Summary

  • RFC 3407 let an endpoint declare media formats it was currently able and willing to support without committing the session to any one of them.
  • The declaration, a later offer/answer selection and an observed working media path were three different receipts.

The problem began with an overloaded description. SDP's m= line told a peer what a session would use, but it also became the place where equipment advertised alternatives. Listing G.711, G.729 and fax support could therefore imply that all listed formats belonged to one simultaneous configuration. A gateway with finite DSP memory might support each alternative separately while being unable to run every combination at once.

RFC 3407 did not solve the whole negotiation problem. It added a small backwards-compatible declaration beside the actual session. A capability description said that a format belonged to the endpoint's current possibility set. It did not select that format. To use it, the parties still needed another mechanism, such as the SDP offer/answer model.

That distinction produced a strong warning: a receiver must not assume that a later attempt using a declared format will succeed. The peer might choose another configuration, a required parameter might differ, resources might have changed, or the combination might be infeasible. “Supports” opened a door to negotiation; it did not record its outcome.

The set was complete and temporal. One sequence number described the whole collection. When a new collection arrived, every older collection ceased to apply. Receivers could miss updates, so a gap in the modulo-256 sequence was not a reason to reject the new set. The sequence established a new declaration epoch, not an uninterrupted delivery log or proof against replay by itself.

Scope mattered as much as freshness. A session-level capability applied to media streams of the stated type. A media-level capability applied only to its associated m= line, even when the declared media type differed. If a session-level declaration named a type with no matching stream, its target was undefined unless the session had exactly one stream. Placement was part of meaning.

Parameters narrowed the claim. A cpar line could state the format parameter or bandwidth condition under which support existed. Minimum and maximum forms expressed a single numeric range. Ignoring those constraints could turn a true declaration into a failed attempt. A codec label alone was not the whole capability.

Capability numbers were local handles within the sequence-numbered set. Their gaps were tolerated too. They were useful for a separate mechanism to refer to an alternative, but RFC 3407 itself did not say how that reference became an agreed configuration. This deliberate incompleteness kept declaration from quietly acquiring negotiation authority.

The security paragraph was brief but consequential. Renegotiating security-sensitive capabilities without authentication could invite downgrade or denial of service. An attacker did not need to falsify media support if it could make the parties select a weaker option or repeatedly reopen negotiation.

RFC 5939 later supplied the broader model RFC 3407 lacked: capabilities, potential configurations, actual configurations and offer/answer procedures. It recommended the newer attributes for implementations, while permitting both forms when legacy interoperability mattered. It did not formally obsolete RFC 3407, and its negotiation procedure explicitly did not consume the old capability descriptions. The two syntaxes could coexist without becoming one decision process.

The historical lesson travels beyond multimedia. Inventories, feature flags and compatibility matrices often state what a system might do. They do not prove what two systems selected, what resources remained available, or what happened on the wire. RFC 3407 made that evidence gap visible inside a protocol that had blurred it.

Sources