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

[Justin Uberti <[e-mail]>]

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.

>
> 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.