Fixing problems with ICE candidate pair prioritization.

Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.

BUG=webrtc:1953, webrtc:2383
R=honghaiz@webrtc.org, pthatcher@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/62351c9923b557b41e90c228ae8c3209a10796c5

[Taylor Brandstetter, 2016-07-07 00:25:38]

Description was changed from

==========
Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.
==========

to

==========
Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.

BUG=webrtc:1953,webrtc:2383
==========

[Taylor Brandstetter, 2016-07-07 00:28:34]

deadbeef@webrtc.org changed reviewers:
+ honghaiz@webrtc.org, pthatcher@webrtc.org

[Taylor Brandstetter, 2016-07-07 00:28:34]

PTAL Peter and Honghai. Especially take a look at the changes to kMatrix.
Remember that the type preference is:

1. Host
2. Peer reflexive
3. Server reflexive
4. Relay

And if there is a choice between a "low<->high" pair and a "high<->low" pair
(such as "stun<->relay" vs "relay<->stun"), the controlling agent's "high<->low"
pair should win.

[honghaiz3, 2016-07-22 20:26:00]

lgtm. Nice fix!

[pthatcher1, 2016-08-08 22:20:30]

https://codereview.webrtc.org/2125823004/diff/20001/webrtc/p2p/base/p2ptransp...
File webrtc/p2p/base/p2ptransportchannel_unittest.cc (right):

https://codereview.webrtc.org/2125823004/diff/20001/webrtc/p2p/base/p2ptransp...
webrtc/p2p/base/p2ptransportchannel_unittest.cc:458: remote_type ==
expected.controlled_type);
I'm so happy to see this cleaned up.

https://codereview.webrtc.org/2125823004/diff/20001/webrtc/p2p/base/port.cc
File webrtc/p2p/base/port.cc (right):

https://codereview.webrtc.org/2125823004/diff/20001/webrtc/p2p/base/port.cc#n...
webrtc/p2p/base/port.cc:782: : ICE_TYPE_PREFERENCE_PRFLX;
It seems like it would make sense to make this fix into its own CL.  What do you
think?

[pthatcher1, 2016-08-08 22:20:45]

lgtm

Nevermind, just go ahead and submit it.

[Taylor Brandstetter, 2016-08-09 16:45:11]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-08-09 16:45:12]

The patchset sent to the CQ was uploaded after l-g-t-m from honghaiz@webrtc.org,
pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2125823004/#ps40001 (title:
"Merge with master.")

[commit-bot: I haz the power, 2016-08-09 16:45:13]

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

[commit-bot: I haz the power, 2016-08-09 17:21:29]

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

[commit-bot: I haz the power, 2016-08-09 17:21:30]

Try jobs failed on following builders:
  linux_ubsan_vptr on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_ubsan_vptr/builds...)

[Taylor Brandstetter, 2016-08-11 21:54:20]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2016-08-11 21:54:27]

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

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

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

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

Try jobs failed on following builders:
  ios32_sim_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios32_sim_dbg/builds/9480)

[commit-bot: I haz the power, 2016-08-11 23:05:20]

Description was changed from

==========
Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.

BUG=webrtc:1953,webrtc:2383
==========

to

==========
Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.

BUG=webrtc:1953,webrtc:2383
R=honghaiz@webrtc.org, pthatcher@webrtc.org

Committed: https://crrev.com/62351c9923b557b41e90c228ae8c3209a10796c5
Cr-Commit-Position: refs/heads/master@{#13734}
==========

[Taylor Brandstetter, 2016-08-11 23:05:20]

Description was changed from

==========
Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.

BUG=webrtc:1953,webrtc:2383
==========

to

==========
Fixing problems with ICE candidate pair prioritization.

The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.

The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.

After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.

BUG=webrtc:1953,webrtc:2383
R=honghaiz@webrtc.org, pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/62351c9923b557b41e90c228a...
==========

[commit-bot: I haz the power, 2016-08-11 23:05:21]

Patchset 4 (id:??) landed as
https://crrev.com/62351c9923b557b41e90c228ae8c3209a10796c5
Cr-Commit-Position: refs/heads/master@{#13734}

[Taylor Brandstetter, 2016-08-11 23:05:22]

Committed patchset #4 (id:60001) manually as
62351c9923b557b41e90c228ae8c3209a10796c5 (presubmit successful).