Bug#614786: chan_mobile

Ralf Schlatterbeck ralf at zoo.priv.at
Thu Nov 8 14:06:05 UTC 2012


I've just applied the patch mentioned earlier that sets the outgoing
channel number to 0 instead of 1. With this patch, chan_mobile finally
works for me.

An explanation what this patch does:

Newer kernels (since 1.6.7 or so, early enough for current debian
kernels to include the feature) allow to bind to a local bluetooth
channel by specifying 0 which makes the kernel take the first free
channel.

This is similar to binding to a local port number for IP-based protocols
(e.g. UDP or TCP) and specifying 0 as the port number, the kernel will
chose the next free port.

The current asterisk version uses the hard-coded channel number 1 for
the local channel of the bluetooth connection to the mobile phone. This
fails when some other bluetooth application is already using that port.
Apparently -- as shipped -- debian bluez already runs some other
application on that port.

This is definitely a bug in chan_mobile. A workaround -- as somebody
else has suggested -- is to not start any bluetooth services and thus
keep this port free. But this means that chan_bluetooth would not work
for 90% of debian users.

So *please* go ahead and apply this bug before squeeze ships, otherwise
we'll have to live for a whole debian release to get a working
chan_mobile.

Thanks
Ralf
-- 
Ralf Schlatterbeck             email: ralf at zoo.priv.at



More information about the Pkg-voip-maintainers mailing list