Re: PR for adding RTCSctpTransport, PeerConnection.getSctpTransports(), and RTCDataChannel.transport

On Mon, Aug 24, 2015 at 2:47 PM, Randell Jesup <randell-ietf@jesup.org>
wrote:

> On 8/24/2015 5:42 PM, Bernard Aboba wrote:
>
>
>
> *Peter asked: *
>
>
>
> “So, the big questions for the WG are:
>
>
>
> 1.    Should we allow multiple SctpTransports per PeerConnection?
>
> [BA] Personally, I don’t see a need for this.
>
>
> Multiple SctpTransports - that would require extra complexity for
> createDataChannel, etc.
>

createDataChannel would be the same.  It's the PeerConnection/SctpTransport
that would be slightly more complex, since a PeerConnection would have more
than on SctpTransport.




> What's the usecase?  What's the advantage?  Right now I don't see anything
> compelling here, but perhaps there's a usecase I'm not considering.
>

​At IETF 93, the desire to have different properties on different data
channels that are really per-association was raised (I believe priority was
the property in question).  So if you had multiple SctpTransports, it would
allow multiple associations and different per-association properties for
each one.

If we say "In 1.0, there is only 1 SctpTransport;  Save multiple
SctpTransports for 1.1", I'd be fine with that, too.  But when I wrote the
PR, I thought was worth seeing how it would look, and after I wrote it, I
thought, "well, that's not so bad, why not allow it?".

​



> --
> Randell Jesup -- rjesup a t mozilla d o t com
> Please please please don't email randell-ietf@jesup.org!  Way too much spam
>
>