add url attribute to RTCIceCandidate - #2773
Conversation
|
looks like Safari is actually setting a value but returning IP addresses when asked for stun servers with a hostname. That doesn't look like anyone is actually using this so this should still be safe to remove. |
|
Needs a bug filed, or reference to the meeting where we agreed to it. |
|
Since Safari is implementing it, I would prefer we keep the current API and add it to candidate. Plus add a note that we plan to deprecate the event url. |
|
Note - I checked the test for RTCPeerConnectionIceEvent-constructor, and it does check that you can construct an RTCPeerConnectionIceEvent with an URL argument, but never checks that the resulting event has an URL in it. Labelling "test needed" .... |
|
Safari still implementing something that was removed isn't a big problem, no (unless we add a negative test)? Nobody cares about chrome still implementing addStream or RTCIceServer.url. |
|
Seems worth doing a 2-step approach. |
|
@fippo can you update this PR to do a two-stage approach? |
|
Discussed at today's editor meeting. |
c2a93e7 to
6d19262
Compare
|
done. I think I got the amendment right (as a separate commit) |
|
apparently the generation is failing because the framesDropped error hasn't been fixed yet. |
aligning with how this is defined in webrtc-stats https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats-url and add deprecation note to the url attribute on the RTCIceEvent
after w3c/webrtc-pc#2773 decided to deprecate the url in the event.
aligning with how this is defined in webrtc-stats
https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats-url
and add deprecation note to the url attribute on the RTCIceEvent
@youennf since you mentioned this was implemented in Safari, can you please check if it actually shows the correct value? Given the trouble I had reconstructing the url in the lowest layers I would not be surprised if this was the empty strings.
Preview | Diff