[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.37
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-08-31 15:39 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0126508) lftsy (reporter) - 2010-08-31 15:39
 https://issues.asterisk.org/view.php?id=16382#c126508 
---------------------------------------------------------------------- 
Hello,
I have to take time to test this patch ASAP, but I think that in
production the flood process starts without prune because in our
environment prune can only be triggered when modifying codec or password
which do not happen often. And floods happens everyday on unstable peers

Since we have several Asterisk servers (2 in the environment with
troubles), I was wondering if the problem can be triggered by creating a
peer with an entry that is still valid but that was created on another
Asterisk.

Ex: I have 2 Asterisk servers behind a proxy: ast-01 and ast-03, if I
register on ast-01 with register timer of 3600s and a few minutes later, on
ast-03, I try to end the call to this peer locally, it will create this
peer on ast-03 with information from the database that is valid. And I
think that it can start the flooding process like that without using the
"sip prune realime" action.


What do you think about this?
I really have to try to confirm this! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-31 15:39 lftsy          Note Added: 0126508                          
======================================================================