[asterisk-users] Remote hold on PRI

Gaëtan Minet gminet at easynet.be
Tue Jan 8 01:24:08 CST 2008


Hi Shane

yes, with verbose activated, I get something like this:

starting Music on hold for Channel SIP/XXX (the local caller sip side)  
with the class specified in sip.conf.

With zap span debugging enabled, I see the bridged zap channel  
receives "REMOTE HOLD" notification just before the moh starts.

That sounds like a nice feature between enterprise servers, but not so  
good between different companies of course.

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"  in fact:).

Thank you

Regards,
Gaetan


On 07/01/2008, at 21:28, Shane Spencer wrote:

> So, watching the asterisk console with full debug on shows something
> about "Starting Music On Hold for Channel xx/yy-zz"?
>
> Shane
>
> On Jan 7, 2008 11:00 AM, Gaëtan Minet <gminet at easynet.be> wrote:
>>
>> Hi
>>
>> Nobody has an Idea ? Should I try and fill a bug report (or feature  
>> request
>> ?) at Digium  ?
>> The only solution I personally see is a patch in the source.
>>
>> Regards
>>
>> Gaetan
>>
>>
>>
>> On 04/01/2008, at 23:26, Gaëtan Minet wrote:
>> Hi everybody
>>
>> We have a strange problem with several asterisk servers (Version
>> 1.4.11) using PRI cards (tied to telco here in Belgium).
>>
>> Indeed we noticed that whenever a local user places an outgoing call
>> through the PRI (and telco) to another IPBX (tied to telco using BRI
>> or PRI), if the remote party places the call on hold, the caller  
>> hears
>> the _local_ music on hold instead of the remote one.  In fact we can
>> briefly hear the remote music on hold start, then it is replaced by
>> the local one.
>>
>> More precisely:
>>
>> Company 1 uses an asterisk server with a PRI card tied to the telco.
>> Company 2 uses any PBX that ca place calls on hold and is tied to the
>> telco using a digital interface (tested with BRIs and PRIs)
>>
>> A (company 1) calls B (company 2)
>> B answers and park or places the call on hold
>> A hears the MOH of company 1.
>>
>> The same happens when calling a mobile: when the mobile user puts the
>> call on hold, instead of hearing the mobile operator's own moh, the
>> calling user hears the moh of his own company asterisk.
>>
>> I think this has something to do with REMOTE_HOLD notifications on  
>> PRI
>> lines that gets reported back to the calling asterisk server, which  
>> in
>> turn somehow puts the bridged (SIP) channel on hold, but I can't find
>> much more information about this.
>> Is this the expected behavior ? A feature or a bug ? Do you know if
>> this can be tuned/tweaked/disabled (i.e. filter or ignore this
>> signaling on the zap channel(s) ?)
>>
>> Kind regards
>> Thanks
>>
>> NB: Oddly enough, when the local user hears the music on hold, his  
>> own
>> channel (a local SIP phone in this case) isn't reported as "On Hold"
>> when issuing "sip show channels" in cli,  and no AMI Hold/Unhold
>> events are generated. I double checked, the MOH that gets played is
>> the one specified in sip.conf, NOT zapata.conf.
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080108/6cc8fb4c/attachment.htm 


More information about the asterisk-users mailing list