Closed Bug 1324788 Opened 8 years ago Closed 6 years ago

Update RTCIceCandidateStats to spec


(Core :: WebRTC, defect, P2)




Tracking Status
firefox53 --- affected
firefox65 --- fixed


(Reporter: jib, Assigned: ng)


(Blocks 2 open bugs)


(Keywords: dev-doc-complete, site-compat)


(1 file)

From henbos in :

"The Chrome and Firefox localcandidate/remotecandidate are similarly incorrect, e.g. have "ipAddress" and "portNumber" instead of spec's "ip" and "port", so given that Firefox is updated with hyphens it makes sense to update this too."

Bug 1322503 presents an opportunity to fix this dictionary to be spec compliant. At present `candidateType` appears to be the lone member which name has not changed in the spec [1][2].

Rank: 15
Priority: -- → P1
FWIW for time reasons, I'm less worried about missing members like `url` than I am about keeping legacy names around forever. If we can demote legacy names to the non-hyphenated version only, that would be a win IMHO.
Assignee: nobody → na-g
This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Keywords: stale-bug
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Looks like this fell off our radar. We missed the opportunity that was bug 1322503 here. In hindsight, I should have marked it as a blocking that bug, not dependent on it.

Let's see if we can piggyback on bug 1380555's timeframe for this.
Blocks: 1380555
Keywords: stale-bug
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #0)
> At present `candidateType` appears to be the lone member which
> name has not changed in the spec [1][2].

Not so. See

candidateType's enum values are now incompatible, and conflict with the spec (and Chrome's).

The spec has: "host", "srflx", "prflx", "relay"
We have [1]:  "host", "serverreflexive", "peerreflexive", "relayed"

We need to up-prioritize fixing our code to spec names. This will break existing users of ice stats in Firefox. :-/ 

Nils, thoughts?

Flags: needinfo?(drno)
there is a chance that existing users *might* check for the old names because chrome legacy stats used this.
I just shaved of some  code for chrome legacy stats on appearin but still had to keep type checks for both "relay" and "relayed"
If not someone has a great idea how to temporarily maintain backwards compatibility I would be in favor of just switching to the spec and announce what we do widely.
Flags: needinfo?(drno)
Keywords: site-compat
Bug 1489040 is a sub set of this, renaming ipAddress to ip.
No longer blocks: 1508543
Depends on: 1508543
Blocks: 1508543
Depends on: 1489040
No longer depends on: 1508543
Spec Notes: there are 3 RTCIceCandidateStats fields that are in the spec that are not implemented after this:
* deleted[0]: this field has open issue about removing this field,
* url[1]: this field will be implemented in bug 1508543,
* networkType[2]: the privacy properties of this field are still being debated.

Bug 1324788 - P1 - rename RTCIceCandidate stat "portNumber" to spec "port"
Bug 1324788 - P2 - update RTCIceCandidateStats candidateType enum to spec
Bug 1324788 - P3 - add RTCIceCandidatePair.priority stat
Bug 1324788 - P4 - update WebRTC ICE candidate stats field componentId to spec name transportId
Bug 1324788 - P5 - remove deprecated RTCIceCandidateStats.mozLocalTransport field
Bug 1324788 - P6 - update WebRTC ICE candidate stats field transport to spec name, protocol
Bug 1324788 - P7 - remove deprecated RTCIceCandidateStats.candidateId
Bug 1324788 - P8 - reorder RTCIceCandidateStats dictionary members to match the spec
Pushed by
Bug 1324688 - Bring RTCIceCandidateStats up to spec r=mjf,jib,smaug
Attachment #9027618 - Attachment description: Bug 1324688 - Bring RTCIceCandidateStats up to spec → Bug 1324788 - Bring RTCIceCandidateStats up to spec
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Note to MDN writers:

I've added a note to the Fx65 rel notes to cover this:

In terms of the docs, the RTCIceCandidateStats main interface page looks to be in good shape; I think sheppy updated the information on there (and the compat data) recently. It would be nice to more completely flesh out the subpages though.

The main page should be up-to-date, as should all of the existing subpages. A number of subpages for properties of the RTCIceCandidateStats object need to be written still.

Progress going forward will be covered on this issue on GitHub:

You need to log in before you can comment on or make changes to this bug.