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

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.

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

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

Received on Friday, 19 June 2015 21:50:45 UTC