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

 
Document Type RFC - Proposed Standard (August 2003; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3581 (Proposed Standard)
Telechat date
Responsible AD Allison Mankin
IESG note Checking revision - Ted's comments were addressed fine and he has changed his Discuss.  Security Considerations expanded.  Waiting for Erik to re-review.
Send notices to <dean.willis@softarmor.com>, <rohan@cisco.com>
Network Working Group                                       J. Rosenberg
Request for Comments: 3581                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                             August 2003

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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Session Initiation Protocol (SIP) operates over UDP and TCP,
   among others.  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
   behavior is not desirable in many cases, most notably, when the
   client is behind a Network Address Translator (NAT).  This extension
   defines a new parameter for the Via header field, called "rport",
   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.

Rosenberg & Schulzrinne     Standards Track                     [Page 1]
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                     [Page 2]
Show full document text