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

I have changed the PR so there is only one SctpTransport per
PeerConnection.  It's much smaller now :).


How, for the fun part, the bikeshedding!


Do we want

Option A: PeerConnection.sctpTransport

or

Option B: PeerConnection.sctp

?



.sctpTransport is more like ".transport"
.sctp is shorter and more like ".dtmf"


I prefer Option B, ".sctp", so have put that in the PR.  If you prefer a
different color of shed, please let me know.



On Tue, Aug 25, 2015 at 5:58 PM, Justin Uberti <juberti@google.com> wrote:

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