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

[Justin Uberti <[e-mail]>]

On Fri, Oct 29, 2021 at 11:08 AM Roman Shpount <[e-mail]> wrote:

> On Fri, Oct 29, 2021 at 1:35 PM Justin Uberti <[e-mail]>
> wrote:
>
>> On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount <[e-mail]> wrote:
>>
>>> Regarding 3PCC, bundle clients should be able to accept the initial
>>> offer without bundle-only. Unfortunately there is nothing there that
>>> prevents them from moving an m= line out of the bundle unless it is marked
>>> with bundle-only.
>>>
>>
>> If it's already bundled, I don't think it can be unbundled, since there
>> is no other transport to move it to. This is the same situation as in
>> subsequent o/a exchanges.
>>
>
> It is correct that m= line cannot be unbundled once it is bundled. If this
> offer is received as a result of 3PCC, there is nothing in the offer that
> indicates that the m= line cannot be unbundled.
> Per draft-ietf-mmusic-rfc8843bis section 7.3.2 (
> https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-moving-a-media-description-
> ):
>
>
>    - In the corresponding offer, the "m=" section is within a previously
>       negotiated BUNDLE group, and
>       - In the corresponding offer, the "m=" section contains an SDP
>       'bundle-only' attribute.
>
> If either criterion above is fulfilled, the answerer cannot move the "m="
> section out of the BUNDLE group in the answer.
>
> For subsequent offers processed as initial offers neither of those
> criteria are true. There are no previously negotiated BUNDLE groups (it is
> an initial offer). There is no 'bundle-only' attribute. Because of this,
> even a bundle aware endpoint can move the m= line out. There is no
> requirement to check that bundled m= lines are using the same address/port.
>
>
>> I was not thinking about the frequency of use of 3PCC with non-bundle
>>> endpoints (extremely rare) but about the use of 3PCC in general (more
>>> common and hard to identify).
>>>
>>> I agree that a=bundle-only is insufficient. We do need to add port zero.
>>> This will ensure that a bundle-aware endpoint will not take the m= line out
>>> of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the
>>> application should create a new PeerConnection instead with an appropriate
>>> bundle policy.
>>>
>>
>> As noted above I don't think taking an m= line out of the bundle is
>> allowed when a shared port is already in use.
>>
>
> 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.