Summary: | ASTERISK-26715: app_queue: Member will not receive any new calls after doing a transfer if wrapuptime = greater than 0 and using Local channel | ||||||
Reporter: | David Brillert (aragon) | Labels: | |||||
Date Opened: | 2017-01-11 15:58:15.000-0600 | Date Closed: | 2017-05-24 07:50:40 | ||||
Priority: | Major | Regression? | Yes | ||||
Status: | Closed/Complete | Components: | Applications/app_queue | ||||
Versions: | 11.25.1 13.13.1 | Frequency of Occurrence | Constant | ||||
Related Issues: |
| ||||||
Environment: | Attachments: | ( 0) bt26715onTransfer.txt ( 1) fulldebug.txt | |||||
Description: | To reproduce edit queues.conf
wrapuptime = 10 Dynamic member answers a call and transfers caller to any extension. Member will not receive a new call from queue until all parties involved in transfer hangup. Testing multiple revisions tells me that the regression was introduced between 2015-02-27 and 2016-01-31. I arrived at this conclusion by testing multiple versions of Asterisk rpms I had laying around until I could reproduce the breakage. At some point between 2015-02-27 and 2016-01-31 something introduced (in call) state in which broke agent status when wrapuptime is defined: Example: {noformat} Local/214@queue-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 2 calls (last was 578 secs ago) {noformat} The last release I am certain that wrapuptime was working properly was 11.16 Based on this additional investigation and review of the changelog it is probably this commit which caused the regression Release 11 {noformat} 2015-12-29 05:44 +0000 [1943cfc53c] Martin Tomec <tomec.martin@gmail.com> app_queue: Add member flag "in_call" to prevent reading wrong lastcall time Member lastcall time is updated later than member status. There was chance to check wrapuptime for available member with wrong (old) lastcall time. New boolean flag "in_call" is set to true right before connecting call, and reset to false after update of lastcall time. Members with "in_call" set to true are treat as unavailable. ASTERISK-19820 #close Change-Id: I1923230cf9859ee51563a8ed420a0628b4d2e500 {noformat} Release 13 {noformat} 2015-12-29 04:31 +0000 [338a8ffed6] Martin Tomec <tomec.martin@gmail.com> * app_queue: Add member flag "in_call" to prevent reading wrong lastcall time Member lastcall time is updated later than member status. There was chance to check wrapuptime for available member with wrong (old) lastcall time. New boolean flag "in_call" is set to true right before connecting call, and reset to false after update of lastcall time. Members with "in_call" set to true are treat as unavailable. ASTERISK-19820 #close Change-Id: I1923230cf9859ee51563a8ed420a0628b4d2e500 {noformat} | ||||||
Comments: | By: Asterisk Team (asteriskteam) 2017-01-11 15:58:16.779-0600 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: Rusty Newton (rnewton) 2017-01-12 09:14:45.765-0600 Thanks for the report. In addition please provide a minimal, but complete queues.conf and extensions.conf that would reproduce the issue. By: Etienne Lessard (hexanol) 2017-01-12 09:47:34.635-0600 Hi David, There seems to be some similarities with the bug I've opened a while ago: ASTERISK-26400 . The only thing being really different is how the transfer is accomplished. By: Etienne Lessard (hexanol) 2017-01-12 09:53:47.027-0600 The ticket I wanted to link to is ASTERISK-26400, I made a mistake in my last post. By: David Brillert (aragon) 2017-01-12 10:03:08.563-0600 Hi Rusty, Extensions.conf refers to a lot of verbose scripts and I am not sure what kind of configs you are looking for... But the easiest way to reproduce is simple: if wrapuptime = 0 there are no issues with member receiving any calls after transfers. if wrapuptime = 1 the member will never receive a call until channels involved in transfer are torn down. {noformat} Transfers tested are: *1 *2 One Touch DTMF PARK SIP blind SIP attended SIP semi-attended SIP PARK {noformat} Regardless of wrapuptime = 0 or 1 Member status during transfer always includes flag (in call) (not in use) while the transferred channels are up. If I quote the author of the regression 'Members with "in_call" set to true are treat as unavailable.' But during testing this statement is false since the member does receive calls after a transfer if wrapuptime = 0 and queue show does display the (in call) flag. Working queues.conf {noformat} strategy = ringall servicelevel = 60 timeout = 15 retry = 5 maxlen = weight = 0 reportholdtime = no reportwaitcall = no memberdelay = 0 timeoutrestart = no autofill = yes autopause = no ringinuse = no setinterfacevar = yes wrapuptime = 0 joinempty = penalty,invalid,unknown leavewhenempty = penalty,invalid,unknown eventwhencalled = vars eventmemberstatus = yes announce-holdtime = no announce = monitor-format = wav49 monitor-type = MixMonitor penaltymemberslimit = -1 {noformat} Affected queues.conf {noformat} strategy = ringall servicelevel = 60 timeout = 15 retry = 5 maxlen = weight = 0 reportholdtime = no reportwaitcall = no memberdelay = 0 timeoutrestart = no autofill = yes autopause = no ringinuse = no setinterfacevar = yes wrapuptime = 10 joinempty = penalty,invalid,unknown leavewhenempty = penalty,invalid,unknown eventwhencalled = vars eventmemberstatus = yes announce-holdtime = no announce = monitor-format = wav49 monitor-type = MixMonitor penaltymemberslimit = -1 {noformat} By: David Brillert (aragon) 2017-01-12 10:16:12.549-0600 Yes Etienne, there are remarkable similarities to your bug report ASTERISK-26400 I am not using AMI "Redirect". It is simple to reproduce with any type of transfer in my case. Not sure if you have tested other transfer methods when wrapuptime = 1 or greater However given that the patch in ASTERISK-19820 was committed back in December 2015 I am not surprised to see others reporting this type of app_queue behavior. This regression reminds me of the old days prior to state_interface implementation. By: Joshua C. Colp (jcolp) 2017-01-17 10:36:25.713-0600 Looking at this it appears to be the same underlying thing as ASTERISK-26400 which you've discussed. To that end I'm marking this out as a duplicate. Any progress will be tracked on ASTERISK-26400. By: David Brillert (aragon) 2017-03-10 15:32:14.190-0600 There are some subtle differences between this ticket and ASTERISK-26400 There is a patch up on the reviewboard which looks to address each issue. External redirects ASTERISK-26400 ASTERISK-26715 direct member transfers. https://gerrit.asterisk.org/#/c/5149/ When a member transfers the call directly (without using features), the device state of the member is correctly reset, but the "in call" flag is still set to true. exmaple: {noformat} master88*CLI> queue show debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 18s talktime), W:0, C:11, A:0, SL:100.0% within 60s Members: Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 11 calls (last was 19 secs ago) No Callers master88*CLI> core show channels Channel Location State Application(Data) SIP/debcomainbtn213- (None) Up AppDial((Outgoing Line)) SIP/debcomainbtn216- s@debcomainbtn-appli Up Queue(debcomainbtn-reception,t Local/214@debcomainb s@debcomainbtn-agent Up AppQueue((Outgoing Line)) Local/214@debcomainb s@macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk 4 active channels 2 of 512 max active calls ( 0.39% of capacity) master88*CLI> sip show channels Peer User/ANR Call ID Format Hold Last Message Expiry Peer 172.31.240.111 debcomainbtn216 0_2064138430@17 (ulaw) No Tx: UPDATE debcomainb 192.168.192.78 (None) 3be2ae342e97dcb (nothing) No Rx: OPTIONS <guest> 172.31.240.110 debcomainbtn213 35c30b9a6a1c852 (ulaw) No Tx: ACK debcomainb 3 active SIP dialogs {noformat} By: Asterisk Team (asteriskteam) 2017-03-10 15:32:14.561-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Sean Bright (seanbright) 2017-03-11 11:08:57.979-0600 [~aragon], are you using state interfaces with your Local queue members? I don't see it in the {{queue show}} output. If not, is the device state of the member always "Not in use" whether they are on a call or not? By: David Brillert (aragon) 2017-03-11 12:44:18.466-0600 [~seanbright] Yes, definitely using state interface. And GROUP_COUNT and callcounters=yes Here is queue show when member is on a call without any transfer. {noformat} debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 32s talktime), W:0, C:1, A:0, SL:100.0% within 60s Members: Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (In use) has taken 1 calls (last was 78865 secs ago) No Callers master88*CLI> core show channels Channel Location State Application(Data) Local/214@debcomainb s@debcomainbtn-agent Up AppQueue((Outgoing Line)) Local/214@debcomainb 214@debcomainbtn-loc Up Dial(SIP/debcomainbtn214,,tk) SIP/debcomainbtn216- s@debcomainbtn-appli Up Queue(debcomainbtn-reception,t SIP/debcomainbtn214- (None) Up AppDial((Outgoing Line)) 4 active channels core show hints 214@debcomainbtn-loc: SIP/debcomainbtn214 State:InUse Presence:Not_Set Watchers 1 {noformat} queue show when idle {noformat} debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 119s talktime), W:0, C:2, A:0, SL:100.0% within 60s Members: Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (Not in use) has taken 2 calls (last was 25 secs ago) No Callers master88*CLI> core show channels Channel Location State Application(Data) 0 active channels 0 of 512 max active calls ( 0.00% of capacity) core show hints 214@debcomainbtn-loc: SIP/debcomainbtn214 State:Idle Presence:Not_Set Watchers 1 {noformat} By: David Brillert (aragon) 2017-03-12 17:33:14.667-0500 [~seanbright] Something weird is going on because core show channels shows Local/214 is involved in a channel after it hangs up to complete the transfer. I've also reproduced this using DTMF feature code transfers. I can't tell what is going on here, but I have uploaded a full CLI fulldebug.txt trace with sip debug also enabled to show when INVITES are occurring during dial plan execution. Essentially a channel is left up after x214 transfers and I think this causes the 'in use' flag. By: Joshua C. Colp (jcolp) 2017-03-12 18:22:37.845-0500 Are you absolutely sure you are using a state interface? As [~seanbright] stated if you are not then you would see the exact behavior you are seeing - as you are transferring the Local channel, and not the caller directly, so the Local channel will remain in use after the transfer. How are you adding queue agents and what are the arguments? By: Joel Vandal (jvandal) 2017-03-12 18:36:50.979-0500 If I check on logs : AddQueueMember("SIP/debcomainbtn214-00000013", "debcomainbtn-reception,Local/214@debcomainbtn-agent/n,,,,SIP/debcomainbtn214,") in new stack And if I check on AstDB : Queue/PersistentMembers/debcomainbtn-reception : Local/214@debcomainbtn-agent/n;0;0;Local/214@debcomainbtn-agent/n;SIP/debcomainbtn214; So the State Interface must be set to SIP/debcomainbtn214 By: David Brillert (aragon) 2017-03-12 18:38:00.754-0500 Joel is my colleague, he replied for me. By: Joel Vandal (jvandal) 2017-03-12 18:46:22.024-0500 And if I check AMI to confirm that StateInterface is set : Event: QueueMember Queue: debcomainbtn-reception Name: Local/214@debcomainbtn-agent/n Location: Local/214@debcomainbtn-agent/n StateInterface: SIP/debcomainbtn214 By: Joshua C. Colp (jcolp) 2017-03-12 18:55:13.913-0500 [~jvandal] Please try removing the "," at the end of the state interface that is passed to the AddQueueMember dialplan application just for kicks. By: David Brillert (aragon) 2017-03-12 19:01:36.165-0500 Same result removing the "," debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 29s talktime), W:0, C:7, A:0, SL:100.0% within 60s Members: Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken no calls yet No Callers By: Joshua C. Colp (jcolp) 2017-03-12 19:03:29.683-0500 Then I'm afraid someone will have to dig in deeper. By: Joel Vandal (jvandal) 2017-03-12 19:12:03.231-0500 We removed all custom patch (ex. xivo_queue_skills), etc... and same issues. We are now using a plain Asterisk 13.14.0 and still have issues. I also remove the , after the state interface. By: Sean Bright (seanbright) 2017-03-13 07:41:00.162-0500 This is strange... if I run {{queue show}} I see the state interface explicitly (maybe because it's a statically defined agent?): {noformat} Members: Sean Bright (Local/Msean@ringall/n from PJSIP/sean) (ringinuse enabled) (Unavailable) has taken no calls yet ^^^^^^^^^^ {noformat} By: Joel Vandal (jvandal) 2017-03-13 08:39:53.583-0500 Sean, you see the "from ..." because the Member Name do not match the Interface name. In our case we arent using the "Member Name", it why this part of app_queues is not displayed : {noformat} ast_str_set(&out, 0, " %s", mem->membername); if (strcasecmp(mem->membername, mem->interface)) { ast_str_append(&out, 0, " (%s", mem->interface); if (!ast_strlen_zero(mem->state_interface)) { ast_str_append(&out, 0, " from %s", mem->state_interface); } ast_str_append(&out, 0, ")"); } {noformat} By: Sean Bright (seanbright) 2017-03-13 08:44:06.909-0500 [~jvandal], roger that. By: Joel Vandal (jvandal) 2017-03-13 08:53:25.030-0500 But thanks, I've been curious why I've never see the "From..." and found the explaination on the code :) To be sure that the State Interface is defined, I've check on AMI output (I see the StateInterface), I also verified on AstDB, etc. so I confirm that the State Interface is set. By: Sean Bright (seanbright) 2017-03-13 13:48:11.674-0500 [New patch uploaded|https://gerrit.asterisk.org/#/c/5151/] but I make no guarantees that it will actually ever be merged (it may or may not be a big hack). By: David Brillert (aragon) 2017-03-14 08:48:16.799-0500 I have two results. Same call flow for both tests Call flow= A = 216 calls queue = reception B = queue member logged to SIP 214 answers via queue and completes an attended SIP Transfer to C = 213 C= 213 is bridged to 216 B= idle (transfer completed) Result 1: Using https://gerrit.asterisk.org/#/c/5151/ patch set 3 and adding debug to core When 214 does the transfer we check to see if the "Redirect trigger" event is generated {noformat} ast_debug(3, "Detected redirect of queue caller channel %s\n", + caller_snapshot->name); {noformat} Is never executed We see : {noformat} [2017-03-13 14:01:42] DEBUG[19505] app_queue.c: Detected entry of caller channel SIP/gateway-00000000 into bridge e0693ed3-75b0-40f2-a03f-64a5d37983e0 [2017-03-13 14:02:14] DEBUG[19525] app_queue.c: Detected hangup of queue member channel Local/214@debcomainbtn-agent-00000000;1 {noformat} But not the transfer so we are left with channels Up which should not be. {noformat} Local/214@debcomainb s@macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk Local/214@debcomainb s@debcomainbtn-agent Up AppQueue((Outgoing Line)) {noformat} Which causes the 'in_call' flag to be true {noformat} Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 11 calls (last was 19 secs ago) No Callers {noformat} We add more debug to see where the redirect fails and see that since it not same uniqueid, not same bridge, etc... it fail {noformat} [2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL wrong bridge : 1489428881.4 - 1489428880.0 ::: 42c6bcd8-f54a-4a81-ad52-d6bdc57efffe 5b340214-af35-46ec-8b25-ff42ee41a282 [2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL left [2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL wrong bridge : 1489428884.18 - 1489428880.0 ::: f8bf135b-f9a5-4164-a3c3-97ccaf06f078 5b340214-af35-46ec-8b25-ff42ee41a282 [2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL left [2017-03-13 14:14:47] DEBUG[3142] app_queue.c: JOEL wrong bridge : 1489428881.8 - 1489428880.0 ::: 42c6bcd8-f54a-4a81-ad52-d6bdc57efffe 5b340214-af35-46ec-8b25-ff42ee41a282 {noformat} And see the failure on this function {noformat} /* Correct channel, correct bridge? */ if (strcmp(left_blob->channel->uniqueid, queue_data->caller_uniqueid) || strcmp(left_blob->bridge->uniqueid, queue_data->bridge_uniqueid)) { ao2_unlock(queue_data); return; } {noformat} Result 2: Is our tests using https://gerrit.asterisk.org/#/c/5151/ patch set 5 I don't have any CLI to report with patch set 5 but here is the summary of our findings: The patch does allow the agent to receive a call after they transfer a call and after the wrapuptime=10 But it still leaves an Up channel whiich should be torn down after a transfer or feature redirect {noformat} Local/214@debcomainb s@debcomainbtn-agent Up AppQueue((Outgoing Line)) Local/214@debcomainb s@macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk {noformat} So patch set 5 fixes the reported issue but does not appear to fix root cause which is a failure to execute the redirect event. By: Sean Bright (seanbright) 2017-03-14 09:10:38.161-0500 There is a lot of noise in your most recent comment, but what I am getting from it is: Using the latest patch on the gerrit review, after a transfer there are still Local channels that you believe should not be there. Does that sum it up? By: Sean Bright (seanbright) 2017-03-14 09:16:00.055-0500 Without the patch, what happens after a "SIP transfer" if your queue member has a wrap up time of 0? By: David Brillert (aragon) 2017-03-14 09:24:46.587-0500 [~seanbright] Yes, we still have a channel Up which IMHO should not be. Afer the agent extension transfers the channel is not torn down on a redirect. Because the redirect fails on function due to different uniqueid and bridge {noformat} /* Correct channel, correct bridge? */ if (strcmp(left_blob->channel->uniqueid, queue_data->caller_uniqueid) || strcmp(left_blob->bridge->uniqueid, queue_data->bridge_uniqueid)) { ao2_unlock(queue_data); return; } {noformat} Without patches and if wrapuptime=0 The agent transfers the caller but can still receive a new call after the transfer and before the transferred channels are hung up. But the 'in_call' flag is true And the core show channels still shows the agent extension in a channel {noformat} debcomainbtn-reception has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 25s talktime), W:0, C:9, A:0, SL:100.0% within 60s Members: Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 9 calls (last was 177 secs ago) No Callers master88*CLI> core show channels Channel Location State Application(Data) SIP/debcomainbtn213- (None) Up AppDial((Outgoing Line)) Local/214@debcomainb s@macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk Local/214@debcomainb s@debcomainbtn-agent Up AppQueue((Outgoing Line)) SIP/debcomainbtn216- s@debcomainbtn-appli Up Queue(debcomainbtn-reception,t 4 active channels 2 of 512 max active calls ( 0.39% of capacity) master88*CLI> sip show channels Peer User/ANR Call ID Format Hold Last Message Expiry Peer 192.168.192.78 (None) 6e0d1264723bc95 (nothing) No Rx: OPTIONS <guest> 172.31.240.111 debcomainbtn216 0_1966151905@17 (ulaw) No Tx: UPDATE debcomainb 172.31.240.110 debcomainbtn213 0715e9a879d7be6 (ulaw) No Tx: UPDATE debcomainb 3 active SIP dialogs {noformat} As a workaround we set wraptime=0 on all queues so that agents continue to receive calls after transferring callers to other extensions. So we cannot use any wrapuptime Another downside is we check channel status to create ACD reports and Agent in use status and these reports are broken because the agent appears to be on a channel. By: Sean Bright (seanbright) 2017-03-14 09:41:03.654-0500 Again there is a lot of noise in your comment (I don't need/want code snippets or CLI output), can you just answer Yes or No to the following questions? # *Without* the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away? # *With* the patch from gerrit, if wrapuptime is greater than 0 and a "sip transfer" is performed, the Local channels stay? Also, considering the code analysis you have done, could you please attach a patch that resolves the problem completely in your environment? I'd be happy to integrate your suggested changes. By: David Brillert (aragon) 2017-03-14 09:49:41.119-0500 1. Without the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away? No 2. With the patch from gerrit, if wrapuptime is greater than 0 and a "sip transfer" is performed, the Local channels stay? Yes Sorry we cannot write a patch, not enough coders with C mojo. By: Sean Bright (seanbright) 2017-03-14 09:53:53.164-0500 {quote} Without the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away? No {quote} OK. So why is that a problem WITH the patch when wrapuptime is greater than 0? By: David Brillert (aragon) 2017-03-14 10:11:27.765-0500 Because with the patch we still have invalid channel status due to the failed redirect. Patch set 5 only masks the problem. The invalid channel affects CDR reports, agent in use status, call durations etc... For what it's worth I did testing and if I do an AMI redirect the reviewboard patch set 3 does fix and tear down the agent channel on the redirect ASTERISK-26400 By: David Brillert (aragon) 2017-03-14 10:19:15.749-0500 Without the patch from gerrit, if wrapuptime is 0 and a "sip transfer" is performed, the Local channels go away? No This means that we still see the ghost channel. Let me try to summarize again since I guess there is a miscommunication still: With or without patches and regardless if wrapuptime =0 or wrapuptime = greater than 0 in_call is always true after a local transfer Local/214@debcomainbtn-agent/n (ringinuse disabled) (dynamic) (in call) (Not in use) has taken 9 calls (last was 177 secs ago) No Callers Agent still shows in a channel after the transfer (ghost channel). Local/214@debcomainb s@macro-debcomainbtn Up Dial(SIP/debcomainbtn213,20,tk Local/214@debcomainb s@debcomainbtn-agent Up AppQueue((Outgoing Line)) It just so happens that if wrapuptime = 0 that agent can still receive a call without patches (fluke) By: Andrej (tekach) 2017-03-22 03:17:14.612-0500 Hi everybody, is there any progress with this issue? Bug is seriously impacting our call center work processes (I originally opened ASTERISK-26757). If this helps and is acceptable, I am offering a bounty for solving this bug (500€). Sincere apologies if this is not appropriate, I am new to this. Thanks, Andrej By: Joshua C. Colp (jcolp) 2017-03-22 05:13:19.364-0500 Any updates will be posted on this issue. As there is noone assigned there is noone working on it. The process for a bounty is also documented on the wiki[1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties By: Friendly Automation (friendly-automation) 2017-05-24 07:50:41.094-0500 Change 5640 merged by Jenkins2: app_queue: Fix members showing as being in call when not. [https://gerrit.asterisk.org/5640|https://gerrit.asterisk.org/5640] By: Friendly Automation (friendly-automation) 2017-05-24 08:40:09.362-0500 Change 5639 merged by Jenkins2: app_queue: Fix members showing as being in call when not. [https://gerrit.asterisk.org/5639|https://gerrit.asterisk.org/5639] By: Friendly Automation (friendly-automation) 2017-05-24 09:41:37.130-0500 Change 5641 merged by Joshua Colp: app_queue: Fix members showing as being in call when not. [https://gerrit.asterisk.org/5641|https://gerrit.asterisk.org/5641] By: David Brillert (aragon) 2017-05-25 10:20:29.695-0500 After applying https://gerrit.asterisk.org/#/c/5639/ to Asterisk 13 SVN I get a segfault each time an agent answers a call on their Polycom phone and tries a SIP attended transfer to any other extension. By: Asterisk Team (asteriskteam) 2017-05-25 10:20:30.091-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: David Brillert (aragon) 2017-05-25 10:57:07.757-0500 Attaching back trace file bt26715onTransfer.txt By: Joshua C. Colp (jcolp) 2017-05-25 11:15:41.393-0500 I just did this with 13 from git with no problems. You're going to need to give more details in order to reproduce it: 1. What specific git revision did you apply it to? 2. Are there other callers in the queue? 3. Are Local channels involved? 4. What is the queue configuration? By: David Brillert (aragon) 2017-05-25 11:22:52.535-0500 Looks like I did not apply the patch correctly. After re-applying the patch there is no more crashing during a transfer and the originally reported issue is also resolved. Sorry for the noise. |