Fixing the behavior of the candidate filter with pooled candidates.
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}
diff --git a/webrtc/p2p/base/portallocator.cc b/webrtc/p2p/base/portallocator.cc
index fdf213b..f9f87b0 100644
--- a/webrtc/p2p/base/portallocator.cc
+++ b/webrtc/p2p/base/portallocator.cc
@@ -71,8 +71,10 @@
int component,
const std::string& ice_ufrag,
const std::string& ice_pwd) {
- return std::unique_ptr<PortAllocatorSession>(
+ auto session = std::unique_ptr<PortAllocatorSession>(
CreateSessionInternal(content_name, component, ice_ufrag, ice_pwd));
+ session->SetCandidateFilter(candidate_filter());
+ return session;
}
std::unique_ptr<PortAllocatorSession> PortAllocator::TakePooledSession(
@@ -88,6 +90,9 @@
std::unique_ptr<PortAllocatorSession> ret =
std::move(pooled_sessions_.front());
ret->SetIceParameters(content_name, component, ice_ufrag, ice_pwd);
+ // According to JSEP, a pooled session should filter candidates only after
+ // it's taken out of the pool.
+ ret->SetCandidateFilter(candidate_filter());
pooled_sessions_.pop_front();
return ret;
}
