[asterisk-bugs] [Asterisk 0011231]: [patch] Many retransmits when chan_sip generates multiple outstanding requests

Tue Jun 30 13:56:39 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=11231 
====================================================================== 
Reported By:                flefoll
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   11231
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:            SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 89184 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2007-11-13 08:08 CST
Last Modified:              2009-06-30 13:56 CDT
====================================================================== 
Summary:                    [patch] Many retransmits when chan_sip generates
multiple outstanding requests
Description: 
I opened issue 10946 in october http://bugs.digium.com/view.php?id=10946 on
the same subject, but it was closed last week, together with issue 9567 and
issue 10915 (sorry, I was away last week).

All 3 issues were closed when chan_skip rev 89097 was committed. This
revision adds support for one outgoing transaction with the new
"lastnoninvite" field.

So, I have given a try to modification brought by chan_skip rev 89097. But
it does not solve the retransmit problem for me.

Typically, try with a series of SendText(ABC) in your extensions.conf :
the SIP peer will never respond quickly enough, and all (except last)
MESSAGE messages will be retransmitted. Silly test, but easy to reproduce
!
The problem also most probably still occurs when REFER handling provokes
too many and too quick NOTIFY messages (not re-tried yet, but new
"lastnoninvite" can handle one NOTIFY only).

Consequently, I propose another patch : this one won't remove code :-) but
it will add a few more lines instead, in order to cancel retransmits when
chan_sip receives a "late" response.

I know, it does not respond to file's dream of "a chan_sip with real
transaction support" :-)

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010915 Problems when doing an attended and una...
has duplicate       0014547 [patch] Resending CANCEL doesn't stop
related to          0010052 NOTIFY race condition when state change...
====================================================================== 

---------------------------------------------------------------------- 
 (0107250) svnbot (reporter) - 2009-06-30 13:56
 https://issues.asterisk.org/view.php?id=11231#c107250 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 204247

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r204247 | mmichelson | 2009-06-29 16:48:54 -0500 (Mon, 29 Jun 2009) | 34
lines

Merged revisions 204243,204246 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r204243 | mmichelson | 2009-06-29 16:23:43 -0500 (Mon, 29 Jun 2009) | 22
lines

  Fix a problem where chan_sip would ignore "old" but valid responses.

  chan_sip has had a problem for quite a long time that would manifest
when
  Asterisk would send multiple SIP responses on the same dialog before
receiving
  a response. The problem occurred because chan_sip only kept track of the
highest
  outgoing sequence number used on the dialog. If Asterisk sent two
requests out,
  and a response arrived for the first request sent, then Asterisk would
ignore
  the response. The result was that Asterisk would continue retransmitting
the
  requests and ignoring the responses until the maximum number of
retransmissions
  had been reached.

  The fix here is to rearrange the code a bit so that instead of simply
comparing
  the sequence number of the response to our latest outgoing sequence
number, we
  walk our list of outstanding packets and determine if there is a match.
If there is,
  we continue. If not, then we ignore the response.

  In doing this, I found a few completely useless variables that I have
now removed.

  (closes issue https://issues.asterisk.org/view.php?id=11231)
  Reported by: flefoll

  Review: https://reviewboard.asterisk.org/r/298
........
  r204246 | mmichelson | 2009-06-29 16:37:05 -0500 (Mon, 29 Jun 2009) | 3
lines

  Fix build oops.
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=204247 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-30 13:56 svnbot         Checkin                                      
2009-06-30 13:56 svnbot         Note Added: 0107250                          
======================================================================