Network Working Group C. Martin
Internet Draft A. Johnston
Expires: January 2002 WorldCom
Category: Informational July 2001
SIP Through NAT Enabled Firewall Call Flows
draft-martin-network-sip-natfw-callflows-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026[1].
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. The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This informational draft outlines the operation of a SIP enabled
NAPT (often referred to as PAT)/firewall ALG which makes
modifications to SIP (Session Initiation Protocol)[2] headers and
SDP (Session Description Protocol)[3] fields. Both inbound and
outbound detailed call flows are included.
Table of Contents
Introduction 3
Overview of NAT 3
Assumptions 4
Scenario Topology 5
Call Scenario 5
Security Considerations and Implications 5
Transparency vs. SIP Proxy Functionality 6
High Level Tasks 6
SIP Signaling 6
Resulting media 6
Media control and status 6
Termination of SIP and Resulting Media 7
Typical Enterprise Application 7
Call Flow LEGEND 7
Outbound SIP through NAT Call Flow Scenario 8
Outbound Call Flow Illustration 8
Outbound Call Flow Detail 8
Inbound SIP Through NAT Call Flows 22
Inbound Call Flow Illustration 22
Inbound Call Flow Detail 22
References 32
Authors' Addresses 33
Copyright Notice 33
Introduction
This document is intended to define the basic minimum requirement
for the operation of the session initiation protocol (SIP)[2]
traversal through NAPT and/or firewalls; both call flow, as well as
firewall and NAT functionality will be addressed. The underlying
intent is to identify specific considerations to the IETF for the
development of SIP compliant middle-boxes for the rapid deployment
of SIP. It does not address control by external proxies or firewall
control mechanisms, or DNS host naming conventions between private
and public realms. However, these flows do give an idea of the
interaction necessary between the middle-box, specifically NAPT and
firewall functionality, to be referred to as firewall in the
remainder of this text. Consideration of "end-to-end" communications
between hosts to maintain internal network integrity to the
enterprise through proper packet modifications will also be
addressed.
Overview of NAT
As described in RFC 1683[5], NAT and RFC 2663[6], IP Network
Address Translator Terminology and Considerations, the following
assumptions can be made, for our purposes, as it relates to NAT,
some of these statements are included word for word from the RFCs:
"The need for IP Address translation arises when a network's
internal IP addresses cannot be used outside the network either
because they are invalid for use outside, or because the internal
addressing must be kept private from the external network." [6]
In this case the scenario pertains to an enterprise scenario which
implements a firewall performing NAT as well as the method of using
one global IP address also commonly known as network address port
translation (NAPT) or PAT. Throughout this document we will discuss
a minimum requirement for "transparent" modifications to SIP packets
in a PAT environment.
"A Global or Public Network is an address realm with unique
network addresses assigned by Internet Assigned Numbers Authority
(IANA) or an equivalent address registry. This network is also
referred as External network during NAT/PAT discussions." [6]
"A private network is an address realm independent of external
network addresses. Private network may also be referred alternately
as Local Network. Transparent routing between hosts in private realm
and external realm is facilitated by a NAT/PAT router." [6]
Along these lines, the call flows in this document refer to a
global address as a Global Address (GA); a private network address
is referred to as a Local Address (LA). Remote global addresses, in
relation to the firewall, are referred to as Remote Addresses (RA).
"In addition to modifying the IP address, NAT/PAT must modify the
IP checksum and the TCP checksum. Remember that TCPs checksum also
covers a pseudo header, which contains the source and destination
address. NAT must also look out for ICMP and FTP and modify the
places where the IP address appears. There are undoubtedly other
places, where modifications must be done." [5]
Now we can add SIP to the list of protocols requiring the
modification features associated with NAT.
"The NAT function cannot by itself support all applications
transparently and often must co-exist with application level
gateways (ALGs) for this reason. People looking to deploy NAT based
solutions need to determine their application requirements first and
assess the NAT extensions (i.e., ALGs) necessary to provide
application transparency for their environment." [6]
This document attempts to address the functional areas relating
to the network layer (IP, for our purposes), and transport layer
(UDP in our example), if necessary. For the purpose of future SIP
communications there may be a requirement for an ALG to create the
appearance of transparent routing for end-to-end communications via
the firewall, as well for modification of key header fields. For now
developing a basic functionality for providing "transparent" SIP
signaling and media flows through firewalls should be considered a
key to facilitating multimedia communications over IP.
Assumptions
Throughout this call flow document the firewall is implemented as
the gateway of last resort (default gateway) for the private
network. All communications within this document are via UDP
transport.
The SIP proxy (NS) is utilized by the enterprise to provide
additional SIP services not available between ordinary SIP clients,
such as conferencing and voice mail.
UserA is on a private network protected by a firewall with NAT
enabled. UserB is a SIP client located on an unprotected public
network located externally in relation to the outside firewall
interface. The SIP proxy is located on the public network as well.
Both UserA and UserB must communicate via the proxy server; hence
the end users never communicate directly during signaling.
Scenario Topology
+---------+
|SIP Proxy|
+---------+
|
|
+----------+ | +--------+
| Firewall |---IP Cloud---| User B |
+----------+ +--------+
|
+----------+
| User A |
+----------+
Figure 1
Call Scenario
If UserA wishes to place a SIP phone call they must go through
the firewall, as seen in Figure 2. If UserB wishes to place a call
to UserA, the firewall must be listening on port 5060 to act on the
incoming INVITE, as seen in Figure 3.
The firewall must be able to recognize and act on SIP packets as
they flow through it. To facilitate this figure 1 and 2 give
detailed call flow progression with notes to describe the
modifications, pinhole creation, etc., which must occur to provide
the illusion of transparency to the end users. For incoming requests
the firewall will need a method to resolve the internal host's IP
address by the "Via:", "Contact:", or c= fields found in the initial
INVITE and 200 OK message bodies.
Relevant fields related to firewall modifications MAY include
some or all of the following headers/fields: Via, Record-Route,
Route, Contact, Call-ID, o=, c=, and m=, and any other fields that
may contain an IP address instead of hostname.
Security Considerations and Implications
Consideration should be made to ensure that internal private
topology information not be divulged in the signaling packets.
Consideration should also be made to reduce information-gathering
attacks that utilize SIP enabled scanning tools (which may
inevitably be created as the protocol gains increased exposure).
The following lines; Via, Record-Route, Route, Contact, Call-ID, To,
From, and Call-ID found in SIP, as well as o=, and c= found in SDP,
MAY include an IP version of those fields that could heighten the
risk of topology leaks if not addressed during development of
firewall solutions. There are many other security aspects not
included in this document but just as important, such as trust
relationships, authentication, firewall control mechanisms, host
resolution behind firewalls, etc.
Transparency vs. SIP Proxy Functionality
To keep things simple, initially, it is recommended that the SIP
functionality of the firewall act as an outbound proxy (B2BUA), when
dealing with the Via, Route, and Record-Route header, in addition to
the function of hiding internal addresses in all other fields where
required. This is both to protect internal topology as well as to
reduce the number of tables required to provide "transparency".
High Level Tasks
SIP Signaling
For initiation of SIP sessions the firewall MUST create a NAT table
entry for the SIP session, that SHOULD require the inclusion of
Call-ID and tag to identify the session.
Resulting media
Before describing RTP and RTCP level tasks we will include the
following excerpt from RFC 1889, regarding RTP, this is only to
illustrate the level of RTP operation required by this document.
"RTP relies on the underlying protocol(s) to provide demultiplexing
of RTP data and RTCP control streams. For UDP and similar protocols,
RTP uses an even port number and the corresponding RTCP stream uses
the next higher (odd) port number. If an application is supplied
with an odd number for use as the RTP port, it should replace this
number with the next lower (even) number.", from RFC 1889 [7] .
Based on this comment the firewall should create a NAT table entry for RTP that requires IP address port translation of local and global address. There should be a mechanism to allow creation of a dynamic firewall access list that allows NAT source entries and source port to NAT destination entries and source port, which SHOULD be based on SDP information, for each direction and associated with the SIP session by Call-ID and tag. Mechanisms SHOULD also be in place to ensure that RTP ports utilize even numbering, as stated in RFC 1889 [7].
Media control and status
The firewall MUST create a NAT table entry for RTCP, if the packet
requires IP address and/or port translation of local and global
address. There MUST be a mechanism to create dynamic firewall access
rules that allows NAT source entries and source port+1 to NAT
destination entries and source port+1, which SHOULD be based on SDP
information, for each direction and associated. This entry SHOULD be
associated with the SIP session by Call-ID and tag. There SHOULD
also be mechanisms to ensure that RTCP ports remain the next odd
numbered ports in relation to the related RTP port number.
Termination of SIP and Resulting Media
Upon receipt of Bye, Cancel, Transfer, or timeout, the firewall
SHOULD remove NAT translations, and the firewall access rules
(pinholes) MUST be removed.
Typical Enterprise Application
The typical enterprise solution for connectivity to the Internet
that is through a firewall implementation with NAT enabled,
utilizing one external global IP address that represents all
internal IP addresses (PAT), in combination with dynamic or static
port assignment to each internal machine. It is important that
incoming and outgoing sessions have the ability to operate in this
type of scenario SIP UA to SIP UA if necessary. It is also
recommended that the firewall behave as a Back-To-Back User Agent
(B2BUA)[8], in order to provide the appropriate level of
transparency as well as to maintain state of the sessions traversing
it. Another possible alternative may be to utilize an internal SIP
proxy to work in tandem with the firewall to create the B2BUA
behavior, this text describes the firewall/B2BUA approach.
Call Flow LEGEND
UserA Local Private Address (LA)= 10.1.1.221
UserB Remote Global Address (RA) = 192.168.1.10
SIP Proxy Server (NS)= 63.81.221.88
Firewall(NAT) global address = 192.168.221.1
Each Packet is enclosed in the following manner:
"============================================="
Headers and fields modified by the firewall have a "*" added at the
end of the line, and detailed notes will be included after each
relevant packet. In this document all packets contain an IP header
field to clarify the operation of NAT throughout the call flow.
Outbound SIP through NAT Call Flow Scenario
Outbound Call Flow Illustration
UserA NAT NS UserB
10.1.1.221 192.168.221.1 63.88.221.88 192168.1.10
| | | |
|----F1 INVITE---->|--F2 INVITE->| |
| | |--F5 INVITE->|
|<---F4 100--------|<-F3 100-----| |
| | | |
| | |<--F6 180----|
|<---F8 180--------|<-F7 180-----| |
| | | |
| | |<--F9 200 OK-|
|<---F11 200 OK----|<-F10 200 OK-| |
| | | |
|----F12 ACK------>|---F13 ACK-->| |
| | |--F14 ACK--->|
| | | |
|<---F15 2WAY RTP->|<-------F16 2WAY RTP------>|
| | | |
|----F17 BYE------>|-F18 BYE---->| |
| | |--F19 BYE--->|
| | | |
| | |<-F20 200 OK-|
|<---F22 200 OK----|<-F21 200 OK-| |
| | | |
Figure 2
Outbound Call Flow Detail
=============================================
F1 INVITE USERA->NAT
------ IP Header ---------------------------
IP Source Address: 10.1.1.221
IP Destination Address: 63.81.221.88
-------- SIP Message ------------------------
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.221:5060
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 123456@10.1.1.221
CSeq: 1 INVITE
Contact: sip:UserA@10.1.1.221
Authorization:Digest username="UserA", realm="MCI WorldCom SIP",
nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="",
uri="sip:63.81.221.88",
response="b3f392f9218a328b9294076d708e6815"
Content-Type: application/sdp
Content-Length: 143
v=0
o=UserA 2890844526 2890844526 IN IP4 UserA.customerA.com
s=-
t=0 0
c=IN IP4 10.1.1.221
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
===============================================
UserA prepares to receive data on port 49170 from the network. The
fields containing IP addresses, in outbound packets, SHOULD be
considered for modification by the firewall.
Note: Call-ID and tag, should be used, in addition to the To:,
From:, and additionally, in the case of the firewall acting as an
outbound proxy (or B2BUA) and external SIP Proxy; Record Route and
associated tags as specified in the SIP specification[1], should be
used to identify this session.
===============================================
F2 INVITE NAT -> NS
------ IP Header ---------------------------
IP source address: 192.168.221.1
IP Destination Address: 63.81.221.88
-------- SIP Message ------------------------
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 192.168.221.1:5060 *
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 12345600@192.168.221.1 *
CSeq: 1 INVITE
Contact: sip:UserA@192.168.221.1 *
Authorization:Digest username="UserA", realm="MCI WorldCom SIP",
nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="",
uri="sip:63.81.221.88",
response="b3f392f9218a328b9294076d708e6815"
Content-Type: application/sdp
Content-Length: 149 *
v=0
o=UserA 2890844526 2890844526 IN IP4 UserA.customerA.com
s=-
t=0 0
c=IN IP4 192.168.221.1 *
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
=================================================
For SIP, NAT may create an IP Header and transport header
translation entry mapping UserA local IP address to the global
address of the firewall, as necessary. All fields for all methods,
tags, and parameters must be translated if they contain an IP
address. The use of such a mapping can facilitate this. This table
shows the Call-ID translation as an example of a field that requires
modification. Examples are presented throughout this call flow,
though they are redundant, with indications of what needs to be
modified and what the method, tag, parameter performs.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| L | G | L | G | L/G | L/G | L/G |
|IP Address| IP Address | Call-ID | Call-ID |List.| Dst | TAG |
| | | | |Prot |Port | |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|10.1.1.221|192.168.221.1|1234500@ | 1234500@ | UDP |5060 |abcde|
| | |10.1.1.221|192.168.221.1| | | |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 1: IP/Call-ID Translation
All subsequent packets can use this mapping for SIP communications.
Optionally some solutions may assign a static source port number to
identify internal users. If this is the operation of the firewall's
NAT features the firewall MUST modify the Via field to reflect the
translation and listening port, in addition to adding a translation
for the global listening port.
Note: Call-ID could be used to identify the internal host for
inbound responses related to this session. The Content-Length header
MUST be modified to reflect the change to the SDP lines for all
relevant packets, i.e., Via, 200 OK, etc.
For RTP, The firewall passes information parsed from SDP "c=" and
"m=" to NAT for creation of inbound IP header and port translation
entry of 10.1.1.221 port 49170/192.168.221.1 port x (49170 in our
example). The firewall MUST create an inbound pinhole for the
listening IP Header and port based on outbound SDP.
NOTE: RTP ports MUST be even numbered
++++++++++++++++++++++++++++++++++++++++++++++++++++
| L | G | L/G | L | G |
| | |Protocol | Port | Port |
++++++++++++++++++++++++++++++++++++++++++++++++++++
|10.1.1.221|192.168.221.1| UDP | 49170 | 49170 |
++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 2: RTP Pinholes
For RTCP, the firewall must also open an incoming pinhole for a port
number one higher (an odd number). In our example it would be global
IP 192.168.221.1 listening Port 49171 Protocol UDP.
++++++++++++++++++++++++++++++++++++++++++++++++++++
| L | G | L/G | L | G |
| | |Protocol| Port | Port |
++++++++++++++++++++++++++++++++++++++++++++++++++++
|10.1.1.221|192.168.221.1 | UDP |49171 | 49171 |
++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 3: RTCP Pinholes
For SIP the firewall SHOULD keep track of Call-ID and tag value for
signaling, state, and to translate inbound SIP responses to the
correct inside host, in this case it is UserA on port 5060.
=================================================
F3 TRYING NS->NAT
-------- IP Header ------------------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.1
--------- SIP Message ---------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.221.1:5060
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>
Call-ID: 1234500@192.168.221.1
CSeq: 1 INVITE
=================================================
The NS uses a location manager function to determine where UserB is
actually located. Based upon location analysis the call is proxied
to UserB, for the firewall, which is actually UserA.
=================================================
F4 Trying NAT->UserA
------------ IP Header ---------------
Source IP Address: 63.81.221.88
Destination IP Address: 10.1.1.221
------------ SIP Message --------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.1.221:5060 *
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>
Call-ID: 1234500@10.1.1.221 *
CSeq: 1 INVITE
=================================================
=================================================
F5 INVITE NS->UserB
------ IP Header ---------------------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.1.10
------ SIP Message --------------------------
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route: <sip:UserB@there.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>
Call-ID: 1234500@192.168.221.1
CSeq: 1 INVITE
Contact: sip:UserA@192.168.221.1
Content-Type: application/sdp
Content-Length: 149
v=0
o=UserA 2890844526 2890844526 IN IP4 UserA.customerA.com
s=-
t=0 0
c=IN IP4 192.168.221.1
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
=================================================
Note: the Record-Route is inserted by proxy servers, which takes on
the form of Request URI, and may include additional tags (rr-param)such as maddr= indicating the proxy address.
=================================================
F6 RINGING UserB->NS
------------ IP Header -------------------
Source IP Address: 192.168.1.10
Destination IP Address: 63.81.221.88
------------ SIP Message ------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 1 INVITE
=================================================
=================================================
F7 RINGING NS->NAT
---------- IP Header -----------------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.1
---------- SIP Message ---------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.221.1:5060
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 1 INVITE
=================================================
=================================================
F8 RINGING NAT->UserA
---------- IP Header ------------------
Source IP Address: 63.81.221.88
Destination IP Address: 10.1.1.221
----------- SIP Message ----------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.1.1.221:5060 *
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@10.1.1.221 *
CSeq: 1 INVITE
=================================================
The firewall MUST modify the Via header to insure that UserA does
not discard this packet.
=================================================
F9 200 OK USERB->NS
------------- IP Header ------------------
Source IP Address: 192.168.1.10
Destination IP Address: 63.81.221.88
---------- SIP Message --------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route: <sip:UserB@there.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 1 INVITE
Contact: sip:UserB@192.168.1.10
Content-Type: application/sdp
Content-Length: 141
v=0
o=UserB 2890844527 2890844527 IN IP4 UserB.there.com
s=-
t=0 0
c=IN IP4 192.168.1.10
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
=================================================
=================================================
F10 200 OK NS->NAT
-------------- IP Header -------------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.1
-------------- SIP Message -----------------
SIP/2.0 200 OK
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route: <sip:UserB@there.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 1 INVITE
Contact: sip:UserB@192.168.1.10
Content-Type: application/sdp
Content-Length: 141
v=0
o=UserB 2890844527 2890844527 IN IP4 UserB.there.com
s=-
t=0 0
c=IN IP4 192.168.1.10
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
=================================================
=================================================
F11 200 OK NAT->UserA
------------- IP Header ---------------
Source IP Address: 63.81.221.88
Destination IP Address: 10.1.1.221
-------- SIP Message ------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.10:5060 *
Record-Route: <sip:UserB@there.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@10.1.1.221 *
CSeq: 1 INVITE
Contact: sip:UserB@192.168.1.10
Content-Type: application/sdp
Content-Length: 141
v=0
o=UserB 2890844527 2890844527 IN IP4 UserB.there.com
s=-
t=0 0
c=IN IP4 192.168.1.10
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
=================================================
The client for UserA prepares to send data on port 3456 to UserB.
For SIP, the firewall MUST do the following: Firewall parses SIP
packet and modifies Via using NAT table entry for the session to
determine the global IP address. Call-ID MUST also be modified if an
IP address is contained within it. In this packet Content-Length
does not require modification because SDP does not require changes
for inbound initiated sessions.
RTP
Firewall MUST determine the remote IP address and remote listening
port values from SDP c=<IP address> and m=<port value>.
This SHOULD be added to the NAT table created, based on Call-ID and
tag.
The following information could be added to the NAT table for RTP
Communications:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP Address | R Protocol | R Listening Port |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| 192.168.1.10 | UDP | 3456 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 4: Outbound RTP
RTCP
Due to the nature of RTP the firewall MUST create a remote
destination IP address and port entry for RTCP the listening
port(the port MUST be one higher, and odd). A NAT entry MUST be
created to allow "transparent" RTCP communications when necessary.
In this example Destination IP 192.168.1.10 Destination port 3457
Protocol UDP.
For more information on RTP and RTCP refer to RFC 1889.
The following information SHOULD be added to the NAT table for RTCP
Communications:
+++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP Address | R Protocol | R Listening Port|
+++++++++++++++++++++++++++++++++++++++++++++++++++++
| 192.168.1.10 | UDP | 3457 |
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 5: Outbound RTCP
=================================================
F12 ACK UserA->NAT
------------ IP Header -------------------
Source IP Address: 10.1.1.221
Destination IP Address: 63.81.221.88
----------- SIP Message ------------------
ACK sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.221:5060
Route: <sip:UserB@192.168.1.10>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@10.1.1.221
CSeq: 1 ACK
=================================================
Note: the Route header is used to identify the next hop from the
proxy.
=================================================
F13 ACK NAT->NS
-------------- IP Header -----------------
Source IP Address: 192.168.221.1
Destination IP Address: 63.81.221.88
-------------- SIP Message --------------
ACK sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 192.168.221.1:5060 *
Route: <sip:UserB@192.168.1.10>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1 *
CSeq: 1 ACK
=================================================
When the ACK is received the NAT translation table for RTP SHOULD be
activated
NAT MUST Translate the IP Header for RTP/RTCP traffic traversing the
firewall.
The firewall MUST modify Via and Call-ID.
Upon receipt of the ACK the firewall MUST enable the pinholes for
RTP and RTCP, with the following rules created using the tables
created earlier:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP | R | R | G IP | G | G |
| Address |Protocol|List| Address |Protocol|Listening|
| | |Port| | | Port |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|192.168.1.10| UDP |3456|192.168.221.1| UDP | 49170 | RTP
|192.168.1.10| UDP |3457|192.168.221.1| UDP | 49171 | RTCP
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 6: RTP/RTCP
Note: The Source Port <regardless of direction> may be an ephemeral
port (1024 through 5000), any of the registered ports (1024-49151)
or up to 65535 depending on vendor implementation. The dynamic
access rules SHOULD specify that the source port be a wildcard.
Alternatively the incoming RTP/RTCP packets may be accepted based on
the state established by an outgoing packet.
=================================================
F14 ACK NS->UserB
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.1.10
-------------- SIP Message ---------------
ACK sip: UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route: <sip:UserB@there.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 1 ACK
=================================================
=================================================
F15 RTP UserA-->NAT
--------- IP Header -------------------------------------
Outbound
[IP Source Address: 10.1.1.221,
Destination IP Address: 192.168.1.10
UDP Source Port: ephemeral, Destination Port: 3456]
Inbound
[IP Source Address: 192.168.1.10,
Destination IP Address: 10.1.1.221
UDP Source Port: ephemeral, Destination Port: 49170]
--------------- RTP Header ------------------------------
RTP Data
=================================================
=================================================
F16 RTP NAT -->UserB
--------- IP Header -------------------------------------
Outbound
[IP Source Address: 192.168.221.1, Destination IP Address:
192.168.1.10]
UDP Destination Port: 3456 Source Port: ephemeral
Inbound
[IP Source Address: 192.168.1.10, Destination IP Address:
192.168.221.1]
UDP Destination Port: 49170 Source Port: ephemeral
--------------- RTP Header ------------------------------
RTP Data
=================================================
NAT translations for IP Headers should remain to allow RTP data
between UserA and UserB until the call is terminated.
NAT should maintain translation for SIP until a BYE, CANCEL or
timeout occurs
=================================================
F17 BYE UserA->NAT
-------------- IP Header ------------------
Source IP Address: 10.1.1.221
Destination IP Address: 63.81.221.88
-------------- SIP Message -----------------
BYE sip: UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.221:5060
Route: <sip:UserB@192.168.1.10>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@10.1.1.221
CSeq: 2 BYE
=================================================
UserA Hangs up.
=================================================
Note: CSeq has incremented because the user that initiated the
communication is the same user that is terminating the call. Also
note the Route header indicating the next hop, from the proxy.
The firewall should keep the pinholes active until a 200 OK is
received, or RTP transmission times out based on inactivity or a
preset timeout on the firewall due to a loss of network
connectivity.
=================================================
F18 BYE NAT->NS
-------------- IP Header -----------------
Source IP Address: 192.168.221.1
Destination IP Address: 63.81.221.88
--------------- SIP Message --------------
BYE sip: UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 192.168.221.1:5060 *
Route: <sip:UserB@192.168.1.10>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1 *
CSeq: 2 BYE
=================================================
=================================================
F19 BYE NS->UserB
-------------- IP Header -----------------
Source IP Address:63.81.221.88
Destination IP Address: 192.168.1.10
--------------- SIP Message ----------------
BYE sip: UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route:<sip:UserB@there.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 2 BYE
=================================================
=================================================
F20 200 OK USERB->NS
-------------- IP Header ----------------
Source IP Address: 192.168.1.10
Destination IP Address 63.81.221.88
------------- SIP Message ---------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 2 BYE
=================================================
=================================================
F21 200 OK NS->NAT
-------------- IP Header -------------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.1
------------- SIP Message ------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.221.1:5060
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@192.168.221.1
CSeq: 2 BYE
=================================================
=================================================
F22 200 OK NAT->UserA
-------------- IP Header -------------
Source IP Address: 63.81.221.88
Destination IP Address:10.1.1.254
--------------- SIP Message ----------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.221:5060 *
From: TheBigGuy <sip:UserA@customerA.com>
To: TheLittleGuy <sip:UserB@there.com>;tag=abcde
Call-ID: 1234500@10.1.1.221 *
CSeq: 2 BYE
=================================================
NAT SHOULD delete translation table entries for the SIP, RTP and
RTCP sessions (using the Call-ID and tag as the reference to this
session) for both inbound and outbound connections.
Firewall MUST close pinholes for inbound and outbound connections as
soon as the call is terminated.
Inbound SIP Through NAT Call Flows
Inbound Call Flow Illustration
UserA NAT NS UserB
10.1.1.221 192.168.221.1 63.88.221.88 192168.1.10
| | | |
| | |<--F1 INVITE-|
|<---F4 INVITE-----|<--F3 INVITE-| |
| | |---F2 100--->|
| | | |
|----F5 180------->|--F6 180---->| |
| | |--F7 180---->|
| | | |
|----F8 200 OK---->|--F9 200 OK->| |
| | |-F10 200 OK->|
| | | |
| | |<-F11 ACK----|
|<---F13 ACK-------|<-F12 ACK----| |
| | | |
|<--F14 2WAY RTP-->|<------F15 2WAY RTP ------>|
| | | |
|----F16 BYE------>|-F17 BYE---->| |
| | |--F18 BYE--->|
| | |<-F19 200 OK-|
|<---F21 200 OK----|<-F20 200 OK-| |
| | | |
Figure 3
Inbound Call Flow Detail
==========================================
F1 INVITE USERB->NS
------------ IP Header -------------------
IP Source Address: 192.168.1.10
IP Destination Address: 63.81.221.88
------------- SIP Message ----------------
INVITE sip:UserA@customerA.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheLittleGuy <sip:UserB@there.com>
To: TheBigGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
Contact: sip:UserB@192.168.1.10
Authorization:Digest username="UserB", realm="MCI WorldCom SIP",
nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="",
uri="sip:63.81.221.88",
response="b3f392f9218a328b9294076d708e6815"
Content-Type: application/sdp
Content-Length: 142
v=0
o=UserB 2890844526 2890844526 IN IP4 UserB.there.com
s=-
t=0 0
c=IN IP4 192.168.1.10
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
==========================================
User B prepares to receive data on port 49170 from the network
F1 shows an example of SIP utilizing the Authentication header for
authentication to the proxy using message digest algorithm. PGP and
S/MIME are also being developed as other possible scalable
authentication mechanisms.
==========================================
F2 Trying NS->UserB
-------------- IP Header ------------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.10
------------- SIP Message -------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheBigGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
==========================================
==========================================
F3 INVITE NS->NAT
------------ IP Header --------------------
IP Source Address: 63.81.221.88
IP Destination Address: 192.168.221.1
------------- SIP Message -----------------
INVITE sip:UserA@customerA.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
From: TheLittleGuy <sip:UserB@there.com>
To: TheBigGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
Contact: sip:UserB@192.168.1.10
Content-Type: application/sdp
Content-Length: 142
v=0
o=UserB 2890844526 2890844526 IN IP4 UserB.there.com
s=-
t=0 0
c=IN IP4 192.168.1.10
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
==========================================
The NS will perform a lookup for the location of UserA; in this case
it would be registered through the firewall.
The firewall should be configured to be listening on port 5060, the
default port for SIP but may be configured according to any custom
implementation parameters. The firewall may have a method to perform
internal hostname lookup based on SIP URI. When name is resolved NAT
SHOULD setup table entries to pass packets through to UserA.
One possible solution is that the firewall performs DNS lookup for
internal IP address of UserA, parsed from the Request URI:
UserA@customerA.com, replacing the "@" with a ".". The lookup would
yield internal host 10.1.1.221 and adds it to the NAT entry for this
session, including in the entry the Call-ID and tag, supplied by
UserB, to identify future SIP packets belonging to the session. NAT
then modifies the IP header Destination IP address of packet. This
is of course assuming that customerA wishes to utilize DNS naming
consistent with this method.
The firewall should prepare pinhole for remote RTP to User B on port
49170.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP Address | R Protocol | R Listening Port |
++++++++++++++++++++++++++++++++++++++++++++++++++++++
|192.168.1.10 | UDP | 49170 |
++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 7: Inbound RTP
The firewall MUST prepare RTCP pinhole for remote of 49170+1
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP Address | R Protocol | R Listening Port |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
| 192.168.1.10 | UDP | 49171 |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 8: Inbound RTCP
==========================================
F4 INVITE NAT->UserA
------------------ IP Header ----------
IP source address: 63.81.221.88
IP Destination Address: 10.1.1.221
----------------- SIP Message -----------
INVITE sip:UserA@customerA.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
From: TheLittleGuy <sip:UserB@there.com>
To: TheBigGuy <sip:UserA@customerA.com>;tag=abcde
Contact: sip:UserB@192.168.1.10
CSeq: 1 INVITE
Contact: sip:UserB@192.168.1.10
Content-Type: application/sdp
Content-Length: ...
v=0
o=UserB 2890844526 2890844526 IN IP4 UserB.there.com
c=IN IP4 192.168.1.10
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
==========================================
==========================================
F5 RINGING UserA->NAT
-------------- IP Header -----------------
Source IP Address: 10.1.1.221
Destination IP Address: 63.81.221.88
--------------- SIP Message -------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
==========================================
==========================================
F6 RINGING NAT->NS
-------------- IP Header -----------------
Source IP Address: 192.168.221.1
Destination IP Address: 63.81.221.88
-------------- SIP Message ---------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
==========================================
The following NAT entry SHOULD be created: 10.1.1.221, 5060, Call-
ID, tag, 192.168.221.1, 5060, Call-ID, tag
==========================================
F7 RINGING NS->UserB
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.1.10
-------------- SIP Message ---------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.221.1:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
==========================================
==========================================
F8 200 OK UserA->NAT
-------------- IP Header ------------------
Source IP Address: 10.1.1.12
Destination IP Address: 192.168.221.1
-------------- SIP Message ----------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Contact: sip:UserA@10.1.1.12
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 148
v=0
o=UserA 2890844527 2890844527 IN IP4 UserA.there.com
s=-
t=0 0
c=IN IP4 10.1.1.12
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
==========================================
UserA prepares to listen on port 3456
The firewall MUST modify IP, port, SIP and via port if necessary,
and SDP c=, and m=,
NAT should create an outbound translation.
Firewall should prepare pinholes for inbound RTP/RTCP IP and port
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP | R | R | G IP | G | G |
| Address |Protocol| Port| Address |Protocol|Port|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|192.168.1.10| UDP |49170|192.168.221.1| UDP |3456| RTP
|192.168.1.10| UDP |49171|192.168.221.1| UDP |3457| RTCP
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 9: NAT RTP/RTCP
==========================================
F9 200 OK NAT->NS
-------------- IP Header -----------------
Source IP Address: 192.168.221.1
Destination IP Address: 63.81.221.88
-------------- SIP Message --------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Contact: sip:UserA@192.168.221.1 *
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 142 *
v=0
o=UserA 2890844527 2890844527 IN IP4 UserA.there.com
s=-
t=0 0
c=IN IP4 192.168.221.1 *
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
==========================================
==========================================
F10 200 OK NS->UserB
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.1.10
-------------- SIP Message ---------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Contact: sip:UserA@192.168.221.1
Call-ID: 12345600@192.168.1.10
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 142
v=0
o=UserA 2890844527 2890844527 IN IP4 UserA.there.com
s=-
t=0 0
c=IN IP4 192.168.221.1
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
==========================================
==========================================
F11 ACK USERB->NS
-------------- IP Header -----------------
Source IP Address: 192.168.1.10
Destination IP Address: 63.81.221.88
-------------- SIP Message ---------------
ACK sip:UserA@here.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Route: <sip:UserA@192.168.221.1>
Call-ID: 12345600@192.168.1.10
CSeq: 1 ACK
==========================================
==========================================
F12 ACK NS->NAT
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.1
-------------- SIP Message ---------------
ACK sip:UserA@here.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
Call-ID: 12345600@192.168.1.10
CSeq: 1 ACK
==========================================
Upon receipt of ACK, NAT translation MUST be activated. Receipt of
ACK firewall MUST enable pinholes using the following rules created
from SDP information.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| R IP | R | R | G IP | G | G |
| Address |Prot|List.| Address |Protocol|Listening|
| | |Port | | | Port |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|63.81.221.88| UDP|49170|192.168.221.1| UDP | 3456 |RTP
|63.81.221.88| UDP|49171|192.168.221.1| UDP | 3457 |RTCP
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table 10 RTP/RTCP
Note: The Source Port will be an ephemeral port (Between 1024 and
65536). Source port could be a wildcard, and may be accepted if ACK
bit set (in the case of TCP), or can be added after first packet
received indicating source port, depending on the stateful
mechanisms employed.
==========================================
F13 ACK NAT->UserA
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address: 10.1.1.221
-------------- SIP Message ---------------
ACK sip:UserA@customerA.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.1.10:5060
From: TheBigGuy <sip:UserB@there.com>
To: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Record-Route: <sip:UserA@customerA.com;maddr=63.81.221.88>
Call-ID: 12345600@192.168.1.10
CSeq: 1 ACK
==========================================
==========================================
F14 RTP UserA-->NAT
--------- IP Header -------------------------------------
Outbound
[IP Source Address: 10.1.1.221,
Destination IP Address: 192.168.1.10
UDP Source Port: ephemeral, Destination Port: 49170]
Inbound
[IP Source Address: 192.168.1.10,
Destination IP Address: 10.1.1.221
UDP Source Port: ephemeral, Destination Port: 3456]
--------------- RTP Header ------------------------------
RTP Data
==========================================
==========================================
F15 RTP NAT -->B
--------- IP Header -------------------------------------
Outbound
[IP Source Address: 192.168.221.1, Destination IP Address:
192.168.1.10
UDP Source Port: ephemeral, Destination Port: 49170]
Inbound
[IP Source Address: 192.168.1.10, Destination IP Address:
192.168.221.1
UDP Source Port: ephemeral, Destination Port: 3456]
--------------- RTP Header ------------------------------
RTP Data
==========================================
User A Hangs Up with User B. */
==========================================
F16 BYE UserA->NAT
-------------- IP Header -----------------
Source IP Address: 10.1.1.221
Destination IP Address: 63.81.221.88
-------------- SIP Message ---------------
BYE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.221:5060
Route: <sip:UserB@192.168.1.10>
To: TheBigGuy <sip:UserB@there.com>
From: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 BYE
==========================================
==========================================
F17 BYE NAT->NS
-------------- IP Header -----------------
Source IP Address: 192.168.221.1
Destination IP Address: 63.81.221.88
-------------- SIP Message ---------------
BYE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 192.168.221.1:5060 *
Route: <sip:UserB@192.168.1.10>
To: TheBigGuy <sip:UserB@there.com>
From: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 BYE
==========================================
==========================================
F18 BYE NS->UserB
-------------- IP Header -----------------
Source IP Address:63.81.221.88
Destination IP Address: 192.168.1.10
-------------- SIP Message ---------------
BYE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
Record-Route: <sip:UserB@there.com;maddr=63.81.221.88>
To: TheBigGuy <sip:UserB@there.com>
From: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 BYE
==========================================
==========================================
F19 200 OK USERB->NS
-------------- IP Header -----------------
Source IP Address: 192.168.1.10
Destination IP Address 63.81.221.88
-------------- SIP Message ---------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 63.81.221.88:5060
Via: SIP/2.0/UDP 192.168.221.1:5060
To: TheBigGuy <sip:UserB@there.com>
From: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 BYE
==========================================
==========================================
F20 200 OK NS->NAT
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address: 192.168.221.1
-------------- SIP Message ---------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.221.1:5060
To: TheBigGuy <sip:UserB@there.com>
From: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 BYE
==========================================
==========================================
F21 200 OK NAT->UserA
-------------- IP Header -----------------
Source IP Address: 63.81.221.88
Destination IP Address:10.1.1.221
-------------- SIP Message ---------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.221:5060 *
To: TheBigGuy <sip:UserB@there.com>
From: TheLittleGuy <sip:UserA@customerA.com>;tag=abcde
Call-ID: 12345600@192.168.1.10
CSeq: 1 BYE
==========================================
Firewall MUST close RTP pinholes in both directions and delete NAT
entries for SIP, RTP and RTCP (using the Call-ID and To: tag as the
reference point for these flows)
References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, March 1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, March 1999.
[3] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
Request for Comments (Proposed Standard) 2327, Internet Engineering
Task Force, April 1998
[4] P. Srisuresh, J. Kuthan, and J. Rosenberg, " Middlebox
Communication Architecture and framework", Internet Engineering Task
Force Internet-Draft, Work in Progress, 2001.
[5] Egevang, K. and P. Francis, "The IP Network Address
Translator",RFC 3022, January 2001.
[6] Srisuresh, P. and M. Holdrege, "NAT Terminology and
Considerations", RFC 2663, August 1999.
[7] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP:A
Transport Protocol for Real-Time Applications " Request for
comments(Standards Track) 1889, Network Working Group Audio-Video
Transport Working Group, January 1996
[8] H. Shulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", Internet Engineering
Task Force, January 1996
Authors' Addresses
Christopher A. Martin
WorldCom
400 International
Richardson, Texas 75081
christopher.a.martin@wcom.com
Alan Johnston
WorldCom
100 S. 4th Street
St. Louis, Missouri 63104
alan.johnston@wcom.com
Copyright Notice
"Copyright (C) The Internet Society 2000. 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.