Summary

  • RFC 3608 allows a registrar to return an ordered Service-Route in a successful REGISTER response. A user agent may store it and may later place it in a Route field for an originating request.
  • The returned vector proves what the registrar proposed at that registration instant. It does not prove what a later user agent sent, how each URI resolved, which proxies were traversed, whether a service executed, or whether a session succeeded.

Published on the Standards Track in October 2003, RFC 3608 defines a SIP extension and its lifecycle; it is not an observation of any operator's present network.

A map can be genuine and still say nothing about the trip. RFC 3608 created such a map for SIP. After a user agent registers, the registrar may return one or more Service-Route values. The user agent may remember them for its address-of-record and use them as a preloaded Route set in a later initial request. The mechanism solves discovery: it gives the device a route through home-domain service proxies without assuming that the device was configured with them in advance.

The evidence error begins when that discovery receipt is promoted into history. A database row showing Service-Route: P2, HSP can establish that those values were returned, in that order, for a particular registration response. It cannot establish that an INVITE was later created. If an INVITE was created, it cannot establish that the stored vector was selected. If the vector was selected, it cannot establish which concrete network endpoints the URIs resolved to or that every listed proxy received the transaction.

RFC 3608 itself preserves these boundaries. The user agent may store the value; it may exercise the route. A later refresh updates the remembered value from the latest successful response. A response without Service-Route clears the old one. A refused registration or an expired registration that is not renewed should cause the route to be discarded. These are version rules, not ceremonial details. A route without its registration instance, refresh lineage and expiry state is an orphaned instruction.

The standard also says that local routing matters. A device may need a locally configured loose route to leave an access network, or it may use an outbound-proxy rule. The learned service route is combined with that local policy in an implementation-dependent way. The vector returned by the home registrar therefore need not be the complete request path even when the user agent follows it correctly. The registrar generally knows its own administrative domain, not the visited network in front of the roaming device.

That makes RFC 3608 different from RFC 3327. Path can be accumulated by proxies as a REGISTER travels toward a registrar, so that later requests from the home side can find the registered contact. Service-Route moves in the opposite operational direction: the registrar tells the user agent which home-side proxies it may use for requests originating at that user agent. Combining the two into one generic “SIP path” destroys the direction, owner and purpose of each record.

Route and Via also answer different questions. A Route field is an instruction carried by a request; it describes routing work still to be processed. Via values are added as SIP elements forward a transaction and identify where responses are to travel. An expected proxy name in Route is not an observation. A Via chain is closer to observed forwarding, but even it is not proof that a policy module, logging function, charging rule or other service actually executed inside each element.

Names introduce another gap. RFC 3263 can turn a SIP domain into candidate transports and endpoints through DNS procedures. TTLs expire. priorities and weights can select alternatives. A transport can fail and another destination can be tried. Local policy can override a choice. The same Service-Route URI can therefore lead to a different machine, address, port or transport at a later time. Preserving only the URI string hides the resolution decision that made the request operational.

Transport state changes the story again. RFC 5626 defines outbound flows and flow tokens for maintaining reachability through intermediaries. RFC 5923 describes connection reuse. Those mechanisms may constrain or reuse a transport relationship, but they do not turn the old REGISTER response into a transcript of a later transaction. A live connection is evidence of a connection. It is not automatically evidence that a particular request crossed it, received the intended service and reached its final target.

Security protection has a similarly bounded role. RFC 3608 warns that an intermediate proxy could alter or insert Service-Route values and recommends integrity and authentication protections. A protected registration response can support a strong claim about who supplied the vector and whether it arrived intact. It cannot authenticate an event that has not happened yet. Integrity of configuration is not continuity of execution.

An auditable system therefore needs separate receipts. The configuration receipt should preserve the exact successful REGISTER response, address-of-record, contact, Call-ID, CSeq, ordered vector, registrar identity, integrity result, time and expiry. The intent receipt should preserve the later request after local route composition, not merely the value in a preferences store. The resolution receipt should preserve DNS answers, TTLs, selected endpoint, transport and fallback attempts.

Traversal needs observations at the relevant hops, joined by transaction identifiers and time. Service execution needs its own record from the policy or application function expected at the proxy. Outcome needs the response code and, where relevant, dialog, media or application evidence. RFC 7989 Session-ID may help correlation across elements, but correlation cannot fill an absent hop log or prove an unobserved service action.

This architecture keeps failures intelligible. If the registrar returned the wrong vector, the configuration layer is responsible. If the user agent retained an expired vector, the state-lifecycle layer is responsible. If DNS selected an unavailable target, the resolution layer is responsible. If a proxy forwarded the request without applying a required service, traversal may look correct while service execution failed. If signalling succeeded but media did not, a call-outcome claim still fails.

The point is not to demand perfect packet capture forever. It is to stop one convenient artifact from speaking for six different events. Retention can be bounded, identifiers can be pseudonymous, and records can be sampled according to risk. What cannot be done honestly is to retain only the registrar's map and later report that the road was travelled.

RFC 3608 is a narrow and competent protocol extension. It defines the minimum shared syntax and lifecycle needed to communicate a service-route proposal. Later use remains with the user agent, local routing, DNS, transports and proxies running code. That division is a virtue. Operators weaken it when they let a control-plane memory become an authority over operational reality.

The durable statement is exact: at a stated time, a registrar returned an ordered route vector for an address-of-record, and the user agent was permitted to store and later use it. Anything about the later journey requires later evidence.