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
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,
$ apt-cache show libsrtp0
Maintainer: Jonas Smedegaard <email@example.com>
Depends: libc6 (>= 2.4)
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.
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
$ 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.
Am 11.12.2012 03:35, schrieb Ingo Bauersachs: