[asterisk-dev] UNHOLD the other channel in a bridge when swapping is completed

[Joshua C. Colp]

On Sun, Dec 13, 2020 at 6:33 AM Ahmed Fouad <afouad at gmail.com> wrote:

> Hi Jousha,
>
> No changes were made there the caller when clicks the transfer button send
> INACTIVE then start the REFER process , the transfer completed fine but the
> call in still in inactive state.
> I can't change the caller behaviour so I had to change the Asterisk code a
> few minutes ago :)
>
> found my way through in bridge_channel.c
>
> *ast_set2_flag(&bridge->feature_flags, dissolve,
> AST_BRIDGE_FLAG_DISSOLVE_EMPTY);*
>
> + ch1 = AST_LIST_FIRST(&bridge->channels);
> + if (ast_channel_hold_state(ch1->chan) == AST_CONTROL_HOLD ) {
> + ast_indicate(ch1->chan, AST_CONTROL_UNHOLD);
> +}
>
> This will happen only when swapping channels so it won't affect the normal
> bridge operations and of course I'd like to get your input if there a
> better place to have this patch.
>

There is not enough context or information for me to be able to answer
that. You'd need to describe the scenario and conditions more and be
specific about which channel is experiencing the issue. With an attended
transfer there's actually 4 channels involved and their state. The code I
linked previously is supposed to unhold the appropriate channels, so if
it's not then understanding why it isn't - or if there's somehow another
channel involved - would be the thing to do. Is this experienced with main
Asterisk 16? If so then filing an issue[1] with SIP traces and full console
log would be appropriate.

[1] https://issues.asterisk.org/jira

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201213/b30b0421/attachment-0001.html>