[pulseaudio-discuss] [PATCH v5 3/4] bluetooth: add correct HFP rfcomm negotiation

[Luiz Augusto von Dentz]

Hi James,

On Fri, Sep 22, 2017 at 9:29 PM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Fri, 2017-09-22 at 21:09 +0300, Luiz Augusto von Dentz wrote:
>> Hi James,
>>
>> On Thu, Sep 21, 2017 at 10:28 PM, James Bottomley
>> <James.Bottomley at hansenpartnership.com> wrote:
> [...]
>> > +static bool hfp_rfcomm_handle(int fd, pa_bluetooth_transport *t,
>> > const char *buf)
>> > +{
>> > +    struct hfp_config *c = t->config;
>> > +    int val;
>> > +
>>
>> Was this code tested against PTS or you just got it working with some
>> specific headsets? Im guessing this is for SLC handling but Im afraid
>> this was never really qualified properly so perhaps some statement
>> here would be nice.
>>
>> If you have no idea what Im talking about you please have a look at:
>>
>> https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=411
>> 65
>
> The site seems to be login protected, but if this is some type of
> simulator, it would be useful to run it by that if you can get me
> access.

Hmm I thought this would be publicly accessible, it seems it requires
a Bluetooth account, anyway this is the testing spec for HFP.

>> There may be commands we would need to implement even if the
>> indicators are not supported to pass qualification. If this is just a
>> 'works for me' solution then we better put a disclaimer about not
>> using this code on Bluetooth certified products.
>
> I can ask Marcel what the usual certification route of Linux code is,
> if it's important.  I wasn't aware we'd put any pulseaudio code through
> bluetooth qualifications before (unless the vendors just did it
> quietly).

Up to now PA wouldn't be doing any PDU exchange, well except for HSP
but that is limited to just very few commands and don't really need a
state machine, but with HFP there are quite many things that can go
wrong.

> [...]
>> > +    /*
>> > +     * once we're fully connected, just reply OK to everything
>> > +     * it will just be the headset sending the occasional status
>> > +     * update, but we process only the ones we care about
>> > +     */
>>
>> Im not really sure responding "OK" to everything will do well for
>> interoperability, some vendors uses HFP with the its own set of
>> vendor commands which may not always accept OK as a response or it
>> may trigger some special mode.
>
> I modelled that on the android code
>
> https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/src/com/android/bluetooth/hfp/HeadsetStateMachine.java
>
> It responds OK to any vendor specific command it doesn't recognise.

Im not seeing anything like that, anyway it probably has all the
standard AT parsing in place, or the RIL just process them. For
instance, the AT commands to dial, etc, are all valid as well though
headsets normally don't use them carkits or other devices with an UI
probably could.

> James
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss



-- 
Luiz Augusto von Dentz