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}
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}
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}
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}
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}
Bulk of the changes were done using
git grep -l '#include "webrtc/base/common.h"' | \
xargs sed -i '\,^#include.*webrtc/base/common\.h,d'
followed by adding back the include in the few places where it is
still needed, and in one case (pseudotcp.cc) instead deleting its use
of RTC_UNUSED.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2644103002
Cr-Commit-Position: refs/heads/master@{#16263}
... As opposed to DtlsTransportInternal.
The code is suboptimal right now, storing two pointers to the different
interfaces. This will all be cleaned up when we have an "RtpTransport"
abstraction that BaseChannel can use.
This CL also cleans up the "fake transport" classes a bit, and gives
them their own header files.
BUG=None
Review-Url: https://codereview.webrtc.org/2648233003
Cr-Commit-Position: refs/heads/master@{#16258}
These defines don't work any more, so they only cause confusion:
FEATURE_ENABLE_SSL
HAVE_OPENSSL_SSL_H
SSL_USE_OPENSSL
BUG=webrtc:7025
Review-Url: https://codereview.webrtc.org/2640513002
Cr-Commit-Position: refs/heads/master@{#16224}
Create a new target //webrtc/api:libjingle_peerconnection_api and start moving
things into it. Move remaining parts of //webrtc/api:libjingle_peerconnection
to //webrtc/pc:libjingle_peerconnection.
Moved the RTCStatsCollectorCallback into its own header file, so that
PeerConnectionInterface can include that instead of pulling in
RTCStatsCollector and PeerConnection and everything.
Separated cricket::MediaType into its own header/source set, so that it
can be used in the api.
BUG=webrtc:5883
Review-Url: https://codereview.webrtc.org/2514883002
Cr-Commit-Position: refs/heads/master@{#16210}
This is used for fallback from DTLS to SDES encryption, which we probably still
want to support. Setting a certificate puts the DTLS transport in a "DTLS
enabled" mode, so it should be delayed until SDP with "a=fingerprint" is set.
BUG=webrtc:6972
Review-Url: https://codereview.webrtc.org/2641633002
Cr-Commit-Position: refs/heads/master@{#16199}
Reason for revert:
Broke chromium build, due to a config being removed. Will add it back and remove the dependency in a chromium CL.
Original issue's description:
> Removing #defines previously used for building without BoringSSL/OpenSSL.
>
> These defines don't work any more, so they only cause confusion:
>
> FEATURE_ENABLE_SSL
> HAVE_OPENSSL_SSL_H
> SSL_USE_OPENSSL
>
> BUG=webrtc:7025
>
> Review-Url: https://codereview.webrtc.org/2640513002
> Cr-Commit-Position: refs/heads/master@{#16196}
> Committed: eaa826c2eeTBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7025
Review-Url: https://codereview.webrtc.org/2648003003
Cr-Commit-Position: refs/heads/master@{#16197}
These defines don't work any more, so they only cause confusion:
FEATURE_ENABLE_SSL
HAVE_OPENSSL_SSL_H
SSL_USE_OPENSSL
BUG=webrtc:7025
Review-Url: https://codereview.webrtc.org/2640513002
Cr-Commit-Position: refs/heads/master@{#16196}
DtlsTransportChannelWrapper is renamed to be DtlsTransport which inherits from
DtlsTransportInternal. There will be no concept of "channel" in p2p level.
Both P2PTransportChannel and DtlsTransport don't depend on TransportChannel
and TransportChannelImpl any more and they are removed in this CL.
BUG=none
Review-Url: https://codereview.webrtc.org/2606123002
Cr-Commit-Position: refs/heads/master@{#16173}
