Re: Proposal for SctpTransport (and big picture diagram)

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
ICE).

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
>