Mostly this consists of marking functions with override when
applicable, and moving function bodies from .h to .cc files.
Not inlining virtual functions with simple bodies such as
{ return false; }
strikes me as probably losing more in readability than we gain in
binary size and compilation time, but I guess it's just like any other
case where enabling a generally good warning forces us to write
slightly worse code in a couple of places.
BUG=163
R=kjellander@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47429004
Cr-Commit-Position: refs/heads/master@{#8656}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8656 4adac7df-926f-26a2-2b94-8c16560cd09d
> Ensure only temporary IPv6 address is selected as the best IP.
>
> The current logic of IPv6 selection could still have a small chance for non-temporary address to be selected for candidate. The scenario is that when there is no non-deprecated temporary IP, the global ones could be selected.
>
> Global ones don't necessarily carry MAC. However, instead of comparing whether it has the MAC in it (sometimes 5 out of 6 elements from a MAC are the same, only one diffs), we should just err on the safe side.
>
> BUG=4348
> R=juberti@webrtc.org, pthatcher@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/38289004TBR=guoweis@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38319004
Cr-Commit-Position: refs/heads/master@{#8534}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8534 4adac7df-926f-26a2-2b94-8c16560cd09d
The current logic of IPv6 selection could still have a small chance for non-temporary address to be selected for candidate. The scenario is that when there is no non-deprecated temporary IP, the global ones could be selected.
Global ones don't necessarily carry MAC. However, instead of comparing whether it has the MAC in it (sometimes 5 out of 6 elements from a MAC are the same, only one diffs), we should just err on the safe side.
BUG=4348
R=juberti@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38289004
Cr-Commit-Position: refs/heads/master@{#8532}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8532 4adac7df-926f-26a2-2b94-8c16560cd09d
WebRTC binds to individual NICs and listens for incoming Stun packets. Sending stun through this specific NIC binding could make OS route the packet differently hence exposing non-VPN public IP.
The fix here is
1. to bind to any address (0:0:0:0) instead. This way, the routing will be the same as how chrome/http is.
2. also, remove the any all 0s addresses which happens when we bind to all 0s.
BUG=4276
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39129004
Cr-Commit-Position: refs/heads/master@{#8418}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8418 4adac7df-926f-26a2-2b94-8c16560cd09d
PeerConnectionTest.java currently works, but only on a device with
network interfaces up. This is not a problem for desktop, but it is a
problem when running on Android devices since the devices in the lab
generally don't have network (due to the chaotic radio environment in
the device labs, devices are simply kept in flight mode).
The test does work if one modifies this line in the file
webrtc/base/network.cc:
bool ignored = ((cursor->ifa_flags & IFF_LOOPBACK) ||
IsIgnoredNetwork(*network));
If we remove the IFF_LOOPBACK clause, the test starts working on
an Android device in flight mode. This is nice - we're running the
call and packets interact with the OS network stack, which is good
for this end-to-end test. We can't just remove the clause though since
having loopback is undesirable for everyone except the test (right)?
so we need to make this behavior configurable.
This CL takes a stab at a complete solution where we pass a boolean
all the way through the Java PeerConnectionFactory down to the
BasicNetworkManager. This comes as a heavy price in interface
changes though. It's pretty out of proportion, but fundamentally we
need some way of telling the network manager that it is on Android
and in test mode. Passing the boolean all the way through is one way.
Another way might be to put the loopback filter behind an ifdef and
link a custom libjingle_peerconnection.so with the test. That is hacky
but doesn't pollute the interfaces. Not sure how to solve that in GYP
but it could mean some duplication between the production and
test .so files.
It would have been perfect to use flags here, but then we need to
hook up gflags parsing to some main() somewhere to make sure the
flag gets parsed, and make sure to pass that flag in our tests.
I'm not sure how that can be done.
Making the loopback filtering conditional is exactly how we solved the
equivalent problem in content_browsertests in Chrome, and it worked
great.
That's all I could think of.
BUG=4181
R=perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36769004
Cr-Commit-Position: refs/heads/master@{#8344}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8344 4adac7df-926f-26a2-2b94-8c16560cd09d
Currently, in ipc_network_manager.cc, the UMA WebRTC.PeerConnection.IPv4Interfaces and its IPv6
counter part counts the addresses, instead of the interfaces as when
chromium delivers available networks to WebRTC, each address is wrapped
inside an individual network object.
The plan is to replace the current MergeNetworkList with the new one once it's rolled into chromium.
BUG=
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36779004
Cr-Commit-Position: refs/heads/master@{#8188}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8188 4adac7df-926f-26a2-2b94-8c16560cd09d
Expose adapter_type from Candidate such that we could add jmidata on top of this.
Created a new type of report just for Ice candidate. The candidate's id is used as part of report identifier. This code change only reports the best connection's local candidate's adapter type. There should be cleaning later to move other candidate's attributes to the new report.
This is migrated from issue 32599004
BUG=
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36379004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7885 4adac7df-926f-26a2-2b94-8c16560cd09d
1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Committed: https://code.google.com/p/webrtc/source/detail?r=7200
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7201 4adac7df-926f-26a2-2b94-8c16560cd09d
1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7200 4adac7df-926f-26a2-2b94-8c16560cd09d
