RFC 3581 (rfc3581) - Page 2 of 13

An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

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