Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAK35n0YJ4AVow4z5Wz9eODUgn3XOkp5msKSY=BJg55YZz9CY5g@mail.gmail.com>
Date: Mon, 28 Mar 2016 18:23:22 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <74244AD7-31A4-42DC-B0AB-5F24EE2C7599@iii.ca>
References: <CALiegfmxG-NFoQdQ0HZi80kB4J4_G0YnYXbCYxwz6TPEg8+ACA@mail.gmail.com>
 <CAK35n0YJ4AVow4z5Wz9eODUgn3XOkp5msKSY=BJg55YZz9CY5g@mail.gmail.com>
To: Taylor Brandstetter <deadbeef@google.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/PY8A8TGUtZQEHUEdCGE7egjyZQ4>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation
Precedence: list


So I think Offer/Answer would allow that, but JSEP says not to do it in =
the normal re-offer case as the desire was not to have codecs change on =
reoffer, however, if the JS wanted to do redo the offer that way, if it =
removed the Track, then added the Track back, I suspect that JSEP would =
re-offer will full set of codecs. That sound about right ?=20


> On Mar 28, 2016, at 5:13 PM, Taylor Brandstetter <deadbeef@google.com> =
wrote:
>=20
> This seems like a bit of a gray area. JSEP says that for subsequent =
offers:
>=20
>    o  The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" =
lines MUST
>       only include codecs present in the remote description.
>=20
> In this situation, the remote description does still contain H.264, so =
it seems it would technically be valid to offer it. However, if Alice =
were to send a reoffer, she could not offer H.264. And then Bob's remote =
description wouldn't contain H.264, so he couldn't offer it even if he =
wants to.
>=20
> I'm thinking this may be an oversight in the spec. I created an issue =
for it: https://github.com/rtcweb-wg/jsep/issues/266
>=20
> As for current implementations: Chrome will freely let you add =
previously discarded codecs, and it even creates offers with discarded =
codecs. Though this is currently considered a bug. I just created an =
issue to track it: =
https://bugs.chromium.org/p/webrtc/issues/detail?id=3D5697
>=20
> On Mon, Mar 28, 2016 at 2:25 PM, I=C3=B1aki Baz Castillo =
<ibc@aliax.net> wrote:
> Hi, the scenario is the following:
>=20
> - Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264
> packetization-mode=3D1 (PT 101).
>=20
> - Bob answers with just VP8 (let's say it sets PT 110) in the m=3D =
line,
> regardless he also supports H264.
>=20
> At this time Alice must send VP8 (PT 110) to Bob, and Bob must send
> VP8 (PT 100) to Alice. Fine.
>=20
> Later Bob wants to change to H264, so he sends a SDP reoffer to Alice
> by just offering H264 packetization-mode=3D1 (PT 111).
>=20
> Assuming this is valid (re-enabling a previously discarded codec),
> Alice answers the reoffer with just H264 (PT 101).
>=20
>=20
> Is this valid? And a more pragmatic questions: should I assume that
> current WebRTC implementations would support this scenario?
>=20
> Thanks a lot.
>=20
>=20
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb