[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Internet Engineering Task Force                                   SIP WG
Internet Draft                                              J. Rosenberg
                                                             dynamicsoft
                                                           J. Weinberger
                                                             dynamicsoft
                                                          H. Schulzrinne
                                                             Columbia U.
draft-ietf-sip-nat-02.txt
July 1, 2002
Expires: January 2003


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

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   The Session Initiation Protocol (SIP) operates over UDP and TCP. When
   used with UDP, responses to requests are returned to the source
   address the request came from, but from the port written into the
   topmost Via header of the request. This behavior is not desirable in
   many cases, most notably, when the client is behind a NAT. This
   extension defines a new parameter for the Via header, called rport,
   that allows a client to request that the server send the response
   back to the source IP address and port where the request came from.






J. Rosenberg et. al.                                          [Page 1]


Internet Draft              Response Routing                July 1, 2002






                           Table of Contents



   1          Introduction ........................................    3
   2          Terminology .........................................    3
   3          Client Behavior .....................................    3
   4          Server Behavior .....................................    4
   5          Syntax ..............................................    4
   6          Example .............................................    5
   7          Security Considerations .............................    6
   8          IANA Considerations .................................    6
   9          Acknowledgements ....................................    6
   10         Author's Addresses ..................................    7
   11         Normative References ................................    7
   12         Informative References ..............................    7
































J. Rosenberg et. al.                                          [Page 2]


Internet Draft              Response Routing                July 1, 2002


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, but from the port written into the
   topmost Via header of the request. 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.

   Related to this, there is currently no way in SIP for a client to
   learn, from a response to its request, the source port that the
   server saw in the request. Currently, SIP does provide the client
   with the source IP address that the server saw in the request. This
   information is conveyed in the received parameter in the topmost Via
   header of the response. This information has proved useful for basic
   NAT traversal, debugging purposes, and support of multi-homed hosts.
   However, it is incomplete without the port information.

   This extension defines a new parameter for the Via header, called
   rport, that allows a client to request that the server send the
   response back to the source IP address and port where the request
   came from. The rport parameter is analagous to the received
   parameter, except rport contains a port number, not the IP address.

2 Terminology

   In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
   "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for compliant SIP implementations.

3 Client Behavior

   The client behavior specified here affects the transport processing
   defined in Section 18.1 of SIP [1].

   A client compliant to this specification (clients include UACs and
   proxies) MAY include an rport parameter in the top Via header of
   requests it generates. This parameter MUST have no value; it serves
   as a flag to indicate to the server that this extension is supported
   and requested for the transaction.

   When the client sends the request, if the request is sent using UDP,
   the client MUST be prepared to receive the response on the same
   socket the request was sent on. Specifically, it MUST be prepared to
   receive the response on the same IP address and port present in the
   source IP address and source port of the request. For backwards



J. Rosenberg et. al.                                          [Page 3]


Internet Draft              Response Routing                July 1, 2002


   compatibility, the client MUST still be prepared to receive a
   response on the port indicated in the sent-by field of the topmost
   Via, as specified in Section 18.1.1 of SIP [1].

   In the case where there is a NAT between the client and server, in
   order for the response to always be received, the NAT binding must
   remain in existence for the duration of the transaction. Most UDP NAT
   bindings appear to have a timeout of about one minute. Therefore,
   non-INVITE transactions will have no problem. For INVITE
   transactions, the client may need to retransmit its INVITE every 20
   seconds or so, even after receiving a provisional response, in order
   to keep the binding open to receive the final response.


        OPEN ISSUE: This is awful. Perhaps a further sign that the
        only real answer is TCP? Or, perhaps this belongs in
        sipping-nat-scenarios, not here.

4 Server Behavior

   The server behavior specified here affects the transport processing
   defined in Section 18.2 of SIP [1].

   When a server compliant to this specification (which can be a proxy
   or UAS) receives a request, it examines the topmost Via header. If
   this Via header contains an rport parameter with no value, it MUST
   insert the port the request was received from as the value of this
   parameter. This is analagous to the way in which a server will insert
   the receieved parameter with the source IP address the request was
   received from. In fact, 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 field. Note that this
   processing takes place independent of the transport protocol.

   When a server attempts to send a response over an unreliable unicast
   transport, such as UDP, and there is no Via maddr parameter present,
   but there is both a received parameter and an rport parameter, the
   response MUST be sent to the IP address listed in the received
   parameter, and the port in the rport parameter. This effectively adds
   a new processing step between bullets two and three in Section 18.2.2
   of SIP [1].

5 Syntax

   The syntax for the rport parameter is:


   response-port = "rport" [EQUAL 1*DIGIT]



J. Rosenberg et. al.                                          [Page 4]


Internet Draft              Response Routing                July 1, 2002


   This extends the existing definition of the Via header parameters, so
   that its BNF now looks like:



        via-params  =  via-ttl / via-maddr
                       / via-received / via-branch
                       / response-port / via-extension


6 Example

   Consider an example. A client sends an INVITE which looks like:


   INVITE sip:user@domain SIP/2.0
   Via: SIP/2.0/UDP 10.1.1.1:4540;rport



   This INVITE is sent with a source port of 4540 and source IP address
   of 10.1.1.1. The request is natted, so that the source IP appears as
   68.44.20.1 and the source port as 9988. This is received at a proxy.
   The proxy forwards the request, but not before appending a value to
   the rport parameter in the proxied request:


   INVITE sip:user@domain2 SIP/2.0
   Via: SIP/2.0/UDP proxy.domain.com
   Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988



   This request generates a response, which arrives at the proxy:


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP proxy.domain.com
   Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988



   The proxy strips its top Via, and then examines the next one. It
   contains both a received param, and an rport. The result is that the
   following response is sent to IP address 68.44.20.1, port 9988:


   SIP/2.0 200 OK



J. Rosenberg et. al.                                          [Page 5]


Internet Draft              Response Routing                July 1, 2002


   Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988



   The NAT rewrites the destination address of this packet back to IP
   10.1.1.1, port 4540, and is received by the client.

7 Security Considerations

   Since this extension merely adds source port information to the
   source address information already present in SIP, it does not appear
   to add any additional security considerations.

8 IANA Considerations

   There are no IANA Considerations associated with this specification.

9 Acknowledgements

   The authors would like to thank Rohan Mahy for his comments and
   contributions to this work.


   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



J. Rosenberg et. al.                                          [Page 6]


Internet Draft              Response Routing                July 1, 2002


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

10 Author's Addresses


   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com

   Joel Weinberger
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jweinberger@dynamicsoft.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu





11 Normative References

   [1] J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

12 Informative References


   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to



J. Rosenberg et. al.                                          [Page 7]


Internet Draft              Response Routing                July 1, 2002


   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





























J. Rosenberg et. al.                                          [Page 8]