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

[Justin Uberti <[e-mail]>]

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.

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

> _____________
> Roman Shpount
>
>
> On Tue, Oct 26, 2021 at 1:15 PM Justin Uberti <[e-mail]> wrote:
>
>> Agree we should add a reference to 8843-bis. I assume we can do that in
>> the endgame as (I believe) no text in 8829bis needs to change.
>>
>> Regarding 3PCC:
>> - bundle clients should be able to accept initial offers without
>> bundle-only. If not, we should fix that in 8843bis, as this seems like an
>> unnecessary limitation - current implementations seem to be managing this
>> OK.
>> - the stats on BUNDLE show that it has been widely adopted (99.999% usage
>> when there is more than 1 a/v stream), and these numbers are only
>> increasing. If "rare" seems overly opinionated, we could use "uncommon"
>> instead.
>>
>> Regarding the suggested workaround:
>> - adding a=bundle-only is insufficient, the application would also need
>> to insert zero ports for the bundled m= lines. It's also not clear that
>> this would lead to a good outcome, as the non-bundle endpoint would only be
>> able to accept the first bundled m= line. So I would suggest that if 3PCC
>> with non-bundle-aware endpoints is likely, the application should just eat
>> the a=group attribute for bundle to prevent bundling in the first place.
>>
>>
>> On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount <[e-mail]> wrote:
>>
>>> Hi Ted,
>>>
>>> I have mentioned on git that:
>>> 1. The reference to RFC 8843bis is missing
>>>
>>> 2. The following language is factually incorrect:
>>>
>>> This is by design, but could cause issues in the rare case of sending a
>>> subsequent offer as an initial offer to a non-bundle-aware endpoint via
>>> Third Party Call Control (3PCC).
>>>
>>> Primarily, this will cause issues if a subsequent offer is used as an
>>> initial even with bundle-aware end points. An offer with no bundle-only
>>> attributes for bundled m= lines might not get processed correctly. Second,
>>> I would not comment on how frequent this call scenario is going to be
>>> unless we have to.
>>>
>>> My suggested language was:
>>>
>>> This is by design, but could cause issues in case of sending a
>>> subsequent offer as an initial offer due to Third Party Call Control
>>> (3PCC). In such cases, the signaling application is responsible for adding
>>> bundle-only attributes to the offer so that it can be used as an initial
>>> offer.
>>>
>>> Best Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>> On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie <[e-mail]> wrote:
>>>
>>>> This email serves as the start of a working group last call for
>>>> draft-uberti-rtcweb-rfc8829bis-01.txt.  Because of the upcoming IETF
>>>> meeting, it will be slightly longer than normal, ending on November 16,
>>>> 2021.
>>>>
>>>> Please send comments to the list.
>>>>
>>>> thanks,
>>>>
>>>> Ted and Sean
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>