Gestalt has been deprecated since macOS 10.8, and it's always been overkill for
finding the macOS version anyways. uname works fine.
BUG=webrtc:6027
Review-Url: https://codereview.webrtc.org/2391633004
Cr-Commit-Position: refs/heads/master@{#14589}
Some runtime dependencies on MSVC were missing and had to be added to rtc_base_approved.
BUG=chromium:497757
NOTRY=True
Review-Url: https://codereview.webrtc.org/2389133002
Cr-Commit-Position: refs/heads/master@{#14562}
Reason for revert:
This change broke a downstream application.
Original issue's description:
> Delete transformadapter.cc and transformadapter.h.
>
> BUG=webrtc:6424
>
> Committed: https://crrev.com/2c3c3e27321e4b616bd1222857b2882befc485e3
> Cr-Commit-Position: refs/heads/master@{#14541}
TBR=perkj@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2400443003
Cr-Commit-Position: refs/heads/master@{#14543}
The replacement methods had already been added to applefilesystem.mm, they just
weren't being used on macOS.
BUG=webrtc:6028
Review-Url: https://codereview.webrtc.org/2395593002
Cr-Commit-Position: refs/heads/master@{#14535}
These tests were checking the behavior of thread synchronization
primitives using nothing but carefully timed sleeps. This was very
unreliable and prone to flakes.
This CL replaces the sleeps with waiting on synchronization events.
There is still the need to wait for timeouts when testing for negative
outcomes, but it's greatly reduced. I've run these tests for thousands
of iterations on MSan without a single failure.
BUG=webrtc:5824
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2393023002 .
Cr-Commit-Position: refs/heads/master@{#14534}
Reason for revert:
This CL breaks some downstream dependencies (contact me for more info).
Original issue's description:
> Delete unused code httprequest, httpclient, and socketpool.
>
> BUG=webrtc:6424
>
> Committed: https://crrev.com/4a255be3790a040cae2f6182ed70b7dd38c6839e
> Cr-Commit-Position: refs/heads/master@{#14514}
TBR=perkj@webrtc.org,pthatcher@webrtc.org,nisse@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2397673002
Cr-Commit-Position: refs/heads/master@{#14518}
The test was heavily dependent on wall clock timing, so it ended up
being disabled in some build configurations. This CL switches it to use
a fake clock instead.
BUG=webrtc:5947
Review-Url: https://codereview.webrtc.org/2392613003
Cr-Commit-Position: refs/heads/master@{#14507}
The former is always defined (by webrtc/base/checks.h) to either 0 or
1, whereas the latter isn't necessarily defined.
NOTRY=true
BUG=webrtc:6451
Review-Url: https://codereview.webrtc.org/2384693002
Cr-Commit-Position: refs/heads/master@{#14474}
The implementation is borrowed from Chromium.
Also change use of raw pointers in VideoSendStreamImpl to use WeakPtr<>
BUG= webrtc:6289
Review-Url: https://codereview.webrtc.org/2367853002
Cr-Commit-Position: refs/heads/master@{#14468}
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
WebRTC polls the list of local IP addresses for both IPv4 and IPv6
every ~2 seconds. It does so by trying to connect() a UDP socket to
an address on the public Internet (without actually sending any
packets).
If the host doesn't have IPv6 (or IPv4) connectivity, it fails with
errno 101 (ENETUNREACH, Linux) or errno 65 (EHOSTUNREACH, Mac).
This is the expected behavior, and we shouldn't be logging these
failures, especially since polling is fairly frequent.
BUG=webrtc:6347
R=deadbeef@webrtc.org, honghaiz@webrtc.org, perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2370383002 .
Cr-Commit-Position: refs/heads/master@{#14440}
It's a very general type, and we're about to start needing it in other
places besides AudioCodingModule.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2380463003
Cr-Commit-Position: refs/heads/master@{#14423}
These are already added in third_party/jsoncpp/BUILD.gn so they
shouldn't be needed.
BUG=webrtc:6412
NOTRY=True
NOTREECHECKS=True
Review-Url: https://codereview.webrtc.org/2368543002
Cr-Commit-Position: refs/heads/master@{#14379}
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
Previously when a Turn port is pruned, if its candidate has been sent to the remote side, the remote side will keep the candidate and use that to create connections.
We now signal the remote side to remove the candidates so that at least no new connection will be created using the removed candidates.
Also updated the virtual socket server to better support our test cases.
1. Allow the virtual socket server to set transit delay for packets sent from a given IP address.
2. Ensure the ordered packet delivery for each socket (Previously the delivery order is enforced on the whole test case, so if a udp packet gets delayed based on its IP address, all TCP packets sent after the UDP packet will be delayed at least until the UDP packet is received).
BUG=webrtc:6380
R=deadbeef@webrtc.org, pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2261523004 .
Cr-Commit-Position: refs/heads/master@{#14297}
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
R=mattdr@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2163683003 .
Cr-Commit-Position: refs/heads/master@{#14296}
The two situations are:
1. A thread is in the process of shutting down, so it won't handle any
more messages.
2. A message queue is cleared before it has a chance to process pending
messages.
In both of those cases, we should consider processing done at that
point.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2319303004 .
Cr-Commit-Position: refs/heads/master@{#14245}
Also enforce a minimum inter-frame interval of 1 ms,
fix a bug in the clipping logic, and improve comments.
BUG=webrtc:5740
Review-Url: https://codereview.webrtc.org/2325563002
Cr-Commit-Position: refs/heads/master@{#14206}
