Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE

[Christer Holmberg <[e-mail]>]

Hi,
 
>>>>>>>I think we need to split the problem into three parts:
>>>>>>>a) what should JSEP endpoints put into initial offers, when in max-bundle mode?
>>>>>>>b) what should JSEP endpoints put into initial offers, when in balanced mode?
>>>>>> 
>>>>>> Whatever JSEP says they should. There is no specification bug or specification misalignment etc that would require us to change that.
>>>>>
>>>>> The current charter text points out the issue here, and I think it's important that that text be maintained. As I've said, we need to take into account what existing applications expect, or else we have specs that can't be implemented. 
>>>>
>>>> So, every time libwebrtc decides to change their non-compliant behavior, without even consulting IETF about it, IETF should update and align their specs? I don't think that is how IETF works.
>>>>
>>>> The fact is that libwebrtc has chosen, for whatever reason, to implement non-compliant behavior. They were even aware of it, as a ticket regarding bundle-only support was raised at some point.
>>>
>>> Look, I am as unhappy as anyone else that we have this issue to deal with. But this isn't an issue about what libwebrtc did or didn't do; this is an observation on the state of the WebRTC ecosystem in 2021. libwebrtc was unable to
>>> implement the standard behavior 6 years ago because of application (not in libwebrtc!) incompatibilities when receiving port zero, and those incompatibilities have likely only multiplied over time. Ergo, we have to consider this situation as part of the problem space and resultant document update.
>>
>>If port zero caused problems already 6 years ago, I'm just wondering why the issue wasn't brought to IETF.
>
> Those details are lost to the ages, but most likely we simply meant to do it, and then when nobody asked for it to be fixed, it never happened.

So, will it be fixed now?

>>>> In this particular case, what makes things even worse is that the suggested solution (initial INVITE with same port in each m- line) is not backward compatible with SDP. We have even seen proof that is causes errors.
>>>>
>>>> We decided at day one that BUNDLE has to be backward compatible with "legacy" SDP equipment. If we want to change that, I think we are talking about a bis - it is not part of a specification alignment task.
>>>
>>> I think it's quite a stretch that any updates to JSEP's *non-default* bundle policies require a bis version of BUNDLE. I'm hoping that a) and b) can be resolved almost entirely in JSEP.
>>
>> So, to make sure I understand: we would define a new same-port-in-initial-offer policy in JSEP, but the same-port-in-initial-offer case would not be defined in BUNDLE?
>
> Something like that. Or we could just have a sentence in BUNDLE saying that same-port is allowed if the offerrer has some a priori knowledge of the remote endpoint, as would be indicated by use of said JSEP policy.

And, what if the offerer does NOT have prior knowledge of the remote endpoint?

Also, what presents such endpoint from RECEIVING an offer with port zero + bundle-only, if sent e.g., by a non-browser?

Regards,

Christer