This CL adds the flag "PORTALLOCATOR_ENABLE_ANY_ADDRESS_PORTS", which will
force the creation of ports not bound to any specific network interface.
These are normally only used when network enumeration fails or is disabled,
but in some circumstances (such as the one the test case adds), they're the
only thing that works.
This will result in extra ports being gathered, which is why it's only enabled
behind a flag for now. In the future, we could probably introduce more
sophisticated "pruning" logic that would lessen the impact of the extra ports
when they're redundant, and make the flag the default.
Some other minor changes that were required to make this use case work:
* Allow a TCPPort to be used for outgoing connections even if it tries and
fails to create a server socket.
* Allow Bind to fail if being called before Connect, and the IP is an "any"
address (0.0.0.0 or ::), since this bind would have been mostly pointless
anyway.
* Prevent P2PTransprotChannel from keeping a "backup" candidate pair using
an "any address" network; we only want this for actual networks.
BUG=webrtc:7798
Review-Url: https://codereview.webrtc.org/2936553003
Cr-Commit-Position: refs/heads/master@{#18578}
Specifically, just like SafeMin() and SafeMax() it handles all
combinations of integer and all
combinations of floating-point arguments by picking a
result type that is guaranteed to be able to hold the result.
This CL also replaces a bunch of std::min + std:max call pairs with
calls to SafeClamp()---the ones that could easily be found by grep
because "min" and "max" were on the same line. :-)
BUG=webrtc:7459
Review-Url: https://codereview.webrtc.org/2808513003
Cr-Commit-Position: refs/heads/master@{#18542}
AsyncStunTCPSocket wasn't firing SignalSentPacket, which the bandwidth
estimator requires for every packet in order to look up send times when
feedback arrives. If the signal isn't fired, it always assumes feedback
is arriving extremely late, and decreases the bandwidth by a factor of
2 until it reaches the minimum of 10kbps.
BUG=webrtc:7717
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2912523003
Cr-Commit-Position: refs/heads/master@{#18279}
The only thing the physical socket server was used for was
"Wait"/"WakeUp", but it could be replaced by a simple rtc::Event.
So, removing this dependency makes things less confusing; the fact that
VirtualSocketServer takes a PhysicalSocketServer may lead someone to
think it uses real sockets internally, when it doesn't.
BUG=None
Review-Url: https://codereview.webrtc.org/2883313003
Cr-Commit-Position: refs/heads/master@{#18172}
For every failing test, the solution was either to do a "has IPv4" check
before the test is run, or avoid depending on real network interfaces
altogether.
This specifically fixes rtc_unittests, peerconnection_unittests, and
webrtc_nonparallel_tests.
BUG=None
Review-Url: https://codereview.webrtc.org/2881973002
Cr-Commit-Position: refs/heads/master@{#18155}
Instead, make the pointer to the associated socket server a
construction time const, and delete its lock.
Introduces a helper class AutoSocketServerThread for code
(mainly tests) which need a socket server associated with
the current thread.
BUG=webrtc:7501
Review-Url: https://codereview.webrtc.org/2828223002
Cr-Commit-Position: refs/heads/master@{#18047}
This is something a well-behaving STUN server shouldn't do, but we shouldn't
crash if it does happen.
Also adding helper function for the common operation of extracting just
the error code out of a STUN packet.
BUG=chromium:708469
Review-Url: https://codereview.webrtc.org/2837133003
Cr-Commit-Position: refs/heads/master@{#17892}
Make all rtc_source_test target that contains tests that
are included in a test executable only be visible to the
rtc_test target. Doing this exposed a couple of errors and
dependency problems that were resolved. Having this could
have prevented duplicated execution of tests like the case that
was recently fixed by deadbeef@ in
https://codereview.webrtc.org/2820263004
New targets:
* //webrtc/modules/rtp_rtcp:fec_test_helper
* //webrtc/modules/rtp_rtcp:mock_rtp_rtcp
* //webrtc/modules/remote_bitrate_estimator:mock_remote_bitrate_observer
The mock files and targets should probably be moved into webrtc/test in
the future, but that's out of the scope of this CL.
BUG=webrtc:5716
NOTRY=True
Review-Url: https://codereview.webrtc.org/2828793003
Cr-Commit-Position: refs/heads/master@{#17863}
The dependency on third_party/expat/ is removed.
The dependency on third_party/jsoncpp is removed from
libjingle_peerconnection while peerconnection_client still
depends on it.
BUG=webrtc:7516
Review-Url: https://codereview.webrtc.org/2832283002
Cr-Commit-Position: refs/heads/master@{#17848}
The signal was only being hooked up for incoming connections, not
outgoing connections.
As a result, the bandwidth estimator didn't know when packets were sent
and couldn't calculate delays.
BUG=webrtc:7509
Review-Url: https://codereview.webrtc.org/2834083002
Cr-Commit-Position: refs/heads/master@{#17817}
Introduce new small header-only targets in system_wrappers:
:cpu_features_api
:field_trial_api
:metrics_api
to untangle and optimize dependencies but still satisfy GN check.
In webrtc/p2p, previously uncovered header "base/fakecandidatepair.h"
is added to :p2p_test_utils target.
Refactor system_wrappers so 'rtc_p2p' can depend on only
system_wrappers:field_trial_api instead of all of system_wrappers
(which led to a breakage in Chromium that called for the revert of
https://codereview.webrtc.org/2735583002).
BUG=webrtc:6828
NOTRY=True
Review-Url: https://codereview.webrtc.org/2739863002
Cr-Commit-Position: refs/heads/master@{#17812}
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
There's some code that resets the ICE role on an ICE restart (behavior
that's specified in ICE, but removed from ICEbis). And it wasn't taking
into account that the remote endpoint may be an ICE lite endpoint, in
which case the WebRTC endpoint's role should always be "controlling".
BUG=chromium:710760
Review-Url: https://codereview.webrtc.org/2812173003
Cr-Commit-Position: refs/heads/master@{#17779}
These tests are already built into rtc_unittests, so they end up being
run three times. Fixed by creating a "p2p_test_utils" target that
contains the test utils that ortc_unittests and rtc_media_unittests
depend on, but not the tests themselves.
BUG=None
TBR=kjellander@webrtc.org
Review-Url: https://codereview.webrtc.org/2820263004
Cr-Commit-Position: refs/heads/master@{#17752}
This patch fixes compilation issues related to usage of std::unique_ptr
and NULL instead of nullptr. This issue pops up once you would try to
compile whole webrtc with using C++14 and gcc-4.9
BUG=webrtc:7461
Review-Url: https://codereview.webrtc.org/2806693004
Cr-Commit-Position: refs/heads/master@{#17600}
JSEP implementations are required to always generate offers with
"actpass", but remote endpoints are not. So we should accept remote
offers with the current negotiated DTLS role.
This was recently clarified in dtls-sdp; it was somewhat ambiguous
before.
Also doing a bit of refactoring of JsepTransport (making a method
private that should have been private, fixing unit tests that were
directly calling said method).
BUG=webrtc:7072
Review-Url: https://codereview.webrtc.org/2770903003
Cr-Commit-Position: refs/heads/master@{#17396}
Extract the remote addresses from SDP c= line on both session level and
media level. The media level address will overwrite the session level one if
exists.
WebRTC is not using c= and this is used for new SDP parsing API.
BUG=webrtc:7311
Review-Url: https://codereview.webrtc.org/2742903002
Cr-Commit-Position: refs/heads/master@{#17326}
To simplify things, the candidate pool is only used in the first
offer/answer.
After setting a local description, the size is frozen, and changing ICE
servers won't refresh the pool.
After setting an answer, the pooled candidates are discarded.
BUG=webrtc:5180
Review-Url: https://codereview.webrtc.org/2717893003
Cr-Commit-Position: refs/heads/master@{#17178}
Add an attribute to the RTCConfiguration which can be used by specific
mobile devices so that the IPv6 ICE candidates on WiFi will not be collected.
BUG=b/35725283
Review-Url: https://codereview.webrtc.org/2731813002
Cr-Commit-Position: refs/heads/master@{#17100}
vector<unique_ptr<StunAttribute>> as suggested in a TODO.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2735523002
Cr-Commit-Position: refs/heads/master@{#17076}
Introduce new target //webrtc/p2p:rtc_p2p_test_utils to host
test-related utilities.
Previously uncovered header "base/fakecandidatepair.h" is now also in a target.
BUG=webrtc:6828
Review-Url: https://codereview.webrtc.org/2714263004
Cr-Commit-Position: refs/heads/master@{#17036}
This isn't used any more so there's no point in maintaining it.
BUG=None
Review-Url: https://codereview.webrtc.org/2731673002
Cr-Commit-Position: refs/heads/master@{#17016}
Introduing IceTransportInternal2 is a temporary fix to switch the base
class of P2PTransportChannel to IceTransportInternal without breaking
Chromium. It is removed in this CL.
Reland this CL after Chromium doesn't depend on this.
BUG=webrtc:6951
Review-Url: https://codereview.webrtc.org/2632563002
Cr-Original-Commit-Position: refs/heads/master@{#16131}
Committed: c7953fa716
Review-Url: https://codereview.webrtc.org/2632563002
Cr-Commit-Position: refs/heads/master@{#16960}
Collected in accordance with the spec:
https://w3c.github.io/webrtc-stats/#candidatepair-dict*
totalRoundTripTime is collected as the sum of rtt measurements, it was
previously not collected.
currentRoundTripTime is collected as the latest rtt measurement, it
was previously collected as a smoothed value, which was incorrect.
Connection is updated to collect these values which are surfaced
through ConnectionInfo.
BUG=webrtc:7062, webrtc:7204
Review-Url: https://codereview.webrtc.org/2719523002
Cr-Commit-Position: refs/heads/master@{#16905}
Connection::nominated() is updated to mean
(remote_nomination_ || acked_nomination_), which means both a
controlling and controlled agent can be said to be "nominated".
Previously this was (remote_nomination_ > 0) which only applies to the
controlling agent.
PortTest.TestNomination added to test nomination values and nomination
stat.
This value is surfaced through cricket::ConnectionInfo::nominated.
RTCStatsCollector uses this value in its collection of
RTCIceCandidatePairStats.
RTCStatsCollectorTest.CollectRTCIceCandidatePairStats updated to test
that ConnectionInfo::nominated is surfaced using mocks.
rtcstats_integrationtest.cc updated to expect nomination set without
using mocks.
Spec: https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatepairstats-nominated
BUG=webrtc:7062, webrtc:7204
Review-Url: https://codereview.webrtc.org/2709293004
Cr-Commit-Position: refs/heads/master@{#16855}
This CL adds the following interfaces:
* RtpTransportController
* RtpTransport
* RtpSender
* RtpReceiver
They're implemented on top of the "BaseChannel" object, which is normally used
in a PeerConnection, and roughly corresponds to an SDP "m=" section. As a result
of this, there are several limitations:
* You can only have one of each type of sender and receiver (audio/video) on top
of the same transport controller.
* The sender/receiver with the same media type must use the same RTP transport.
* You can't change the transport after creating the sender or receiver.
* Some of the parameters aren't supported.
Later, these "adapter" objects will be gradually replaced by real objects that don't
have these limitations, as "BaseChannel", "MediaChannel" and related code is
restructured. In this CL, we essentially have:
ORTC adapter objects -> BaseChannel -> Media engine
PeerConnection -> BaseChannel -> Media engine
And later we hope to have simply:
PeerConnection -> "Real" ORTC objects -> Media engine
See the linked bug for more context.
BUG=webrtc:7013
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2675173003
Cr-Commit-Position: refs/heads/master@{#16842}
Where "TRANSPORT attributes" refers to:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16
The BUNDLE draft now says that these attributes can
(in fact, MUST) be omitted when m= sections are bundled
(they only need to go in one of the bundled m= sections),
so we should start accepting that SDP.
This CL doesn't fix "a=rtcp-mux", unfortunately. That will be easier
to fix once we've split apart an "RtpTransport" object from
BaseChannel.
BUG=webrtc:6351
Review-Url: https://codereview.webrtc.org/2647593003
Cr-Commit-Position: refs/heads/master@{#16782}
This reduces binary size considerably and solves some other problems.
Also rewrote using variadic templates.
Initial patch contributed by andrey.semashev@gmail.com.
BUG=webrtc:2305
Review-Url: https://codereview.webrtc.org/2509733003
Cr-Commit-Position: refs/heads/master@{#16703}
downstream application depends on it.
Mark the old Port::AddAddress deprecated and will be removed after the
applications stop replying on it.
BUG=None.
R=deadbeef@webrtc.org
Review-Url: https://codereview.webrtc.org/2694103003 .
Cr-Commit-Position: refs/heads/master@{#16598}
The URL of the ICE server will be reconstructed by the Port and the URL
attribute is added to the cricket::Candidate struct so that we can tell
which ICE server the candidate was gathered from.
This CL only changes the native C++ code. The Java and Objc wrapper will
be created in separate CLs.
BUG=webrtc::7128
Review-Url: https://codereview.webrtc.org/2685053004
Cr-Commit-Position: refs/heads/master@{#16591}
This is the naming scheme we've been using for internal interfaces.
Also, this CL will introduce a PacketTransportInterface in the webrtc namespace,
which would get too easily confused with the rtc:: one:
https://codereview.webrtc.org/2675173003/
BUG=None
Review-Url: https://codereview.webrtc.org/2679103006
Cr-Commit-Position: refs/heads/master@{#16539}
Replaced by assigning value to a local variable, followed by a DCHECK.
Also deletes dead test code under the always false TEST_DIGEST define.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2623473004
Cr-Commit-Position: refs/heads/master@{#16476}
This CL replaces the previously-hardcoded DTLS timeout value of 50 ms with one that is picked dynamically as 2x ICE RTT (clamped between 50 and 3000 ms to keep it reasonable).
No tests yet - I'm working on these, but sending out this CL early to get feedback. I've tested it manually and on slow networks it results in successful DTLS setup in a single attempt - instead of clogging up the slow link with multiple retransmissions as done previosly.
BUG=webrtc:7099
Review-Url: https://codereview.webrtc.org/2670113002
Cr-Commit-Position: refs/heads/master@{#16426}
If an application sets a non-null value in RTCConfiguration.iceCheckMinInterval, we do not sent STUN pings more often than that. This is useful for bandwidth constrained scenarios.
This CL also increases the maximum STUN ping timeout to 60 seconds up from its previous value of 5 (which meant that a ping response received 5 seconds later would not be counted), and allows the RTT estimate to go up to 60 seconds from its previous limit of 3. RTTs above 3 seconds are possible on mobile links. (webrtc:7109)
This CL was originally written by pthatcher@, I am just submitting it after a minor cleanup.
BUG=webrtc:7082, webrtc:7109
Review-Url: https://codereview.webrtc.org/2670053002
Cr-Commit-Position: refs/heads/master@{#16421}
Proper error handling was missing, using VERIFY to crash in debug
builds, while release builds would ignore the error and leak the
attribute memory. The check of attribute type consistency was changed
to a RTC_DCHECK.
Also removes a large number of uses of the deprecated VERIFY macro.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2665343002
Cr-Commit-Position: refs/heads/master@{#16413}
