* HFP gateway and new incoming connection @ 2011-08-22 16:48 Arnaud Mouiche 2011-08-22 17:49 ` Gustavo Padovan 0 siblings, 1 reply; 10+ messages in thread From: Arnaud Mouiche @ 2011-08-22 16:48 UTC (permalink / raw) To: linux-bluetooth Hi all. I'm currently playing with the HFP unit role provided by bluez (ie. what is related to audio/gateway.c) No problem concerning the connection to a HFP gateway (ie. GSM most of the time). I have more concern with the reverse side, to accept incoming HFP connection, as, obviously I didn't get time to register a "Handsfree agent" for the particular new connecting device, at the proper time. Today, I'm using bluez v4.95, but no real difference with the upstream for this case. Also, I didn't plan to use oFono.... even if it is great piece of software. I also saw a discussions concerning the initial design in the mailling list : http://marc.info/?l=linux-bluetooth&m=126390401614859&w=2 _My questions:_ 1) does this design is today "set in stone" ? 2) It seems the only ways to register an agent at the proper time are: - to trace creation of new devices, and try to register an agent at this time. But what if the device doesn't show HFP SDP record when connection for the first time, and activate it later ? Any race conditions ? or - collect the authorization request in the adapter user agent, when "audio_device_request_authorization" is called. So it means that the user agent must forward request concerning the HFP uuid to the HFP service. True ? 3) What do you think of the possibility to set a "adapter based" Handsfree agent, and use it when there is no "device based" handsfee argent matching ? (the same way "device_request_authentication" (src/device.c) is looking for an agent registered to the device first, then, for an agent registered to the adapter) Regards, Arnaud Mouiche ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-22 16:48 HFP gateway and new incoming connection Arnaud Mouiche @ 2011-08-22 17:49 ` Gustavo Padovan 2011-08-22 19:58 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Gustavo Padovan @ 2011-08-22 17:49 UTC (permalink / raw) To: Arnaud Mouiche; +Cc: linux-bluetooth * Arnaud Mouiche <arnaud.mouiche@invoxia.com> [2011-08-22 18:48:57 +0200]: > Hi all. > > I'm currently playing with the HFP unit role provided by bluez (ie. > what is related to audio/gateway.c) > No problem concerning the connection to a HFP gateway (ie. GSM most > of the time). > > I have more concern with the reverse side, to accept incoming HFP > connection, as, obviously I didn't get time to register a "Handsfree > agent" for the particular new connecting device, at the proper time. > > Today, I'm using bluez v4.95, but no real difference with the > upstream for this case. > Also, I didn't plan to use oFono.... even if it is great piece of software. > > I also saw a discussions concerning the initial design in the > mailling list : > http://marc.info/?l=linux-bluetooth&m=126390401614859&w=2 > > _My questions:_ > 1) does this design is today "set in stone" ? Not sure, we just changed it to add HFP version information. > > 2) It seems the only ways to register an agent at the proper time are: > - to trace creation of new devices, and try to register an agent at > this time. > But what if the device doesn't show HFP SDP record when connection > for the first time, and activate it later ? > Any race conditions ? You should listen to DBus UUID property change for the device in the Agent side. Check the bluetooth plugin inside oFono to learn how to implement that. > or > - collect the authorization request in the adapter user agent, when > "audio_device_request_authorization" is called. > So it means that the user agent must forward request concerning the > HFP uuid to the HFP service. > > True ? > > 3) What do you think of the possibility to set a "adapter based" > Handsfree agent, and use it when there is no "device based" handsfee > argent matching ? I think Luiz also wants that. Luiz? Gustavo ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-22 17:49 ` Gustavo Padovan @ 2011-08-22 19:58 ` Luiz Augusto von Dentz 2011-08-23 9:08 ` Arnaud Mouiche 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2011-08-22 19:58 UTC (permalink / raw) To: Arnaud Mouiche, linux-bluetooth Hi, On Mon, Aug 22, 2011 at 8:49 PM, Gustavo Padovan <padovan@profusion.mobi> wrote: > * Arnaud Mouiche <arnaud.mouiche@invoxia.com> [2011-08-22 18:48:57 +0200]: > >> Hi all. >> >> I'm currently playing with the HFP unit role provided by bluez (ie. >> what is related to audio/gateway.c) >> No problem concerning the connection to a HFP gateway (ie. GSM most >> of the time). >> >> I have more concern with the reverse side, to accept incoming HFP >> connection, as, obviously I didn't get time to register a "Handsfree >> agent" for the particular new connecting device, at the proper time. >> >> Today, I'm using bluez v4.95, but no real difference with the >> upstream for this case. >> Also, I didn't plan to use oFono.... even if it is great piece of software. >> >> I also saw a discussions concerning the initial design in the >> mailling list : >> http://marc.info/?l=linux-bluetooth&m=126390401614859&w=2 >> >> _My questions:_ >> 1) does this design is today "set in stone" ? > > Not sure, we just changed it to add HFP version information. > >> >> 2) It seems the only ways to register an agent at the proper time are: >> - to trace creation of new devices, and try to register an agent at >> this time. >> But what if the device doesn't show HFP SDP record when connection >> for the first time, and activate it later ? >> Any race conditions ? > > You should listen to DBus UUID property change for the device in the Agent > side. Check the bluetooth plugin inside oFono to learn how to implement that. > >> or >> - collect the authorization request in the adapter user agent, when >> "audio_device_request_authorization" is called. >> So it means that the user agent must forward request concerning the >> HFP uuid to the HFP service. >> >> True ? >> >> 3) What do you think of the possibility to set a "adapter based" >> Handsfree agent, and use it when there is no "device based" handsfee >> argent matching ? > > I think Luiz also wants that. Luiz? Yep, we have some plans to move the Agent registration to adapter path, so it gonna be per adapter. This is necessary to set the features bit properly in the record and probably gonna support both roles (with different agents). My initial idea was to use Media API, but perhaps is confusing since HFP is not entirely about audio but call control too (mostly) so perhaps we gonna have a different interface for it e.g. org.bluez.Telephony, in addition to that we are planning to pass the endpoint bus and path together in the NewConnection so the telephony agent (oFono) can communicate directly to endpoint in use (PulseAudio). Those are my plans, but none of this is set in stone and Im pretty open for ideas -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-22 19:58 ` Luiz Augusto von Dentz @ 2011-08-23 9:08 ` Arnaud Mouiche 2011-08-23 11:14 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Arnaud Mouiche @ 2011-08-23 9:08 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hi, On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: > [...] > Yep, we have some plans to move the Agent registration to adapter > path, so it gonna be per adapter. This is necessary to set the > features bit properly in the record and probably gonna support both > roles (with different agents). My initial idea was to use Media API, > but perhaps is confusing since HFP is not entirely about audio but > call control too (mostly) so perhaps we gonna have a different > interface for it e.g. org.bluez.Telephony, in addition to that we are > planning to pass the endpoint bus and path together in the > NewConnection so the telephony agent (oFono) can communicate directly > to endpoint in use (PulseAudio). > > Those are my plans, but none of this is set in stone and Im pretty > open for ideas > what about using the org.bluez.Adapter / RegisterAgent API, and add: - the possibility to setup multiple agents (maintain a list of agents) - use the "capability" field as a filter definition to find the good agent for the particular request ex: audio/gateway.c::agent_sendfd() will look for a agent in the list, with a "HFP" capability to send the "NewConnection" request Arnaud ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-23 9:08 ` Arnaud Mouiche @ 2011-08-23 11:14 ` Luiz Augusto von Dentz 2011-08-23 11:53 ` Arnaud Mouiche 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2011-08-23 11:14 UTC (permalink / raw) To: Arnaud Mouiche; +Cc: linux-bluetooth Hi Arnaud, On Tue, Aug 23, 2011 at 12:08 PM, Arnaud Mouiche <arnaud.mouiche@invoxia.com> wrote: > Hi, > > On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: >> >> [...] >> Yep, we have some plans to move the Agent registration to adapter >> path, so it gonna be per adapter. This is necessary to set the >> features bit properly in the record and probably gonna support both >> roles (with different agents). My initial idea was to use Media API, >> but perhaps is confusing since HFP is not entirely about audio but >> call control too (mostly) so perhaps we gonna have a different >> interface for it e.g. org.bluez.Telephony, in addition to that we are >> planning to pass the endpoint bus and path together in the >> NewConnection so the telephony agent (oFono) can communicate directly >> to endpoint in use (PulseAudio). >> >> Those are my plans, but none of this is set in stone and Im pretty >> open for ideas >> > > what about using the org.bluez.Adapter / RegisterAgent API, and add: > - the possibility to setup multiple agents (maintain a list of agents) > - use the "capability" field as a filter definition to find the good agent > for the particular request > ex: > audio/gateway.c::agent_sendfd() will look for a agent in the list, with a > "HFP" capability to send the "NewConnection" request I guess it would be confusing since with the same method we would have different types of agents which implements different interfaces, there is also the problem that by using Adapter interface it would have to be implemented in the core daemon but my intention is to maintain this inside the audio plugin to hook with Media API. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-23 11:14 ` Luiz Augusto von Dentz @ 2011-08-23 11:53 ` Arnaud Mouiche 2011-08-24 11:03 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Arnaud Mouiche @ 2011-08-23 11:53 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On 08/23/2011 01:14 PM, Luiz Augusto von Dentz wrote: > Hi Arnaud, > > On Tue, Aug 23, 2011 at 12:08 PM, Arnaud Mouiche > <arnaud.mouiche@invoxia.com> wrote: >> Hi, >> >> On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: >>> [...] >>> Yep, we have some plans to move the Agent registration to adapter >>> path, so it gonna be per adapter. This is necessary to set the >>> features bit properly in the record and probably gonna support both >>> roles (with different agents). My initial idea was to use Media API, >>> but perhaps is confusing since HFP is not entirely about audio but >>> call control too (mostly) so perhaps we gonna have a different >>> interface for it e.g. org.bluez.Telephony, in addition to that we are >>> planning to pass the endpoint bus and path together in the >>> NewConnection so the telephony agent (oFono) can communicate directly >>> to endpoint in use (PulseAudio). >>> >>> Those are my plans, but none of this is set in stone and Im pretty >>> open for ideas >>> >> what about using the org.bluez.Adapter / RegisterAgent API, and add: >> - the possibility to setup multiple agents (maintain a list of agents) >> - use the "capability" field as a filter definition to find the good agent >> for the particular request >> ex: >> audio/gateway.c::agent_sendfd() will look for a agent in the list, with a >> "HFP" capability to send the "NewConnection" request > I guess it would be confusing since with the same method we would have > different types of agents which implements different interfaces, there > is also the problem that by using Adapter interface it would have to > be implemented in the core daemon but my intention is to maintain this > inside the audio plugin to hook with Media API. > You are right. I didn't see how the core was compartmentalized from plugins. I need took more closely to the Media API... arnaud ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-23 11:53 ` Arnaud Mouiche @ 2011-08-24 11:03 ` Luiz Augusto von Dentz 2011-08-25 8:37 ` Arnaud Mouiche ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Luiz Augusto von Dentz @ 2011-08-24 11:03 UTC (permalink / raw) To: Arnaud Mouiche; +Cc: linux-bluetooth Hi, On Tue, Aug 23, 2011 at 2:53 PM, Arnaud Mouiche <arnaud.mouiche@invoxia.com> wrote: > On 08/23/2011 01:14 PM, Luiz Augusto von Dentz wrote: >> >> Hi Arnaud, >> >> On Tue, Aug 23, 2011 at 12:08 PM, Arnaud Mouiche >> <arnaud.mouiche@invoxia.com> wrote: >>> >>> Hi, >>> >>> On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: >>>> >>>> [...] >>>> Yep, we have some plans to move the Agent registration to adapter >>>> path, so it gonna be per adapter. This is necessary to set the >>>> features bit properly in the record and probably gonna support both >>>> roles (with different agents). My initial idea was to use Media API, >>>> but perhaps is confusing since HFP is not entirely about audio but >>>> call control too (mostly) so perhaps we gonna have a different >>>> interface for it e.g. org.bluez.Telephony, in addition to that we are >>>> planning to pass the endpoint bus and path together in the >>>> NewConnection so the telephony agent (oFono) can communicate directly >>>> to endpoint in use (PulseAudio). >>>> >>>> Those are my plans, but none of this is set in stone and Im pretty >>>> open for ideas >>>> >>> what about using the org.bluez.Adapter / RegisterAgent API, and add: >>> - the possibility to setup multiple agents (maintain a list of agents) >>> - use the "capability" field as a filter definition to find the good >>> agent >>> for the particular request >>> ex: >>> audio/gateway.c::agent_sendfd() will look for a agent in the list, >>> with a >>> "HFP" capability to send the "NewConnection" request >> >> I guess it would be confusing since with the same method we would have >> different types of agents which implements different interfaces, there >> is also the problem that by using Adapter interface it would have to >> be implemented in the core daemon but my intention is to maintain this >> inside the audio plugin to hook with Media API. >> > You are right. I didn't see how the core was compartmentalized from plugins. > I need took more closely to the Media API... > How about the following: Telephony hierarchy [experiemental] =================== Service org.bluez Interface org.bluez.Telephony Object path [variable prefix]/{hci0,hci1,...} Methods void RegisterAgent(object path, dict properties) Register a TelephonyAgent to sender, the sender can register as many agents as it likes. Note: If the sender disconnects its agents are automatically unregistered. possible properties: string UUID: UUID of the profile which the agent is for. uint16 Version: Version of the profile which the agent implements. byte Features: Agent supported features as defined in profile spec e.g. HFP. Possible Errors: org.bluez.Error.InvalidArguments void UnregisterAgent(object path) Unregister sender agent. TelephonyAgent hierarchy ======================== Service unique name Interface org.bluez.TelephonyAgent Object path freely definable ethods void NewConnection(filedescriptor fd, dict properties) This method gets called whenever a new connection has been established. This method assumes that DBus daemon with file descriptor passing capability is being used. The agent should only return successfully once the establishment of the service level connection (SLC) has been completed. In the case of Handsfree this means that BRSF exchange has been performed and necessary initialization has been done. If Endpoint is set the agent is responsible to create an object implementing org.bluez.MediaTransport and notify the Endpoint using org.bluez.MediaEndpoint. possible properties: strict Device: BlueZ remote device object. string UUID: Profile UUID of the connection. uint16 Version: Remote profile version. byte Features: Remote profile features. string Endpoint: Optional. Endpoint bus id. string EndpointPath: Optional. Endpoint object path. Possible Errors: org.bluez.Error.InvalidArguments org.bluez.Error.Failed void Release() This method gets called whenever the service daemon unregisters the agent or whenever the Adapter where the TelephonyAgent registers itself is removed. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-24 11:03 ` Luiz Augusto von Dentz @ 2011-08-25 8:37 ` Arnaud Mouiche 2011-08-26 14:35 ` Frederic Danis 2011-08-26 14:39 ` Frederic Danis 2 siblings, 0 replies; 10+ messages in thread From: Arnaud Mouiche @ 2011-08-25 8:37 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hi, This looks fine to me. But I'm not the one with sufficiently good experience in this part of bluez to be a good advise, and see long-term implications regards, arnaud On 08/24/2011 01:03 PM, Luiz Augusto von Dentz wrote: > Hi, > > On Tue, Aug 23, 2011 at 2:53 PM, Arnaud Mouiche > <arnaud.mouiche@invoxia.com> wrote: >> On 08/23/2011 01:14 PM, Luiz Augusto von Dentz wrote: >>> Hi Arnaud, >>> >>> On Tue, Aug 23, 2011 at 12:08 PM, Arnaud Mouiche >>> <arnaud.mouiche@invoxia.com> wrote: >>>> Hi, >>>> >>>> On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: >>>>> [...] >>>>> Yep, we have some plans to move the Agent registration to adapter >>>>> path, so it gonna be per adapter. This is necessary to set the >>>>> features bit properly in the record and probably gonna support both >>>>> roles (with different agents). My initial idea was to use Media API, >>>>> but perhaps is confusing since HFP is not entirely about audio but >>>>> call control too (mostly) so perhaps we gonna have a different >>>>> interface for it e.g. org.bluez.Telephony, in addition to that we are >>>>> planning to pass the endpoint bus and path together in the >>>>> NewConnection so the telephony agent (oFono) can communicate directly >>>>> to endpoint in use (PulseAudio). >>>>> >>>>> Those are my plans, but none of this is set in stone and Im pretty >>>>> open for ideas >>>>> >>>> what about using the org.bluez.Adapter / RegisterAgent API, and add: >>>> - the possibility to setup multiple agents (maintain a list of agents) >>>> - use the "capability" field as a filter definition to find the good >>>> agent >>>> for the particular request >>>> ex: >>>> audio/gateway.c::agent_sendfd() will look for a agent in the list, >>>> with a >>>> "HFP" capability to send the "NewConnection" request >>> I guess it would be confusing since with the same method we would have >>> different types of agents which implements different interfaces, there >>> is also the problem that by using Adapter interface it would have to >>> be implemented in the core daemon but my intention is to maintain this >>> inside the audio plugin to hook with Media API. >>> >> You are right. I didn't see how the core was compartmentalized from plugins. >> I need took more closely to the Media API... >> > How about the following: > > Telephony hierarchy [experiemental] > =================== > > Service org.bluez > Interface org.bluez.Telephony > Object path [variable prefix]/{hci0,hci1,...} > > Methods void RegisterAgent(object path, dict properties) > > Register a TelephonyAgent to sender, the sender can > register as many agents as it likes. > > Note: If the sender disconnects its agents are > automatically unregistered. > > possible properties: > > string UUID: > > UUID of the profile which the agent is > for. > > uint16 Version: > > Version of the profile which the agent > implements. > > byte Features: > > Agent supported features as defined in > profile spec e.g. HFP. > > Possible Errors: org.bluez.Error.InvalidArguments > > > void UnregisterAgent(object path) > > Unregister sender agent. > > TelephonyAgent hierarchy > ======================== > > Service unique name > Interface org.bluez.TelephonyAgent > Object path freely definable > > ethods void NewConnection(filedescriptor fd, dict properties) > > This method gets called whenever a new connection > has been established. This method assumes that DBus > daemon with file descriptor passing capability is > being used. > > The agent should only return successfully once the > establishment of the service level connection (SLC) > has been completed. In the case of Handsfree this > means that BRSF exchange has been performed and > necessary initialization has been done. > > If Endpoint is set the agent is responsible to > create an object implementing org.bluez.MediaTransport > and notify the Endpoint using org.bluez.MediaEndpoint. > > possible properties: > > strict Device: > > BlueZ remote device object. > > string UUID: > > Profile UUID of the connection. > > uint16 Version: > > Remote profile version. > > byte Features: > > Remote profile features. > > string Endpoint: > > Optional. Endpoint bus id. > > string EndpointPath: > > Optional. Endpoint object path. > > Possible Errors: org.bluez.Error.InvalidArguments > org.bluez.Error.Failed > > void Release() > > This method gets called whenever the service daemon > unregisters the agent or whenever the Adapter where > the TelephonyAgent registers itself is removed. > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-24 11:03 ` Luiz Augusto von Dentz 2011-08-25 8:37 ` Arnaud Mouiche @ 2011-08-26 14:35 ` Frederic Danis 2011-08-26 14:39 ` Frederic Danis 2 siblings, 0 replies; 10+ messages in thread From: Frederic Danis @ 2011-08-26 14:35 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hello, Le 24/08/2011 13:03, Luiz Augusto von Dentz a écrit : > Hi, > > On Tue, Aug 23, 2011 at 2:53 PM, Arnaud Mouiche > <arnaud.mouiche@invoxia.com> wrote: >> On 08/23/2011 01:14 PM, Luiz Augusto von Dentz wrote: >>> >>> Hi Arnaud, >>> >>> On Tue, Aug 23, 2011 at 12:08 PM, Arnaud Mouiche >>> <arnaud.mouiche@invoxia.com> wrote: >>>> >>>> Hi, >>>> >>>> On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: >>>>> >>>>> [...] >>>>> Yep, we have some plans to move the Agent registration to adapter >>>>> path, so it gonna be per adapter. This is necessary to set the >>>>> features bit properly in the record and probably gonna support both >>>>> roles (with different agents). My initial idea was to use Media API, >>>>> but perhaps is confusing since HFP is not entirely about audio but >>>>> call control too (mostly) so perhaps we gonna have a different >>>>> interface for it e.g. org.bluez.Telephony, in addition to that we are >>>>> planning to pass the endpoint bus and path together in the >>>>> NewConnection so the telephony agent (oFono) can communicate directly >>>>> to endpoint in use (PulseAudio). >>>>> >>>>> Those are my plans, but none of this is set in stone and Im pretty >>>>> open for ideas >>>>> >>>> what about using the org.bluez.Adapter / RegisterAgent API, and add: >>>> - the possibility to setup multiple agents (maintain a list of agents) >>>> - use the "capability" field as a filter definition to find the good >>>> agent >>>> for the particular request >>>> ex: >>>> audio/gateway.c::agent_sendfd() will look for a agent in the list, >>>> with a >>>> "HFP" capability to send the "NewConnection" request >>> >>> I guess it would be confusing since with the same method we would have >>> different types of agents which implements different interfaces, there >>> is also the problem that by using Adapter interface it would have to >>> be implemented in the core daemon but my intention is to maintain this >>> inside the audio plugin to hook with Media API. >>> >> You are right. I didn't see how the core was compartmentalized from plugins. >> I need took more closely to the Media API... >> > > How about the following: > > Telephony hierarchy [experiemental] > =================== > > Service org.bluez > Interface org.bluez.Telephony > Object path [variable prefix]/{hci0,hci1,...} > > Methods void RegisterAgent(object path, dict properties) > > Register a TelephonyAgent to sender, the sender can > register as many agents as it likes. > > Note: If the sender disconnects its agents are > automatically unregistered. > > possible properties: > > string UUID: > > UUID of the profile which the agent is > for. > > uint16 Version: > > Version of the profile which the agent > implements. > > byte Features: > > Agent supported features as defined in > profile spec e.g. HFP. > > Possible Errors: org.bluez.Error.InvalidArguments > > > void UnregisterAgent(object path) > > Unregister sender agent. > > TelephonyAgent hierarchy > ======================== > > Service unique name > Interface org.bluez.TelephonyAgent > Object path freely definable > > ethods void NewConnection(filedescriptor fd, dict properties) > > This method gets called whenever a new connection > has been established. This method assumes that DBus > daemon with file descriptor passing capability is > being used. > > The agent should only return successfully once the > establishment of the service level connection (SLC) > has been completed. In the case of Handsfree this > means that BRSF exchange has been performed and > necessary initialization has been done. > > If Endpoint is set the agent is responsible to > create an object implementing org.bluez.MediaTransport > and notify the Endpoint using org.bluez.MediaEndpoint. > > possible properties: > > strict Device: > > BlueZ remote device object. > > string UUID: > > Profile UUID of the connection. > > uint16 Version: > > Remote profile version. > > byte Features: > > Remote profile features. > > string Endpoint: > > Optional. Endpoint bus id. > > string EndpointPath: > > Optional. Endpoint object path. > > Possible Errors: org.bluez.Error.InvalidArguments > org.bluez.Error.Failed > > void Release() > > This method gets called whenever the service daemon > unregisters the agent or whenever the Adapter where > the TelephonyAgent registers itself is removed. > > This interface should be used with org.bluez.Media API, daemon registering with org.bluez.Telephony will take care of control channel while org.bluez.Media will be used to manage audio part, did I understand correctly ? I understand how connection will be managed for server part (incoming connections), but what will be used for client part (outgoing connections) ? It may be possible to use a per device interface similar to org.bluez.HandsfreeGateway with only connect/disconnect methods (with different interfaces for each HFP roles). Regards Fred -- Frederic Danis Open Source Technology Centre frederic.danis@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: HFP gateway and new incoming connection 2011-08-24 11:03 ` Luiz Augusto von Dentz 2011-08-25 8:37 ` Arnaud Mouiche 2011-08-26 14:35 ` Frederic Danis @ 2011-08-26 14:39 ` Frederic Danis 2 siblings, 0 replies; 10+ messages in thread From: Frederic Danis @ 2011-08-26 14:39 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hello, Le 24/08/2011 13:03, Luiz Augusto von Dentz a écrit : > Hi, > > On Tue, Aug 23, 2011 at 2:53 PM, Arnaud Mouiche > <arnaud.mouiche@invoxia.com> wrote: >> On 08/23/2011 01:14 PM, Luiz Augusto von Dentz wrote: >>> >>> Hi Arnaud, >>> >>> On Tue, Aug 23, 2011 at 12:08 PM, Arnaud Mouiche >>> <arnaud.mouiche@invoxia.com> wrote: >>>> >>>> Hi, >>>> >>>> On 08/22/2011 09:58 PM, Luiz Augusto von Dentz wrote: >>>>> >>>>> [...] >>>>> Yep, we have some plans to move the Agent registration to adapter >>>>> path, so it gonna be per adapter. This is necessary to set the >>>>> features bit properly in the record and probably gonna support both >>>>> roles (with different agents). My initial idea was to use Media API, >>>>> but perhaps is confusing since HFP is not entirely about audio but >>>>> call control too (mostly) so perhaps we gonna have a different >>>>> interface for it e.g. org.bluez.Telephony, in addition to that we are >>>>> planning to pass the endpoint bus and path together in the >>>>> NewConnection so the telephony agent (oFono) can communicate directly >>>>> to endpoint in use (PulseAudio). >>>>> >>>>> Those are my plans, but none of this is set in stone and Im pretty >>>>> open for ideas >>>>> >>>> what about using the org.bluez.Adapter / RegisterAgent API, and add: >>>> - the possibility to setup multiple agents (maintain a list of agents) >>>> - use the "capability" field as a filter definition to find the good >>>> agent >>>> for the particular request >>>> ex: >>>> audio/gateway.c::agent_sendfd() will look for a agent in the list, >>>> with a >>>> "HFP" capability to send the "NewConnection" request >>> >>> I guess it would be confusing since with the same method we would have >>> different types of agents which implements different interfaces, there >>> is also the problem that by using Adapter interface it would have to >>> be implemented in the core daemon but my intention is to maintain this >>> inside the audio plugin to hook with Media API. >>> >> You are right. I didn't see how the core was compartmentalized from plugins. >> I need took more closely to the Media API... >> > > How about the following: > > Telephony hierarchy [experiemental] > =================== > > Service org.bluez > Interface org.bluez.Telephony > Object path [variable prefix]/{hci0,hci1,...} > > Methods void RegisterAgent(object path, dict properties) > > Register a TelephonyAgent to sender, the sender can > register as many agents as it likes. > > Note: If the sender disconnects its agents are > automatically unregistered. > > possible properties: > > string UUID: > > UUID of the profile which the agent is > for. > > uint16 Version: > > Version of the profile which the agent > implements. > > byte Features: > > Agent supported features as defined in > profile spec e.g. HFP. > > Possible Errors: org.bluez.Error.InvalidArguments > > > void UnregisterAgent(object path) > > Unregister sender agent. > > TelephonyAgent hierarchy > ======================== > > Service unique name > Interface org.bluez.TelephonyAgent > Object path freely definable > > ethods void NewConnection(filedescriptor fd, dict properties) > > This method gets called whenever a new connection > has been established. This method assumes that DBus > daemon with file descriptor passing capability is > being used. > > The agent should only return successfully once the > establishment of the service level connection (SLC) > has been completed. In the case of Handsfree this > means that BRSF exchange has been performed and > necessary initialization has been done. > > If Endpoint is set the agent is responsible to > create an object implementing org.bluez.MediaTransport > and notify the Endpoint using org.bluez.MediaEndpoint. > > possible properties: > > strict Device: > > BlueZ remote device object. > > string UUID: > > Profile UUID of the connection. > > uint16 Version: > > Remote profile version. > > byte Features: > > Remote profile features. > > string Endpoint: > > Optional. Endpoint bus id. > > string EndpointPath: > > Optional. Endpoint object path. > > Possible Errors: org.bluez.Error.InvalidArguments > org.bluez.Error.Failed > > void Release() > > This method gets called whenever the service daemon > unregisters the agent or whenever the Adapter where > the TelephonyAgent registers itself is removed. > > This interface should be used with org.bluez.Media API, daemon registering with org.bluez.Telephony will take care of control channel while org.bluez.Media will be used to manage audio part, did I understand correctly ? I understand how connection will be managed for server part (incoming connections), but what will be used for client part (outgoing connections) ? It may be possible to use a per device interface similar to org.bluez.HandsfreeGateway with only connect/disconnect methods (with different interfaces for each HFP roles). Regards Fred -- Frederic Danis Open Source Technology Centre frederic.danis@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-08-26 14:39 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-22 16:48 HFP gateway and new incoming connection Arnaud Mouiche 2011-08-22 17:49 ` Gustavo Padovan 2011-08-22 19:58 ` Luiz Augusto von Dentz 2011-08-23 9:08 ` Arnaud Mouiche 2011-08-23 11:14 ` Luiz Augusto von Dentz 2011-08-23 11:53 ` Arnaud Mouiche 2011-08-24 11:03 ` Luiz Augusto von Dentz 2011-08-25 8:37 ` Arnaud Mouiche 2011-08-26 14:35 ` Frederic Danis 2011-08-26 14:39 ` Frederic Danis
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.