[asterisk-bugs] [JIRA] (ASTERISK-26101) [patch] Bridge: Channel is not unheld in attended transfer

[Niclas Larsson (JIRA)]

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

Niclas Larsson edited comment on ASTERISK-26101 at 6/10/16 7:42 AM:
--------------------------------------------------------------------

Done. One thing though, in 

{code}
static enum attended_transfer_state double_checking_exit(struct attended_transfer_properties *props,
                enum attended_transfer_stimulus stimulus)`
{code}

there is

{code}
        case STIMULUS_DTMF_ATXFER_SWAP:
                hold(props->transferer);
                bridge_move(props->target_bridge, props->transferee_bridge, props->transferer, NULL);
                unhold(props->transferer);
                return TRANSFER_CONSULTING;
{code}

which will cause the patch to unhold a second time. Maybe it's better to unhold directly in the case statement?


was (Author: edgesystems):
Done. One thing though, in 

{code}
static enum attended_transfer_state double_checking_exit(struct attended_transfer_properties *props,
                enum attended_transfer_stimulus stimulus)`
{code}

there is

{code}
        case STIMULUS_DTMF_ATXFER_SWAP:
                hold(props->transferer);
                bridge_move(props->target_bridge, props->transferee_bridge, props->transferer, NULL);
                unhold(props->transferer);
                return TRANSFER_CONSULTING;
{code}

which will cause the patch to unhold a second time.

> [patch] Bridge: Channel is not unheld in attended transfer
> ----------------------------------------------------------
>
>                 Key: ASTERISK-26101
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26101
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging/bridge_basic
>    Affects Versions: 13.9.0
>         Environment: Debian 7.10
>            Reporter: Niclas Larsson
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: atxfer.patch
>
>
> 1. A calls B
> 2. B starts a atxfer to C
> 3. A => moh, B => hold
> 4. C answers
> 5. A hung up
> 6. B and C is still talking (and the atxfer is aborted) but B is still on hold
> Shouldn't B be unholded as soon as the channel starts dialing or at least when C answers?
> The following patch solves the problem (when C answers) but I'm not quite sure if it's the right place/thing to do.
> Inline patch removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)