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

[Christer Holmberg <[e-mail]>]

Hi,

First, it would have been nice to see a call-flow that shows exactly where the issue arises, as there are different ways of doing 3PCC.

Already at the early days of BUNDLE, we agreed that an initial offer will NOT contain a shared address, because it is not backward compatible with non-bundle aware endpoints. Some people (including e.g., myself and Cullen) were very keen on that. Instead we will use port zero + bundle-only for m- lines that are only be accepted if part of a BUNDLE group. I do not agree to adding text to 8843bis saying there are cases where the specified procedures for initial offers don’t apply, or don’t have to be followed.

Yes, we did add some 3PCC clarification text  (which anyone could have commented on) in 8843bis, but we did not change the procedures for initial offers.

Also keep in mind that the difference between an initial offer and a subsequent offer is not related only the BUNDLE-related information. For example, an initial offer must also contain unique ICE candidates in each non-bundle-only m- line.

My understanding of the text in 8829bis is that JSEP does NOT support (or, if we want to word it differently, is not able to detect) the 3PCC cases referenced by Roman (again, call flows would have been nice), so a JSEP endpoint will always send a subsequent offer according to the rules for sending a subsequent offer.

Regarding Roman’s suggested solutions #2 and #3, sending ALL bundled m- lines with port zero and bundle-only would be something completely new, as there would be no offerer-tagged m- section. I don’t think that is a good idea. We wither send an initial offer, using the procedures for initial offers, or we send a subsequent offer, using the procedures for subsequent offers.

Regards,

Christer


From: rtcweb <[e-mail]> On Behalf Of Roman Shpount
Sent: lauantai 30. lokakuuta 2021 5.27
To: Justin Uberti <[e-mail]>
Cc: Justin Uberti <[e-mail]>; RTCWeb IETF <[e-mail]>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

On Fri, Oct 29, 2021 at 6:49 PM Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:


On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:

As I am trying to explain, there is nothing in the offer that would prevent the compliant implementation from moving the m= line out. This is not obvious but can cause grief.

The problem is that it is not possible, as there is no other transport to move the unbundled line to. As noted in the section you cite:

 "NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section cannot be moved out of the BUNDLE group in an answer. Instead, an offer is needed.:"

Generally, I think that if there is a shared address, that signifies that a BUNDLE group has already been negotiated, even if that decision was made elsewhere. Perhaps a note should be added to bundle-bis to explicitly state this.

When discussing bundle-bis the understanding was that it is generally known when an offer is generated for 3pcc. Because of this, it was decided that when the offer is generated for 3pcc it should be generated using the same rules as the initial offer (i.e. with port zero and bundle-only). This was considered to be both backwards compatible with RBF 8843 and safe to use as an initial offer for non-bundle aware, bundle, and bundle-bis endpoints. For whatever reason, inspecting transport addresses was not considered a valid mechanism to detect that m= lines are already bundled and cannot be unbundled in the future. If we want to switch to inspecting transport addresses when deciding which m= lines can be unbundled, this deserves a lot more than a note in bundle-bis.

This logic needs to be applied on subsequent offers already though, so I don't understand why asking endpoints to also consider it on initial offers is an issue. Perhaps Christer could weigh in here.

During the initial offer end point does not have already negotiated bundle groups. Once the endpoint has already negotiated bundle groups, m= lines cannot be removed from them.

I would still argue that a safe way to generate an offer for 3PCC is to do SDP manipulation and set ports to 0 with attribute bundle-only. Everything else would not be compatible with either bundle-bis or RFC 8843.

I am fine to include this as a consideration for non-BUNDLE endpoints but it seems error-prone and unnecessary to do this for BUNDLE-aware endpoints.

Your logic only works if bundle-aware endpoints were not allowed to remove m= lines from a bundle group. Looking at the addresses to determine what is already grouped is insufficient, since an offer can also be an offer with ice restart and trickle. No addresses will be present, so the endpoint will have to look at ice parameters as well. This gets complicated and no one wanted to describe this when 8843bis was written.  This is why rfc 8843bis specifies that subsequent offers for 3PCC should be valid initial offers.

There are, potentially, two solutions to this:

1. Change bundle so that endpoints are required to inspect initial offers for transport addresses and ice parameters. Do not allow m= lines to be removed from the bundle group if they share the transport address. This would require pulling RFC 8843bis and writing the appropriate language.

2. Change JSEP note to specify that the application needs to make sure that in case of 3PCC and remote endpoints either potentially removing m= lines from the bundle or not being bundle-aware, bundled m= lines need to be modified to have port 0 and bundle-only attribute. Considering that most bundle-aware endpoints do not remove m= lines from the bundle, this option would cause the least amount of specification work.

3. If we want to completely avoid applications messing with SDP, change JSEP to specify that when ice-restart is specified and a new offer is generated, already bundled m= lines should be marked with port 0 and bundle-only. This would also result in the least number of surprises for developers.

Best Regards,
_____________
Roman Shpount