wdiff draft-ietf-sip-nat-01.txt draft-ietf-sip-nat-02.txt

Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,J.Weinberger,H.Schulzrinne
draft-ietf-sip-nat-01.txt dynamicsoft,Columbia J. Rosenberg
dynamicsoft
J. Weinberger
dynamicsoft
H. Schulzrinne
Columbia U.
November 21, 2001
Expires: May
draft-ietf-sip-nat-02.txt
July 1, 2002

SIP Extensions
Expires: January 2003

An Extension to the Session Initiation Protocol (SIP)
for NAT Traversal 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

In this draft, we discuss how SIP can traverse existing, non-SIP
aware NATs. Our approach is to make SIP "NAT friendly" with two minor
extensions.

The first allows for Session Initiation Protocol (SIP) operates over UDP and TCP. When
used with UDP, responses to UDP requests to go back are returned to the source port of
address the request. The second allows a registrar to
use request came from, but from the source IP address and port instead of written into the Contact in a REGIS-
TER.

1 Introduction

The problem of getting applications through NATs has received a lot
topmost Via header of attention [1]. Getting SIP [2] through NATs is particularly trou-
blesome. There are several ways to solve the problem. One of these request. This behavior is
to embed an ALG in all NATs. However, this has not happened. The top
commercial NAT products continue to be SIP-unaware. Even if SIP ALG
support were added tomorrow, there desirable in
many cases, most notably, when the client is still a huge installed based of
NATs that do not understand SIP. As behind a result, there is going to be NAT. This
extension defines a
long period of time during which users will be behind NATs that are
ignorant of SIP, probably at least two to three years. The SIP com-
munity cannot wait new parameter for ubiquituous deployment of SIP aware NATs.

Another solution is to ubiquitously deploy IPv6, in the expectation Via header, called rport,
that this will eliminate the need for NATs. Whether this expectation
is realistic or not is one question, but the timeframes for such
deployment are long.

Yet another solution is to use midcom [3], with allows a user agent or proxy
controlling the firewall. This solution is, architecturally, much
better than usage of ALGs, but will take even longer client to ubiquitously
deploy.

Therefore, request that the approach taken is to make SIP "NAT Friendly" through
some backwards compatible extensions. These extensions generally
operate by informing a server to ignore an IP address present in send the
SIP message, and instead use response
back to the source IP address and port. This
follows the recommendations of [4].

Of course, the harder problem is port where the traversal request came from.

Table of the media streams
through NAT. That problem is covered separately. Contents

1 Introduction ........................................ 3
2 Reference Architecture

Consider the standard SIP "trapezoid" of Figure 1. 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

1 Introduction

The client UA 1,
is behind a NAT, NAT 1. It sends all requests Session Initiation Protocol (SIP) [1] operates over UDP and TCP.
When used with UDP, responses to local outbound proxy
1. Those requests are forwarded to terminating proxy 2, which then
sends them returned to the called party, UA 2, who is also behind a NAT.

Getting SIP through in this configuration involves two parts. The
first is getting source
address the request came from, but from UA 1 to Proxy 1, and the response
back. The second is getting the INVITE from Proxy 2 to UA 2, and the
response back. The solution for the first problem is "Via Received
Ports". This solution follows the usage of the received parameter in port written into the
topmost Via header (which handles IP addresses), but for ports. The solu-
tion for of the second problem request. This behavior is not desirable in
many cases, most notably, when the new Translate header, which allows
a client to tell is behind a registrar to ignore NAT. In that
case, the Contact header, and
instead register an address obtained from response will not properly traverse the IP address and port
from NAT, since it will
not match the binding established with the REGISTER request.

The sections below describe these extensions

Related to this, there is currently no way in more detail.

3 Via Ports
+-------+ +-------+
| | | |
| Proxy |------------- | Proxy |
| 1 | | 2 |
| | | |
/ +-------+ +-------+
/ \
/ \
+------------------+ +------------------------+
.....+------------------+... ..+------------------------+..
. / NAT 1 . . NAT 2 \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................

Figure 1: Reference Configuration

The first problem with SIP traversal through NATs is sending a
request from for a client behind a NAT to
learn, from a server on the outside (UA 1
to proxy 1).

SIP specifies that for UDP, the response is sent to its request, the source port number that the
server saw in the Via header and request. Currently, SIP does provide the client
with the source IP address that the request came from. However,
due to NAT, the port number server saw in the Via header will be wrong. request. This
means that the response will not be sent to
information is conveyed in the proper location. How-
ever, with TCP, responses are sent over received parameter in the connection topmost Via
header of the INVITE
arrived on. response. This means that a response sent over the TCP connection
will be received properly by a caller behind a NAT. Therefore, one
solution information has proved useful for traversal basic
NAT traversal, debugging purposes, and support of requests from inside to outside is to use
persistent TCP connections. multi-homed hosts.
However, many VoIP endpoints do not sup-
port TCP, so a UDP based solution is desirable.

Our approach it is to define incomplete without the port information.

This extension defines a new parameter for the Via header parameter, header, called
rport, that allows a client to request that the
response port, encoded as "rport". This parameter is inserted by
clients (which can be proxies or UACs) when they wish for server send the
response to be sent back to the source IP address and port where the request was sent
came from. The rport parameter is inserted with no value analagous to flag this feature.
When received at a server which understands this extension, the
server (which can be received
parameter, except rport contains a proxy or UAS) MUST insert the port number, not the request
was received from as the value of IP address.

2 Terminology

In this parameter. If document, the Via maddr
parameter is not present, that port MUST be used key words "MUST", "MUSTNOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to send the
response, instead of the port be interpreted as described in the sent-by field. If the maddr Via
parameter is present, the rport parameter is ignored for sending the
response, RFC 2119 [2] and
indicate requirement levels for compliant SIP implementations.

3 Client Behavior

The client behavior specified here affects the procedures transport processing
defined in [2] are used.

response-port = ``rport'' [``='' 1*DIGIT] Section 18.1 of SIP [1].

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

When the client sends the request, if the request is sent on, and using UDP,
the client MUST also list,
in be prepared to receive the sent-by field, response on the local port of that same
socket the request was sent from. The latter is mandatory for backwards compatibility.

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 of
10.1.1.1. The request is natted, so that on. Specifically, it MUST be prepared to
receive the source response on the same IP appears as
68.44.20.1 address 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 present 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 con-
tains both a received param, and an rport. The result is that the
follow response is sent to
source IP address 68.44.20.1, and source port 9988:

SIP/2.0 200 OK
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.

This works fine when the server supports this extension, so long as
there are no nats between request. For backwards
compatibility, the client and server. Consider a server
that does not understand it. In this case, it will ignore the rport
parameter, and send the following response MUST still be prepared to IP 10.1.1.1, port 4540:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;rport

As specified by SIP, this receive a
response is sent to the source IP of the
request, and on the port indicated in the Via header. Since the client is listen-
ing on 4540, sent-by field of the response is received correctly. topmost
Via, as specified in Section 18.1.1 of SIP [1].

In the case where the server does not support the extension, but there is a nat NAT between the client and the server, the response is
sent to the source IP and port in the Via, which will be dropped by
the nat. This is the same behavior exhibited by SIP today. As a
result, our extension is backwards compatible, in the sense that it
always works at least as well as baseline SIP. When both sides
support it, and there is a nat in the middle, traversal works
correctly.

For
order for the response to always be received, the NAT binding must
remain in existence for the duration of the transaction. Most UDP NAT bind-
ings
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.

Because of the increased network traffic generated to keep the UDP
bindings active, it is RECOMMENDED that TCP be used instead, as it
generates much less data.

4 Contact Translation

The received port parameter will allow requests initiated from inside
the NAT (and their responses), to work. However, getting requests
from a proxy outside the NAT, to a host inside,

OPEN ISSUE: This is awful. Perhaps a different story.

The problem has to do with registrations. In Figure 1, the callee, UA
2, will receive requests at further sign that UA because it had previously sent a
REGISTER request to the registrar, which
only real answer is co-located with proxy 2.
This registration contains a Contact header which lists the address
where the incoming requests should be sent to. However, in the case
of NAT, TCP? Or, perhaps this address will be wrong. It will contain a domain name or
IP address that is within the private space of domain B. Thus, the
REGISTER might look like:

This address is belongs in
sipping-nat-scenarios, not reachable by here.

4 Server Behavior

The server behavior specified here affects the proxy.

To solve this problem, we need two things. First, we need a per-
sistent "connection" to be established from UA 2 to proxy 2.
Secondly, we need transport processing
defined in Section 18.2 of SIP [1].

When a way for incoming requests destined for UA 2 server compliant to be
routed over this connection.

To address this first problem, clients have to send REGISTER requests
over specification (which can be a TCP or TLS connection, proxy
or use UDP along with the response port
parameter in UAS) receives a request, it examines the topmost Via header. If TCP is used,
this connection is kept
open indefinitely. We further recommend that Via header contains an rport parameter with no value, it MUST
insert the proxy/registrar hold
this connection in a table, where port the table is indexed by request was received from as the remote
side value of the transport connection. For UDP, the client holds on to the
socket, and uses it for REGISTER refreshes and to receive incoming
calls. The server also holds on this
parameter. This is analagous to the "connection". In the case of
UDP, that means that way in which a server stores the local IP/port that will insert
the request
was received on, and indexes it by receieved parameter with the source IP and port address the request was sent
received from. When In fact, the proxy wishes to send a packet to some server
at MUST insert a received parameter
containing the source IP address M, port N, transport O, it looks up the tuple (M,N,O)
in that the table to see request came from, even if a connection already exists, and then uses it.

The NAT bindings are kept fresh through REGISTER refreshes (see Sec-
tion 4.1).

Now, a connection is available for contacting the user. However, this
connection must be associated with sip:ua2@B.com. Unfortunately,
it is not. Calls for sip:ua2@B.com are translated to sip:ua2@10.0.1.100,
which does not correspond identical to the remote side connection used to send
the REGISTER, as seen by the proxy. Thats because value of NAT, which will
make the remote side appear to be a publically routable address.

To handle sent-by field. Note that this problem, the proxy could, in principal, record the IP
address and port from the remote side
processing takes place independent of the connection used transport protocol.

When a server attempts to send a REGISTER. Then, it can create a Contact entry of the form
sip:bob@[ip-addr]:[port], where [ip-addr] and [port] are the IP
address response over an unreliable unicast
transport, such as UDP, and port of the remote side of the connection. However, this
is assuming that the registration is for the purposes of connecting
the address in the To field with the machine the connection is coming
from. That may not be the intent of the registration. The registra-
tion may be used to set up a call forwarding service, for example.

As a result, it there is our proposal that clients be allowed to explicitly
ask a proxy to create a Contact entry corresponding to the machine a
REGISTER no Via maddr parameter present,
but there is sent from. To do that, the UA inserts both a Translate header
into the request. This header contains received parameter and an rport parameter, the URL (which
response MUST be one of
the Contact URLs) that is sent to be translated, along with a parameter
that indicates the type of NAT the client is behind.

translate-header = ``Translate'' ``:'' ``<'' addr-spec ``>''
[``;'' ``nat'' ``='' nat-types]
nat-types = ``sym'' | ``cone''

If a registrar receives a REGISTER request with a translate header,
it MUST find the matching Contact header (using standard URL matching
rules [2]) in the REGISTER request, and MUST replace the host value
with the IP address listed in the received parameter of the bottom-most Via,
if present, else the host from
parameter, and the Via sent-by field. The port of the
Contact MUST be replaced with in the rport parameter from the bottom-
most Via, if present, else the value from the sent-by field, if
present, else 5060. parameter. This is the actual Contact stored in the regis-
tration database, effectively adds
a new processing step between bullets two and returned to the client three in the response. Using
the bottom-most Via to obtain the source IP and source port Section 18.2.2
of the
client allows SIP [1].

5 Syntax

The syntax for the case where the registrar and the outbound proxy
are not co-located.

If no matching Contact was found in the REGISTER, the Translate
header is ignored.

The nat-type parameter is an optional rport parameter that tells the regis-
trar what type of NAT the client is behind. is:

response-port = "rport" [EQUAL 1*DIGIT]
This information is very
helpful for some faul tolerance and scalability scenarios, described
below. The means by which extends the client can determine which type of nat
it is behind are outside the scope existing definition of this specification.

Any 2xx response to a request that contained a Translate header, and
resulted in a translation (because there was a matching Contact),
MUST include a Translate header in the response. This header MUST
contain the translated URL. Of course, the same URL will also appear
amongst the Contacts in the 2xx. The Translate Via header in the 2xx is
needed parameters, so
that a UAC can determine the value of the translated Con-
tact when there are more than one registered contacts. its BNF now looks like:

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

6 Example

Consider once more the architecture of Figure 1. The callee has an IP
address of 10.0.1.100. It 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 REGISTER from port 2234 to source port
5060 on the proxy. This connection goes through the NAT, of 4540 and the source IP address
of 10.1.1.1. The request is rewritten to 77.2.3.88, natted, so that the source IP appears as
68.44.20.1 and the source port to
2937. The registration looks like:

REGISTER sip:ua2@Y.com SIP/2.0
From: sip:ua2@Y.com
To: sip:ua2@Y.com
Via: SIP/2.0/UDP 10.0.1.100;rport
Translate: sip:ua2@10.0.1.100:2234
Contact: sip:ua2@10.0.1.100:2234 as 9988. This is received at a proxy.
The proxy Y then stores the socket forwards the request was received on into request, but not before appending a
table, indexed by the source port:

(77.2.3.88,2397,UDP) -> [reference value to UDP socket]
It fills in
the rport parameter, and adds the received parameter, to
the top Via. It also translates the Contact header to
sip:ua2@77.2.3.88:2397, and stores that parameter in the registration database.
It then responds to the REGISTER: proxied request:

INVITE sip:user@domain2 SIP/2.0 200 OK
From: sip:ua2@Y.com
To: sip:ua2@Y.com
Via: SIP/2.0/UDP 10.0.1.100;rport=2397;received=77.2.3.88
Translate: sip:ua2@77.2.3.88:2397
Contact: sip:ua2@77.2.3.88:2397 proxy.domain.com
Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988

This response is sent to 77.2.3.88:2397 because of the rport. The NAT
translates this to 10.0.1.00:2234, request generates a response, which is then received by the
client.

Now, when an INVITE arrives for sip:ua2@Y.com, it is looked up in at the
registration database. 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 contact is extracted, and the proxy tries
to send the request to that address. To do so, it checks strips its connec-
tion table to an open connection to the IP address, port top Via, and tran-
sport where then examines the request is destined. In this case, such next one. It
contains both a connection
is available, received param, and the request is forwarded over it. Because it is
over a connection with an existing NAT binding, it is properly routed
through the NAT. rport. The response from the callee is also routed over the
same connection.

If the UA is behind a symmetric NAT, the proxy that the user is con-
nected to needs to record route incoming and outgoing INVITE
requests.

4.1 Refresh Interval

Since the connection used for the registrations result is held persistently
in order to receive incoming calls, the NAT binding must be main-
tained. To avoid timeout, data must traverse the NAT over that con-
nection with some minimum period. When UDP is used, registrations
will need to be refreshed at least once every minute. The clients
SHOULD include an Expires header or parameter with this value. For
TCP, a longer interval can be used. 10 minutes is RECOMMENDED.

To test whether the interval is short enough, proxy servers MAY
attempt to send OPTIONS requests to the client shortly before the
registration expires. If the OPTIONS requests generates no
following response
at all, the server SHOULD lower the value of the Expires header in
the next registration. Servers SHOULD cache and reuse the largest
successful refresh interval that they discover for a given Contact
value.

4.2 Routing to the Ingress Proxy

A complication arises when a domain supports multiple proxy servers.
Consider the scenario shown in Figure 2

A user joe in domain.com is behind a NAT. In DNS, domain.com contains
an SRV entry that points to three servers, 1.domain.com, 2.domain.com
and 3.domain.com. When the user registers, they will resolve
domain.com to one of these. Assume its 1.domain.com. As a result of
this, the connection state is stored proxy 1.

In the case of TCP, this connection state is important. Unless calls
for joe@domain.com arrive to proxy 1, they won't be routable to the
UA. In the case of UDP, whether it is important or not depends on the
type of NAT the user is behind. One type of NAT, which we call "sym-
metric", treats UDP much like TCP. When A sends a request from inside
to B on the outside, UDP messages back sent to A must come from B, with a
source IP address 68.44.20.1, port equal to 9988:

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

The NAT rewrites the destination port address of messages from A to B. In
the other case, which we call "cone", which is described in [5], UDP
messages this packet back to A can have any source IP
10.1.1.1, port 4540, and IP address.

If the user is behind a NAT that operates in cone mode, any of the
proxies in the proxy farm will be able to reach the customer through
the NAT. All will send requests to the public IP address and port
binding created received by the NAT, but with different source IP addresses
and ports. client.

7 Security Considerations

Since source addressing doesn't matter, things work well.
In this case, the proxy need not even store connection state as
described in Section 4.

If the user is behind a NAT that operates in symmetric mode, calls to
the user must come in through the proxy that the user registered to.
In order extension merely adds source port information to enable this, we recommend that the location server data-
base store not only the contact, but the proxy that the user con-
nected to. When a call comes in for that user, the proxy receiving
the INVITE looks up the user
source address information already present in the database. The database entry
indicates the proxy the user is connected to (call this the connected
proxy). If the connected proxy is not the proxy which received the
INVITE, the proxy that received the INVITE uses a route header to
force the call through the connected proxy. In the case where joe
registered at proxy1, and the incoming INVITE arrived at proxy 2, the
request sent by proxy 2 would look like:

INVITE sip:proxy1.domain.com SIP/2.0
--
// \\
/ \
| DB |
| |
\ /
\\ //
--

+-----+ +-----+ +-----+
| | | | | | domain.com
|Proxy| |Proxy| |Proxy|
| 1 | | 2 | | 3 |
+-----+ +-----+ +-----+

+-------------------------+
| NAT |
+-------------------------+

+-----+
| |
|UA |
| |
+-----+

Figure 2: Multiple Proxy Configuration
Route: sip:joe@22.1.20.3:3038

This request will first go to proxy1, and from there, over the exist-
ing connection to joe.

An alternate approach, instead of Route headers, is to simply have
the proxy which received the request forward it to the one that the
user registered with, without modifying the request URI. This will
cause the receiving proxy to perform the location server lookup a
second time, which is inefficient. However, SIP, it does not rely on the
usage of pre-loaded routes.

The differing proxy behaviors for symmetric and cone NATs explains
the presence of the nat-type attribute in the Translate header.
Assuming the client can determine which type it is behind it can sim-
ply inform the proxy, allowing it to take the proper action.

4.3 INVITE Usage

The 200 OK response to the REGISTER request contains the SIP URL that
the registrar placed into the database. This address has the impor-
tant property that it is routable to the client from the proxy on the
public side of the NAT. As a result, the client needs to place this
URL as the Contact header in its INVITE requests and 2xx responses appear
to
INVITE, so that it can be reached from the proxy on the outside.

5 Security add any additional security considerations.

8 IANA Considerations

Arguably, the usage of receive ports and the Translate header improve
security. In normal SIP usage, a rogue UA or proxy can send registra-
tions that contain Contacts that point to a different phone. Or, they
can send an INVITE

There are no IANA Considerations associated with a Via header that contains the echo port, or
some other port, on the machine. These can be used to launch attacks.
The receive port and Translate header insure that only the entity
that sent the requet, is the one to receive further messages.

6 this specification.

9 Acknowledgements

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

7 Changes since draft-ietf-sip-nat-00

o Described resolution of conflict between rport and maddr
parameter.

o Specified that the registrar use the bottom-most Via rport and
received parameter to obtain the source IP and port.

o Specified that the Translate header needs to appear in 2xx
REGISTER responses.

8 Changes since draft-rosenberg-sip-entfw-02

o Split entfw into three. This is piece 1, which covers the pure
SIP extensions.

o Changed syntax of Translate header. Allow any URL type, and
require usage of angle brackets to distinguish URL from header
parameters.

o Clarified that record-routing of INVITE at the proxy is not
needed if UDP is used and the client is behind a full cone
NAT.

Full Copyright Statement

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 docu-
ment
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 develop-
ing
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 MER-
CHANTABILITY
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

10 Bibliography

11 Normative References

[1] M. Holdrege and P. Srisuresh, "Protocol complications with the IP
network address translator (NAT)," Internet Draft, Internet Engineer-
ing Task Force, Oct. 2000. Work in progress.

[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, H. Schulzrinne, et al. , "SIP:
session Session initiation
protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.

[3] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan,
"Middlebox communication architecture and framework," Internet Draft, Internet Engineering Task Force, Oct. 2001. Feb.
2002. Work in progress.

[4] D. Senie, "NAT friendly application design guidelines," Internet
Draft,

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

12 Informative References

Full Copyright Statement

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 progress.

[5] J. Rosenberg, R. Mahy, its implementation may be prepared, copied, published
and C. Huitema, "Traversal using nat relay
(turn)," 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 Draft, Society or other
Internet Engineering Task Force, Nov. 2001.
Work organizations, except as needed for the purpose of
developing Internet standards in progress. 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.