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

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 <deadbeef@google.com> wrote:
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb