Is there any problem on linaro Debian(arm64) with using SRTP for WebRTC?
I’ve installed latest srtp packges. (https://packages.debian.org/source/jessie/srtp)
But has same issue with below chromium logs.

[51:62:0504/071416:ERROR:srtpfilter.cc(721)] Failed to init SRTP, err=5
[51:62:0504/071416:ERROR:srtpfilter.cc(721)] Failed to init SRTP, err=2
[51:62:0504/071416:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071417:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071418:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071419:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071419:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071420:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071421:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071422:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071423:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071423:ERROR:stunport.cc(90)] Binding request timed out from 192.168.43.13:44834 (wlan0)
[51:62:0504/071424:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071425:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071426:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071426:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071427:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071427:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071428:ERROR:channel.cc(579)] Can’t send outgoing RTCP packet when SRTP is inactive and crypto is required
[51:62:0504/071433:ERROR:stunport.cc(90)] Binding request timed out from 192.168.43.13:44834 (wlan0)
[51:62:0504/071442:ERROR:stunport.cc(90)] Binding request timed out from 192.168.43.13:44834 (wlan0)

Could you provide net-internals log? The instructions can be found here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

If you use ‘chromium –no-sandbox’, remote streaming is temporarily working.


and same issue is already reported. Here is a bug-fix for it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770659
https://bugzilla.mozilla.org/attachment.cgi?id=822066&action=diff

Is there no problem applying the fix patch?

Thank you for providing more feedback. Adding requester "kapishnikov@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is a WebRTC issue, not a net stack one. It should go to WebRTC folks.

That said, per comment #5, this is  issue #501318 . This is not in a build that we support, so, in general, you need to file bugs with Debian, not us. Debian builds Chromium in an unsupported configuration which makes it impossible for us to resolve a lot of issues. We also only support the latest version which is 50, not 49.

Conveniently, in 50, I took away the unsupported build knob that Debian was incorrectly setting anyway. You should ask Debian to (a) update to 50 as being out-of-date means you are missing important security fixes and (b) stop setting use_system_libsrtp because it doesn't work and, in 50 and later, was removed altogether.

Sadly WebRTC is still broken in Chromium 50 on Debian (ffmpeg issue this time), see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823312

What I can suggest to the OP is to install the backported version for Jessie, it should work there.

Oh fun. :-/ That sounds like something you all would have to get Debian to fix. We ship a bundled ffmpeg which I'm guessing Debian is unbundling. This tends not to work well for libraries inside a sandbox.