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

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