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

noreply at bugs.digium.com noreply at bugs.digium.com
Thu Jan 31 02:01:04 CST 2008


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 02:01 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" :-)

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

---------------------------------------------------------------------- 
 oej - 01-31-08 02:01  
---------------------------------------------------------------------- 
I'll take a look, but there's a limit on how much time I can spend on
non-customer related Asterisk issues currently. 

In general, my opinion is that this is just patches to an already bad code
base that needs a rewrite. There's no transaction state engine which shows
up in more and more bug reports. Everything we can do right now is just
quick and very dirty fixes. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-31-08 02:01  oej            Note Added: 0081485                          
======================================================================




More information about the asterisk-bugs mailing list