Don't mean to be annoying by insisting so much, but this issue has also been recently reproduced by others, notably by Abel from The Guardian Project, and has been accepted as a bug on the CSipSimple wiki here http://code.google.com/p/csipsimple/issues/detail?id=2378 . Unfortunately it seems like Regis doesn't have the time to spend debugging this at the moment. Hopefully Werner can help out of he has the time? Cheers On Mon, Jun 10, 2013 at 9:39 PM, Privus 007 <privus007 at gmail.com> wrote: > Werner, > > Please let me know if there are any other tests I can undertake to help > pinpoint the issue. > > Thanks > > > On Sat, Jun 8, 2013 at 12:04 PM, Privus 007 <privus007 at gmail.com> wrote: > >> I just realised my previous logcat logs are pretty sparse. >> Here's a better capture from another ZRTP call that quickly >> dropped/crashed CSip with the relevant info from right before the crash. >> Notice that PJSIP's log was cutoff in mid logging activity. The relevant >> Android log (full debug this time) is here <http://pastebin.com/0C5LpzKX>. >> Notice the "D/SIP SRV (1694): Stop sip stack" message. Something is >> definitely wrong here. >> >> Also, I had a SDES/SRTP call running with the exact same endpoints and >> network last night, with no problems whatsoever for over 15 minutes. >> This, to me, seems to strongly indicate there is some bug or integration >> issue between PJSIP/CSipSimple and Werner's ZRTP implementation. >> I'm pretty certain by now there is a real issue here. I hope others can >> test and replicate this. You need to let the ZRTP call run for some time to >> observe this behaviour, because it doesn't always crash immediately. Just >> yesterday I managed to hold a successful ZRTP call for almost 6 minutes >> before it inevitably crashed. >> >> >> 22:12:24.114 zrtp_android.c !ZRTP warning message: Dropping packet >> because SRTP replay check failed! >> 22:12:24.683 zrtp_android.c ZRTP warning message: Dropping packet >> because SRTP replay check failed! >> 22:12:25.144 zrtp_android.c !ZRTP warning message: Dropping packet >> because SRTP replay check failed! >> 22:12:27.844 zrtp_android.c !ZRTP warning message: Dropping packet >> because SRTP replay check failed! >> 22:12:28.876 ec0x738859f0 !Underflow, buf_cnt=197, will generate 1 frame >> 22:12:35.045 zrtp_android.c !ZRTP warning message: Dropping packet >> because SRTP replay check failed! >> 22 >> >> >> On Fri, Jun 7, 2013 at 9:48 PM, Privus 007 <privus007 at gmail.com> wrote: >> >>> Hi Werner, >>> >>> I've done some more testing, and the strange behaviour continues. This >>> time I tried from a Jitsi client calling to an Android 4.2.2 running on 3G >>> Indeed it seems like CSip crashes, although it may just be dropping the >>> registration and re-registering. It all happens very fast. >>> As you can see, the logging stops suddenly when the call drops/csip >>> crashes. >>> >>> I've uploaded the PJSIP logs here <http://pastebin.com/0xfVN2QN>and >>> also the corresponding logcat logs here <http://pastebin.com/WRzrF1sg>. >>> Earlier today (not in the logs I'm posting) I managed to have a 6 minute >>> conversation before the inevitable happened (and the logs do show the SRTP >>> replay error messages). But usually the conversation never even reaches 1 >>> minute. >>> >>> I hope you can make some sense of this. >>> >>> Thanks >>> >>> >>> On Fri, Jun 7, 2013 at 6:54 AM, Werner Dittmann < >>> Werner.Dittmann at t-online.de> wrote: >>> >>>> Hmmm - this looks suspicious :-) . An automatic re-registration could >>>> mean >>>> that CSipSimple automatically restarts. I know of another VoIP client >>>> that >>>> performs an auto-restart in case it crashes. Such a restart happens >>>> quite >>>> fast and is often barely noticeable. >>>> >>>> I cannot reproduce the problem here, thus can you check/see if >>>> CSipSimple >>>> just crashes and performs a automatic restart? If this is the case than >>>> we >>>> can try to get the Android logfies from the devices and analyse them. >>>> >>>> Werner >>>> >>>> Am 06.06.2013 19:43, schrieb Privus 007: >>>> > *The available log does not show the "call drop", the log suddenly >>>> stops in >>>> > the midst >>>> > of another warning message. Any info about this? What does it mean >>>> "drops >>>> > the connection?" >>>> > RTP/SRTP does not have a connection per se, it's UDP thus CS cannot >>>> "drop >>>> > it". >>>> > Does it drop the SIP connection (you use TLS and this CS must hold a >>>> TCP >>>> > connection)? A re-registration is only necessary if either the >>>> register >>>> > timer triggers or if the SIP TLS(TCP) connection is lost. >>>> > >>>> > * >>>> > Correct, I use TLS (TCP) for the SIP signalling and RTP/SRTP for the >>>> media. >>>> > What I mean by the "connection drops" is that the call suddenly ends >>>> in mid >>>> > call and I then see CSip immediately re-registering on the server. >>>> > Since I don't see any TLS errors in the logs, and only the SRTP replay >>>> > error, I think the issue lies with ZRTP. Plus, as I said, SDES SRTP >>>> calls >>>> > (also using TLS) never suddenly "drop" nor does CSip suddenly >>>> re-register, >>>> > which I think tends to rule out TLS as the problem. >>>> > Still, I'm going to make a few more calls with the fullOpenSSL build >>>> and >>>> > I'll upload the logs to pastebin.* >>>> > * >>>> > >>>> > >>>> > On Thu, Jun 6, 2013 at 4:33 PM, Werner Dittmann < >>>> Werner.Dittmann at t-online.de >>>> >> wrote: >>>> > >>>> >> Am 06.06.2013 16:46, schrieb Privus 007: >>>> >>> *So some questions: >>>> >>> - is the audio completely disturbed during the call? Or what's the >>>> >>>> <SNIP ---- SNAP> >>>> >>>> -- >>>> ---------------------------------------------- >>>> 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/20130615/25ac7dc2/attachment-0001.html>
