[jitsi-dev] Jitsi with FMJ, reports and problems


#1

Dear all,

some reports (just to keep you busy also in 2012 :slight_smile: ) and stuff found during some
tests. I performed these tests after Jitsi switched to FMJ to check for possible
regressions in ZRTP, SRTP, SRTCP .

Used environment:

- Jitsi, fresh from SVN, compiled and built using "ant rebuild" and/or "ant make"
- openSuSE 12.1 64bit, java version "1.6.0_29" (Sun) 64bit

First the good news: ZRTP, SRTP and SRTCP work, tested against Phil Zimmermann's
Zfone implementation. I used a PJSUA client without ZRTP enabled and Zfone's
"Bump-in-the-wire" feature performed the ZRTP, SRTP, SRTCP handling. As usual I used
my beloved Wireshark to check the real stuff on the network. With regard to
ZRTP, SRTP, SRTCP - all lights are green.

Now some not so good news. While most of these findings did'nt prevent Jitsi from
working inside my test environment, IMHO it would be a good idea to check and probably
fix the problems.

1) the FMJ RTP implementation does not handle the RTP timestamp correctly. The
聽聽聽timestamp value in the first RTP packet is always 0xffff and is then decremented
聽聽聽by 1 for each sent RTP packet. This is not according to RFC 3550, chapter 5.1 .
聽聽聽During the tests I use the PCMA codec with 8000Hz sampling rate thus the timestamp
聽聽聽must _increase_ by 160 for every 20ms (80 for every 10ms) sample. This wrong handling
聽聽聽may prevent the other applications from computing correct jitter and synchronisation
聽聽聽of streams.

2) Jitsi now uses a very large sample time. It sends 480 samples in one RTP packet. This
聽聽聽computes to a sample time of 60ms. IMHO this is far too long, a sample time of 20ms
聽聽聽or 30ms should be used instead. The RTP timestamp value should be computed accordingly
聽聽聽to match the sample time.

3) Jitsi sends RTP packets with a large jitter. The wireshark protocols show that Jitsi
聽聽聽does not send RTP packets in regulary intervals that matches the sample time. During
聽聽聽my tests the RTP send intervals were between ~40ms and ~80/90ms. The intervals should
聽聽聽be ~55ms - ~65ms in general if the sample time is set to 60ms. IMHO the sending interval
聽聽聽should be in a range of +-15% of the sample time for smaller sample times, +-%5 for
聽聽聽large sample times.

4) While testing SRTCP I noticed that Jitsi produces RTCP data even after the call was
聽聽聽closed. This data does not go to the network, but some debug statements that I used
聽聽聽to check encrypted/decrypted data showed this fact. This goes on until I close Jitsi
聽聽聽(I haven't checked if Jitsi/FMJ also produces RTP output in a similar way).
聽聽聽To me it looks like there are problems in the FMJ RTCP handling (agreed, RTCP handling
聽聽聽is somewhat complex :slight_smile: ).

If necessary I can provide a wireshark trace (~200k), just drop me a line.

Best regards
Werner

Below the annotated debug output, recorded after closing the call:

聽聽// **** Jitsi sends SR, no RR, SDES, BYE, reason: Closed Stream
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c8 00 06 98 b2 38 74 4f 00 2d b5 0c 08 31 26 ......8tO.-...1&
聽聽聽聽聽[java] ff ff fe b3 00 00 01 4c 00 02 70 60 81 ca 00 06 .......L..p`....
聽聽聽聽聽[java] 98 b2 38 74 01 11 77 65 72 6e 65 72 40 6c 69 6e ..8t..werner@lin
聽聽聽聽聽[java] 75 78 62 6c 61 63 6b 00 81 cb 00 05 98 b2 38 74 uxblack.......8t
聽聽聽聽聽[java] 0d 43 6c 6f 73 65 64 20 53 74 72 65 61 6d 00 00 .Closed Stream..
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c8 00 06 98 b2 38 74 86 fa 0b c0 44 6f 8c 67 ......8t....Do.g
聽聽聽聽聽[java] 31 7a c4 01 31 cb 93 f8 e5 5e 0f 2e 67 af 7c 95 1z..1....^..g.|.
聽聽聽聽聽[java] 54 19 34 2d 12 17 dd fc df da 1d fe 2b 14 ac ba T.4-........+...
聽聽聽聽聽[java] c5 8d 0e 70 75 93 c0 0b 3d 4a 7e 7b 87 9b d0 72 ...pu...=J~{...r
聽聽聽聽聽[java] 24 df 0f a7 3d 25 8b a9 af 58 64 59 ca a6 f8 f2 $...=%...XdY....
聽聽聽聽聽[java] 80 00 00 05 50 2e 01 f1 ....P...

聽聽// **** Jitsi sends empty RR, SDES, BYE, reason: dispose - ok, but one BYE is enough
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 81 ca 00 13 98 b2 8b 5f ......._......._
聽聽聽聽聽[java] 01 11 77 65 72 6e 65 72 40 6c 69 6e 75 78 62 6c ..werner@linuxbl
聽聽聽聽聽[java] 61 63 6b 03 1f 66 6d 6a 2d 64 65 76 65 6c 40 6c ack..fmj-devel@l
聽聽聽聽聽[java] 69 73 74 73 2e 73 6f 75 72 63 65 66 6f 72 67 65 ists.sourceforge
聽聽聽聽聽[java] 2e 6e 65 74 06 0e 46 4d 4a 20 52 54 50 20 50 6c .net..FMJ RTP Pl
聽聽聽聽聽[java] 61 79 65 72 00 00 00 00 81 cb 00 03 98 b2 8b 5f ayer..........._
聽聽聽聽聽[java] 07 64 69 73 70 6f 73 65 .dispose
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 28 dc 07 f5 39 67 28 9a ......._(...9g(.
聽聽聽聽聽[java] 76 e4 2a 21 63 b9 41 03 2d 94 25 4e 6b 73 6d 5c v.*!c.A.-.%Nksm\
聽聽聽聽聽[java] fd dd 9f 75 0b 93 60 f2 cd 43 13 5b 38 23 7e 99 ...u..`..C.[8#~.
聽聽聽聽聽[java] 4f 3e 4b 66 3f e4 9a 82 48 d4 00 55 b9 ea fa 02 O>Kf?...H..U....
聽聽聽聽聽[java] 96 bb 8b c7 24 99 77 1b 16 d1 7b 36 fe d9 ca ab ....$.w...{6....
聽聽聽聽聽[java] 81 de 78 96 41 65 3b 1b 1a 81 c7 cb ec 5b bb db ..x.Ae;......[..
聽聽聽聽聽[java] cb 47 91 7f a7 4a f2 09 80 00 00 00 9e b5 8d 94 .G...J..........

聽聽// **** Jitsi sends empty RR, SDES where it announces a FMJ RTP Player again
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 81 ca 00 13 98 b2 8b 5f ......._......._
聽聽聽聽聽[java] 01 11 77 65 72 6e 65 72 40 6c 69 6e 75 78 62 6c ..werner@linuxbl
聽聽聽聽聽[java] 61 63 6b 03 1f 66 6d 6a 2d 64 65 76 65 6c 40 6c ack..fmj-devel@l
聽聽聽聽聽[java] 69 73 74 73 2e 73 6f 75 72 63 65 66 6f 72 67 65 ists.sourceforge
聽聽聽聽聽[java] 2e 6e 65 74 06 0e 46 4d 4a 20 52 54 50 20 50 6c .net..FMJ RTP Pl
聽聽聽聽聽[java] 61 79 65 72 00 00 00 00 ayer....
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 3e c2 65 64 38 44 e8 69 ......._>.ed8D.i
聽聽聽聽聽[java] 76 10 14 2d 26 39 4e 35 c8 c4 a5 31 bd 97 b9 71 v..-&9N5...1...q
聽聽聽聽聽[java] 72 55 84 db 0f 7c cb 30 56 fd a8 e2 63 6d 40 7f rU...|.0V...cm@.
聽聽聽聽聽[java] 7b 88 67 4f a6 87 51 38 70 f2 6c 82 aa 3a 41 37 {.gO..Q8p.l..:A7
聽聽聽聽聽[java] 61 39 9d 57 6c e1 f8 88 c6 22 ab 98 2d 30 c7 16 a9.Wl...."..-0..
聽聽聽聽聽[java] e1 e0 d8 9f b0 91 eb 2b 80 00 00 01 ae 3b d1 2b .......+.....;.+

聽聽// **** Jitsi sends empty RR, SDES just with CNAME
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 81 ca 00 06 98 b2 8b 5f ......._......._
聽聽聽聽聽[java] 01 11 77 65 72 6e 65 72 40 6c 69 6e 75 78 62 6c ..werner@linuxbl
聽聽聽聽聽[java] 61 63 6b 00 ack.
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f d3 5f 62 a9 1d 2f 8d fc ......._._b../..
聽聽聽聽聽[java] 05 15 3e 8c 78 e5 fd dc c4 0d 27 bf 93 62 5c 10 ..>.x.....'..b\.
聽聽聽聽聽[java] 6c 00 89 8d 80 00 00 02 c8 c8 9d 74 l..........t

聽聽// **** Jitsi sends empty RR, SDES just with CNAME
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 81 ca 00 06 98 b2 8b 5f ......._......._
聽聽聽聽聽[java] 01 11 77 65 72 6e 65 72 40 6c 69 6e 75 78 62 6c ..werner@linuxbl
聽聽聽聽聽[java] 61 63 6b 00 ack.
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 7e 6c 96 4e cc 16 30 19 ......._~l.N..0.
聽聽聽聽聽[java] b6 8e 09 75 48 6d ff e0 0a 49 6e 20 2b 82 8c 4d ...uHm...In +..M
聽聽聽聽聽[java] 0b 93 83 c1 80 00 00 03 b6 fc fa 8c ............

聽聽// **** Jitsi sends empty RR, SDES where it announces a FMJ RTP Player again
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 81 ca 00 13 98 b2 8b 5f ......._......._
聽聽聽聽聽[java] 01 11 77 65 72 6e 65 72 40 6c 69 6e 75 78 62 6c ..werner@linuxbl
聽聽聽聽聽[java] 61 63 6b 03 1f 66 6d 6a 2d 64 65 76 65 6c 40 6c ack..fmj-devel@l
聽聽聽聽聽[java] 69 73 74 73 2e 73 6f 75 72 63 65 66 6f 72 67 65 ists.sourceforge
聽聽聽聽聽[java] 2e 6e 65 74 06 0e 46 4d 4a 20 52 54 50 20 50 6c .net..FMJ RTP Pl
聽聽聽聽聽[java] 61 79 65 72 00 00 00 00 ayer....
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f af 44 e0 05 ba a7 42 f2 ......._.D....B.
聽聽聽聽聽[java] a5 94 20 f9 a2 b9 ee ff 26 67 27 bb 61 f3 4f 4c .. .....&g'.a.OL
聽聽聽聽聽[java] 77 88 d4 df 8d bb e0 42 61 5d 3c 6f 86 c1 d0 0c w......Ba]<o....
聽聽聽聽聽[java] ef 28 5e 6f 70 a6 35 06 85 d5 34 fd 15 0a 18 eb .(^op.5...4.....
聽聽聽聽聽[java] 4b 14 6a 16 88 69 64 85 9b 8e 9e 5c 9f 88 e5 79 K.j..id....\...y
聽聽聽聽聽[java] b8 49 5c 7f 35 5e 70 1c 80 00 00 04 e7 cc bd 85 .I\.5^p.........

聽聽// **** Jitsi sends empty RR, SDES just with CNAME
聽聽聽聽聽[java] before encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f 81 ca 00 06 98 b2 8b 5f ......._......._
聽聽聽聽聽[java] 01 11 77 65 72 6e 65 72 40 6c 69 6e 75 78 62 6c ..werner@linuxbl
聽聽聽聽聽[java] 61 63 6b 00 ack.
聽聽聽聽聽[java] after encrypt
聽聽聽聽聽[java] 80 c9 00 01 98 b2 8b 5f c0 47 b2 a1 8b 68 96 72 ......._.G...h.r
聽聽聽聽聽[java] 69 ee 53 a5 f6 2b 1f d6 c2 11 9e 7a 64 da 08 7d i.S..+.....zd..}
聽聽聽聽聽[java] ac 5b f9 5e 80 00 00 05 ee 82 0b 2e .[.^........

聽聽... and so on, and so on


#2

Dear Werner,

Thank you very much for the thorough testing and reporting!

I'm on vacation and the Internet connection in the hotel is flaky so I
will not personally be able to look into the issues you've reported
prior to returning home on January 5, 2012.

Best regards,
Lyubomir


#3

Dear Werner,

路路路

2012/1/1 Werner Dittmann <Werner.Dittmann@t-online.de>:

1) the FMJ RTP implementation does not handle the RTP timestamp correctly. The
timestamp value in the first RTP packet is always 0xffff and is then decremented
by 1 for each sent RTP packet. This is not according to RFC 3550, chapter 5.1 .
During the tests I use the PCMA codec with 8000Hz sampling rate thus the timestamp
must _increase_ by 160 for every 20ms (80 for every 10ms) sample. This wrong handling
may prevent the other applications from computing correct jitter and synchronisation
of streams.

2) Jitsi now uses a very large sample time. It sends 480 samples in one RTP packet. This
computes to a sample time of 60ms. IMHO this is far too long, a sample time of 20ms
or 30ms should be used instead. The RTP timestamp value should be computed accordingly
to match the sample time.

I believe the problems 1) and 2) that you've discovered are fixed in r9292.

Best regards,
Lyubomir


#4

Hi Lyubomir,

the problems are not showstoppers :-), so
enjoy your vacation

Regards,
Werner

路路路

Am 01.01.2012 17:12, schrieb Lyubomir Marinov:

Dear Werner,

Thank you very much for the thorough testing and reporting!

I'm on vacation and the Internet connection in the hotel is flaky so I
will not personally be able to look into the issues you've reported
prior to returning home on January 5, 2012.

Best regards,
Lyubomir