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

Re: Proposal for SctpTransport (and big picture diagram)

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 18 Feb 2014 13:28:22 -0800
Message-ID: <CAJrXDUHDZ-u-=+HPLDu=Cn2OgvpNubBwEDDeeRLmhnOgeMO+fQ@mail.gmail.com>
To: James Spring <jim.spring@skype.net>
Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-orca@w3.org" <public-orca@w3.org>
On Mon, Feb 17, 2014 at 3:54 PM, James Spring <jim.spring@skype.net> wrote:

>  On Jan 24, 2014, at 9:59 AM, Peter Thatcher <pthatcher@google.com> wrote:
> 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.
> I'm still getting re-engaged with a lot of the WebRTC/ORTC mailings, but I
> have (I hope) a fairly simple question -
>  For ORTC, why is the DataChannel tightly coupled to an SCTP transport?
>  I can understand why for WebRTC 1.0 compatibility.  That said, given the
> number endpoints actually capable of sctp (pretty small -- I believe
> Windows, iOS, and Android don't support it), is there a reason why SCTP is
> the only transport provided for the DataChannel in ORTC?  I could see a
> "MUST" for backward compatibility, but has there been discussions about
> softening that for non-backward compliant implementations?
First, this isn't raw SCTP.  It's SCTP on DTLS on (either TCP or UDP, with

Second, it's the only data transport defined for RTCWEB, there aren't
really any other options for a data channel.

However, we have purposefully made the API flexible such that native apps
or future versions of the spec can have different types of data channels.
The SctpTransport (wrapping a DtlsTransport, wrapping an IceTransport) is
just the first possible implementation.  A native app could have, for
example, a PseudoTcpTransport wrapping a DtlsTransport wrapping an
IceTransport, or a RtpDataTransport wrapping a RawUdpTransport.  Or perhaps
someday, there could be a QuicTransport wrapping an IceTransport.  In other
words, it's *not* tightly coupled, quite the opposite, especially compared
to the WebRTC 1.0 API.

>  Thanks
> -jim spring
Received on Tuesday, 18 February 2014 21:29:30 UTC

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