Re: [PATCH v17 01/15] doc: Add telephony interface documents

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
[off-list ref] wrote:

quoted

quoted

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.

quoted

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