Summary:	ASTERISK-09729: Ringback stops after 183 Session Progress is received from a SIP UA that is part of a multi UA Dial attempt
Reporter:	Eric Davis (ericwaynedavis)	Labels:
Date Opened:	2007-06-21 13:36:52	Date Closed:	2011-06-07 14:07:51
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) packet-trace-sip-debug.zip
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. ****** ADDITIONAL INFORMATION ****** extensions.conf --------------- [default] exten => 5446,1,Macro(stdexten,${EXTEN},SIP/4.79.212.236/+14041234567&sip/5446-pcom601-line1&sip/5446-spa941-line1) [macro-stdexten]; ; ; Standard extension macro: ;   ${ARG1} - Extension  (we could have used ${MACRO_EXTEN} here as well ;   ${ARG2} - Device(s) to ring ; exten => s,1,NoOp(${CALLERID(num)}) exten => s,n,NoOp(${CALLERID(name)}) exten => s,n,Dial(${ARG2},20)                   ; Ring the interface, 20 seconds maximum exten => s,n,Goto(s-${DIALSTATUS},1)            ; Jump based on status (NOANSWER,BUSY,CHANUNAVAIL,CONGESTION,ANSWER) exten => s-NOANSWER,1,Voicemail(${ARG1},u)      ; If unavailable, send to voicemail w/ unavail announce ;exten => s-NOANSWER,2,Goto(default,s,1)        ; If they press #, return to start exten => s-BUSY,1,Voicemail(${ARG1},b)          ; If busy, send to voicemail w/ busy announce ;exten => s-BUSY,2,Goto(default,s,1)            ; If they press #, return to start exten => _s-.,1,Goto(s-NOANSWER,1)              ; Treat anything else as no answer exten => a,1,VoicemailMain(${ARG1})             ; If they press *, send the user into VoicemailMain
Comments:	By: Joshua C. Colp (jcolp) 2007-06-29 11:57:53 I tried many different ways to reproduce this but was unable to... so here it goes - can you please add debug to the console section in logger.conf, do a logger reload, and set debug 9 and attach the output to this bug? Thanks. By: andykwg (andykwg) 2007-07-30 13:42:37 I may have the similar issue. I wonder, in addition to 'r' option for Dial() that ringback until 180/183, say there is a 'R' option, which will force the ringback on the call until 200 OK, then the calls will progress as it should, right? By: Joshua C. Colp (jcolp) 2007-08-07 10:33:47 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.