[asterisk-bugs] [Asterisk 0010052]: NOTIFY race condition when state changes happen very fast

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10052 
====================================================================== 
Reported By:                raarts
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   10052
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            1.2.19  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             06-25-2007 08:47 CDT
Last Modified:              01-10-2008 05:50 CST
====================================================================== 
Summary:                    NOTIFY race condition when state changes happen very
fast
Description: 
This particular problem was encountered with SNOM360 phones, but it is not
specific to it.

What happens:
- SNOM has subscribed a LED to another phone
- SNOM user dials this other phone. 
- dialplan adds an answer-after=0 SIP header.
- asterisk send INVITE to the other phone
- other phone send back RINGING, this is sent back to the SNOM as well
- asterisk send NOTIFY 'early' to the SNOM
- meanwhile, the other phone answers very quickly
- asterisk sends OK to INVITE to SNOM to indicate the other phone 
  has answered the line, and immediately after that, a NOTIFY 'confirmed'.

  At this point in time the OK to the previous NOTIFY 'early' has not 
  been sent yet by the SNOM.

Now the system is confused, because the SNOM finally sends the OK
to the NOTIFY 'early', but asterisk is only expecting an OK to the
last sent NOTIFY, and starts retrying. See attached trace.

I think asterisk should not sent a new NOTIFY. I think ideally NOTIFY's
should be queued on a per-channel basis. Or should asterisk remember
earlier



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

---------------------------------------------------------------------- 
 flefoll - 01-10-08 05:50  
---------------------------------------------------------------------- 
This issue seems very similar to issue 11231
http://bugs.digium.com/view.php?id=11231 or former issues 9567
http://bugs.digium.com/view.php?id=9567, 10915
http://bugs.digium.com/view.php?id=10915, 10946
http://bugs.digium.com/view.php?id=10946, all due (or partly due) to
chan_sip performing inappropriate retransmits (consequences may vary,
depending on devices ...) because it explicitely ignores SIP responses
where CSeq is not the last highest CSeq that it sent. Thus, the problem
arises each time chan_sip sends a "too fast" series of requests (within a
SIP dialog).

The patch that one47 proposes keeps the ast_set_flag SIP_PKT_IGNORE and
SIP_PKT_IGNORE_RESP but continues handling the response. I proposed a very
similar patch for issue 10946 that merely dropped the "ignore" code section
: it is the same as one47 patch, except that SIP_PKT_IGNORE and
SIP_PKT_IGNORE_RESP were not set.

In reply to Olle questioning about this "ignore" section, imho, it may
originate in a copy/paste of code that is pertinent when handling a
REQUEST, certainly not when handling a RESPONSE : you can find the
equivalent "if (p->icseq && (p->icseq > seqno))" (versus "if (p->ocseq &&
(p->ocseq != seqno))") just below the section that handle responses, when
entering requests handling. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-10-08 05:50  flefoll        Note Added: 0076628                          
======================================================================