Summary:	ASTERISK-06707: SIP 100 Trying not being sent on 404 error
Reporter:	Steven Ringwald (sringwald)	Labels:
Date Opened:	2006-04-05 12:49:18	Date Closed:	2011-06-07 14:03:07
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Level3 sends us a call, to a number not in our dialplan. There spec says that there should be a SIP 100 "Trying" before the SIP 404 "Not Found" is sent out. They require this on all their connections, even the ones that error.
Comments:	By: Olle Johansson (oej) 2006-04-05 12:51:50 So where is the bug in Asterisk? By: Olle Johansson (oej) 2006-04-05 13:07:08 The SIP RFC clearly states that if we know the answer, we should not send 100 Trying, but send the answer directly. By: Joshua C. Colp (jcolp) 2006-04-05 13:41:29 Sorry but I'm with oej on this, we bend the rules enough as it is for compatibility but if it's clearly stated in the RFC that's just silly. By: Steven Ringwald (sringwald) 2006-04-06 09:34:00 Level3 claims that they have several asterisk-based customers currently using their proxies who are able to do this. Is there some workaround or patch that I could put into place for my systems that would do this? By: Olle Johansson (oej) 2006-04-06 09:36:24 Well, do they want to change their rules to be able to follow the standard RFC? By: Steven Ringwald (sringwald) 2006-04-06 10:18:23 Here is they have said: <quote> True, the RFC indicates this.  We are arguing the RFC in this case. Level3 has standardized on the use of the 100 Trying as a receipt of the Invite especially when using UDP.  Thus we require it.  We have many other customers using Asterisk to have been able to use 100 Trying in this case.  Will you be able to add it? </quote> By: Olle Johansson (oej) 2006-04-06 10:52:16 It's a rather simple fix, but I don't like adding non-RFC support in chan_sip just for one provider or one piece of equipment. By: Russell Bryant (russell) 2006-04-06 11:01:45 That is absolutely ridiculous.  "We are arguing the RFC in this case."  Are you serious?!  There is absolutely no reason we should introduce obviously contrary to RFC behavior because a specific provider decided that's the way it should be. By: Steven Ringwald (sringwald) 2006-04-06 11:13:28 Yes, they are quite serious, and are holding up some DIDs that we wish to deploy because of it. I agree that making the change for a single provider is completely ridiculous, but they have something we need *right now*. I figured out the change and made it to ours. In the meantime, I will keep trying to get them to follow the RFC. Thanks for your help y'all!