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

[Bernard Aboba <[e-mail]>]

Harald said:

"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."

[BA] This is the biggest problem with RFC 8864/8865, because it is being
represented in ETSI mandates as a "WebRTC datachannel standard" when in
fact, it is incompatible with WebRTC datachannel implementations and cannot
be implemented in browsers. Yet it was published as a  "Proposed Standard"
even though the "real" RTCWEB protocol specifications required
implementation and demonstrated interoperability prior to publication.

On Thu, Apr 4, 2024 at 5:28 AM Harald Alvestrand <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>