Re: PR for adding RtpSender.transport, RtpReceiver.transport, RTCDtlsTransport, RTCIceTransport, etc

On Fri, Jun 19, 2015 at 4:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Jun 19, 2015 at 2:49 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> I just made a PR for adding RtpSender.transport, RtpReceiver.transport,
>> RTCDtlsTransport, RTCIceTransport, etc:
>>
>> https://github.com/w3c/webrtc-pc/pull/241
>>
>>
>> The complete list of things I added is the following.  For full WebIDL,
>> check the PR.
>>
>> RtpSender.transport
>> RtpSender.rtcpTransport (=== .transport with RTCP mux)
>> RtpReceiver.transport
>> RtpReceiver.rtcpTransport (=== .transport with RTCP mux)
>> DtlsTransport
>> DtlsTransport.transport
>> DtlsTransport.state
>> DtlsTransport.getRemoteCertificates()
>> DtlsTransport.onstatechange
>> DtlsTransportState (enum)
>> IceTransport
>> IceTransport.state
>> IceTransport.getNominatedCandidatePair()
>> IceTransport.state
>> IceTransport.onstatechange
>> IceTransport.onnomincatedcandidatepair
>> IceCandidatePair
>> IceCanddiate
>> IceCanddiateProtocol (enum)
>> IceCandidateType (enum)
>>
>>
>> This reflects the consensus we had at TPAC 2014, and subsequent
>> discussions.  However, there are a few things I think we did not have
>> enough discussion on, and I have questions about them:
>>
>> 1.  Should we call it getSelectedCandidatePair(),
>> getNomincatedCandidatePair(), or something else?  In TPAC we said
>> getSelectedCandidatePair(), and in ORTC it's getNominatedCandidatePair().
>> For the PR right now, I went with getNomincatedCandidatePair().  If there's
>> a good reason either way, let me know.  Otherwise, I'll keep the name as it
>> is in ORTC.
>>
>
> nominated seems wrong, since with aggressive nomination there can be
> multiple nominated pairs. Selected or active seem better.
>
>
​
I'm fine with changing it to "getSelectedCandidatePair"
​ (what we had at TPAC 2014)​
.  Does anyone else have an opinion before I change it?

​


>
>
>
>
> 2.  What states should we have in DtlsTransport.state?  I have
>> new/connecting/connected/closed/failed, which closely matches both the ICE
>> state and the ORTC DtlsTransportState.  However, the ORTC state does not
>> have "failed", whereas the ICE state does.  So, I included "failed" even
>> though it's missing in ORTC (or rather, closed the purpose of failed as
>> well).
>>
>
> Well, it certainly can fall, so it should have a state.
>

​Yes, but the question is not "​should failure have state", but rather
"should failure have the closed state, or a separate 'failed'" state.  ICE
has a separate "failed" state, so having one would be more consistent with
ICE.



>
> -Ekr
>
>
>
>
>> 3.  What should the IceCandidate object have in it?  I'd hate to have it
>> be a blob of SDP (we have enough of that already), so I simply copied most
>> of what was in the ORTC IceCandidate dictionary, which is what you would
>> expect:  protocol, type, ip, port, priority, foundation, etc.  I think it's
>> a good fit for what we are trying to accomplish here.   If we go the
>> dictionary route (which I think we should), then we also need to define two
>> no enums: IceCandidateType and IceCandidateProtocol.  I mostly just copied
>> those from ORTC as well (although, it's called IceProtocol there instead of
>> IceCandidateProtocol.  I put IceCandidateProtocol in the PR).
>>
>>
>>
>> If you have opinions about the names and structures here, please let us
>> know.
>>
>> Thanks,
>> Peter
>>
>
>