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

We should probably be consistent with how the properties for other
transports, e.g. IceTransport and DtlsTransport, are named. Looking at PR
https://github.com/w3c/webrtc-pc/pull/241/files, everything is named
.transport.

.transport is clearly too general for something on PeerConnection, so I
prefer either A, .sctpTransport, or a new Option C, .dataTransport.

On Tue, Aug 25, 2015 at 6:18 PM, Peter Thatcher <pthatcher@google.com>
wrote:

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