|Summary:||ASTERISK-18160: Delay between sip unregistration and peer status change|
|Reporter:||Vadim Mikhnevych (vmikhnevych)||Labels:|
|Date Opened:||2011-07-21 06:53:27||Date Closed:|
|Versions:||22.214.171.124 126.96.36.199 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 127.0.0.1:5061
[Jul 21 14:43:51] NOTICE: 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
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:firstname.lastname@example.org:5061
Qualify Freq : 60000 ms
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.