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

I agree that single SctpTransport for 1.0 is the right way to go. We
already have the ability to have multiple data channels on a transport, so
having N channels * M transports isn't buying us much.

And if we decide we need multiple transports later for some reason, the
cost of backtracking on this issue would be low.

On Mon, Aug 24, 2015 at 2:56 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> 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
>>
>>
>