Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)

[Gunnar Hellström <[e-mail]>]

Hi,

Den 2024-04-05 kl. 11:32, skrev Christer Holmberg:
> Hi,
>
>>>>> I am not sure what you mean be "pre-agreed data channels", but I was
>>>>> referring to applications that use both DCEP and SDP.
>>>> I was specifically referring to datachannels created with the "negotiated"
>>>> flag set to "true".
>>> Gotcha.
>>>
>>> So, you are saying there ARE applications that use both DCEP and SDP
>>> ("negotiated" flag set to "true") to negotiate data channels?
>> Yes. We've seen it used.
> Ok, that is useful input.
>
> Do you know WHY those applications use both mechanisms?
I can see the case when implementing RFC 8865 for RTT, that there may be 
an interest to negotiate in a standardised way the extra channel 
parameters about language and modality preference and increase the 
default characters per second. The reason to do it in a standardised way 
may be because a gateway may be involved in the communication and it can 
be good to have that implemented in a generally accepted way.
Once the channel characteristics is negotiated it is of interest to 
handle the creation of the channel and the communication in it by code 
in a web page and calls to the WebRTC API for ease of development and use.

I am not sure that it will be a popular method. Maybe it will be more 
popular to go straight on to use DCEP and the API.

>
>>>>> WebRTC, as currently specified, will ignore all attempts to negotiate
>>>>> datachannels using SDP, so those channels can only be created by the
>>>>> application parsing the SDP, extracting the information, and calling
>>>>> "createDataChannel" with "negotiated" set to true.
>>>> Correct.
>>>>
>>>>> Also, your claim that the DCEP odd/even restriction would not apply
>>>>> for certain cases is (AFAIK) not defined anywhere. Also, I don't
>>>>> understand why the odd/even restriction would not apply in the case
>>>>> where you have pre- agreed data channels.
>>>> The WebRTC spec, at <removed link> does not
>>>> mention the odd/even rule. For good reason; both ends have to call
>>>> createDataChannel with the same value for "id", so it *has* to "violate"
>>>> the odd/even rule.
>>> Both endpoints obviously have to use the same "id", but one endpoint
>>> has to decide which "id" to use, and when using SDP the idea was to
>>> re-use the DCEP odd/even rule.
>> And that re-use is exactly the thing that we can't do.
> I agree.
>
>>> I DO agree that the odd/even rule does not work in SDP actpass cases
>>> (where the id has to be set before the DTLS roles have been
>>> determined), and should be corrected, but I am not sure whether the
>>> correction suggested in the errata is the right way.
>> I'm happy to see alternate text suggested. My suggestion was only in order
>> to
>> have something specific to suggest in order to get rid of the inappropriate
>> MUST.
> The problem with simply removing the MUST is that it will introduce risk for
> id collision - especially if there are applications that use both DCEP and
> SDP.
>
> We can either try to solve that some other way, or simply document the
> collision risk, but in either case we should document it.

The risk is discussed in the Appendix A of RFC 8864, but I do not see it 
getting closer to a solution.

Regards

Gunnar

>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
------------------------------------------------------------
Gunnar Hellström
GHAccess
[e-mail]
Tel: [phone]