Asterisk info slow to update SIP registrations

[dcitelecom]

From time to time we have a user complaining that his SIP adapter is no longer working and we go to Asterisk Info > Sip Info and check his Sip registration.

Unfortunately there seems to be a delay with the list mechanism. Many times an adapter is not registered but still shows as registered on the SIP Info list. This was much more accurate in trixbox. Loss of registration was reported almost immediately on their SIP info screen.

Is there a setting we have to change to refresh the sip registration faster?

 

[kh40s]

Asterisk will show the device as registered until such time as the registration expires. The question is why the device does not think it is registered. There are two possibilities: (A) it is losing network connectivity or (B) for some reason it is ignoring the registration expiry timer sent back by Asterisk in the SIP OK response to the REGISTER request and setting a shorter one.

For (A), put "yes" in the Qualify field on the extension definition on the Freepbx admin interface. This will cause Asterisk to send it an OPTIONS keepalive request every 60 seconds. If there is loss of connectivity, then Asterisk will know about it in 60 seconds or less. That might fix your symptom (the SIP peers showing the device still registered), but won't tell you why the device is losing connectivity. If it is behind a NAT router, that could be the explanation (as UDP connections will generally be flushed from a NAT table after 120 seconds of no traffic). You need to check on the device config: see what its registration timeout value is set to, and check on the other registration parameters, such as how many times it tries to reregister in event of a failure, etc.

(B) is very unlikely, so there's no point in exploring it further until you've checked if the solution in (A) works for you.

Can you post more information about your network topology? It would help in diagnosing your problem...

 

[dcitelecom]

Thanks for the reply but you misunderstood my question. The issue is not why the adapter loses registration. The issue is why PBX in a flash thinks the adapter is still registered for more than 10 minutes after the registration is lost.

When we provide support to a customer we need to know in "realtime" if the adapter is registered or not. I am using the following settings in PIAF and I have also listed the previous settings from trixbox where we did not have the issue. I know we could simply mirror the setting and check if the problem goes away but apparently these are the PIAF recommended settings.

PIAF
rtptimeout=60
rtpholdtimeout=300
rtpkeepalive=20
registerattempts=60
registertimeout=100
minexpiry=60
maxexpiry=3600
defaultexpiry=120

TRIXBOX
minexpiry=60
maxexpiry=300
defaultexpiry=120
rtptimeout=60
rtpholdtimeout=120
rtpkeepalive=20

 

[Linetux]

The only thing I can think of with something like this is a firewall that is doing SIP inspection (like a Cisco ASA). It seems to me as if the firewall is proxing the SIP keep alive, but something is breaking down.

I always turn off sip inspection on ASA's, as I've never found that it works with anything other than CallManager (surprise surprise!)

 

[Astrosmurfer]

I've seen similar behavior from both systems.

Qualify=yes keeps Asterisk aware of registration or communication loss to 60 seconds or less.

 

[Linetux]

To add to that - from voip-info.org:

The value in qualfiy = represents the timeout after a packet is sent before we consider the peer to be unreachable. If the packet is not responded within 1 second, asterisk will keep trying until 7 packets have failed. At this point, asterisk won't try again until the next 60 cycle period completes. If a packet is lost, which can easily happen with UDP, there are 7 more packets which are transmitted. Additionally asterisk will keep trying every 60 seconds. So even if all 7 packets are lost, asterisk tries again at the next 60 second cycle.

 

[kh40s]

I didn't really misunderstand the post. As both Astrosmurfer and I pointed out, the solution to your problem is to use the qualify option, which will make sure that any registration loss will be picked up in 60 seconds or less. This should fix the problem of Asterisk showing a registration when in fact it is lost. Asterisk thinks the device is still registered because no qualify is being sent, and therefore there is no communication occuring (in the absence of a phone call) between the device and Asterisk until the end of the registration timeout. In the absence of communication, Asterisk must think the device is still registered. At a guess, Trixbox probably has the qualify option defaulted to yes on extensions

 

[dcitelecom]

Qualify=yes is set for all extensions and we are not behind a firewall. Both the PIAF and trixbox servers are on the same Internet connection. It's gotta be something else. Thanks.

 

[kh40s]

I assume you are refering to an entry in the SIP Peers section, and not an entry in the SIP Registry section of the info screen. I'm not sure what else you could do on the Asterisk side of the equation. The line in SIP Info,

701/701         192.168.1.100    D   N   A  5060     OK (6 ms)

is produced by a function in chan_sip.c that iterates through the linked list of peers and prints the OK message if there is a ping time associated with the peer. This ping time is set in the function

static void handle_response_peerpoke(struct sip_pvt *p, int resp, struct sip_request *req)

That is to say, only as a result of a reply to a SIP OPTIONS packet (a qualify). So this means that if the SIP Info screen is showing OK for that device, then the device is replying to Asterisk's SIP OPTIONS packet. There is a caveat, however: even if a device is not registered, it will reply to a SIP OPTIONS, but in this case likely with a SIP 403 Forbidden or SIP 401 Not authorized response. Asterisk's broken SIP OPTIONS handling code does not actually check this return code - it simply sees the response from the device, updates the ping time, and thus marks the host as reachable.

So if the device sends any type of response to a qualify (SIP OPTIONS) while holding an active registration, Asterisk will think everything is ok with it and show it as online. From Asterisk's point of view, everything IS ok with the device. Asterisk does not even do a check if the device is registered when printing out this status message.

Asterisk also still thinks the registration is valid because it's actually showing the device as online. When Asterisk's registration timer expires, the expire_register() function in chan_sip.c zeroes the address in the peer data structure. The sip_show_peers() function that is displaying the info on the SIP Info page checks if the address is zero and will show the peer as offline in the output of the SIP Info page (sip show peers in the CLI) if it is zero, ie., does not have an active registration.

So you have SIP connectivity because of the responses to the qualifies and the fact that Asterisk shows the device as still being online and Asterisk still holds a valid registration (because it shows the device as still online). There's little that you can do here other than track down why the device thinks it is not registered, because unless it stops responding to the OPTIONS, Asterisk will always think it's ok until such time as the registration timer expires. At worst case this will be 3600 seconds

 

[dcitelecom]

Thanks for the detailed explanation. So if I change the maxexpiry setting from 3600 to say 300 (like I had in my trixbox system) then it will speed up the update time to 300 seconds (worst case scenario). Right?

 

[kh40s]

Thanks for the detailed explanation. So if I change the maxexpiry setting from 3600 to say 300 (like I had in my trixbox system) then it will speed up the update time to 300 seconds (worst case scenario). Right?

Yes, that will make the worst case scenario 300 seconds.