Subject: [sipcore] Reviewers needed for new music-on-hold technique

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 17 Aug 2011 16:06:27 -0400

> From: Elwell, John [john.elwell at siemens-enterprise.com]
> 
> I haven't reviewed it in detail, but I see there is no mention of
> RTCP. Perhaps it isn't really relevant, except that it provides
> another reason why the media server needs to supply an IP address and
> port - even though it will not receive RTP, it will receive RTCP. The
> RTCP port could be implicit or explicit.

I don't think I've mentioned this, but draft-worley-service-example-06
has updates to point out that allowing RTCP is useful.  See
http://tools.ietf.org/rfcdiff?url2=draft-worley-service-example-06 and
search for "RTCP".  These changes are carried forward into the
current -07 draft as well.

Do these changes suffice?

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 18 Aug 2011 09:05:04 +0200

Dale,

Yes, it does now make an appropriate mention of RTCP - thanks.

I am also curious as to why there are a couple of mentions of using directionality "inactive". Why would any of the entities involved use "inactive" unless they don't wish to send/receive music-on-hold? In particular, why would the INVITE from the executing UA to the MOH source use "inactive" - it is specifically asking the MOH source to send music, so if it wants "inactive", why send the INVITE?

Perhaps this is to do with multiple media, where the remote UA offers several media, and MOH is required only for one of these, so the other media descriptions are set to "inactive" in the INVITE to the MOH source. Whether or not that was the intention of "inactive", I think further discussion of multi-media situations is required. For example, if the remote UA offers audio and video and the executing UA wants MOH only for audio, how would it behave? Perhaps the example should be extended to show such a possibility.

John

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:[email-masked]] 
> Sent: 17 August 2011 21:06
> To: [email-masked]; Elwell, John
> Subject: Reviewers needed for new music-on-hold technique
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 18 Aug 2011 14:11:15 -0400

> From: Elwell, John [[email-masked]]
> 

Good -- Thanks for checking that out.

> I am also curious as to why there are a couple of mentions of using
> directionality "inactive". Why would any of the entities involved use
> "inactive" unless they don't wish to send/receive music-on-hold? In
> particular, why would the INVITE from the executing UA to the MOH
> source use "inactive" - it is specifically asking the MOH source to
> send music, so if it wants "inactive", why send the INVITE?

The strict answer as to why "inactive" is mentioned is that the
algorithm would not be correct without it, and I hadn't considered the
possible optimization of omitting the INVITE to the MOH source.

The situation arises when the remote UA gives directionality
"sendonly" because the remote UA has previously put the call on hold
also.  (The remote UA may reduce the directionality to "inactive" due
to the +sip.rendering="no" in the re-INVITE from the executing UA.)

There probably other situations where this arises.  E.g., where the
remote UA has formerly used a media stream in the dialog but no longer
wants to.

If all of the media streams that would be in the INVITE to the MOH
source have "inactive" directionality, the executing UA can omit
establishing the dialog with the MOH source.  The executing UA would
synthesize the SDP answer itself.  While the call is on hold, if the
remote UA sends a re-INVITE with directionality "active"/"recvonly",
then the executing UA has to start a dialog with the MOH source.

I should add a note that discusses this optimization.

> Perhaps this is to do with multiple media, where the remote UA offers
> several media, and MOH is required only for one of these, so the other
> media descriptions are set to "inactive" in the INVITE to the MOH
> source. Whether or not that was the intention of "inactive", I think
> further discussion of multi-media situations is required. For example,
> if the remote UA offers audio and video and the executing UA wants MOH
> only for audio, how would it behave? Perhaps the example should be
> extended to show such a possibility.

I would expect multiple media streams to work exactly as an extension
of the single media stream situation.  But there may be requirements
that I am not considering.

In the case where a call is being put on-hold and the remote UA is
willing to accept two streams (e.g., audio and video), I would expect
the executing UA to forward this request intact to the MOH server.
The MOH server would decide what media to send to the remote UA.

If the executing UA wanted to restrict the MOH media, it could do so
by editing the SDP offer.  But I don't see any particular reason to do
so.

What are the complexities you are seeing?

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Aug 2011 08:24:02 +0200

> Sent: 18 August 2011 19:11
> To: Elwell, John; [email-masked]
> Subject: RE: Reviewers needed for new music-on-hold technique
> 
[JRE] Nothing that can't be dealt with relatively easily, but perhaps some mention is needed. Don't forget that hold (in terms of SDP directionality indications) can be on a per medium basis. I guess if the remote UA offers audio and video and the executing UA only wants to hold audio, it would need to manipulate the SDP such that only audio is offered to the MOH source, and then when the answer is received, add in its own video description before forwarding the answer to the remote UA. Or if the executing UA forwards both audio and video to the MOH source and the MOH source rejects video, the executing UA might want to send inactive to the remote UA rather than passing on the rejection.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 19 Aug 2011 15:48:56 -0400

How about adding these sections to the end of section 2?

When the Media Stream Directionality is "inactive"

The directionality of the media stream in the SDP offer in an INVITE
or re-INVITE to the music source can be "inactive" if the SDP offer
from the remote UA was "sendonly" or "inactive".  Generally, this
happens when the remote UA also has put the call on hold and provided
a directionality of "sendonly".  In this situation, the executing UA
can omit establishing the dialog with the music source (or can
terminate the existing dialog with the music source).

If the executing UA uses this optimization, it creates the SDP answer
itself, with directionality "inactive" and using its own RTP/RTCP
ports, and returns that answer to the remote UA.

The executing UA must be prepared for the remote UA to send a
re-INVITE with directionality "active" or "recvonly", in which case
the executing UA must initiate a dialog with the music source, as
described above.

Multiple Media Streams

There may be multiple media streams (multiple m= lines) in any of the
the SDPs involved in the dialogs.  As the SDPs are manipulated, each
media description (each starting with an m= line) is manipulated as
described above for a single media stream.  But there are some
elaborations that the executing UA may implement to achieve specific
effects.

If the executing UA desires to present only certain media types as
on-hold media, when passing the offer SDP through, it can reject any
particular media streams by setting the port number in the m= line to
zero.[offer-answer]  This ensures that the answer SDP will also have a
rejection for that m= line.

If the executing UA wishes to provide its own on-hold media for a
particular m= line, it can do so by providing the answer information
for that m= line.  The executing UA may decide to do this when the
offer SDP is received (by modifying the m= line to rejected state when
sending it to the music source), or upon receiving the answer from the
music source and discovering that the m= line has been rejected.

The executing UA may not want to pass a rejected m= line from the
music source to the remote UA (when the remote UA provided a
non-rejected m= line), and instead provide an answer with
directionality "inactive" (and specifying its own RTP/RTCP ports).

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Aug 2011 08:25:51 +0200

Dale,

Yes, this text addresses my concerns.

John 

> Sent: 19 August 2011 20:49