- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 19 Jun 2015 14:49:36 -0700
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUECw-fnMCc35wRRrVLGz85Cx3JiwAXacCKwMJxwhTdUew@mail.gmail.com>
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