[asterisk-bugs] [Asterisk 0011556]: "No audio" on incoming bluetooth call to voicemail, call dropped
noreply at bugs.digium.com
noreply at bugs.digium.com
Thu Jun 26 04:11:39 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=11556
======================================================================
Reported By: non-poster
Assigned To: dbowerman
======================================================================
Project: Asterisk
Issue ID: 11556
Category: Addons/chan_mobile
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): 1.4
SVN Revision (number only!): 92526
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 12-14-2007 14:55 CST
Last Modified: 06-26-2008 04:11 CDT
======================================================================
Summary: "No audio" on incoming bluetooth call to voicemail,
call dropped
Description:
I have "context=incoming-mobile" in mobile.conf for my bluetooth phone. It
connects, and Asterisk indicates that "Usable" for voice = "Yes", "Type" =
"Phone".
The incoming-mobile context directs the call to voicemail:
context incoming-mobile {
_. => {
VoiceMail(9999,b);
Hangup();
};
}
When I call the bluetooth phone, I hear the outgoing voicemail message
"...9999 is busy... leave message...beep", then the call is dropped. The
logs contain:
channel.c:2992 in set_format: Set channel Mobile/SCP2500-f304 to write
format slin
-- Recording the message
app.c:603 in __ast_play_and_record: Recording Formats: sfmts=sln
rtp.c:1089 in ast_rtcp_read: Got RTCP report of 104 bytes
app.c:657 in __ast_play_and_record: One waitfor failed, trying another
app.c:661 in __ast_play_and_record: No audio available on
Mobile/SCP2500-f304??
channel.c:1465 in ast_hangup: Hanging up channel 'Mobile/SCP2500-f304'
chan_mobile.c:667 in mbl_hangup: Hanging up device SCP2500.
The chan_mobile messages:
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [+CIEV:
3,1]
chan_mobile.c:1418 in do_monitor_phone: Device SCP2500 [+CIEV: 3,1]
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [RING]
chan_mobile.c:1418 in do_monitor_phone: Device SCP2500 [RING]
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [+CLIP:
"206xxxyyyy",129]
chan_mobile.c:1002 in rfcomm_write: rfcomm_write() (SCP2500) [ATA ]
chan_mobile.c:869 in mbl_devicestate: Checking device state for device
SCP2500
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [OK]
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [+CIEV:
2,1]
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [+CIEV:
3,0]
chan_mobile.c:1831 in do_sco_listen: accept()ed socket.
chan_mobile.c:1836 in do_sco_listen: Incoming Audio Connection from device
00:00:A0:2E:XX:XX MTU is 64
chan_mobile.c:1828 in do_sco_listen: About to accept() socket.
chan_mobile.c:943 in do_alignment_detection: Alignment Detection result is
[0 0 0 0]
chan_mobile.c:667 in mbl_hangup: Hanging up device SCP2500.
chan_mobile.c:1002 in rfcomm_write: rfcomm_write() (SCP2500) [AT+CHUP ]
chan_mobile.c:869 in mbl_devicestate: Checking device state for device
SCP2500
chan_mobile.c:869 in mbl_devicestate: Checking device state for device
SCP2500
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [OK]
chan_mobile.c:1326 in do_monitor_phone: rfcomm_read() (SCP2500) [+CIEV:
2,0]
chan_mobile.c:1418 in do_monitor_phone: Device SCP2500 [+CIEV: 2,0]
======================================================================
----------------------------------------------------------------------
horbra - 06-26-08 04:11
----------------------------------------------------------------------
I am having the same issue here (using trunk version of chan_mobile
(revision 600), backported to asterisk 1.4.21, on a MIPS-based routerbox
using OpenWRT, bluez-libs/utils 3.32, kernel 2.6.22 with all bluetooth-mods
backported from 2.6.25.4, (but could also reproduce the issue on x86
(2.6.25-kernel with bluez 3.24), and earlier versions of kernel mods
(2.6.22) and bluz-libs (2.something and 3.24) on MIPS).
I did a little debugging myself, and noticed the following issues:
- in my backported version, I in the beginning had no audio at all any
more, whereas an older patched version (rev 451) still had "one-way" audio
as described in this report. I figured when in sco_read() switching back to
using recv() instead of read() on the sco_socket, it worked again one-way
- in sco_read(), whenever an non-blocking recv() (see previous bullet) was
performed the return value was -1 and errno was 11 (EAGAIN), I _never_ got
any successful recv from the socket. It that context it seemed even more
strange that switching from recv() to read() would kill the audio
completely (also from the send-side)... Could it be that for some reason
the socket is only established one-way? I am only beginning to look into
how this should work on the bluez-side
- I am new to asterisk and bluez, did some reading on the API docs, but
cannot say that I have fully grasped all concepts yet. Yet it occurred to
me that mbl_read() (which seems to be registered as the read-method for the
mobile asterisk channel), seemed never to be called at all, I never saw any
debug message from that routine in the logs, whereas mbl_write() is called
frequently. Maybe I overlooked some signaling mechanism that would indicate
to asterisk that no useful data was available due to the failing sco_reads
(which seem to be actually called by mbl_write(), piping data to the
mbl_read(), yet another thing I did not fully grasp)...? Also it could be
that asterisk maybe does not really use that function at all, as said,
haven't figured it all out yet. ;-)
- As the issue seemed somewhat hardware-dependent: I tested several
BT-sticks with different chipsets. CSR and ISSR -chipsets worked as
described (ISSR being somewhat unstable), an Anycom-200
(Broadcom-chipset-based) had no audio at all no matter what. I was only
able to test SonyEricsson phones (K600i, W850i, T610), will try to get
hands on some other brand.
- I used echo testing and forwarding the call via misdn, both having the
same issue (no audio can be heard on the called side)
- As mentioned I used an earlier semi-officially backport-patch from the
web, based on trunk revision 451, then switched to 600 which I backported
myself (basically removing the new cli-stuff and changing some log messages
and name changes), but keeping most of the other fixes since 451) . The
451-version had the same problem.
Hope this helps...
Issue History
Date Modified Username Field Change
======================================================================
06-26-08 04:11 horbra Note Added: 0089268
======================================================================
More information about the asterisk-bugs
mailing list