*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 > > 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. > > 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. > > Werner > > > > > *- 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* > > * > > > > <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/20130606/c6dfd848/attachment-0001.html>
