ubuntu-phone team mailing list archive

[Simon Fels <simon.fels@xxxxxxxxxxxxx>]

On 08.10.2015 15:08, Michael Zanetti wrote:
> On 08.10.2015 14:57, Simon Fels wrote:
> > On 08.10.2015 14:30, Michał Sawicz wrote:
> > > W dniu 08.10.2015 o 14:00, Simon Fels pisze:
> > > > A tablet stays a tablet. Having a modem included doesn't make it a
> > > > phone. The Bluetooth device class is meant to stay static for one device
> > > > forever. No dynamic changes. It is your first point to find out what
> > > > kind of Bluetooth device you've found.
> > > >
> > > > Btw. that a tablet includes a GSM modem still doesn't say anything about
> > > > if it also allows you to do voice calls ... If we have a "phablet"
> > > > device then this needs to be categorized as a phone as it provides voice
> > > > call capabilities. See
> > > > https://www.bluetooth.org/en-us/specification/assigned-numbers/baseband
> > > > for some more details on the major and minor device classes we're
> > > > talking about here. Putting the device into the right major/minor class
> > > > is crucial as some car kits doesn't allow you to pair them only with
> > > > devices part of the phone device class...
> > > >
> > > > Also what would be the benefit of having an option for the user to
> > > > override this?
> > >
> > > I think you just wrote what would be the benefit - some car kits only
> > > connect to phone devices. What if I wanted my 3G tablet (no voice, but
> > > VoIP still works!) to connect to the car?
> >
> > That would a use case, yes, but still really a workaround for a corner
> > case.
> >
> > However that wouldn't work with our implementation playing the role of
> > the audio gateway strictly requires a modem with voice call
> > capabilities.. no way to inject your VoIP stack here. It also hardly
> > depends on how the hardware is build. For HFP on most Android devices
> > the audio is directly routed from the microphone to the BT chip without
> > involving the CPU so we can gurantee you're even able to inject your
> > VoIP audio data.
>
> Hmm... wouldn't be so sure about that.. Yes, HFP's control channel is
> based on AT commands, and it's also correct that most hardware wires the
> sound chip with the Bluetooth chip directly, still, every Bluetooth chip
> I came across so far allowed routing audio data through the HCI. AFAIK,
> bypassing the HCI is the optional case here. I did see dummy AT command
> layers injecting VoIP into HFP before...

On Android devices that is the regular case. The audio data is passed to 
the BT chip over a PCM line rather than through HCI. That still doesn't 
say it's not possible to do it but that is a way nobody tested yet and 
proved it works.

In our current setup we're using the PCM line approach which also saves 
us from burning CPU cycles on this rather than letting the BT chip which 
is optimised for this doing that.

The next bigger point is how HFP is currently implemented. With the 
shift to BlueZ 5 the implementation moved into ofono as that is the 
natural place where you want to do AT command processing. The current 
implementation expects a voice call capable modem to be present before 
we even even allow the HFP AG profile to be connected. As there can be 
only one provider in the system for a profile we would have to integrate 
what VoIP solution we want to use over HFP into ofono to let it expose a 
modem which we can use as control interface ... However that doesn't say 
that we can add another provider for the HFP profile which becomes 
active in scenarios where we don't have a GSM modem but then has to 
implement the whole profile support on its own with the point of proper 
audio routing still being sorted.

regards,
Simon