Summary:ASTERISK-15137: [patch] [regression] The status of External SIP peer used as Queue member is not updating correctly
Reporter:Alisher (licedey)Labels:
Date Opened:2009-11-13 23:49:00.000-0600Date Closed:2011-07-27 13:28:56
Versions:Frequency of
Environment:Attachments:( 0) conf.zip
( 1) full.zip
( 2) patch.asterisk1.4.28
( 3) patch.asterisk1.6.2.0
Description:The External SIP peer used in Queue doesn't update it's status when it becomes available. The subscription hints are updated correctly but Queue member status remaining in Unavailable state. When all queue members are external peers, it ends up as all members are busy. It's possible to dial directly external sip peer but not from the queue. The only way to correct the status is to launch reload command from CLI.

This issue was discovers in April but still wasn't correct even with the latest releases, here is the link to the discussion thread:

This issue is also discussed on FreePBX forum:

Here are the steps to reproduce the issue:
1. Configure external sip peers (qualify=yes) and add them to the Queue
2. Check the status the of sip peers and test the Queue
3. Remove internet connection from one of the external SIP. So the state of sip peer/queue member is stated as Unavailable
4. Connect internet back
5. Now the subscription and peer state of the external sip peer should become Idle/available again, but queue member state is still unavailable


localhost*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status
3005/3005            D   N      5060     Unmonitored
3019/3019                  (Unspecified)    D   N      0        OK (113 ms)

localhost*CLI> core show hints
   -= Registered Asterisk Dial Plan Hints =-
                  3019@BLF_Group_1         : SIP/3019              State:Idle            Watchers  1
                  3005@BLF_Group_1         : SIP/3005              State:Idle            Watchers  0

localhost*CLI> show queue
RQueue_1     has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime), W:0, C:0, A:6, SL:0.0% within 60s
  Members: I>
     SIP/3005@3005 (Not in use) has taken no calls yet
     SIP/3019@3019 (Unavailable) has taken no calls yet
  No Callers>
Comments:By: Leif Madsen (lmadsen) 2009-11-16 10:46:51.000-0600

Well, the issue wasn't reported here -- it was just mentioned on a FreePBX mailing list which does not count as being reported.

Additionally, I'm not 100% sure if this is an issue that can be resolved on 1.4 -- session-timers in the later 1.6.x versions (I think 1.6.1.x had them first) may resolve this issue as you're disconnecting a device from the network.

Regardless, you haven't provided any console output or sip traces per the bug guidelines in order to determine if this is an issue or not.

By: Alisher (licedey) 2009-11-16 18:37:16.000-0600

To Imadsen: The source of the issue is not sip, but app_queue, since when device is connected back to network, the hints and peer state are indicated correctly. If it was sip related issue than the device would be available to dial. But it works for Peer-to-Peer calls and doesn't work only with Queue.

After doing some tests and looked into app_queue code, I noticed that the status of Queue member is update only when Queue tries to dial the certain peer.

I will capture some output from CLI and upload it here.

By: Alisher (licedey) 2009-11-22 17:29:38.000-0600

I took some more tests, and noticed that it's not easy to reproduce the issue in the normal situation. I have uploaded the the log file with CLI output and SIP traces. During the tests I was able to dial the remote external member, but the status in the queue wasn't stated correctly.

By: Alisher (licedey) 2009-12-19 12:49:25.000-0600

After I upgraded Asterisk to the latest version, 1.4.28 and 1.6.2. I found that queue member states are broken. After the first call, the all members states in the queue are set to [Rining] and remains like that all time even when the call is ended/hanged up. It's not possible to receive a call anymore and requires to reload the app_queue module.

localhost*CLI> queue show
RQueue_1     has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:3, SL:0.0% within 60s
  Members: I>
     SIP/3005@3005 (Ringing) has taken no calls yet
  No Callers>
localhost*CLI> core show channels
Channel              Location             State   Application(Data)
0 active channels
0 active calls
9 calls processed

By: Leif Madsen (lmadsen) 2009-12-22 14:30:45.000-0600

Can you provide your configuration files so we can attempt to reproduce this?

By: Alisher (licedey) 2009-12-22 19:39:24.000-0600

I have uploaded extension.conf/queue.conf and sip.conf files in the conf.zip.

By: Leif Madsen (lmadsen) 2009-12-23 11:44:03.000-0600

In the future, please attach the files as plaintext files and not within an archive. Thanks!

By: Alisher (licedey) 2009-12-24 04:18:37.000-0600

It seems that the issue I mentioned on 2009-12-19 12:49 is caused by adding @extension to the member.

After I removed @3005 tail from the member in queue.conf the states started showing correctly.

member => SIP/3005@3005 to member => SIP/3005

So we cannot use member => Technology/Peer@Peer in the Asterisk 1.6.XX

I will take some tests with the latest version to see, if external sip states are stated correctly, and report it here.

By: Leif Madsen (lmadsen) 2010-01-04 13:52:27.000-0600

And what version did that work in previously? That seems like a very strange setup...

By: Alisher (licedey) 2010-01-05 02:46:14.000-0600

This worked until (app_queue.c Revision: 115320). I tested with all 1.6.XX versions, it doesn't work with 1.6.X. There was patch that added a modifications to interfaces states, it was backported from 1.6 version. The change was made after 1.4.26 version.

By: Leif Madsen (lmadsen) 2010-01-05 08:48:58.000-0600

Can you retest a revision prior to 115320 and then 115320 directly to make sure that is the exact commit that caused this issue? Thanks!

By: Leif Madsen (lmadsen) 2010-01-05 08:49:59.000-0600

svn log -r 115320 http://svn.asterisk.org/svn/asterisk/branches/1.4
r115320 | mmichelson | 2008-05-05 16:41:34 -0500 (Mon, 05 May 2008) | 13 lines

Don't consider a caller "handled" until the caller is bridged with
a queue member. There was too much of an opportunity for the member
to hang up (either during a delay, announcement, or overly long
agi) between the time that he answered the phone and the time when
he actually was bridged with the caller. The consequence of this
was that if the member hung up in that interval, then proper
abandonment details would not be noted in the queue log if the caller
were to hang up at any point after the member hangup.

(closes issue ASTERISK-11950)
Reported by: ablackthorn

By: Alisher (licedey) 2010-01-06 12:46:53.000-0600

After taking some tests with Asterisk 1.4, the reason why in some cases we have to add @extension in order to make queue work is related to sip.conf configuration.

In the sip.conf configuration file, if the extension is same as username, we can omit  @extension tail in queue member configuration.


; member=SIP/3000@3000 is also ok

In case if in sip.conf extension is different from username than we must add @extension to member in order to make queue to ring the extension


; member=SIP/3000 won't work

After removing @extension tail and setting username=extension at sip.conf, the queues are working correctly with all Asterisk versions, latest 1.6 and 1.4 .

So the wrong configuration caused the problem.

By: gb_delti (gb_delti) 2010-09-14 07:48:02

We are seeing this error here too after our upgrade from Asterisk 1.4.24 to We are queuing calls to external providers that have only one number per hotline and not one number per agent. So we definitely need the member=SIP/1234@myprovider notation.

By: Russell Bryant (russell) 2011-07-27 13:28:49.254-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!