[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:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16033
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.6.1.6 
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:              2010-02-18 09:06 CST
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0118216) kkm (reporter) - 2010-02-18 09:06
 https://issues.asterisk.org/view.php?id=16033#c118216 
---------------------------------------------------------------------- 
No, this is not the case. There are 2 slightly mutated clones of the same
code currently; I rearranged them into one function unregister_peer that is
called from 2 places. One place (expire_peer, if I remember correctly) has
the Cause field:

<blockquote>
-	manager_event(EVENT_FLAG_SYSTEM, "PeerStatus", "ChannelType:
SIP\r\nPeer: SIP/%s\r\nPeerStatus: Unregistered\r\nCause: Expired\r\n",
peer->name);
</blockquote>

and the second does not

<blockquote>
-		manager_event(EVENT_FLAG_SYSTEM, "PeerStatus", "ChannelType:
SIP\r\nPeer: SIP/%s\r\nPeerStatus: Unregistered\r\n", peer->name);
</blockquote>

The behavior is preserved in the new function through its second argument
`cause':

<blockquote>
+	if (mgr_cause)
+		manager_event(EVENT_FLAG_SYSTEM, "PeerStatus", "ChannelType:
SIP\r\nPeer: SIP/%s\r\nPeerStatus: Unregistered\r\nCause: %s\r\n",
peer->name, mgr_cause);
+	else
+		manager_event(EVENT_FLAG_SYSTEM, "PeerStatus", "ChannelType:
SIP\r\nPeer: SIP/%s\r\nPeerStatus: Unregistered\r\n", peer->name);
</blockquote> 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-18 09:06 kkm            Note Added: 0118216                          
======================================================================