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

noreply at bugs.digium.com noreply at bugs.digium.com
Fri Nov 2 02:36:20 CDT 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10946 
====================================================================== 
Reported By:                flefoll
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10946
Category:                   Channels/chan_sip/General
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     new
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-02-2007 02:36 CDT
====================================================================== 
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 ?

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

---------------------------------------------------------------------- 
 flefoll - 11-02-07 02:36  
---------------------------------------------------------------------- 
chan_sip.c.trunk.86150.outstandreqs-patch still applies to current Trunk
head : revision 88077.
I add chan_sip.c.1.4.13.outstandreqs-patch that applies to Asterisk 1.4.13
and current 1.4 Branch head : revision 87342.

Between 1.4 and Trunk, two ast_set_flag() have disappeared, and the
comment has changed, but the problem is the same.
I disagree with the comment in Trunk, when CSeq in response is lower than
last outgoing CSeq : "But in this case this is a response already, so we
really have nothing to do with this message, and even setting the ignore
flag is pointless". Ignoring "late" responses *is* a problem because
chan_sip will illegitimately retransmit requests. Without the patch, we did
have the problem with NOTIFY messages that follow a REFER request.

Any comments or feedback ? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-02-07 02:36  flefoll        Note Added: 0072953                          
======================================================================




More information about the asterisk-bugs mailing list