Summary

  • RFC 3158 treated translated RTP media and the RTCP evidence about that media as one consistency problem. Changing encoding, packetization, sequence numbers or timestamp frequency required corresponding changes to counts, timestamps and reception reports.
  • Reception reports travelled opposite to the media and referred to a particular sequence space. If a translator could not map loss and extended sequence information back meaningfully, an explicit omission or locally synthetic report was more honest than forwarding valid-looking numbers for the wrong stream.
  • The testing memo also limited its own authority. Its scenarios could expose common errors and demonstrate bounded interoperability; passing them did not certify complete RTP conformance, security, deployment quality or user experience.

The pictures could arrive while the evidence lied

Imagine a translator between a fast network and a narrow link. It receives two RTP packets, converts their encoding and combines them into one outgoing packet. The receiver plays the result. To an observer looking only at the media, the translation worked.

Now let the receiver send an RTCP reception report. Its highest sequence number and loss count describe the outgoing sequence space: one packet where the source sent two. If the translator simply forwards that report upstream, the original sender sees a syntactically correct account of a packet history it never emitted. A loss fraction calculated after the merge can no longer be copied unchanged into the pre-merge world.

The failure is subtle because none of its parts needs to look corrupt. The translated payload can decode. The source identifier can remain the same. The RTCP packet can parse correctly. Its sender can even authenticate it under the applicable security mechanism. Yet the report can still be semantically false for the point at which it is read.

RFC 3158 made this a testing question. Its translator section did not stop after asking whether the far endpoint could play the converted media. It asked whether changes to payload type, timestamp, sequence number, padding and marker behavior were accompanied by corresponding changes in the control reports. The report was not decorative telemetry. It was part of the protocol state that had to follow the transformation.

The test instrument stood outside both implementations

The 2001 memo proposed an application-level packet forwarder between two RTP implementations. Both endpoints sent to the test instrument; it forwarded packets to the other side. In ordinary runs it introduced no loss or extra delay. In selected runs it delayed or discarded traffic and logged packet contents.

That arrangement gave the test a useful third point of view. An endpoint could say that it sent a packet, another could say that it received one, and the instrument could preserve what crossed the controlled boundary. By deliberately dropping roughly one percent of data packets, the tester could compare known impairment with the receiver report’s loss fraction and cumulative loss. By removing loss and adding variable delay, it could look for the expected rise in reported interarrival jitter.

The instrument did not become an omniscient witness. It saw the traffic at its own location, under its own scripted conditions. It could not prove what an implementation did in every untested state, what a production network would do, or whether a human found the audio or video useful. RFC 3158 said so at the beginning: the strategy was not exhaustive, and passing it did not necessarily imply conformance to the complete RTP specification.

That disclaimer is not a ceremonial caveat. It defines the receipt. A successful run can establish that two identified builds exchanged selected media under a recorded setup and reacted as expected to chosen edge cases. It cannot silently become a certificate for every payload format, topology, timer, malformed input, security mode or deployment condition.

RTP and RTCP described one history from different angles

RTP carried the media packets. RTCP carried control information about the sources and how their packets were received. The two channels were separate on the wire, but their meanings were joined.

A sender report named an SSRC and supplied an NTP time, the corresponding RTP timestamp, a packet count and an octet count. A reception report named the source it described and carried loss, an extended highest sequence number, jitter, the last sender-report timestamp and delay since that report. These fields were meaningful only relative to the data stream and observation point that generated them.

RFC 3158 therefore tested consistency, not just presence. It checked that an SR’s SSRC matched the RTP data; that its RTP time matched the media timeline; that counts matched the packets and bytes sent; and that an RR’s sequence and loss information corresponded to controlled impairment. A report arriving on schedule was not enough. It had to describe the right history.

This distinction matters because monitoring systems often privilege the control record. It is smaller, structured and easy to aggregate. But a compact report is a projection of media events, not a replacement for them. If an intermediary changes those events without updating the projection, the cleanest dashboard may become the least faithful account.

A translator kept the source label but could change almost everything around it

RTP distinguished a translator from a mixer. A translator forwarded sources separately and preserved their SSRC values, even though all forwarded packets could acquire the translator’s network address. A mixer combined streams, generated its own timing and sent the combined output under its own SSRC, optionally listing contributing sources as CSRCs.

Preserving the SSRC did not mean preserving the packet history. A translator could change data encoding and therefore payload type. It could alter packetization interval or frame rate and therefore timestamps. It could merge several packets into one or split one into several and therefore assign a new outgoing sequence progression. It could add or remove padding, change marker behavior, or add or remove encryption.

The stable source label helped receivers group the stream across the intermediary. It did not certify that the byte count, packet count, timestamp scale or sequence positions remained invariant. Identity continuity and measurement continuity were different claims.

This is where the article’s title earns its second sentence. Once the translator changed the packets, the reports had to follow. Otherwise the original SSRC would bind two incompatible statistical worlds under one familiar number.

Every transformation created a matching accounting duty

RFC 3158 listed concrete pairs. If the translator changed the data encoding, it should update the sender report’s octet count. If it combined multiple data packets into one, it should update the packet count. If it changed the sampling frequency, it should change the RTP timestamp in the sender report.

Those are not bookkeeping niceties. Suppose a low-rate output encoding uses fewer bytes than the input. Forwarding the original octet count would make the downstream report describe a bitrate the narrow link never carried. Suppose three small input packets become one larger output packet. Keeping the original packet count would distort packet-rate calculations and make later loss interpretation ambiguous.

The reverse path was harder. A receiver reported what it saw after translation. If merging or splitting packets changed sequence numbers, the translator had to adjust packet-loss fields and the extended highest sequence number before passing the report toward the source. This required a mapping between the two packet histories, not merely an arithmetic offset.

One lost outgoing packet might correspond to several input packets. One lost fragment after a split might represent only part of an input packet. A translator could preserve gaps induced by input loss in its output numbering, but that design choice itself had to be known before the reception report could be interpreted upstream. The meaning of “one lost packet” depended on which side of the translation boundary asked the question.

The report travelled backwards through a forward transformation

Media flowed from source through translator to receiver. Reception reports flowed in the opposite direction. The translator therefore faced an inverse problem: take observations made in the output space and express them, if possible, in the input space.

That inverse was not always complete. A many-to-one packet merge discards distinctions. If the receiver loses the merged packet, it cannot tell which individual input contributions would have been lost had they remained separate. Re-encoding can also change frame boundaries and byte counts in ways that no simple formula reverses.

RFC 3550, which replaced the original RTP specification after RFC 3158, strengthened the rule. A payload-transforming translator had to make corresponding SR and RR changes and must not simply forward the packets unchanged. For reverse reports it required inverse manipulation where possible, then acknowledged that the work could be complex.

The direction of evidence is the historical insight. Forward transformation authority did not guarantee reverse explanatory power. A component able to create a valid output stream might still be unable to reconstruct a truthful end-to-end loss statement. The system needed a declared boundary, not invented precision.

No report could be more accurate than a false one

RFC 3158 allowed a translator to strip report blocks and send empty sender or receiver reports when the transformation made reception reports impossible to translate sensibly. RFC 3550 described two bounded alternatives: pass no reception report, or send a synthetic report based on the translator’s own reception.

These alternatives did not mean the same thing. No report said that the intermediary lacked a meaningful end-to-end projection for that interval. A synthetic report described what the translator itself received at its own observation point. Neither meant zero loss. Neither was a report from the final receiver about the original packet sequence.

Explicit absence protected the semantics of the remaining evidence. Filling every field would have produced numerical completeness at the cost of truth. A locally generated report could still be useful for diagnosing the upstream segment, provided its origin and scope remained visible.

The design offered no universal algorithm because transformations differed. That local discretion was not permission to forward anything convenient. It was a requirement to choose the report that made sense for the actual mapping and to refrain when the mapping could not support the claim.

Replication, translation and mixing were not one intermediary class

A translator that merely replicated unchanged packets between multicast and unicast could also forward RTCP unchanged. The evidence obligation followed the change. The presence of a middle system alone did not require fabricating a new statistical history.

A payload translator occupied the next category. It preserved source separation while changing data representation, so its reports needed corresponding transformations. It might also allocate an SSRC for reports about its own reception, but those local reports referred to the data as seen at the translator.

A mixer crossed a different boundary. It combined sources, generated new timing and used its own SSRC. Reception reports for sources in one cloud were not simply forwarded into another where those sources were no longer synchronization sources. The mixer produced its own reports within the relevant cloud.

Calling all three devices “media relays” would erase the evidence structure. An unchanged replicator, a source-preserving translator and a new-source mixer had different identities, sequence spaces and reporting authority. Testing had to know which one it faced.

Even report aggregation could alter what the numbers meant

RFC 3550 generally advised translators not to aggregate sender and receiver reports from different sources into one report packet. The reason was measurement accuracy: propagation delay calculations used the last sender report and delay-since-last-sender-report fields. Repackaging reports could change their timing relationship.

This is a second-order version of the same rule. An intermediary can leave field values untouched and still alter the evidence by changing when or how they travel. Syntax preservation is not always semantic preservation.

The safe record therefore includes more than the final numbers. It identifies the reporting source, the data source, the observation side, the report’s creation time, any intermediary hold or aggregation, and the mapping applied. Without those coordinates, a delay value can look universal while measuring only one rearranged segment.

A protected report could still describe the wrong stream

SRTP and SRTCP later supplied confidentiality, integrity protection and replay defenses for media and control traffic under defined contexts. Those protections answer whether a packet was altered or replayed outside the accepted security relationship. They do not prove that a translator selected the correct inverse mapping.

A report can be authentic to the intermediary and still be synthetic. It can be intact and still refer to the translator’s reception rather than the final receiver’s. It can pass cryptographic verification while carrying pre-translation counts into a post-translation path.

Security therefore adds another receipt rather than collapsing the chain. Preserve the protected bytes and verification result, then ask which observation the authenticated sender was entitled and able to describe. Integrity protects the statement; it does not expand the statement’s scope.

RFC 3158 limited its own test claim

The memo ranged widely: media transport, header extensions, sender and receiver reports, source descriptions, BYE behavior, RTCP timing, reconsideration, translators, mixers, collision handling and SSRC randomization. Breadth made it useful and made its opening limit essential.

Its randomization section illustrates why a test plan also needs review. It called its procedure only a rough validation, then printed 2,500 samples distributed across 25 bins while saying the expectation was 40 per bin. Direct division yields 100. The coefficient-of-variation formula printed later is consistent with the sample and bin variables, but the expected count and acceptance band appear to belong to another sample size. The RFC Editor search frozen for this research found no matching erratum.

That observation is not an official correction, and it should not be inflated into a verdict on RTP. It is evidence about evidence. A published test strategy can contain a bounded numerical inconsistency; an operator should preserve the exact procedure used, calculate its expectations independently and report deviations rather than borrowing authority from the document number.

Passing a flawed or incomplete test can be worse than failing a well-scoped one if the pass is later used as a universal badge. RFC 3158’s authors prevented that overreach in advance: their tests illustrated likely errors and selected interoperability, not the whole specification.

Later metrics enlarged the vocabulary, not the observation point

RTCP Extended Reports added richer measurements. Topology documents later described a wider variety of relays, mixers, selective forwarders and other RTP arrangements. More fields and more named topologies improved diagnosis, but they did not abolish provenance.

A metric still needed a source, interval, packet population, sequence space and observation point. A post-translation loss value could not become a pre-translation value merely because a newer report format carried it. A topology label could explain which intermediary was expected, but not prove what code ran or which path a particular packet took.

Profiles and payload formats also remained important. Payload type, timestamp rate and marker meaning depended on the applicable profile. A translator could not validate or rewrite them by treating their bits as universal. The common header carried syntax; the profile supplied part of the meaning.

The durable artifact was a joined transformation receipt

An accountable translation record begins with an input capture: SSRC, sequence number, timestamp, payload type, size and arrival time. It records the transformation rule, software and configuration identity, and the mapping from input packets or frames to output packets. It then preserves the outgoing sequence and timestamp space.

For each sender report, it records how byte count, packet count and RTP timestamp were rewritten. For each reverse reception report, it records the output-space observation, the inverse mapping attempted and the resulting upstream fields. If no meaningful mapping existed, it records omission. If the translator issued a local synthetic report, it labels the observation point and does not present it as the final receiver’s account.

The next receipts belong to other layers: whether the receiver decoded the payload, whether playout met its deadline, whether the application used it, and whether a human experienced intelligible media. A perfect RTCP rewrite cannot prove those outcomes. A good user experience cannot retroactively make a false report accurate.

RFC 3158’s enduring lesson is not that every intermediary must preserve every number. It is that a system must not preserve the appearance of evidence after destroying its meaning. When packets change, reports must change with them—or admit exactly where they can no longer follow.

Sources