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

[Harald Alvestrand <[e-mail]>]

On 4/4/24 12:03, Christer Holmberg wrote:
> 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 
(https://w3c.github.io/webrtc-pc/#dom-rtcdatachannelinit-negotiated) set 
to "true".

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.

> 
> 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 
https://w3c.github.io/webrtc-pc/#dom-rtcdatachannelinit-id, 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.

> You still want to avoid stream ID collisions when using DCEP -
> no matter if you have pre-agreed data channels or not.

Of course. This is detailed in 
https://www.rfc-editor.org/rfc/rfc8832#section-6 - "The peer that 
initiates opening a data channel selects a stream identifier for which 
the corresponding incoming and outgoing streams are unused. "

And: "If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions 
above, the receiver MUST close the corresponding data channel using the 
procedure described in [RFC8831] and MUST NOT send a DATA_CHANNEL_ACK 
message in response to the received message. This might occur if, for 
example, a DATA_CHANNEL_OPEN message is received on an already used 
stream...."

All this is well defined. RFC 8864 is wrong.

> 
> Regards,
> 
> Christer
> 
>> -----Original Message-----
>> From: mmusic <[e-mail]> On Behalf Of Harald Alvestrand
>> Sent: Thursday, 4 April 2024 8.38
>> To: [e-mail]
>> Subject: Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)
>>
>> Yes, there are applications that both establish pre-agreed datachannels and
>> use DCEP. For those cases, the odd/even restriction does not apply; it is up
>> to
>> the application to rendezvous properly.
>>
>> This erratum removes the incorrect claim that SDP-negotiated channels are
>> capable of obeying the odd/even rule, bringing SDP-negotiated channels in
>> line with the rules for pre-agreed datachannels.
>>
>> Harald
>>
>>
>> On 3/27/24 11:48, Christer Holmberg wrote:
>>> Hi,
>>>
>>>>>>> The issues (AFAIU) is when the offerer sends the *initial* offer,
>>>>>>> with ACTPASS, and creates one or more data channels using SDP. At
>>>>>>> that point the offerer does not yet know whether it will become
>>>>>>> DTLS client or server, but it still has to assign identifiers (odd
>>>>>>> or even) to the data channels.
>>>>>>
>>>>>> Good point. At that point there should be no risk of conflict with
>>>>>> DCEP.
>>>>>> Maybe a revision is needed to deal with that.
>>>>>
>>>>> Yes.
>>>>>
>>>>> And, if DCEP is then later used to create another data channel, it
>>>>> needs to make sure that it does not re-use the same identifier (no
>>>>> matter if it is odd or even).
>>>>>
>>>>>>> Once the DTLS roles have been determined, the DCEP rules work fine
>>>>>>> also for SDP.
>>>>>>>
>>>>>>> (Personally I have never seen a use-case where both DCEP and SDP
>>>>>>> are used to create and manage data channels.)
>>>>>>
>>>>>> It is hard to envision a use case for it. But as I recall we were
>>>>>> trying to avoid precluding it. One alternative would be for the SDP
>>>>>> negotiation to include the choice of either DCEP or SDP for
>>>>>> negotiating data channels.
>>>>>> But
>>>>>> could that be done in a backward compatible way?
>>>
>>> The usage of dcmap does indicate such choice in my opinion.
>>>
>>> But, again, I cannot guarantee that there are no implementation that
>>> use both SDP and DCEP within the same session.
>>>
>>>>>> If we were able to verify that there is currently no concurrent use
>>>>>> in the wild then perhaps we could amend to say that use of SDP to
>>>>>> negotiate data channels precludes use of DCEP.
>>>>>
>>>>> It is difficult to verify that.
>>>>>
>>>>> But, as discussed above, if we say that in case of ACTPASS the
>>>>> offerer can choose either an odd or even value.
>>>>
>>>> It sounds to me like this is something you'd want to discuss should a
>>>> -bis document ever become a reality, but not confirm the erratum
>>>> as-is.  Is that correct?  If so, then we want "Hold For Document
>>>> Update" rather than "Verified" for this one, correct?
>>>
>>> We can discuss whether we should fix this using a -bis or an erratum.
>>>
>>> But, the current erratum should not be agreed in its current form.
>>>
>>> I think the first thing we need to do is how the solution would look
>>> like: the easiest solution would be to simply that say:
>>>
>>> 1)	If one uses SDP one SHOULD/MUST NOT use DCEP
>>> 2)	Remove the even/odd requirement when using SDP (at least when
>> using
>>> ACTPASS)
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>>
>> ietf.org%2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
>> ber
>>>
>> g%40ericsson.com%7Cb1e38f9c6c404579285108dc54696c5c%7C92e84cebfb
>> fd47ab
>>>
>> be52080c6b87953f%7C0%7C0%7C638478058969825780%7CUnknown%7CT
>> WFpbGZsb3d8
>>>
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>> D%7C0
>>>
>> %7C%7C%7C&sdata=2F2msSXLsc9axwanuxC7N4%2B6w%2FwYD4cv9NqjTm3f
>> OsE%3D&res
>>> erved=0
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>> etf.org%2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
>> berg%40ericsson.com%7Cb1e38f9c6c404579285108dc54696c5c%7C92e84ce
>> bfbfd47abbe52080c6b87953f%7C0%7C0%7C638478058969838191%7CUnkn
>> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1xdEPMYo26r5ZizOpgZ
>> UB%2Fs34kJB3PqN%2B4KcydN6LTQ%3D&reserved=0