Issue metadata
Sign in to add a comment
|
Chrome 57 does not send use_srtp extension in DTLS hello for webRTC datachannel
Reported by
tim.pan...@gmail.com,
Apr 13 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.54 Safari/537.36 Steps to reproduce the problem: 1. create a datachannel only with no media on a peer connection 2. pcap traffic 3. observe no use_srtp extension in DTLS client hello 4. repeat with chrome 56 - observe use_srtp extension Subsequent added audio channels (on the same peer connection) don't come up - presumably because use_srtp is not there. What is the expected behavior? use_srtp extension should always be offered in client hello, incase a subsequent O/A exchange upgrades a text chat to audio. (for example) What went wrong? use_srtp isn't added in chrome 57, but it is in chrome 56. Did this work before? Yes chrome 56 Does this work in other browsers? Yes Chrome version: 57 Channel: stable OS Version: OS X 10.11.6 Flash Version:
,
Apr 13 2017
,
Apr 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/7914b8cb4127e1bca4d288f2f53f08dc13468b6a commit 7914b8cb4127e1bca4d288f2f53f08dc13468b6a Author: deadbeef <deadbeef@webrtc.org> Date: Fri Apr 21 10:23:33 2017 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} [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/api/peerconnectioninterface.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/base/sslstreamadapter.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/base/sslstreamadapter.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/dtlstransportchannel.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/dtlstransportchannel.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/dtlstransportchannel_unittest.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/dtlstransportinternal.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/fakedtlstransport.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/faketransportcontroller.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/transportcontroller.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/p2p/base/transportcontroller.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/channel.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/channel.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/channel_unittest.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/channelmanager.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/channelmanager.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/mediasession.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/mediasession.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/peerconnection_integrationtest.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/peerconnectionfactory.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/peerconnectioninterface_unittest.cc [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/test/mock_webrtcsession.h [modify] https://crrev.com/7914b8cb4127e1bca4d288f2f53f08dc13468b6a/webrtc/pc/webrtcsession_unittest.cc
,
Apr 21 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by guidou@chromium.org
, Apr 13 2017