732 lines
28 KiB
Plaintext
732 lines
28 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
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 analogous to the "received"
|
|||
|
parameter, except "rport" contains a port number, not the IP address.
|
|||
|
|
|||
|
2. Terminology
|
|||
|
|
|||
|
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
|
|||
|
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
|||
|
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
|
|||
|
[2] and indicate requirement levels for compliant 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 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 IP
|
|||
|
address and port it used to populate 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
A UA MAY execute the binding lifetime discovery algorithm in Section
|
|||
|
10.2 of RFC 3489 [4] to determine the actual binding lifetime in the
|
|||
|
NAT. If it is longer than 1 minute, the client SHOULD increase the
|
|||
|
interval for request retransmissions up to half of the discovered
|
|||
|
lifetime. If it is shorter than one minute, it SHOULD decrease the
|
|||
|
interval for request retransmissions to half of the discovered
|
|||
|
lifetime. Note that discovery of binding lifetimes can be
|
|||
|
unreliable. See Section 14.3 of RFC 3489 [4].
|
|||
|
|
|||
|
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 analogous 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.
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
A client sends an INVITE to a proxy server which looks like, in part:
|
|||
|
|
|||
|
INVITE sip:user@example.com 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 192.0.2.2 (proxy.example.com),
|
|||
|
listening on both port 5060 and 5070. The client sends the request
|
|||
|
to port 5060. The request passes through a NAT on the way to the
|
|||
|
proxy, so that the source IP address appears as 192.0.2.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@example.com SIP/2.0
|
|||
|
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
|
|||
|
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.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.example.com;branch=z9hG4bKkjsh77
|
|||
|
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.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 192.0.2.1, port 9988, and sends it
|
|||
|
from port 5060 on 192.0.2.2:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
SIP/2.0 200 OK
|
|||
|
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.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
|
|||
|
|
|||
|
When a server uses this specification, responses that it sends will
|
|||
|
now include the source port where the request came from. In some
|
|||
|
instances, the source address and port of a request are sensitive
|
|||
|
information. If they are sensitive, requests SHOULD be protected by
|
|||
|
using SIP over TLS [1]. In such a case, this specification does not
|
|||
|
provide any response routing functions (as these only work with TCP);
|
|||
|
it merely provides the client with information about the source port
|
|||
|
as seen by the server.
|
|||
|
|
|||
|
It is possible that an attacker might try to disrupt service to a
|
|||
|
client by acting as a man-in-the-middle, modifying the "rport"
|
|||
|
parameter in a Via header in a request sent by a client. Removal of
|
|||
|
this parameter will prevent clients from behind NATs from receiving
|
|||
|
service. The addition of the parameter will generally have no
|
|||
|
impact. Of course, if an attacker is capable of launching a man-in-
|
|||
|
the-middle attack, there are many other ways of denying service, such
|
|||
|
as merely discarding the request. Therefore, this attack does not
|
|||
|
seem significant.
|
|||
|
|
|||
|
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 [5]. 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) [4].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 6]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
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/registrar 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
|
|||
|
located behind a NAT, none of the addresses on any of its interfaces
|
|||
|
will be reachable from the proxy. 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 IP address and port it used to populate the source IP
|
|||
|
address and port of the registration it sent. This approach will
|
|||
|
only work when servers send requests to a UA from the same address
|
|||
|
and port on which the REGISTER itself was received.
|
|||
|
|
|||
|
In many cases, the server to whom the registration is sent won't be
|
|||
|
the registrar itself, but rather a proxy which then sends the request
|
|||
|
to the registrar. In such a case, any incoming requests for the
|
|||
|
client must traverse the proxy to whom the registration was directly
|
|||
|
sent. The Path header extension to SIP [3] allows the proxy to
|
|||
|
indicate that it must be on the path of such requests.
|
|||
|
|
|||
|
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 IP address and port it used to populate the source IP address
|
|||
|
and port of the OPTIONS request.
|
|||
|
|
|||
|
Because of this potential usage, this document must consider the
|
|||
|
issues raised in [5].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 7]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
9.1. Problem Definition
|
|||
|
|
|||
|
From [5], 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 [5], 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 [6].
|
|||
|
|
|||
|
Implementors of this specification are encouraged to follow this work
|
|||
|
for better solutions for registrations and record-routing through
|
|||
|
NAT.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 8]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
9.3. Brittleness Introduced by this Specification
|
|||
|
|
|||
|
From [5], 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 UDP 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.
|
|||
|
|
|||
|
o If the NAT is of the symmetric variety [4], a client will only be
|
|||
|
able to use its address to receive requests if the server sends
|
|||
|
requests to the client from the same address and port the server
|
|||
|
received the registrations on. This server behavior is not
|
|||
|
mandated by RFC 3261 [1], although it appears to be common in
|
|||
|
practice.
|
|||
|
|
|||
|
o If the registrar and the server to whom the client sent its
|
|||
|
REGISTER request are not the same, the approach will only work if
|
|||
|
the server uses the Path header field [3]. There is not an easy
|
|||
|
and reliable way for the server to determine that the Path header
|
|||
|
should be used for a registration. Using Path when the address in
|
|||
|
the topmost Via header field is a private address will usually
|
|||
|
work, but may result in usage of Path when it is not actually
|
|||
|
needed.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 9]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
9.4. Requirements for a Long Term Solution
|
|||
|
|
|||
|
From [5], 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 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
|
|||
|
commercially 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 [5], 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 and Allison Mankin for
|
|||
|
their comments and contributions to this work.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 10]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
11. References
|
|||
|
|
|||
|
11.1. Normative References
|
|||
|
|
|||
|
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
|
|||
|
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
|
|||
|
Session Initiation Protocol", RFC 3261, June 2002.
|
|||
|
|
|||
|
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
|||
|
Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
|
|||
|
Extension Header Field for Registering Non-Adjacent Contacts",
|
|||
|
RFC 3327, December 2002.
|
|||
|
|
|||
|
[4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
|
|||
|
Simple Traversal of User Datagram Protocol (UDP) Through Network
|
|||
|
Address Translators (NATs)", RFC 3489, March 2003.
|
|||
|
|
|||
|
11.2. Informative References
|
|||
|
|
|||
|
[5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral
|
|||
|
Self-Address Fixing (UNSAF) Across Network Address Translation",
|
|||
|
RFC 3424, November 2002.
|
|||
|
|
|||
|
[6] Mahy, R., "Requirements for Connection Reuse in the Session
|
|||
|
Initiation Protocol (SIP)", Work in Progress.
|
|||
|
|
|||
|
12. Intellectual Property Statement
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
intellectual property or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; neither does it represent that it
|
|||
|
has made any effort to identify any such rights. Information on the
|
|||
|
IETF's procedures with respect to rights in standards-track and
|
|||
|
standards-related documentation can be found in BCP-11. Copies of
|
|||
|
claims of rights made available for publication and any assurances of
|
|||
|
licenses to be made available, or the result of an attempt made to
|
|||
|
obtain a general license or permission for the use of such
|
|||
|
proprietary rights by implementors or users of this specification can
|
|||
|
be obtained from the IETF Secretariat.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 11]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights which may cover technology that may be required to practice
|
|||
|
this standard. Please address the information to the IETF Executive
|
|||
|
Director.
|
|||
|
|
|||
|
13. Authors' Addresses
|
|||
|
|
|||
|
Jonathan Rosenberg
|
|||
|
dynamicsoft
|
|||
|
600 Lanidex Plaza
|
|||
|
Parsippany, NJ 07054
|
|||
|
US
|
|||
|
|
|||
|
Phone: +1 973 952-5000
|
|||
|
EMail: jdrosen@dynamicsoft.com
|
|||
|
URI: http://www.jdrosen.net
|
|||
|
|
|||
|
|
|||
|
Henning Schulzrinne
|
|||
|
Columbia University
|
|||
|
M/S 0401
|
|||
|
1214 Amsterdam Ave.
|
|||
|
New York, NY 10027
|
|||
|
US
|
|||
|
|
|||
|
EMail: schulzrinne@cs.columbia.edu
|
|||
|
URI: http://www.cs.columbia.edu/~hgs
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 12]
|
|||
|
|
|||
|
RFC 3581 Symmetric Response Routing August 2003
|
|||
|
|
|||
|
|
|||
|
14. Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2003). 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 assignees.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
Acknowledgement
|
|||
|
|
|||
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
Internet Society.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Rosenberg & Schulzrinne Standards Track [Page 13]
|
|||
|
|