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

Discussion:

Richard Brady

2009-03-30 18:15:19 UTC

Hi all

If Asterisk is bridging a call between two SIP peers and one peer puts
the other on hold by means of a re-INVITE with SDP containing
a=sendonly, Asterisk will play locally generated MOH instead of
relaying the media streamed by the SIP peer which took the hold
action.

Any ideas how to change that?

(This is understandable if the peer is a handset but can be a problem
if it is a PBX with its own MOH source.)

Richard

--
Richard Brady

Kevin P. Fleming

2009-03-30 20:04:05 UTC

Permalink

Post by Richard Brady
If Asterisk is bridging a call between two SIP peers and one peer puts
the other on hold by means of a re-INVITE with SDP containing
a=sendonly, Asterisk will play locally generated MOH instead of
relaying the media streamed by the SIP peer which took the hold
action.
Any ideas how to change that?

What version of Asterisk are you using? If it's 1.4 or later, this
already configurable in sip.conf.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: ***@digium.com
Check us out at www.digium.com & www.asterisk.org

Richard Brady

2009-03-31 11:09:10 UTC

Permalink

Kevin

That's great to hear. I'm using 1.4.21.2, but I can't see where or how
it's configurable.

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.

Any help greatly appreciated.

Richard

Post by Kevin P. Fleming

What version of Asterisk are you using? If it's 1.4 or later, this
already configurable in sip.conf.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users

Kevin P. Fleming

2009-03-31 11:45:26 UTC

Permalink

Post by Richard Brady
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.

Richard Brady

2009-03-31 12:32:32 UTC

Permalink

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?

Post by Kevin P. Fleming

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
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users

Anthony Plack

2009-04-01 16:44:37 UTC

Permalink

Post by 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.

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

Richard Brady

2009-04-01 17:16:20 UTC

Permalink

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?

Post by Anthony Plack
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

Post by Anthony Plack
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

Richard Brady

2009-04-02 13:05:23 UTC

Permalink

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.

Post by Richard Brady
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
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?

Post by Anthony Plack
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

Olle E. Johansson

2009-04-03 08:03:56 UTC

Permalink

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

Post by Richard Brady
Furthermore, the following two IETF documents address the need to both
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.

Post by Anthony Plack
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

Post by Anthony Plack
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
http://lists.digium.com/mailman/listinfo/asterisk-users

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

Richard Brady

2009-04-03 10:16:30 UTC

Permalink

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.

Post by Olle E. Johansson
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

Post by Anthony Plack
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

Post by Anthony Plack
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

---
* 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
http://lists.digium.com/mailman/listinfo/asterisk-users

Richard Brady

2009-05-13 11:51:21 UTC

Permalink

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

Post by Richard Brady
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?
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.
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
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
[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.

Post by Anthony Plack
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

Post by Anthony Plack
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

Richard Brady

2009-08-27 09:46:08 UTC

Permalink

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

Post by Anthony Plack
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

Post by Anthony Plack
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