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