Opened 10 years ago
Closed 10 years ago
#696 closed defect (fixed)
Wrong timestamp calculation causing RTCP clock skew (thanks Guido Fischer for the fix!)
Reported by: | bennylp | Owned by: | nanang |
---|---|---|---|
Priority: | normal | Milestone: | release-1.1 |
Component: | pjmedia | Version: | trunk |
Keywords: | Cc: | ||
Backport to 1.x milestone: | Backported: |
Description
Quoting Guido's post on the list:
"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."
Kudos Guido Fischer for fixing this two and half year old bug!
Change History (2)
comment:1 Changed 10 years ago by bennylp
comment:2 Changed 10 years ago by bennylp
- Resolution set to fixed
- Status changed from new to closed
Fixed in r2422
The corresponding ticket for 1.0.x branch is ticket #697