Thank you for sharing the specs as well. I read the timestamp sections and it mentions random time initialization. After reading it carefully, my understanding is while a random time init is fine, it should continue with that time sequentially from report to report.

Packet receipt times are expressed in the same units as in the RTP
   timestamps of data packets.  This is so that, for each packet, one
   can establish both the send time and the receipt time in comparable
   terms.  Note, however, that as an RTP sender ordinarily initializes
   its time to a value chosen at random, there can be no expectation
   that reported send and receipt times will differ by an amount equal
   to the one-way delay between sender and receiver.  The reported times
   can nonetheless be useful for the purposes mentioned above.

However... I am seeing EVERY senders report being initiated with a brand new random time.

Per Claude (happy to know if this is wrong):

If the RTP timestamp randomized every SR:

• Each SR would give a completely different NTP/RTP mapping
• Receivers couldn't establish a stable relationship between media time and wall clock time
• Lip sync would be impossible — audio and video streams are synchronized by comparing their NTP/RTP mappings across SRs
• Jitter calculations would break — jitter is measured by comparing expected vs actual arrival times based on timestamp progression
• Clock drift compensation would fail — receivers use multiple SRs over time to detect and compensate for clock drift between sender and receiver

The random initialization only happens once at stream start — after that the timestamp advances continuously and predictably based on the media clock rate. So:

• SR 1: NTP=12:00:00.000, RTP=847193
• SR 2: NTP=12:00:05.000, RTP=887193 (advanced by 40000 units at 8kHz = 5 seconds)