| 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-0600 | Date Closed: | 2011-07-27 13:28:56 |
| Priority: | Major | Regression? | Yes |
| Status: | Closed/Complete | Components: | Applications/app_queue |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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: http://www.freepbx.org/forum/freepbx/installation/no-ringing-to-external-caller-with-queue 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 ****** ADDITIONAL INFORMATION ****** localhost*CLI> sip show peers Name/username Host Dyn Nat ACL Port Status 3005/3005 192.168.1.229 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> localhost*CLI> core show channels Channel Location State Application(Data) 0 active channels 0 active calls 9 calls processed localhost*CLI> 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. ------<1>------------ sip.conf [3000] username=3000 type=peer queue.conf member=SIP/3000 ; 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 ------<2>------------ sip.conf [3000] username=Test type=peer queue.conf member=SIP/3000@3000 ; member=SIP/3000 won't work ------<1>------------ 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 1.6.2.11. 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! | ||