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

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.





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.

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