Using ofono HFP

Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 3622 bytes --]

Hi there,

Bluetooth newbie here, try to be gentle :-)

I am trying to use ofono HFP. But I am not having success so far.

I have Fedora release 13 in vmware fusion virtual machine (the host is a mac
book pro). When I connect my usb bluetooth adapter and bridge it to the vm,
bluez detects it just fine and I can see it with hciconfig.

hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:15:83:15:A3:10  ACL MTU: 672:3  SCO MTU: 128:2
        UP RUNNING PSCAN
        RX bytes:4726 acl:46 sco:0 events:140 errors:0
        TX bytes:1555 acl:74 sco:0 commands:39 errors:0

I can see my cell phone using "hcitool scan" and the HF Voice Gateway
service using "sdtool browse", the service is at channel 4.

The information retrieved from my cell is:

root(a)fedora test # hcitool info 00:1D:28:4B:9A:A8
Requesting information ...
        BD Address:  00:1D:28:4B:9A:A8
        Device Name: Moycell
        LMP Version: 1.2 (0x2) LMP Subversion: 0x41c
        Manufacturer: Philips Semiconductors (37)
        Features: 0xff 0xed 0x8d 0xf8 0x1a 0x08 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot
offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <channel quality> <SCO link> <HV3 packets>
                <u-law log> <A-law log> <CVSD> <power control>
                <transparent SCO> <broadcast encrypt> <enhanced iscan>
                <interlaced iscan> <interlaced pscan> <inquiry with RSSI>
                <extended SCO> <EV5 packets> <AFH cap. slave>
                <AFH class. slave> <AFH cap. master>

I paired my cell phone using blueman utilities. I was able to transfer a
file from linux to the cell phone. The cell phone sees the hands free
service from linux, but, when I try to connect from my cell phone to Linux,
I get this in /var/log/messages:

Sep 26 08:29:56 fedora bluetoothd[19854]: link_key_request
(sba=00:15:83:15:A3:10, dba=00:1D:28:4B:9A:A8)

And I get a prompt from blueman asking me to allow the cell phone to
connect, I accept and after a few seconds the cell phone reports the
bluetooth connection as failed. Nothing in /var/log/messages.

ofono version is 0.28

Output of rpm -qa | grep bluez is:

bluez-compat-4.64-1.fc13.i686
bluez-libs-devel-4.64-1.fc13.i686
bluez-alsa-4.64-1.fc13.i686
bluez-libs-4.64-1.fc13.i686
pybluez-0.16-2.fc13.i686
bluez-4.64-1.fc13.i686
bluez-hcidump-1.42-4.fc12.i686

dbus version is dbus-1.2.24-1.fc13.i686

I decided both bluez and ofono from latest git sources (latest as of 2 days
ago), and the only difference is I get an additional error after the
link_key_request:

bluetoothd[14120]: audio/headset.c:rfcomm_io_cb() ERR or HUP on RFCOMM
socket

I was advised by padovan on IRC that I should try dbus >= 1.3 ... I am going
to try that today, I was putting that off cuz this seemed like a lower level
issue and upgrading dbus seemed like non-trivial since many things depend on
dbus and fedora 13 does not seem to include rpm for dbus >= 1.3

Can I somehow to try ofono connect to my cell and not the other way around?

A few days ago I tried the project "nohands" (
http://nohands.sourceforge.net/), which connect to the cell phone just fine
and I am able to place and receive calls, but since the project looks like
kind of dead I decided to give ofono a try because looks more active.

The final goal here is NOT use this with pulseaudio, but rather have access
to the SCO socket so I can manipulate the audio.

Any advice will be certainly welcomed,

--
Moises Silva

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4795 bytes --]

Re: Using ofono HFP

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Hi Moises,

> I was advised by padovan on IRC that I should try dbus >= 1.3 ... I am
> going to try that today, I was putting that off cuz this seemed like a
> lower level issue and upgrading dbus seemed like non-trivial since many
> things depend on dbus and fedora 13 does not seem to include rpm for
> dbus >= 1.3

Neither oFono nor BlueZ will enable the plugins for HFP support unless
DBus-1.3 is installed (or alternatively a hacked dbus-1.2 with file
descriptor passing support)

> 
> Can I somehow to try ofono connect to my cell and not the other way around?

The connection initiator is actually irrelevant.  You just need to make
sure that BlueZ has paired with your device and the HandsfreeGateway
interface is created for your device.

> The final goal here is NOT use this with pulseaudio, but rather have
> access to the SCO socket so I can manipulate the audio.

If you want this, then you will need to eventually write your own plugin
that will manage the RFCOMM and SCO sockets.  Today, BlueZ does this part...

Regards,
-Denis

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Hi Denis,

Neither oFono nor BlueZ will enable the plugins for HFP support unless
> DBus-1.3 is installed (or alternatively a hacked dbus-1.2 with file
> descriptor passing support)


That explains a lot.



> If you want this, then you will need to eventually write your own plugin
> that will manage the RFCOMM and SCO sockets.  Today, BlueZ does this
> part...
>

I will look into that then. Thanks a lot for the response. This puts me back
in the right track.

Regards,

-
Moises

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 945 bytes --]

RE: Using ofono HFP

[Zhang, Zhenhua]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

Hi Moises,

Denis Kenzior wrote:
> Hi Moises,
> 
>> I was advised by padovan on IRC that I should try dbus >= 1.3 ... I
>> am going to try that today, I was putting that off cuz this seemed
>> like a lower level issue and upgrading dbus seemed like non-trivial
>> since many things depend on dbus and fedora 13 does not seem to
>> include rpm for dbus >= 1.3
> 
> Neither oFono nor BlueZ will enable the plugins for HFP support unless
> DBus-1.3 is installed (or alternatively a hacked dbus-1.2 with file
> descriptor passing support) 

Denis is right. For example, my ubuntu 10.04 has dbus-1.3.0 so HFP works smoothly on my laptop. I remember there's someone has a hacked dbus-1.2 with fd passing support. It does work but I would recommend you use dbus-1.3.

>> 
>> Can I somehow to try ofono connect to my cell and not the other way
>> around? 
> 
> The connection initiator is actually irrelevant.  You just need to
> make sure that BlueZ has paired with your device and the
> HandsfreeGateway interface is created for your device.
> 
>> The final goal here is NOT use this with pulseaudio, but rather have
>> access to the SCO socket so I can manipulate the audio.
> 
> If you want this, then you will need to eventually write your
> own plugin
> that will manage the RFCOMM and SCO sockets.  Today, BlueZ
> does this part...

Right. See bluez/audio/unix.c for BlueZ part SCO code that cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX type socks.

> Regards,
> -Denis
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua <zhenhua.zhang@intel.com>wrote:

> Right. See bluez/audio/unix.c for BlueZ part SCO code that cooperate with
> pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX type socks.
>
>
Thanks a lot for the additional help. I just setup a quick wiki page to
start documenting this: http://ofono.org/wiki/hands-free-profile

It's small and crappy, but it's a start. I will keep improving it as I go.

Regards,

-
Moises Silva

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 867 bytes --]

RE: Using ofono HFP

[Zhang, Zhenhua]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Hi Silva, 

	From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of Moises Silva
	Sent: Tuesday, September 28, 2010 10:45 AM
	To: ofono(a)ofono.org
	Subject: Re: Using ofono HFP
	
	
	On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua <zhenhua.zhang@intel.com> wrote:
	

		Right. See bluez/audio/unix.c for BlueZ part SCO code that cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX type socks.
		
		


	Thanks a lot for the additional help. I just setup a quick wiki page to start documenting this: http://ofono.org/wiki/hands-free-profile

	It's small and crappy, but it's a start. I will keep improving it as I go.

[Zhenhua] I have some experience on HFP as I am main contributor of HFP in the oFono. Would you mind me to update your wiki page to add detailed information related with HFP?

Btw, Could you send plain text format mail to the mailing list in the future as it's an formal upstream project. I tried but I cann't reply your mail propertly.

Thanks,
Zhenhua

	Regards,

	-
	Moises Silva

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Mon, Sep 27, 2010 at 11:23 PM, Zhang, Zhenhua
<zhenhua.zhang@intel.com> wrote:
>
> [Zhenhua] I have some experience on HFP as I am main contributor of HFP in the oFono. Would you mind me to update your wiki page to add detailed information related with HFP?
>
> Btw, Could you send plain text format mail to the mailing list in the future as it's an formal upstream project. I tried but I cann't reply
> your mail propertly.

Hello Zhenhua,

By all means, add anything you wish to the wiki page.

I apologize for the HTML, I did not realize my gmail client was setup for HTML.

--
Moises Silva

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua <zhenhua.zhang@intel.com> wrote:
>
> Right. See bluez/audio/unix.c for BlueZ part SCO code that cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX
> type socks.

This put me in the right direction and I have a clearer idea of how to
do it. I found odd though that it seems I need to copy the ipc.c and
ipc.h files into my own app. Any reason they are not part of
libbluetooth API?

Another thing that puzzles me is that supposedly DBUS >= 1.3 is needed
to be able to pass file descriptors. However as you pointed out and
per ipc.c the file descriptor is sent using a unix socket. Why the
need for DBUS file descriptor passing?

I'm gonna start testing right away and most likely will be back with
more questions (like what's the audio format, sampling rate and such)
:-)

Thanks,

--
Moises Silva

RE: Using ofono HFP

[Zhang, Zhenhua]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

Hi Silva,

Moises Silva wrote:
> On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua
> <zhenhua.zhang@intel.com> wrote:
>> 
>> Right. See bluez/audio/unix.c for BlueZ part SCO code that
> cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX
>> type socks.
> 
> This put me in the right direction and I have a clearer idea of how to
> do it. I found odd though that it seems I need to copy the ipc.c and
> ipc.h files into my own app. Any reason they are not part of
> libbluetooth API? 

Marcel may know the answer for your question.

> Another thing that puzzles me is that supposedly DBUS >= 1.3 is needed
> to be able to pass file descriptors. However as you pointed out and
> per ipc.c the file descriptor is sent using a unix socket. Why the
> need for DBUS file descriptor passing?

DBUS file descriptor passing is used in BlueZ/oFono communication, to pass RFCOMM port file handler to another process. I guess dbus 1.3 has some wrapper for such file descriptor passing magic.

Marcel, any comments on Silva's question?

> I'm gonna start testing right away and most likely will be back with
> more questions (like what's the audio format, sampling rate and such)
> :-) 
> 
> Thanks,
> 
> --
> Moises Silva
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

On Tue, Sep 28, 2010 at 10:44 PM, Zhang, Zhenhua
<zhenhua.zhang@intel.com> wrote:
> DBUS file descriptor passing is used in BlueZ/oFono communication, to pass RFCOMM port file handler to another process. I guess
> dbus 1.3 has some wrapper for such file descriptor passing magic.

Oooh, the RFCOMM for the AT commands, of course. I get it now.

--
Moises Silva

Re: Using ofono HFP

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Hi Moises,

On 09/28/2010 09:33 PM, Moises Silva wrote:
> On Mon, Sep 27, 2010 at 9:26 PM, Zhang, Zhenhua <zhenhua.zhang@intel.com> wrote:
>>
>> Right. See bluez/audio/unix.c for BlueZ part SCO code that cooperate with pulseaudio. BlueZ sends SCO fd to pulseaudio via UNIX
>> type socks.
> 
> This put me in the right direction and I have a clearer idea of how to
> do it. I found odd though that it seems I need to copy the ipc.c and
> ipc.h files into my own app. Any reason they are not part of
> libbluetooth API?
> 
> Another thing that puzzles me is that supposedly DBUS >= 1.3 is needed
> to be able to pass file descriptors. However as you pointed out and
> per ipc.c the file descriptor is sent using a unix socket. Why the
> need for DBUS file descriptor passing?
> 

There are two descriptors involved here.  DBus 1.3 is needed to have
BlueZ pass the RFCOMM file descriptor to oFono for the control socket.
E.g. the socket where AT commands are being passed.  This is done by
using HandsfreeGateway and HandsfreeAgent.  See doc/hfp-api.txt in BlueZ.

The second descriptor (what ipc.c and ipc.h deal with) is used to pass
the SCO fd to PulseAudio or gStreamer.  This fd is used for Audio.
Marcel or Johan might know better, but I think the reason for ipc.c and
ipc.h was that DBus did not support fd-passing at the time BlueZ audio
integration work was being done.

Regards,
-Denis

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Tue, Sep 28, 2010 at 10:50 PM, Denis Kenzior <denkenz@gmail.com> wrote:
> The second descriptor (what ipc.c and ipc.h deal with) is used to pass
> the SCO fd to PulseAudio or gStreamer.  This fd is used for Audio.
> Marcel or Johan might know better, but I think the reason for ipc.c and
> ipc.h was that DBus did not support fd-passing at the time BlueZ audio
> integration work was being done.

Thanks for the help.

I have a few more questions. I got my own small app connecting to the
audio server and I am able to read/write fromt he sco socket.

However it seems the MTU is hard-coded int audio/unix.c to 48.

Where does this 48 comes from? I come from the TDM open source world,
where typical configuration for TDM devices is 160 (160 bytes of
alaw/ulaw, 160 samples, each 20ms).

Is there any way to change that socket MTU to 160 or 320 (depending if
it's either SLN16 or alaw/mulaw?

How can I know the format for the audio?

I'll keep digging in pulseaudio to see if I find the answer ...

Moises Silva
Senior Software Engineer
Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON
L3R 9R6 Canada
t. 1 905 474 1990 x128 | e. moy(a)sangoma.com

RE: Using ofono HFP

[Zhang, Zhenhua]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

Hi Silva,

Moises Silva wrote:
> On Tue, Sep 28, 2010 at 10:50 PM, Denis Kenzior
> <denkenz@gmail.com> wrote:
>> The second descriptor (what ipc.c and ipc.h deal with) is used to
>> pass the SCO fd to PulseAudio or gStreamer.  This fd is used for
>> Audio. Marcel or Johan might know better, but I think the reason for
>> ipc.c and ipc.h was that DBus did not support fd-passing at the time
>> BlueZ audio integration work was being done.
> 
> Thanks for the help.
> 
> I have a few more questions. I got my own small app connecting to the
> audio server and I am able to read/write fromt he sco socket.
> 
> However it seems the MTU is hard-coded int audio/unix.c to 48.
> 
> Where does this 48 comes from? I come from the TDM open source world,
> where typical configuration for TDM devices is 160 (160 bytes of
> alaw/ulaw, 160 samples, each 20ms).
> 
> Is there any way to change that socket MTU to 160 or 320 (depending if
> it's either SLN16 or alaw/mulaw?

You might want to raise your question on bluez's IRC or mailing list. oFono takes care of call control logic while BlueZ/PulseAudio takes care of SCO audio packets.

> How can I know the format for the audio?

I think it should be PCM raw data from SCO packets but it could wrong maybe.

> I'll keep digging in pulseaudio to see if I find the answer ...
> 
> Moises Silva
> Senior Software Engineer
> Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON
> L3R 9R6 Canada t. 1 905 474 1990 x128 | e. moy(a)sangoma.com
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Regards,
Zhenhua

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On Thu, Oct 7, 2010 at 11:25 PM, Zhang, Zhenhua <zhenhua.zhang@intel.com> wrote:
>>
>> Where does this 48 comes from? I come from the TDM open source world,
>> where typical configuration for TDM devices is 160 (160 bytes of
>> alaw/ulaw, 160 samples, each 20ms).
>>
>> Is there any way to change that socket MTU to 160 or 320 (depending if
>> it's either SLN16 or alaw/mulaw?
>
> You might want to raise your question on bluez's IRC or mailing list. oFono takes care of call control logic while BlueZ/PulseAudio takes care of SCO audio packets.

I will do that. I just thought somebody around here could know.

>> How can I know the format for the audio?
>
> I think it should be PCM raw data from SCO packets but it could wrong maybe.

Just for the record. I found out the format is SLN16, but the MTU is
fixed and hard-coded in bluez to 48 bytes (that is 24 samples). I
don't know if the format is cell-phone specific or is always SLN16 for
MTU.

Just throwing another question in the air, what should be the best way
to go to use Ofono DBUS API from a C program?

I am trying to write the C version of ./list-modems Python script. I
see in the D-BUS page that they don't recommend using the bare bones
D-BUS C API but rather bindings, like glib bindings. What do you
think? I was trying to use glib for the list-modems C port, but got
stuck on which data type to use for the return value of the GetModems
API.

Thanks,

Moises Silva
Senior Software Engineer
Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON
L3R 9R6 Canada
t. 1 905 474 1990 x128 | e. moy(a)sangoma.com

Re: Using ofono HFP

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

Hi Moises,

2010/10/8 Moises Silva <moises.silva@gmail.com>:
> Just throwing another question in the air, what should be the best way
> to go to use Ofono DBUS API from a C program?
>
> I am trying to write the C version of ./list-modems Python script. I
> see in the D-BUS page that they don't recommend using the bare bones
> D-BUS C API but rather bindings, like glib bindings. What do you
> think? I was trying to use glib for the list-modems C port, but got
> stuck on which data type to use for the return value of the GetModems
> API.

dbus-glib is, err, challenging. Use gdlib if you can.

On the other hand, telepathy-ring has a minimal implementation of
Modem and ModemManager APIs for dbus-glib:

http://meego.gitorious.org/meego-cellular/telepathy-ring

It uses some dbus-glib types from telepathy-glib, but otherwise it is
does not depend on telepathy framework.

-- 
Pekka.Pessi mail at nokia.com

Re: Using ofono HFP

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Thu, Oct 14, 2010 at 8:00 AM, Pekka Pessi <ppessi@gmail.com> wrote:
>
> dbus-glib is, err, challenging. Use gdlib if you can.
>
> On the other hand, telepathy-ring has a minimal implementation of
> Modem and ModemManager APIs for dbus-glib:
>
> http://meego.gitorious.org/meego-cellular/telepathy-ring
>
> It uses some dbus-glib types from telepathy-glib, but otherwise it is
> does not depend on telepathy framework.

Thanks a lot for the information Pekka, I'll give it a try.

-
Moises Silva