- From: Soares Chen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Jun 2017 03:39:17 +0000
- To: public-webrtc-logs@w3.org
By expensive I mean that the userland JS code would need to do unnecessary works to retrieve the list of IceTransports and DtlsTransports. Due to mux and bundle there might be only one instance of each transport, but the userland code nevertheless have to iterate through all senders/receivers/sctp because there is no guarantee that they are the same transport. I faced this issue during testing, but I suspect this might happen in practice as well. What happen is I try to obtain an instance of IceTransport and DtlsTransport, doesn't matter where they come from, but there is no simple way to get that. - In `RTCRtpSender` and `RTCRtpReceiver`, the `transport` and `rtcpTransport` attributes are nullable. - In `RTCPeerConnection`, the `sctp` attribute is nullable. - If we want to wait for any of these attributes to become non-null, the only option seems to be listen for the `connectionstatechange` event, then iterate through the senders/receivers/sctp to collect the DtlsTransport. - More specifically, the spec doesn't specify when the `transport`, `rtcpTransport`, and `sctp` attributes are set to non-null, and how can application wait for such changes. - The `icegatheringstatechange` and `iceconnectionstatechange` events are useless for this use case. Because any IceTransport created is inaccessible until there is a DtlsTransport connecting to it and attached to a sender/receiver/sctp. - Curiously the spec seems to rely on the same approach to collect list of transports. This can be found in step 5 and 6 of the `close` method of `RTCPeerConnection`. (It has missed the DtlsTransport in `sctp`) - There seems to be a circular dependency on how the spec implement the `connectionstatechange` event. (4.3.1.3) If the peer connection have no idea how many IceTransports and DtlsTransports it has, and that they can be added to any one of the null attributes at any time, then it can only constantly poll for the attribute changes just to fire the event. Surely there are better way to specify how the transports are obtained? -- GitHub Notification of comment by soareschen Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1306#issuecomment-305681038 using your GitHub account
Received on Friday, 2 June 2017 03:39:24 UTC