Summary

  • RTP's sequence number orders transmitted packets, while its timestamp locates media on a format-specific sampling or presentation clock; neither field is a receipt for the packet's absolute send time.
  • Different streams acquire common time through occasional RTCP Sender Reports that pair an RTP counter with an NTP-format reference value. The mapping, not a resemblance between raw numbers, is the evidence.

Imagine a video encoder splitting one picture across several network packets. The packets must leave in an order, so their RTP sequence numbers rise one by one. Yet every piece belongs to the same sampled frame, so the packets may carry the same RTP timestamp. Nothing is inconsistent. The two fields are answering different questions.

That separation sits near the centre of the Real-time Transport Protocol written by Henning Schulzrinne, Stephen Casner, Ron Frederick and Van Jacobson. RFC 1889 published the standard in 1996; RFC 3550 revised it in 2003 without changing the packet formats on the wire. Casner is the subject here because USC's Information Sciences Institute credits him with leading RTP's development and standardisation, not because a collaborative protocol should be rewritten as a lone-inventor story.

The distinction they preserved remains easy to lose in modern telemetry. A field is named “timestamp”; an analyst assumes it names a universal instant. A sequence rises; a dashboard assumes the media did too. RTP resists both shortcuts. It offers small pieces of evidence whose limits are part of their design.

One counter follows packets, another follows media

The 16-bit sequence number increments for every RTP data packet sent. A receiver can use it to detect gaps and reconstruct packet sequence. Its initial value is random, so even this apparently simple counter is not a session-wide serial starting at one. It describes position within one source's transmitted packet sequence.

The 32-bit timestamp follows a different clock. RFC 3550 defines it as the sampling instant of the first octet carried in the packet. When packets are generated periodically, the value comes from the nominal sampling clock, not from reading the system clock as the packet crosses a socket. Its rate depends on the payload format.

For fixed-rate audio, a block containing 160 sampling periods advances the timestamp by 160. It advances by the same amount when that block is dropped as silence. The media timeline continues even when no packet carries the silent interval. Treating the RTP value as a packet dispatch time would erase precisely the continuity it was chosen to preserve.

Video exposes the other side of the rule. Several packets that make up one frame can share a timestamp because they were logically generated at one media instant. Encoded frames can also be transmitted in an order different from the order in which they were sampled. The sequence numbers still rise with transmission, while consecutive timestamps may move non-monotonically. A capture showing that pattern has not, by itself, proved network reordering or a faulty clock.

RTP also randomises the initial timestamp. A raw value such as 900000 therefore carries no standalone calendar meaning. Before an operator converts it to seconds, the payload's clock rate is needed. Before it can be compared with another stream, its source and offset must be known. Before it can be placed on a common timeline, a mapping is required.

Audio and video cannot synchronize by numerical resemblance

An audio stream and a video stream may be captured at the same physical moment and still report counters that look unrelated. Their clock rates can differ, and each normally begins from an independent random offset. Direct comparison of their RTP timestamps is therefore ineffective for synchronization, RFC 3550 says.

This is a deliberate refusal to overload the data packet. A media-specific clock is excellent for arranging one stream and calculating variation in arrival against its sampling rhythm. It is a poor universal clock. Making it absolute everywhere would tie the fast data path to a time source and representation that many applications do not need.

Instead, a sender periodically produces an RTCP Sender Report. The report places an NTP-format reference timestamp beside an RTP timestamp corresponding to the same instant. The pair defines a relationship between the local media counter and reference time. Audio and video can then be placed together by using their separate mappings to a shared clock.

Those pairs are intentionally sparse. They are not copied into every RTP data packet. The receiver interpolates from the known relationship between counter rate and reference time. The RTP value in a Sender Report will usually not equal the timestamp in an adjacent media packet; it is calculated for the report's reference instant. A tool that searches for an exact neighbouring number may reject a correct mapping.

The mapping also has a boundary that its familiar format can conceal. RFC 3550 permits a sender without absolute time to use a commonly available relative clock, such as system uptime, for the NTP-format field. A sender with neither wall-clock nor elapsed-time knowledge may set it to zero. Sixty-four bits shaped like NTP are not automatically proof of UTC accuracy.

RFC 7273 later made the model explicit in clock-signalling terms: the NTP/RTP pair in an RTCP Sender Report defines a mapping, while time-aligned playout across sources still relies on reference timestamps that themselves are synchronized. The report is a correlation receipt. It does not improve the underlying clock merely by naming it.

The timing design came from constrained media, not decorative metadata

Casner's path into this problem began with packet voice on the ARPANET. The ISI account describes work that had to compress continuous audio, divide it into packets and reconstruct it at the other end under severe bandwidth limits. He later worked on packet video, helped establish the MBONE multicast experiment and led RTP development and standardisation. The institution's memorial traces RTP back through ISI's Network Voice Protocol and Packet Video Protocol.

That history helps explain why the fields are economical. RTP does not promise bandwidth, resource reservation or quality of service. It provides identifiers, sequence, media time and delivery reports that an application can use. The network may delay, drop or reorder packets; the receiver still needs enough structure to recover a playable timeline and enough control evidence to understand its limits.

The 2003 revision illustrates the same discipline. RFC 3550 says the wire packet formats did not change from RFC 1889. Its largest change was to the scalable timer algorithm governing RTCP transmission when many participants join. The data-path vocabulary was stable; the control system around how often evidence could be reported was refined.

The result is not a magic clock embedded in every packet. It is a set of separations. Sequence counts transmission. Timestamp follows media. SSRC scopes the source. RTCP reports delivery and supplies occasional reference mappings. Applications decide how these pieces become playout.

A capture needs the clock domain it came from

An observability system that stores only the 32-bit timestamp has already discarded essential evidence. It should preserve the SSRC, payload format, timestamp clock rate, sequence number, capture time, and the nearest valid RTCP RTP/NTP pairs. It should also record whether the reference value was absolute, relative or absent if that is knowable.

With that receipt, investigators can distinguish several failures. A missing sequence number may indicate packet loss. A timestamp discontinuity may mark a source restart, payload-clock change or presentation jump. A growing difference between mapped audio and video time may indicate drift. A long gap between Sender Reports may make correlation uncertain without saying anything about the media counter itself.

Without the receipt, conversion becomes guesswork. Dividing every timestamp by 90,000 silently assumes a video clock that may not apply. Sorting by timestamp silently substitutes sampling order for transmission order. Comparing two raw streams silently assumes equal rates and offsets. Printing an NTP-shaped value as UTC silently promotes a representation into a guarantee.

Casner's protocol work offers a durable rule for evidence systems: do not make the most convenient field carry the whole story. A narrow field can remain stable across applications precisely because the mapping to broader meaning is explicit, occasional and testable.

Sources