[jitsi-dev] SRTP with asterisk. Silence when seq-nums wrap


#1

Hello,

I'm using jitsi for company-wide communication here which
integrates with our asterisk PBX. I'm using SIP-TLS and SDES
SRTP encryption for the voice/video data.

However, there's a severe limitation in that after some random
amount of time within a call, one end becomes silent.

After further investigation, it seems to correspond with when
the RTP Sequence Number in the corresponding media stream wraps
up from 65535 to 0.

It doesn't occur with other SIP clients (blink, SNOM) and
doesn't happen if I disable encryption. I just verified it can
be reproduced with a default installation of asterisk on debian
wheezy. It happens with the latest jitsi snapshot from today.
The issue is not new and has been going on for as long as we've
used jitsi+SRTP+asterisk (over a year).

I've checked with different versions of Java (6, 7,
openjdk/oracle) on Linux (Debian and Ubuntu) i386/amd64 and
Microsoft Windows 7 (i386).

Nothing in the log when the call becomes silent.

To reproduce:

In debian wheezy, (with asterisk 1.8.13, though it also occurs
with 1.8.4):

apt-get install asterisk ssl-cert
cat /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-snakeoil.key > /etc/asterisk/asterisk.pem

Edit /etc/asterisk/sip.conf

Change those settings:

tlsenable=yes
tlscertfile=/etc/asterisk/asterisk.pem
tlsclientmethod=tlsv1
tlsdontverifyserver=no
tlscipher=HIGH
tlscafile=/etc/ssl/certs/ca-certificates.crt
videosupport=yes

And add an extension to register against:

[test.extension]
deny=0.0.0.0/0.0.0.0
secret=abc123
dtmfmode=rfc2833
canreinvite=no
context=default
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
transport=udp,tls
nat=yes
qualify=yes
qualifyfreq=60
callgroup=1
pickupgroup=1
dial=SIP/test.extension
permit=0.0.0.0/0.0.0.0
callerid="Test <123>"
callcounter=yes
faxdetect=no
encryption=yes
cc_monitor_policy=generic

Run "service asterisk restart"

Configure jitsi with TLS preferred transport and mandatory
encryption (SDES, no ZRTP). User test.extension, password
abc123.

Then dial 600 (echo test), wait up to 22 minutes (65535 * 0.02
seconds) and the call will turn silent any time within that
period (whether because the sent stream or its echo becomes
silent first).

Any help would be appreciated. I can provide with additional
debug information if need be.

···

--
Stephane


#2

Hey

Stephane, thanks a lot for the very detailed description!
We've been aware that there was an issue with long calls with SDES, but
never had the time and success to actually track it down. I'm going to take
a look at that, but I can't tell you any ETA (unless someone else has the
time of course - Werner?)

In the meantime I'm wondering if that is really only SDES or affects ZRTP as
well. Well, I know that calls longer than 22 Minutes work with ZRTP, but do
they actually work with _other_ clients than Jitsi for that amount of time?
If not, my first "fingerpointing" would be our SRTP code, as SDES is simply
delivering key-material for the very same engine that ZRTP uses as well and
the error description sounds like something with our ROC calculation is
wrong.

Regards,
Ingo

···

-----Original Message-----
From: Stephane Chazelas [mailto:stephane.chazelas@gmail.com]
Sent: Montag, 10. Dezember 2012 08:59
To: dev@jitsi.java.net
Subject: [jitsi-dev] SRTP with asterisk. Silence when seq-nums wrap
Hello,

I'm using jitsi for company-wide communication here which
integrates with our asterisk PBX. I'm using SIP-TLS and SDES
SRTP encryption for the voice/video data.

However, there's a severe limitation in that after some random
amount of time within a call, one end becomes silent.

After further investigation, it seems to correspond with when
the RTP Sequence Number in the corresponding media stream wraps
up from 65535 to 0.

It doesn't occur with other SIP clients (blink, SNOM) and
doesn't happen if I disable encryption. I just verified it can
be reproduced with a default installation of asterisk on debian
wheezy. It happens with the latest jitsi snapshot from today.
The issue is not new and has been going on for as long as we've
used jitsi+SRTP+asterisk (over a year).

I've checked with different versions of Java (6, 7,
openjdk/oracle) on Linux (Debian and Ubuntu) i386/amd64 and
Microsoft Windows 7 (i386).

Nothing in the log when the call becomes silent.

To reproduce:

In debian wheezy, (with asterisk 1.8.13, though it also occurs
with 1.8.4):

apt-get install asterisk ssl-cert
cat /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-
snakeoil.key > /etc/asterisk/asterisk.pem

Edit /etc/asterisk/sip.conf

Change those settings:

tlsenable=yes
tlscertfile=/etc/asterisk/asterisk.pem
tlsclientmethod=tlsv1
tlsdontverifyserver=no
tlscipher=HIGH
tlscafile=/etc/ssl/certs/ca-certificates.crt
videosupport=yes

And add an extension to register against:

[test.extension]
deny=0.0.0.0/0.0.0.0
secret=abc123
dtmfmode=rfc2833
canreinvite=no
context=default
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
transport=udp,tls
nat=yes
qualify=yes
qualifyfreq=60
callgroup=1
pickupgroup=1
dial=SIP/test.extension
permit=0.0.0.0/0.0.0.0
callerid="Test <123>"
callcounter=yes
faxdetect=no
encryption=yes
cc_monitor_policy=generic

Run "service asterisk restart"

Configure jitsi with TLS preferred transport and mandatory encryption
(SDES, no ZRTP). User test.extension, password abc123.

Then dial 600 (echo test), wait up to 22 minutes (65535 * 0.02
seconds) and the call will turn silent any time within that
period (whether because the sent stream or its echo becomes
silent first).

Any help would be appreciated. I can provide with additional
debug information if need be.


#3

Hey

Stephane, thanks a lot for the very detailed description!
We've been aware that there was an issue with long calls with SDES, but
never had the time and success to actually track it down. I'm going to take
a look at that, but I can't tell you any ETA (unless someone else has the
time of course - Werner?)

In the meantime I'm wondering if that is really only SDES or affects ZRTP as
well. Well, I know that calls longer than 22 Minutes work with ZRTP, but do
they actually work with _other_ clients than Jitsi for that amount of time?
If not, my first "fingerpointing" would be our SRTP code, as SDES is simply
delivering key-material for the very same engine that ZRTP uses as well and
the error description sounds like something with our ROC calculation is
wrong.

I'll have a look at it, however I did quite some tests with ROC calculation,
in particular with Jav because Java misses unsigned intgegers. We have tested
the C++ SRTP implementation with other clients and had longer calls, often more
than an hour.

As an additional question: which SRTP implementation does Asterisk and
the other clients use?

Werner

···

Am 11.12.2012 03:35, schrieb Ingo Bauersachs:

Regards,
Ingo

-----Original Message-----
From: Stephane Chazelas [mailto:stephane.chazelas@gmail.com]
Sent: Montag, 10. Dezember 2012 08:59
To: dev@jitsi.java.net
Subject: [jitsi-dev] SRTP with asterisk. Silence when seq-nums wrap
Hello,

I'm using jitsi for company-wide communication here which
integrates with our asterisk PBX. I'm using SIP-TLS and SDES
SRTP encryption for the voice/video data.

However, there's a severe limitation in that after some random
amount of time within a call, one end becomes silent.

After further investigation, it seems to correspond with when
the RTP Sequence Number in the corresponding media stream wraps
up from 65535 to 0.

It doesn't occur with other SIP clients (blink, SNOM) and
doesn't happen if I disable encryption. I just verified it can
be reproduced with a default installation of asterisk on debian
wheezy. It happens with the latest jitsi snapshot from today.
The issue is not new and has been going on for as long as we've
used jitsi+SRTP+asterisk (over a year).

I've checked with different versions of Java (6, 7,
openjdk/oracle) on Linux (Debian and Ubuntu) i386/amd64 and
Microsoft Windows 7 (i386).

Nothing in the log when the call becomes silent.

To reproduce:

In debian wheezy, (with asterisk 1.8.13, though it also occurs
with 1.8.4):

apt-get install asterisk ssl-cert
cat /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-
snakeoil.key > /etc/asterisk/asterisk.pem

Edit /etc/asterisk/sip.conf

Change those settings:

tlsenable=yes
tlscertfile=/etc/asterisk/asterisk.pem
tlsclientmethod=tlsv1
tlsdontverifyserver=no
tlscipher=HIGH
tlscafile=/etc/ssl/certs/ca-certificates.crt
videosupport=yes

And add an extension to register against:

[test.extension]
deny=0.0.0.0/0.0.0.0
secret=abc123
dtmfmode=rfc2833
canreinvite=no
context=default
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
transport=udp,tls
nat=yes
qualify=yes
qualifyfreq=60
callgroup=1
pickupgroup=1
dial=SIP/test.extension
permit=0.0.0.0/0.0.0.0
callerid="Test <123>"
callcounter=yes
faxdetect=no
encryption=yes
cc_monitor_policy=generic

Run "service asterisk restart"

Configure jitsi with TLS preferred transport and mandatory encryption
(SDES, no ZRTP). User test.extension, password abc123.

Then dial 600 (echo test), wait up to 22 minutes (65535 * 0.02
seconds) and the call will turn silent any time within that
period (whether because the sent stream or its echo becomes
silent first).

Any help would be appreciated. I can provide with additional
debug information if need be.

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#4

2012-12-11 07:45:16 +0100, Werner Dittmann:
[...]

> In the meantime I'm wondering if that is really only SDES or affects ZRTP as
> well. Well, I know that calls longer than 22 Minutes work with ZRTP, but do
> they actually work with _other_ clients than Jitsi for that amount of time?
> If not, my first "fingerpointing" would be our SRTP code, as SDES is simply
> delivering key-material for the very same engine that ZRTP uses as well and
> the error description sounds like something with our ROC calculation is
> wrong.

I'll have a look at it, however I did quite some tests with ROC calculation,
in particular with Jav because Java misses unsigned intgegers. We have tested
the C++ SRTP implementation with other clients and had longer calls, often more
than an hour.

As an additional question: which SRTP implementation does Asterisk and
the other clients use?

[...]

Thanks Ingo and Werner,

asterisk uses:

$ apt-cache show libsrtp0
Package: libsrtp0
Source: srtp
Version: 1.4.4+20100615~dfsg-1
Installed-Size: 192
Maintainer: Jonas Smedegaard <dr@jones.dk>
Architecture: amd64
Depends: libc6 (>= 2.4)
Suggests: srtp-utils
Description-en: Secure RTP (SRTP) and UST Reference Implementations - shared library
SRTP is a security profile for RTP that adds confidentiality, message
authentication, and replay protection to that protocol. It is specified
in RFC 3711.
.
LibSRTP provides an implementation of the Secure Real-time Transport
Protocol (SRTP), the Universal Security Transform (UST), and a
supporting cryptographic kernel.
.
This package contains the shared libraries.
Homepage: http://srtp.sourceforge.net/srtp.html
Description-md5: b86be50185de339144d91624003e7952
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/s/srtp/libsrtp0_1.4.4+20100615~dfsg-1_amd64.deb
Size: 78218
MD5sum: 304d3ac5db13d91a22dbaecb2ea16bdb
SHA1: cc65c791d6d27e46ca570a459935249778164ce9
SHA256: cbea2422b86b6ddee9338b355a4645bbb4aaf670c74ffb62a7772bad8e1ec446

That's amd64. For good measure, I just tried with asterisk on a
*i386* ubuntu 12.10 VM (1.4.4+20100615~dfsg-1build1). Same issue.

blink uses python-sipsimple, the SNOM phones I don't know, but
this from their binary application inside their rootfs image may
give some clue to anyone who knows different SRTP
implementations:

$ nm -C -D 1lid | grep srtp
00428d50 W srtp_session_ctx::~srtp_session_ctx(void)
00428ec0 W srtp_ctx::~srtp_ctx(void)
0046f4a0 W srtp_session_ctx::srtp_session_ctx(void)
0046f56c W srtp_session_ctx::srtp_session_ctx(srtp_session_ctx const &)
0046f674 W srtp_ctx::srtp_ctx(srtp_ctx const &)
0046aca0 T audio_stream::copy_srtp_roc(audio_stream const &)
00468ccc T audio_stream::encrypt_srtp(str &)
004624d8 T srtcp_append_tag(srtp_ctx &, str &, int)
0046243c T srtcp_decrypt(srtp_ctx &, str &, unsigned int, long)
004623b0 T srtcp_encrypt(srtp_ctx &, str &, unsigned int)
00462168 T srtcp_set_index(srtp_ctx &, unsigned int)
004621e8 T srtcp_set_local_ssrc(srtp_ctx &)
004622d0 T srtcp_set_rem_ssrc(srtp_ctx &, long)
00461cfc T srtp_append_tag(srtp_ctx &, str &, int)
00461f04 T srtp_check_tag(srtp_ctx &, str const &, int, int)
00461c84 T srtp_decrypt(srtp_ctx &, str &, unsigned int, long)
00461bf8 T srtp_encrypt(srtp_ctx &, str &, unsigned int)
004617e0 T srtp_init(srtp_ctx &, str const &, str const &, long)
004618e0 T srtp_set_index(srtp_ctx &, unsigned int)
00461a34 T srtp_set_local_ssrc(srtp_ctx &)
00461b18 T srtp_set_rem_ssrc(srtp_ctx &, long)

All google searches with those point to SNOM so I suppose it's
their own implementation.

When looking up the issue a few months ago, I vaguely remember
coming accross an old (long solved) asterisk or srtp issue
(sorry very vague memory here) whereby the seqnum was
overflowing and somehow overiding the next field in some
structure (possibly internal or in the RTP header) and affecting
the codec identifier. Maybe there's something like that going on
in the implementation jitsi uses.

I find it strange that both streams become silent (the one jitsi
sends but also the one jitsi receives) when the seq-num wraps (I
don't mean they both become silent at the same time, just that
each becomes silent when its own seq-num wraps), as if it was a
symmetrical interoperability issue between asterisk and jitsi.

I don't know if the media traffic contains silence at that point
or if jitsi fails to decode it somehow and fails to encode it in
a way supported by asterisk. I suspect the latter though since
the asterisk generated media definitely doesn't contain blank
when sent to other clients after the seqnum wrap.

Best regards,
Stephane

···

Am 11.12.2012 03:35, schrieb Ingo Bauersachs:


#5

2012-12-11 11:04:10 +0000, Stephane Chazelas:
[...]

When looking up the issue a few months ago, I vaguely remember
coming accross an old (long solved) asterisk or srtp issue
(sorry very vague memory here) whereby the seqnum was
overflowing and somehow overiding the next field in some
structure (possibly internal or in the RTP header) and affecting
the codec identifier. Maybe there's something like that going on
in the implementation jitsi uses.

[...]

Looking it up now, I find:

http://code.google.com/p/csipsimple/issues/detail?id=524

https://issues.asterisk.org/jira/browse/ASTERISK-16898

possibly related. I don't have enough knowledge on the matter to
be able to comment any more on that.

HTH,
Stephane


#6

2012-12-11 11:23:40 +0000, Stephane Chazelas:

2012-12-11 11:04:10 +0000, Stephane Chazelas:
[...]
> When looking up the issue a few months ago, I vaguely remember
> coming accross an old (long solved) asterisk or srtp issue
> (sorry very vague memory here) whereby the seqnum was
> overflowing and somehow overiding the next field in some
> structure (possibly internal or in the RTP header) and affecting
> the codec identifier. Maybe there's something like that going on
> in the implementation jitsi uses.
[...]

Looking it up now, I find:

http://code.google.com/p/csipsimple/issues/detail?id=524

https://issues.asterisk.org/jira/browse/ASTERISK-16898

possibly related. I don't have enough knowledge on the matter to
be able to comment any more on that.

[...]

If I increase the log level on asterisk, I do see
SRTP unprotect failed with: authentication failure 110

messages now as well too.

And I've heard the sound come back most probably at the same
time as this message in asterisk logs:

SRTP unprotect failed with replay check failed (index too old), retrying

regards,
Stephane


#7

2012-12-11 11:23:40 +0000, Stephane Chazelas:

2012-12-11 11:04:10 +0000, Stephane Chazelas:
[...]

When looking up the issue a few months ago, I vaguely remember
coming accross an old (long solved) asterisk or srtp issue
(sorry very vague memory here) whereby the seqnum was
overflowing and somehow overiding the next field in some
structure (possibly internal or in the RTP header) and affecting
the codec identifier. Maybe there's something like that going on
in the implementation jitsi uses.

[...]

Looking it up now, I find:

http://code.google.com/p/csipsimple/issues/detail?id=524

https://issues.asterisk.org/jira/browse/ASTERISK-16898

Checked the Asterisk issue and according to the comments and Jira status
to me it seems that this problem was not solved on Asterisk.

I've checked the code in Jitsi and ti looks ok.

Werner

PS: I've no Asterisk code on my system to crosscheck.
W.

···

Am 11.12.2012 12:44, schrieb Stephane Chazelas:

possibly related. I don't have enough knowledge on the matter to
be able to comment any more on that.

[...]

If I increase the log level on asterisk, I do see
SRTP unprotect failed with: authentication failure 110

messages now as well too.

And I've heard the sound come back most probably at the same
time as this message in asterisk logs:

SRTP unprotect failed with replay check failed (index too old), retrying

regards,
Stephane

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#8

https://issues.asterisk.org/jira/browse/ASTERISK-16898

Checked the Asterisk issue and according to the comments and Jira status
to me it seems that this problem was not solved on Asterisk.

I've checked the code in Jitsi and ti looks ok. [...] PS: I've no
Asterisk code on my system to crosscheck.

[...]

It's still marked as unresolved indeed. From what they say, it looks
like the issue, if any, is in libsrtp (from srtp.sourceforge.net). I'm
not qualified to say who's right or wrong. It looks like an
interoperability issue. we've got a few srtp stacks that work well with
asterisk's and a few that don't.

I wish jitsi's were amongst the ones that do.

There's definitely something that jitsi and SNOM (for instance) do
differently.

Well, most client use libsrtp with SNOM and Jitsi apparently being the
exceptions. Your Asterisk output mentions libsrtp-1.4.4, which according to
the SourceForge release date, is from 2007.
Could you try to use a hand-built libsrtp based on the current CVS head?
There are quite some fixes in there, even one from August that concerns the
seq-num/ROC.

If I remember right, I needed to use the CVS version when I originally
developed the SDES code for Jitsi as Asterisk segfaulted with the release
from the debian package.

Would that help if I provided network captures for a jitsi
call and a SNOM call along with the server private key?

At least for me, no, I'd need to debug.

For now, I disable encryption and use OpenVPN.

Thanks,
Stephane

Regards,
Ingo


#9

2012-12-11 14:25:32 +0100, Werner Dittmann:
[...]

>> https://issues.asterisk.org/jira/browse/ASTERISK-16898

Checked the Asterisk issue and according to the comments and Jira status
to me it seems that this problem was not solved on Asterisk.

I've checked the code in Jitsi and ti looks ok.

[...]

PS: I've no Asterisk code on my system to crosscheck.

[...]

It's still marked as unresolved indeed. From what they say, it
looks like the issue, if any, is in libsrtp (from
srtp.sourceforge.net). I'm not qualified to say who's right or
wrong. It looks like an interoperability issue. we've got a few
srtp stacks that work well with asterisk's and a few that
don't.

I wish jitsi's were amongst the ones that do.

There's definitely something that jitsi and SNOM (for instance)
do differently. Would that help if I provided network captures
for a jitsi call and a SNOM call along with the server private
key?

For now, I disable encryption and use OpenVPN.

Thanks,
Stephane


#10

2012-12-11 09:28:26 -0500, Ingo Bauersachs:

>>>> https://issues.asterisk.org/jira/browse/ASTERISK-16898
>>
>> Checked the Asterisk issue and according to the comments and Jira status
>> to me it seems that this problem was not solved on Asterisk.
>>
>> I've checked the code in Jitsi and ti looks ok. [...] PS: I've no
>> Asterisk code on my system to crosscheck.
> [...]
>
> It's still marked as unresolved indeed. From what they say, it looks
> like the issue, if any, is in libsrtp (from srtp.sourceforge.net). I'm
> not qualified to say who's right or wrong. It looks like an
> interoperability issue. we've got a few srtp stacks that work well with
> asterisk's and a few that don't.
>
> I wish jitsi's were amongst the ones that do.
>
> There's definitely something that jitsi and SNOM (for instance) do
> differently.

Well, most client use libsrtp with SNOM and Jitsi apparently being the
exceptions. Your Asterisk output mentions libsrtp-1.4.4, which according to
the SourceForge release date, is from 2007.
Could you try to use a hand-built libsrtp based on the current CVS head?
There are quite some fixes in there, even one from August that concerns the
seq-num/ROC.

[...]

Thank Ingo,

I had intended to do that but had given up after failing to do a
CVS checkout.

Anyway, I've just downloaded and compiled the CVS head, and
the behavior is still the same. The diff below between debian's
and CVS head doesn't contain much. This is the only non-cosmetic
change AFAICT:

diff -pur ./crypto/replay/rdbx.c ../srtp/srtp/crypto/replay/rdbx.c
--- a/crypto/replay/rdbx.c 2010-09-10 20:27:59.000000000 +0100
+++ b/crypto/replay/rdbx.c 2012-04-27 00:14:48.000000000 +0100
@@ -145,18 +145,18 @@ index_guess(const xtd_seq_num_t *local,
   if (local_seq < seq_num_median) {
     if (s - local_seq > seq_num_median) {
       guess_roc = local_roc - 1;
- difference = seq_num_max - s + local_seq;
+ difference = s - local_seq - seq_num_max;
     } else {
       guess_roc = local_roc;
       difference = s - local_seq;
     }
   } else {
     if (local_seq - seq_num_median > s) {
- guess_roc = local_roc+1;
- difference = seq_num_max - local_seq + s;
+ guess_roc = local_roc + 1;
+ difference = s - local_seq + seq_num_max;
     } else {
- difference = s - local_seq;
       guess_roc = local_roc;
+ difference = s - local_seq;
     }
   }
   guess_seq = s;

Cheers,
Stephane


#11

So, I finally took the time to install an Asterisk once again and look for
the culprit: It is indeed Jitsi's SRTP code. The SRTP context was constantly
being recreated for each incoming packet, and due to that, the ROC never
increased. With the attached patch, I had a 3h+ call to Asterisk's
Echo-Service.
ZRTP is not affected, as it wraps the broken SRTP code.

Devs: How do I have to commit changes to libjitsi? Standard commit to
libjitsi, make libjitsi, copy libjitsi.jar created in the root directory to
jitsi/lib/installer-exclude, second commit?

Stephane: Once this is in Jitsi and it still doesn't work with the shipped
version of libsrtp, please try to update the lib as your diff showed changes
in the ROC calculation after all. I did my tests with the CVS snapshot of
libsrtp + the patches from the Ubuntu/Debian repository to create a shared
library [1]:

dpkg -r --force-depends libsrtp0
tar -xvf libsrtp.tar
#apply all patches listed in [1]/debian/patches/series
patch -p1 < 100xx.patch
./configure --prefix=/usr
make
make install

Regards,
Ingo

[1]
http://archive.ubuntu.com/ubuntu/pool/universe/s/srtp/srtp_1.4.4+20100615~df
sg-1.debian.tar.gz

srtp-context-creation.patch (3.82 KB)


#12

Hey Ingo,

Devs: How do I have to commit changes to libjitsi? Standard commit to
libjitsi, make libjitsi, copy libjitsi.jar created in the root directory

to

jitsi/lib/installer-exclude, second commit?

Yes, that's it! Thanks for taking care of this. It's been a long standing
one!

Cheers,
Emil


#13

Ingo,

actually I think the way you fixed it is not entirely correct.

If I remember correctly the design was that the SRTPTransformEngine is just a
SRTP context creation/maintainig class and once the SRTP context is setup the
caller shall get the SRTPTransformer that belongs to that contaxt. The caller
uses the SRTPTransfomer, not the SRTPTransformEngine and shall even "forget"
the STRPTRansformEngine.

That's the reason why SRTPTransformer.close() calls the STRPTRansformEngine.close()
and not vice versa.

(This is already several years ago and I don't know if my mail archives still
contain the e-mail exchange where Bing Su described this :slight_smile: )

The fix may lead to a memory leak (depends on the GC strategies): after the fix
the STRPTRansformEngine and the SRTPTransfomer references each other (circular
reference) and none of them clears the refs when closing. Also calling
STRPTRansformEngine.close() does not close the SRTPTransfomer.

My proposal to fix: the SDES code shall get the SRTPTransfomer once it had created
the STRPTRansformEngine, forget STRPTRansformEngine, use SRTPTransfomer and call
SRTPTransformer.close() once it's done with SRTP.

Werner

···

Am 25.12.2012 09:11, schrieb Emil Ivov:

Hey Ingo,

Devs: How do I have to commit changes to libjitsi? Standard commit to
libjitsi, make libjitsi, copy libjitsi.jar created in the root directory

to

jitsi/lib/installer-exclude, second commit?

Yes, that's it! Thanks for taking care of this. It's been a long standing
one!

Cheers,
Emil

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#14

Hey Werner

actually I think the way you fixed it is not entirely correct.

Thanks for reviewing!

If I remember correctly the design was that the SRTPTransformEngine is

just a

SRTP context creation/maintainig class and once the SRTP context is setup

the

caller shall get the SRTPTransformer that belongs to that contaxt. The

caller

uses the SRTPTransfomer, not the SRTPTransformEngine and shall even

"forget"

the STRPTRansformEngine.

Well, at least according to the Javadoc, your description makes no sense:

* SRTPTransformEngine class implements TransformEngine interface.
* It stores important information / objects regarding SRTP processing.
* Through SRTPTransformEngine, we can get the needed PacketTransformer,
which
* will be used by abstract TransformConnector classes.

If the TransformEngine interface is implemented, I expect to be able to use
it directly as a TransformEngine in the upper layers. And our upper layers
call getRTPTransformer()/getRTCPTransformer() for every packet.
SRTPContextFactory, SRTPContextCreator or SRTPMasterContext would actually
be a better name for SRTPTransformEngine when doing like you describe
(dropping the two getRT(C)PTransformer methods completely).

That's the reason why SRTPTransformer.close() calls the
STRPTRansformEngine.close() and not vice versa.

The close stuff is new and doesn't necessarily adhere to the original
design.

(This is already several years ago and I don't know if my mail archives

still

contain the e-mail exchange where Bing Su described this :slight_smile: )

The fix may lead to a memory leak (depends on the GC strategies): after
the fix the STRPTRansformEngine and the SRTPTransfomer references each
other (circular reference) and none of them clears the refs when
closing. Also calling STRPTRansformEngine.close() does not close the
SRTPTransfomer.

STRPTRansformEngine.close() does not close the transformers as this would
cause a stack overflow. Clearing out references is generally considered
performance wasting in a managed language. If a GC had problems with
circular dependencies, it would be completely broken. A GC constructs a
graph and throws away any partial graph or object that has no edge to the
root object. But that's not the topic here.

My proposal to fix: the SDES code shall get the SRTPTransfomer once it
had created the STRPTRansformEngine, forget STRPTRansformEngine, use
SRTPTransfomer and call SRTPTransformer.close() once it's done with SRTP.

Done so in the attached patch, along with some refactoring as the
SRTPTransformEngine is really not an engine. Is this one okay for you?

Werner

Ingo

srtp-context-creation.patch (16.6 KB)


#15

2012-12-25 16:57:54 +0100, Ingo Bauersachs:
[...]

Done so in the attached patch, along with some refactoring as the
SRTPTransformEngine is really not an engine. Is this one okay for you?

[...]

Thanks a lot for looking into it! (on Christmas day! That's
dedication :-)).

I had trouble applying the patch as it wasn't reflecting the
fact that the SRTPTransformEngine had been renamed, and it was
missing a diff for
src/org/jitsi/impl/neomedia/transform/srtp/AsymmetricSRTPTransformer.java
that was referencing SRTPTransformEngine.

After resolving those issues and building libjitsi and jitsi
with the new libjitsi, I confirm that the issue goes away.
However I hear a short screeching sound consistently when the
sequence number wraps during the "echo test" though no error in
the asterisk logs (no big deal, and acceptable for me, but
suggests there may still be something wrong). No such screeching
sound with SNOM phones.

In jitsi logs, at that time we have:
13:38:25.138 INFO: net.sf.fmj.media.Log.info() Resetting queue, last seq added: 65535, current seq: 0

That's with an unmodified libsrtp from debian on the asterisk side.

Using PortAudio on debian amd64, direct "hw" alsa devices.

All the best for jitsi and its developers in this new year 2013!
Stephane


#16

From: Stephane Chazelas
2012-12-25 16:57:54 +0100, Ingo Bauersachs:
[...]

Done so in the attached patch, along with some refactoring as the
SRTPTransformEngine is really not an engine. Is this one okay for you?

[...]

Thanks a lot for looking into it! (on Christmas day! That's
dedication :-)).

I had trouble applying the patch as it wasn't reflecting the fact that
the SRTPTransformEngine had been renamed, and it was missing a diff for
src/org/jitsi/impl/neomedia/transform/srtp/AsymmetricSRTPTransformer.java
that was referencing SRTPTransformEngine.

One of Git's quirks... sorry.

After resolving those issues and building libjitsi and jitsi
with the new libjitsi, I confirm that the issue goes away.
However I hear a short screeching sound consistently when the
sequence number wraps during the "echo test" though no error in
the asterisk logs (no big deal, and acceptable for me, but
suggests there may still be something wrong). No such screeching
sound with SNOM phones.

In jitsi logs, at that time we have:
13:38:25.138 INFO: net.sf.fmj.media.Log.info() Resetting queue, last seq
added: 65535, current seq: 0

I've seen that too (but haven't noticed anything audible). A packet coming
from Asterisk is considered invalid by the GSM decoder. That's however
already after the SRTP processing: if the packet were invalid at the
encryption layer, it wouldn't even reach the decoder. This must be something
else.

That's with an unmodified libsrtp from debian on the asterisk side.

Good to know.

Using PortAudio on debian amd64, direct "hw" alsa devices.

Probably unrelated.

All the best for jitsi and its developers in this new year 2013!

Thanks a lot! All the best for you as well!

Stephane

Regards,
Ingo


#17

2013-01-03 15:11:34 +0100, Ingo Bauersachs:
[...]

> However I hear a short screeching sound consistently when the
> sequence number wraps during the "echo test" though no error in
> the asterisk logs (no big deal, and acceptable for me, but
> suggests there may still be something wrong). No such screeching
> sound with SNOM phones.
>
> In jitsi logs, at that time we have:
> 13:38:25.138 INFO: net.sf.fmj.media.Log.info() Resetting queue, last seq
> added: 65535, current seq: 0

I've seen that too (but haven't noticed anything audible). A packet coming
from Asterisk is considered invalid by the GSM decoder. That's however
already after the SRTP processing: if the packet were invalid at the
encryption layer, it wouldn't even reach the decoder. This must be something
else.

[...]

Note that in my case, it's G.711, not GSM.

···

--
Stephane


#18

2013-01-03 15:11:34 +0100, Ingo Bauersachs:
[...]

> After resolving those issues and building libjitsi and jitsi
> with the new libjitsi, I confirm that the issue goes away.
> However I hear a short screeching sound consistently when the
> sequence number wraps during the "echo test" though no error in
> the asterisk logs (no big deal, and acceptable for me, but
> suggests there may still be something wrong). No such screeching
> sound with SNOM phones.
>
> In jitsi logs, at that time we have:
> 13:38:25.138 INFO: net.sf.fmj.media.Log.info() Resetting queue, last seq
> added: 65535, current seq: 0

I've seen that too (but haven't noticed anything audible). A packet coming
from Asterisk is considered invalid by the GSM decoder. That's however
already after the SRTP processing: if the packet were invalid at the
encryption layer, it wouldn't even reach the decoder. This must be something
else.

[...]

Hi Ingo, all,

I just verified that the issue was fixed in 1.1.4405.10286 (I
saw the fix was included in revision 10236).

I still hear the screeching sound though with PCMU encoding.

I tried to force GSM codec as you said you didn't hear it with
that one and it's the same for me: no screeching sound.either.

best regards,
Stephane


#19

Hey Stephane,

2013-01-03 15:11:34 +0100, Ingo Bauersachs:
[...]

After resolving those issues and building libjitsi and jitsi
with the new libjitsi, I confirm that the issue goes away.
However I hear a short screeching sound consistently when the
sequence number wraps during the "echo test" though no error in
the asterisk logs (no big deal, and acceptable for me, but
suggests there may still be something wrong). No such screeching
sound with SNOM phones.

In jitsi logs, at that time we have:
13:38:25.138 INFO: net.sf.fmj.media.Log.info() Resetting queue, last seq
added: 65535, current seq: 0

I've seen that too (but haven't noticed anything audible). A packet coming
from Asterisk is considered invalid by the GSM decoder. That's however
already after the SRTP processing: if the packet were invalid at the
encryption layer, it wouldn't even reach the decoder. This must be something
else.

[...]

Hi Ingo, all,

I just verified that the issue was fixed in 1.1.4405.10286 (I
saw the fix was included in revision 10236).

I still hear the screeching sound though with PCMU encoding.

Could you please open an issue for this?

Thanks,
Emil

···

On 17.01.13, 15:49, Stephane Chazelas wrote:

I tried to force GSM codec as you said you didn't hear it with
that one and it's the same for me: no screeching sound.either.

best regards,
Stephane

--
https://jitsi.org


#20

2013-01-19 03:42:45 +0100, Emil Ivov:
[...]

> I still hear the screeching sound though with PCMU encoding.

Could you please open an issue for this?

[...]

Done: http://java.net/jira/browse/JITSI-1099

···

--
Stephane