89824f6fe0
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}
Name: WebRTC URL: http://www.webrtc.org Version: 90 License: BSD License File: LICENSE Description: WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream. Third party code used in this project is described in the file LICENSE_THIRD_PARTY.