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

Thu Aug 27 04:46:08 CDT 2009

Hi Olle and co

I'm really struggling to convert this into a feature request.

Can anyone help?

Regards,
Richard

--
Richard Brady
T: +44 (0)7771 623 348
E: rnbrady at gmail.com

2009/4/3 Richard Brady <rnbrady at gmail.com>:
> 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
>>
>