I had a closer look to your logs at http://pastebin.com/bgQiiuaU . All the following time info assumes that the time stamps generated by the app are accurate (+/- a few percent). I looked at the log and started at the time stamp at 18:58:02.613. Some findings: - the ZRTP handshake was OK and took less than 2s to complete (at 18:58:04.264) - the first SRTP warning was at 18:58:07.428, thus about 3 seconds after ZRTP switched on SRTP. Thus about 150 SRTP packets were processed without problems (assuming CSipSimple send a packet every 20ms, 50 per second, which is the standard setting, some clients send packets every 30ms). - the replay warnings then show up at random times and not in a flood/batch. This means that only a few single packets generate this warning (assuming CSipSimple reports every occurrence). - The call goes on several minutes. CSipSimple sends 3000pkts per minute (one per 20ms). During the first minute of the call (18:58:07.428 to 18:59:07.707 I count about 30 warning messages, that's about 1% of packets. Still a high number assuming normal network conditions. However, because they are duplicates this would mean no data loss, but see remark below regarding late arrival of packets. So some questions: - is the audio completely disturbed during the call? Or what's the behaviour of the audio? - are there any network elements that buffer and send or resend UPD (SRTP) data at some arbitrary time? My SRTP stack not only reports duplicate packets but also packets that arrive too late. Currently I have implemented a window size of 64. Thus if a packet is too late (the difference between its sequence number and the current sequence number is >64, thus more than one second off) the SRTP stack also reports a replay warning. Well, not really accurate in that case ;-) . - Does the normal PJSIP SDES implementation even report replay warnings or SRTP problems at all? Please keep in mind that SDES uses a different SRTP stack than I use for ZRTP, mainly because ZRTP can negotiate bigger keys and more cipher algorithms than SDES and the standard SRTP stack does not support this. Werner Am 04.06.2013 14:54, schrieb Privus 007: > Hi Werner, > > Thanks for replying. It's quite an honor after all you've done to get ZRTP > into the mainstream. > > I'm using the latest CSip nightly build, and I've also experimented with > Regie's fullOpenSSLbuild too. Both give these results. > I've uploaded a full log here <http://pastebin.com/bgQiiuaU>. I don't see > any other ZRTP messages. On the clients, usually everything works ok (ie > SAS pops up, gets verified,etc) and audio flows both ways before the crash. > > I stand corrected on attributing the issue to PJSIP. Obviously I'm no > expert on these issues, all I know is what I've reported. > And I've been using CSip's ZRTP since it first came along (a year or 2 > ago?). Although it was never easy to get it working, I have used it > successfully with your PJSIP ZRTP implementation. The crashes I mention > are fairly recent. Can't really say when they started since I haven't used > CS in quite some time. If it helps any, I think that ZRTP worked fine last > time I used it last December. > > I think I also mentioned that I tested the same setup with (SDES) "classic" > SRTP, and there were no issues then. On both ZRTP and SDES SRTP tests, I > always use TLS (v1) transport. Calls lasted well over 10 minutes without > any problems with SDES. Maybe its a bug in the SRTP stack. I really don't > know but I hope smarter people like you can figure it out. > > Let me know if there's any other tests I can do or help in any other way > with my limited knowledge. > > And thanks again for your contributions to ZRTP. Many people appreciate > your work. > > > On Tue, Jun 4, 2013 at 6:55 AM, Werner Dittmann <Werner.Dittmann at t-online.de >> wrote: > >> Am 03.06.2013 20:33, schrieb Privus 007: >>> Hello list, >>> >>> I've researched this issue quite a bit before posting it here, so I'm now >>> fairly confident this bug/issue is with PJSIP's implementation of ZRTP >> and >>> not an Android or CSipSimple issue. >>> >>> In a nutshell, as I reported in CSipSimple's issue tracker here >>> http://code.google.com/p/csipsimple/issues/detail?id=2378 , all my ZRTP >>> enabled calls crash after a few seconds with the log full of these error >>> messages: >>> >>> "zrtp_android.c !ZRTP warning message: Dropping packet because SRTP >>> replay check failed!" >> >> Actually this message occurs _after_ ZRTP has setup the SRTP crypto >> context. >> Do you see any other ZRTP message before the replay message on one of the >> clients? >> >>> >>> I don't see anyone reporting the issue here, and I believe CSip >>> basically uses PJSIP's code for its ZRTP and SRTP implementation, so I >>> think the root of the problem lies in PJSIP. >> >> Not really PJSIP. It could be in the handling of the SRTP packets. Replay >> error >> means that the SRTP crypto stack thinks the packet was already received, >> i.e. >> a duplicate sequence number. This can have several reasons: the packet was >> given >> twice to the SRTP stack or some data was overwritten or the SRTP stack has >> a bug >> >>> >>> I've experimented with different phones (Samsung S3 LTE running 4.2.2 >>> as well as Sony Xperia running stock 4.0.4) and the crashes always >>> occur with ZRTP. Plain old (SDES based) SRTP calls are fine though. >> >> Which version of CSipSimple do you use? Nightly? I need to check which >> version of the ZRTP/SRTP stack CSIpSImple uses. I did some small fixes in >> SRTP some time ago that solves a "border case problem" with replay >> handling, >> however your report does not indicate this border case. >> >>> >>> Let me know if there's anything I can do to help or if you need more >>> logs and/or info. >>> >>> Thanks, >>> >>> Privus >>> >>> >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip at lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >> >> >> -- >> ---------------------------------------------- >> Werner Dittmann Werner.Dittmann at t-online.de >> Tel +49 173 44 37 659 >> PGP key: 82EF5E8B >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -- ---------------------------------------------- Werner Dittmann Werner.Dittmann at t-online.de Tel +49 173 44 37 659 PGP key: 82EF5E8B
