- From: Soares Chen <soares.chen@gmail.com>
- Date: Fri, 1 Dec 2017 15:41:31 +0800
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Received on Friday, 1 December 2017 07:42:14 UTC
On Fri, Dec 1, 2017 at 1:43 AM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: > Why does the RTCIceTransport test depend on the RTCSctpTransport being defined? > > For example, if a browser supports RtpSender/Receiver, DtlsTransport and IceTransport but not SctpTransport couldn't an RTCIceTransport object be obtained from sender.transport.transport ? There was some discussion about this in GitHub issue #1306. [1] In summary there were issues of getting an instance of RTCIceTransport from an RTCRtpsender/Receiver, because the transport attribute there is nullable. At the time of writing the tests, RTCSctpTransport was used for getting instance of RTCIceTransport, because there is a deterministic way that we can be sure that peerconnection.sctp become non-null when setting session description. That wasn't the case for RTCRtpsender/Receiver. It looks like the newer editor's draft now has normative steps in setting session description for setting the transport attributes to set the transport attribute of RTCRtpsender/Receiver. This should make testing it much easier and we can update the tests to retrieve RTCIceTransport instances that way. [1] https://github.com/w3c/webrtc-pc/issues/1306#issuecomment-305681038
Received on Friday, 1 December 2017 07:42:14 UTC