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

[Roman Shpount <[e-mail]>]

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.

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.
_____________
Roman Shpount