Summary:ASTERISK-18160: Delay between sip unregistration and peer status change
Reporter:Vadim Mikhnevych (vmikhnevych)Labels:
Date Opened:2011-07-21 06:53:27Date Closed:
Versions: 13.18.4 Frequency of
Description:After a phone (SIP peer) us unregistered (and Asterisk console shows the appropriate message), "sip show peer XXX" command shows its status as OK for some time.
This also affects the SipShowPeerResponse for SipShowPeerAction (Asterisk-Java classes, wrapping the SIPshowpeer manager action), which we use to determine peer information upon receiving PeerStatusEvent.

A copypaste from asterisk console:

CLI>     -- Registered SIP '2051' at
[Jul 21 14:43:51] NOTICE[20471]: chan_sip.c:20087 handle_response_peerpoke: Peer '2051' is now Reachable. (19ms / 2000ms)
   -- Unregistered SIP '2051'
CLI> sip show peer 2051

 * Name       : 2051
 Secret       : <Set>
 MD5Secret    : <Not set>
 Remote Secret: <Not set>
 Context      : PHBX_165
 Subscr.Cont. : PHBX_165_HINT_2051
 Language     : en
 Accountcode  : 2051
 ToHost       :
 Addr->IP     : (null)
 Defaddr->IP  : (null)
 Prim.Transp. : UDP
 Allowed.Trsp : UDP
 Def. Username: 2051
 SIP Options  : (none)
 Codecs       : 0x50e (gsm|ulaw|alaw|g729|ilbc)
 Codec Order  : (g729:20,ulaw:20,alaw:20,gsm:20,ilbc:30)
 Auto-Framing :  No
 100 on REG   : No
 Status       : OK (19 ms)
 Useragent    : sflphoned/0.9.6
 Reg. Contact : sip:2051@
 Qualify Freq : 60000 ms
 Variables    :
                MOH = MOH_170
 Sess-Timers  : Accept
 Sess-Refresh : uas
 Sess-Expires : 1800 secs
 Min-Sess     : 90 secs
 RTP Engine   : asterisk
 Parkinglot   : PARKINGLOT_165
 Use Reason   : No
 Encryption   : No
Comments:By: David Woolley (davidw) 2011-07-21 07:37:55.221-0500

At the most, this is trivial, not major.  It is showing the results of the qualify mechanism, not the device status.

By: Vadim Mikhnevych (vmikhnevych) 2011-07-21 08:24:00.687-0500

It makes data received from Asterisk inconsistent - one source says that a peer can't be reached, the other says it's ok. That is, at least, confusing.
Besides, "Addr->IP" is (null) after the peer is unregistered, and it looks like peer unregistration affects peer information partially - IP is updated, but status is not. And we have a peer without IP, but it's OK.
Perhaps qualify should be triggered upon peer unregistration to update the data completely?

By: Leif Madsen (lmadsen) 2011-09-12 15:37:37.591-0500

This is a borderline feature request (well, it technically *is* a feature request) but I'm going to acknowledge it because I believe this is something worth doing.