Midcom Working Group C. Martin Internet Draft A. Johnston Expires: August 2001 WorldCom February 2001 Category: Informational SIP Through NAT Enabled Firewall Call Flows draft-martin-midcom-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 transparent SIP NAT/firewall proxy 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......................................................2 Overview of NAT...................................................2 Assumptions.......................................................3 Security Considerations and Implications..........................4 Transparency vs. SIP Proxy Functionality..........................4 High Level Tasks..................................................4 LEGEND 5 Outbound SIP Through NAT Call Flow Scenario.......................6 Inbound SIP Through NAT Call Flows...............................19 References.......................................................30 Martin and Johnston Informational [Page 1] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 Authors' Addresses...............................................31 Introduction This document is intended to define the basic minimum requirement for the operation of SIP through NAT enabled firewalls; both call flow, as well as firewall and NAT functionality will be addressed. The underlying intent is to offer guidance and identify specific considerations to the global community for the development of compliant products 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 information exchange necessary between the Middlebox (NAT and firewall) and the MIDCOM agent (transparent SIP proxy) [4]. 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 with NAT enabled using one global IP address for NAT, we discuss a minimum requirement for transparent modifications to SIP packets. "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 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 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 must modify the IP checksum and the TCP checksum. Remember that TCPs checksum also Martin & Johnston Informational [Page 2] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 promoting the promotion of SIP signaling. 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 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. If UserA wishes to place a SIP phone call they must go through the firewall, as seen in Figure 1. 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 2. 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 Martin & Johnston Informational [Page 3] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 with NAT-like functionality, rather than SIP proxy functionality, 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 For 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. For 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 Martin & Johnston Informational [Page 4] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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] . The firewall MUST create a NAT table entry for RTP that requires IP address port translation of local and global address. There MUST 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]. For 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. For 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 is through a firewall implementation with NAT enabled, utilizing one external global IP address that represents all internal IP addresses, in combination with 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. LEGEND UserA = 10.1.1.221 Local Address = (L) UserB = 192.168.1.10 Global Address = (G) SIP Proxy Server (NS)= 63.81.221.88 Global Remote Address = (R) Firewall(NAT) global address = 192.168.221.1 Each Packet is enclosed in the following manner: "=============================================" Martin & Johnston Informational [Page 5] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 1 Outbound Call Flow Detail ============================================= F1 INVITE USERA->NAT ------ IP Header --------------------------- Martin & Johnston Informational [Page 6] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheLittleGuy ;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 a firewall that implements NAT. Note: Call-ID and tag, SHOULD be used, in addition to the To:, From:, and Call-ID fields, as specified in the SIP specification[1], to identify this session. Call-ID alone can not uniquely identify a session for forking or transfers for example, as the same Call-ID may be the same for each session within the same timeframe as a boot-up or recycle of the SIP client. =============================================== 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 Martin & Johnston Informational [Page 7] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 Via: SIP/2.0/UDP 192.168.221.1:5060 * From: TheBigGuy To: TheLittleGuy ;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 MUST create an IP Header and transport header translation entry mapping UserA local IP address to the global address of the firewall, as necessary. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 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| | | | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ All subsequent packets will use this mapping for SIP communications. Optionally some solutions may assign a 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 plus tag SHOULD 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. Martin & Johnston Informational [Page 8] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 | ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 | ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 To: TheLittleGuy 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 Martin & Johnston Informational [Page 9] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheLittleGuy 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: From: TheBigGuy To: TheLittleGuy 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 the proxy, which takes on the form of Request URI, and includes maddr= indicating the proxy address. ================================================= F6 RINGING UserB->NS ------------ IP Header ------------------- Martin & Johnston Informational [Page 10] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheLittleGuy ;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 To: TheLittleGuy ;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 To: TheLittleGuy ;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. Martin & Johnston Informational [Page 11] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 ================================================= 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: From: TheBigGuy To: TheLittleGuy ;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: From: TheBigGuy To: TheLittleGuy ;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 Martin & Johnston Informational [Page 12] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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: From: TheBigGuy To: TheLittleGuy ;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. Content-Length does not require modification because SDP does not require changes for inbound initiated sessions. For RTP, Firewall MUST determine the remote IP address and remote listening port values from SDP c= and m=. Martin & Johnston Informational [Page 13] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 This SHOULD be added to the NAT table created in F2, based on Call-ID and tag. The following information SHOULD be added to the NAT table for RTP Communications: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP Address | R Protocol | R Listening Port | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 192.168.1.10 | UDP | 3456 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 | +++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================= 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: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@10.1.1.221 CSeq: 1 ACK ================================================= Note the Route header used to identify the next hop from the proxy. ================================================= F13 ACK NAT->NS Martin & Johnston Informational [Page 14] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 -------------- 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: From: TheBigGuy To: TheLittleGuy ;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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Note: The Source Port may be an ephemeral port (i.e., 1024 through 65536). 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 --------------- Martin & Johnston Informational [Page 15] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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: From: TheBigGuy To: TheLittleGuy ;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 Destination Port: 3456 Source Port: ephemeral Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 10.1.1.221] UDP Destination Port: 49170 Source Port: ephemeral --------------- 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 translates IP Headers for RTP data between UserA and UserB until the call is terminated. NAT MUST maintain translation for SIP until a BYE, CANCEL or timeout occurs ================================================= F17 BYE UserA->NAT -------------- IP Header ------------------ Source IP Address: 10.1.1.221 Martin & Johnston Informational [Page 16] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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: From: TheBigGuy To: TheLittleGuy ;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 MAY 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: From: TheBigGuy To: TheLittleGuy ;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 Martin & Johnston Informational [Page 17] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 --------------- 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: From: TheBigGuy To: TheLittleGuy ;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 To: TheLittleGuy ;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 To: TheLittleGuy ;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 Martin & Johnston Informational [Page 18] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheLittleGuy ;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 2 Martin & Johnston Informational [Page 19] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheBigGuy ;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->NAT -------------- IP Header ------------------ Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 ------------- SIP Message ------------------- Martin & Johnston Informational [Page 20] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheBigGuy ;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: From: TheLittleGuy To: TheBigGuy ;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 MUST be listening on port 5060, the default port for SIP. 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 Martin & Johnston Informational [Page 21] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 MUST 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 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++ ========================================== 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: From: TheLittleGuy To: TheBigGuy ;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 Martin & Johnston Informational [Page 22] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheLittleGuy ;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 To: TheLittleGuy ;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 Martin & Johnston Informational [Page 23] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 -------------- SIP Message --------------- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy ;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: From: TheBigGuy To: TheLittleGuy ;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 MUST create an outbound translation. Firewall MUST prepare pinholes for inbound RTP/RTCP IP and port +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP | R | R | G IP | G | G | | Address |Protocol| Port| Address |Protocol|Port| Martin & Johnston Informational [Page 24] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ========================================== 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: From: TheBigGuy To: TheLittleGuy ;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: From: TheBigGuy To: TheLittleGuy ;tag=abcde Contact: sip:UserA@192.168.221.1 Martin & Johnston Informational [Page 25] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 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 To: TheLittleGuy ;tag=abcde Route: 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 To: TheLittleGuy ;tag=abcde Record-Route: Call-ID: 12345600@192.168.1.10 CSeq: 1 ACK ========================================== Martin & Johnston Informational [Page 26] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 Upon receipt of ACK, NAT translation MUST be activated. Upon 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Note: The Source Port will be an ephemeral port (Between 1024 and 65536). Source port SHOULD 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 To: TheLittleGuy ;tag=abcde Record-Route: Call-ID: 12345600@192.168.1.10 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 Destination Port: 49170 Source Port: ephemeral Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 10.1.1.221] UDP Destination Port: 3456 Source Port: ephemeral Martin & Johnston Informational [Page 27] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 --------------- RTP Header ------------------------------ RTP Data ========================================== ========================================== F16 RTP NAT -->B --------- IP Header ------------------------------------- Outbound [IP Source Address: 192.168.221.1, Destination IP Address: 192.168.1.10] UDP Destination Port: 49170 Source Port: ephemeral Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 192.168.221.1] UDP Destination Port: 3456 Source Port: ephemeral --------------- 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: To: TheBigGuy From: TheLittleGuy ;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 Martin & Johnston Informational [Page 28] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 Via: SIP/2.0/UDP 192.168.221.1:5060 * Route: To: TheBigGuy From: TheLittleGuy ;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: To: TheBigGuy From: TheLittleGuy ;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 From: TheLittleGuy ;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 Martin & Johnston Informational [Page 29] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 -------------- SIP Message --------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.221.1:5060 To: TheBigGuy From: TheLittleGuy ;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 From: TheLittleGuy ;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. Martin & Johnston Informational [Page 30] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 [5] Egevang, K. and P. Francis, "The IP Network Address Translator", RFC 1631, May 1994. [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 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. Martin & Johnston Informational [Page 31] Internet Draft SIP Through NAT Enabled Firewall Call Flows Feb 2001 Martin & Johnston Informational [Page 32]