Summary:	ASTERISK-03730: SIP INVITE Fail (407) after upgrading from 1.0.0 to 1.0.7
Reporter:	uvik (uvik)	Labels:
Date Opened:	2005-03-21 14:14:25.000-0600	Date Closed:	2005-04-01 00:26:19.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) session.log ( 1) session5.log ( 2) session6.log ( 3) sip_ignore_fix_rev1.diff.txt ( 4) sip_ignore_fix-1.0_rev1.diff.txt
Description:	The SIP client was working well with version 1.0.0 : REGISTER and INVITE With version 1.0.7 (even 1.0.3) the same client won't work any more on INVITE ( it REGISTER well ). It seems that the "nonce" is not synchronized between * and the client.
Comments:	By: Olle Johansson (oej) 2005-03-21 14:39:28.000-0600 Which version are you running? Stable 1.0.7 or CVS head??? By: Mark Spencer (markster) 2005-03-21 14:41:47.000-0600 This is a configuration issue.  Please see a bug marshall in #asterisk before reopening and also we will not be able to service this bug if it is marked private. By: Olle Johansson (oej) 2005-03-21 14:42:58.000-0600 This is a configuration issue, your codecs are not compatible. Please upload your configuration file - sip.conf By: uvik (uvik) 2005-03-21 15:27:08.000-0600 add sip.conf By: Olle Johansson (oej) 2005-03-21 15:44:14.000-0600 THe user you are calling to only allows g729 as a codec. Check if you have a license installed after the upgrade. This is a configuration issue, not a bug in the bug tracker. By: Olle Johansson (oej) 2005-03-21 15:44:45.000-0600 ---Find someone in #asterisk or #asterisk-bugs on the IRC to sort this out. By: uvik (uvik) 2005-03-21 17:02:01.000-0600 removing all the "disallow=" and "allow=" forcing ulaw on the two UA the result is the same : 407 Proxy authentication required it seems that it as nothing to do with codec does it depend on the fact the UA are about 700ms off the * server ? influencing the sync of the authentication challenge ! but it works with 1.0.0 in the same conditions By: Mark Spencer (markster) 2005-03-21 20:13:02.000-0600 407 is the proxy authentication response and is normal.  As I said before, do NOT reopen this bug until you have discussed your problem with a bug marshall.  Everything so far points to this being a configuration issue.  Alternatively you can receive technical support by purchasing it from Digium or someone else who can walk you through your needs. By: Kevin P. Fleming (kpfleming) 2005-03-22 11:54:24.000-0600 He has been discussing this with me, and a full trace is on the way so we can figure out what is happening. Given that we are getting other reports of SIP incompatibility with 1.0.7 suddenly, this is worth tracking down. (I'm also removing his sip.conf so the bug can be made public). By: uvik (uvik) 2005-03-22 12:22:54.000-0600 adding session5.log (with verbose 255 and debug 255) of a non working INVITE with 1.0.7 By: uvik (uvik) 2005-03-22 12:31:08.000-0600 adding session6.log (verbose 255 debug 255) of a successfull INVITE with version 1.0.0 Same config , same clients than the non-working session5.log (1.0.7) By: Kevin P. Fleming (kpfleming) 2005-03-22 12:49:47.000-0600 OK, this clearly has something to do with the move of process_sdp after check_auth in handle_request, since the session5.log doesn't show the SDP processing happening at all, which results in '488 Not Acceptable Here' after check_auth has been completed. I will take a closer look to see what is going on. By: Kevin P. Fleming (kpfleming) 2005-03-22 14:02:51.000-0600 OK, I think I know what is going on here. It does appear to be a bug in the peer. 1) Peer sends INVITE with CSeq 61 with auth information included, but with the nonce that Asterisk supplied in it's 407 response to CSeq 60. 2) Asterisk receives it and replies with '407 Proxy Authentication Required', because the authentication fails (since the nonce is wrong). 3) The peer re-sends the INVITE with proper authentication information, but using the same CSeq number, which is not correct behavior. 4) Asterisk receives the second INVITE, notes that it is a duplicate (see the line 'Ignoring this request'), but instead of truly ignoring it, it sends '488 Not Acceptable Here' (for the cause of this, see below). 5) The peer sends the INVITE again, using a new CSeq, with the proper authentication information, but Asterisk destroyed the call information after step 4, so the authentication fails, and the cycle starts over. Now, there are two issues here: A) Asterisk is sending '488 Not Acceptable Here' instead of '503 Unavailable', because when the first INVITE was processed the SDP portion was _not_ processed, so Asterisk assumes that the reason this particular INVITE failed was because of codec mismatch. B) Asterisk is marking the private structure to be destroyed, even though the INVITE request is being ignored. As best I can tell, the entire block of chan_sip.c from lines 7419 through 7434 should be inside an 'if (!ignore) {' block, as I don't see why we should be sending any response to a request we are ignoring, nor should the private structure be destroyed because of a request we are ignoring. I haven't followed the CVS history far enough back to find out when started sending '503 Unavailable' for requests it is ignoring, but obviously it started happening after 1.0 was released. edited on: 03-22-05 14:48 By: Olle Johansson (oej) 2005-03-22 14:32:30.000-0600 See my note in ASTERISK-3727 about how to handle retransmissions. Possibly we should merge these two bug reports. By: Kevin P. Fleming (kpfleming) 2005-03-22 14:44:27.000-0600 Some basic testing shows that this change does indeed solve the problem, so here are two small patches (one for HEAD and one for 1-0) to actually properly ignore repeated INVITES. Disclaimer is on file. By: Kevin P. Fleming (kpfleming) 2005-03-22 14:51:17.000-0600 oej, if that is the case, then the whole 'INVITE ignore' path in handle_request_invite needs to be reworked, because 90% of that function is inside 'if (!ignore)...' blocks. By: Olle Johansson (oej) 2005-03-22 15:52:55.000-0600 kpfleming: Yes, I'm afraid that's correct. I'll spend some time with this tomorrow, let's catch up when you go on line. By: uvik (uvik) 2005-03-22 15:55:06.000-0600 ok , with the patch :   else if (!ignore) { instead of   else { on line 7418 it works on all the UAs that failed before that. They now can INVITE By: Kevin P. Fleming (kpfleming) 2005-03-22 16:05:47.000-0600 I don't think we can afford to wait for the proper fix for 'stable', since it will be much more invasive. Essentially, my patch is just putting Asterisk's behavior when it is ignoring an INVITE back to what is used to be, which is certainly safer than what we have now. I do agree, though, that this patch should not go into HEAD, but HEAD should get a proper fix for ignored INVITES. By: Mark Spencer (markster) 2005-03-23 19:57:16.000-0600 Even ignored packets must have the proper response sent. but it should not affect the state of the call in any way. By: Kevin P. Fleming (kpfleming) 2005-03-23 23:56:54.000-0600 Based on my reading of the RFC, that is not the case, there are only certain states in an INVITE dialog where repeated packets are not completely ignored, but instead generate a repeat of the previous response. By: Olle Johansson (oej) 2005-03-24 15:23:18.000-0600 Is pedantic on? By: Mark Spencer (markster) 2005-03-26 01:31:02.000-0600 Yes, sending a repeat of the previous response is not ignoring them :) By: Mark Spencer (markster) 2005-03-26 01:40:39.000-0600 It does seem logical to merge this with 3817 so long as we don't forget about the 488/503 issue, too. By: Olle Johansson (oej) 2005-04-01 00:26:19.000-0600 --merged with another bug report.