[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:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   11231
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
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:              01-31-2008 01:56 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 - 01-31-08 01:56  
---------------------------------------------------------------------- 
It must be possible indeed to change the code that generates NOTIFYs after
REFER, so that chan_sip does not send new NOTIFYs until it receives a
response for last one (if I understand what you suggest, oej).
It may be the opportunity then, to comply to RFC 3515 "The Session
Initiation Protocol (SIP) Refer Method", section "3.10 Rate of
Notifications" : "NOTIFYs to event refer SHOULD NOT be sent more frequently
than once per second".

But the "responses ignored" problem still can occur after a series of
MESSAGES, and possibly other situations ? In fact, it is completely generic
to chan_sip transaction (request/response) handling, and even with a fix in
code that generates NOTIFYs after REFER, I keep thinking that chan_sip
should never drop a "late but valid" response as it does now.

Maybe an enhancement in REFER/NOTIFYs as you suggest, PLUS a retransmit
cancellation for residual late responses, would be a not-so-bad solution ? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-31-08 01:56  flefoll        Note Added: 0081484                          
======================================================================