[Home]

Summary:ASTERISK-30043: Wrong party is disconnected when hook-flashing on 3-way bridge
Reporter:Josh Alberts (jalberts)Labels:
Date Opened:2022-05-03 21:14:07Date Closed:2022-06-15 11:41:00
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:16.20.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:debian on a x86_64 (Astlinux)Attachments:
Description: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.
Comments:By: Asterisk Team (asteriskteam) 2022-05-03 21:14:08.282-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: N A (InterLinked) 2022-05-04 05:53:54.888-0500

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@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@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@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@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@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@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@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@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@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.)
By: George Joseph (gjoseph) 2022-05-04 06:06:28.965-0500

Will you be fixing this yourself?

By: N A (InterLinked) 2022-05-04 06:08:46.777-0500

You can assign this to me. I already have a fix for it, I just want to verify a few things.
By: Friendly Automation (friendly-automation) 2022-06-15 11:41:01.257-0500

Change 18631 merged by Friendly Automation:
sig_analog: Fix broken three-way conferencing.

[https://gerrit.asterisk.org/c/asterisk/+/18631|https://gerrit.asterisk.org/c/asterisk/+/18631]
By: Friendly Automation (friendly-automation) 2022-06-15 12:20:15.782-0500

Change 18632 merged by Friendly Automation:
sig_analog: Fix broken three-way conferencing.

[https://gerrit.asterisk.org/c/asterisk/+/18632|https://gerrit.asterisk.org/c/asterisk/+/18632]
By: Friendly Automation (friendly-automation) 2022-06-15 12:21:25.334-0500

Change 18630 merged by Friendly Automation:
sig_analog: Fix broken three-way conferencing.

[https://gerrit.asterisk.org/c/asterisk/+/18630|https://gerrit.asterisk.org/c/asterisk/+/18630]
By: Friendly Automation (friendly-automation) 2022-06-15 13:19:06.137-0500

Change 18538 merged by Kevin Harwell:
sig_analog: Fix broken three-way conferencing.

[https://gerrit.asterisk.org/c/asterisk/+/18538|https://gerrit.asterisk.org/c/asterisk/+/18538]