Summary

  • SDP has two different notions of version. v=0 identifies the protocol format; sess-version in o= must rise when one identified session description changes.
  • The version is scoped by the origin tuple. Comparing the decimal alone across changed origins, or treating a timestamp-shaped value as authenticated time, destroys the evidence needed to establish continuity.

The largest number was not necessarily the newest state

Imagine a voice platform failing over between two controllers. Both emit syntactically valid SDP. The first uses an origin tuple for controller-a.example; the second names controller-b.example. Their version numbers came from separate creator histories. If an inventory strips the other five origin fields and keeps only 402, it has converted two local sequences into a fictional global clock.

This is a quiet failure because every individual field can look reasonable. The SDP parses. The number is decimal. The later packet may even have arrived later. Yet “arrived later,” “has a larger creator-assigned version” and “is the authorized successor to the previous description” are three different claims. The origin line can help join them; it cannot collapse them.

v=0 and sess-version answer different questions

RFC 8866 begins every SDP description with v=0. That line identifies the version of SDP itself, and the RFC says there is no minor version number. A reader should not increment it when a call adds video, changes a codec or moves a media address.

The next required line begins with o= and contains six values: username, session ID, session version, network type, address type and unicast address. Here, sess-version describes a revision of session data. RFC 8866 requires the creating tool to increase it when the description changes and recommends a timestamp allocation. The same digits therefore sit beside a much larger identity statement.

Confusing the fields creates two opposite mistakes. Incrementing v= for an ordinary session update invents a new protocol format. Holding sess-version still while changing the offer makes changed content masquerade as the same revision. A useful parser records both, but gives each the scope the standard assigns.

Five fields make the name; the sixth orders its revisions

The current standard says that username, session ID, network type, address type and unicast address together form a globally unique identifier for the session. No one component carries the whole identity. A session ID reused by another host is not the same lineage merely because its digits match. A familiar username does not authenticate a person. An address change is not automatically a transparent continuation.

RFC 2327 made the original operational purpose unusually clear. Handley and Van Jacobson wrote that the version was needed so proxy announcements could detect which of several announcements for the same session was most recent. “For the same session” is the boundary. The current RFC preserves the tuple and the requirement that the version increase when that description changes.

This is why a database key such as session_id + max(version) is incomplete. The comparison key must preserve the whole RFC identity, or a locally defined canonical identity with an auditable mapping to it. If failover deliberately changes the origin tuple, continuity needs a separate migration record. A larger integer cannot authorize that handover.

Offer/answer makes unchanged mean unchanged

RFC 3264 applies a stricter rule when SDP is used in offer/answer. A modifying offer keeps the o= line identical to the previous SDP except that its origin version increases by one. If the version does not increase, the SDP must be identical to the description carrying that version. Receiving the same version again is effectively a no-op, although the answerer still returns a valid answer.

That rule gives operators a sharp consistency test. Same origin identity plus same version plus different bytes is not a harmless retransmission in this context. It is conflicting evidence. The safe response is to retain both payload hashes, mark the lineage inconsistent and apply the local protocol/error policy—not silently crown the last arrival.

The inverse also matters. A changed version proves that the creator declared a modification. It does not prove that the receiver accepted it, that media began to flow, or that users experienced a successful call. Offer creation, answer decision, media receipt and application outcome remain separate events.

A timestamp shape is not a trusted clock

RFC 8866 recommends timestamps for allocating both the session ID and session version. That is a practical way for a creator to obtain distinctive, increasing decimal values. It is not a time-attestation system. The value is supplied by the creator; the origin field does not establish clock synchronization, receipt time or organizational authority.

Security is explicit elsewhere in the same RFC. A session description cannot be trusted unless it was obtained through an authenticated and integrity-protected transport from a known and trusted source. Therefore, a revision receipt needs the transport principal and integrity result beside the origin tuple. Syntax alone can say who the document claims as origin; it cannot prove who sent or authorized it.

Separate layers keep separate change signals

Session Announcement Protocol offers a useful comparison. RFC 2974 has its own originating-source and message-identifier-hash fields. A changed SAP hash tells a receiver to parse changed announcement content. The SDP payload still carries its own origin identity and session version. One layer’s hash is not the other layer’s lineage.

That separation is characteristic of SDP’s design. RFC 8866 calls SDP a description format, not a transport protocol, and says it is not itself intended to negotiate content or encodings. SIP offer/answer can use SDP in a limited negotiation framework; SAP can distribute it; HTTP or email can carry it. Transport receipt, description identity, negotiation state and media result must remain joinable without becoming synonyms.

Mark Handley’s place in the lineage

RFC 2327, published in 1998, names Mark Handley and Van Jacobson. RFC 4566 later names Handley, Jacobson and Colin Perkins. The current RFC 8866 names Ali Begen, Paul Kyzivat, Perkins and Handley. SDP is durable collective work, not a solitary invention, and the article’s attribution should preserve that lineage just as an implementation preserves an origin tuple.

The Royal Society describes Handley as Professor of Networked Systems at UCL, an author of many Internet standards and a former Internet Architecture Board member. ACM SIGCOMM’s 2019 award citation recognizes his contributions across Internet multimedia, multicast, congestion control, multipath networks and protocol standardization. The small revision field belongs inside that wider career of making network state communicable across independently built systems.

What a session version can prove

With the complete identity, the exact SDP bytes and a trusted acquisition record, sess-version can support a bounded claim: this creator marked one description as a later revision of the same session. Under RFC 3264, it can also expose a same-version/different-content conflict or a modifying offer whose version failed to advance.

It cannot prove that a different origin is the successor, that the creator’s clock is correct, that the sender had authority, that the offer was accepted, that packets followed the described path, or that a user received intelligible media. Those claims require migration authorization, transport authentication, offer/answer records, packet observations and outcome tests of their own.

Sources