W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

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

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 22 Jun 2015 15:32:33 -0700
Message-ID: <CAJrXDUFrpJWWM6i06OkOVmmVpdsPwHEfxsHgJr3gUsQLfrbQ2A@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
FYI, based on feedback, I have:

1. Renamed getNominatedCandidatePair to getSelectedCandidatePair.
2. Change RtpSender.rtcpTransport and RtpReceiver.rtcpTransport to be null
when RTCP mux is enabled, rather than making it === .transport.
3.  Left a "failed" state for DtlsTransport.

On Fri, Jun 19, 2015 at 2:49 PM, Peter Thatcher <pthatcher@google.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 Monday, 22 June 2015 22:33:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC