Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 17 users
Status: Verified
Closed: Feb 2016
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment
ICE completes but no media passes on recent Linux builds
Reported by, Jun 17 2015 Back to list
UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.0.1

Example URL:

Steps to reproduce the problem:
1. Install the standard Debian package "apt-get install chromium" on two computers
2. Start the browser on each computer
3. Navigate to on each browser

Instead of testing with it is also possible to observe the same problem with (tested with JsSIP 0.6.30)

What is the expected behavior?
After ICE completion, users should see and hear each other.

What went wrong?
ICE completes successfully (log message in the JavaScript console) but there is no sound and the remote video window is black.  Neither browser is sending a media stream (checked with tcpdump).

Did this work before? Yes Checked a machine running Debian 7 / Chromium 37 and it is working.  Have not checked all intermediate releases.

Chrome version: 43.0.2357.65 (Developer Build) Built on 8.0, running on Debian 8.0 (64-bit)  Channel: stable
OS Version: Debian 8
Flash Version: Shockwave Flash 11.2 r202
Comment 1 by, Jun 17 2015
Tried same combination of Chromium 43 and JsSIP 0.6.30 on a Windows machine and the media streams did work.  Appears to be a Linux-specific issue.

The Debian package is version 43.0.2357.65-1~deb8u1
Comment 2 by, Jun 17 2015
Labels: Needs-Feedback
Please follow these instructions to make sure the app is granted access to your microphone and camera: go to Menu -> Settings -> Show advances settings... -> Privacy -> Content settings... -> Media.  Make sure you see your camera and microphone in the corresponding dropdown lists.  If not, that is a device driver issue.  If you do, make sure you check "Ask when a site requires access to your camera and microphone".  Then click Manage exceptions, and check the record for (or  If you see any of the items listed as "Block", delete the record, exit Settings, and open the site again.  A prompt should pop up asking for access to camera and microphone.

Please let us know if you were able to make sure that the app has access to your camera and microphone.  Thank you.
Comment 3 by, Jun 17 2015
As mentioned, it got to the ICE completion stage.  That happens after all the authorization prompts appear, SDP offer/answer exchanges, etc.  I can confirm that I allowed access, I can see myself in the self-view part of the page using, and JSCommunicator.
Comment 4 by, Jun 17 2015
Labels: -Needs-Feedback Cr-Internals-Media
Re: #3.  Thank you.  I'm attaching Cr-Internals-Media label for this.
Comment 5 by, Jun 17 2015
Labels: Needs-Feedback
One more question: does chat work?
Comment 6 by, Jun 17 2015
I'm not specifically testing any chat software, although the chat works even when there is no audio or video.  The WebSocket connection is working and when I test I can see the SIP messages going back and forth on the WebSocket connection.
Labels: -Cr-Internals-Media Cr-Blink-WebRTC
this is WebRTC related. it not use html5 video.
I just tried with Chrome 43 on ChromeOS (which is based on Linux), and it worked.  So if it's Linux-specific, it's not affecting ChromeOS.

If you could provide some native logs, we might get a better sense of what might be going wrong.  You can get native logs by running chromium with the following flags:

--enable-logging=stderr --vmodule=*/libjingle/*=3,*=0
Comment 9 by, Jun 25 2015

Can you please clarify, does it just work for viewing yourself / local webcam or it successfully makes a call and you can see another user?

Comment 10 by, Jun 25 2015

Looking at the logs, something appears to go wrong at the SRTP stage

Why is it logged VERBOSE* and not ERROR?

The error code comes from srtp_init() and it doesn't tell much:

 err_status_init_fail    = 5,  /**< couldn't initialize */

Why does it keep trying to send SRTP packets after such a fundamental failure of SRTP?

[34:43:0625/] Installing keys from DTLS-SRTP on audio RTP
[34:43:0625/] Failed to init SRTP, err=5
[34:43:0625/] DTLS-SRTP key installation failed


[34:43:0625/] Installing keys from DTLS-SRTP on video RTP
[34:43:0625/] Failed to init SRTP, err=2
[34:43:0625/] DTLS-SRTP key installation failed
[13805:13805:0625/192203:INFO:CONSOLE(369)] "Data channel opened by the Videobridge!", source: (369)
[13805:13805:0625/192203:INFO:CONSOLE(515)] "selected endpoint changed: ", source: (515)
[13805:13805:0625/192203:INFO:CONSOLE(521)] "sending selected endpoint changed notification to the bridge: ", source: (521)
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] VAdapt Frame: scaled 0 / out 90 / in 90 Changes: 0 Input: 640x360 i0 Scale: 1 Output: 640x360 i0 Changed: false
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[13805:13805:0625/192211:INFO:CONSOLE(12474)] "Jingle error", source: (12474)
[13805:13805:0625/192211:INFO:CONSOLE(12474)] "Jingle error", source: (12474)
[13805:13805:0625/192211:INFO:CONSOLE(12474)] "Jingle error", source: (12474)
[13805:13805:0625/192212:INFO:CONSOLE(12474)] "Jingle error", source: (12474)
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required
[34:43:0625/] Can't send outgoing RTCP packet when SRTP is inactive and crypto is required

Comment 11 by, Jun 25 2015
The second srtp_init failure is a different error code:

  err_status_bad_param    = 2,  /**< unsupported parameter */
Comment 12 Deleted
Labels: -Cr-Blink-WebRTC -Needs-Feedback Cr-Blink-Webrtc-Network
Status: Assigned
Clearing the Needs-Feedback label per #10.
There are two things here:

1.  Why is SRTP failing to init?

2.  When we fail to setup the DTLS-SRTP keys, we end up calling WebRtcSession::OnDtlsSetupFailure, which doesn't actually terminate the session/PeerConnection.  We should fix that so that the PeerConnection terminates rather than proceeding in a useless state.
I made a separate bug for the error handling issue:

But we still need to figure out why SRTP is failing to init in the first place.
Comment 16 by, Jul 15 2015

Should the libsrtp version make any difference?

The Chromium package on Debian currently uses the libsrtp shared library from the libsrtp0 package.

Debian currently has libsrtp 1.4.5~20130609~dfsg-1.1

On other platforms, which libsrtp is Chromium using?

Should it check the version at startup to make sure it supports any necessary algorithms and APIs?

Comment 17 by, Jul 15 2015
Also, should there be a libsrtp version check in the configure script before compiling?
Comment 18 Deleted
We got a similar bug report in Gentoo when using system libsrtp, see .

It'd be great to investigate this more on the Chromium side - while that configuration is theoretically unsupported (it works in Chrome), it suggest we're having a dependency on specific version of libsrtp or specific way in which it's compiled, which could be improved for better maintainability/reliability.
If Chrome works, is this an issue with the way Chromium is being compiled?  Can the linux distros just compile Chromium with libsrtp compiled in statically?
It has been pointed out in the Debian bug report that disabling Chrome's sandbox fixes the issue, which I can confirm. Maybe someone with some actual knowledge of how the sandbox works can point us in the right direction?
After some investigation it would seem the reason why the call to srtp_init() fails is that the rand_source_init() function calls open(DEV_URANDOM, O_RDONLY), which fails with EPERM. Does the sandbox prevent access to /dev/urandom?

For reference the bug in question is

I think the sandbox prevents filesystem access so yeah that would explain it.
Comment 24 by, Jul 29 2015 linux distros never do static linking.  That wastes disk space and it makes it harder to deploy security updates for libraries, because every package with a static copy of the library would need to be updated.

In the case of this bug, if it is about sandbox access to /dev/urandom then static linking would not resolve it anyway.
I noticed that libsrt 1.5.x gained support for offloading the crypto / rng to openssl (and presumably boringssl). I am attempting to rebuild chromium with an openssl-enabled libsrtp to see if it solves the issue.
Comment 26 by, Jul 29 2015
As discussed on IRC, libsrtp 1.5.x isn't present in stable Linux distributions like Debian jessie Ubuntu 14.10 and even the upcoming Ubuntu release won't have it:

unless it progresses out of Debian experimental.

On the other hand, libsrtp 1.5.x has a new ABI number and so the binary package will be libsrtp1 (the 1.4.x package is libsrtp0), this means that people can potentially have both installed concurrently on their system and applications using the older version shouldn't be impacted.  It will still be necessary to discuss with the security team and/or stable release managers from each distribution to see if they are willing to have the new libsrtp, but only if it will actually fix the problem.
Switching to libsrtp 1.5.x with openssl enabled did not resolve anything: we still hit the sandbox. A look at chromium's code suggests that the Chrome builds have some special initialisation code which circumvents the problem when using boringssl. Can anyone with a good knowledge of the sandbox please explain how we are supposed to move forward?
As I pointed out in the Debian bug, WebRTC in chromium package shipped with Ubuntu 15.04 works fine. I don't know how they sorted it out. I also noticed that 

ldd /opt/google/chrome/chrome | grep srtp

returns nothing (that's the Google Chrome binary), so it's not dynamically linked with an srtp library.  I'll try that on an Ubuntu system and let you know.

I had a look at Ubuntu's chromium and it seems to be using the bundled libsrtp *and* boringssl, putting it on the "happy path" where srtp calls boringssl for any crypto / random number generation, and boringssl's rng is initialize outside the sandbox.

My conclusion at this stage: distros who wish to use the system's libraries are in trouble as far as WebRTC support goes. The only option is probably going to be to punch a hole in the sandbox..
So the bundled libsrtp has been modified? Otherwise I don't see how it can make a difference... If it is modified, this could be a good reason for package maintainers to decide to use the bundled library instead of the system's one...

The bundled libsrtp is not necessarily modified, it is just statically linked to boringssl which has a special codepath in chromium to initialise the RNG.

I have found a solution which does not involve using bundled libraries : if we patch the system libsrtp to use fopen(3) instead of open(2) on /dev/urandom, it works. The reason is that chromium's sandbox has some code to allow this call in order for NSS to work. I proposed a patch against Debian's libsrtp here:;bug=770659;msg=124;filename=2003_use_fopen_for_chromium_sandbox.patch

An alternative would be to modify Chrome's Linux sandbox in order to allow open(2) on /dev/urandom, but I am not confident making that kind of change.

Could some Chromium devs weigh in on whether the code which allows fopen(3) on /dev/urandom will be kept in the forseable future?
That code is a hack to deal with system NSS where it's difficult to bundle the crypto portion and still use it for system certificate and smartcard integrations. We're switching Linux to BoringSSL which does not require this ( issue #506323 ). It will not be kept long-term.

pthatcher: I'll let you decide if you want to continue digging, but I think you can just WontFix this. Using a system library, which may change independently of the browser and was designed to run in an unconstrained environment, inside the sandbox is inherently fraught with peril and extremely fragile (as can be seen by this attempt to "fix" it with fopen). Our hands are tied with NSS for a number of reasons, hence the fopen hack and worse (see crypto::InitNSSSafely). Getting out of that bind is one of the many wins of switching to BoringSSL.

The bundled libsrtp is, for all practical purposes, patched. We bundle BoringSSL (and //net will not entertain patches to unbundle and support building against upstream OpenSSL), which means, transitively, every library we link against BoringSSL rather than OpenSSL is patched and must be bundled. Distributions which attempt to unbundle those do so at their own peril. In BoringSSL's case, the PRNG is configured externally to work within the sandbox via a custom RAND_set_urandom_fd API.
This is very discouraging. If you are going to actively be hostile to linux distros which cannot ship bundled librairies, at least own up to it. Rename your libsrtp fork to boringsrtp, document the fact that boringssl + boringsrtp are the only way to have a fully function web platform and remove the broken use_system_libsrtp option.

I expected better from the chromium project, especially in light of the laudable efforts to upstream Chromium's changes to libsrtp so far.
Comment 34 by, Jul 30 2015
An "us-and-them" attitude is not helpful from either upstream developers (e.g. Chromium) or distributions.

Many of us in Debian are also developers.  I'm also release manager of reSIProcate, which also uses libsrtp, so I fully understand there is sometimes conflict between using the most secure or compatible library versions and getting something into stable distributions where there are older libraries hanging around, sometimes well past their use-by-date.

If every package in Debian or Ubuntu or Fedora had embedded libraries then many people would never benefit from patches made in other projects.  Developers would actually spend more time duplicating things that other people had fixed already.  That is just insane but that is the logical conclusion if every package embeds their own libraries.

These days, when most people use Git and Github, it is often easier than ever to get patches into a library too and cherry-pick them into a stable release branch of the library.  That said, Debian probably needs to be a little bit more tolerant about accepting things from a stable upstream release branch, the current workflow requires the package maintainer to selectively backport patches into stable versions and that slows people down.

Also see  issue 328475  . It turns out the issues with /dev/urandom in sandbox have been known, see e.g. "This RNG is only used during self-testing of libsrtp and BoringSSL can't be used inside Chrome from WebRTC as that sandbox doesn't have access to "/dev/urandom" as used by libsrtp."

Have the Chromium changes to libsrtp been sent upstream? I see no reason not to have OpenSSL or even BoringSSL support in upstream libsrtp, or at least not to try.
That comment was later corrected. BoringSSL can be used in the sandbox just fine. (We need this to be the case for WebCrypto and many other things.) It just hadn't been primed for the sandbox in the then not yet shipped Linux BoringSSL/NSS chimera build configuration.

Though, yeah, at a glance it does look like it's only called in self-tests right now, so that it wasn't hooked up correctly was harmless. But not having working a working PRNG in a crypto-related library is normally a terrifying security-critical bug. I'm glad we got this sorted out before things change someday and we failed to notice it became one.
jeremy.laine: It's certainly good to upstream any patches we have to libsrtp that upstream wants. That's good for everyone, us included. That's not what's going on here, it's just a matter of how dependencies work transitively and the unique problems of imposing a sandbox on a platform that hasn't traditionally provided one.

If A depends on B depends on C, and A has a custom version of C, even if B is used entirely unmodified from upstream, switching the dependency tree from
    A -> B -> C
    A -> B -> C_system
     \-> C
can easily break things.

C_system here is OpenSSL and C BoringSSL, which has diverged enough from OpenSSL that maintaining support for building against OpenSSL would not be realistic. We also do not match OpenSSL's ABI as that would prevent all the cleanups we've been doing, so you can't just build a and have it work.

Chromium's sandbox is a very constrained environment that, by design, needs special effort for any code accessing system resources, either by building in a configuration that doesn't need those resources or setting up the resources out-of-band.

For the PRNG in BoringSSL, we added an API to pass the /dev/urandom fd out-of-band. This works for anything in Chromium which calls BoringSSL, but Debian's libsrtp naturally doesn't. But Chromium can't prime system OpenSSL's PRNG because we don't even know system OpenSSL exists. (And since BoringSSL and system OpenSSL occupy the same symbols, there would be complications if we tried.)

This is particularly complex for system libraries because they're updated independently of the Chromium project. This constrained environment isn't what Linux typically provides. System libraries are, naturally, written assuming that they can do exotic things like fork/exec or open local dotfiles or anything else freely. By updating code in the sandbox independently of Chromium, any update could cause things to break. (System NSS has been a particular source of trouble, so replacing sandboxed uses with BoringSSL is a huge win.)

I understand Linux distributions have a desire to unbundle things, but it doesn't seem use_system_libsrtp is a tenable build option right now. We should probably remove and de-unofficial-support it until this PRNG issue can be resolved.
What next steps do we have to do, then?  Is it up to package maintainers to not use use_system_libsrtp?  Or are there changes that we can upstream that would help?  
One thing that might work is to arrange for srtp_init to be called before the sandbox is engaged? But this should not be done in any supported configuration, only if USE_SYSTEM_LIBSRTP is defined. The more random code in libraries we call into before engaging the sandbox, the more risk there is something will leave an fd open somewhere that we don't know about.

Really I think we should just remove use_system_libsrtp. We don't have any relevant patches to upstream because our "patch" is to build libsrtp against a known instance of a sandbox-aware crypto library. The system copy of OpenSSL is neither sandbox-aware nor a known instance.
It should also be made clear that NSS support is already broken: unless I am mistaken the only working combination is embedded boringssl + embedded libsrtp.
Oh, sorry, I probably should have given some word to the NSS side of things. I didn't mention them just because trunk has changed, and it's complicated enough as it is. :-)

So, Chrome 45 and below use NSS on Linux. On trunk, this is now BoringSSL and any new changes will, unless something terrible goes wrong and we have to revert, be made for the BoringSSL configuration.

The BoringSSL ports now build the embedded libsrtp in OpenSSL build configuration and link it with BoringSSL. Whether or not libsrtp works inside the sandbox is entirely dependent on whether the OpenSSL instance it links to works inside the sandbox. For us, that's BoringSSL and we make BoringSSL sandbox-aware. For a system libsrtp, if built in OpenSSL configuration, this is system OpenSSL and that is won't be sandbox-aware.

In the NSS ports (which, on trunk, no longer exist), and also on the BoringSSL ports prior to libsrtp's OpenSSL build configuration, we used libsrtp's other build configuration where it has an internal implementation of all crypto, including the PRNG code here:

We built that with DEV_URANDOM unset (I suspect more on accident than intentionally), so we lose all the ifdefs and hit the fprintf. So there was a scary message, but it's *currently* safe. Long-term, it scares me, but we've resolved it now with the BoringSSL switch. However, a system libsrtp is obviously not going to be built with DEV_URANDOM unset. Which means it's going to try to open /dev/urandom, error, and fail to initialize itself.

In both cases, I think the only solution is to either use the embedded one (avoids a ton of headache) or maaaybe to call srtp_init before entering the sandbox, only in the USE_SYSTEM_LIBSRTP configuration. But it would be code in Chromium in a very security-sensitive bit that's only used by an unsupported build configuration.
Labels: WebrtcTriaged
Comment 43 by, Nov 23 2015
Can anybody comment on when this issue will be fixed?  Each new version of Chromium I've tried still has problems with WebRTC.
Labels: -Cr-Internals-Network
Bug is still present,  Version 47.0.2526.80 Built on 8.2, running on Debian stretch/sid (64-bit)

I think we are in this for the long haul gentlemen.... --no-sandbox still works of course.
s0m3f00l: Please file a bug with Debian to build in a supported configuration. As described earlier in the thread, using the system libsrtp is not a thing that can work due to Chromium's sandboxed architecture.

We probably should just remove use_system_libsrtp altogether. None of them are supported anyway, but we may as well remove the ones that have no hope of ever working.
Comment 47 by, Feb 4 2016
There are over 20,000 packages in Debian and Ubuntu (and similar distributions like Fedora too).  If every package included duplicate copies of libraries, security support would be impossible.  The people doing security updates are always under pressure, no developer should expect them to maintain two copies of a library (e.g. the system libsrtp and a second version embedded in a package like chromium).  Why is it so hard for Chromium to contribute patches back to the standard libsrtp as pull requests on Github?  Why does this approach work for so many other libraries but not for Chromium / libsrtp?
daniel: Please see my comments earlier in the thread. A system version of libsrtp is not feasible here for architectural reasons. Compromising on that architecture would mean removing a critical part of the project's security story (our sandbox). 

Chromium is a very active project and deals with relevant security issues in its bundled dependencies, just as it deals with security issues in its upstream code. Keeping up with Chromium updates will pull in all of that, and distributions MUST do this to package Chromium anyway. Having a system libsrtp is no substitute for that. libsrtp makes up such an insignificant amount of the total amount of code that is Chromium (and runs in the sandbox, no less) that worrying about this dependency in isolation makes no sense.
Comment 49 by, Feb 4 2016
I understand you have patched libsrtp, but it is still not clear why you can't submit your patches to the libsrtp project through Github:

Surely you could generalize your patches so they could be enabled and disabled as required by different users of the library?

Or could you maintain your forked libsrtp under a different name, so it could be distributed as a standalone library package?  Then if it turns out you are doing a better job of supporting it than regular libsrtp, people will use and support your library instead.

I also saw your comments about using BoringSSL.  That is really something for the Debian security team to decide on but I can imagine them considering various options:

a) leaving out WebRTC support completely and telling users it is because of embedded libraries, this would be slightly better than the status quo, as it just silently fails at present

b) dropping the Chromium package and just supporting Firefox (Iceweasel) on Debian

c) accepting the bundled libraries that you propose

d) trying to make some other hack

There are no patches to upstream. That's the point. It's a dependencies thing. See comments above.

I'm going to go upload a patch to remove the use_system_libsrtp build knob. We don't support those knobs anyway, but any library that Chromium expects to link against unbundled BoringSSL fundamentally cannot be unbundled, so we should remove the ones that do not work and will never work.
Comment 51 by, Feb 4 2016
There actually have been a couple of patches that were submitted upstream (e.g. support for compiling against BoringSSL and some other things), so there are no more functional differences between upstream libsrtp and the version bundled with Chromium - apart from the architectural way it is used/sandboxed in Chromium as described by David.
davidben: Thanks for taking care of this. May we expect the use_system_libsrtp build knob to be absent in Chromium 49?

Comment 53 by, Feb 9 2016
Have you actually I checked that the Debian package maintainer or security team have agreed to this strategy?  I haven't seen any comment from them so far.

This is type of thing is also one of the big reasons why Fedora does not distribute an official Chromium package:

paride.legovini: 50 at the earliest, though I'm still waiting on a code review. If the flag is causing issues, I suggest contacting your distributor. We've never supported those flags and distributors turn them on at their own peril. In this case it turns out the flag breaks things, so turning it off would be prudent.

daniel: What Debian does with their Chromium package is their decision. Personally, I think the (not unreasonable) preference against bundling is being taken to an extreme and applied to contexts where it doesn't make sense. Again, see this thread for the technical reasons why making that flag work is not feasible. If the flag will never work, it makes no sense to keep it around, thus it should be removed.
Labels: M-50
Status: Fixed
I'm not sure why bugdroid hasn't commented on the bug, but the flag's been removed.

This does not remove other use_system_foo flags (though I can't recommend one set them either), only use_system_libsrtp because that one can't be made to work for the reasons described elsewhere in the thread, notably comment #37.
(This is only going to appear in version 50, where the flag will be ignored. Affected users should file bugs with their distributions to remove use_system_libsrtp from the package files because it doesn't work.)
Project Member Comment 57 by, Feb 11 2016
The following revision refers to this bug:

commit 8f25a1aaadfe9898a73d1f03c50ba41a83a576d3
Author: davidben <>
Date: Wed Feb 10 23:40:25 2016

Roll src/third_party/libsrtp/ 9cc4f2f79..8eecac0fe (1 commit).

$ git log 9cc4f2f79..8eecac0fe --date=short --no-merges --format='%ad %ae %s'
2016-02-09 davidben Remove use_system_libsrtp build knob.

BUG= 501318 

Review URL:

Cr-Commit-Position: refs/heads/master@{#374785}


Status: Verified
Verified with the original repro steps -

Opened https://// in Ubuntu 14.04 and Mac 10.11.3, both running Chrome M50 Canary 50.0.2658.0 
Both ends can see and hear each other
srnarayanan: This bug never affected Google Chrome. It's purely a problem with some Linux distributions Chromium packages. But don't worry about it. There's no need to QA this. :-)
 Issue 608654  has been merged into this issue.
Sign in to add a comment