[jitsi-dev] SDES for SIP calls


#1

Hey all

I'm now committing the integration of the SDES (also known as S-Descriptor or SRTP) key-exchange method as an alternative to ZRTP for secure SIP calls. This is a huge patch-set and I'd ask all developers to review the commit logs if I touched "their" code in case I made something you don't like.
Especially Werner, as I had to adapt some ZRTP stuff as well.

After a lengthy discussion with Emil, there is also a note about the reference of the Call UIs SecurityPanel to the neomedia package. In order to keep the overall codebase simpler and easier to maintain, we decided to pass a reference to the SrtpControl (formerly ZrtpControl) object in the security events. This avoids walking through the CallPeer to the OpSets to neomedia, doing redundant checks, providing methods that cannot always be called in a PPS and eases the integration of further key-exchange methods (MIKEY, which is in the pipeline).
If someone still has a good argument against that way, I'm happy to listen.

Regards,
Ingo


#2

2011-10-04 14:33:48 +0200, Bauersachs Ingo:

I'm now committing the integration of the SDES (also known as
S-Descriptor or SRTP) key-exchange method as an alternative to
ZRTP for secure SIP calls. This is a huge patch-set and I'd
ask all developers to review the commit logs if I touched
"their" code in case I made something you don't like.
Especially Werner, as I had to adapt some ZRTP stuff as well.

After a lengthy discussion with Emil, there is also a note
about the reference of the Call UIs SecurityPanel to the
neomedia package. In order to keep the overall codebase
simpler and easier to maintain, we decided to pass a reference
to the SrtpControl (formerly ZrtpControl) object in the
security events. This avoids walking through the CallPeer to
the OpSets to neomedia, doing redundant checks, providing
methods that cannot always be called in a PPS and eases the
integration of further key-exchange methods (MIKEY, which is
in the pipeline).
If someone still has a good argument against that way, I'm happy to listen.

[...]

That's great news!

The very feature I was missing for jitsi to be the best possible
SIP+XMPP client for my needs.

The first try with asterisk (SIP-TLS+SRTP/SDES) looks
promissing. I am able to call jitsi from another extension
through asterisk,though for some reason there's a delay (about
30 seconds but varying) from the time I accept the call on jitsi
to the call being established (during which the other end ears a
ring tone).

If the call is initiated by jitsi though, I get the same kind of
delay (seems to be an issue with jitsi as I don't see network traffic from
jitsi for some of that delay), but then the call is rejected by asterisk with a
"488 Not acceptable here" and the log saying (misleadingly)
"We are requesting SRTP, but they responded without it!"

I had looked at that for another client. What asterisk doesn't
like here is this SDP:

v=0
o=me 0 0 IN IP4 10.10.10.4
s=-
c=IN IP4 x.x.x.x
t=0 0
m=audio 5000 RTP/AVP 9 96 97 98 100 0 8 102 3 103 5 6 15 101
a=rtpmap:9 G722/8000
a=rtpmap:96 SILK/24000
a=rtpmap:97 SILK/16000
a=rtpmap:98 speex/32000
a=rtpmap:100 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:102 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:103 speex/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:6 DVI4/16000
a=rtpmap:15 G728/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:iYqbGM1Cwg8jCVBkTRSejAnINMsb91tbHLQmYnTn
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:QNrGESiAkrwqlySuBTNgwR0DnFGlwrkN1CuUu5y4
m=video 5002 RTP/AVP 104 99
a=recvonly
a=rtpmap:104 H264/90000
a=fmtp:104 packetization-mode=1
a=imageattr:104 send [x=[0-640],y=[0-480]] recv [x=[0-1920],y=[0-1200]]
a=rtpmap:99 H264/90000
a=imageattr:99 send [x=[0-640],y=[0-480]] recv [x=[0-1920],y=[0-1200]]
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:4fxmTFKLwZFqfW10/YKWnVpwdZyL5xDU8cavoedi
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:x15r5GlPxzRM4axiLtIma9nhPRJT+2fcPobPVpHe

That is the crypto parameters without the RTP/SAVP

(it could very well be a bug in asterisk encryption negociation).

···

--
Stephane


#3

Hi,

this is indeed a __very__ huge patch and it is IMHO quite unreasonable for
one person who was not invloved in the SDES project to check or cross-check
this. I've rarely seen such a large patch in an Open Source project. Just
as a hint/proposal: don#T take this into the stable release before many users
have tested this.

A first short note from my side - just by browsing the code: the generic rename of some
parts from ZrtpControl to SrtpControl may lead to confusion. As an example
out of several: I've seen functions called "setMultistream(...)" or
"getMediaHandler().startSrtpMultistream(multiStreamData)" .

This is in fact really confusing: SRTP does not have a multistream feature, SRTP handles
exactly one stream (RTP session). Multistream is a ZRTP feature to avoid duplicate
negotiation using public key methods and thus saving CPU cycles and protocol
handshakes.

Some other information see below.

Best regards,
Werner

Hey all

I'm now committing the integration of the SDES (also known as S-Descriptor or SRTP) key-exchange method as an alternative to ZRTP for secure SIP calls. This is a huge patch-set and I'd ask all developers to review the commit logs if I touched

"their" code in case I made something you don't like.

Especially Werner, as I had to adapt some ZRTP stuff as well.

A not completey correct description of SDES above:
Session Description Protocol Security Description for Media Streams.

Ingo's decsription may indicate that SRTP is used to exchange key material, that's not the case.
All key material is exchanged in the SIP message.

And here we should issue a big warning to the end user (except Jitsi fully supports SIP S/MIME
to encrypt data inside the SIP message - but I doubt Jitsi supports this :slight_smile: )

···

Am 04.10.2011 14:33, schrieb Bauersachs Ingo:

*****
***** SDES uses SIP message to transport the key data as plain text data.
*****
***** If you use SDES to exchange SRTP keyes then ALL SIP providers MUST support SIPS (secure SIP)
***** and use SIPS to communicate with your client and with the client of the called party.
***** If the clients or the SIP providers do not support SIPS then they MUST use IPsec or an
***** encrypted VPN to communicate.
*****
***** SIP providers MUST communicate via secure (encrypted) channels when routing the SIP messages,
***** this can be either SIPS or IPsec or an encyrpted VPN
*****
***** Your SIP provider and the SIP provider of the called party can read the SRTP key material
***** because SIPS, IPsec, or encrypted VPN provide full end-to-end encryption.
*****

Quote from RFC 4568:
"The SDP security descriptions defined here are suitable for restricted cases only where IPsec,
TLS, or some other encapsulating data-security protocol (e.g., SIP S/MIME) protects the
SDP message.
"

Such an information is IMHO necessary because only a few provides support SIPS or other
equivalent security protocols. Also a caller cannot be sure of the provider of the called
party has implemented the same or simliar security protocols.

After a lengthy discussion with Emil, there is also a note about the reference of the Call UIs SecurityPanel to the neomedia package. In order to keep the overall codebase simpler and easier to maintain, we decided to pass a reference to the SrtpControl (formerly ZrtpControl) object in the security events. This avoids walking through the CallPeer to the OpSets to neomedia, doing redundant checks, providing methods that cannot always be called in a PPS and eases the integration of further key-exchange methods (MIKEY, which is in the pipeline).
If someone still has a good argument against that way, I'm happy to listen.

Regards,
Ingo


#4

2011-10-04 16:41:19 +0100, Stephane Chazelas:
[...]

If the call is initiated by jitsi though, I get the same kind of
delay (seems to be an issue with jitsi as I don't see network traffic from
jitsi for some of that delay)

If I move the mouse and click on the call window, it reduces the
delay (this is on debian testing amd64).

but then the call is rejected by asterisk with a
"488 Not acceptable here" and the log saying (misleadingly)
"We are requesting SRTP, but they responded without it!"

[...]

Sorry, my bad, I had missed the RTP/SAVP configuration settings.
If I select Optional, it fails with "Faling due to too many
media streams" on:

v=0
o=me 0 0 IN IP4 x.x.x.x
s=-
c=IN IP4 x.x.x.x
t=0 0
m=audio 5008 RTP/SAVP 9 96 97 98 100 0 8 102 3 103 5 6 15 101
a=rtpmap:9 G722/8000
a=rtpmap:96 SILK/24000
a=rtpmap:97 SILK/16000
a=rtpmap:98 speex/32000
a=rtpmap:100 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:102 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:103 speex/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:6 DVI4/16000
a=rtpmap:15 G728/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5ScMZhl4/afEQVzzb9ccKtuObaRTeBDuTI0fgU2D
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:Pp/qkKuRAU4N5SLym2C44L4h3/ppFNCw8B0JZOjZ
m=audio 5008 RTP/AVP 9 96 97 98 100 0 8 102 3 103 5 6 15 101
a=rtpmap:9 G722/8000
a=rtpmap:96 SILK/24000
a=rtpmap:97 SILK/16000
a=rtpmap:98 speex/32000
a=rtpmap:100 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:102 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:103 speex/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:6 DVI4/16000
a=rtpmap:15 G728/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5010 RTP/SAVP 104 99
a=recvonly
a=rtpmap:104 H264/90000
a=fmtp:104 packetization-mode=1
a=imageattr:104 send [x=[0-640],y=[0-480]] recv [x=[0-1920],y=[0-1200]]
a=rtpmap:99 H264/90000
a=imageattr:99 send [x=[0-640],y=[0-480]] recv [x=[0-1920],y=[0-1200]]
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Wg+GE0vsFerplfnODoRqQuMXLMSkKUSWlWnC7qOz
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:lP/y6pCKoUtggWKSl6YtmvGFVn/aIxnpPRgSAVbO
m=video 5010 RTP/AVP 104 99
a=recvonly
a=rtpmap:104 H264/90000
a=fmtp:104 packetization-mode=1
a=imageattr:104 send [x=[0-640],y=[0-480]] recv [x=[0-1920],y=[0-1200]]
a=rtpmap:99 H264/90000
a=imageattr:99 send [x=[0-640],y=[0-480]] recv [x=[0-1920],y=[0-1200]]

With "mandatory", it works though I'm seeing some "SRTP
unprotect: authentication failure" in asterisk logs every few
seconds:

[...]
[2011-10-04 17:22:36] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:39] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:40] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:43] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:44] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:47] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:50] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:53] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:53] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:58] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:22:58] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:03] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:04] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:08] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:09] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:11] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:12] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:14] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:16] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:20] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:20] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:26] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:27] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:30] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:30] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:33] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[2011-10-04 17:23:34] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure
[...]

Not sure what they mean (asterisk is using libsrtp)

···

--
Stephane


#5

2011-10-04 20:05:49 +0200, Werner Dittmann:
[...]

Quote from RFC 4568:
"The SDP security descriptions defined here are suitable for restricted cases only where IPsec,
TLS, or some other encapsulating data-security protocol (e.g., SIP S/MIME) protects the
SDP message.
"

Such an information is IMHO necessary because only a few provides support SIPS or other
equivalent security protocols. Also a caller cannot be sure of the provider of the called
party has implemented the same or simliar security protocols.

[...]

Enterprise deployments with SIP-TLS and SRTP are the typical
case where that is needed and ZRTP not desirable (you want
clients (employees) to be able to talk to each other securely from
all over the world including from untrusted public networks but
the central company PBX has to be able to monitor all the
calls).

jitsi does support SIP-TLS, as well as the major free software
IP PBXes (asterisk, freeswitch).

···

--
Stephane


#6

Hey

this is indeed a __very__ huge patch and it is IMHO quite unreasonable for
one person who was not invloved in the SDES project to check or cross-
check
this. I've rarely seen such a large patch in an Open Source project. Just
as a hint/proposal: don#T take this into the stable release before many
users have tested this.

Well, just committing parts of it wouldn't have made any sense. I'd love to hear an idea on how to do it better.

A first short note from my side - just by browsing the code: the generic
rename of some
parts from ZrtpControl to SrtpControl may lead to confusion. As an example
out of several: I've seen functions called "setMultistream(...)" or
"getMediaHandler().startSrtpMultistream(multiStreamData)" .

This is in fact really confusing: SRTP does not have a multistream
feature, SRTP handles
exactly one stream (RTP session). Multistream is a ZRTP feature to avoid
duplicate
negotiation using public key methods and thus saving CPU cycles and
protocol handshakes.

I don't like that as well. It is the last leftover from ZRTP in the general stuff. But I haven't come up with an idea yet how to separate this out of the general Control without losing the generalization approach.
And although SRTP itself doesn't have this kind of multistream, it could be possible that another key exchange appears which would require something like this.

> I'm now committing the integration of the SDES (also known as S-
Descriptor or SRTP) key-exchange method as an alternative to ZRTP for
secure SIP calls. This is a huge patch-set and I'd ask all developers to
review the commit logs if I touched
"their" code in case I made something you don't like.
> Especially Werner, as I had to adapt some ZRTP stuff as well.

A not completey correct description of SDES above:
Session Description Protocol Security Description for Media Streams.

Ingo's decsription may indicate that SRTP is used to exchange key
material, that's not the case.
All key material is exchanged in the SIP message.

Correct. Sadly lots of clients and literature name RFC4568 simply "SRTP" encryption. And that's why I wrote "aka SRTP".

And here we should issue a big warning to the end user (except Jitsi fully
supports SIP S/MIME
to encrypt data inside the SIP message - but I doubt Jitsi supports this
:slight_smile: )

No, it doesn't (yet? :-).

*****
***** SDES uses SIP message to transport the key data as plain text data.
*****
***** If you use SDES to exchange SRTP keyes then ALL SIP providers MUST
support SIPS (secure SIP)
***** and use SIPS to communicate with your client and with the client of
the called party.
***** If the clients or the SIP providers do not support SIPS then they
MUST use IPsec or an
***** encrypted VPN to communicate.
*****
***** SIP providers MUST communicate via secure (encrypted) channels when
routing the SIP messages,
***** this can be either SIPS or IPsec or an encyrpted VPN
*****
***** Your SIP provider and the SIP provider of the called party can read
the SRTP key material
***** because SIPS, IPsec, or encrypted VPN provide full end-to-end
encryption.
*****

The SIP account reg. wizard has SDES disabled by default and the option to enable it is already hidden behind a big warning. We could extend this warning with the information you wrote above.

Quote from RFC 4568:
"The SDP security descriptions defined here are suitable for restricted
cases only where IPsec,
TLS, or some other encapsulating data-security protocol (e.g., SIP
S/MIME) protects the
SDP message.
"

Such an information is IMHO necessary because only a few provides support
SIPS or other
equivalent security protocols. Also a caller cannot be sure of the
provider of the called
party has implemented the same or simliar security protocols.

True. I couldn't find any public SIP provider supporting TLS. But as Stephane already noted, the expected usage is primarily for users inside a corporate environment where e.g. an Asterisk server is running (with TLS enabled).

Thanks for your input!
Ingo


#7

Hey

With "mandatory", it works though I'm seeing some "SRTP unprotect:
authentication failure" in asterisk logs every few seconds:

[...]
[2011-10-04 17:22:36] WARNING[20411] res_srtp.c: SRTP unprotect:
authentication failure
[...]

Not sure what they mean (asterisk is using libsrtp)

I saw these messages too, and they are also generated when Snom or Linksys SIP Hardphones make calls through Asterisk. I don't know what they mean. I think there are some bug entries in Asterisk's Bugzilla (can't remember the ID though).

Ingo


#8

Hey

.....

And here we should issue a big warning to the end user (except Jitsi fully
supports SIP S/MIME
to encrypt data inside the SIP message - but I doubt Jitsi supports this
:slight_smile: )

No, it doesn't (yet? :-).

Would be somewhat complex given the need of a full blown certificate handling :slight_smile: .
I saw/used that once is a larger company and it was very difficault to educate the
users about this stuff, how to deal with certs, when to renew certs on a regular
basis, etc.

*****
***** SDES uses SIP message to transport the key data as plain text data.
*****
***** If you use SDES to exchange SRTP keyes then ALL SIP providers MUST
support SIPS (secure SIP)
***** and use SIPS to communicate with your client and with the client of
the called party.
***** If the clients or the SIP providers do not support SIPS then they
MUST use IPsec or an
***** encrypted VPN to communicate.
*****
***** SIP providers MUST communicate via secure (encrypted) channels when
routing the SIP messages,
***** this can be either SIPS or IPsec or an encyrpted VPN
*****
***** Your SIP provider and the SIP provider of the called party can read
the SRTP key material
***** because SIPS, IPsec, or encrypted VPN provide full end-to-end
encryption.
*****

The SIP account reg. wizard has SDES disabled by default and the option to enable it is already hidden behind a big warning. We could extend this warning with the information you wrote above.

Quote from RFC 4568:
"The SDP security descriptions defined here are suitable for restricted
cases only where IPsec,
TLS, or some other encapsulating data-security protocol (e.g., SIP
S/MIME) protects the
SDP message.
"

Such an information is IMHO necessary because only a few provides support
SIPS or other
equivalent security protocols. Also a caller cannot be sure of the
provider of the called
party has implemented the same or simliar security protocols.

True. I couldn't find any public SIP provider supporting TLS. But as Stephane already noted, the expected usage is primarily for users inside a corporate environment where e.g. an Asterisk server is running (with TLS enabled).

In a public network this could even render to nearly impossible: using SDES
without S/MIME requiers that the _whole_ SIP signaling network must be protected.
If only one provider in the signaling chain fails to do that or plays foul
then the whole security fails. BTW, this is also a major problem for internal
networks in larger companies and requiers quite some effort as I know :slight_smile: .

Best regards,
Werner

···

Am 05.10.2011 00:58, schrieb Bauersachs Ingo:

Thanks for your input!
Ingo


#9

2011-10-04 17:28:37 +0100, Stephane Chazelas:

2011-10-04 16:41:19 +0100, Stephane Chazelas:
[...]
> If the call is initiated by jitsi though, I get the same kind of
> delay (seems to be an issue with jitsi as I don't see network traffic from
> jitsi for some of that delay)

If I move the mouse and click on the call window, it reduces the
delay (this is on debian testing amd64).

[...]

It occurs as well in
jitsi_1.0-beta1-nightly.build.3691_amd64.deb

But not on the Win7 amd64 one (with same settings).

If I turn SDES off, the delay disappears. Note that it makes it
unusable.

[...]

With "mandatory", it works though I'm seeing some "SRTP
unprotect: authentication failure" in asterisk logs every few
seconds:

[...]
[2011-10-04 17:22:36] WARNING[20411] res_srtp.c: SRTP unprotect: authentication failure

[...]

I'm seeing those as well with the Win7 client.

···

--
Stephane


#10

Hey

With "mandatory", it works though I'm seeing some "SRTP unprotect:
authentication failure" in asterisk logs every few seconds:

[...]
[2011-10-04 17:22:36] WARNING[20411] res_srtp.c: SRTP unprotect:
authentication failure
[...]

Not sure what they mean (asterisk is using libsrtp)

In libsrtp this means that the authentication code of the received packet
does not match the computed authentication code. This is usually the case
if both parties use different keys to encrypt, or one party does not encrypt
at all, or that there was a problem during data transmission (bit error).
The last one is quite unusual because UDP (as well as TCP for that matter)
use a checksum to detect transmission problems.

When I implemented / tested SRTP for Jitsi (and others) this error usually
indicated that one party has not yet activated SRTP: it's normal to see a
few packets with this error after the clients enable SRTP. A client that
enabled SRTP reports this error for packets that are already sent by the
other client before this client sends its first SRTP packets (packets in
transfer). However, if this error persists for more that a few packets then
it's more serious - see above.

Best regards,
Werner

···

Am 05.10.2011 01:01, schrieb Bauersachs Ingo:

I saw these messages too, and they are also generated when Snom or Linksys SIP Hardphones make calls through Asterisk. I don't know what they mean. I think there are some bug entries in Asterisk's Bugzilla (can't remember the ID though).

Ingo


#11

2011-10-05 12:27:36 +0100, Stephane Chazelas:

2011-10-04 17:28:37 +0100, Stephane Chazelas:
> 2011-10-04 16:41:19 +0100, Stephane Chazelas:
> [...]
> > If the call is initiated by jitsi though, I get the same kind of
> > delay (seems to be an issue with jitsi as I don't see network traffic from
> > jitsi for some of that delay)
>
> If I move the mouse and click on the call window, it reduces the
> delay (this is on debian testing amd64).
[...]

It occurs as well in
jitsi_1.0-beta1-nightly.build.3691_amd64.deb

But not on the Win7 amd64 one (with same settings).

If I turn SDES off, the delay disappears. Note that it makes it
unusable.

[...]

It occurs as well with the x86 build on Ubuntu 10.04 (with openjdk,
the one above was on debian testing with java-sun-6)

···

--
Stephane


#12

If the call is initiated by jitsi though, I get the same kind of delay
(seems to be an issue with jitsi as I don't see network traffic from
jitsi for some of that delay)

If I move the mouse and click on the call window, it reduces the
delay (this is on debian testing amd64).

[...]

If I turn SDES off, the delay disappears. Note that it makes it unusable.

Thanks a lot for your feedback!
I found the cause for the delay: The default implementation of Java's SecureRandom (used for generating the encryption key and salt) relies on /dev/random, which is known to be painfully slow sometimes.
It doesn't matter where you move your mouse, as you start seeding the random number generator with this.

I'm looking at using the same random generator ZRTP uses and hope to have a fix sometime tomorrow.

[...]

With "mandatory", it works though I'm seeing some "SRTP
unprotect: authentication failure" in asterisk logs every few
seconds:

[...]
[2011-10-04 17:22:36] WARNING[20411] res_srtp.c: SRTP unprotect:

authentication failure
[...]

I'm seeing those as well with the Win7 client.

These are definitely not OS dependent, and also occur with Snom and Linksys hardphones.

Ingo


#13

When I implemented / tested SRTP for Jitsi (and others) this error
usually indicated that one party has not yet activated SRTP: it's normal
to see a few packets with this error after the clients enable SRTP. A
client that enabled SRTP reports this error for packets that are already
sent by the other client before this client sends its first SRTP packets
(packets in transfer). However, if this error persists for more that a
few packets then it's more serious - see above.

If SDES is enabled, then not one single RTP packet should go out without being encrypted. So this shouldn't be the case. The message appears in a relatively regular interval. My suspicion is therefore that it's about SRTCP packets - which are not encrypted (neither in SDES nor in ZRTP).

Ingo


#14

2011-10-05 09:24:48 +0200, Bauersachs Ingo:

> When I implemented / tested SRTP for Jitsi (and others) this error
> usually indicated that one party has not yet activated SRTP: it's normal
> to see a few packets with this error after the clients enable SRTP. A
> client that enabled SRTP reports this error for packets that are already
> sent by the other client before this client sends its first SRTP packets
> (packets in transfer). However, if this error persists for more that a
> few packets then it's more serious - see above.

If SDES is enabled, then not one single RTP packet should go
out without being encrypted. So this shouldn't be the case.
The message appears in a relatively regular interval. My
suspicion is therefore that it's about SRTCP packets - which
are not encrypted (neither in SDES nor in ZRTP).

[...]

It's true, I've checked yesterday, those messages occur at the
same rate as some of the SRTCP packets, though not synchronously
with them (AFAICT though I could be wrong as tshark delays its
output).

In the call, there is one audio and one video media channel, but
only the audio was being used, I can try and see if it occurs as
well with video calls.

Note that while those messages occur, both parties can hear each
other perfectly.

Cheers,
Stephane