Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for SctpTransport (and big picture diagram) #25

aboba opened this issue Jan 31, 2014 · 5 comments

Proposal for SctpTransport (and big picture diagram) #25

aboba opened this issue Jan 31, 2014 · 5 comments


Copy link

aboba commented Jan 31, 2014

From: Peter Thatcher
Subject: Proposal for SctpTransport (and big picture diagram)
Date: Thu, 23 Jan 2014 09:55:25 -0800

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:

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);

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

var channel = sctp.createDataChannel({...});

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

var sctp = new RTCSctpTransport(dtls);

// 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") {

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.

Copy link
Contributor Author

aboba commented Jan 31, 2014

Copy link

piranna commented Jan 31, 2014

Your proposal for DataChannels seems good to me.

2014-01-31 aboba

Big picture URL:

Reply to this email directly or view it on GitHub

"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

Copy link
Contributor Author

aboba commented Feb 4, 2014

[Bernard Aboba]
RTCRtpCapabilities is referenced in the RtpSender/RtpReceiver split proposal (,
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

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

Copy link
Contributor Author

aboba commented Feb 7, 2014

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


Copy link
Contributor Author

aboba commented Feb 15, 2014

Please review the fixes relating to this issue in the latest ORTC Editor's draft:

If there are any remaining concerns, please post these to the mailing list.

@aboba aboba closed this as completed Feb 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants