RFC 3581 (rfc3581) - Page 2 of 13
An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
Alternative Format: Original Text Document
RFC 3581 Symmetric Response Routing August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . 8
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 8
9.3. Brittleness Introduced by this Specification . . . . . . 9
9.4. Requirements for a Long Term Solution . . . . . . . . . 10
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
12. Intellectual Property and Copyright Statements . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The Session Initiation Protocol (SIP) [1] operates over UDP and TCP.
When used with UDP, responses to requests are returned to the source
address the request came from, and to the port written into the
topmost Via header field value of the request. This results in a
"hybrid" way of computing the destination of the response. Half of
the information (specifically, the IP address) is taken from the IP
packet headers, and the other half (specifically, the port) from the
SIP message headers. SIP operates in this manner so that a server
can listen for all messages, both requests and responses, on a single
IP address and port. This helps improve scalability. However, this
behavior is not desirable in many cases, most notably, when the
client is behind a NAT. In that case, the response will not properly
traverse the NAT, since it will not match the binding established
with the request.
Furthermore, there is currently no way for a client to examine a
response and determine the source port that the server saw in the
corresponding request. Currently, SIP provides the client with the
source IP address that the server saw in the request, but not the
port. The source IP address is conveyed in the "received" parameter
in the topmost Via header field value of the response. This
information has proved useful for basic NAT traversal, debugging
Rosenberg & Schulzrinne Standards Track