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

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 <ibc@aliax.net> wrote:

> 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
> <ibc@aliax.net>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>