Rename "updateICE" to "setConfiguration", everywhere except in Blink.

Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in
Blink, once it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is
functional, and will allow an application to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

updateIce will no longer be tracked after this CL, which should be ok
since it has always been nonfunctional and stats show zero use.

BUG=chromium:587453
Committed: https://crrev.com/08110857fc26f4a0a0725edef75ea658a9d4a4c8
Cr-Commit-Position: refs/heads/master@{#438206}

[Taylor_Brandstetter, 2016-11-17 02:01:20]

deadbeef@chromium.org changed reviewers:
+ foolip@chromium.org, perkj@chromium.org, tommyw@chromium.org

[Taylor_Brandstetter, 2016-11-17 02:01:21]

tommyw@chromium.org: Please review changes in test_runner/ and WebKit/Source/

foolip@chromium.org: Please review changes in WebKit/public/

perkj@chromium.org: Please review changes in 
content/renderer/media/

And please add any other reviewers you feel are necessary.

[foolip, 2016-11-17 10:10:54]

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl
(right):

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl:87:
[CallWith=ExecutionContext, RaisesException] void setConfiguration
(RTCConfiguration configuration);
This is great, if the implementation already does what
https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-setconfiguration says
then we should totally ship it.

Because this changes the web-exposed API, it'll need an "Intent to Ship". And
removing updateIce below will need an "Intent to Deprecate and Remove". See
https://www.chromium.org/blink#launch-process

Tests for setConfiguration will be needed as well, things like checking that
InvalidStateError is thrown if the connection is closed, and the many
InvalidModificationError cases in
https://w3c.github.io/webrtc-pc/#set-pc-configuration

I would suggest, for this CL, to do everything except the IDL changes, so that
when you do the web-exposed changes, it's a minimal CL that can be reverted if
stuff breaks.

Nit: extra space before (.

[foolip, 2016-11-17 10:11:52]

foolip@chromium.org changed reviewers:
+ guidou@chromium.org, hbos@chromium.org

[foolip, 2016-11-17 10:11:52]

Adding guido@ and hbos@ who've been reviewing here lately.

[foolip, 2016-11-17 10:13:40]

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
(left):

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp:821: //
Constraints are ignored.
Ah, right given this you could keep these changes but add
ImplementedAs=setConfiguration for updateIce in the IDL file.

[hbos_chromium, 2016-11-17 15:06:52]

Looks good, but a couple of things:

updateIce is currently exposed to the web, removing it could break existing
products relying on its existence. The right steps are to add and ship
setConfiguration and then if the usage counts of updateIce become low remove it
separately. I think we started measuring it (with "Measure" in
RTCPeerConnection.idl) quite recently so I don't know if the stats are reliable
yet, but this [1] says nobody is using it? If almost nobody is using it then we
can just remove it, but doing so separately is a good idea in case you have to
revert.

This CL lacks tests. See third_party/WebKit/LayoutTests/fast/peerconnection/
[2]. There are a bunch of tests there. I don't see any for updateIce? There
should be tests for setConfiguration. Prefer using "testharness.js" (which e.g.
this [3] uses) to "js-test.js" (which e.g. this [4] uses).



FYI about testing:

How to run layout tests if your output directory is "out/gn":
ninja -C out/gn blink_tests
third_party/WebKit/Tools/Scripts/run-webkit-tests -t gn
fast/peerconnection/RTCPeerConnection.html
Run with --reset-results to replace -expected.txt file. The tests pass or fail
depending on if there is a diff between the run and a previous run stored as
-expected.txt.

This script eats up printfs, if you want to debug and see printfs run this
instead:
out/gn/Content\ Shell.app/Contents/MacOS/Content\ Shell --run-layout-test
fast/peerconnection/RTCPeerConnection.html

I believe layout tests uses MockWebRtcPeerConnectionHandler so it is limited in
what it can test (it does not run code all the way down to webrtc repo), but you
should test stuff like feeding in the wrong parameters should throw the
appropriate exception according to spec and feeding it the right parameters
should not throw an exception.

(A test that tests the functionality fully, all the way down to the webrtc repo,
would be a browser test [5] using peerconnection.js [6] and friends, but that is
probably overkill assuming setConfiguration is already tested in the webrtc
layer and considering that would be a lot of work.)

[1] https://www.chromestatus.com/metrics/feature/timeline/popularity/1647
[2]
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/peer...
[3]
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/peer...
[4]
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/peer...
[5]
https://cs.chromium.org/chromium/src/chrome/browser/media/webrtc/webrtc_brows...
[6]
https://cs.chromium.org/chromium/src/chrome/test/data/webrtc/peerconnection.j...

[Taylor_Brandstetter, 2016-11-17 21:31:16]

On 2016/11/17 15:06:52, hbos_chromium wrote:
> updateIce is currently exposed to the web, removing it could break existing
> products relying on its existence.

It has always just thrown an exception, which is probably why no one is using it
according to the stats.

> I believe layout tests uses MockWebRtcPeerConnectionHandler so it is limited
in
> what it can test (it does not run code all the way down to webrtc repo), but
you
> should test stuff like feeding in the wrong parameters should throw the
> appropriate exception according to spec and feeding it the right parameters
> should not throw an exception.

Wait, does this mean that input validation code needs to be duplicated between
chromium and webrtc? This may be fine for simple things, but there are some
cases where it's completely infeasible, like SDP parsing.

[Taylor_Brandstetter, 2016-11-17 21:32:53]

I removed the IDL changes from this CL. I'll make those changes and add the JS
tests in a follow-up CL.

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
(left):

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp:821: //
Constraints are ignored.
On 2016/11/17 10:13:40, foolip wrote:
> Ah, right given this you could keep these changes but add
> ImplementedAs=setConfiguration for updateIce in the IDL file.

Done.

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl
(right):

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl:87:
[CallWith=ExecutionContext, RaisesException] void setConfiguration
(RTCConfiguration configuration);
On 2016/11/17 10:10:54, foolip wrote:
> This is great, if the implementation already does what
> https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-setconfiguration says
> then we should totally ship it.

It doesn't do everything yet. Things it doesn't yet do:

- Candidate pool size (implemented in WebRTC library, just not added to
blink::RTCConfiguration).
- Changing the ICE ufrag/password in the next call to createOffer, as described
by JSEP.
- Throwing the right DOMExceptions. This is a problem with all PeerConnection
APIs; we don't currently have a mechanism to get an error reason from the native
library.

I thought these things could be considered bugs and fixed over time. Do any of
these absolutely need to be fixed before shipping it? I guess that's what the
"Intent to Ship" would reveal?

> 
> Because this changes the web-exposed API, it'll need an "Intent to Ship". And
> removing updateIce below will need an "Intent to Deprecate and Remove". See
> https://www.chromium.org/blink#launch-process

I do have an old "Intent to Deprecate and Remove":
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/setconfig...

> Tests for setConfiguration will be needed as well, things like checking that
> InvalidStateError is thrown if the connection is closed, and the many
> InvalidModificationError cases in
> https://w3c.github.io/webrtc-pc/#set-pc-configuration

Is it ok if these tests fail at first? (see above)

> I would suggest, for this CL, to do everything except the IDL changes, so that
> when you do the web-exposed changes, it's a minimal CL that can be reverted if
> stuff breaks.

Reverted IDL changes.

[perkj_chrome, 2016-11-18 08:31:08]

content/renderer lgtm

[foolip, 2016-11-18 08:56:06]

https://codereview.chromium.org/2511633002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
(right):

https://codereview.chromium.org/2511633002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp:804:
const Dictionary& mediaConstraints,
Remove the argument name to make it obvious that it's unused. (Removing it from
the IDL would be observable in a very small way, so probably clean do that when
removing updateIce.)

[foolip, 2016-11-18 08:58:43]

On 2016/11/17 21:31:16, Taylor_Brandstetter wrote:
> On 2016/11/17 15:06:52, hbos_chromium wrote:
> > updateIce is currently exposed to the web, removing it could break existing
> > products relying on its existence.
> 
> It has always just thrown an exception, which is probably why no one is using
it
> according to the stats.
> 
> > I believe layout tests uses MockWebRtcPeerConnectionHandler so it is limited
> in
> > what it can test (it does not run code all the way down to webrtc repo), but
> you
> > should test stuff like feeding in the wrong parameters should throw the
> > appropriate exception according to spec and feeding it the right parameters
> > should not throw an exception.
> 
> Wait, does this mean that input validation code needs to be duplicated between
> chromium and webrtc? This may be fine for simple things, but there are some
> cases where it's completely infeasible, like SDP parsing.

If third_party/webrtc already has exactly the error handling steps in
https://w3c.github.io/webrtc-pc/#set-pc-configuration then keeping it in one
place and just propagating the error is probably best. I assume that isn't the
case however. I guess that'll be a question for shipping setConfiguration().

[foolip, 2016-11-18 09:16:05]

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl
(right):

https://codereview.chromium.org/2511633002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.idl:87:
[CallWith=ExecutionContext, RaisesException] void setConfiguration
(RTCConfiguration configuration);
On 2016/11/17 21:32:52, Taylor_Brandstetter wrote:
> On 2016/11/17 10:10:54, foolip wrote:
> > This is great, if the implementation already does what
> > https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-setconfiguration says
> > then we should totally ship it.
> 
> It doesn't do everything yet. Things it doesn't yet do:
> 
> - Candidate pool size (implemented in WebRTC library, just not added to
> blink::RTCConfiguration).
> - Changing the ICE ufrag/password in the next call to createOffer, as
described
> by JSEP.
> - Throwing the right DOMExceptions. This is a problem with all PeerConnection
> APIs; we don't currently have a mechanism to get an error reason from the
native
> library.
> 
> I thought these things could be considered bugs and fixed over time. Do any of
> these absolutely need to be fixed before shipping it? I guess that's what the
> "Intent to Ship" would reveal?

It's fine to ship with some known issues, if fixing them is itself
risky/non-trivial or an orthogonal concern of sorts.

It sounds like supporting iceCandidatePoolSize would be easy, but that affects
the RTCPeerConnection constructor also, so if it's not easy, or if it's not
obvious that supporting it is even a good idea, then leaving that is fine I
think.

Overall, the most important question is whether the implementation is
interoperable with other implementations, or, if it's the first, if it's in
close conformance with the spec and tests, so that the next implementation will
not have to reverse engineer.

> > Because this changes the web-exposed API, it'll need an "Intent to Ship".
And
> > removing updateIce below will need an "Intent to Deprecate and Remove". See
> > https://www.chromium.org/blink#launch-process
> 
> I do have an old "Intent to Deprecate and Remove":
>
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/setconfig...

Oh, I'd forgotten about that. If it's still true that it always throws, then I'd
add an entry to chromestatus.com and update that thread saying that you're now
going to remove updateIce without a deprecation period.

For setConfiguration, because it wasn't super clear, perhaps it's best to send a
new Intent to Ship. With that, if you want to make all of the changes in a
single CL like this, that seems fine. Getting them all in the same release would
be good at least.

> > Tests for setConfiguration will be needed as well, things like checking that
> > InvalidStateError is thrown if the connection is closed, and the many
> > InvalidModificationError cases in
> > https://w3c.github.io/webrtc-pc/#set-pc-configuration
> 
> Is it ok if these tests fail at first? (see above)

Per above, yes, see e.g.
third_party/WebKit/LayoutTests/imported/wpt/webrtc/rtcpeerconnection/rtcpeerconnection-constructor-expected.txt
for some failing tests of the RTCPeerConnection constructor that I recently
unprefixed.

(Note that this test is from web-platform-tests, for Blink-only tests it's
preferred to test the actual behavior and not the spec'd behavior.)

[foolip, 2016-11-18 09:17:27]

If you're going to land this CL first, can you update the description to match
the changes being made?

[hbos_chromium, 2016-11-18 15:11:17]

Ah, updateIce really does nothing.
(https://cs.chromium.org/chromium/src/third_party/webrtc/api/peerconnectionint...)

That should make removing it simple. However, this change would change updateIce
from doing nothing to actually calling setConfiguration. That might make some
people start to use it!

Can we have these changes without changing the behavior of updateIce?

I think it's OK to change its implementation to do the equivalent of what
happens when webrtc::PeerConnectionInterface::updateIce returns false if that
makes things simpler and so that it can be removed from the webrtc repo.

[Taylor_Brandstetter, 2016-11-18 20:04:25]

Description was changed from

==========
Rename obsolete "updateICE" method to "setConfiguration".

UpdateIce was never functional in the first place (in the native webrtc
library). SetConfiguration is, and allows you to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

BUG=chromium:587453
==========

to

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in Blink, once
it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is functional,
and will allow an applicationto change the set of ICE servers and ICE candidate
policy. Soon, also the ICE candidate pool size.

BUG=chromium:587453
==========

[Taylor_Brandstetter, 2016-11-18 20:06:55]

Description was changed from

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in Blink, once
it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is functional,
and will allow an applicationto change the set of ICE servers and ICE candidate
policy. Soon, also the ICE candidate pool size.

BUG=chromium:587453
==========

to

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in Blink, once
it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is functional,
and will allow an applicationto change the set of ICE servers and ICE candidate
policy. Soon, also the ICE candidate pool size.

BUG=chromium:587453
==========

[Taylor_Brandstetter, 2016-11-18 20:07:08]

Description was changed from

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in Blink, once
it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is functional,
and will allow an applicationto change the set of ICE servers and ICE candidate
policy. Soon, also the ICE candidate pool size.

BUG=chromium:587453
==========

to

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in Blink, once
it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is functional,
and will allow an application to change the set of ICE servers and ICE candidate
policy. Soon, also the ICE candidate pool size.

BUG=chromium:587453
==========

[Taylor_Brandstetter, 2016-11-18 20:07:56]

Alright, this CL will now produce no web-visible changes.

https://codereview.chromium.org/2511633002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
(right):

https://codereview.chromium.org/2511633002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp:804:
const Dictionary& mediaConstraints,
On 2016/11/18 08:56:05, foolip wrote:
> Remove the argument name to make it obvious that it's unused. (Removing it
from
> the IDL would be observable in a very small way, so probably clean do that
when
> removing updateIce.)

Done.

[hbos_chromium, 2016-11-21 09:13:04]

lgtm

https://codereview.chromium.org/2511633002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
(right):

https://codereview.chromium.org/2511633002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp:822: //
m_peerHandler->setConfiguration.
This will now no longer track updateIce
(RTCPeerConnectionHandler::setConfiguration doing
peer_connection_tracker_->Track[UpdateIce/SetConfiguration]) but I think that is
OK considering this always failed anyway and there is no conceivable use case
for this function as implemented, and the stats we do have are 0.

(If other reviewers mind you can simply comment out
rtc_peer_connection_handler.cc:1398 instead (replace return
native_peer_connection_->SetConfiguration with return false) and move the TODO
comment there.)

[hbos_chromium, 2016-11-21 09:17:56]

https://codereview.chromium.org/2511633002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
(right):

https://codereview.chromium.org/2511633002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp:822: //
m_peerHandler->setConfiguration.
On 2016/11/21 09:13:04, hbos_chromium wrote:
> This will now no longer track updateIce
> (RTCPeerConnectionHandler::setConfiguration doing
> peer_connection_tracker_->Track[UpdateIce/SetConfiguration]) but I think that
is
> OK considering this always failed anyway and there is no conceivable use case
> for this function as implemented, and the stats we do have are 0.
> 
> (If other reviewers mind you can simply comment out
> rtc_peer_connection_handler.cc:1398 instead (replace return
> native_peer_connection_->SetConfiguration with return false) and move the TODO
> comment there.)

If you land as-is (up to you) take a note of this in the CL description.
Also nit: prefer to keep a 76 line length in the CL description so that git log
fits in a 80 character terminal window.

[Taylor_Brandstetter, 2016-11-28 18:11:11]

Description was changed from

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in Blink, once
it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is functional,
and will allow an application to change the set of ICE servers and ICE candidate
policy. Soon, also the ICE candidate pool size.

BUG=chromium:587453
==========

to

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in
Blink, once it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is
functional, and will allow an application to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

updateIce will no longer be tracked after this CL, which should be ok
since it has always been nonfunctional and stats show zero use.

BUG=chromium:587453
==========

[Taylor_Brandstetter, 2016-11-28 18:11:22]

The CQ bit was checked by deadbeef@chromium.org

[Taylor_Brandstetter, 2016-11-28 18:11:23]

The patchset sent to the CQ was uploaded after l-g-t-m from perkj@chromium.org
Link to the patchset: https://codereview.chromium.org/2511633002/#ps40001
(title: "Making sure updateIce doesn't change behavior in this CL.")

[commit-bot: I haz the power, 2016-11-28 18:12:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-28 18:22:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-28 18:22:18]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Taylor_Brandstetter, 2016-12-05 19:01:42]

foolip and tommyw: Can you take another look? Updated CL description.

[hbos_chromium, 2016-12-06 09:50:56]

On 2016/12/05 19:01:42, Taylor_Brandstetter wrote:
> foolip and tommyw: Can you take another look? Updated CL description.

tommyw is OOO, if nobody else is covering ownership for him you'll want to get
another reviewer.

[Taylor_Brandstetter, 2016-12-06 19:26:11]

deadbeef@chromium.org changed reviewers:
- tommyw@chromium.org

[Taylor_Brandstetter, 2016-12-06 19:27:13]

deadbeef@chromium.org changed reviewers:
+ dmazzoni@chromium.org

[Taylor_Brandstetter, 2016-12-06 19:27:13]

dmazzoni@chromium.org: Please review changes in test_runner

[foolip, 2016-12-07 16:02:46]

Explicitly leaving this to other reviewers. Looking forward to the web facing
changes :)

[Guido Urdaneta, 2016-12-12 09:44:01]

lgtm

[dmazzoni, 2016-12-12 18:32:46]

lgtm for test_runner

[foolip, 2016-12-13 11:03:33]

third_party/WebKit/public/platform/WebRTCPeerConnectionHandler.h lgtm

[foolip, 2016-12-13 11:04:04]

The CQ bit was checked by foolip@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-13 11:04:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-13 12:32:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-13 12:32:18]

Dry run: This issue passed the CQ dry run.

[Taylor_Brandstetter, 2016-12-13 17:26:48]

The CQ bit was checked by deadbeef@chromium.org

[commit-bot: I haz the power, 2016-12-13 17:27:16]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-13 17:31:25]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1481650008559730,
"parent_rev": "d231c60cd1f8f33b788bef5734214ef3841e4d7e", "commit_rev":
"9db47ec83e13b1410a76ccc83ed99b5e3176308e"}

[commit-bot: I haz the power, 2016-12-13 17:33:00]

Description was changed from

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in
Blink, once it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is
functional, and will allow an application to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

updateIce will no longer be tracked after this CL, which should be ok
since it has always been nonfunctional and stats show zero use.

BUG=chromium:587453
==========

to

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in
Blink, once it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is
functional, and will allow an application to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

updateIce will no longer be tracked after this CL, which should be ok
since it has always been nonfunctional and stats show zero use.

BUG=chromium:587453

Review-Url: https://codereview.chromium.org/2511633002
==========

[commit-bot: I haz the power, 2016-12-13 17:33:07]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-12-13 17:34:14]

Description was changed from

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in
Blink, once it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is
functional, and will allow an application to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

updateIce will no longer be tracked after this CL, which should be ok
since it has always been nonfunctional and stats show zero use.

BUG=chromium:587453

Review-Url: https://codereview.chromium.org/2511633002
==========

to

==========
Rename "updateICE" to "setConfiguration", everywhere except in Blink.

This CL prepares for later renaming updateIce to setConfiguration in
Blink, once it has an Intent to Ship.

updateIce was never functional in the first place (in the native webrtc
library), always throwing the same exception. SetConfiguration is
functional, and will allow an application to change the set of ICE
servers and ICE candidate policy. Soon, also the ICE candidate pool
size.

updateIce will no longer be tracked after this CL, which should be ok
since it has always been nonfunctional and stats show zero use.

BUG=chromium:587453

Committed: https://crrev.com/08110857fc26f4a0a0725edef75ea658a9d4a4c8
Cr-Commit-Position: refs/heads/master@{#438206}
==========

[commit-bot: I haz the power, 2016-12-13 17:34:15]

Patchset 3 (id:??) landed as
https://crrev.com/08110857fc26f4a0a0725edef75ea658a9d4a4c8
Cr-Commit-Position: refs/heads/master@{#438206}