[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:                     closed
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-12-03 10:04 CST
Last Modified:              2010-11-11 16:01 CST
====================================================================== 
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...
related to          0017779 [patch] tcptls.c:350 Unable to connect ...
====================================================================== 

---------------------------------------------------------------------- 
 (0128800) svnbot (reporter) - 2010-11-11 16:01
 https://issues.asterisk.org/view.php?id=16382#c128800 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 294735

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r294735 | jpeeler | 2010-11-11 16:01:03 -0600 (Thu, 11 Nov 2010) | 39
lines

Merged revisions 294734 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r294734 | jpeeler | 2010-11-11 15:58:25 -0600 (Thu, 11 Nov 2010) | 32
lines
  
  Merged revisions 294733 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r294733 | jpeeler | 2010-11-11 15:57:22 -0600 (Thu, 11 Nov 2010) | 25
lines
    
    Merged revisions 294688 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010) |
18 lines
      
      Fix problem with qualify option packets for realtime peers never
stopping.
      
      The option packets not only never stopped, but if a realtime peer
was not in
      the peer list multiple options dialogs could accumulate over time.
This
      scenario has the potential to progress to the point of saturating a
link just
      from options packets. The fix was to ensure that the poke scheduler
checks to
      see if a peer is in the peer list before continuing to poke. The
reason a peer
      must be in the peer list to be able to properly manage an options
dialog is
      because otherwise the call pointer is lost when the peer is
regenerated from
      the database, which is how existing qualify dialogs are detected.
      
      (closes issue https://issues.asterisk.org/view.php?id=16382)
      (closes issue https://issues.asterisk.org/view.php?id=17779)
      Reported by: lftsy
      Patches: 
            bug16382-3.patch uploaded by jpeeler (license 325)
      Tested by: zerohalo
    ........
  ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=294735 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-11 16:01 svnbot         Checkin                                      
2010-11-11 16:01 svnbot         Note Added: 0128800                          
======================================================================