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

[Roman Shpount <[e-mail]>]

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

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