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

On Mon, Jun 22, 2015 at 3:14 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> 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.
>
>
>
Yes, I think there should be a failed state.

-Ekr


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