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

[Christer Holmberg <[e-mail]>]

Hi,

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

I am not sure what you mean by "cannot be implemented in browsers".

As Harald said: the application has to parse the SDP and use createDataChannel() with "negotiated" set to true.

Regards,

Christer







 
> On Thu, Apr 4, 2024 at 5:28 AM Harald Alvestrand <[e-mail]
> <mailto:[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
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.
> github.io%2Fwebrtc-pc%2F%23dom-rtcdatachannelinit-
> negotiated&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b
> 7d3acb94df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%
> 7C0%7C0%7C638478366751279448%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 0%7C%7C%7C&sdata=7J%2BB%2BP80o1iMG3D8pgfgVvH26gmI6NEbOgKmR0
> tSDQA%3D&reserved=0> ) 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
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.
> github.io%2Fwebrtc-pc%2F%23dom-rtcdatachannelinit-
> id&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b7d3acb9
> 4df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> %7C638478366751295137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C
> %7C&sdata=DnKd6pxN44GL1ZVyLSHW%2BGIJYvJrCrdPIYF5rwu7jJY%3D&rese
> rved=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.
> 
> 	> 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
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .rfc-editor.org%2Frfc%2Frfc8832%23section-
> 6&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b7d3acb9
> 4df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> %7C638478366751306293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C
> %7C&sdata=xRO9CAbdJSgoiw3q%2Fsmlg63afLsvuhfswpJdr8tK%2B%2FU%3D
> &reserved=0>  - "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] <mailto:mmusic-
> [e-mail]> > On Behalf Of Harald Alvestrand
> 	>> Sent: Thursday, 4 April 2024 8.38
> 	>> To: [e-mail] <mailto:[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] <mailto:[e-mail]>
> 	>>>
> 	>>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> %2F&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b7d3ac
> b94df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7
> C0%7C638478366751313768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C&sdata=RVatVsJp4gyQDdFEW6RrblCmNtVcVJfR73wjG2IILy4%3D&reser
> ved=0> .
> 	>>>
> 	>> ietf.org
> <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
> g%2F&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b7d3a
> cb94df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%
> 7C0%7C638478366751319840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=2Ej0A7%2B26fqmz%2BxHH57mMXb7OV83nrnL%2FIeHWdk
> FN6Y%3D&reserved=0>
> %2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
> 	>> ber
> 	>>>
> 	>> g%40ericsson.com <http://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] <mailto:[e-mail]>
> 	>>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .i%2F&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b7d3a
> cb94df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%
> 7C0%7C638478366751325704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=jgWiHmf33GDDLf8tRoJ%2FTpVVo7tV2cNouXXvdsmVbLw%3
> D&reserved=0>
> 	>> etf.org
> <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.or
> g%2F&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C5933b7d3a
> cb94df4e1c408dc54b1159c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%
> 7C0%7C638478366751331510%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=KewYggp1WtxKXL4VcrU3qEAHVOUXejl3XDYiGrGuK2U%3D&r
> eserved=0>
> %2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
> 	>> berg%40ericsson.com <http://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] <mailto:[e-mail]>
> 	https://www.ietf.org/mailman/listinfo/mmusic
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
> berg%40ericsson.com%7C5933b7d3acb94df4e1c408dc54b1159c%7C92e84c
> ebfbfd47abbe52080c6b87953f%7C0%7C0%7C638478366751337360%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=n39%2FherwejvI82ZfO
> uU1JBOnH5lX2Bu5w7vIWYiAkTg%3D&reserved=0>
>