OK. Thanks everyone for the responses. If I can summarize, I think here's what's been discussed:
Asterisk becomes aware of SIP extensions/peers, as soon as they register. Regarding how asterisk becomes aware of (or determines) that they are unavailable/unreachable, I believe I am hearing two possible scenarios: 1. "The Interval of Registration". So asterisk has a timeout value that it is expecting the phone to reregister within. If the phone does not reregister within the timeout period, then asterisk determines that the extension/peer is no longer available. A few questions I have on this are: a. Where does this "timeout" interval come from? Is it a configuration parameter that we configure asterisk with, or is it something that is dynamically determined, or is it something that the phone/peer actually dictates to asterisk? b. If it is an asterisk configuration parameter, where does it exist (how do I set it & confirm what it is currently set to)? It is a per-extension/peer setting, or is it global? c. Is there a command I can issue from the asterisk CLI to query it? 2. "qualify=yes" can be configured for any given SIP peer in asterisk. This will send a SIP OPTIONS message/packet to the peer every 1 or 2 minutes (depending on the configuration) that probes the peer to confirm it is still online. The keepalives (SIP OPTIONS packets) are actually sent from asterisk to the SIP peer, correct? But then the SIP peer actually has to respond to each one with its own SIP packet, correct? With this scenario, asterisk will still utilize scenario 1 (reregistration) as a means of determining that the peer is available, but additionally will continue to monitor the peer constantly (every 1-2 seconds) via these keepalives? This way asterisk is able to have a much more rapid discovery of peers that become unavailable (because they are literally no longer reachable, as they're no longer responding to the keepalives), correct? So my next questions are: a. Am I wrong with any of the above interpretations of the explanations you guys have given? b. Is the "no-reply" timer Sammy mentioned [(max time)x(max retries)] a parameter that can be set within asterisk? If so, what are the corresponding configuration parameters called? If not, what are the "max time" and "max retries" values? c. Is the SIP response the peer is supposed to give also an OPTIONS packet or something else? Thanks a LOT! I really appreciate all of the input & insight you guys bring! - Doug Mortensen Network Consultant Impala Networks P: 505.327.7300 From: Sammy Govind [mailto:[email protected]] Sent: Monday, November 14, 2011 10:36 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How do extensions "stay registered" Continuing eherr here, behind the OPTIONS messages(infact all SIP comm) you definitely to look into SIP timers which tell how many time to resend a packet if no response is received and for how long to wait before thinking that the SIP packet got lost(network disconnected or end-point lost) so, qualify=yes a peer means to send-keep alives and have the NAT mechanism stay active, as soon as the SIP keep-alive packets reach a no-reply (max time)x(max retries) Asterisk marks the peer as UNREACHABLE. qualify=no wouldn't do all of the above. Another interesting thing to know is that SIP end-points have registrations time-out and refresh Registration timers as well. So if everything is going well, SIP end-points refresh their registration after some defined time. On Tue, Nov 15, 2011 at 3:35 AM, eherr <[email protected]<mailto:[email protected]>> wrote: I think the wrap up answer is the interval of registration compacted, if used, with the SIP OPTION packet. I like the SIP OPTION packet because we have scripts to monitor the status and lets us know when a phone is up or down. --E From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Carlos Alvarez Sent: Monday, November 14, 2011 5:30 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How do extensions "stay registered" I think the registration part was answered. The de-registration part is different. If the phone is gracefully taken off line it specifically de-registers. If it just can't be reached because it powers off or the router closes NAT, or whatever, then Asterisk won't know this until it times out. On Mon, Nov 14, 2011 at 3:19 PM, eherr <[email protected]<mailto:[email protected]>> wrote: I think the question is more along the lines of how does asterisk know immediately when a sip phone becomes on line and when you unplug the phone from the network, how does asterisk essentially know immediately that it status is "UNKNOWN" If I am not mistaken. --E From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Danny Nicholas Sent: Monday, November 14, 2011 5:01 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] How do extensions "stay registered" "Extensions" do not register - peers do. A peer can register itself or be registered by Asterisk. In most cases the "extension" is equivalent to the "peer" (301 = 301) but it can be quite different (301 = sipuser1) or (301 = [email protected]<mailto:[email protected]>). From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Douglas Mortensen Sent: Monday, November 14, 2011 3:52 PM To: '[email protected]<mailto:[email protected]>' Subject: [asterisk-users] How do extensions "stay registered" I know this is probably a very basic question for many on this list. But in troubleshooting an issue, I wanted to take a step back & ask the question. In Asterisk (or maybe all SIP), how do extensions stay registered with the SIP server? Do the extensions simply register repeatedly as a means of telling asterisk "I'm still here", or are there actual keepalive packets that are transmitted to actually keep a TCP session alive? My guess is the former. But am I oversimplifying it? Is there more to the process? Thanks, - Doug Mortensen Network Consultant Impala Networks Inc CCNA, MCSA, Security+, A+ Linux+, Network+, Server+ . www.impalanetworks.com<http://www.impalanetworks.com> P: (505) 327-7300<tel:%28505%29%20327-7300> F: (505) 327-7545<tel:%28505%29%20327-7545> . -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Carlos Alvarez TelEvolve 602-889-3003 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
