<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 28, 2017 at 3:10 AM, Jason TOMLINSON <span dir="ltr"><<a href="mailto:j.tomlinson@isi-com.com" target="_blank">j.tomlinson@isi-com.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="FR">
<div class="gmail-m_-845299529193221296WordSection1">
<p class="MsoNormal">Hi,</p></div></div></blockquote><div><br></div><div>Greetings!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-845299529193221296WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">I raised an issue [ <a href="https://issues.asterisk.org/jira/browse/ASTERISK-27071" target="_blank">
<span style="color:windowtext">https://issues.asterisk.org/<wbr>jira/browse/ASTERISK-27071</span></a> ] where music on hold keeps playing on the held channel after an attended transfer on asterisk 13<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">So, after the transfer is done and we get the bridge concerned I added (in the if(bridge){…} block near the end):<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"> struct ast_bridge_channel *other;<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"> AST_LIST_TRAVERSE(&bridge-><wbr>channels, other, entry) {<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"> ast_moh_stop(other->chan); /*attended trf done, so stop all moh*/<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"> }<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Which works.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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?</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>[1] <a href="https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage">https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-845299529193221296WordSection1"><p class="MsoNormal"><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks for any advice!<span class="gmail-HOEnZb"><font color="#888888"><u></u><u></u></font></span></span></p><span class="gmail-HOEnZb"><font color="#888888">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Jason<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</font></span></div>
</div>
</blockquote></div><br clear="all"><div>Hope that helps and thanks for your contribution!</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><pre style="padding:2px;border:1px solid rgb(114,99,77);background-color:rgb(238,238,238);color:rgb(0,0,0);overflow:auto">Kevin Harwell
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></pre></div></div>
</div></div>