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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11231 
====================================================================== 
Reported By:                flefoll
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11231
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 89184 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-13-2007 08:08 CST
Last Modified:              11-14-2007 03:09 CST
====================================================================== 
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" :-)

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

---------------------------------------------------------------------- 
 flefoll - 11-14-07 03:09  
---------------------------------------------------------------------- 
I confirm that REFER handling still provokes NOTIFY's retransmits, even
with new "lastnoninvite" feature. Typically :

IF a *fake* "NOTIFY 183 Ringing" sent by handle_request_refer() is
followed "too quickly" by a *real* "NOTIFY 200 Ok" (too quickly to enable
REFER requester to repond to first NOTIFY before),

THEN retransmits occur for "NOTIFY 183 Ringing", because new lastnoninvite
stores CSeq for last NOTIFY, not first one (am I clear enough ? hemm ...).

The patch I propose here fixes the problem, since it cancels retransmit
mechanism, in case we decide not to handle the response (until chan_sip can
fully handle responses when it generates multiple outstanding requests :
this is another question). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-14-07 03:09  flefoll        Note Added: 0073629                          
======================================================================