Re: Proposal for SctpTransport (and big picture diagram)

I like the abstraction here, as it separates the data channel object the
app developer needs to use from the underlying protocol plumbing, similar
to what has been done with MediaStreamTrack and RtpSender.


On Thu, Jan 23, 2014 at 9:55 AM, Peter Thatcher <pthatcher@google.com>wrote:

> A missing piece of the current ORTC API is SCTP data channels.  I
> think this part of WebRTC 1.0 is pretty good, we this 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<DataChannel> 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.
>