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

That's an interesting idea, to make .rtcpTransport == null when RTCP-mux is
enabled.  That's what ORTC does also.  Perhaps in order to make it more
consistent with stats and ORTC, we should do that.

On Sat, Jun 20, 2015 at 2:47 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  We actually embedded a fair number of these in the stats specification
> some months back.
>
> The names should at least be correlated - as editor of the stats
> specification, I'm probably not the right one to decide which spec to
> suggest changes in; I'm too enamored of my own prose :-)
>
> One worry: In Washington, we decided that in order to make the objects
> simpler for the (normal) RTCP mux case, we would not have a separate
> RtcpTransportStats object; rather, we would have a reference in the
> transport object called "rtcpTransportStatsId", which referenced another
> transport object; when the two were muxed, the rtcp reference would be null.
>
> See
> http://w3c.github.io/webrtc-stats/webrtc-stats.html#transportstats-dict*
>
> It would be nice if we followed the same model in the two specs.
>
>
> On 06/19/2015 11:49 PM, Peter Thatcher 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.
>
>  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
>
>
>