Open murillo128 opened 2 years ago
the question is how to deal with a datachannel that has been rejected by the remote peer. Maybe something like:
https://www.w3.org/TR/webrtc/#error-on-creating-data-channels
Let channel be the RTCDataChannel object for which the user agent could not create an underlying data transport.
Set channel.[[ReadyState]] to "closed".
Fire an event named error using the RTCErrorEvent interface with the errorDetail attribute set to "negotation-failure" at channel.
Fire an event named close at channel.
I'm curious as to why we'd need these options, as well as sdp
being confusing since the datachannel is included in the SDP as part of the offer/answer regardless of how it's set up. Something like dcmap
would be better while also signaling support for the mapping features. The DCEP chunk could also certainly be expanded to include additional options or just using supported extensions would work as well: I'm guessing "exposure" is really what's needed on the javascript-side?
Not sure exactly if your concerns are about the values of the enum or about the need for this mechanism. If it is about the values in the enum, I am perfectly find to change the sdp
by dcmap
or any other string that feels appropriate.
What do you mean by "supported extensions"?
Yes, the enums, for clarity. By supported extensions I mean the widely used FORWARDTSN
and RE-CONFIG
entries coordinated currently with browsers; info in various RFC's. Good list here for the two listed on IANA https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml
Speaking as contributor ... I thought this was a bad idea when 8864 was written (and said so), I still think it's a bad idea, and we shouldn't provide an API for it, any more than we provide API for the GSMA extensions, multiple SCTP transports, or other things that you can do with SDP.
It will take a quite compelling use case to change my mind.
Can't an application do negotiation on its own without a change to the API?
Currently in W3C we are able to negotiate datachannels either inband in DCEP, or outband by the js APP.
https://www.w3.org/TR/webrtc/#dom-rtcdatachannelinit-negotiated
RFC8864 allows to negotiate it via SDP, which wouldn't be supported by curren API.
Not sure if it it is a valid WebIDL, but we could have something like this:
If the
negotiated
attribute is a boolean, we keep current behaviour and if it is aRTCDataChannelNegotiation
:dcep
current in-band negotiationsdp
negotiated via SDPdcmap
attribute as of RFC8864app
current out-of-band negotiation