7914b8cb41
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}
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.