Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

[Justin Uberti <[e-mail]>]

>
>
> >1. Make subsequent offers valid initial offers. This means adding some
> language explaining how the endpoint processing initial offer can detect
> that m= lines cannot be unbundled. Even if we add this language it will
> have backwards compatibility issues with anything that has not implemented
> it.
>
>
>
> I don’t agree with that suggestion. Because, in that case we could have
> done it from the beginning, as a general rule, without using port zero. But
> there were reason we chose not to allow shared addresses (with non-zero
> port values) in initial offers.
>

We did come up with a=bundle-only mechanism to ensure backwards
compatibility, and none of us want to revisit that decision. However, I do
think that it would be consistent with Postel's Principle for the answerer
to properly handle the case where a 3PCC offer ends up with a shared
address, rather than failing simply because the offer does not appear to be
an initial offer.

>
>
> >2. Make endpoints generate subsequent offers that are valid initial
> offers in 3PCC scenarios. This is what draft 8843 bis does.
>
>
>
> Correct.
>
>
>
> However, keep in mind that it is not only about how to encode the port
> numbers and bundle-only attributes. Sending an initial offer also comes
> with a set of procedures. Some of those (e.g., ICE)  I assume you will have
> to do anyway, as the remote endpoint changes.
>
>
>
> >I would even be fine with webrtc endpoint not doing anything and adding a
> note to JSEP telling the 3PCC application to "fix" the offer and add m=
> port zero and bundle-only attributes when it is sending subsequent offers
> as initial offers to a new end point.
>
>
>
> I would be fine adding such text to JSEP. It could be an additional
> sentence to the existing text.
>
>
>
> (However, I still would not say “sending subsequent offers as initial
> offers”. I would say “create and send an initial offer based on a received
> subsequent offer”, or something like that.)
>

This might turn out to be the simplest option, but as noted before, it will
require several SDP changes and will be somewhat error-prone as a result
(assuming anyone implements this at all). Accordingly I think #1 above is
the least bad choice.