Hello Luiz,

On 09/08/2012 16:42, Luiz Augusto von Dentz wrote:
> Hi Frederic,
>
> On Thu, Aug 9, 2012 at 1:03 PM, Frederic Danis
> <frederic.danis@linux.intel.com> wrote:
>>> They are mostly independent, oFono will never really acquire or
>>> anything like that, but there are some AT commands (+VGS,+VGM) that
>>> does notify PA about volume gain changes and as I said above it could
>>> be useful to notify about wideband speech in the same way.
>>>
>>
>> It is also possible that telephony agent implements a TelephonyClient
>> interface for each connection, object which should be returned by
>> NewConnection method.
>
> You should return the properties as well to avoid another round trip
> to get the properties of the client. Btw this requires yet another
> object and interface that increases the complexity of the solution.

OK, I add the client properties to return of NewConnection.

I agree with you this increase complexity, but as media transport is 
linked to the codec it uses I do not find another solution.

>> In this case BlueZ will listen to properties changes on this interface (like
>> for remote volume change) or call SetProperty (when receiving volume change
>> from PulseAudio).
>>
>> As MediaTransport may change during wideband speech HFP session, due to
>> codec re-negotiation, this architecture may simplify media transport code.
>
> I don't think we need to do the codec negotiation on acquire, it
> actually doesn't work since the transport cannot be reconfigured with
> another codec as by design the endpoints can only have 1 codec, so I
> suggest having the list of available codecs be given upfront in
> NewConnection then you actually negotiate the codec before responding.

Yes , I pass them in NewConnection method.

> If the remote device attempts to change the codec oFono then can check
> if the codec is available in the list of available codecs given on
> NewConnection, if it find a match then it accepts and emit a signal of
> codec changes that triggers a new transport to be configured.

In HFP 1.6 specs (chapter 4.11.3, page 32) I saw that after codec 
negotiation "the AG shall open the synchronous connection". This may 
imply that we will need to do it when PA tries to use HFP audio connection.

> Btw, Im not sure if this is really productive to discuss before we
> even have this working with 1.5, IMO is easier to do things step by
> step and the first step should be to get HFP 1.5 working as the
> current upstream does then we think about 1.6 and other profiles such
> as DUN and SAP.

I agree with you that most important point is to get a working HFP 1.5, 
but moving to HFP 1.6 may break the telephony interface if we do not 
take a look at it now.

Find attached new version of documents proposal.

Regards

Fred

-- 
Frederic Danis                            Open Source Technology Center
frederic.danis@intel.com                              Intel Corporation