Subject: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2016 23:25:48 +0200

Hi, the scenario is the following:

- Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264
packetization-mode=1 (PT 101).

- Bob answers with just VP8 (let's say it sets PT 110) in the m= line,
regardless he also supports H264.

At this time Alice must send VP8 (PT 110) to Bob, and Bob must send
VP8 (PT 100) to Alice. Fine.

Later Bob wants to change to H264, so he sends a SDP reoffer to Alice
by just offering H264 packetization-mode=1 (PT 111).

Assuming this is valid (re-enabling a previously discarded codec),
Alice answers the reoffer with just H264 (PT 101).

Is this valid? And a more pragmatic questions: should I assume that
current WebRTC implementations would support this scenario?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 28 Mar 2016 16:13:00 -0700

This seems like a bit of a gray area. JSEP says that for subsequent offers:

   o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
>       only include codecs present in the remote description.

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.

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

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=5697

On Mon, Mar 28, 2016 at 2:25 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 28 Mar 2016 18:23:22 -0600

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 ? 

> On Mar 28, 2016, at 5:13 PM, Taylor Brandstetter <[email-masked]> wrote:
> 
> 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.
> 
> 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
> 
> 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=5697
>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 28 Mar 2016 17:36:49 -0700

> 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
By "normal re-offer case", do you mean when the re-offer is generated by
the same peer that generated the initial offer? If so, is there a reason
why this should work differently than an "abnormal" re-offer case (where
the re-offer is generated by the peer that generated the initial answer)?

> 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.
As the specs are currently written, removing and re-adding a track would
create a new transceiver. So it would definitely have the full set of
codecs.

On Mon, Mar 28, 2016 at 5:23 PM, Cullen Jennings <[email-masked]> wrote:

>
> 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 ?
>
>
> > 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
> > 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
> >
> > 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=5697
> >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2016 10:09:49 +0200

Hi. Since a JSEP issue has been open, I've commented there:

https://github.com/rtcweb-wg/jsep/issues/266

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Mar 2016 08:29:22 +0000

Hi,

I see no reason why one should not be allowed to add previously discarded
codecs. There can be many reasons why a codec is discarded at one point,
but might be accepted later.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2016 10:39:44 +0200

> but might be accepted later.

Agreed.
Also: https://github.com/rtcweb-wg/jsep/issues/266#issuecomment-202769776

-- 
Iñaki Baz Castillo
<[email-masked]>