From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>,
 "sipcore@ietf.org" <sipcore@ietf.org>
Date: Fri, 19 Aug 2011 08:24:02 +0200
Thread-Topic: Reviewers needed for new music-on-hold technique
Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QCAANGxwA==
Message-ID: <A444A0F8084434499206E78C106220CA09BDB6A21E@MCHP058A.global-ad.net>
References: <CD5674C3CD99574EBA7432465FC13C1B222B1F582F@DC-US1MBEX4.global.avaya.com>,
 <A444A0F8084434499206E78C106220CA09BDB69E4C@MCHP058A.global-ad.net>
 <CD5674C3CD99574EBA7432465FC13C1B222B1F5837@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F5837@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique
Precedence: list

=20

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20
> Sent: 18 August 2011 19:11
> To: Elwell, John; sipcore@ietf.org
> Subject: RE: Reviewers needed for new music-on-hold technique
>=20
> > From: Elwell, John [john.elwell@siemens-enterprise.com]
> >=20
> > Yes, it does now make an appropriate mention of RTCP - thanks.
>=20
> Good -- Thanks for checking that out.
>=20
> > I am also curious as to why there are a couple of mentions of using
> > directionality "inactive". Why would any of the entities=20
> 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?
>=20
> 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.
>=20
> 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=3D"no" in the re-INVITE from the executing UA.)
>=20
> 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.
>=20
> 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.
>=20
> I should add a note that discusses this optimization.
>=20
> > Perhaps this is to do with multiple media, where the remote=20
> UA offers
> > several media, and MOH is required only for one of these,=20
> 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.=20
> For example,
> > if the remote UA offers audio and video and the executing=20
> UA wants MOH
> > only for audio, how would it behave? Perhaps the example should be
> > extended to show such a possibility.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> What are the complexities you are seeing?
[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 i=
ndications) can be on a per medium basis. I guess if the remote UA offers a=
udio 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, a=
nd then when the answer is received, add in its own video description befor=
e forwarding the answer to the remote UA. Or if the executing UA forwards b=
oth 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 pass=
ing on the rejection.

John


John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: john.elwell@siemens-enterprise.com
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 Siemen=
s AG.


>=20
> Dale
> =