[asterisk-bugs] [Asterisk 0011231]: [patch] Many retransmits when chan_sip generates multiple outstanding requests
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Feb 4 04:39:11 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: 02-04-2008 04:39 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" :-)
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0010915 Problems when doing an attended and una...
related to 0010052 NOTIFY race condition when state change...
======================================================================
----------------------------------------------------------------------
flefoll - 02-04-08 04:39
----------------------------------------------------------------------
Here are the results of my test.
- the patch won't work as is : a "return AST_SUCCESS;" should terminate
the new code "Check if we already have an open NOTIFY transaction" in
transmit_notify_with_sipfrag(), otherwise we queue the new NOTIFY, but we
send it anyway :-)
- in my call scenarios, the 200 response to first NOTIFY is handled in the
"Responses to OUTGOING SIP requests on INCOMING calls" section of
handle_response(). Bad luck :-) for me. In fact, handle_response() contains
a huge "if (ast_test_flag(&p->flags[0], SIP_OUTGOING)) { ... } else {
...}" where both parts of the if/else contain a "case 200" and I think
that both parts should include the NOTIFY de-queuing code, or even better,
the de-queuing code may be common and reside outside the incoming/outgoing
alternative.
But : if I add the "return" in transmit_notify_with_sipfrag() and I
duplicate the de-queuing code where it is useful (although I don't like
this solution very much), I obtain indeed a delayed NOTIFY transmission.
Issue History
Date Modified Username Field Change
======================================================================
02-04-08 04:39 flefoll Note Added: 0081642
======================================================================
More information about the asterisk-bugs
mailing list