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

Wed May 13 06:51:21 CDT 2009

Hi folks

I am still thinking about the best way to fit this into the config
files, but in the meantime I would like to offer some additional info
in support of my argument for both signalling hold and sending MOH
media. This is quoted from the SIPConnect recommendation from The SIP
Forum, an industry group working towards standardisation:

<quote>

When the hold initiator (which may be the SIP-PBX or Service Provider
network acting transparently as Media Endpoint) provides music-on-hold
(MOH) treatment:

-	The MOH source in the SIP-PBX or SP-SSE is based on local policy.
-	The hold initiator MUST set the SDP directionality attribute to "a=sendonly".

If the hold initiator does not provide MOH, it MUST set the SDP
directionality attribute to "a=inactive" or "a=sendonly". The
attribute "a=inactive" is RECOMMENDED because it provides an
indication to the held entity that MOH is not being provided by the
hold initiator.

<quote/>

For more info see http://www.sipforum.org/sipconnect

Regards,
Richard

On Fri, Apr 3, 2009 at 11:16 AM, Richard Brady <rnbrady at gmail.com> wrote:
> 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
>>
>