I had this problem too, and I’m still working on it. I found this information at * website:
[b]If qualify=yes or a numeric value, then asterisk will sometimes poke this peer by sending a “SIP OPTIONS” request to phones or other pbx’s.
If they do not reply on time, they will be considered unreachable, and this message will be printed on the asterisk CLI.
When the phone is back online (first time it replies on time) then asterisk will tell you Peer ‘XXX’ is now REACHABLE, if we got a reply from the phone, but not on time, the message Peer ‘XXX’ is now too LAGGED will be printed on the CLI.
The timeout is set to 2000ms by default. (If you specify qualify=yes).
But you could also set it to any other value.
- Reasons for seeing this message:
When a phone is rebooted, or when a phone hangs, or when its shut down this message might pop up.
(Or when there is a too big delay on the network).
If all your phones become unreachable at the same time, its probably your asterisk server that has network problems instead of the phone.
When a phone is unreachable, asterisk will not try to call it. (So you might want to set this value not too low, or you might want to completely disable it).
If the phone that has unreachable messages all the time is behind a NAT, it might be that the UDP timeout is set too low on the firewall.[/b]
So, there are two options. Number is to disable the qualify atribute, what should change the status of the peer to unmonitored. Increasing the time of the qualify atribute is not likely to work, because 2 seconds is plenty of time to get the response from the peer in most situations (of course it may be of some value sometime, and it worth the shot). It’s important to note that the qualify value is just a timeout for the response, it’s not an interval that asterisk uses to pool the peer. Even thought you won’t get an unreachable status, it’s not guaranteed that your peer is going to work, and that’s because of the last line in Reasons for seeing this message. This means that if your peer is in a LAN, your gateway has an UDP timeout to bind it’s public port to your application. The bind is established the first time you send a packet, and it should remain active for a period of time without receiving new packets. With the timeout occur, then your appication won’t receive any packet any more, and won’t be able to receive the options request from asterisk. That’s the main problem… In this case, the notify atribute helps to keep the UDP binding active, because it keeps the traffic in the gateway public port.
Resuming: Try to increase the qualify timeout. If it doesn’t work, you’re loosing the UDP binding, and your application is not receiving the packets anymore.