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

[Richard Brady]

Ok, this is where it gets interesting. Consider the case of a PBX
which has its own MOH source and is talking via Asterisk to another
PBX.

If that PBX wants to put the call on hold while sending its own MOH,
you would probably argue that it should not send a re-INIVTE at all,
but should simply replace the outbound audio stream with its MOH and
discard the inbound audio stream.

But there are motivations for signalling that the call is on hold
(bandwidth, or ISDN interworking for example) so if the PBX wants to,
it should be able to. If it sends a re-INVITE with a=sendonly in the
SDP, that is an explicit indication that it is going to continue to
send media but is not interested in receiving any. It is reasonable
then to assume that the media which it continues to send is its MOH.

So I would disagree with the statement that "placing you on hold and
sending you a media stream, that is broken".

The counter argument to mine is that there are scenarios where the
endpoint (usually a handset) needs to signal that the call is on hold
in such a way that Asterisk knows to insert MOH. Currently this might
be done with the a=sendonly mechanism, which makes this scenario
incompatible with the one I describe above due to ambiguity of the
a=sendonly line.

In response to this I would say the correct way for such an endpoint
to signal hold is with a=inactive, as the handset is neither producing
nor consuming media during the hold. The PBX (Asterisk) then has the
option to pass on the a=inactive to the other endpoint or to
renegotiate for the insertion of local MOH.

I am not sure whether the current convention for handsets is
a=sendonly or a=inactive but I'm hoping it's the latter.

In any case, because MOH is often used for marketing, corporate
identity or just to irritate people, there is a need to get the
scenario above working. How could we go about that?


On Tue, Mar 31, 2009 at 12:45 PM, Kevin P. Fleming <kpfleming at digium.com> wrote:
> Richard Brady wrote:
>
>> I have researched the musiconhold / musicclass options in sip.conf as
>> well as the various documented classes and modes within
>> musiconhold.conf but I can't see how I tell it to just relay the media
>> stream straight on.
>
> Well, first, I was mistaken, and support for this behavior (passing
> through the 'hold' signaling) has not in fact been added to chan_sip.c
> yet, although it is supported in chan_iax2.c.
>
> However, your last comment here doesn't make sense: if the remote party
> put you on hold, there shouldn't be any media stream to 'relay' from it.
> That's why we normally replace the missing media stream with locally
> generated MOH. When (if) chan_sip is enhanced to support the
> 'mohinterpret=passthrough' setting like chan_iax2 has, then instead we'd
> pass on the 'hold' signaling to the SIP endpoint that was placed on
> hold, instead of sending it MOH. What it chooses to do to present that
> hold state to its user (or farther endpoint, if it is another B2BUA) is
> up to it, but in any case, there is no media stream to pass to it.
>
> If you have an endpoint that is *both* placing you on hold and sending
> you a media stream, that is broken. We don't have any concept of 'hold
> with media' in Asterisk today.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: kpfleming at digium.com
> Check us out at www.digium.com & www.asterisk.org
>
> _______________________________________________
> -- 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
>