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

And while fixing some phantomjs errors, I also realized that I was creating
a duplicated RTCIceCandidate dictionary even though there is an existing
RTCIceCandidate interface.  Rather than try to resolve the duplication, I
simply removed the dictionary which I had added.  The RTCIceCandidatePair
now simply has two of the existing RTCIceCandidate interfaces.  So my
question #3 is obselete, which means that all of the questions are now
resolved.

On Mon, Jun 22, 2015 at 3:32 PM, Peter Thatcher <pthatcher@google.com>
wrote:

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