[asterisk-dev] MOH still playing after attended transfer

[Kevin Harwell]

On Fri, Jul 28, 2017 at 3:10 AM, Jason TOMLINSON <j.tomlinson at isi-com.com>
wrote:

> Hi,
>

Greetings!


>
>
> I raised an issue [ https://issues.asterisk.org/jira/browse/ASTERISK-27071
> ] where music on hold keeps playing on the held channel after an attended
> transfer on asterisk 13
>
> It affects calls coming in though a trunk from an alcatel pbx, but after
> digging though the code it seems likely that it might affect any trunk in
> general which requests an attended transfer via replaces
>
>
>
> The invite/replaces arrives at chan_sip.c -> handle_invite_replaces which
> does its thing to do the transfer, but nowhere (it seems) is the moh
> stopped on the waiting channel (unlike in asterisk 11 pre-bridge changes
> where all channels are explicitely stopped).
>
>
>
> So, after the transfer is done and we get the bridge concerned I added (in
> the if(bridge){…} block near the end):
>
>                 struct ast_bridge_channel *other;
>
>                 AST_LIST_TRAVERSE(&bridge->channels, other, entry) {
>
>                                ast_moh_stop(other->chan); /*attended trf
> done, so stop all moh*/
>
>                 }
>
>
>
> Which works.
>
>
>
> So, is this a good way to go? Ie, is this the correct place to stop moh,
> and/or should I be queuing up an AST_CONTROL_UNHOLD frame instead on the
> channels?
>

The bulk of the transfer handling code is now done through the bridging
framework (Asterisk 12+). My first inclination was going to be say the code
may need to be modified somewhere within the bridging framework itself in
order to handle this case. That way it is fixed in one place and other
users of the bridging framework are fixed as well.

>From what I can tell by glancing at the code it appears a modification
would need to be done within ast_bridge_impart[_interal] if you went that
route. However, I am unsure of the possible side effects as this function
is called from several other places (and some of those other places in turn
stop the moh themselves, so there may be a reason why it was not done at
the bridge_impart level). If you are feeling adventurous it might be worth
looking into though.

That all being said the easier route and the fix with less side effects is
the one you propose (I believe res_pjsip_refer suffers from this same
problem so it would be good to fix there as well too). I do lean toward
queuing up an AST_CONTROL_UNHOLD frame instead of calling ast_moh_stop
directly though.

Whatever you decide I would go ahead and push up a patch to Asterisk's
Gerrit server[1]. Once pushed up for code review others will have a better
idea of your proposed changes and will comment appropriately.

[1] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage


>
>
> Thanks for any advice!
>
>
>
> Jason
>
>
>
>
>

Hope that helps and thanks for your contribution!

-- 

Kevin Harwell
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170731/7a3ec712/attachment.html>