Summary:	ASTERISK-03071: Polycom IP300/500 stop ringing when "180 Ringing" is sent
Reporter:	Kevin P. Fleming (kpfleming)	Labels:
Date Opened:	2004-12-22 15:05:15.000-0600	Date Closed:	2008-01-15 15:19:56.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) polycom_progress_example_rev1.diff.txt
Description:	On my Polycom IP300/500 phones (running firmware 1.3.1 or 1.3.4), and call certain PSTN numbers, the ringback to the user stops after one or two rings. The call does proceed to completion, though. Debugging has proved that the cases that work (where ringback does not stop) include a "183 Session Progress" message being sent to the phone, but nothing else until it is answered. This works fine. In the cases that fail, _after_ the "183 Session Progress" is sent, a "180 Ringing" message is also sent. Presumably this is because the Asterisk/Zaptel callprogress detection has kicked in, and has noticed that there is ringing coming back from the far end. However, on the Polycom phones, when "180 Ringing" is received, the audio stream is stopped and the ringing is no longer heard. This problem does not exhibit itself on a Cisco 7940/7960, or a Grandstream BT100. After some chatting with oej, I have found what I believe is the source of the problem: in chan_sip, at approximately line 1893, the code decides whether to send "180 Ringing" or not. It will only send it if "183 Session Progress" has _not_ been sent, or if "progressinband" is set to anything but "never". The cause of my problem is that "progressinband" defaults to "never" (even though the sample sip.conf file implies it defaults to "no"). Changing it to "no" globally for my SIP users cures this problem. I don't know if the proper fix is to just change the default, or if the logic here is actually broken; it seems that the latter is more likely. Instead of checking for !p->progressinband, I suspect the proper check is for p->progressinband != 2, since both 0 and 1 mean not to send inband progress.
Comments:	By: Clod Patry (junky) 2004-12-22 21:41:45.000-0600 I've an IP500 here, i'll make some tests related to this problem during my break week, next week. By: Clod Patry (junky) 2004-12-30 20:58:13.000-0600 from my IP500, im calling on PSTN and there's no trouble for me. Ringing continues until my voicemail is starting (my cell phone). What do you've in your settings exactly? By: Kevin P. Fleming (kpfleming) 2004-12-31 09:28:14.000-0600 The problem is hard to duplicate, because it depends on the route through the PSTN that the call takes. If the call goes out via ISDN PRI, and receives "PROCEEDING" from the network, then the phone gets "183 Session Progress", and the reverse-audio path is set up. If the end-switch for the call then generates ringback audio, the Asterisk DSP recognizes it, and turns it into "180 Ringing" to send to the phone. On the Polycom phones, this causes the reverse-audio path to be closed, until the call is answered. It's probably a firmware bug in the phones, but... There is no reason for Asterisk to send "180 Ringing" after "183 Session Progress" that included SDP for reverse audio. I believe this is a bug in Asterisk, and should be corrected. Now that my chan_sip flags conversion patch has been merged, it would be easy to change (one flag test on one line). The problem is, I don't know who did all the "progress in band" stuff in chan_sip, so I can't ask them if there's a good reason why it works the way it does now, or if it's accidental. By: Mark Spencer (markster) 2004-12-31 10:43:11.000-0600 Originally asterisk did not send 180 after 183, however if you say you won't send 180 after 183, that forces you to create in-band audio which can consume transcoders which would otherwise be unnecessary.  To work around this we created an option in chan_sip.c we allowed "progressinband" to be overloaded to say either "no", "never" or "yes" send the ringing as in-band.  The correct default should be "never" since it uses the lease resources, and I couldn't find any reference in the documentation that said the default was "no" other than the commented out example in sip.conf, which i've changed to say "never".  If there is another place, feel free to reopen. By: Kevin P. Fleming (kpfleming) 2004-12-31 11:25:00.000-0600 I'm reopening, but not for the documentation reason... sip.conf.sample was the only place that had the default listed incorrectly. The problem as I see it is this: Asterisk sends out-of-band "180 Ringing" whenever progressinband is "never", but not "no" or "yes". However, even if progressinband is "never", the "183 Session Progress" that occurred previously included SDP and has set up an audio path (including transcoding resources). The progressinband value is _never_ checked when "183 Session Progress" is about to be sent, it _always_ includes SDP and sets up an audio path. In other words, I suspect the whole point of the progressinband value was to do exactly as you describe, but it has not been implemented that way. So, let's start this discussion over: can someone describe to me what the difference between progressinband "never" and "no" are supposed to be? The way I see it, progressinband should have only two values, "no" and "yes." Their effects should be the following: If "no", "183 Session Progress" with SDP should _not_ be sent to the peer, as that _is_ "progress in band". That keeps the audio path from being set up, and does not consume transcoding resources. Also, if "no", and AST_CONTROL_RINGING is sent, then we send "180 Ringing" to the peer, so it can generate ringback locally if it chooses to do so. If "yes", then we should always send "183 Session Progress" with SDP, setting up the audio path, and _never_ send "180 Ringing". Then if we receive AST_CONTROL_RINGING from the core (because the DSP has detected it), then let the core send simulated ringback (in other words, "progress in band"). This sounds like it would do exactly what you suggested, except that you implied that there was a way to send "183 Session Progress" _without_ consuming audio resources; there is not any way to do that in Asterisk right now. Every single time "183 Session Progress" is sent, it is sent with SDP, and an RTP audio path is set up. If what you want is a way to send "183 Session Progress" _without_ SDP (and thus without RTP), then that needs to be implemented, because it's not there right now. By: Clod Patry (junky) 2004-12-31 12:35:21.000-0600 I can't help at this point, cause i don't know the answer. I'll wait with you for some answers of someone. By: twisted (twisted) 2005-01-01 17:19:13.000-0600 This appears to be a problem with the way the flags are set.  I'm not sure exactly how this is wrong though, but it doesn't make any sense to me.  Look at lines 8421 thru 8427 in channels/chan_sip.c to see what I mean. By: Mark Spencer (markster) 2005-01-01 18:14:18.000-0600 This is still a symantics issue, to clarify, these settings relate specifically to ringing, not progress in general, so to clearify: progressinband=yes When "RING" event is requested, always send 180 Ringing (if it hasn't been sent yet) followed by 183 and in-band audio progressinband=no Send "180 Ringing" if 183 has not yet been sent establishing audio path.  If audio path *is* established already (with 183) then send in-band ringing (this is the way asterisk historically behaved because of buggy phones like polycom) progressinband=never Whenever ringing occurs, send "180 ringing" as long as "200 OK" has not yet been sent. By: Kevin P. Fleming (kpfleming) 2005-01-03 16:07:31.000-0600 Patch uploaded to add Polycom example to sip.conf.sample, to document that Polycom phones don't work correctly with progressinband=never. (No disclaimer needed, it's not code). By: Mark Spencer (markster) 2005-01-03 23:08:32.000-0600 Added to CVS head. By: Russell Bryant (russell) 2005-01-04 23:54:16.000-0600 added to 1.0 By: Digium Subversion (svnbot) 2008-01-15 15:19:13.000-0600 Repository: asterisk Revision: 4622 U   trunk/configs/sip.conf.sample ------------------------------------------------------------------------ r4622 | markster | 2008-01-15 15:19:12 -0600 (Tue, 15 Jan 2008) | 2 lines Fix example to reflect that "never" is the default value for progressinband (bug ASTERISK-3071) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4622 By: Digium Subversion (svnbot) 2008-01-15 15:19:39.000-0600 Repository: asterisk Revision: 4651 U   trunk/configs/sip.conf.sample ------------------------------------------------------------------------ r4651 | markster | 2008-01-15 15:19:38 -0600 (Tue, 15 Jan 2008) | 2 lines Document polycom example (bug ASTERISK-3071) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4651 By: Digium Subversion (svnbot) 2008-01-15 15:19:56.000-0600 Repository: asterisk Revision: 4671 U   branches/v1-0/configs/sip.conf.sample ------------------------------------------------------------------------ r4671 | russell | 2008-01-15 15:19:55 -0600 (Tue, 15 Jan 2008) | 2 lines document a problem with polycom phones (bug ASTERISK-3071) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4671