Proposal for SctpTransport (and big picture diagram)

[aboba]

From: Peter Thatcher pthatcher@google.com
To: public-orca@w3.org
Subject: Proposal for SctpTransport (and big picture diagram)
Date: Thu, 23 Jan 2014 09:55:25 -0800
URL: http://lists.w3.org/Archives/Public/public-orca/2014Jan/0033.html

A missing piece of the current ORTC API is SCTP data channels. I think this part of WebRTC 1.0 is pretty good, with the exception of its dependence on SDP and PeerConnection. I propose we add a createDataChannel method and a ondatachannel event similar to the one on WebRTC 1.0's PeerConnection. But instead of adding it to directly to DtlsTransport, we create an SctpTransport which wraps a DtlsTransport, like so:

[Constructor(RTCDtlsTransport)]
interface RTCSctpTransport {
attribute RTCDtlsTransport transport;

static RTCSctpCapabilities getCapabilities();

void start(RTCSctpCapabilities remoteCaps);
void stop();

DataChannel createDataChannel(RTCDataChannelParameters);
EventHandler ondatachannel;
}

dictionary RTCSctpCapabilities {
int maxMessageSize;
}

// Same as WebRTC 1.0 DataChannelInit
dictionary RTCDataChannelParameters {
boolean outOfOrderAllowed;
unsigned short maxRetransmitTime;
unsigned short maxRetransmitNum;
DOMString protocol;
boolean preset;
unsigned short stream;
}

This is similar to the good parts of WebRTC 1.0, but also signals
every thing without SDP, hooks up to DtlsTransport nicely, and gives the programmer easy control of which transport to use (shared with media or not). Furthermore, it allows future expansion into other types of data channels, or data channels built on other types of transports.

Here is an example of how it would be used:

function initiate(signaller) {
var dtls = ...; // See ICE/DTLS example.
var sctp = new RTCSctpTransport(dtls);

signaller.sendInitiate({
// ... include ICE/DTLS info from other example.
sctpCapabilities: RTCSctpTransport.getCapabilities()
}, function(remote) {
sctp.start(remote.sctpCapabilities);
});

var channel = sctp.createDataChannel({...});
channel.send("foo");
}

function accept(signaller, remote) {
var dtls = ...; // See ICE/DTLS example.
signaller.sendAccept({
// ... include ICE/DTLS info from other example.
"sctpCapabilities": RTCSctpTransport.getCapabilities()
});

var sctp = new RTCSctpTransport(dtls);
sctp.start(remote.sctpCapabilties);

// Assume in-band signalling. We could also easily add
// RTCDataChannelParameters into the out-of-band signalling
// And call .createDataChannel here with negotiated: true.

sctp.ondatachannel = function(channel) {
channel.onmessage = function(message) {
if (message == "foo") {
channel.send("bar");
}
}
}

Altogether, if our proposals for RtpSender, RtpReceiver, IceTransport, DtlsTransport, and SctpTransport are accepted, the overall picture would look like the one attached.

[Stefan Hakansson]
That picture looks fine.

Two questions:

1. What about sharing: can several SCTPTransports and several
   RtpTransports share DTLSTransport? Can several DTLSTransports share ICETransport?
2. Where would the IdentityProvider attach?

[Peter Thatcher]
Several RtpSenders and RtpReceivers can share a DtlsTransport, as long as the RtpReceivers can demux according to ssrc/payload-type/header-extension.

I think there can only be one SctpTransport per DtlsTransport at a time, because I don't know if there is a way to demux multiple SCTP associations over a shared DTLS connection. Maybe SCTP port number? Or non-overlapping SIDs? But that all sounds like extra complexity without much benefit. You could, I think, have different SctpTransports on top of the DtlsTransport at different times (stop one and start another), but I'm not sure if there's a good use case for that.

Similarly for DtlsTransport and IceTransport, you can only have one DtlsTransport per IceTransport at a time because we don't have a way to demux multiple DTLS connections over one ice connection. You could, I think, have different DtlsTransports on top of the IceTransport at different times (stop one and start another), but I'm not sure if there's a good use case for that. The reverse might be more useful: you could have different IceTransports under a DtlsTransport at different times, as a mechanism for doing JS-triggered ICE warming or ICE restarts. The API I proposed doesn't support that right now, but it could be added if we found value in it.

1. Where would the IdentityProvider attach?

On the DtlsTransport, I think. But I'll leave that to people who know more about IdP than me.

[aboba]

Big picture URL: http://lists.w3.org/Archives/Public/public-orca/2014Jan/att-0033/ortc-big-picture.svg

[piranna]

Your proposal for DataChannels seems good to me.

2014-01-31 aboba notifications@github.com

Big picture URL:
http://lists.w3.org/Archives/Public/public-orca/2014Jan/att-0033/ortc-big-picture.svg

Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-33846927
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."

• Linus Tordvals, creador del sistema operativo Linux

[aboba]

[Bernard Aboba]
RTCRtpCapabilities is referenced in the RtpSender/RtpReceiver split proposal (http://lists.w3.org/Archives/Public/public-orca/2014Jan/0000.html),
but is only defined in this proposal. Any more thoughts on "Codecs" and "stuff"? For example, is "Codecs" referring to sequence codecs; ?

[Peter Thatcher]
Bernard asked me what I thought the RTCRtpCapabilities should look like. Here's what I think they should look like:

dictionary RTCRtpCapabilities {
sequence audioCodecs;
sequence videoCodecs;
sequence headerExtensions; // Just the URIs
sequence features;
}

dictionary RTCRtpCodec {
DOMString name; // aka MIME media type
int? clockrate;
int? channels;
sequence formatParameters; }

dictionary KeyValueParam {
DOMString key;
DOMString value;
};

enum RTCRtpFeatures {
"nack", // from RFC 4585,
// ...
}

This is a lot like the existing RTCCodec, with the following notable
differences:

• There are two lists of codecs: one audio and one video. I suppose we could mix them together, but I think it's more convenient this way.
• The RTCCodec doesn't have a specific payload type, because that's not part of a "capability".
• There are header extensions in the capabilities.
• There are "rtp features" in the capabilities, with a list we can expand on later.

It still lacks RED and FEC, though, and I think we'd want to nail down how those would fit into the RTCRtpCapabilities. Are they an RTCRtpFeature, or a new dictionary type?

In short, it's an expansion of the existing RTCCodec to match the new RtpSender/RtpReceiver model.

[aboba]

An updated "Big Picture" (adding the ice listener):

[aboba]

Please review the fixes relating to this issue in the latest ORTC Editor's draft:
http://ortc.org/wp-content/uploads/2014/02/ortc.html

If there are any remaining concerns, please post these to the public-orca@w3.org mailing list.