Summary:	ASTERISK-03727: Asterisk doesn't seem to cope well in dealing with retransmitted INVITES
Reporter:	ennuyeux72 (ennuyeux72)	Labels:
Date Opened:	2005-03-21 03:48:18.000-0600	Date Closed:	2005-06-27 23:32:29
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip1.html
Description:	Asterisk receives 2 identical INVITES due to retransmission, however it treats both as different and this causes problems which result in the call ultimately being rejected: Architecture: UA------->NAT PROXY-------->SER--------->ASTERISK----->PSTN With reference to the attached sip diagram file. There are 2 INVITES F3 and F4 but they both get a reply F5 and F8 even though F4 is a retransmission. The second reply F8 is blocked cos F5 was processed. At least this is what I think is happening.
Comments:	By: Olle Johansson (oej) 2005-03-21 03:55:07.000-0600 Is this really *latest* CVS head, updated today? By: ennuyeux72 (ennuyeux72) 2005-03-21 04:00:17.000-0600 cvs head date is 21/2/05 Has this been dealt with in the cvs updates since then. If so let me know I will update and retest. By: Olle Johansson (oej) 2005-03-21 04:11:57.000-0600 Please also provide a full SIP debug output from your Asterisk server. The diagram is very nice, thank you, but a SIP debug from Asterisk also includes a lot of information about how Asterisk reacts to messages, which is very important for me to see. By: ennuyeux72 (ennuyeux72) 2005-03-21 04:23:46.000-0600 ok willdo but do you still want me to update to the latest cvs? By: Olle Johansson (oej) 2005-03-21 04:26:02.000-0600 Note for myself: RFC3261 17.2.1: "If a request retransmission is received while in the “Proceeding” state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission. A request is a retransmission if it matches the same server transaction based on the rules of Section 17.2.3." ---We should possible not send 503 on ignore on an invite By: Olle Johansson (oej) 2005-03-21 04:52:16.000-0600 Yes, latest CVS has been going through quite a lot of changes, so I need to know if this problem exists there. By: Kevin P. Fleming (kpfleming) 2005-03-21 08:18:06.000-0600 ennuyeux72: Yes, when you report problems against CVS HEAD, you always need to check against the current version (I believe this is documented in the bug reporting guidelines). By: Kevin P. Fleming (kpfleming) 2005-03-22 16:18:30.000-0600 OK, the cause of this appears to be the same as in ASTERISK-3793820. I don't believe that the "Proceeding" state issue is actually involved here, because the initial INVITE has not been accepted (the only response generated was 407). While there is a possibility that we need to remember and retransmit 1xx responses  if we receive an INVITE that we have already accepted (according to the RFC), that is not the issue here. The "server transaction" (to use the RFC language) has not entered the "Proceeding" state, because we have not sent a 1xx response to the INVITE. ennuyeux2, please try the HEAD patch that I posted in ASTERISK-3793820 to see if it solves your problem, and report back here. Thanks! By: Olle Johansson (oej) 2005-03-23 02:29:54.000-0600 Also look at ASTERISK-3578 By: Olle Johansson (oej) 2005-05-01 15:35:00 We're waiting on response from bug reporter.... By: Olle Johansson (oej) 2005-06-05 17:36:06 Is this still a problem? Will close if no answer within a week. /Housekeeping By: Michael Jerris (mikej) 2005-06-27 23:32:29 Close what appears to be a duplicate for no response from original poster.