[asterisk-bugs] [Asterisk 0016338]: chan_mobile doesn't hangup

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16338 
====================================================================== 
Reported By:                pj
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   16338
Category:                   Addons/chan_mobile
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 231401 
Request Review:              
====================================================================== 
Date Submitted:             2009-11-27 17:50 CST
Last Modified:              2009-12-03 09:45 CST
====================================================================== 
Summary:                    chan_mobile doesn't hangup
Description: 
chan_mobile doesn't hangup call, when it receives audio from mobile device.
It can be progress audio message from gsm network (eg. ringback) or audio
from answered call. Phone is also disconnected from chan_mobile in this
case.

When call setup is terminated before any incomming audio is received from
gsm network by chan_mobile, mobile channel is successfully terminated and
phone is not disconnected from chan_mobile.


====================================================================== 

---------------------------------------------------------------------- 
 (0114658) mnicholson (administrator) - 2009-12-03 09:45
 https://issues.asterisk.org/view.php?id=16338#c114658 
---------------------------------------------------------------------- 
Ok, so there are some differences I noticed in my trace vs your trace.  In
my trace, the protocol for the RFCOMM messages is listed as RFCOMM, but in
your trace it is listed as L2CAP.  I know that RFCOMM is built on top of
L2CAP, so I am not sure if this difference is significant.  Beyond that,
the disconnection sequence looks normal as far as I can tell.  I don't see
anything related to a read error and I am not sure if that would even be in
this trace.  The bluetooth connection is not terminated until after we
request a disconnect.

Something that might be useful is modifying chan_mobile to continue after
it receives that read error and see what happens.  I'll work on a patch to
do that. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-03 09:45 mnicholson     Note Added: 0114658                          
======================================================================