Internet Engineering Task Force SIP WG
Internet Draft J. Rosenberg
dynamicsoft
J. Weinberger
dynamicsoft
H. Schulzrinne
Columbia U.
draft-ietf-sip-symmetric-response-00.txt
September 27, 2002
Expires: March 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, 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 where the request came from.
J. Rosenberg et. al. [Page 1]
Internet Draft Response Routing September 27, 2002
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 3
3 Client Behavior ..................................... 3
4 Server Behavior ..................................... 4
5 Syntax .............................................. 5
6 Example ............................................. 5
7 Security Considerations ............................. 6
8 IANA Considerations ................................. 7
9 IAB Considerations .................................. 7
9.1 Problem Definition .................................. 8
9.2 Exit Strategy ....................................... 8
9.3 Brittleness Introduced by this Specification ........ 8
9.4 Requirements for a Long Term Solution ............... 9
9.5 Issues with Existing NAPT Boxes ..................... 10
10 Acknowledgements .................................... 10
11 Author's Addresses .................................. 11
12 Normative References ................................ 11
13 Informative References .............................. 12
J. Rosenberg et. al. [Page 2]
Internet Draft Response Routing September 27, 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, 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
socket. 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 does provide the client with
the source IP address that the server saw in the request, but not the
port. This information 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 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 field,
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 (RFC 3261) [1].
A client compliant to this specification (clients include UACs and
proxies) MAY include an "rport" parameter in the top Via header field
value of requests it generates. This parameter MUST have no value; it
serves as a flag to indicate to the server that this extension is
J. Rosenberg et. al. [Page 3]
Internet Draft Response Routing September 27, 2002
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
compatibility, the client 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 SIP [1].
When there is a NAT between the client and server, the request will
create (or refresh) a binding in the NAT. This binding must remain in
existence for the duration of the transaction in order for the client
to receive the response. Most UDP NAT bindings appear to have a
timeout of about one minute. This exceeds the duration of non-INVITE
transactions. Therefore, responses to a non-INVITE request will be
received while the binding is still in existence. INVITE transactions
can take an arbitrarily long amount of time to complete. As a result,
the binding may expire before a final response is received. To keep
the binding fresh, the client SHOULD retransmit its INVITE every 20
seconds or so. These retransmissions will need to take place even
after receiving a provisional response.
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 field
value. If this Via header field value contains an "rport" parameter
with no value, it MUST set the value of the parameter to the source
port of the request. This is analagous to the way in which a server
will insert the "received" parameter into the topmost Via header
field value. 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" component. Note that
this processing takes place independent of the transport protocol.
When a server attempts to send a response, it examines the topmost
Via header field value of that response. If the "sent-protocol"
component indicates an unreliable unicast transport protocol, such as
UDP, and there is no "maddr" parameter, 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. The response MUST be sent from the
same address and port that the corresponding request was received on.
J. Rosenberg et. al. [Page 4]
Internet Draft Response Routing September 27, 2002
This effectively adds a new processing step between bullets two and
three in Section 18.2.2 of SIP [1].
The response must be sent from the same address and port that the
request was received on in order to traverse symmetric NATs. When a
server is listening for requests on multiple ports or interfaces, it
will need to remember the one on which the request was received. For
a stateful proxy, storing this information for the duration of the
transaction is not an issue. However, a stateless proxy does not
store state between a request and its response, and therefore cannot
remember the address and port on which a request was received. To
properly implement this specification, a stateless proxy can encode
the destination address and port of a request into the Via header
field value that it inserts. When the response arrives, it can
extract this information and use it to forward the response.
5 Syntax
The syntax for the "rport" parameter is:
response-port = "rport" [EQUAL 1*DIGIT]
This extends the existing definition of the Via header field
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 to a proxy server which
looks like, in part:
INVITE sip:user@domain SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
This INVITE is sent with a source port of 4540 and a source IP
address of 10.1.1.1. The proxy is at 68.44.10.3, listening on both
J. Rosenberg et. al. [Page 5]
Internet Draft Response Routing September 27, 2002
port 5060 and 5070. The client sends the request to port 5060. The
request passes through a NAT, so that to the proxy server, the source
IP address appears as 68.44.20.1 and the source port as 9988. 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;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
;branch=z9hG4bKkjshdyff
This request generates a response, which arrives at the proxy:
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.domain.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
;branch=z9hG4bKkjshdyff
The proxy strips its top Via header field value, and then examines
the next one. It contains both a "received" parameter, and an "rport"
parameter. The server follows the rules specified in Section 4 and
sends the response to IP address 68.44.20.1, port 9988, and sends it
from port 5060 on 68.44.10.3:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
;branch=z9hG4bKkjshdyff
This packet matches the binding created by the initial request.
Therefore, the NAT rewrites the destination address of this packet
back to 10.1.1.1, and the destination port back to 4540. It forwards
this response to the client, which is listening for the response on
that address and port. The client properly receives the response.
7 Security Considerations
Since this extension merely adds source port information to the
source IP address information already present in SIP, it does not
appear to add any additional security considerations.
J. Rosenberg et. al. [Page 6]
Internet Draft Response Routing September 27, 2002
8 IANA Considerations
There are no IANA considerations associated with this specification.
9 IAB Considerations
The IAB has studied a class of protocols referred to as Unilateral
Self Address Fixing (UNSAF) protocols [3]. These protocols allow a
client behind a NAT to learn the IP address and port that a NAT will
allocate for a particular request, in order to use this information
in application layer protocols. An example of an UNSAF protocol is
the Simple Traversal of UDP Through NATs (STUN) protocol [4].
Any protocol is an UNSAF protocol if it reveals, to a client, the
source IP address and port of a packet sent through that NAT.
Although not designed for that purpose, this specification can be
used as an UNSAF protocol. Using the "rport" parameter (defined here)
and the "received" parameter (defined in RFC 3261 [1]) in the topmost
Via header field value of a response, a client sending a request can
learn its address as it was seen by the server which sent the
response.
There are two uses of this information. The first is for
registrations. Consider a client behind a NAT wishing to register
with a proxy on the other side of the NAT. The client must provide,
in its registration, the address at which it should receive incoming
SIP requests from the proxy. However, since the client is natted,
none of the addresses on any of its interfaces will be reachable from
the proxy. However, if the client can provide the proxy with an
address that the proxy can reach, the client can receive incoming
requests. Using this specification, a client behind a NAT can learn
its address and port as seen by the proxy which receives a REGISTER
request. The client can then perform an additional registration,
using this address in a Contact header. This would allow a client to
receive incoming requests, such as INVITE, on the socket through
which the registration was sent.
The second usage is for record routing, to address the same problem
as above, but between two proxies. A proxy behind a NAT which
forwards a request to a server can use OPTIONS, for example, to learn
its address as seen by that server. This address can be placed into
the Record-Route header field of requests sent to that server. This
would allow the proxy to receive requests from that server on the
same socket used to send it requests.
Because of this potential usage, this document must consider the
issues raised in [3].
J. Rosenberg et. al. [Page 7]
Internet Draft Response Routing September 27, 2002
9.1 Problem Definition
From [3], any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem
that is to be solved with the UNSAF proposal. A short term
fix should not be generalized to solve other problems; this
is why "short term fixes usually aren't".
This specification is primarily aimed at allowing SIP responses to be
received when a request is sent through a NAT. In this primary
application, this specification is not an UNSAF proposal. However, as
a side effect of this capability, this specification can be used as
an UNSAF protocol. In that usage, it would address two issues:
o Provide a client with an address that it could use in the
Contact header of a REGISTER request when it is behind a NAT.
o Provide a proxy with an address that it could use in a
Record-Route header in a request, when it is behind a NAT.
9.2 Exit Strategy
From [3], any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better
short term fixes are the ones that will naturally see less
and less use as the appropriate technology is deployed.
The SIP working group has recognized that the usage of this
specification to support registrations and record-routing through
NATs is not appropriate. It has a number of known problems which are
documented below. The way to eliminate potential usage of this
specification for address fixing is to provide a proper solution to
the problems that might motivate the usage of this specification for
address fixing. Specifically, appropriate solutions for registrations
and record-routing in the presence of NATs need to be developed.
These solutions would not rely on address fixing.
Requirements for such solutions are already under development [5].
Implementors of this specification are encouraged to follow this work
for better solutions for registrations and record-routing through
NAT.
9.3 Brittleness Introduced by this Specification
J. Rosenberg et. al. [Page 8]
Internet Draft Response Routing September 27, 2002
From [3], any UNSAF proposal must provide:
Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data
at multiple network layers create more dependencies,
increase debugging challenges, and make it harder to
transition.
This specification, if used for address fixing, introduces several
points of brittleness into a SIP system:
o If used for registrations, a client will need to frequently
re-register in order to keep the NAT bindings fresh. In many
cases, these registrations will need to take place nearly one
hundred times more frequently than the typical refresh
interval of a registration. This introduces load into the
system and hampers scalability.
o A client cannot accurately determine the binding lifetime of a
NAT it is registering (or record-routing) through. Therefore,
there may be periods of unreachability that occur between the
time a binding expires and the next registration or OPTIONS
refresh is sent. This may result in missed calls, messages, or
other information.
o If the NAT is of the symmetric variety [4], a client will only
be able to use its address to receive requests from the server
it has sent the request to. If that server is one of many
servers in a cluster, the client may not be able to receive
requests from other servers in the cluster. This may result in
missed calls, messages, or other information.
9.4 Requirements for a Long Term Solution
From [3], any UNSAF proposal must provide:
Identify requirements for longer term, sound technical
solutions -- contribute to the process of finding the right
longer term solution.
The brittleness described in Section 9.3 has led us to the following
requirements for a long term solution:
The client should not need to specify its address.
Registrations and record routing require the client to
specify the address at which it should receive requests. A
J. Rosenberg et. al. [Page 9]
Internet Draft Response Routing September 27, 2002
sound technical solution should allow a client to
explicitly specify that it wants to receive incoming
requests on the connection over which the outgoing request
was sent. In this way, the client does not need to specify
its address.
The solution must deal with clusters of servers. In many
commerically deployed SIP systems, there will be multiple
servers, each at different addresses and ports, handling
incoming requests for a client. The solution must
explicitly consider this case.
The solution must not require increases in network load. There
cannot be a penalty for a sound technical solution.
9.5 Issues with Existing NAPT Boxes
From [3], any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.
To our knowledge, at the time of writing, there is only very limited
usage of this specification for address fixing. Therefore, no
specific practical issues have been raised.
10 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
J. Rosenberg et. al. [Page 10]
Internet Draft Response Routing September 27, 2002
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.
11 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
12 Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
J. Rosenberg et. al. [Page 11]
Internet Draft Response Routing September 27, 2002
[2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
13 Informative References
[3] L. Daigle, "IAB considerations for UNilateral self-address fixing
(UNSAF) across network address translation," Internet Draft, Internet
Engineering Task Force, July 2002. Work in progress.
[4] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN -
simple traversal of UDP through network address translators,"
Internet Draft, Internet Engineering Task Force, Aug. 2002. Work in
progress.
[5] R. Mahy, "Requirements for connection reuse in the session
initiation protocol (SIP)," Internet Draft, Internet Engineering Task
Force, June 2002. Work in progress.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
J. Rosenberg et. al. [Page 12]
