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.

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.
 
…
 
>>>c) may actually be the most significant decisioni, since it changes the behavior for just about every existing app (i.e., offerers will now start getting zero ports in their answers, regardless of mode). So I think we really
>>>just have to decide if there is a technical reason to prefer the BUNDLE behavior over the JSEP behavior, given the risks of such a change.
>>
>> As I have said in off-list discussions, I am not religious regarding how we fix the JSEP/BUNDLE misalignment issue. As it covers a case when BUNDLE has been negotiated, we don’t need to consider backward compatibility with non-JSEP/BUNDLE endpoints.
>
> We certainly have to consider backward compatibility with JSEP endpoints that don't expect to receive port zero in answers. 

Yes. What I meant was that when solving  the specification misalignment issue we don't have to consider endpoints that don't support JSEP and/or BUNDLE to begin with.

> If there's not a strong argument in favor of this new behavior, the simplest path would be to revert BUNDLE to the v40 (same as JSEP) behavior.

It would be nice to get input from a few more people - especially from those that don't use libwebrtc in the implementations. 

If people don't care, at least indicate that :)

Regards,

Christer