Addressing Record-Route Issues in the Session Initiation Protocol (SIP)
Extracted elements (21)
Double Record-Routing results in less time complexity than rewriting because the proxy performs no searching or editing when processing responses; the handling of in-dialog requests and responses requires no special logic once the two headers are inserted on the initial request.
Record-Route rewriting in responses is not recommended because the callee cannot sign the rewritten route set, breaking end-to-end protection. This violates the Internet's principles of openness and end-to-end connectivity because the route set seen by the caller differs from the one seen by the callee.
Record-Route rewriting requires proxies to implement special multi-homed logic: during request forwarding, resolve the output interface and encode it in the Record-Route URI; during response processing, inspect and selectively rewrite each Record-Route. This lookup on every forwarded response introduces a CPU drag that double Record-Routing avoids entirely.
The recommendation against 'transport=tls' in Record-Route URIs exists because this usage was deprecated by RFC 3261. To signal TLS, proxies must instead use SIPS URIs or construct URIs such that RFC 3263 resolution selects TLS.
The transport parameter on Record-Route URIs SHOULD NOT be included unless the proxy knows all downstream elements support that transport. If an intermediate proxy (P2) is not Record-Routing, a downstream SIP element may be forced to use a transport it does not support to reach the upstream proxy.
Many UAs bypass RFC 3263 transport selection for initial requests by allowing users to configure transport explicitly. This creates transport-switching failures in subsequent in-dialog messages when proxies Record-Route without a transport parameter, as the UA is then forced by RFC 3263 to use a different transport for the route URI.
UAs that always keep the same transport for a given dialog behave erroneously when proxies are not Record-Routing, because the callee may receive subsequent requests over a transport different from the one specified in its Contact. Correct behavior requires DNS-driven transport selection, not static configuration.
When a proxy does double Record-Routing with transport parameters and an intermediate proxy P2 is not Record-Routing, SIP elements downstream of P2 may be required to contact the upstream proxy using a transport (e.g., SCTP) that those elements do not support. P2 applying double Record-Routing would prevent this.
When a proxy inserts a Record-Route with a numeric IP address and no transport parameter, RFC 3263 procedures resolve the URI to UDP by default (no NAPTR lookup is performed for numeric IPs). This causes subsequent in-dialog requests such as ACK to be sent over UDP even when the initial request arrived over TCP, typically causing the ACK to fail.
A proxy SHOULD apply double Record-Routing as soon as it changes the transport protocol between its incoming and outgoing sides, and SHOULD also insert a Record-Route header for any multi-homed situation (scheme changes, SIGCOMP, IPv4/IPv6 changes, transport changes) that may impact processing of proxies on the path of subsequent requests.
If a UA wants to avoid transport protocol switching between initial and subsequent requests, it SHOULD rely on DNS records for transport selection and SHOULD avoid statically configuring the outbound proxy with a numeric IP address; a logical name with no transport parameter SHOULD be used instead.
In order to avoid a spiral when double Record-Routing, a proxy MAY remove two Route headers instead of one when performing 'Route Information Preprocessing' per RFC 3261 Section 16.4 — it can scan an extra Route header ahead to determine whether the request will spiral through it.
Proxies compliant with this specification MUST NOT use a 'transport=tls' parameter on the URI placed in the Record-Route because the 'transport=tls' usage was deprecated by RFC 3261.
The ability to force the transport protocol in UAs for initial requests SHOULD be avoided; bypassing RFC 3263 for initial requests causes the UA to be forced into the RFC 3263-preferred transport for subsequent requests, leading to transport-switching failures mid-dialog.
UA implementations SHOULD be ready to change the transport protocol between the initial request and subsequent in-dialog messages, since forcing a mid-dialog transport switch typically leads to interoperability failures.
When a proxy changes the transport protocol between its incoming and outgoing sides, it SHOULD use the double Record-Route technique and SHOULD add a transport parameter to each of the Record-Route URIs it inserts.
When TLS is used on the transport on either side of the proxy, the URI placed in the Record-Route header field MUST encode a next-hop that will be reached using TLS — either via a SIPS URI or via a URI constructed such that RFC 3263 resolution selects TLS.
A multi-homed proxy is connected to two or more different networks with an interface into each such that traffic arrives on one network and exits through another. Examples include IPv4-to-IPv6 transition proxies, transport protocol switching proxies, and SIGCOMP-to-non-SIGCOMP proxies.
The double Record-Routing technique consists of inserting two Record-Route headers before any existing ones: the first URI reflects the input interface (including scheme and/or URI parameters), and the second reflects the output interface. No modification of the recorded route is required when processing responses, and it is fully backward compatible with RFC 3261.
The Record-Route header inserted by a proxy contains a SIP or SIPS URI indicating where and how subsequent in-dialog requests should be sent to reach the proxy. The URI may include IPv4 or IPv6 addresses and parameters such as 'transport=tcp' or 'comp=sigcomp' that influence downstream routing.
Double Record-Routing carries information about both proxy interfaces to each involved endpoint and any intermediaries, whereas the rewriting technique only exposes the interface closest to each endpoint. If topology hiding or privacy (per RFC 3323) is a concern, the URI values in each Record-Route must be carefully constructed to avoid leaking unintended internal network topology.