Hi Vinicius,

On 03/27/2013 09:22 AM, Vinicius Costa Gomes wrote:
> Hi Denis,
>
> On 23:59 Tue 26 Mar, Denis Kenzior wrote:
>> Hi Vinicius,
>>
>> On 03/26/2013 04:28 PM, Vinicius Costa Gomes wrote:
>>> Now each handsfree implementation may be notified that a card wants
>>> its audio to be connected.
>>>
>>> In case, that the cards wishes to fallback to the default SCO connection
>>> procedure, it just needs to return -ENOSYS.
>>
>> Are you interpreting section 4.11.2:
>> "For all HF initiated audio connection establishments for which both
>> sides support the Codec Negotiation feature, the HF shall trigger
>> the AG to establish a Codec Connection. This is necessary because
>> only the AG knows about the codec selection and settings of the
>> network."
>>
>> ... to mean that AT+BCC is only sent when both sides support codec
>> negotiation?  e.g. if one or the other side does not support codec
>> negotiation, then we are supposed to fall back to old SCO
>> establishment rules procedures?
>
> Yes. This behaviour is even covered in one of the PTS tests: TP/ACC/BV-03-I
> (from the description of the test, "To verify the capability of the HF
> initiating a legacy audio connection with an AG that does not support the
> Codec Connection setup procedure. The HF should be able to correctly negotiate
> a working legacy audio connection to the AG.")
>

Okay, that makes things a little harder since we cannot determine the 
driver to use until the SLC is established.

<snip>

>>> +	if (!driver || !driver->connect)
>>> +		goto fallback;
>>> +
>>> +	err = driver->connect(card, card_connect_reply_cb, card);
>>> +	if (err == -EINPROGRESS) {
>>> +		card->msg = dbus_message_ref(msg);
>>> +		return NULL;
>>
>> As mentioned earlier, the driver should not return an int, however,
>> lets revisit this part.  I want to better understand the AT+BCC and
>> codec negotiation interactions.
>
>
> Of course.
>
> Another thing that may make sense to bring up now is the AG case: if we want
> to have a HFP 1.6 capable AG, we may want to select the codec (send a +BCS)
> before establishing the SCO connection. I was thinking of setting a specific
> error code in the callback to signify that the core handsfree-audio may
> connect the SCO at that point.
>

I thought of setting error codes in callbacks, but I'm not happy with 
that solution.  Perhaps we should make SCO establishment a part of the 
card utility API.  e.g. ofono_handsfree_card_connect_sco().  That way 
the AG can run the required +BCS transactions and call the above 
function when it comes to making the SCO connection.

For HFP 1.6/1.5, we can either use +BCC or call 
ofono_handsfree_card_connect_sco directly.

Thoughts, other ideas?

Regards,
-Denis