From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>,
 "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 18 Aug 2011 09:05:04 +0200
Thread-Topic: Reviewers needed for new music-on-hold technique
Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrg
Message-ID: <A444A0F8084434499206E78C106220CA09BDB69E4C@MCHP058A.global-ad.net>
References: <CD5674C3CD99574EBA7432465FC13C1B222B1F582F@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F582F@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

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 directi=
onality "inactive". Why would any of the entities involved use "inactive" u=
nless they don't wish to send/receive music-on-hold? In particular, why wou=
ld the INVITE from the executing UA to the MOH source use "inactive" - it i=
s specifically asking the MOH source to send music, so if it wants "inactiv=
e", why send the INVITE?

Perhaps this is to do with multiple media, where the remote UA offers sever=
al media, and MOH is required only for one of these, so the other media des=
criptions 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 mu=
lti-media situations is required. For example, if the remote UA offers audi=
o and video and the executing UA wants MOH only for audio, how would it beh=
ave? Perhaps the example should be extended to show such a possibility.

John

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20
> Sent: 17 August 2011 21:06
> To: sipcore@ietf.org; Elwell, John
> Subject: Reviewers needed for new music-on-hold technique
>=20
> > From: Elwell, John [john.elwell at siemens-enterprise.com]
> >=20
> > 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=20
> address and
> > port - even though it will not receive RTP, it will receive=20
> RTCP. The
> > RTCP port could be implicit or explicit.
>=20
> 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=3Ddraft-worley-service-example-06 and
> search for "RTCP".  These changes are carried forward into the
> current -07 draft as well.
>=20
> Do these changes suffice?
>=20
> Dale
> =