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

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

This discussion looks promising. I would like to see two sequences of 
actions for successful use of the data channel for the subprotocol 
"t140",  one by use of SDP plus the WebRTC API, and one only using only 
the WebRTC API.   Plus an indication of what was needed to be done in 
the case with SDP that is different from what RFC 8864/8865 results in.  
And a discussion if anything special needs to be done for any collision 
case.

Bernard, yes RFC 8865 is mentioned in ETSI drafts, and I would like to 
see this issue sorted out before this draft goes for approval.

RFC 8865 is also mentioned as the WebRTC solution for RTT in RFC 9248.

Regards

Gunnar

Den 2024-04-04 kl. 16:11, skrev Bernard Aboba:
> 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
>     <http://ietf.org>%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]
>     >>
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>     >> etf.org
>     <http://etf.org>%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]
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

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