[asterisk-bugs] [Asterisk 0010032]: Ringback stops after 183 Session Progress is received from a SIP UA that is part of a multi UA Dial attempt

noreply at bugs.digium.com noreply at bugs.digium.com
Tue Aug 7 10:33:47 CDT 2007


The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10032 
====================================================================== 
Reported By:                ericwaynedavis
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10032
Category:                   Core/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.5 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             06-21-2007 13:36 CDT
Last Modified:              08-07-2007 10:33 CDT
====================================================================== 
Summary:                    Ringback stops after 183 Session Progress is
received from a SIP UA that is part of a multi UA Dial attempt
Description: 
My objective is to have the user's SIP phone and their cell phone ring
simultaneously when a call to their SIP phone extension is received.

I have a SIP server running FC6 (2.6.19-1.2911.fc6) that has a number of
registered SIP phones (Polycom, SPA-941, X-lite, etc). I am using
Bandwidth.com (aka Level3) for SIP trunking to the PSTN. This service
provider always sends 183 Session Progress messages in place of 180 Ringing
when I make outbound calls.

I have my dialplan configured so that when I receive a call from the PSTN
to one of our numbers, I simultaneously ring the user's SIP phone and the
user's cell phone. In order to ring the cell phone, I have to use a SIP
connection back to the service provider. The caller hears one ring and then
silence until either one of the SIP UAs or the cell-phone answers, or the
call is connected to voice mail on the PBX.

Using Wireshark (trace attached) to look at what is happening, I see that
the RTP stream containing the ringback tone stops when the service provider
sends a 183 Session Progress message. The RTP ringback stream starts at
11.788 secs and lasts for 4.960 secs, which is when the 183 message is
received at 16.759 secs.

According to ietf-sip-183
(http://tools.ietf.org/id/draft-ietf-sip-183-00.txt)  "There are instances,
most notably dealing with SIP to PSTN interwork-
   ing, that necessitate that the SIP called User Agent (UA) be able to
   suppress local alerting by the SIP calling UA and to set up a prelim-
   inary media session from the called UA to the calling UA.  This would
   allow the called UA to play back media prior to the full SIP session
   being set up.  This media would be used to report on the status of
   the session setup request. "

Through inspection of the packet trace, this seems to be exactly what is
taking place. The RTP media stream that starts at t=16.873 contains
ringback tone from the service provider's media gateway. The implementation
seems correct.

The problem is that my dial statement is ringing multiple phones and the
ringback tone to the caller is being terminated before anyone actually
answers the call. My understanding is that the intent of the ietf-183-draft
is to provide inband signaling of call progress from the PSTN to a SIP
caller. Any intermediary SIP proxy should pass the 183 session progress
message downstream to the SIP UA that originated the call as well as the
RTP ringback audio stream. In the simple case where a SIP UA dials out to
the PSTN via my Asterisk PBX and the service provider, this is what occurs
and the ringback tone is heard as expected. 

However, in this problem case, the caller of interest is my Asterisk PBX.
The call to the service provider is a result of the Dial command shown here
which is ringing multiple SIP UAs. And this Dial command is called in
response to a call from the PSTN through this same service provider. It
would be improper to forward the 183 session progress message back to the
caller (the service provider on the initial channel), since the 183 message
represents the call progress of only one of several possible channels to
which this call might be connected.

In this case, it seems like the correct behavior should be for the
Asterisk PBX to maintain the ringback RTP audio stream on the initial
channel until it gets a  200 OK from any of the channels, a failure
indication on all of the channels, or a timeout occurs.

I hope I am not being too presumptuous. I researched this quite a bit
before opening a report. Despite this fact, it's quite possible I have no
idea what I'm talking about. Alternately, there might be an acceptable
alternative method to accomplish what I am trying to do here. Any
suggestions to that end, would be most appreciated.


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

---------------------------------------------------------------------- 
 file - 08-07-07 10:33  
---------------------------------------------------------------------- 
Due to lack of feedback I'm suspending this bug. If it is still an issue
and you can provide the needed info feel free to reopen.

andykwg: We don't accept feature requests on the bug tracker. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-07-07 10:33  file           Status                   feedback => resolved
08-07-07 10:33  file           Resolution               open => suspended   
08-07-07 10:33  file           Assigned To               => file            
08-07-07 10:33  file           Note Added: 0068541                          
======================================================================




More information about the asterisk-bugs mailing list