Record-Route and Route are the headers that determine whether a proxy stays in the path of a dialog after the initial INVITE. Forgetting Record-Route is one of the most common causes of mid-call failures, especially missing ACKs and BYE messages that go to the wrong destination.
Record-Route is a header inserted by a proxy in the initial INVITE (and its response) to indicate that the proxy wants to remain in the path for all subsequent in-dialog requests. By appending its own URI to Record-Route, the proxy ensures it sees future re-INVITEs, BYEs, and ACKs.
Route is the header used in subsequent in-dialog requests to direct the request through the chain of proxies that Record-Routed in the initial dialog setup. The Route header is built from the Record-Route headers in reverse order.
Together, they implement the route set: the ordered list of proxies that the dialog must traverse for every mid-dialog request. Without this mechanism, a proxy that handled the initial INVITE would be bypassed for the BYE, often causing the BYE to fail to reach the right place.
The route set is constructed during dialog setup:
For subsequent in-dialog requests, the originator sets the Route header to the route set and the Request-URI to the remote target (the Contact in the original 200 OK). Proxies along the path pop themselves from Route and forward.
RFC 3261 defines two routing modes. Loose routing is universal in modern SIP; strict routing is legacy.
The Request-URI stays as the remote target (the final destination). Route headers contain the proxy chain. Each proxy pops itself from Route and forwards to the next, treating Route as a hop-by-hop direction.
Loose routing is indicated by the ;lr parameter in the proxy URI. RFC 3261 mandates loose routing for compliance.
The Request-URI is set to the next proxy. Each proxy rewrites the Request-URI to point to the next hop, eventually pointing to the actual destination. The remote target is shifted into the Route header before being forwarded.
Strict routing is the original SIP behavior from RFC 2543. It is now legacy and exists in modern stacks only for backward compatibility. New implementations should always use loose routing.
If you see a SIP message with Route headers but no ;lr parameter, you are likely dealing with a legacy stack. Most modern issues come from inconsistencies in loose routing across vendors.
A proxy should Record-Route when it needs to see mid-dialog requests. Common reasons:
A proxy should NOT Record-Route when:
Adding Record-Route everywhere is sometimes done as a safety measure, but it has performance cost and increases the chance of routing failures if any proxy in the chain becomes unreachable later in the call.
Record-Route is a header inserted by a proxy in the initial INVITE and its response to indicate that the proxy wants to remain in the path for all subsequent in-dialog requests (re-INVITE, BYE, INFO, etc). The proxy URIs in Record-Route are used to build the route set, which determines the path that mid-dialog requests follow. Without Record-Route, a proxy is bypassed for in-dialog messages.
Record-Route is set by proxies during initial dialog setup to declare that they want to stay in the path. Route is set by endpoints in subsequent in-dialog requests, built from the Record-Route headers, to direct messages through the proxy chain. Record-Route is the source; Route is the result. The route set is the chain of proxies that the dialog must traverse for all mid-dialog requests.
Without Record-Route, mid-dialog requests like ACK and BYE bypass proxies that handled the initial INVITE. If a proxy opened a NAT pinhole on the inbound path, the ACK takes a different route and gets dropped — leading to the classic 30-second call drop. If a proxy needs to see BYE for billing or state cleanup, missing it leaves stale call state. Proxies that need mid-dialog visibility must Record-Route.
Paste your SIP trace into SIPSymposium. The analyzer correlates Record-Route declarations with mid-dialog routing, identifying missing route sets and the path failures they cause.