| Summary: | ASTERISK-26534: Queue member stuck in state Not is use and in call after channel redirect to another extension. | ||||
| Reporter: | Morten Hansen (mfk@itxnorge.no) | Labels: | |||
| Date Opened: | 2016-10-30 17:28:45 | Date Closed: | 2016-11-03 09:26:54 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Applications/app_queue | ||
| Versions: | 13.7.2 13.11.2 13.12.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Ubuntu 16.04 LTS | Attachments: | |||
| Description: | Running Asterisk 13.12.1.
After blind transferring a call received from app_queue, the member state is stuck in not in use and in call. The state is probably in call, because of the channel running AppQueue is still alive. After channel redirect, this channel should be dead. The method handle_blind_transfer in app_queue is never executed. After channel redirect, core show channels verbose gives me 3 channels, but the summary says 2 active channels. All 3 channels are revoked after hang up. The member will not be able to receive new calls before this transferred call ends. Configuration issue or a bug? Same issue on Asterisk 13.7, 13.11 and 13.12.1. {noformat} -- Executing [4765353406@from-trunk-test:1] Verbose("SIP/xyz-trunk-prod-x-00000003", "3, Channel: SIP/xyz-trunk-prod-x-00000003") in new stack -- Channel: SIP/xyz-trunk-prod-x-00000003 -- Executing [4765353406@from-trunk-test:2] Queue("SIP/xyz-trunk-prod-x-00000003", "xyzvakt,tT") in new stack -- Started music on hold, class 'classical-piano', on channel 'SIP/xyz-trunk-prod-x-00000003' == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 -- Called SIP/50104 -- SIP/50104-00000004 is ringing -- SIP/50104-00000004 answered SIP/xyz-trunk-prod-x-00000003 -- Stopped music on hold on SIP/xyz-trunk-prod-x-00000003 -- Channel SIP/50104-00000004 joined 'simple_bridge' basic-bridge <2f3b774c-fb1a-4299-9d8e-d58ad6a2ef02> -- Channel SIP/xyz-trunk-prod-x-00000003 joined 'simple_bridge' basic-bridge <2f3b774c-fb1a-4299-9d8e-d58ad6a2ef02> > 0x7ff9d4005f50 -- Probation passed - setting RTP source address to 193.215.16.22:31102 > 0x7ff9c0021480 -- Probation passed - setting RTP source address to 83.143.85.110:18938 xyz-kvm-02-voipdev*CLI> core show channels verbose Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID SIP/50104-00000004 default 4765353406 1 Up AppQueue (Outgoing Line) 73206085 00:00:04 50104 2f3b774c-fb1a-4299-9 SIP/xyz-trunk-prod-i from-trunk-test 4765353406 2 Up Queue xyzvakt,tT 95959595 00:00:04 50104 2f3b774c-fb1a-4299-9 2 active channels 1 active call 2 calls processed xyz-kvm-02-voipdev*CLI> channel redirect SIP/xyz-trunk-prod-x-00000003 transfer-to-test,50098,1 Channel 'SIP/xyz-trunk-prod-x-00000003' successfully redirected to transfer-to-test,50098,1 -- Channel SIP/xyz-trunk-prod-x-00000003 left 'simple_bridge' basic-bridge <2f3b774c-fb1a-4299-9d8e-d58ad6a2ef02> -- Channel SIP/50104-00000004 left 'simple_bridge' basic-bridge <2f3b774c-fb1a-4299-9d8e-d58ad6a2ef02> -- Executing [50098@transfer-to-test:1] Dial("SIP/xyz-trunk-prod-x-00000003", "SIP/50098") in new stack == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 -- Called SIP/50098 -- SIP/50098-00000005 is ringing -- SIP/50098-00000005 answered SIP/xyz-trunk-prod-x-00000003 -- Channel SIP/50098-00000005 joined 'simple_bridge' basic-bridge <c919c4b1-3156-4238-8ba2-fb53a1ffd8b0> -- Channel SIP/xyz-trunk-prod-x-00000003 joined 'simple_bridge' basic-bridge <c919c4b1-3156-4238-8ba2-fb53a1ffd8b0> > 0x7ff9d40149d0 -- Probation passed - setting RTP source address to 193.215.16.22:19368 xyz-kvm-02-voipdev*CLI> core show channels verbose Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID SIP/50104-00000004 default 4765353406 1 Up AppQueue (Outgoing Line) 73206085 00:00:18 50104 SIP/50098-00000005 default 1 Up AppDial (Outgoing Line) 73969355 00:00:06 50104 c919c4b1-3156-4238-8 SIP/xyz-trunk-prod-i transfer-to-test 50098 1 Up Dial SIP/50098 95959595 00:00:18 50104 c919c4b1-3156-4238-8 2 active channels 1 active call 2 calls processed xyz-kvm-02-voipdev*CLI> queue show it xyz xyzvakt xyz-kvm-02-voipdev*CLI> queue show xyzvakt xyzvakt has 0 calls (max unlimited) in 'rrmemory' strategy (0s holdtime, 31s talktime), W:1, C:1, A:0, SL:100.0% within 0s Members: SIP/50104 (ringinuse enabled) (dynamic) (in call) (Not in use) has taken 1 calls (last was 836 secs ago) {noformat} | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-10-30 17:28:45.585-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Etienne Lessard (hexanol) 2016-10-31 11:30:30.887-0500 This looks at least partially similar to ASTERISK-26400. By: Rusty Newton (rnewton) 2016-11-03 09:26:54.509-0500 Does look like it duplicates ASTERISK-26400. [~mfk@itxnorge.no] please add any additional information, (maybe queue configuration details) onto ASTERISK-26400. That issue will be used to track. | ||||