Gecko bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1116766

Changed label to PeerConnection, since this is more a Blink issue than an ICE protocol issue.

Use counters:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1656
https://www.chromestatus.com/metrics/feature/timeline/popularity/1657

Usage the singular url member is just a little bit lower than for the plural urls member. I would recommend trying to standardize what is implemented, it's simple enough and it doesn't seem worthwhile breaking anything in order to get rid of it.

people not moving toward .urls and sticking to .url is merely a sign that there is not enough effort to point out the need :-/

Allow multiple ICE servers was a change made in the spec in 2013. urls has been implemented in Chrome for a long time, the closest indicator I can find is https://bugs.chromium.org/p/webrtc/issues/detail?id=2832 which was three years ago.

But is it worth anyone's time to do this advocacy, and how many years will it take? There are plenty of interop problems in WebRTC to work on, and this is one that can be fixed simply be accepting both the old and the new form in a standardized manner.

Mozilla has been advocating against .url with a console warning for a very long time. Maybe Chrome should start doing the same?

This is the least of WebRTCs interop problems. If its impossible to solve an issue this tiny (and hey, its a simple as adding one character) then I guess the harder problems like moving people away from the stream based model to the track based model.

We generally don't add deprecation messages in Chrome as a way to change usage, because it doesn't seem to work, or at least not work well enough that it makes the difference between removing and not removing. If we want to remove something, we instead have to understand what the usage in the wild looks like, and what it would take to change it. Sometimes it's possible to update a single library and wait for a year, and sometimes it's just game over.

There are indeed much larger interop problems for both browser developers and web developers to worry about, which is why I wouldn't spend any time trying to avoid two dictionary members here. However, I'm just giving my perspective, it's the WebRTC team that has to decide what the best use of time is.

What does the usage counter do if there is both .url and .urls?

changing a library: let me try... ;-)

The use counter for singular url is only hit if the value is actually used, which is if there is no plural urls member.

great, that is a useful counter definition!

For the test you might want to check that when supplying .url (or .urls) stun.l.google.com:19302 results in a onicecandidate with a candidate that has 'typ sdp' in it somewhere. This would assert that its actually hooked up but depends on something external :-/

I know that singular url is treated like plural urls with a single entry in both Blink and Gecko from the code, but I can't confirm that for Edge. I can't come up with a test involving "stun:stun.l.google.com:19302" that doesn't throw an exception in Edge. But the url member behaves differently that a banana member, so it's most likely a similar kind of alias.

argh, I forgot that Edge doesn't support stun (https://github.com/webrtc/adapter/blob/master/src/js/edge/edge_shim.js#L36) so the test doesn't work. I'll check later today.

> I would recommend trying to standardize what is implemented

"What is implemented" where? just in Chrome / libwebrtc?

I'm sorry but things work the other way around: vendors should implement what the specifications standardize. And it happens that Google actively takes part in those standardizations so your argument makes zero sense.

Please, implement the standards no matter how your current code looks like.

> "What is implemented" where? just in Chrome / libwebrtc?

When handling the RTCIceServer dictionary, if there is no urls member but there is a url member, the url member is used instead, and behaves as if an array with that single string were used for the urls member. This is true in at least Blink and Gecko, and EdgeHTML does *something* with the url member, likely the same thing.

> I'm sorry but things work the other way around: vendors should implement what the specifications standardize.

Often when there's some discrepancy between spec and implementation, changing the spec is part of the solution. I recently wrote a document describing how I approach these problems, that might provide some background:
https://docs.google.com/document/d/1LSuLWJDP02rlC9bOlidL6DzBV5kSkV5bW5Pled8HGC8/edit?usp=sharing

We are talking about a so simple transition from `url` to `urls` (array). IMHO it's not so difficult to just let the standardized `urls` entry and warn users about it. The warning message would be something like:

"urls exists for 3 years, come on!"

Also, this is a very simple task for adapter.js (which probably already handles it anyway).

As described in http://www.chromium.org/blink/removing-features, deprecation without a known date for removal is strongly discouraged. It doesn't reliably drive down usage, and creates uncertainty about what action is required.

Anyway, if the WebRTC team decides they'd like to take the standardization approach, we can discuss all of this in a spec issue, because it affects the other vendors as well.

P.S. Updating popular libraries is sometimes effective, but it depends on the upgrade habits of those using the libraries, and it's never fast. https://www.chromestatus.com/metrics/feature/timeline/popularity/217 is a good example, I updated all libraries that I could find, including jQuery, and years later usage hasn't even decreased by a factor of 10.

inaki: I just made a PR for adapter which will do this. The issue is smaller than you think, RTCIceServer.urls is defined as (DOMString or sequence<DOMString>)

> The issue is smaller than you think, RTCIceServer.urls is defined as (DOMString or sequence<DOMString>)

True. So easy.

after some digging: 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22347 has the discussion that led to the change.
https://lists.w3.org/Archives/Public/public-webrtc/2013Jun/0074.html shows some of the rationale for moving to .uris. I do not think that rationale has changed so this is still a change which needs to happen.

The rationale and the change that was made was about allowing multiple URLs, which now works, but it does not require removing the url member, as evidenced by what is currently shipping.

Edge 15 support both url and urls it seems. You have to feed it with a valid turn url and username/credential

> Usage the singular url member is just a little bit lower than for the plural urls member.

Your usage numbers seem to be url 0.018 (37%) vs. urls 0.030 (63%).

> deprecation without a known date for removal is strongly discouraged.

What's your process for determining that date?

As comment 10 mentions, we think warnings and advocacy help move the needle used to set the end date, and I think the numbers reflect that here. Requiring an end-date first seems a bit of a chicken and egg problem.

> What's your process for determining that date?

Once we think that removal is going to work out, we usually go with deprecation in one milestone and removal in the next. More milestones with the deprecation message before removal may be used if we think web developers will need more time to adapt to the change. 

> As comment 10 mentions, we think warnings and advocacy help move the needle used to set the end date, and I think the numbers reflect that here. Requiring an end-date first seems a bit of a chicken and egg problem.

I admit that they may have some impact, but it's never seemed to be large enough to make a decisive difference to the compat risk, i.e. end user impact.

I'm not understanding why it's worth much effort to get rid of the url member, given that it's essentially an alias. It'd be like https://dom.spec.whatwg.org/#dom-element-webkitmatchesselector, just another silly thing on the web platform that we live with.

On the merits of url alone, I agree there may be a case for standardizing url (failing connections == bad). Just wondering if it fits into a larger strategy.

Mostly I'm curious about the claim that deprecation warnings are ineffective. Do we have data to back that up? E.g. years of usage numbers that wouldn't budge in spite of deprecation warnings in multiple browsers?

I actually found 63% urls quite impressive given zero behavioral difference, rarity of multi-url servers, and hardly any documentation on it outside the spec. I'd naively attribute that to Firefox console warnings, and some advocacy on e.g. stackoverflow, webrtc samples.

That said, I find it hard to believe the numbers wouldn't have been substantially better had Chrome added these warnings at the same time 3 years ago.

I'm interested in the note about making the url member "not enumerable". Does that mean that checkign if the url member is present won't work, but using it works?

Is there a standard IDL way of declaring a member not enumerable?

With all the junk we have in the "compatibility" section, I'd claim that adding "url" as an alias of "urls" isn't the biggest deal in the world.

What note? I made a note like that yesterday on `remoteId` on a different topic. That was for a property of an `object` produced by getStats, where we're contemplating backward compatibility tricks like that. How would that help here?

> Mostly I'm curious about the claim that deprecation warnings are ineffective. Do we have data to back that up? E.g. years of usage numbers that wouldn't budge in spite of deprecation warnings in multiple browsers?

I became skeptical after failing to see the hoped-for effect in multiple cases.

https://www.chromestatus.com/metrics/feature/timeline/popularity/198 has been deprecated for years in Chrome and the triggering code would throw an exception in Firefox, but there's no trend at all in the usage. The usage is in some library IIRC.

https://www.chromestatus.com/metrics/feature/timeline/popularity/501 was deprecated for a long time in Chrome, and didn't have the hoped-for effect. See https://groups.google.com/a/chromium.org/d/msg/blink-dev/5o0yiO440LM/YGEJBsjUAwAJ

https://www.chromestatus.com/metrics/feature/timeline/popularity/581 has been deprecated for years in both Chrome and Firefox, and while usage is trending downwards, it's nowhere near enough for removal to become feasible.

Meanwhile, some things that aren't deprecated show decreasing usage over time:
https://www.chromestatus.com/metrics/feature/timeline/popularity/53
https://www.chromestatus.com/metrics/feature/timeline/popularity/55
https://www.chromestatus.com/metrics/feature/timeline/popularity/217 (I updated libraries to not use it near the peak of usage)

None of this is conclusive, but cause for doubt. In order to have confidence that deprecation messages have the intended effect, some statistics would be needed. Unless we understand what works and doesn't, deprecating all the things we want to get rid of would invariably result in some things not working out, and web developers having wasted their time heeding our advice.

spec-note that if this is to be brought back there is some prose needed, see 
https://github.com/w3c/webrtc-pc/issues/1251#issuecomment-305777218

Safari Technology preview throws a type error on this:
   var pc = new RTCPeerConnection({iceServers: [{url: "stun:stun.l.google.com:19302"}]})
(it works when using "urls")

I am very much in favor of trying to tip the scales and keen no seeing the impact of this decision on Chrome statistics.

While I was overjoyed to see RTCIceServer.urls double in usage here
    https://www.chromestatus.com/metrics/feature/timeline/popularity/1657
this coincides with M59 starting to roll out last week.

guido: can you check if that metric could be broken somehow?

I looked at the stats:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1657 -- urls: 0.9%
https://www.chromestatus.com/metrics/feature/timeline/popularity/1656 -- url: 0.15%

Is this low enough for Chrome to consider removing? hta@ may have more detailed numbers about the 'ickyness factor' of the 0.15%.