| 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: | |
| Priority: | Minor | Regression? | |
| Status: | Open/New | Components: | Channels/chan_sip/Registration |
| Versions: | 1.6.2.19 1.8.5.0 13.18.4 | Frequency of Occurrence | Frequent |
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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[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@192.168.1.163:5061 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. | ||