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}
Revert of Only expose gflags target in non-Chromium and non-fuzzer builds. (patchset #1 id:40001 of https://codereview.webrtc.org/2321963002/ )
Revert of Allow the DTLS fingerprint verification to occur after the handshake. (patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )
Revert of Roll chromium_revision cf9457edb7..cede888c27 (416297:419407) (patchset #3 id:40001 of https://codereview.webrtc.org/2348133003/ )
Revert of Roll chromium_revision cf9457edb7..cede888c27 (416297:419407) (patchset #3 id:40001 of https://codereview.webrtc.org/2348133003/ )
…
…
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others. This page is maintained by the Google Chrome team.
Development
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.
More info
- Official web site: http://www.webrtc.org
- Master source code repo: https://chromium.googlesource.com/external/webrtc
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: http://build.chromium.org/p/client.webrtc
Description
The idea is to make CMake build for WebRTC m130 version - for audio processing module
Languages
C++
90.3%
Java
2.9%
C
2.2%
Objective-C++
2%
Python
1.3%
Other
1%