Summary:	ASTERISK-02803: [patch] it allows to send the response 180 Ringing even if has been already sended '183 Progress Response'
Reporter:	cybershield (cybershield)	Labels:
Date Opened:	2004-11-13 06:05:27.000-0600	Date Closed:	2004-11-14 21:33:06.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip.diff
Description:	It allows to send to peer/user a response '180 Ringing' when ringing a called number.   Add an option 'ringingresponse' into global/peer/user sip.conf to send the response '180 Ringing' only to who are interested of such message.
Comments:	By: Olle Johansson (oej) 2004-11-13 09:10:29.000-0600 Why shouldn't we send a 180 ringing? Also, you forgot to mention if this patch is disclaimed. Please read the bug tracker instructions that you were notified of while opening this report! By: Mark Spencer (markster) 2004-11-13 10:33:55.000-0600 Once you send 183, most devices will not create in-band audio for a 180 ringing.  I do not think this patch is a good idea. By: cybershield (cybershield) 2004-11-13 12:35:09.000-0600 I have added the option 'ringingrequest' in the section users and peers just to send the response '180 ringing' only to those devices that they have need of such message (i have created this patch just for experiences of necessity of such message). If the option 'ringingrequest' is not set to yes, it does not come altered the actual protocol SIP. 'Ringingrequest' is a global param, users param and peers param. By: khb (khb) 2004-11-13 14:03:00.000-0600 This seems very bogus. By: Brian West (bkw918) 2004-11-13 14:16:24.000-0600 how about a "braindeadsip = yes" option :P bkw By: Olle Johansson (oej) 2004-11-13 15:13:29.000-0600 Cybershield: I still would like to know what broken devices that can't handle a 1xx message from us. That would be highly irregular. By: cybershield (cybershield) 2004-11-14 03:43:20.000-0600 WHAT ?!? But you never send to calling '180 Ringing' !!! When the app_dial call the function 'sip_indicate' with (condition==AST_CONTROL_RINGING) does not come sended response '180 Ringing' because has been already forwarded response '183 Session Progress'. RFC says not to send message '180 Ringing' if has been already sended message '183 Session Progress' ?   If yes, ok I have mistaken...but otherwise why not to allow to forward this message ? By: Olle Johansson (oej) 2004-11-14 09:46:00.000-0600 Of course we send 180 ringing to the caller. I must be misunderstanding you completely, since I can't make sense of what you are saying. I am not using English natively, so please bear with me and explain your problem again in detail. Also, please refer to a section of the RFC where it says that we cannot send an 180 Ringing... Please find me on IRC to discuss this. I am "oej" By: Mark Spencer (markster) 2004-11-14 10:13:15.000-0600 Okay, take a look at latest CVS, cyber.  I went ahead and recycled the "progressinband" so we didn't have to add 'yet another sip config option' so now you can just say progressinband=never to accomplish what you'd like :)  Please try it out and let me know. By: khb (khb) 2004-11-14 11:52:20.000-0600 I think he is asking if it is RFC behavior not to send 180 Ringing when 183 Session progress has already been sent. And that's usually the interpretation. 180 is sent if a local ring-back with custom ring tones is desired for which there should be an Alert-info header as well. Asterisk SIP sends 180 Ringing when it gets a ring indication from the PBX (zap or phone channel), in which case it doesn't send 183. I think it should only send it when there is one-way in-band early (ringing) media, which has already been stated here. The 183 response was added to SIP to indicate session progression to the calling UA when no local alerting should occur. So 183 and 180 at the same time seem contradictory.  Unless perhaps there is more detailed info conveyed in 183, which is possible, but why send a 180 then? The subject of session progress and state and alerting can become complex if one or more PSTN gateways are involved and we should only implement standard accepted behavior.  Just sending a 180 Ringing whenever a user wishes via a configuration parameter makes things only more confusing.  Asterisk is used by a lot of service providers, so there needs to be more strict quality control on our protocol behavior. I think the way Asterisk is doing this right now is at least close to the accepted behavior for simple configurations.  Asterisk is not a proxy so it is questionable whether it should pass on even a received 180-ringing from another  gateway. By: cybershield (cybershield) 2004-11-14 12:04:31.000-0600 Sorry for my bad english. Ok, mark. Work Please check if is correct the default value of 'progressinband'. Now default value of 'progressinband' is 'never', in chan_sip the global_progressinband is initialize to 0 (0 -> never). By: Mark Spencer (markster) 2004-11-14 19:37:48.000-0600 Yah, believe it or not I think the never sounds like a good place to start.  We'll just hope it doesn't break anybody :)