Routing: Via, Record-Route, Route

10.1 Two paths: responses follow Via, requests follow Route

Every SIP element that handles a message answers one question: where does it go next? The answer comes from different headers for requests and for responses.

The first INVITE finds Bob with DNS and the location service (Modules 3 and 11). Its responses retrace that path exactly. But the requests that come later in the dialog — the ACK for the 2xx, the BYE, a re-INVITE — do not follow the INVITE. They follow the route set, which comes from Record-Route (10.4). Mixing up the two paths is the most common routing mistake.

10.2 The Via stack

Each element that sends a request puts its own Via on top of the Vias already there. Each element that forwards a response takes its own Via off the top. The Vias are a stack: the response pops them in the reverse order of the request.

One Via value holds:

• Transport and sent-by: SIP/2.0/UDP 198.51.100.10:5060 — the transport and the address where the sender wants the response.
• branch: the transaction ID, starting with z9hG4bK (Module 8). Each hop has its own transaction, so each Via has its own branch.
• received and rport: what the next hop really saw — added by the next hop, not by the sender (10.3).

A Via belongs to one transaction. A new request — the ACK for a 2xx, a BYE — starts again with one Via, and gets a new stack along its own path. Step through the call below. Watch the stack grow on the INVITE and shrink on the 200 OK, and see where each message goes.

10.3 received and rport: the response path behind NAT

The sender writes its own address into sent-by. Behind a NAT router, that is a private address, such as 192.168.1.20:5060. A response sent there never arrives. So the next hop writes what it actually saw into the Via:

received fixes the address, but not the port. A NAT router also changes the UDP source port. RFC 3581 adds rport: the sender adds it with no value, and the next hop fills in the source port.

The server then picks the response address from the top Via, in this order:

In the Via stack above, step 2 shows this. Proxy A sends the 100 Trying to 192.0.2.10:40112 — the public side of Alice’s NAT router — and not to the private address that Alice wrote. A proxy keeps the received and rport of the Vias below its own; it removes only its own Via. Module 20 covers the rest of NAT: keepalives, Contact rewriting, and SIP Outbound.

10.4 Record-Route: staying in the path

After the first INVITE, a proxy is out of the call — unless it asks to stay. Some proxies must see every request in the dialog: a billing proxy needs the BYE to stop counting, a proxy that handles NAT must relay requests to a phone behind a NAT router, and an SBC at the network edge must see everything. Such a proxy adds Record-Route to the request that creates the dialog:

The UAS copies the Record-Route values into its 2xx (and its 101–199 responses), in the same order, so both sides learn the list:

Record-Route has a cost. Every request in the dialog passes through the proxy, and a dialog-stateful proxy keeps state for every call. So a proxy record-routes only when a service needs it:

Turn Record-Route on and off for each proxy below, and choose a later request. The INVITE and its 200 OK always pass both proxies. Only the later request changes its path.

Try these:

• Both off. The BYE goes straight from Alice to Bob. Neither proxy knows that the call ended.
• Only Proxy B on. Alice’s ACK and BYE skip Proxy A — her own outbound proxy — and go straight to Proxy B.
• Both on, re-INVITE from Bob. Bob’s request visits Proxy B first, then Proxy A: his route set is in the other order.

10.5 Building the route set

Each proxy puts its Record-Route value on top, so the last proxy before Bob is first in the list. When the INVITE reaches Bob, it has:

Record-Route: <sip:proxy.biloxi.example;lr>
Record-Route: <sip:proxy.atlanta.example;lr>

Each side wants its nearest proxy first. Bob’s nearest proxy is Proxy B, already on top, so he keeps the order. Alice’s nearest proxy is Proxy A, at the bottom, so she reverses the list:

The route set is fixed once the dialog is confirmed. A re-INVITE can change the remote target, but not the route set:

To send a request in the dialog, the UA puts the remote target in the Request-URI and the route set in Route:

Each proxy on the way finds itself in the top Route value and removes it. When no Route value is left, the request goes to the Request-URI: the remote target.

10.6 Loose routing (;lr) and strict routing

RFC 3261 separates two things: where the request is going (the Request-URI) and which proxies it must visit on the way (Route). This is loose routing. The lr parameter in a URI says “this element is a loose router”:

The older RFC 2543 used strict routing: the next hop always went into the Request-URI, and the real target moved to the end of Route.

A UA still supports strict routers. If the first URI of the route set has no lr, it builds the request the old way. The same BYE, with a route set of one proxy:

An RFC 3261 proxy that receives a request with its own Record-Route URI in the Request-URI repairs it. It moves the last Route value back into the Request-URI:

So every modern proxy must put lr in its Record-Route URI. A missing lr makes every UA use strict routing for the whole dialog (see Common mistakes).

10.7 Outbound proxy and pre-loaded Route

A phone usually sends its requests to a proxy of its provider, its outbound proxy, whatever the destination. RFC 3261 recommends that the phone holds the outbound proxy as a pre-loaded Route — a route set of one URI that it uses for requests outside a dialog:

The Request-URI stays the real target, sip:bob@biloxi.example. The outbound proxy finds its own URI in Route, removes it, and routes on the Request-URI. Inside the dialog, the phone uses the route set from Record-Route, not its outbound proxy. An outbound proxy that does not record-route drops out of the call:

Many phones have an “outbound proxy” setting that instead sends every request to one address, with no pre-loaded Route. RFC 3261 allows this, but does not recommend it. Then the requests inside the dialog also go to the outbound proxy, even when it is not in the route set, and it must forward them by their Route headers.

10.8 Request-URI and To: why they can be different

The first INVITE starts with the same URI in the Request-URI and in To:

After that, they separate. To names the user that the caller wanted, and no proxy changes it. The Request-URI names where the request goes now, and each proxy can replace it:

Route on the Request-URI, never on To. A proxy or B2BUA that routes on To sends a forwarded call back to the original user, and a UAS that rejects a request because To is not its own address breaks call forwarding and support lines.

10.9 Loops, spirals, Max-Forwards, 482, 483

A request can reach the same proxy twice. Whether that is an error depends on what changed:

A spiral is normal. Bob’s phone forwards the call to Carol: it sends the INVITE back to Proxy B with the Request-URI sip:carol@biloxi.example. Proxy B sees the request a second time, but with a new target. A loop is a fault, usually two routing tables that point at each other. A proxy that checks for loops looks for its own address in the Via headers:

Loop detection is optional. The safety net that always works is Max-Forwards: the UA starts at 70, every proxy decrements it, and the element that receives 0 stops the request.

A low Max-Forwards also works like traceroute: a request with Max-Forwards 1 is stopped at the second hop. A B2BUA starts new requests with only its own Via, so Via-based loop detection cannot see through it. It should carry Max-Forwards across, one lower (RFC 7332). If it resets Max-Forwards to 70, a loop through two B2BUAs does not stop (Module 25).

10.10 Double Record-Route on multi-homed proxies

A multi-homed proxy has interfaces in two networks — for example, 10.1.0.1 on an office LAN and 198.51.100.10 on the Internet. One Record-Route URI can hold only one address, and each side can reach only one of them. RFC 3261 lets the proxy rewrite its Record-Route value in the response, so each side sees a different URI:

RFC 5658 recommends a simpler way. The proxy adds two Record-Route values, one for each interface. Nothing changes in the response, and both sides keep the same list:

Each side’s route set now has both URIs, and the reachable one comes first: Bob gets the outside address first, Alice the inside address. When a request arrives, the proxy finds itself in both top Route values and removes both:

Open-source proxies such as Kamailio and OpenSIPS add the second Record-Route value by themselves when a request leaves on a different interface or transport (the enable_double_rr setting of their rr modules).

Common mistakes

Summary

• Responses follow Via. Each element that sends a request adds a Via on top; each element that forwards the response removes its own.
• Requests follow Route, then the Request-URI. Each proxy removes its own Route value and may replace the Request-URI.
• Behind NAT, the next hop adds received and fills in rport. A UDP response goes to received:rport.
• A proxy that adds Record-Route to the request that creates the dialog stays in the path of every later request. Without it, the ACK, BYE, and re-INVITE skip the proxy.
• The callee takes the route set from Record-Route in order; the caller reverses it. Each side has its nearest proxy first.
• Every Record-Route URI needs ;lr. Without it, the UAs use strict routing, and the request works only if the proxy repairs it.
• An outbound proxy is best set as a pre-loaded Route. It stays in the dialog only if it record-routes.
• To keeps the user the caller wanted; the Request-URI is where the request goes now. Route on the Request-URI.
• A spiral is normal; a loop is a fault. Loop detection gives 482; Max-Forwards at 0 gives 483.
• A multi-homed proxy adds two Record-Route values, one for each interface, so each side can reach it.