[asterisk-bugs] [Asterisk 0016382]: [patch] SIP OPTIONS qualify message forever

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16382 
====================================================================== 
Reported By:                lftsy
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   16382
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Target Version:             1.4.38
Asterisk Version:           SVN 
JIRA:                       SWP-478 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-12-03 10:04 CST
Last Modified:              2010-09-23 15:10 CDT
====================================================================== 
Summary:                    [patch] SIP OPTIONS qualify message forever
Description: 
Hello, I have a trouble with different Asterisk versions (1.4.26, 1.4.27,
1.4.27.1). When I use the steps below, Asterisk starts to send SIP OPTIONS
to the previous IP/port used by a SIP realtime peer (that has been pruned)
and will keep trying to send SIP OPTIONS pings forever, event if the peer
is connected with a new IP/port address.

I have just checked with my old Asterisk 1.2.27 with the same sip.conf and
I do not have the problem, the SIP OPTIONS stops once register timer has
expired.

During my experience to reproduce the bug, I have been able to have 10
IP/port currently pinged by the Asterisk server for one single peer.
And the only way to stop it is to restart Asterisk...

Thank you for your attention!
Marc Leurent
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0016764 Sip Channels Colapse
related to          0015716 [patch] chan_sip fails to destroy chann...
related to          0015627 [patch] Asterisk runs out of sockets
related to          0017643 [patch] dialplan reload deadlocks in as...
====================================================================== 

---------------------------------------------------------------------- 
 (0127344) zerohalo (reporter) - 2010-09-23 15:10
 https://issues.asterisk.org/view.php?id=16382#c127344 
---------------------------------------------------------------------- 
So this is what I think is happening - a poke goes unanswered and asterisk
schedules the destruction of the peer and the lastms field is set to -1.
before the destruction, the UA in question's reply to the poke comes back,
resetting the lastms and scheduling a future poke. this continues, etc,
until a really good race gets going. You can see this if you watch the
lastms column of the sip peer jump back and forth from -1 to the pingtime
of each reply as it comes in. This seems to happen when we have a peer set
up for a failover pattern among serveral servers - even though a peer has
jumped to a backup server (due to packet loss) and back to the primary, it
appears that Polycom UAs will still reply to an OPTION, even from a server
it's not on - this causes the behavior we see when a secondary server DoS's
the phone and connection. Some of the time, this shows up as a bunch of
repeating "Peer 'PEER' is now Reachable. (pingtime / maxms)." 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-23 15:10 zerohalo       Note Added: 0127344                          
======================================================================