Re: Proposal for SctpTransport (and big picture diagram)

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?

Stefan

On 23/01/14 18:55, "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.

Received on Friday, 24 January 2014 10:12:08 UTC