[Home]

Summary:ASTERISK-04150: Outbound calls to cell phones or other switches which do not immediately know the state of the called station hang indefinitely
Reporter:clint (clint)Labels:
Date Opened:2005-05-12 14:32:28Date Closed:2005-06-19 11:38:53
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) FailedToHangup.txt
Description:When dialing out to a switch which does not immediately know the status of the called station, such as a cell phone switch which must wait a few seconds to determine whether the subscriber terminal can be reached, the switch may return a PROGRESS message with a cause (7) User Busy AFTER the ALERTING message.  In this case, no HANGUP message will be received, leading asterisk to believe that the call is still ringing forever.

Asterisk needs to receive a hangup when libpri reads a PROGRESS message with a type (7) User Busy component.

****** ADDITIONAL INFORMATION ******

In order to duplicate this issue, you will need a cell phone WITHOUT voicemail.  Phones from Cingular, Verzion and Suncom have been tested.  Call the phone from asterisk, and on the first ring, hit the end key to decline the call.  This is a shortcut to force the switch to delay returning a user busy response.  The same behavior can be seen 'in the wild,' but it will not occur all the time.  Letting the phone ring once simulates the exact same behavior on the D channel as is observed in situ when the switch just takes a second or two to recognize that a handset is out of range or busy.

Attached, you will find pri debug span of the issue occurring.  At the end of this trace, the call is still up, passing early audio from the switch, and asterisk believes that the call is still ringing.  The remote switch has already torn down the trunk between the local provider's switch and itself, and the local provider's switch is generating a reorder tone on the talk path.  One would expect a HANGUP message to follow, however both Telcove and Bellsouth have confirmed that this behavior is normal according to Lucent for the 5ess in National mode in the case of a busy being returned after early audio is available.

Asterisk needs (I think) to recognize this as equivalent to a hangup.  I will shortly attach a patch to accomplish this, however I want to ensure that patching this is "The Right Thing (tm)."  I suspect that there may be some discussion as to whether this trace shows a violation of Q.931, and I'd rather not introduce new brokenness.
Comments:By: klaus3000 (klaus3000) 2005-05-23 13:01:58

This problem sounds similar to my problem. Check bug ASTERISK-4244 for details.
By: Michael Jerris (mikej) 2005-06-19 11:38:53

This does appear to be a duplicate of 4347.  If it is not, Please re-open.