If a port is not used by any channel and if it has no connection for 30
seconds, it will be removed.
Note, as long as a port is used by a transport channel, it will be kept
even if it does not have any connection. This will be beneficial to
continual gathering because new connections can be created in the future
when network changes.
BUG=
R=pthatcher@webrtc.org, zhihuang@webrtc.org
Review URL: https://codereview.webrtc.org/2171183002 .
Cr-Commit-Position: refs/heads/master@{#13567}
Logging when a candidate is gathered or the gathering state or a
Port changes. This will make it easier to identify problems related
to candidate gathering.
Review-Url: https://codereview.webrtc.org/2122373004
Cr-Commit-Position: refs/heads/master@{#13490}
we will periodically check if any network does not have any connection on it and if yes, attempt to re-gather on those networks.
BUG=
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2025573002 .
Cr-Commit-Position: refs/heads/master@{#13367}
When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
This effectively reduces the number of TURN candidates and connections created by TURN ports.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2093623004 .
Committed: https://crrev.com/17aac053f585e892114974d2eb248e05ad37f973
Cr-Original-Commit-Position: refs/heads/master@{#13335}
Cr-Commit-Position: refs/heads/master@{#13354}
Reason for revert:
Breaks Win32/Win64 Debug bots in client.webrtc waterfall
Original issue's description:
> Add config to prune low-priority TURN ports for creating connections
> When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
>
> This effectively reduces the number of TURN candidates and connections created by TURN ports.
>
> BUG=
> R=deadbeef@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/17aac053f585e892114974d2eb248e05ad37f973
> Cr-Commit-Position: refs/heads/master@{#13335}
TBR=pthatcher@webrtc.org,deadbeef@webrtc.org,honghaiz@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2111663003
Cr-Commit-Position: refs/heads/master@{#13342}
When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
This effectively reduces the number of TURN candidates and connections created by TURN ports.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2093623004 .
Cr-Commit-Position: refs/heads/master@{#13335}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
This allows webrtc to not gather on cellular networks if wifi or
other low cost networks are present.
BUG=
Review-Url: https://codereview.webrtc.org/1987833002
Cr-Commit-Position: refs/heads/master@{#12979}
According to JSEP, the candidate filter does not affect pooled
candidates because they can be filtered once they're ready to be
surfaced to the application.
So, pooled port allocator sessions will use a filter of CF_ALL, with a
new filter applied when the session is taken by a P2PTransportChannel.
When the filter is applied:
* Some candidates may no longer be returned by ReadyCandidates()
* Some candidates may no longer have a "related address" (for privacy)
* Some ports may no longer be returned by ReadyPorts()
To simplify this, the candidate filtering logic is now moved up from
the Ports to the BasicPortAllocator, with some helper methods to perform
the filtering and stripping out of data.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1998813002 .
Cr-Commit-Position: refs/heads/master@{#12856}
Depends on this CL in order to work in Chromium:
https://codereview.chromium.org/1976673002/
It works by creating pooled PortAllocatorSessions which can be picked up
by a P2PTransportChannel when needed (after a local description is set).
This can optimize candidate gathering time when there is some time between
creating a PeerConnection and setting a local description.
R=pthatcher@webrtc.org
Committed: 48e9d05f51
Review URL: https://codereview.webrtc.org/1956453003 .
Cr-Commit-Position: refs/heads/master@{#12729}
Reason for revert:
Breaks remoting_unittests. They defined their own operator== which conflicts with this one.
I'll remove the operator== in a roll CL. But until it's approved, I'm reverting this so the FYI bots will pass.
Original issue's description:
> Implement RTCConfiguration.iceCandidatePoolSize.
>
> It works by creating pooled PortAllocatorSessions which can be picked up
> by a P2PTransportChannel when needed (after a local description is set).
>
> This can optimize candidate gathering time when there is some time between
> creating a PeerConnection and setting a local description.
>
> R=pthatcher@webrtc.org
>
> Committed: 48e9d05f51TBR=pthatcher@webrtc.org,honghaiz@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/1972043004
Cr-Commit-Position: refs/heads/master@{#12709}
It works by creating pooled PortAllocatorSessions which can be picked up
by a P2PTransportChannel when needed (after a local description is set).
This can optimize candidate gathering time when there is some time between
creating a PeerConnection and setting a local description.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1956453003 .
Cr-Commit-Position: refs/heads/master@{#12708}
AllocationSequence is responsible for receiving incoming packets on
a shared UDP socket and passing them to the Port objects. TurnPort
may stop sharing UDP socket in which case it allocates a new socket.
AllocationSequence::OnReadPacket() wasn't handling that case properly
which was causing an assert in TurnPort::OnReadPacket().
BUG=webrtc:5757
R=honghaiz@webrtc.org, jiayl@chromium.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1871693004 .
Cr-Commit-Position: refs/heads/master@{#12675}
Reason for revert:
Relanding with compile warning fixed.
Original issue's description:
> Revert of Adding the ability to change ICE servers through SetConfiguration. (patchset #7 id:120001 of https://codereview.webrtc.org/1391013007/ )
>
> Reason for revert:
> Caused compiler warning, breaking Chrome FYI bots.
>
> Original issue's description:
> > Adding the ability to change ICE servers through SetConfiguration.
> >
> > Added a SetIceServers method to PortAllocator. Also added a new
> > PeerConnection Initialize method that takes a PortAllocator, in the
> > hope that we can get rid of PortAllocatorFactoryInterface, since the
> > only substantial thing a factory does is convert the webrtc:: ICE
> > servers to cricket:: versions.
> >
> > Committed: https://crrev.com/d3b26d94399ff539db375a9b84010ee75479d4cf
> > Cr-Commit-Position: refs/heads/master@{#10420}
>
> TBR=pthatcher@webrtc.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/18a944bf0ac9eed872dc009bd58e6bc12c946303
> Cr-Commit-Position: refs/heads/master@{#10421}
TBR=pthatcher@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1414313003
Cr-Commit-Position: refs/heads/master@{#10609}
Reason for revert:
Caused compiler warning, breaking Chrome FYI bots.
Original issue's description:
> Adding the ability to change ICE servers through SetConfiguration.
>
> Added a SetIceServers method to PortAllocator. Also added a new
> PeerConnection Initialize method that takes a PortAllocator, in the
> hope that we can get rid of PortAllocatorFactoryInterface, since the
> only substantial thing a factory does is convert the webrtc:: ICE
> servers to cricket:: versions.
>
> Committed: https://crrev.com/d3b26d94399ff539db375a9b84010ee75479d4cf
> Cr-Commit-Position: refs/heads/master@{#10420}
TBR=pthatcher@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1424803004
Cr-Commit-Position: refs/heads/master@{#10421}
Added a SetIceServers method to PortAllocator. Also added a new
PeerConnection Initialize method that takes a PortAllocator, in the
hope that we can get rid of PortAllocatorFactoryInterface, since the
only substantial thing a factory does is convert the webrtc:: ICE
servers to cricket:: versions.
Review URL: https://codereview.webrtc.org/1391013007
Cr-Commit-Position: refs/heads/master@{#10420}
This change filters out local ports when CF_HOST is not originally specified to prevent these ports from sending out STUN which leaks IP address.
BUG=webrtc:4946
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1378753003 .
Cr-Commit-Position: refs/heads/master@{#10121}
whose network has ever been removed. It is unlikely the sockets/ports/candidates created from
those AllocationSequences will still be valid.
BUG=
Review URL: https://codereview.webrtc.org/1361183004
Cr-Commit-Position: refs/heads/master@{#10093}
There are 2 ways to design this.
1. TCP Only mode: this means that we disable all UDP protocols across board.
2. disallow TURN over UDP. Along with DISABLE_UDP, DISABLE_STUN, we should achieve the same result.
I'm going with #2.
BUG=webrtc:4784
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1311153003 .
Cr-Commit-Position: refs/heads/master@{#9791}
Migrated from https://codereview.webrtc.org/1275703006/ which causes test failures for android. On android, loopback interface was used as local interface to generate candidates. Add a test case to make sure this won't be broken in the future.
Also observed some failures under content_browsertests in chromium.fyi bot but can't repro locally. Might just be temporary test issue.
BUG=webrtc:4517
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1299333003 .
Cr-Commit-Position: refs/heads/master@{#9746}
Adapter enumeration disable should be a concept from Network. Network will be hooked up with media permission (mic/camera) to check whether gathering local address is allowed.
BUG=crbug.com/520101
R=juberti@webrtc.org, pthatcher@webrtc.org
Committed: ba9ab4cd8d
Review URL: https://codereview.webrtc.org/1284113003 .
Cr-Commit-Position: refs/heads/master@{#9735}
This reverts commit 0a2955f227666efd87b2a303a69c083ef801c528.
Revert "In the past, P2PPortAllocator.enable_multiple_routes is the indicator whether we should bind to the any address. It's easy to translate that into a port allocator flag in P2PPortAllocator's ctor. Going forward, we have to depend on an asynchronous permission check to determine whether gathering local address is allowed or not, hence the current way of passing it through constructor approach won't work any more. The asynchronous check will trigger SignalNetowrksChanged so we could only check that inside DoAllocate."
This reverts commit ba9ab4cd8d2e8fbc068dc36b5e6f6331d7deeccf.
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1288843003 .
Cr-Commit-Position: refs/heads/master@{#9729}
Adapter enumeration disable should be a concept from Network. Network will be hooked up with media permission (mic/camera) to check whether gathering local address is allowed.
BUG=crbug.com/520101
R=juberti@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1284113003 .
Cr-Commit-Position: refs/heads/master@{#9728}
Bug 4865: even without STUN/TURN, as long as the peer is on the open internet, the connectivity should work. This is actually a regression even for hangouts.
We need to issue the 0.0.0.0 candidate into Port::candidates_ and filter it out later. The reason is that when we create connection, we need a local candidate to match the remote candidate.
The same connection later will be updated with the prflx local candidate once the STUN ping response is received.
BUG=webrtc:4865
R=juberti@webrtc.org
Review URL: https://codereview.webrtc.org/1274013002 .
Cr-Commit-Position: refs/heads/master@{#9708}
This was already working in most cases, but not for some corner cases:
* If the PORTALLOCATOR_ENABLE_SHARED_SOCKET flag is not set
* If both a STUN server and TURN server are configured
I added unit tests for these cases, and centralized the code that gets
STUN server addresses in order to fix these and any related issues.
BUG=webrtc:4215
Review URL: https://codereview.webrtc.org/1215713003
Cr-Commit-Position: refs/heads/master@{#9596}
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
Committed: https://code.google.com/p/webrtc/source/detail?r=8418
Review URL: https://webrtc-codereview.appspot.com/39129004
Cr-Commit-Position: refs/heads/master@{#8419}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8419 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
