commit 7914b8cb4127e1bca4d288f2f53f08dc13468b6a
author deadbeef <deadbeef@webrtc.org> Fri Apr 21 03:23:33 2017 -0700
committer Commit bot <commit-bot@chromium.org> Fri Apr 21 10:23:33 2017 +0000
tree 6a7d5b22319ede7990321ee8bfdee6133d5f9120
parent 30952b460ff6e6e0fada8015c362064fac7ba8af

Negotiate the same SRTP crypto suites for every DTLS association formed.

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}