W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: Proposal for SctpTransport (and big picture diagram)

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Sun, 2 Feb 2014 03:38:12 +0000
To: "public-orca@w3.org" <public-orca@w3.org>
Message-ID: <98f0e96c57cb42ff9dfa05822672f5ed@SN2PR03MB031.namprd03.prod.outlook.com>
Peter --

The Big Picture diagram is great.  

A question about RTCDataChannelParameters.

Now that we have allowed a Data Channel to be connected to
a transport, I am wondering whether some parameters in 
RTCDataChannelParameters shouldn't be parameters of the transport

For example, in WebRTC 1.0 DataChannelInit, protocol refers to the
sub-protocol, but that might or might not make sense depending on
the transport.  

Does it make sense to have RTCSctpParameters? 

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:

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;
Received on Sunday, 2 February 2014 03:38:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC