[asterisk-bugs] [JIRA] (ASTERISK-30043) Wrong party is disconnected when hook-flashing on 3-way bridge
N A (JIRA)
noreply at issues.asterisk.org
Wed May 4 05:55:40 CDT 2022
[ https://issues.asterisk.org/jira/browse/ASTERISK-30043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259077#comment-259077 ]
N A commented on ASTERISK-30043:
--------------------------------
Step #1 can be amended in that it doesn't matter what tech the calls are using. This happens even with native DAHDI to DAHDI calls.
Here is some debug for this scenario:
Flash to conference in 3-way AFTER answer (correct):
{noformat}
Connected to Asterisk 18.6.0 currently running on debian (pid = 7000)
[May 3 17:25:12] -- Executing [204 at from-internal:1] Goto("DAHDI/5-1", "ring,4,1") in new stack
[May 3 17:25:12] -- Goto (ring,4,1)
[May 3 17:25:13] -- Executing [4 at ring:1] NoOp("DAHDI/5-1", "Pres: allowed_not_screened / Num Pres: allowed_not_screened / Name Pres: allowed_not_screened") in new stack
[May 3 17:25:13] -- Executing [4 at ring:2] Dial("DAHDI/5-1", "DAHDI/4") in new stack
[May 3 17:25:13] -- Called DAHDI/4
[May 3 17:25:13] -- DAHDI/4-1 is ringing
[May 3 17:25:13] -- DAHDI/4-1 answered DAHDI/5-1
[May 3 17:25:13] -- Channel DAHDI/4-1 joined 'simple_bridge' basic-bridge <0f134609-6065-4d04-b0ce-cd28db39de05>
[May 3 17:25:13] -- Channel DAHDI/5-1 joined 'simple_bridge' basic-bridge <0f134609-6065-4d04-b0ce-cd28db39de05>
[May 3 17:25:17] -- Starting simple switch on 'DAHDI/5-2'
[May 3 17:25:17] -- Started three way call on channel 5
[May 3 17:25:17] -- Started music on hold, class 'default', on channel 'DAHDI/4-1'
[May 3 17:25:20] -- Hanging up on 'DAHDI/5-2'
[May 3 17:25:20] -- Hungup 'DAHDI/5-2'
[May 3 17:25:21] -- Stopped music on hold on DAHDI/4-1
[May 3 17:25:35] -- Starting simple switch on 'DAHDI/5-2'
[May 3 17:25:35] -- Started three way call on channel 5
[May 3 17:25:35] -- Started music on hold, class 'default', on channel 'DAHDI/4-1'
[May 3 17:25:43] -- Executing [209 at from-internal:1] Goto("DAHDI/5-2", "ring,9,1") in new stack
[May 3 17:25:43] -- Goto (ring,9,1)
[May 3 17:25:43] -- Executing [9 at ring:1] NoOp("DAHDI/5-2", "Pres: allowed_not_screened / Num Pres: allowed_not_screened / Name Pres: allowed_not_screened") in new stack
[May 3 17:25:43] -- Executing [9 at ring:2] Dial("DAHDI/5-2", "DAHDI/9") in new stack
[May 3 17:25:43] -- Called DAHDI/9
[May 3 17:25:43] -- DAHDI/9-1 is ringing
[May 3 17:25:45] -- DAHDI/9-1 is ringing
[May 3 17:25:47] -- DAHDI/9-1 answered DAHDI/5-2
[May 3 17:25:47] -- Channel DAHDI/9-1 joined 'simple_bridge' basic-bridge <1b6f1c9d-acba-4d35-a748-b1ddaafd88f1>
[May 3 17:25:47] -- Channel DAHDI/5-2 joined 'simple_bridge' basic-bridge <1b6f1c9d-acba-4d35-a748-b1ddaafd88f1>
[May 3 17:25:50] -- Building conference call with DAHDI/5-1 and DAHDI/5-2
[May 3 17:25:51] -- Stopped music on hold on DAHDI/4-1
[May 3 17:25:57] -- Dropping three-way call on DAHDI/5-2
[May 3 17:25:57] -- Channel DAHDI/5-2 left 'simple_bridge' basic-bridge <1b6f1c9d-acba-4d35-a748-b1ddaafd88f1>
[May 3 17:25:57] -- Channel DAHDI/9-1 left 'simple_bridge' basic-bridge <1b6f1c9d-acba-4d35-a748-b1ddaafd88f1>
[May 3 17:25:57] -- Hanging up on 'DAHDI/9-1'
[May 3 17:25:57] -- Hungup 'DAHDI/9-1'
[May 3 17:25:57] == Spawn extension (ring, 9, 2) exited non-zero on 'DAHDI/5-2'
[May 3 17:25:57] -- Hanging up on 'DAHDI/5-2'
[May 3 17:25:57] -- Hungup 'DAHDI/5-2'
{noformat}
Flash to conference in 3-way BEFORE answer (buggy):
{noformat}
[May 3 17:26:06] -- Starting simple switch on 'DAHDI/5-2'
[May 3 17:26:06] -- Started three way call on channel 5
[May 3 17:26:06] -- Started music on hold, class 'default', on channel 'DAHDI/4-1'
[May 3 17:26:13] -- Executing [209 at from-internal:1] Goto("DAHDI/5-2", "ring,9,1") in new stack
[May 3 17:26:13] -- Goto (ring,9,1)
[May 3 17:26:13] -- Executing [9 at ring:1] NoOp("DAHDI/5-2", "Pres: allowed_not_screened / Num Pres: allowed_not_screened / Name Pres: allowed_not_screened") in new stack
[May 3 17:26:13] -- Executing [9 at ring:2] Dial("DAHDI/5-2", "DAHDI/9") in new stack
[May 3 17:26:13] -- Called DAHDI/9
[May 3 17:26:13] -- DAHDI/9-1 is ringing
[May 3 17:26:15] -- DAHDI/9-1 is ringing
[May 3 17:26:16] -- Building conference call with DAHDI/5-1 and DAHDI/5-2
[May 3 17:26:16] -- Stopped music on hold on DAHDI/4-1
[May 3 17:26:19] -- DAHDI/9-1 answered DAHDI/5-2
[May 3 17:26:20] -- Channel DAHDI/9-1 joined 'simple_bridge' basic-bridge <673a0f78-9b92-43ec-8d82-66f6ff6f24cd>
[May 3 17:26:20] -- Channel DAHDI/5-2 joined 'simple_bridge' basic-bridge <673a0f78-9b92-43ec-8d82-66f6ff6f24cd>
[May 3 17:26:25] -- Dropping three-way call on DAHDI/5-1
[May 3 17:26:26] -- Channel DAHDI/5-1 left 'simple_bridge' basic-bridge <0f134609-6065-4d04-b0ce-cd28db39de05>
[May 3 17:26:26] -- Channel DAHDI/4-1 left 'simple_bridge' basic-bridge <0f134609-6065-4d04-b0ce-cd28db39de05>
[May 3 17:26:26] -- Hanging up on 'DAHDI/4-1'
[May 3 17:26:26] -- Hungup 'DAHDI/4-1'
[May 3 17:26:26] == Spawn extension (ring, 4, 2) exited non-zero on 'DAHDI/5-1'
[May 3 17:26:26] -- Hanging up on 'DAHDI/5-1'
[May 3 17:26:26] -- Hungup 'DAHDI/5-1'
{noformat}
Correct scenario:
{noformat}
[May 3 18:05:02] -- Building conference call with DAHDI/5-1 and DAHDI/5-2
[May 3 18:05:02] -- Stopped music on hold on DAHDI/4-1
debian*CLI> dahdi show channel 5
...
Owner: DAHDI/5-1
Real: DAHDI/5-1 (Confed)
Callwait: <None>
Threeway: DAHDI/5-2 (Confed)
{noformat}
Buggy scenario:
{noformat}
debian*CLI> dahdi show channel 5
...
Owner: DAHDI/5-2
Real: DAHDI/5-2 (Confed)
Callwait: <None>
Threeway: DAHDI/5-1 (Confed)
...
[May 3 18:05:49] -- Dropping three-way call on DAHDI/5-1
[May 3 18:05:49] -- Channel DAHDI/5-1 left 'simple_bridge' basic-bridge <5b3e8f44-e4b9-4918-afcb-6874bcffa86c>
[May 3 18:05:49] -- Channel DAHDI/4-1 left 'simple_bridge' basic-bridge <5b3e8f44-e4b9-4918-afcb-6874bcffa86c>
[May 3 18:05:49] -- Hanging up on 'DAHDI/4-1'
[May 3 18:05:49] -- Hungup 'DAHDI/4-1'
[May 3 18:05:49] == Spawn extension (ring, 4, 2) exited non-zero on 'DAHDI/5-1'
[May 3 18:05:49] -- Hanging up on 'DAHDI/5-1'
[May 3 18:05:49] -- Hungup 'DAHDI/5-1'
debian*CLI> dahdi show channel 5
...
Owner: DAHDI/5-2
Real: DAHDI/5-2
Callwait: <None>
Threeway: <None>
{noformat}
Here is the way that good calls work.
Using 1 to refer to DAHDI/5-1 and 2 to refer to DAHDI/5-1.
When in the first call, only 1 exists.
Flashing to start a 3-way call means that 2 is the owner/real and 1 is the 3-way.
If the calls are conferenced post-answer, 1 is swapped back to owner/real and 2 becomes the 3-way (correct).
If done before answer, this swap never happens, so 2 remains the owner/real. The result is that when we kick the third party, we actually kick 1, which is still in the 3-way slot.
Hence, the problem is we should be swapped the three-way subchannel back if conferencing occurs before answer, but this isn't being done. This is what's done for instance if you cancel a 3-way call that gets aborted:
{noformat}
[May 3 17:41:13] -- Dumping incomplete call on DAHDI/5-1
[May 3 17:41:13] DEBUG[7233][C-0000000e]: sig_analog.c:360 analog_swap_subs: Swapping 2 and 0
{noformat}
The actual cause seems to be quite trivial. It's just some logic issues in sig_analog, when determine if subs should be swapped when building the conference. (The bug doesn't occur at deconference time, as shown above.)
> Wrong party is disconnected when hook-flashing on 3-way bridge
> --------------------------------------------------------------
>
> Key: ASTERISK-30043
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-30043
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_dahdi
> Affects Versions: 16.20.0
> Environment: debian on a x86_64 (Astlinux)
> Reporter: Josh Alberts
>
> The wrong party is disconnected when hook-flashing on 3-way bridge.
> Steps to consistently reproduce this issue from a Dahdi FXO Kewlstart channel (but I believe it also happens on other FXO signalling types as well):
> 1) Establish a PJSIP or IAX call (it doesn't matter if the Dahdi channel places or receives the call. I'm not using other channel types so I can't say what happens on those).
> 2) Flash the hook switch on the Dahdi channel and get a dial tone
> 3) Dial a number to add as a 3-way call. Flash BEFORE the third party answers (this is key)
> 4) After the third party answers, flash the hookswitch
> 5) The Dahdi channel is now left with the third party. The original party is now disconnected.
> This behavior is incorrect. The expected behavior is to disconnect the third party and keep the bridge between the original parties. The expected behavior occurs when you do step 3 but wait to flash back until AFTER the third party answers.
> I consider this behavior to be incorrect because I don't know of any other PBX or CO Switch that behaves this way. At the very least, the behavior should be consistent regardless of whether the Dahdi channel flashes before or after the third party answers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list