[asterisk-bugs] [JIRA] (ASTERISK-30043) Wrong party is disconnected when hook-flashing on 3-way bridge

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-30043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259499#comment-259499 ] 

Friendly Automation commented on ASTERISK-30043:
------------------------------------------------

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]

> 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
>            Assignee: N A
>
> 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)