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 : [email protected] [mailto:[email protected]] 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 <[email protected]<mailto:[email protected]>> 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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
