<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Shane</div><div><br class="webkit-block-placeholder"></div>yes, with verbose activated, I get something like this:<div><br class="webkit-block-placeholder"></div><div>starting Music on hold for Channel SIP/XXX (the local caller sip side) with the class specified in sip.conf.</div><div><br></div><div>With zap span&nbsp;debugging&nbsp;enabled, I see the bridged zap channel&nbsp;receives&nbsp;"REMOTE HOLD" notification just before the moh starts.</div><div><br class="webkit-block-placeholder"></div><div>That sounds like a nice feature&nbsp;between&nbsp;enterprise servers, but not so good between different companies of course.</div><div><br class="webkit-block-placeholder"></div><div>I wonder if this is not a side effect of the (relatively new ?) "mohinterpret=passtrough" option. That would be nice to have a "mohinterpret=disable" &nbsp;in fact:).</div><div><br class="webkit-block-placeholder"></div><div>Thank you</div><div><br class="webkit-block-placeholder"></div><div>Regards,</div><div>Gaetan</div><div><br class="webkit-block-placeholder"></div><div><br><div><div>On 07/01/2008, at 21:28, Shane Spencer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">So, watching the asterisk console with full debug on shows something<br>about "Starting Music On Hold for Channel xx/yy-zz"?<br><br>Shane<br><br>On Jan 7, 2008 11:00 AM, Gaëtan Minet &lt;<a href="mailto:gminet@easynet.be">gminet@easynet.be</a>&gt; wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Nobody has an Idea ? Should I try and fill a bug report (or feature request<br></blockquote><blockquote type="cite">?) at Digium &nbsp;?<br></blockquote><blockquote type="cite">The only solution I personally see is a patch in the source.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Gaetan<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 04/01/2008, at 23:26, Gaëtan Minet wrote:<br></blockquote><blockquote type="cite">Hi everybody<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We have a strange problem with several asterisk servers (Version<br></blockquote><blockquote type="cite">1.4.11) using PRI cards (tied to telco here in Belgium).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Indeed we noticed that whenever a local user places an outgoing call<br></blockquote><blockquote type="cite">through the PRI (and telco) to another IPBX (tied to telco using BRI<br></blockquote><blockquote type="cite">or PRI), if the remote party places the call on hold, the caller hears<br></blockquote><blockquote type="cite">the _local_ music on hold instead of the remote one. &nbsp;In fact we can<br></blockquote><blockquote type="cite">briefly hear the remote music on hold start, then it is replaced by<br></blockquote><blockquote type="cite">the local one.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">More precisely:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Company 1 uses an asterisk server with a PRI card tied to the telco.<br></blockquote><blockquote type="cite">Company 2 uses any PBX that ca place calls on hold and is tied to the<br></blockquote><blockquote type="cite">telco using a digital interface (tested with BRIs and PRIs)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A (company 1) calls B (company 2)<br></blockquote><blockquote type="cite">B answers and park or places the call on hold<br></blockquote><blockquote type="cite">A hears the MOH of company 1.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The same happens when calling a mobile: when the mobile user puts the<br></blockquote><blockquote type="cite">call on hold, instead of hearing the mobile operator's own moh, the<br></blockquote><blockquote type="cite">calling user hears the moh of his own company asterisk.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think this has something to do with REMOTE_HOLD notifications on PRI<br></blockquote><blockquote type="cite">lines that gets reported back to the calling asterisk server, which in<br></blockquote><blockquote type="cite">turn somehow puts the bridged (SIP) channel on hold, but I can't find<br></blockquote><blockquote type="cite">much more information about this.<br></blockquote><blockquote type="cite">Is this the expected behavior ? A feature or a bug ? Do you know if<br></blockquote><blockquote type="cite">this can be tuned/tweaked/disabled (i.e. filter or ignore this<br></blockquote><blockquote type="cite">signaling on the zap channel(s) ?)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Kind regards<br></blockquote><blockquote type="cite">Thanks<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">NB: Oddly enough, when the local user hears the music on hold, his own<br></blockquote><blockquote type="cite">channel (a local SIP phone in this case) isn't reported as "On Hold"<br></blockquote><blockquote type="cite">when issuing "sip show channels" in cli, &nbsp;and no AMI Hold/Unhold<br></blockquote><blockquote type="cite">events are generated. I double checked, the MOH that gets played is<br></blockquote><blockquote type="cite">the one specified in sip.conf, NOT zapata.conf.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a>--<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">asterisk-users mailing list<br></blockquote><blockquote type="cite">To UNSUBSCRIBE or update options visit:<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;<a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a>--<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">asterisk-users mailing list<br></blockquote><blockquote type="cite">To UNSUBSCRIBE or update options visit:<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;<a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a>--<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> &nbsp;&nbsp;<a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br></div></body></html>