W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2014

Proposal for SctpTransport

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 03 Nov 2014 21:28:39 +0000
Message-ID: <CAJrXDUEsvhbj502dTbNMYHzhXx2UmLQR4VOAcMwr3Ru4nvuzJg@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
At TPAC (2014), we dicussed the possibility of an "SCTP doohickey".  This
would be able to answer the following questions to the JS:

- What is the max message size for the data channel?
- Which DtlsTransport are the data channels going over?
- Which IceTransport are the data channels going over?

For that, I propose we add:

interface RTCSctpTransport {
    readonly attribute RTCDtlsTransport transport;
    unsigned int maxMessageSize;
};

partial interface RTCDataChannel {
    // null until negotiation of the transport is complete
    readonly attributed RTCSctpTransport? transport;
};

Which can be used like this:

// What is the max message size I can use?
var dc = pc.createDataChannel();
dc.transport.maxMessageSize;

// What DTLS transport is my data going over?
dc.transport.transport;  // dtls

// What ICE transport is my data going over?
pc.transport.transport.transport;  // ice


That last bit is slightly ugly, and if it mattered enough, we could make it
something like:
dc.transport.dtls;
dc.transport.ice;

But I don't think it's worth it to do so.


Now, I do have a question to ask the group:  Should we also have
RTCPeerConnection.getDataTransport()?  It seems like it would only be
useful to have one if we can have a data transport without having a data
channel, and that doesn't seem very useful to me.  Is there a worthwhile
use case?
Received on Monday, 3 November 2014 21:29:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC