[asterisk-bugs] [Asterisk 0016033]: [patch] Autocreated peers not deleted when unregister explicitly, become zombies

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16033 
====================================================================== 
Reported By:                kkm
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   16033
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Target Version:             1.4/1.6.2 Issues (Final Release)
Asterisk Version:           SVN 
JIRA:                       SWP-909 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-10-07 04:50 CDT
Last Modified:              2011-04-26 17:47 CDT
====================================================================== 
Summary:                    [patch] Autocreated peers not deleted when
unregister explicitly, become zombies
Description: 
When a SIP peer is autocreated (per `autocreatepeer=yes' in sip.conf), and
later explicitly un-registers, the peer record in Asterisk is never
deleted. 

The `sip show peer' command output indicated `Transport : UNKNOWN'. This
changes the moment the peer unregisters; before that, the transport is
indicated as UDP.

The peer stays in the list forever, but registration with the same name
becomes impossible. Each REGISTER message is rejected by Asterisk, and the
following error is printed:

[Oct  7 02:21:31] ERROR[26490]: chan_sip.c:11650 register_verify: 'UDP' is
not a valid transport for 'dyn-Q-N5'. we only use 'UNKNOWN'! ending call.
[Oct  7 02:21:31] NOTICE[26490]: chan_sip.c:19958 handle_request_register:
Registration from '<sip:dyn-Q-N5 at 192.168.0.91>' failed for '192.168.0.103'
- Device not configured to use this transport type

If, however, the peer fails to register within its registration expiration
time, the record is deleted as expected.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015638 [patch] event AgentComplete - fields di...
related to          0017774 [patch] SIP peers memory leak
related to          0016908 [patch] SIP autocreate peers registered...
====================================================================== 

---------------------------------------------------------------------- 
 (0134162) svnbot (reporter) - 2011-04-26 17:47
 https://issues.asterisk.org/view.php?id=16033#c134162 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 315671

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r315671 | twilson | 2011-04-26 17:47:58 -0500 (Tue, 26 Apr 2011) | 11
lines

Make sure unregistering a peer unlinks it from the peer container

Instead of mostly copying the code from expire_register, just use the
function
that "does the right thing".

(closes issue https://issues.asterisk.org/view.php?id=16033)
Reported by: kkm
Patches: 
      016033-tilgman-fixed-refcount.diff uploaded by kkm (license 888)
Tested by: kkm, tilghman, twilson

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-26 17:47 svnbot         Checkin                                      
2011-04-26 17:47 svnbot         Note Added: 0134162                          
======================================================================