[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:                file
====================================================================== 
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:              11-28-2007 09:21 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



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

---------------------------------------------------------------------- 
 one47 - 11-28-07 09:21  
---------------------------------------------------------------------- 
oej: In fact, the existing chan_sip code is clever enough to know that a
new transaction (notify) may have started before the old one is complete,
and keeps a nice list of all of the outstanding ones so they can be
retransmitted, with a note of which one is "current" ie. which one is the
most recent.

What is happening without the patch is that the OK for an "old" NOTIFY is
arriving, and being COMPLETELY ignored. This means that the NOTIFY is never
removed from the outstanding-work list, and starts to be retransmitted.

Each retransmit receives an OK, which is also ignored because the
transaction is not at the "top of the stack".

The code change simply allows the OK to be processed, the old NOTIFY timer
is then stopped and removed from the retries list, and everyone is happy.
The code even looks as if it was written to work in the manner specified by
the patch, but that there was a typo during the initial execution :)

Like some other people, I now have this in production at several sites,
and have yet to find a problem (of course I realise that this means nothing
:) ) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-28-07 09:21  one47          Note Added: 0074471                          
======================================================================