Add support for negotiating datachannels in SDP (RFC8864)

[murillo128]

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:

enum RTCDataChannelNegotiation  {
  "decp",
  "sdp",
  "app"
};

dictionary RTCDataChannelInit {
  (boolean or RTCDataChannelNegotiation) negotiated = false;
};

If the negotiated attribute is a boolean, we keep current behaviour and if it is a RTCDataChannelNegotiation:

• dcep current in-band negotiation
• sdp negotiated via SDP dcmap attribute as of RFC8864
• app current out-of-band negotiation

[murillo128]

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

1. Let channel be the RTCDataChannel object for which the user agent could not create an underlying data transport.

2. Set channel.[[ReadyState]] to "closed".

3. Fire an event named error using the RTCErrorEvent interface with the errorDetail attribute set to "negotation-failure" at channel.

4. Fire an event named close at channel.

[mondain]

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?

[murillo128]

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

[mondain]

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

[alvestrand]

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.

[aboba]

Can't an application do negotiation on its own without a change to the API?