Summary

  • SDP's o= line combines a session identity tuple with a separate sess-version; a new description can belong to the same session without being the same revision.
  • General SDP requires the version to increase when the description changes. Offer/Answer is stricter: a changed offer keeps the origin line fixed except for a version increment of one, while a repeated version must carry identical SDP.
  • A larger number supports stale-description detection. It does not authenticate the sender, accept the proposal, authorize media, establish a path or prove that anyone acted on the revision.

One description needed two kinds of continuity

The early Internet's multimedia tools had a recurring problem. A session could outlive any one description of it. A multicast announcement might change its schedule. A unicast call might add video, put audio on hold or move a receiving address. Recipients needed to distinguish a revised description from an unrelated session, and a current revision from a stale copy.

One number could not safely do both jobs. If every edit created a new identity, caches and participants would lose the lineage that said the session continued. If identity never changed and there were no revision coordinate, an old announcement could return and look current.

SDP placed both coordinates in its origin line:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

The design is compact, but the fields do not all make the same claim. The identity coordinate is the tuple of username, session ID, network type, address type and origin address. The version coordinate orders descriptions inside that lineage. A receiver must first establish which lineage it is considering and only then ask whether one description is later than another.

The username was not an authentication credential

The word “origin” invites over-reading. In SDP, the username may be a login name, but it may also be a dash when the host has no useful user-ID concept. The current specification even permits an arbitrary username and a private origin address for privacy, provided the complete tuple remains globally unique.

That makes the boundary plain. The tuple is a namespace for descriptions, not a proof of a human, organization or device. The origin address need not be the media destination, and the username is not a credential. Two descriptions with the same numeric session ID but different origin coordinates do not automatically belong to one session.

The allocation of sess-id is local to the creating tool. The specifications recommend a timestamp measured from the NTP epoch as a practical way to obtain uniqueness. Recommendation is not attestation. A timestamp-shaped identifier does not prove that a clock was synchronized, that the description was created at that instant or that the sender owns the address it wrote.

Revision existed without a central revision service

The adjacent sess-version records change. SDP requires the creating tool to increase it whenever the session description is modified. A proxy or recipient can therefore compare descriptions that share one origin identity and avoid replacing a later description with an earlier one.

This was a decentralized answer. No registry had to allocate every revision. No server had to certify a universal “latest” value. Each receiver could retain the origin tuple, version and exact description it had accepted, then compare later evidence locally.

The freedom is narrower than it first appears. General SDP says the version must increase; it does not require every application to add exactly one. It recommends a timestamp but does not turn the field into civil time. Nor does it define meaningful order between versions carried by different origin tuples.

Revision is therefore relative evidence. The statement “version 40 is later than version 39” is useful only after both values have been shown to describe the same lineage under the relevant application rules.

Offer/Answer made the revision contract stricter

SDP began as a description format, with a strong multicast inheritance. The Offer/Answer model later supplied operational rules for two agents trying to establish or modify a shared view. It also exposed a crucial dependency: a higher-layer protocol such as SIP carries the descriptions, keeps exchange context, orders messages and resolves simultaneous offers.

When an agent modifies a session under Offer/Answer, its new origin line must remain identical to its previous origin line except for the version. That version must increment by one. The stable coordinates say “same offered lineage”; the single step says “next revision from this agent.”

Offer/Answer also closes the opposite loophole. If an offer repeats the previous origin version, its SDP must be identical to the description associated with that version. A sender may repeat an unchanged description, and the receiver must still generate a valid answer, but the old version cannot lawfully carry new bytes.

This creates a useful audit invariant. A repeated (origin tuple, version) with a different body is not an innocent alternative representation of one revision. It is conflicting evidence. A receiver cannot repair the conflict by choosing whichever copy arrived last.

The model avoids rollover by requiring its numeric session ID and version to fit a signed 64-bit integer and the initial version to remain below 2^62 - 1. That is an application-specific operating bound, not circular arithmetic and not permission to compare unrelated sessions.

A new revision was still only an offer

A revision number identifies proposed description state. It does not decide whether the other agent accepts that state. Offer/Answer separates those acts. The answerer can accept compatible streams, reject others or reject the offer through the enclosing signaling protocol. If an offer is rejected, the session returns to its prior description state.

The exchange also limits concurrency. An agent must not issue a new offer while its previous offer is unanswered, or while it owes an answer to the peer. If both sides offer at once, the result is glare; the higher-layer protocol must resolve it. The version field alone is not a distributed lock and “largest number wins” is not the algorithm.

Even a valid answer remains bounded evidence. It records agreement about a description. It does not prove that packets reached the advertised address, that a codec worked, that a firewall admitted traffic, that a user consented, that recording was lawful or that a commercial service completed.

Freshness did not supply trust

A malicious sender can choose a very large number as easily as a legitimate sender. For that reason, the Offer/Answer specification depends on its carrier for end-to-end authentication and integrity protection. The receiving application must also apply local admission and consent policy.

The separation is essential. Authentication answers who supplied the description. Integrity shows whether it changed in transit. The origin tuple says which description lineage is claimed. The version says which revision is claimed. Offer/Answer state says whether a proposal is outstanding, accepted or rejected. Media observation says whether the negotiated path actually worked.

Collapsing these records gives the revision number authority it was never designed to hold. The correct lesson from SDP is more modest and more durable: continuity becomes governable when identity and change receive separate coordinates, and when neither coordinate is mistaken for permission.

Sources and evidence limits

The historical and normative record is RFC 2327, RFC 4566, RFC 8866 and RFC 3264. These documents establish the description grammar and Offer/Answer rules. They do not measure current implementation conformance, identify a live sender, validate a business change or prove successful media delivery.