Janus-gateway: Oops, error creating inbound SRTP session for component 1 in stream 1

[gdiazlo]

hello!
I have a setup with:

janus-gatewat 0.9.1
libnice 0.1.16
libsrtp 2.3.0

When running the videoroom demo in firefox 74 with janus default configuration modified to add let's encrypt certificates and more debug, the publishing of the video fails. The janus-gateway states:

[WARN] [2756815112186902]     Missing valid SRTP session (packet arrived too early?), skipping...
[2756815112186902] DTLS established, yay!
[2756815112186902] Computing sha-256 fingerprint of remote certificate...
[2756815112186902] Remote fingerprint (sha-256) of the client is E9:C7:0A:6F:11:40:26:2D:9D:1A:08:10:F5:BA:0E:38:F8:37:BF:B7:75:3A:D3:26:B0:CF:52:65:1C:D2:3D:E6
[2756815112186902]  Fingerprint is a match!
[2756815112186902] SRTP_AEAD_AES_128_GCM
[2756815112186902] Key/Salt/Master: 28/16/12
[ERR] [dtls.c:janus_dtls_srtp_incoming_msg:870] [2756815112186902] Oops, error creating inbound SRTP session for component 1 in stream 1??
[ERR] [dtls.c:janus_dtls_srtp_incoming_msg:871] [2756815112186902]  -- 1 (srtp_err_status_fail)
[2756815112186902] DTLS alert triggered on stream 1 (component 1), closing...
[2756815112186902] Hanging up PeerConnection because of a DTLS alert
[2756815112186902] Telling the plugin about the hangup (JANUS VideoRoom plugin)
[janus.plugin.videoroom-0x2168490] No WebRTC media anymore; 0x7fae70002070 0x7fae700021e0
[2756815112186902] Notifying WebRTC hangup; 0x7fae70002070
[2756815112186902] Sending event to transport...; 0x7fae70002070
[2756815112186902] WebRTC resources freed; 0x7fae70002070 0x7fae70001a90

The demo works fine with chromium based browsers using the same computer and networks. Also the demo in https://janus.conf.meetecho.com/videoroomtest.html works fine, so there should be something on my set up.

I have checked the ports and IPs. There is no NAT in the server, and no other failures in the log, besides some warnings about the sockets server not being enabled)

I can't figure out why it has an error creating the SRTP session. This may be related to #1688 ? That issue the most similar I've been able to find.

Any hints?

Thanks alot!

[lminiero]

No, your issue is different:

[ERR] [dtls.c:janus_dtls_srtp_incoming_msg:870] [2756815112186902] Oops, error creating inbound SRTP session for component 1 in stream 1??
[ERR] [dtls.c:janus_dtls_srtp_incoming_msg:871] [2756815112186902]  -- 1 (srtp_err_status_fail)

It's a libsrtp error in srtp_create. First of all, try master, as lines in dtls.c don't match. Have you also checked if it works as expected with older versions of libsrtp, e.g., 2.2.0 instead of 2.3.0?

[gdiazlo]

That solved the problem! great! I need to learn more about the different components and their mission, any recommendations to read?

I downgraded libsrtp to version 2.2.0.

Thanks a lot

[lminiero]

But that's not good news... it means that libsrtp 2.3.0 breaks something, apparently. I'll add it to the things to check.

[gdiazlo]

Oh! sorry :-) Should I open a new issue or reopen this one? I might be able to do more tests these days if needed.

[lminiero]

No need, I'll try and investigate myself, and reopen in case. If it turns out we need some more testing from who can replicate the issue, I'll make sure to ping you, thanks :slightly_smiling_face:

[atoppi]

FWIW I've been successfully using libsrtp 2.3.0 for the last months.
The only difference is that I do not use certificates.

[lminiero]

In that case, @gdiazlo you may want to try with 2.3.0 again, but without using the LetsEncrypt certificates. For DTLS you don't need valid certificates at all, it's always self-signed in browsers as well, and if you don't provide any Janus will create one for you at startup.

[gdiazlo]

Where should I put the certificates if I do not want to use a proxy? I just put them in all certificate blocks in the config files.

[lminiero]

The transport configuration file: the certificates setting in janus.jcfg is, as explained in the commented section, only for DTLS.

[gdiazlo]

I tested with the certificate block and lets encrypt certificates only in janus.transport.http.jcfg and janus.transport.websockets.jcfg. No certificates in janus.jcfg. Libsrtcp 2.3.0 and janus 0.9.1.

Still has the behaviour described in the issue.

[ERR] [dtls.c:janus_dtls_srtp_incoming_msg:870] [2099492507476063] Oops, error creating inbound SRTP session for component 1 in stream 1??
[ERR] [dtls.c:janus_dtls_srtp_incoming_msg:871] [2099492507476063] -- 1 (srtp_err_status_fail)

@atoppi have you tested it with firefox? which version? It fails to me with firefox 74 :(

Thanks!

[jonassmedegaard]

I have the same issue on two instances of Janus, and can help test as needed.

[jonassmedegaard]

in case it is relevant: I run Debian testing on armhf hardware.

[jonassmedegaard]

compiling libsrtp2 with configure option --enable-nss made the problem go away for me.

@gdiazlo is your libsrtp2 linked with any of libssl or libnss, or without either of those?

Libsrtp2 can _optionally_ be linked with either libssl (a.k.a. openssl) or libnss, and it seems from the symbols of compiled code that _without_ those a few GCM functions are missing.

I notice if perhaps the build-time checks in janus for HAVE_SRTP_AESGCM should instead be runtime probing for libsrtp capabilities?

[lminiero]

I notice if perhaps the build-time checks in janus for HAVE_SRTP_AESGCM should instead be runtime probing for libsrtp capabilities?

I removed those checks.

[jonassmedegaard]

Really?

I mean lines like https://github.com/meetecho/janus-gateway/blob/5f75deb/dtls.c#L417

[lminiero]

HAVE_SRTP_AESGCM is always set to true right now.

[jonassmedegaard]

ah.

If janus cannot query at runtime which crypto ciphers are available, then I guess it would be helpful to at least document that janus needs libsrtp linked against libnss or libssl - because such linking is optional.

[lminiero]

Had to get rid of that check because of #2019 which forced me to use pkg-config in #2033, and I can't check for methods using pkg-config. I asked for feedback on whether the check was needed, nobody answered, so I merged. We can't check at runtime, I think, because the method signature is always there, but the method is not always implemented.

[jonassmedegaard]

I don't mean to say that any specific change to janus code is wrong - I am not qualified to judge that.
What I do try to point out is that this issue is marked as closed, even though the described issue still persist: It happens when using janus linked with libsrtp2 which is not linked with either libssl or libnss.
It seems related to https://github.com/cisco/libsrtp/issues/387 (but again, I am not qualified - just a guess).

I suggest to reopen this issue until janus can reliably probe for GCM support at runtime, and mention in README the requirement/recommendation of libsrtp with GCM capability.

[lminiero]

I suggest to reopen this issue until janus can reliably probe for GCM support at runtime,

As I already said, you can't. Janus won't start because of undefined references, since the method is in the header, but is not implemented in some cases (I guess when libsrtp is not built against libssl or libnss). I had those checks in place exactly because I wanted to verify if they were in the library, but since I had to switch to pkg-config (and to my knowledge pkg-config doesn't have ways to check if a method is in the library, only if the library is there) I had to remove those checks. I asked for feedback and as usual nobody answered when I needed it, so here we are. I can add a note to the README, but won't investigate further, and will definitely not reopen this issue which is unrelated (again, if GCM isn't there it just won't start). If you guys have solutions, happy to review a pull request.

[gdiazlo]

@jonassmedegaard it worked compiling in openssl or nss, or both. Thanks!

[jonassmedegaard]

I can add a note to the README,

Thanks. I think that would be helpful for your users.

but won't investigate further, and will definitely not reopen this issue which is unrelated (again, if GCM isn't there it just won't start).

I did not mean that _you_ should solve this. What I meant was to keep this issue open until Cisco improves on that issue I referenced.

But this is all just suggestions for how I think your users are best helped (not imposing extra work on you) - if you disagree then do whatever you like, this is your project :-)

@gdiazlo thanks for confirming!

[lminiero]

What I meant was to keep this issue open until Cisco improves on that issue I referenced.

Oh sorry, I missed the reference to the libsrtp issue. Makes sense now, thanks :+1:
Looks like it's a very old issue, though, and that the milestone has changed a few times, so it's likely it won't be available any time soon. I'll make this clearer in the README for the time being.

[lminiero]

Just added a --disable-aes-gcm configure flag in case --enable-openssl doesn't help for some reason. Added to FAQ too: https://janus.conf.meetecho.com/docs/FAQ#aesgcm

[biodranik]

I confirm this issue with the stock version of libsrtp2 2.3.0 installed via brew install srtp on Mac OS X. Recompilation with --enable-openssl fixes the issue.