[jitsi-users] Bug: SDP key negotiation fails on transfer


#1

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, and 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

Initially we thought this was a bug in Asterisk. I created an issue there: https://issues.asterisk.org/jira/browse/ASTERISK-27397
But after more testing we isolated the problem to Jitsi. If I replace Jitsi with another device, everything works normally.


#2

Can you please open an issue on Github so it won't get lost? I can't work on this for a while.

Ingo

···

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Phil Tull
Sent: Mittwoch, 27. Dezember 2017 03:15
To: users@jitsi.org
Subject: [jitsi-users] Bug: 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, and 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

Initially we thought this was a bug in Asterisk. I created an issue
there: https://issues.asterisk.org/jira/browse/ASTERISK-27397 But after
more testing we isolated the problem to Jitsi. If I replace Jitsi with
another device, everything works normally.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Yes I will. I wrote it here because Github said you have to open it in the mailing list.

···

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: Friday, December 29, 2017 9:48 AM
To: 'Jitsi Users' <users@jitsi.org>
Subject: Re: [jitsi-users] Bug: SDP key negotiation fails on transfer

Can you please open an issue on Github so it won't get lost? I can't work on this for a while.

Ingo

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Phil Tull
Sent: Mittwoch, 27. Dezember 2017 03:15
To: users@jitsi.org
Subject: [jitsi-users] Bug: 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, and 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

Initially we thought this was a bug in Asterisk. I created an issue
there: https://issues.asterisk.org/jira/browse/ASTERISK-27397 But
after more testing we isolated the problem to Jitsi. If I replace
Jitsi with another device, everything works normally.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users