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

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.

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

On Tue, Oct 26, 2021 at 1:15 PM Justin Uberti <justin@uberti.name> 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 <roman@telurix.com> 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 <ted.ietf@gmail.com> 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
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>