Hi Guido, sorry for late reply! Wow, I'm amazed you found it! This was a two and half year bug, and frankly I had given up in fixing this, blaming it on system time. In fact I'm so impressed that I think I will start posting "bug and bug champion of the week" series in pjsip blog. This is even a good contender for bug of the month series if we have one! (If there is a bug of the year contest, then 2008 winner is http://trac.pjsip.org/repos/ticket/660, where INVITE is not retried when 401/407 challenge is received after a provisional response. How silly is that?) Thanks again for your perseverance, I've committed this in http://trac.pjsip.org/repos/ticket/696 cheers Benny On Mon, Dec 15, 2008 at 2:28 PM, Guido Fischer <fischer_guido at yahoo.de>wrote: > Hi, > > there seems to be a bug in "rtcp.c". The rtt-time was faulty at some point > and > a few times, when enabling the trace in rtcp.c, I got "Internal RTCP NTP > clock skew detected"-failures (time now < time of lsr). > > In my understanding the problem is in pjmedia_rtcp_get_ntp_time: > > /* Calculate seconds fractions */ > ts.u64 %= sess->ts_freq.u64; > pj_assert(ts.u64 < sess->ts_freq.u64); > ts.u64 = (ts.u64 << 32) / sess->ts_freq.u64; > > When calculating ntp->hi, this is done hooked on its base (ts.u64 - > sess->ts_base.u64). > I think this should also be done when calculating the fractions. > > /* Calculate seconds fractions */ > ts.u64 = (ts.u64 - sess->ts_base.u64) % sess->ts_freq.u64; > pj_assert(ts.u64 < sess->ts_freq.u64); > ts.u64 = (ts.u64 << 32) / sess->ts_freq.u64; > > Worked fine for me. No more clock skews and noticeable rtt-time failures. > > Cheers > Guido > > _______________________________________________ > 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/20090120/969ab626/attachment.html>