jitsi
SDP key negotiation fails on transfer
Jitsi 2.11.5558 on Windows 10. Asterisk 15.1. When a call that is secured using SIPS/SRTP, and that call is transferred (or any other SDP negotiation event happens), then the Jitsi issues a new key which is not applied correctly, and the call fails. Here are simple steps to reproduce the problem.
207 is the starting point. That is Jitsi with SRTP. 207 calls 202. 202 is a Grandstream 2160, not encrypted. This leg of the call works.
202 transfers the call to 225. 225 is a Snom M3, not encrypted.
The call is lost at this point. The following errors are in the asterisk log.
== SRTCP unprotect failed on SSRC 775162036 because of authentication failure == SRTP unprotect failed on SSRC 775162036 because of authentication failure 160
This is the issue we opened in Asterisk ASTERISK-27397, but after further testing it was determined to be a problem in Jitsi.
We have a similar problem which ends also in SRTP unprotected failure. Please have a look at this problem in jitsi.
When you say "we have a similar problem" do you mean "it involves Jitsi + Grandstream + Snom", or do you mean "we get SRTP unprotect failures". There are lots of reasons to get a failure in the crypto, and they nearly always all end in "SRTP unprotect failure",
Martin
On 17 April 2018 at 17:34, Schagalaah [email protected] wrote:
We have a similar problem which ends also in SRTP unprotected failure. Please have a look at this problem in jitsi.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jitsi/jitsi/issues/433#issuecomment-382037285, or mute the thread https://github.com/notifications/unsubscribe-auth/AER2YzuG69nU2Y_BrKxUY-xW8i5YUKmjks5tpgufgaJpZM4RPLpk .
dev mailing list [email protected] Unsubscribe instructions and other list options: http://lists.jitsi.org/mailman/listinfo/dev
You're right, its not exactly similar.
What we do is we let asterisk initiate a call. When the jitsi client is used and as soon as the call has been accepted by the jitsi client we get "SRTP unprotect failure" on the asterisk server.
If we use a snom phone as the client it's not a problem.
I'm sorry but Ì did not know that "SRTP unprotect failure" is something which can have a lots of reasons. It sounded very specific. Should we open another entry for your problem?
I hope you all aren't thinking the problem I reported is related to snom or grandstream, because we proved that it is 100% a problem in Jitsi. Even the Asterisk devs got in on it.
The only reason the original issues mentions grandstream and snom is because that is the test scenario I initially setup, before I knew where the problem was.
There's no particular reason you should know that. (I only know because I have made changes to the underlying libsrtp to support custom crypto algorithms, and it doesn't matter what I do wrong - it always ends in that error.)
It sounds like this is a sufficiently different reproduction case, that it would be worth raising a separate ticket for it. (It might be the same underlying problem, but it might not either).
Martin
On 23 April 2018 at 17:09, Schagalaah [email protected] wrote:
You're right, its not exactly similar.
What we do is we let asterisk initiate a call. When the jitsi client is used and as soon as the call has been accepted by the jitsi client we get "SRTP unprotect failure" on the asterisk server.
If we use a snom phone as the client it's not a problem.
I'm sorry but Ì did not know that "SRTP unprotect failure" is something which can have a lots of reasons. It sounded very specific. Should we open another entry for your problem?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jitsi/jitsi/issues/433#issuecomment-383610111, or mute the thread https://github.com/notifications/unsubscribe-auth/AER2Y9kL0Ig8CNz2uogzWSFJGaQX_qt-ks5tre6ygaJpZM4RPLpk .
dev mailing list [email protected] Unsubscribe instructions and other list options: http://lists.jitsi.org/mailman/listinfo/dev
We can make Jitsi - Jitsi transfers and they fail 100% of the time. Any other device (and I have many) work 100% of the time.
That's not proof, but it's pretty strong evidence.
FWIW, I tried to debug this when you reported it. The snippet on the issue tracker had no problems with Jitsi, but since Asterisk apparently only applies the new keys on versions >= 14 this is no surprise. I couldn't be bothered yet to compile my own Asterisk 14/15 (Ubuntu and Debian are still on v13).
Yeah, it works on legacy versions of Asterisk. I've used Jitsi for years with no problems until we were forced to enable encryption. Rolling back Asterisk is not an option. Keep in mind most folks are going to be up on the latest version of Asterisk.
Well, it would help if Asterisk had a Debian repo to install their current version(s).
If I may recommend the FreePBX distro, it's great. I've run raw Asterisk in the past, and well, this is much more convenient.
I know FreePBX, but it doesn't really help to run snippets like the one in the linked issue. And I don't always have VirtualBox available.