An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
Extracted elements (18)
A long-term solution should allow a client to explicitly request receiving incoming requests on the same connection over which the outgoing request was sent, without needing to specify its own address. The solution must also handle server clusters and must not increase network load.
A stateless proxy cannot store the address and port on which a request was received, so to implement symmetric response routing it can encode the destination address and port of a request into the Via header field value it inserts, then extract this information from the response to forward it correctly.
Although this specification is primarily aimed at enabling SIP responses to traverse NATs, it can also be used as a UNSAF (Unilateral Self-Address Fixing) protocol, allowing a client to learn its externally-visible IP address and port for use in Contact or Record-Route headers. The IAB considerations section documents the brittleness of such secondary usage.
SIP uses a hybrid method for computing response destinations: the IP address is taken from IP packet headers and the port from the Via header. This design allows a server to listen on a single IP/port for both requests and responses, improving scalability, but fails when clients are behind NATs.
If used for address fixing with a symmetric NAT, a client can only receive requests from the specific server it sent the request to, not from other servers in a cluster. Additionally, the server must send requests from the same address and port on which it received the registration, behavior not mandated by RFC 3261.
The 'rport' mechanism for symmetric response routing only applies to UDP (unreliable unicast transport); when SIP is used over TLS, this specification does not provide response routing functions and merely provides the client with source port information as seen by the server.
A client MAY include an 'rport' parameter in the top Via header field value of requests it generates. This parameter MUST have no value when sent by the client; it serves as a flag indicating the extension is supported and requested.
A UA MAY execute the binding lifetime discovery algorithm (RFC 3489 Section 10.2) to determine NAT binding lifetime. If longer than 1 minute, the client SHOULD increase retransmission intervals up to half the discovered lifetime; if shorter, it SHOULD decrease to half the discovered lifetime.
For backwards compatibility, a client using 'rport' MUST still be prepared to receive a response on the port indicated in the sent-by field of the topmost Via header field value, as specified in Section 18.1.1 of RFC 3261.
The server MUST insert a 'received' parameter containing the source IP address that the request came from, even if it is identical to the value of the 'sent-by' component, when processing a request with 'rport'.
To keep NAT bindings fresh during INVITE transactions, the client SHOULD retransmit its INVITE every 20 seconds or so, even after receiving a provisional response, because INVITE transactions can take arbitrarily long and most UDP NAT bindings have approximately one minute timeouts.
When a server receives a request with an 'rport' parameter having no value in the topmost Via header field, it MUST set the value of the parameter to the source port of the request, independent of the transport protocol.
When sending a response, if the sent-protocol is an unreliable unicast transport (e.g., UDP) with no 'maddr' parameter but both 'received' and 'rport' parameters present, the response MUST be sent to the IP address in 'received' and the port in 'rport', and MUST be sent from the same address and port that the corresponding request was received on.
When the client sends a request using UDP with the 'rport' parameter, the client MUST be prepared to receive the response on the same IP address and port it used to populate the source IP address and source port of the request.
The 'rport' parameter is a new Via header field parameter that allows a client to request that the server send the response back to the source IP address and port from which the request originated, analogous to the existing 'received' parameter but carrying a port number instead of an IP address.
An attacker acting as a man-in-the-middle could modify or remove the 'rport' parameter in a Via header, preventing clients behind NATs from receiving responses. However, this attack is not considered significant because an attacker capable of a MITM attack has many other denial-of-service options.
Responses sent by a server using this specification will include the source port from which the request was sent. If source address and port are sensitive, requests SHOULD be protected using SIP over TLS.
The 'rport' parameter syntax is: response-port = "rport" [EQUAL 1*DIGIT]. It extends the Via header field parameters BNF alongside via-ttl, via-maddr, via-received, via-branch, and via-extension.