Summary:ASTERISK-17523: Qualify for static realtime peers does not work
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2011-03-08 09:19:23.000-0600Date Closed:2014-03-06 22:37:24.000-0600
Versions: 11.2.1 Frequency of
Environment:Attachments:( 0) full
( 1) realtime_fix_11.7.0.txt
( 2) sip.conf
Description:Every time when I run command "sip show peers", every peer has status UNKNOWN, below is a sample output of the peer (jamicque) and friend (test001 who registers to Asterisk).

sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
jamicque/jamicque              5060     UNKNOWN    Cached RT
test001/test001           D   N      5060     OK (5 ms)  Cached RT

In additional info is the real-time configuration of test001 and jamicque



"1","test001","test001","\N","\N","*","no ","CALLEX","\N","\N","\N","\N","sip:test001@^3Brinstance=198163cbdf0a1fbf^3Btransport=UDP","dynamic","\N","\N","11@CALLEX","\N","yes","\N","\N","\N","\N","5060","yes","\N","\N","\N","test001","friend","test001","all","alaw;g729","\N","1299597595","","\N","yes","\N","\N","1","\N","9999","no","\N","Zoiper rev.11137","5"

"14","jamicque","jamicque","\N","\N","\N","no ","CALLEX","\N","\N","\N","sip.freeconet.pl","\N","","invite,port","\N","\N","\N","no","\N","\N","\N","\N","5060","yes","\N","\N","\N","xxxxxxx","peer","jamicque","all","g729;alaw","\N","0","","\N","yes","\N","\N","\N","6","9999","no","\N","\N","\N"
Comments:By: Maciej Krajewski (jamicque) 2011-03-08 09:26:29.000-0600

I can add that no NOTIFY'a are send by asterisk to jamicque
I use postgres conneted via ODBC

By: Leif Madsen (lmadsen) 2011-03-08 11:39:35.000-0600

Per bug guidelines when filing issues related to SIP:

* sip.conf configuration file
* SIP trace from the Asterisk console with debug level logging
* layout of topology and devices in use

You must be able to provide enough information for someone else to be able to reproduce the issue.

By: Maciej Krajewski (jamicque) 2011-03-08 13:11:49.000-0600

Hi, I've attached the full debug log from restarting asterisk and making the call.
The topology is as follows. (NAT) ---- (Asterisk) --(NAT)---- sip.freeconet.pl (Telco)

After making the call
sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     Realtime
jamicque/jamicque              5060     UNKNOWN    Cached RT
test001/test001           D   N      8335     OK (40 ms) Cached RT
2 sip peers [Monitored: 1 online, 1 offline Unmonitored: 0 online, 0 offline]

If there is any more information needed, please let me know.

No NOTIFY packet is send towards sip.freeconet.pl

By: Maciej Krajewski (jamicque) 2011-03-17 10:52:06

is there any more information required?

By: Maciej Krajewski (jamicque) 2011-06-07 12:55:59.129-0500

this bug still exists in

By: Maciej Krajewski (jamicque) 2012-02-13 13:44:06.391-0600 still the same.

By: Trevor Peirce (trev) 2013-02-07 14:00:27.912-0600

I was about to create a new ticket but this looks like the same problem.

I use MySQL -> ODBC -> Asterisk Realtime for SIP peers.

Sometimes, Asterisk writes a 0 or -1 in the lastms column (presumably when a peer is offline or similar).

The next time Asterisk loads this peer it reports the status as UNKNOWN and never sends any probes to determine if the peer is up.

The workaround is to manually edit the database and replace lastms with a value of 1 or greater.  Prune the realtime peer, load it, and then Asterisk send the qualify packet and reports the peer as online once again.

This affects at least Asterisk 11.2.0 and

By: Trevor Peirce (trev) 2013-04-22 13:35:54.307-0500

It seems this is the culprit.

By: Trevor Peirce (trev) 2013-04-22 13:36:20.953-0500

I have attached fix realtime.txt with what I believe is a fix.

By: wushumasters (wushumasters) 2013-06-22 12:18:32.460-0500

I had the same problem and only solved with the patch of Trevor but in version 1.8.22 the lines on chan_sip.c are different.

If I set in the lastms value 2ms when created a peer works too

Sorry my english

By: wushumasters (wushumasters) 2013-07-05 12:32:04.409-0500

I try 11.4.0 and the same problem. Only solved with patch

By: Trevor Peirce (trev) 2014-02-10 01:50:04.048-0600

Attached a new file for Asterisk 11.7.0 with a more in depth fix.

By: Michael L. Young (elguero) 2014-02-10 11:42:22.715-0600

I am not sure that there is a bug here.  It would appear that the current behavior is working according to the way it was intended.

I do not agree with this patch.

If a peer is registering to us (dynamic), we should not be sending out pokes if the peer has expired.  The peer may no longer be at the last address registered.  That peer should be re-registering with us anyways to say "Here I am.  This is my current address."

It would appear that this occurs when a peer expires during an Asterisk restart.  Therefore, if the peer sent a registration refresh and it didn't get back a response from Asterisk, it should be sending another registration refresh.

Now, we do have the configuration setting "ignoreregexpire" so that you can still send a call to the peer even though their registration has expired.

What is the problem that is trying to be fixed besides the output from "sip show peers" displaying "Uknown"?


By: Trevor Peirce (trev) 2014-02-10 12:06:28.775-0600

The problem I observed affects only static realtime peers with qualify enabled.

If a peer goes offline, Asterisk writes -1 as lastms.  If a peer did not have qualify enabled, but is subsequently enabled, Asterisk will have 0 as lastms.

Upon a restart of Asterisk, it'll load the peer with lastms of either 0 or -1.

This prevents Asterisk from sending an initial probe to determine if the peer is online.  If a call is destined to this peer, it instantly refuses as it believes the peer is perpetually offline.

The most recent patch I uploaded includes more logic to prevent peer poking on expired dynamic peers but to always initiate the poke process for static realtime peers.

By: Michael L. Young (elguero) 2014-02-27 12:19:32.327-0600

Trevor, thanks for clarifying that this is for static peers in realtime.  I think this is a different issue than what was originally reported.  It appears that the original reporter was working with a dynamic peer.

Otherwise, I think the latest patch is not too bad. Perhaps we should open a new issue for realtime static peers not being poked when loaded and qualify is set to yes.  We can then link it to this issue as being related.

By: Trevor Peirce (trev) 2014-02-28 10:19:22.571-0600

I think this is exactly the same issue.  If you look at the original report, the copy/paste of "sip show peers" shows one UNKNOWN peer and one OK peer.  The UNKNOWN peer is a static peer, and the OK peer is one that registers.

By: Michael L. Young (elguero) 2014-02-28 10:32:55.433-0600

Thanks for your patience - I was looking at the wrong peer in the database output in the description.  So, you are right.

Do you have access to review board?  If not, I can put this up for review for you and try to move this along.

By: Trevor Peirce (trev) 2014-02-28 12:00:10.241-0600

I do not have review board access.  If you could post it I'd greatly appreciate it!

By: Michael L. Young (elguero) 2014-03-03 13:09:03.704-0600

Trevor, it looks like everyone who has signed a contributor's license now has access to Review Board.  You should be able to use the same login that you use for JIRA.  If you want, you can go ahead and post the patch there in order for it to be reviewed.


By: Michal Rybarik (pixall) 2014-03-03 18:28:08.266-0600

I applied patch to the latest asterisk-11, and it resolved the problem.  Static realtime peers are now qualified properly.  Thank you Trevor for the patch, good work.

By: Michael L. Young (elguero) 2014-03-04 08:32:41.711-0600

Trevor, I see that your patch has been reviewed and it was accepted.  I will work on getting this committed for you.

By: Matt Jordan (mjordan) 2014-03-06 22:02:57.342-0600

Hey Michael - I had some time and went ahead and committed it. :-)

By: Michael L. Young (elguero) 2014-03-07 08:45:00.064-0600

Thanks Matt - I have been a real slow poke lately.  Thanks for helping to get this in.