*So some questions: - is the audio completely disturbed during the call? Or what's the behaviour of the audio?* Audio is fine (using opus codec) until the call drops. Once that happens CSip drops the connection and reregisters with the PBX. Sometimes the call drops after a few seconds, sometimes after a few minutes (usually drops right before the 2 minute mark). I'll try using a more standard codec in my next tests to see if it makes any difference. *- 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 ;-) .* Hmmm, this is a good question. There *shouldn*'t be any network elements buffering or messing with the packets. I've tested with CSip using my broadband wifi connection (the Freeswitch server is on the same ISP and the connection is quite good, with little latency and jitter) and I've tried with 3G too. Both scenarios reproduce the problem. I'm hoping someone else can replicate my scenario to try and rule out some router in the ISP messing with the packets. When I have time I'm going to try and install a Kamailio server to see if there's any change at all. Currently I'm using Freeswitch (latest stable release) with TLS transport and "bypass media <https://wiki.freeswitch.org/wiki/Proxy_Media>" option enabled. * - 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. * I'm not sure about the SRTP stack used in PJSIP's SDES implementation. Perhaps a PJSIP developer could answer this one? Thanks* * On Thu, Jun 6, 2013 at 6:41 AM, Werner Dittmann <Werner.Dittmann at t-online.de > wrote: > 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 > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20130606/a3ab6090/attachment-0001.html>
