Re: Proposal for SctpTransport (and big picture diagram)

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

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:


[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;
}

Received on Sunday, 2 February 2014 03:38:42 UTC