Re: Proposal for SctpTransport (and big picture diagram)

On Fri, Jan 24, 2014 at 2:11 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> That picture looks fine.
>
> Two questions:
>
> 1. What about sharing: can several SCTPTransports and several
> RtpTransports share DTLSTransport? Can several DTLSTransports share
> ICETransport?

Several RtpSenders and RtpReceivers can share a DtlsTransport, as long
as the RtpReceivers can demux according to
ssrc/payload-type/header-extension.

I think there can only be one SctpTransport per DtlsTransport at a
time, because I don't know if there is a way to demux multiple SCTP
associations over a shared DTLS connection.  Maybe SCTP port number?
Or non-overlapping SIDs?  But that all sounds like extra complexity
without much benefit.  You could, I think, have different
SctpTransports on top of the DtlsTransport at different times (stop
one and start another), but I'm not sure if there's a good use case
for that.

Similarly for DtlsTransport and IceTransport, you can only have one
DtlsTransport per IceTransport at a time because we don't have a way
to demux multiple DTLS connections over one ice connection.  You
could, I think, have different DtlsTransports on top of the
IceTransport at different times (stop one and start another), but I'm
not sure if there's a good use case for that.  The reverse might be
more useful: you could have different IceTransports under a
DtlsTransport at different times, as a mechanism for doing
JS-triggered ICE warming or ICE restarts.  The API I proposed doesn't
support that right now, but it could be added if we found value in it.

>
> 2. Where would the IdentityProvider attach?
>

On the DtlsTransport, I think.  But I'll leave that to people who know
more about IdP than me.


> 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 18:00:34 UTC