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

[Justin Uberti <[e-mail]>]

On Mon, Nov 1, 2021 at 6:29 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
> >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.
>
> I don't agree with that. Again, that is why we did not define it to begin
> with. When this was discussed, people indicated that even in cases where an
> answerer would accept the offer, it is not possible to predict how the
> answer would look like.
>
> Also, keep in mind that the answerer may not know that the offer is for
> 3PCC. It may just see an initial offer.
>

I think we are talking about a much narrower situation than what was
considered years ago. The concern Roman raises is regarding a bundle-aware
endpoint that receives an initial offer that is a valid bundle subsequent
offer.

Can you suggest a specific technical reason why it would be ambiguous for
the answerer to handle this 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.
>
> I don't agree with suddenly allowing (read: specify in the standard that
> it is ok) something that we agreed that we are not going to do more or less
> from day one, and that has never considered later during the process either.
>
> ---
>
> The PROBLEM is that we have two endpoints, where one sends a subsequent
> offer, and the other one expects an initial offer. What do you normally do
> when you have that kind of problem? You use an SBC/B2BUA. In this case that
> SBC/B2BUA would be the 3PCC controller.
>
> So, my suggestion would be to remove the SHOULD text from 8843bis, and
> simply add a note somewhere (in 8843bis and/or 8829bis) which describes the
> issue and says that the 3GPP controller needs to modify the offer
> accordingly.
>
>
Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP
anyway then maybe adding a=bundle-only isn't the end of the world.