Summary

  • RFC 3605 added a media-level SDP attribute for an RTCP port and optional address after NAT made the old adjacent-port rule unreliable. That line documents where control packets should go; it does not prove the path was used.
  • Operations should record SDP acceptance, negotiated RTP/RTCP mode, socket state, mapping observation, packet send, packet arrival, RTCP validation and report use as separate receipts. RTP media can arrive while RTCP feedback remains absent.

Picture a conference platform after an otherwise successful change. Offer and answer were parsed. Audio counters rise. The dashboard shows the expected control address and port. Yet the receiver-report counter is zero. One team reads the SDP record and says the feedback path was configured. Another reads the media graph and says the call works. Neither observation answers the question the quality controller needs: did a valid RTCP packet return from the intended reporting source during the relevant interval?

RFC 3605 is useful because it never promised that answer. Published in October 2003 on the Standards Track, it addressed a narrower defect in the session description. RTP media and RTCP control commonly used two UDP ports. Older convention made the RTCP port the next higher odd number after the RTP port. A port-mapping NAT could destroy order and parity. A NAT with a pool could even place the two mappings on different public addresses.

The document added an explicit value attribute: a=rtcp: followed by a port and, optionally, a network type, address type and connection address. It may appear at media level and must not be used at session level. Its achievement was representational. A peer no longer had to reconstruct a translated control destination with arithmetic that the translator had invalidated.

Representation is the first boundary. A generated line proves what one component wrote. A parsed line proves what another component accepted. An offer/answer result proves a negotiation state. None proves that the receiving process bound the advertised socket, that the operating system admitted the packet, that the NAT retained its binding or that the network delivered a datagram.

RFC 3605 deliberately chose an attribute instead of enlarging the media line. The design preserved a predictable compatibility failure: software that did not understand the attribute would ignore it. Such software could still receive RTP media but would fail to send RTCP packets to the specified destination. This is not a corner case invented by an operator. It is the documented trade-off that allowed an extension to coexist with older SDP implementations.

That trade-off breaks a common dashboard shortcut. “Media received” cannot stand in for “control path working.” The RTP plane may carry audible or visible content while the RTCP plane is pointed at an inferred adjacent port, a stale mapping or no listener. A user may report that the call sounds fine during a short test, while the system has lost the reports needed to diagnose longer-term loss, jitter, source changes or synchronization.

The second boundary is between discovery and durability. RFC 3605 sketches a STUN procedure: allocate two sockets, send from each to a well-connected server, receive the external address and port observations, then place those translated coordinates in SDP. The RFC immediately states the assumption: the NAT must use the same translation toward that server and toward the eventual SDP peer. It gives no guarantee that every deployed NAT has that property.

A STUN response is therefore scoped evidence. It says a named observer saw a mapping at a time, under a transport tuple and network condition. Copying that mapping into SDP does not extend its lifetime or audience. A later packet may encounter a different destination-dependent mapping, an expired binding, a policy filter, a changed interface or a failover device with no corresponding state.

This makes timestamps and vantage points part of truth. A useful record includes the local socket tuple, the STUN server, transaction time, observed external tuple, intended media peer, SDP version and the first packet time. Without those coordinates, “mapping discovered” is a claim detached from the circumstances that made it true.

The third boundary is between transmission and reception. A sender-side counter may prove that an application handed bytes to a socket. A host capture may prove that a datagram crossed one interface. A receiving-edge capture may prove arrival at that edge. Only parsing and validation at the receiver establishes that the bytes formed an acceptable RTCP packet for a known session. Each receipt closes a different gap.

Even a valid RTCP receiver report has a bounded meaning. RFC 3550 uses RTCP for reception-quality feedback, participant identification, synchronization and control information. A report is associated with reporting sources, synchronization sources, counters and intervals. It is not a universal certificate that the media was good, the human participant was correctly identified, every direction was observed or the user achieved the intended task.

Silence is more ambiguous. Zero reports can mean the peer ignored a=rtcp, selected a different negotiated mode, sent to the wrong coordinate, lost its NAT binding, encountered a filter, had no eligible source state, had not reached its reporting interval, or failed to expose the metric. Treating all silence as packet loss produces false incidents; treating it as health creates blind operation.

Later standards add choices without erasing the chain. RFC 5761 defines RTP and RTCP multiplexing on one port. RFC 8859 classifies rtcp as a transport attribute for SDP multiplexing analysis. The current IANA SDP registry still lists the media-level attribute. A system may negotiate a shared port or separate ports, but it must preserve which mode was selected. A static default is not evidence of the negotiated result.

RFC 5389 also repositioned STUN as a tool rather than a complete NAT traversal solution. That is the right operational reading. Discovery supplies an observation that other mechanisms can use. It does not authorize an application to label the eventual path proven. Likewise, signaling integrity can protect the SDP declaration against rewriting, but an authentic declaration can still name a closed port or a mapping that no longer exists.

The security distinction is important. RFC 3605 notes that an attacker able to rewrite signaling could redirect the RTCP fraction of an exchange and discusses protecting SDP integrity. That protects who said what. Reachability asks whether packets can travel. Authorization asks whether the destination should receive control telemetry. Reception asks what arrived. Those are four separate questions.

The evidence ladder should remain visible in production. Preserve the source SDP and hash. Record the parser and offer/answer decision. Store the selected separate-port or multiplexed mode. Record socket binding and the process owner. Preserve external-mapping observations with time and observer. Record the advertised tuple and integrity result. Then capture first send, first receiving-edge arrival, first valid RTCP packet, first receiver report and the exact report interval used by analytics.

Only after those receipts should the system record an operational decision such as changing a bitrate, declaring a quality breach or closing an incident. Otherwise a decision engine can consume absence as if it were a measurement. The fact that no report entered a database is not a report saying zero loss.

This is the durable lesson in a small protocol extension. RFC 3605 repaired the syntax needed to describe a control path after translation. The implementation still had to make the path real. The monitoring system still had to observe it. The decision owner still had to say what evidence was sufficient. A green SDP row can begin that chain; it cannot finish it.