Summary

  • RTP's sample receiver placed an unseen synchronization source on probation: one plausible packet was not enough, while a short consecutive run supplied weak evidence of continuity.
  • The same state machine rejected a huge sequence jump, remembered its successor and re-synchronised only if that next number arrived; this protected loss accounting but never authenticated the sender or proved successful playout.

A header could pass before a source did

Imagine a conference receiver that has never seen SSRC 0x4A17 and suddenly receives sequence number 41,900. The packet says RTP version 2. Its payload type is one the session understands. Padding and length are internally consistent. Nothing in those facts proves that this datagram belongs to the intended conference. It might be misaddressed traffic, a packet decrypted with the wrong context, a random collision or merely the beginning of a genuine source whose history is still unknown.

The original RTP standard, RFC 1889, confronted that evidentiary poverty directly. Its successor, RFC 3550, retained the design and sharpened the explanation. For a source not heard before, only weak header-validity checks are available. Version, payload type, padding, extension and length can rule out some impossible interpretations. They cannot turn a solitary packet into a history.

The receiver therefore makes time part of the test. A newly observed SSRC enters probation. The sample algorithm waits for a small run of consecutive sequence numbers before declaring the source valid. With the typical MIN_SEQUENTIAL value of two, packet 41,900 remains a candidate. Packet 41,901 supplies the first relation that cannot be found inside either packet alone.

The relation is deliberately modest. Two consecutive numbers do not identify a human, authenticate a device or establish that the payload will decode. They make one operational hypothesis more useful than it was a packet ago: this looks like a source maintaining a sequence.

Probation charged latency for fewer accidents

RTP allowed an application to discard probationary packets or hold them until validation, if the resulting delay was acceptable. That choice exposes the real cost of stronger admission. Requiring more consecutive packets reduces the chance that coincidental headers and numbers will pass, but it withholds more initial media. On a lossy path, a long required run can prevent a genuine source from becoming valid at all.

The standard did not pretend that one constant serves every application. It presented an algorithm and typical parameters inside an appendix. A receiver that has already accepted a valid RTCP packet can start with stronger context. A payload format whose timestamps follow a predictable increment can supply another check. A telephone conversation, stored stream and high-delay multicast session need not purchase the same balance between false admission and delayed sound.

This is why “probation” is a better name than “authentication.” It is a local admission policy under uncertainty. The receiver chooses what amount of temporal consistency is worth the startup cost.

The number lived in a circular space

After admission, the receiver still could not compare sequence numbers as ordinary integers. RTP carries a 16-bit sequence number. After 65,535 comes zero. A small number following a large one can therefore mean an entirely healthy wrap, not a journey backwards.

The sample state keeps the highest observed number and a count of completed 16-bit cycles. Together they form an extended sequence number for accounting. This lets an RTCP report say how many packets were expected across wraps without expanding the wire field.

But networks also reorder packets. A number slightly behind the maximum may be a late arrival or duplicate. A number moderately ahead may reveal a gap. The receiver needs an acceptable neighbourhood around its current maximum rather than a single equality test.

RFC 3550's example uses MAX_MISORDER 100 and MAX_DROPOUT 3,000. The accompanying assumptions are important: fifty packets per second, two seconds of maximum misordering and one minute of maximum dropout. These are not timeless natural constants. They explain the operational world in which the example draws its boundary.

An impossible jump received no immediate biography

Now let the running source reach sequence 12,000 and then deliver 50,000. Counting the difference as loss would produce a confident disaster report. Accepting 50,000 immediately as a restart would also invent a history from one anomaly. It could be a damaged packet, stray traffic, a discontinuity, a source restart or a very long period the receiver did not observe.

The sample algorithm takes neither shortcut. It rejects the large jump and stores the rejected number plus one as bad_seq. If the next received packet is 50,001, the pair supplies a consecutive beginning. The receiver then reinitialises sequence state as though 50,001 were the first accepted packet of a new epoch.

One suspicious number was not enough to redefine the past. Its successor made the restart hypothesis actionable.

This two-packet inference resembles initial probation, but it answers a different question. Initial probation asks whether an unseen SSRC deserves long-lived source state. Restart confirmation asks whether a known SSRC's old sequence history has ceased to describe the packets now arriving. Both use continuity because no explicit restart message can be assumed.

Resetting the counter was an admission of ignorance

When the receiver re-synchronises after a large jump, it resets packet-loss statistics. That can look like throwing evidence away. In fact, preserving the old baseline would manufacture evidence the receiver never obtained.

Several complete 16-bit cycles may have passed during an extended dropout. The source may have restarted at a random sequence number. Without an observed bridge, the receiver cannot know how many packets belonged between the old and new epochs. A continuous cumulative-loss figure would convert that unknown interval into a precise-looking count.

RTP loss accounting is already more subtle than a dashboard percentage suggests. RFC 3550 defines cumulative loss as expected packets minus packets actually received, and “received” includes late packets and duplicates. The result can be negative when duplicates outnumber missing packets. RFC 3611 later added traces for loss and duplication and advised reporters to preserve observed events rather than rush into interpretation.

The epoch boundary decides what the denominator means. A reset does not say the earlier loss did not matter. It says that one defensible sequence arithmetic cannot cross an unobserved rebirth.

RFC 3550 repaired the example, not the idea

The mechanism appeared in RFC 1889 in 1996. When RFC 3550 replaced it in 2003, the change record documented small but consequential repairs. base_seq initialization became the received sequence number rather than one less. The prose was corrected to say that the bad sequence number plus one is stored. Initialization steps were separated so an implementer would not mistake one function call for the whole setup, and words lost while RFC 1889 was processed into publication were restored.

This history matters because examples become infrastructure. A pseudocode appendix can be copied more widely than the paragraph explaining its limits. An off-by-one error in the starting point changes expected-packet arithmetic, and ambiguous prose around bad_seq changes which second packet confirms a new epoch.

The correction also reveals the design's true centre. The clever part is not the literal value 2, 100 or 3,000. It is the placement of uncertainty in explicit state: candidate, valid sequence, acceptable reorder, suspicious discontinuity and confirmed new beginning.

Continuity was not cryptographic authority

A forged sender able to emit consecutive numbers can pass a sequence-continuity test. A genuine sender can fail it under loss. A misconfigured endpoint can produce beautifully ordered nonsense. RTP's header checks and probation are filters against accidental misdelivery and implausible state, not proofs of origin.

RFC 3711 later defined SRTP to provide confidentiality, message authentication and replay protection with appropriate key management. That is a different evidence layer. Even SRTP does not prove that a person listened, that the media was intelligible or that a business conversation occurred. It protects packets within a cryptographic context.

The useful historical lesson is narrower and more durable. A field becomes evidence only through the state that interprets it. The first sequence number is a claim without a past. The second can establish continuity. A huge jump suspends the old account. The following number can establish a new epoch. At every step, the receiver owns the decision and must preserve what the decision can—and cannot—say.

Sources