[asterisk-bugs] [Asterisk 0010946]: chan_sip can generate several outstanding requests, but ignores responses

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10946 
====================================================================== 
Reported By:                flefoll
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10946
Category:                   Channels/chan_sip/General
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-11-2007 02:25 CDT
Last Modified:              11-07-2007 19:09 CST
====================================================================== 
Summary:                    chan_sip can generate several outstanding requests,
but ignores responses
Description: 
chan_sip can generate several outstanding requests within a dialog. The
problem then, is that chan_sip will ignore all responses where CSeq is
lower than last outgoing CSeq, which will provoke retransmission of all
requests, except last one.

This is especially the case when chan_sip handles a REFER request and
generates NOTIFY messages towards the REFER requester : one NOTIFY is
transmitted per event during the REFER operations, without waiting for
response to previous NOTIFY's. As far as I understand, this is "BAD" but
not forbidden (see additional information).

The problem is higly related to the speed of answer of SIP devices implied
in the REFER operation.

This behaviour comes from a code section in handle_request()
[handle_incoming() in SVN trunk, but the problem seems to be the same]
after "if (req->method == SIP_RESPONSE)" :

[...] if (p->ocseq && (p->ocseq != seqno)) {
	/* ignore means "don't do anything with it" but still have to 
			   respond appropriately  */
	ignore = TRUE;
	ast_set_flag(req, SIP_PKT_IGNORE);
	ast_set_flag(req, SIP_PKT_IGNORE_RESP);
	append_history(p, "Ignore", "Ignoring this retransmit\n");
} [...]

My first idea is to remove this code, in order let handle_response() do
its work (just below). I tried and it seems to work, but I'm not 100% sure
of side-effects. Any opinions ?

====================================================================== 

---------------------------------------------------------------------- 
 svnbot - 11-07-07 19:09  
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 89097

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r89097 | file | 2007-11-07 19:09:28 -0600 (Wed, 07 Nov 2007) | 8 lines

Add support for allowing one outgoing transaction. This means if a
response comes back out of order chan_sip will still handle it. I dream of
a chan_sip with real transaction support.
(closes issue http://bugs.digium.com/view.php?id=10946)
Reported by: flefoll
(closes issue http://bugs.digium.com/view.php?id=10915)
Reported by: ramonpeek
(closes issue http://bugs.digium.com/view.php?id=9567)
Reported by: atca_pres

------------------------------------------------------------------------ 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-07-07 19:09  svnbot         Checkin                                      
11-07-07 19:09  svnbot         Note Added: 0073343                          
11-07-07 19:09  svnbot         Status                   acknowledged => assigned
11-07-07 19:09  svnbot         Assigned To               => file            
======================================================================