[asterisk-dev] Asterisk Realtime - Static Peers w/ Qualify, long time bug

Trevor Peirce tpeirce-lists at acrovoice.ca
Mon Feb 10 15:28:21 CST 2014


For many years now, when using Asterisk with realtime static SIP peers, 
enabling qualify would occasionally cause peers to be stuck in an 
offline state causing Asterisk to never attempt to send calls to those 

I have determined the cause of the problem to be when Asterisk notices 
the peer goes offline, it writes -1 in the lastms column of the 
database.  Or when a new peer is created, the lastms column defaults to 
0.  This by itself is fine, and should be acceptable behaviour and 
indeed works fine if qualify=no.

For some peers, we want qualify=yes so if they are down, we can bypass 
the peer and move to an alternate peer faster.  These peers are affected 
by this bug.

The problem is exposed when Asterisk is restarted.  Upon the first need 
to contact a peer, it's loaded from the database.  If lastms < 0, 
Asterisk will *NOT* probe the peer to determine if it's up. Instead, the 
peer remains in the UNKNOWN state and Asterisk never tries to send any 
calls, even though the peer is loaded and can place calls to Asterisk.

A workaround has been to manually edit the database and change lastms to 
a value of 1 or higher, which then causes Asterisk to probe the peer as 

Upon examining chan_sip.c, I have determined that the check if lastms < 
0 was in there to avoid probing peers that are dynamic and have 
expired.  This is fine because these peers will be 'fixed' the next time 
they attempt to register.  However, static peers don't register and are 
never probed.

I propose a fix that corrects this when loading static peers, which I 
have attached to the appropriate ticket.


I would appreciate any feedback you have to offer and assistance in 
having this fix accepted into the main repo, so I can finally stop 
patching my own systems :)

Trevor Peirce
AcroVoice Solutions Inc

More information about the asterisk-dev mailing list