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

[Taylor Brandstetter <[e-mail]>]

> 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 <[e-mail]> 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 ?
>
>
> > On Mar 28, 2016, at 5:13 PM, Taylor Brandstetter <[e-mail]>
> 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 <[e-mail]>
> 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
> > <[e-mail]>
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>