<div>I believe your approach to be correct - still it is a pity that you have no way to trigger the dialplan when a relevant event happens. Maybe (but I really have no idea if this is feasible) there is a way to change res_musiconhold to trigger an event when the MOH status is changed? running an external AMI server (though not very complex) seems a bit overkill and has no direct integration with the rest of the dialplan....<br>
</div><div>l.</div><br><div class="gmail_quote">2012/8/31 Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">During a call hold the call is still in a bridge and can't really execute the dialplan without serious effects. Call hold is just a media state.<div><br></div><div>Brainstorming, we could implement a function where a call hold breaks the bridge and each call leg goes back to the dialplan (HOLD_CONTEXT) to do some cool things instead of being on hold. The problem then is what unhold means and how to explain to the phones (that are on hold state) what you want to do.</div>
<div><br></div><div>Better would be to develop an AMI client that makes the decision for you on what you want to do with the call.</div><div><br></div><div>/O<br></div></div></blockquote></div><br clear="all"><br>-- <br><div>
Loway - home of QueueMetrics - <a href="http://queuemetrics.com" target="_blank">http://queuemetrics.com</a><br></div><div> Test-drive WombatDialer beta @ <a href="http://wombatdialer.com" target="_blank">http://wombatdialer.com</a>
</div><br>