[asterisk-dev] MOH still playing after attended transfer

[Jason TOMLINSON]

OK, thanks

Replacing ast_moh_stop(other->chan) with ast_queue_control(other->chan, AST_CONTROL_UNHOLD) also works, so I’ll go with that.
I’ll submit a patch as soon as I’m able (just signed the licence agreement)


De : asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] De la part de Kevin Harwell
Envoyé : mardi 1 août 2017 01:17
À : Asterisk Developers Mailing List
Objet : Re: [asterisk-dev] MOH still playing after attended transfer

On Fri, Jul 28, 2017 at 3:10 AM, Jason TOMLINSON <j.tomlinson at isi-com.com<mailto: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/20170801/c98ea608/attachment-0001.html>