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

[Christer Holmberg <[e-mail]>]

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?

> 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
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.gi
> thub.io%2Fwebrtc-pc%2F%23dom-rtcdatachannelinit-
> id&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C3bd0b5c63c86
> 470f330f08dc54a2bc12%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> %7C638478305114832628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C
> %7C&sdata=HbedMunDcF%2Fvy7YawmqPo%2FFBhqi7kjeflQWO185SXvQ%3
> D&reserved=0, 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.

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.


>> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r
> fc-editor.org%2Frfc%2Frfc8832%23section-
> 6&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C3bd0b5c63c864
> 70f330f08dc54a2bc12%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%
> 7C638478305114842622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> 7C&sdata=abmJjGn3q%2BlNwEzFmus3t4NE61qKW7ttfhEPQ53NLgg%3D&res
> erved=0 - "The peer that
> initiates opening a data channel selects a stream identifier for which
> the corresponding incoming and outgoing streams are unused. "

The sentence after that says:

"If the side is acting as the DTLS client, it MUST choose an even stream 
identifier; if the side is acting as the DTLS server, it MUST choose an odd 
one."

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
> %2F&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C3bd0b5c63c
> 86470f330f08dc54a2bc12%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7
> C0%7C638478305114851485%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C&sdata=%2FE3aEfS8xmgzBFNY5CXvLk1RDBXecvJsKbVc69SiZKU%3D&re
> served=0.
> >>>
> >>
> 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
> %2F&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C3bd0b5c63c
> 86470f330f08dc54a2bc12%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7
> C0%7C638478305114856829%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C&sdata=RsDs%2BEU%2FgG89wdfvIBTzss5XRNEPkJ8DbkMxnxivV5c%3D
> &reserved=0
> >>
> 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