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

Fri Apr 3 05:16:30 CDT 2009

Agreed Olle, it would definitely have to be option driven, not least
for backward compatibility.

When you say "old idea", is there any discussion we can refer to?

Exisiting variables include:

mohinterpret
mohsuggest
musicclass
musiconhold

The first step would be to clarify what each of these are for. Then
perhaps we can add options for those which cover the scenarios we are
interested in.

Of course we we need to understand those scenarios too. So, let's look
at that. For each channel in the call you need to know how it holds
and how it likes to be held.

Ways it may hold:
1.1. a=sendonly and sends its own MOH (most likely a PBX)
1.2. a= sendonly and expects MOH to be generated upstream (most likely
a handset)
1.3. a=inactive and expects MOH to be generated upstream (could be PBX
or handset)
1.4. No signalling, it will simply substitute media

Ways it may like to be held:
2.1. Send it a=sendonly and send it MOH (could be PBX or handset)
2.2. Send it a= sendonly and no media (inside a network as you mentioned)
2.3. Send it a=inactive and no media (could be PBX or handset)
2.4. No signalling, simply send it substituted media.

At first glance you would think that it would hold as it likes to be
held. But actually a handset could use 1.2. while expecting 2.4 as it
cannot generate hold music for either it's own user when put on hold
or the remote user when holding.

So do we need two variables with 4 values each? I don't think so. We
only need to disambiguate between 1.1 and 1.2, and to choose between
2.1 through 2.4. Hopefully there is some scope to narrow that down
further. I will think about it some more.

Giving chan_sip support for the mohinterpret=passthrough option would
would be a start. But that option itself is ambiguous: does it mean
media passthrough or signalling passthrough? This ambiguity is
highlighted in the unanswered message from exvito on this list in
March last year:

[asterisk-users] Local music on hold -- mohinterpret=passthrough assymetrical ?

So some thought definitely needs to go into this before it becomes a
feature request.

R.

On Fri, Apr 3, 2009 at 9:03 AM, Olle E. Johansson <oej at edvina.net> wrote:
> 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
>
>
>
>
> _______________________________________________
> -- 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
>