Summary

  • RFC 2543 used a Via branch mainly to distinguish copies made by a forking proxy. RFC 3261 made the branch mandatory and unique across space and time so it could identify a transaction.
  • The prefix z9hG4bK is a compatibility marker, not a secret. It lets a receiver apply the compact RFC 3261 matching rule and retain a multi-field fallback for older traffic.
  • Retransmissions keep a branch, new forwarding attempts get new ones, and CANCEL plus non-2xx ACK deliberately reuse one. The exceptions define transaction boundaries rather than weakening them.

Before the cookie, a branch only separated a fork

A SIP request can cross several proxies before reaching a user agent. Each stateful hop receives one request, chooses one or more next targets, and creates a local client transaction for every attempt. Responses travel back through the Via values stacked along the route.

The first SIP standard, RFC 2543, already had a branch parameter. Its promise was narrow. Every forking proxy inserted one so that responses from parallel copies could be assigned to the right virtual client. A non-forking proxy could insert one but did not have to. The token needed to be unique only among the isomorphic requests in that fork.

That branch was one clue among several. RFC 2543 mapped responses using To, From, Call-ID, CSeq and the first Via branch. Request handling also reasoned about call legs and sequence numbers. The protocol could work, but a server could not see an arbitrary branch and conclude that it was a transaction identifier with one uniform uniqueness rule.

This distinction matters whenever old and new implementations share a network. Changing the meaning of an existing field without marking the change makes the receiver guess. The sender knows which rule it followed; the receiver bears the cost of being wrong.

Seven characters selected a new matching law

RFC 3261 changed the contract in 2002. A user-agent client had to place a Via at the top of every request, and that Via had to contain a branch. With defined exceptions, the value had to be unique across space and time for all requests sent by that user agent.

The new branch also had to begin with z9hG4bK. The string carries no encoded date, vendor, route or identity. The specification chose seven unlikely characters so an RFC 2543 implementation would not produce them accidentally. On receipt, the prefix says that the remaining token was constructed under the RFC 3261 uniqueness rule.

That is why “magic cookie” can mislead a modern reader. It is not a browser cookie, credential or random challenge. It is a version witness embedded in the value whose interpretation changed. Rather than asking a registry whether a peer was modern, the receiver could inspect the request and choose its matching law locally.

A transaction became locally matchable

For a cookie-bearing request, a server transaction matches three facts: the branch in the top Via, that Via's sent-by value, and the method. ACK has a specific exception because a non-success ACK belongs to the INVITE transaction. Sent-by remains necessary because two clients can duplicate a branch accidentally or maliciously.

If the branch is missing or lacks the cookie, the server does not pretend the new promise exists. It falls back to the RFC 2543 compatibility procedure, comparing Request-URI, tags, Call-ID, CSeq and the top Via as applicable. The protocol therefore preserved two compatibility sets without confusing them.

Responses use the top Via branch plus the CSeq method. Method is essential because CANCEL constitutes a different transaction while sharing the branch it targets. A matching token narrows the search; it does not erase the meaning of the surrounding fields.

The examples in RFC 3665 make the layering visible. Each proxy adds its own Via and branch on the outbound path. The corresponding value is removed as the response returns. The identifier is local to one adjacent client-server transaction, not a global name for the call.

The same attempt must reproduce the same branch

A stateful proxy gives every outgoing attempt a new branch. If one target fails and the proxy tries another address, the attempt is a new client transaction and needs a different token. If a request returns to the proxy after its processing inputs have changed, it can be a legitimate spiral rather than a loop; an implementation that performs loop detection can include those inputs in a separable component of the branch.

A retransmission is the opposite case. It is another copy of the same attempt and must carry the same branch so the server finds existing state and resends the stored response instead of executing the request again.

This creates a subtle constraint for stateless proxies. They do not keep a table saying which packet is a retransmission. Generating new randomness on every receipt would split one transaction into many. RFC 3261 therefore requires the stable part of a stateless branch to be derived from request fields and configuration that do not change across retransmission. Uniqueness and reproducibility have to be satisfied together.

CANCEL reused identity without sharing completion

CANCEL needs to find the exact pending request along the same hop-by-hop route. It copies the Request-URI, Call-ID, tags, CSeq number, top Via and branch of that request, while changing the CSeq method to CANCEL. A stateless proxy can consequently make the same forwarding choice.

Yet CANCEL is a transaction in its own right. A server may answer it with 200 while the original INVITE separately ends with 487, another final response, or a response that had already won the race. Success of the cancellation request proves that CANCEL matched and was accepted for processing; it does not retroactively rewrite the outcome of the original transaction.

RFC 3261 explicitly separated the two after RFC 2543 had intermingled them. Reusing the branch is therefore correlation, not shared fate.

ACK split at the final-response class

An ACK for a non-2xx final response stays inside the INVITE transaction. It repeats the INVITE's top Via and branch, changes the method to ACK and is absorbed by the transaction state machine. The proxy chain that handled the failure also handles its acknowledgment.

A 2xx response is different. A fork can produce more than one accepted dialog, and every success must reach the caller. The user-agent core, not each proxy transaction, acknowledges those responses end to end. The 2xx ACK sits outside the original INVITE transaction and follows the dialog route with a newly constructed Via branch.

The split is not ceremonial. Reusing the negative-response branch lets an existing hop suppress retransmission of one failure. Creating a new exchange for success prevents an intermediate transaction from hiding another accepted destination.

Later repairs changed lifetime, not identity

Transaction identity did not solve every state-machine defect. RFC 4320 corrected non-INVITE response and timeout behavior. RFC 6026 later added an Accepted state and Timer L so a server retained enough INVITE transaction state to absorb retransmissions after sending a 2xx.

RFC 6026 also retained special handling for a legacy ACK whose branch lacks the RFC 3261 cookie. The detail confirms the marker's continuing role: state lifetime can be repaired, but the receiver still needs to know which identity assumptions the sender actually supplied. RFC 5359 documents later service flows using the branch convention; it is evidence of the specified operating grammar, not a census of implementations.

What the marker never proved

Anyone can type z9hG4bK. The prefix does not authenticate a user, authorize a call, protect message integrity or prove that the rest of the branch is unique. TLS can protect a hop, digest authentication can establish a credential claim, and application policy can decide whether to accept a request; none of those duties belongs to the cookie.

Nor is a transaction a dialog. Call-ID and tags identify dialog relationships. Route sets guide later requests. Media negotiation and RTP have their own state. A correct branch match proves only that one received message belongs to the local transaction state selected by the matching rules.

The historical achievement is narrower and more durable. SIP changed a field's contract without making every receiver infer the change from institutional status or surrounding behavior. Seven visible characters selected an executable rule, and the rule stopped at the boundary it could actually verify.

Sources and evidence limits

The closed evidence set consists of RFC 2543, RFC 3261, RFC 3665, RFC 4320, RFC 5359 and RFC 6026. They establish protocol history, matching rules, examples and later corrections. They do not establish present deployment share, product conformance, call quality or the absence of branch collisions.