1307994 - Implement the RTCIceTransport interface

Status: NEW

(Core :: WebRTC: Networking, enhancement, P3)

Description

[Nils Ohlmeier [:drno]]

According to the latest webrtc spec we should add the RTCIceTransport object.
https://w3c.github.io/webrtc-pc/#rtcicetransport-interface

Personally I don't see the missing implementation of this as a big deal, because a lot of information exposed through the RTCIceTransport object can be accessed today already.
But it's mostly a getter object, so the effort to implement it should not be too high any way.

Comment 1

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 2

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 3

[Eric Shepherd [:sheppy]]

There are a few things that could be useful in RTCIceCandidate. In particular, the selectedcandidatepairchange event to get notifications as the ICE agent finds new, better candidates, for purposes of analysis, debugging, and possibly other tasks.

It also provides a convenient way to get a complete look at the set of candidates that have been considered, which otherwise you'd have to record them all yourself as they come through on their way to and fro.

I don't think there's anything critical, but it would still likely be convenient in a few cases.

Comment 4

[Byron Campen [:bwc]]

Some stuff that will be part of this bug:

RTCIceTransport.role: Does not actually reflect the current role of the ICE agent. It only reflects what the default role is based on SDP negotiation. In other words, role conflict resolution within ICE is not taken into account. This means we do not need to teach MediaTransportHandler and friends to expose the role of the ICE component.

RTCIceTransport.component: Is not the ICE component that shows up in candidates, it is either "rtp" or "rtcp".

RTCIceTransport.state/onstatechange: We already have the API on MediaTransportHandler for this, so this part should be fairly easy.

RTCIceTransport.gatheringState/ongatheringstatechange: We'll need to teach MediaTransportHandler and friends to have a separate ICE gathering state for each transport. Right now this is a single state for the entire ICE ctx, all the way down to nICEr.

RTCIceTransport.getLocalCandidates(): MediaTransportHandler has the callbacks to tell us what these are, so this part should be fairly easy. DO NOT try to use the stats API for this.

RTCIceTransport.getRemoteCandidates(): We can just keep track of this ourselves as we pass these to MediaTransportHandler.

RTCIceTransport.getSelectedCandidatePair()/onselectedcandidatepairchange: We'll need to teach MediaTransportHandler and friends to fire notifications when the selected candidate pair changes (right now we can learn this from stats, but we do not want to have to do this with polling).

RTCIceTransport.getLocalParameters(): Spec says these get set by setLocalDescription (in the queued success task, presumably), so we can ask the JSEP engine when that happens.

RTCIceTransport.getRemoteParameters(): Spec says these get set by setRemoteDescription, similar to the above.

Comment 5

[Byron Campen [:bwc]]

I should note that the fact that webrtc-pc mandates rtcp-mux means that RTCIceTransport.component will always be "rtp", and even if webrtc-pc did not mandate this, there is no place an rtcp RTCIceTransport would even be exposed to JS.

Comment 6

[Byron Campen [:bwc]]

It is possible that we could build some of this state using JsepIceTransport/JsepTransport. It looks like the remote candidates are there, at least.

Comment 7

[Byron Campen [:bwc]]

It looks fairly likely that this work will interact significantly with bug 1468993. I'm not yet sure which we should do first.

Comment 8

[Byron Campen [:bwc]]

There are probably some opportunities for wpt improvements here, including:

Negotiation that adds/removes transports should cause the appropriate state change events.
State changes/events are batched appropriately and in the correct order.

Comment 9

[Jim Mathies [:jimm]]

Have we implemented everything here or just state?

https://developer.mozilla.org/en-US/docs/Web/API/RTCIceTransport

Comment 10

[Byron Campen [:bwc]]

We've implemented |state|, |gatheringState|, and the event targets for changes to those two.