Summary

  • RFC 3327 let proxies add an ordered Path during REGISTER; after a successful registration, the registrar associated that vector with the AOR/contact binding and returned it.
  • A home proxy could later copy the stored vector into a Route header for requests toward that contact. The vector was a future-routing instruction, not proof of the path a REGISTER packet had taken.

The contact was known. The route back was not.

A SIP registrar can store the address at which a user agent (UA) is reachable. That binding answers a narrow question: which Contact should receive a request for this address-of-record? It does not necessarily answer another: which intermediate proxies must the request cross to reach that Contact?

The gap appears when registration travels through edge proxies that a home proxy cannot reconstruct from DNS or its own routing tables. A UA may register through a visited network, a registrar may sit elsewhere, and a later incoming request may have to return through proxy nodes that were not obvious from the contact URI. RFC 3327, published in December 2002, gave those nodes a way to leave a route vector in the registration exchange.

The word “Path” can make the header sound like a measurement. Its job was different. A proxy traversed by REGISTER could add a Path value. The registrar preserved the ordered values with the contact and AOR binding, then reflected them in a successful REGISTER response. Later, a home proxy retrieving that binding could place the saved vector in a preloaded Route header and send the new request through those proxies. The memory belonged to the binding, not to the REGISTER transaction as a packet capture.

A route that survives the transaction

Path resembles Record-Route, but their lifetimes differ. Record-Route establishes routing for requests inside the dialog that created it. Path is carried in REGISTER and its successful response so a proxy sequence can be used for later dialogs. RFC 3261's existing routing machinery supplies the Route behavior; RFC 3327 carries the sequence across the registration boundary.

This was scoped rather than universal. The mechanism applied to requests transiting or originating in the user's home domain. Values followed Route-element syntax and used the loose-routing ;lr parameter. The UA could advertise support with Supported: path; proxies generally should not add Path unless the UA indicated that support. If a registrar received Path without that indication, the RFC recommended rejection but left room for local policy.

The important historical shift was not that SIP learned where every packet had gone. Registration became a place where proxies could attach routing context to the binding that would govern later inbound requests. The registrar's response also returned that Path to the UA, making added proxies visible for inspection rather than silently converting them into a universal topology database.

The vector is not a witness

RFC 3327 explicitly allowed a topology-aware proxy to add a Path value that referenced another node, even if the value did not match the route REGISTER had actually taken. That option is decisive: Path is an ordered route prescription assembled under proxy and registrar policy, not forensic evidence of packet traversal. It cannot, by itself, establish that a proxy forwarded a prior message, that the proposed route is reachable, or that a future call will be delivered.

The same choice created a security boundary. A proxy inserted into the saved vector could be placed on future requests and potentially intercept calls. RFC 3327 therefore discussed transport integrity and mutual authentication, such as TLS or IPsec, and described protected S/MIME copies that could let a UA detect changes to the returned Path. A syntactically valid URI was never the same thing as an authorized intermediary.

Later work reused the mechanism for a narrower purpose. RFC 5626 places a unique flow token in Path so an edge proxy can map a future request to a particular client-initiated connection. That per-flow behavior belongs to the later extension; it should not be projected onto every RFC 3327 route vector. RFC 3608's Service-Route points in the opposite direction, giving a UA a route for its own outbound requests rather than a path for incoming requests to the UA.

Sources