[asterisk-users] Asterisk doesn't relay remote MOH during hold

Fri Apr 3 03:03:56 CDT 2009

My old idea was to implement an option, since there are many people  
with different opinions
on how a PBX should behave when a channel is put on hold.

An option could control how we should handle the bridged channel when  
the caller or the callee
puts a call on hold. It could either be local hold, meaning we  
entertain the user with music,
or a remote hold, which means that we send the hold forward over ISDN  
or SIP and let the
other end handle the hold. This would also work well in larger  
Asterisk installations,
where you don't want to fill up trunks between Asterisk servers with  
music. The edge server
provides the music, no one else.

In SIP we could easily add a proprietary header for music class  
suggestion in these cases.

Asterisk admins should be able to set this option per call in the  
dialplan or per device in
channel configurations - or per PBX, also in channel configs.

"local hold" or "remote hold" might mean something else, coming to  
think of it. But it fitted
in nicely here.... :-)

/Olle

2 apr 2009 kl. 15.05 skrev Richard Brady:

> Furthermore, the following two IETF documents address the need to both
> signal the hold and provide the music:
>
> 1. RFC 5359 (Session Initiation Protocol Service Examples)
>
> 2. draft-worley-service-example-03 (Session Initiation Protocol
> Service Example -- Music on Hold)
>
> Unfortunately they both address more complex scenarios and solutions,
> but they do back me up on the fact that there are good reasons to both
> signal hold and provide music.
>
> R.
>
> On Wed, Apr 1, 2009 at 6:16 PM, Richard Brady <rnbrady at gmail.com>  
> wrote:
>> Hi Tony
>>
>> I can see where you guys are coming from on this and have already
>> enumerated your argument in my own email.
>>
>> But there are very real reasons for a PBX to signal the hold even  
>> when
>> it wants to send its own MOH:
>>
>> 1. Bandwidth: under your scheme the PBX would continue to receive
>> bandwidth-consuming media without using it.
>> 2. Privacy: the far-end has an expectation of privacy while on hold
>> and should have the option to mute automatically when held.
>> 3. Feature richness: signalling the hold enables such innovative
>> features such as reverse hold.
>> 4. ISDN interworking: ISDN supports this and SIP should be compatible
>> with that (as per standard ITU-T Q.1912.5)
>>
>> Also, can you explain why the PBX would use a=sendonly but not
>> dispatch media. Why not a=inactive for that case?
>>
>>> IMHO, PBX-A would be broken if it passed this along the Hold  
>>> message to downstream and then started servicing the MOH itself
>>
>> Remember it is not a hold message, it is a media attribute and we are
>> discussing how that should be interpreted within the context of the
>> hold feature in traditional telephony.
>>
>> I would also like to point out in my defence that there are several
>> telephone systems in the field which behave as I described (Nortel
>> BCM50, Aastra Intelligate, Mitel 3300 to name a few).
>>
>> Regards,
>> Richard
>>
>>
>>> I have to agree with Kevin on this one.
>>>
>>> I fail to understand how you have a PBX-A talking to Asterisk  
>>> talking to PBX-B and the PBX-A placing the call on hold.   
>>> Typically you should have a Client/Phone to PBX-A to Asterisk to  
>>> PBX-B to Client/Phone/VoiceMail.
>>>
>>> If the Client signals Hold, the PBX should NOT be passing that  
>>> Hold status on but transition audio stream from Client to MOH  
>>> (assuming MOH is handled).  Asterisk shouldn't notice a thing  
>>> except more RTP packets (or less if it is my teenage daughter on  
>>> the phone as the case may be).
>>>
>>> IMHO, PBX-A would be broken if it passed this along the Hold  
>>> message to downstream and then started servicing the MOH itself on  
>>> the RTP stream.  That just doesn't make sense.
>>>
>>> Now if PBX-A were not a PBX and were a SIP Router, and the SIP  
>>> Router was attempting this, I can see how it would Re-Invite, but  
>>> it shouldn't pass the hold status onto Asterisk.
>>>
>>> Need some clarity here.
>>>
>>> Tony Plack
>>
>
> _______________________________________________
> -- 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

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden