WebRTC (https://apprtc.appspot.com/) used to work with Chromium 24. I am no longer able to connect (even locally to my own computer) after I upgraded to Chromium 25. The same happens with Chromium 26. I have tested google-chrome-26 ebuild and WebRTC is still working there. Reproducible: Always Steps to Reproduce: 1. Go to https://apprtc.appspot.com/?debug=loopback Actual Results: apprtc.appspot.com just says "Connecting..." Expected Results: Connection should be successfully started with either other people or myself (if debug=loopback option is used) Chromium 25 supports Opus codec while 24 version does not. I'm not sure if this might cause the problem.
I've now noticed that if I go to chrome://webrtc-internals then I can see an error (using Chromium): setRemoteDescriptionOnFailure SetRemoteDescription failed. This doesn't happen with Chrome which instead shows: setRemoteDescriptionOnSuccess.
This still doesn't work with Chromium 27.0.1423.0 but that version is slightly more verbose in its error message: SetRemoteDescription failed: Failed to update session state.
I determined that this is caused by using system libsrtp. I've compiled chromium with internal libsrtp and WebRTC seems to be working fine. Transition to system libsrtp was made with Chromium-25 ebuild, so that's why it stopped working.
Confirmed here with chromium-27.0.1425.0. It works in the same version of google-chrome.
Isn't this fixed in www-client/chromium-29.0.1547.57? Looking at the ebuild it seems to use bundled libsrtp.
Bundled libsrtp means that workaround is still used not vice versa The problem is that libsrtp upstream is dead and chromium ships with a patched librstp. I guess upstream librstp is just too old for WebRTC.
06 Jul 2015; Pawel Hajdan jr +chromium-45.0.2438.3-r1.ebuild: Use system libsrtp, bug #459932 by Andrius Stikonas. Test case from this bug worked for me. More testing would be appreciated - please report, also if the test is successful for you. I plan to close the bug once the fix makes it to stable.
Doesn't work with stable libsrtp. I think we need to enforce newest libsrtp version.
Thanks for the test. Could you confirm it does work with net-libs/libsrtp-1.5.2-r1 ? Since I couldn't reproduce the problem with stable libsrtp (1.4.4_p20121108-r1), are you using the steps from this bug or something else? Could you re-post full results of the tests with different libsrtp versions so I can compare with what I'm getting on my machine?
Yes, I'm using the same test with apprtc loopback. With net-libs/libsrtp-1.4.4_p20121108-r1 States: Signaling: stable Gathering: gathering Connection: new Local: host:8 srflx:4 relay:12 Remote: host:8 srflx:4 relay:12 Stats: Call time: 00:22 Setup time: 0 ms Audio Tx: opus, - bps, - pps Video Tx: , 0p0, - bps, - pps setRemoteDescription: Failed to set remote answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to setup SRTP filter.. Version: gitHash: c2179d16ae879f4ece4d2838585966e7c029c9d3 branch: master time: Wed Jun 3 11:08:09 2015 -0700 I'm now recompiling with a newer version of libsrtp...
Unfortunately, it didn't work with newer libsrtp either. Tried both apprtc.appspot.com and vline.com My chromium use flags are: [ebuild R #] www-client/chromium-45.0.2438.3-r1::gentoo USE="cups kerberos (pic) proprietary-codecs pulseaudio tcmalloc -custom-cflags -gnome -gnome-keyring -hidpi -hotwording (-neon) (-selinux) {-test}" LINGUAS="en_GB lt -am -ar -bg -bn -ca -cs -da -de -el -es -es_LA -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lv -ml -mr -ms -nb -nl -pl -pt_BR -pt_PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh_CN -zh_TW" 0 KiB
Thanks, Andrius! Could you confirm it works with 45.0.2438.3 (which uses bundled libsrtp)? Can we also get reports from more folks? I plan to also repeat my tests, but I'm confused about this - the test seemed to work for me.
(In reply to Paweł Hajdan, Jr. from comment #12) > Thanks, Andrius! Could you confirm it works with 45.0.2438.3 (which uses > bundled libsrtp)? > > Can we also get reports from more folks? I plan to also repeat my tests, but > I'm confused about this - the test seemed to work for me. Yes, it works with 45.0.2438.3.
You can get more logs by running the browser with following command-line flags: --enable-logging=stderr --vmodule=*/libjingle/*=3,*=0 Could you do so and post the results?
Created attachment 407976 [details] webrtc_bad Chromium 45.0.2454.15. Uses system libsrtp, webrtc fails.
(In reply to Andrius Štikonas from comment #15) > Created attachment 407976 [details] > webrtc_bad > > Chromium 45.0.2454.15. Uses system libsrtp, webrtc fails. To summarize, the error is [1:14:0730/110305:ERROR:srtpfilter.cc(721)] Failed to init SRTP, err=5 So I guess we still have that access problem to /dev/urandom mentioned in upstream bug.
(In reply to Andrius Štikonas from comment #16) > (In reply to Andrius Štikonas from comment #15) > > Created attachment 407976 [details] > > webrtc_bad > > > > Chromium 45.0.2454.15. Uses system libsrtp, webrtc fails. > > To summarize, the error is > [1:14:0730/110305:ERROR:srtpfilter.cc(721)] Failed to init SRTP, err=5 > > So I guess we still have that access problem to /dev/urandom mentioned in > upstream bug. If libsrtp is compiled with openssl USE flag than the error changes to Failed to init SRTP, err=1 So something is still not working.
Yeah, we're back to bundled libsrtp. See https://code.google.com/p/chromium/issues/detail?id=501318 for reasons why this is hard. Thanks a lot for all the testing! *chromium-46.0.2467.2 (31 Jul 2015) *chromium-45.0.2454.15-r1 (31 Jul 2015) 31 Jul 2015; Pawel Hajdan jr (phajdan.jr) -chromium-45.0.2438.3.ebuild, -chromium-45.0.2438.3-r1.ebuild, +chromium-45.0.2454.15-r1.ebuild, +chromium-46.0.2467.2.ebuild: Dev channel bump. Use bundled libsrtp (bug #459932 by Andrius Stikonas). Remove old.
Is this still valid as of libsrtp-1.5.4 and libsrtp-2.0.0?
(In reply to Aric Belsito from comment #19) > Is this still valid as of libsrtp-1.5.4 and libsrtp-2.0.0? libsrtp-1.5.4 still doesn't work (I've quickly tested with qupzilla/qtwebengine). I can test chromium too, but most likely it won't work either.
(In reply to Andrius Štikonas from comment #20) > (In reply to Aric Belsito from comment #19) > > Is this still valid as of libsrtp-1.5.4 and libsrtp-2.0.0? > > libsrtp-1.5.4 still doesn't work (I've quickly tested with > qupzilla/qtwebengine). I can test chromium too, but most likely it won't > work either. Actually with chromium it seems to work. Can anybody confirm?
(In reply to Andrius Štikonas from comment #21) > (In reply to Andrius Štikonas from comment #20) > > (In reply to Aric Belsito from comment #19) > > > Is this still valid as of libsrtp-1.5.4 and libsrtp-2.0.0? > > > > libsrtp-1.5.4 still doesn't work (I've quickly tested with > > qupzilla/qtwebengine). I can test chromium too, but most likely it won't > > work either. > > Actually with chromium it seems to work. Can anybody confirm? Sorry, I'm taking it back. After compiling I noticed that my portage tree got resynced and I was building unmodified chromium with bundled libsrtp.
Does chromium still support building with unbundled libsrtp? I wasn't able to modify ebuild to build with system libsrtp? And then I also found a comment in https://bugs.chromium.org/p/chromium/issues/detail?id=501318 where it says support was removed.
