Summary

  • RFC 3327 let selected SIP proxies attach an ordered Path vector to a REGISTER transaction, so the registrar could store the route with one address-of-record and Contact binding and the home proxy could preload it into later requests.
  • Path was deliberately not a complete history: a traversed proxy could remain absent, a proxy could name another node, the registrar could transform the vector, and later policy could add routes. It was a declaration about future delivery, not authenticated proof of the past.

A location binding did not contain a delivery plan

Imagine a handset registering from inside an access network. Its public SIP identity might be stable while the Contact URI in the registration described the current endpoint. A registrar could accept that association and return success. From the database's point of view, the binding existed. From the home proxy's point of view, however, the endpoint could still sit behind an outbound edge, a firewall-adjacent proxy, a visited network or another intermediary that later requests were required to traverse.

Sending directly to the Contact could bypass policy or simply fail. The registration message had crossed the necessary intermediaries, but ordinary SIP registration did not require the registrar to retain that sequence as part of the binding. The packet had arrived; the knowledge needed for the next packet was about to disappear.

RFC 3327 addressed that asymmetry with the Path header field. A proxy handling REGISTER could add a URI that it wanted the home network to use on future requests toward the registered user agent. Multiple participating proxies produced an ordered vector. The registrar stored that vector together with the address-of-record and the particular Contact. When it accepted the registration, it reflected the Path values in the successful response. Later, when the home proxy selected that Contact, it could prepopulate the Route set with the stored vector before forwarding the request.

The unit of state mattered. Path did not belong vaguely to a subscriber or domain. It belonged with a registration binding. One address-of-record might have several Contacts, each reached through a different access route. A refreshed Contact could replace its vector; an expired binding could retire it. Storing the route separately from the Contact would risk applying yesterday's path, or another device's path, to today's destination.

This was also why the mechanism belonged in registration rather than in static DNS discovery. RFC 3263 helped a client locate SIP servers for a domain. It did not describe the transient, Contact-specific chain between a home proxy and one registered endpoint. DNS answered where service could begin. Path preserved how this binding asked to be reached after service discovery had finished.

The name was tempting, but Path was not a trace

The historical subtlety of RFC 3327 lies in what it refused to promise. A reader can easily see a sequence of URIs and call it the path taken by REGISTER. The specification allowed a different reality.

A proxy traversed by REGISTER did not have to insert itself. A topology-aware intermediary could insert a URI for another node that should handle future traffic. A registrar could transform the stored vector, for example by applying local routing rules. When a later request was sent, the home proxy could combine the stored values with an existing Route set, a configured outbound proxy or other local policy. The resulting request therefore need not retrace the registration transaction hop for hop.

Path was prescriptive more than descriptive. It declared constraints and waypoints for future traffic. A capture of the REGISTER and its response could prove which values were carried at that observation point. It could not prove that every traversed proxy appeared, that every listed proxy had been traversed, or that the eventual request visited exactly that set. A durable operational record should retain at least four distinct receipts: observed REGISTER traversal, declared Path vector, registrar transformation and storage, and later Route realization.

That distinction separates Path from nearby SIP mechanisms. Via records transaction routing so responses can return through the transaction chain. Record-Route is inserted while a dialog-forming request travels and establishes the route set for that dialog. Path is collected during registration for requests that may create future dialogs. Service-Route, defined in RFC 3608, points in the other direction: a registrar tells the user agent which route to use for future outbound requests for service. Path tells the home side how to route inward toward the registered Contact.

Confusing these surfaces produces attractive but false diagrams. Via is not a durable subscriber route. Record-Route does not solve delivery before a dialog exists. Service-Route is not the registrar's inward Contact route. Path does not reconstruct the packet's forensic history. Each field assigns routing authority at a different moment and to a different actor.

Reflection created a check, not an endorsement

The successful REGISTER response returned the stored Path values. That reflection let the user agent or an intermediary observe what the registrar had accepted. A normal user agent did not use Path to build its own route and could ignore it. Inspection was nevertheless valuable: an unexpected URI might reveal that an improper proxy had inserted itself into every future request toward the Contact.

The security consequence was direct. A malicious proxy that added itself to Path could gain a durable interception position. Its influence could outlive the one REGISTER transaction because the registrar might reuse the vector for every request sent to the binding. Reordering could change which policy domain saw traffic first; deletion could bypass a required edge; silent transformation could make an unreachable route look accepted.

RFC 3327 therefore discussed integrity and mutual authentication. Those controls answer bounded questions. They may show that protected values were not altered between authenticated peers. They do not prove that a URI represents an honest proxy, that the route is available, that the inserter was entitled to speak for another node, or that the path was later followed. Reflection is likewise an observability mechanism, not a certificate of truth.

The specification warned against a user agent inserting Path itself. Downstream proxies could interpret the URI as a proxy-supplied routing instruction and later expect the device to behave as a proxy. A field that looks syntactically valid can still assign the wrong role. Provenance—who inserted which value, at what hop, under which trust relationship—was part of the meaning.

Later extensions refined the neighborhood

RFC 3327 was published in December 2002 and was later updated by RFC 5626. SIP Outbound dealt more systematically with flows from user agents behind network boundaries and with maintaining usable routes through edge proxies. The update did not turn old Path values into packet histories. It refined how registration, flow identifiers and edge routing could cooperate.

RFC 5627 added Globally Routable User Agent URIs, addressing a different problem: a URI that identifies a user-agent instance and can be routed outside the context of one registration flow. RFC 5922 later specified domain certificates for SIP, improving the authentication vocabulary around domains. RFC 3680 defined registration event notification, allowing authorized subscribers to learn registration state changes. These mechanisms surround Path, but none erases its specific contract.

The IANA SIP Parameters registry makes the field and its option tag discoverable as protocol assignments. Registry presence establishes standardized names and syntax; it does not establish deployment, current use or security. The historical record is strongest when it stops at that boundary.

RFC 3327's larger lesson is architectural. Endpoint identity, current locator, required route and observed history are separate kinds of knowledge. A network can know the first two and still fail at delivery. It can know a future route and still know little about the past. Path succeeded because it made the missing state explicit. It remained safe to reason about only when operators resisted turning that declaration into evidence it was never designed to provide.

Sources