Network Convergence and the NAT/Firewall Problems Victor Paulsamy Zapex Technologies, Inc. Mountain View, CA 94043 Samir Chatterjee School of Information Science Claremont Graduate University Claremont, CA 91711-6190 {samir.chatterjee@cgu.edu} Abstract: Voice over IP technology is fueling the rapid growth on network convergence and we are seeing the successful deployment of converged networks within enterprises. However, most enterprises today sit behind Firewalls and also use private IP addressing behind NATs (Network Address Translators). These NATs and Firewalls cause significant problems for multimedia over IP to work and function properly. There are presently two standards for VoIP signaling: H.323 (from ITU-T) and SIP (Session Initiation Protocol from IETF). In this paper we present the details of the problems and issues associated with NATs/Firewalls and then survey some ways to solve this problem for SIP. There is no single best solution yet. However, this paper discusses how such a simple and elegant solution can be built. This problem remains a significant obstacle for the successful adoption of convergence as security has become even more important to enterprises than adoption of emerging technologies. 1. Introduction The problem of firewall and NAT traversal is particularly troublesome for interactive multimedia communications such as those established and managed by SIP [1] and H.323. The motivation for this paper is due to a plethora of problems enumerated and the multitude of solutions developed to solve them. The big picture is not portrayed in one single place. Thus, this work is intended to fill that void and to motivate a single neat solution to the problems posed by NAT/firewall boxes. We discuss a variety of scenarios including service providers, enterprises, residential, nats alone, nats and firewalls, firewalls alone, in the paper. 2 Definitions 2.1 NAT From RFC 2663[2], Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. 2.2 Firewalls From [3] A firewall is a device with two interfaces - one on the "inside" and one on the "outside". Its function is generally to protect devices on the inside from those on the outside, and to sometimes prevent users on the inside from connecting to, or accessing, services on the outside. 3. Types of NATs Four types of NATs are described in [4]. Full Cone: All requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
Restricted Cone: All requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike full cone NAT, an external host with source IP address X can send a packet to the internal host only if the internal host had sent a packet to IP address X. Port Restricted Cone: Like the restricted cone but with restricted port numbers. An external host with source IP address X and source port Y can send a packet to the internal host only if the internal host had sent a packet to address X and port Y. Symmetric: All requests from the same internal IP address and port to a specific destination IP address and port are mapped to the same external IP address/port pair. If the same host were to send a packet with the same source port but to a different destination, a different mapping is used. Furthermore, only the external host that that receives a packet can send a UDP packet back to the internal host. 4. An Example This would be used as a running example throughout the paper. Internal host, say, A that is residing behind a NAT, for instance, wishes to initiate a session to the external host, say, B. Host A sends a packet with source IP address 10.1.1.1 and port 4540. The NAT translates the source address/port pair to 68.44.20.1:7000 and forwards the packet towards the external host B whose IP address is 220.220.1.2 and port is 5500.In case of a full-cone NAT, even if host A sends a packet from 10.1.1.1:4540 to another host C (IP address 144.16.1.2:8888), the translated external address will be same as 68.44.20.1:7000.Any host on the Internet can reach A by sending a packet to the mapped global address, 68.44.20.1:7000. 5. Why NAT/Firewall is Problematic for multimedia SIP Sessions? Without going into details, an example illustrates the problems. From the previous example: A s B. The request looks like this (shown partially for brevity): sip:userb@domain.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540 This goes through the NAT that rewrites the source IP address and port to 68.44.20.1:7000. For B, the source IP address is different from the value in Via: header (10.1.1.1) hence captures it in received parameter. sip:userb@domain.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1 For UDP the response is sent to the source address the request came from but to the port in the topmost via header. In other words, the response will be sent to 68.44.20.1:4540. However, the mapping at the NAT is 68.44.20.1:7000. Thus the packet will be dropped by the NAT. For TCP, the response is sent over the same connection the request arrived on. This ensures that the response reaches proper destination. Firewalls do not let UDP packets in or out. A proxy could control the firewall to open/close pinholes. Moreover voice and video sessions use dynamic random ports, which are blocked by firewalls. 6. NAT Firewall Solutions The first solution is to have a packet filtering firewall/nat controlled by a proxy. The second solution proposes to reconfigure firewall/nat. The third one establishes a TLS secure connection, runs SIP over that connection and runs bi-directional RTP over UDP as well. 6.1. Architectural Solution Two possible architectural ways for traversing NATs and firewalls have been discussed in [3]. 6.1.1 Co-location of Proxy and Firewall/NAT By co-locating SIP proxy with firewall/nat, the proxy can have direct control over it through internal API. This makes it the ideal solution for the external services configuration (SIP provider is not same as the ISP. The user makes use of external SIP provider for SIP services). This solution has the drawback of bothering firewall with an application layer protocol. The firewall/nat should be aware of all the applications that get deployed within the enterprise network and clearly this is difficult to manage and support.
6.1.2. Firewall/NAT Controlling Proxy An alternative solution is to segregate proxy and firewall/nat so that the application information can be externalized. A control protocol is needed for proxy to communicate with firewall/nat, the opening and closing of pinholes for media stream. 6.1.3. Registration Registrations can leave the network when a user wants all his calls forwarded to the network he is visiting or when the user has setup external forwarding service. Registrations are processed when arriving externally if they are authenticated and come from a known user of the network. 6.1.4. Initiating a Session The proxy extracts ports and IP addresses for all media from the and remembers the SDP [5] as well. The proxy notes address and port for accepted media from the response and forwards the response towards the client. The proxy then opens holes for media. If the contained IP address A and port B for some media stream, and if the contained IP address C and port D, the firewall/proxy will allow UDP packets from outside to inside if they are destined for address A and port B. UDP packets from inside to the outside are allowed if they are destined for address C and port D. 6.1.5. Receiving an invitation to a Session For internal services configuration, handling of an incoming call is opposite to that of an outgoing call. For external services configuration, the incoming call handling is very similar to that of the outgoing call. 6.1.6. Media Flow As soon as a response arrives at the inside proxy, it opens up the pinholes for media to flow from outside to inside and back. 6.1.7. Terminating a Session A SIP call is terminated by BYE message. Holes in the firewall are closed on receipt of the response () for the BYE message. In the event of an abrupt termination, for e.g., one of the SIP entities crashed in the middle of a session or did not care to send BYE while closing a session, media pinholes at the firewall can safely be closed when a session timer [6] fires. 6.2. Configuration Solution [7] handles SIP signaling and media flow by reconfiguring firewall/nat. The design is based on a firewall with three interfaces: the first one connects SIP agents within the firewall, the second connects the public Internet and the third interface connects SIP and RTP proxies in a demilitarized zone (DMZ). 6.2.1. Initiating a Session SIP Agent1 is inside the firewall and Agent2 is outside (see Fig. 1). An sent by Agent1 to Agent2. The SIP proxy copies the SDP in the into a MGCP command and then orders the RTP proxy to create a connection towards Agent1. To start with, the RTP proxy should not forward media stream and hence the connection mode is inactive. The RTP proxy creates a connection and returns its SDP and a relay code in a back to the SIP proxy. The SIP proxy orders another connection towards Agent2 by specifying the relay code but with out giving SDP as it does not have the SDP of Agent2 yet. Since the relay code is specified, the RTP proxy creates the corresponding port and sets up the relay between the newly created ports and the previously set up ports. The RTP proxy then returns the new ports and IP address in a message. The SIP proxy copies the returned SDP parameters into the and sends it out to Agent2. The Agent2 can set up a connection with the RTP proxy. When the user accepts the call, the SIP proxy orders the RTP proxy to modify its connection towards Agent2 by giving it the SDP in the response. The RTP proxy modifies the connection and sends back a. The SIP proxy again orders to modify the connection, however, this time towards Agent1. After modifying the connection according to the new SDP, the RTP proxy responds with a message. This SDP message is copied into the SIP message and sent to Agent1. Agent1 sends back to Agent2 via the SIP proxy. The SIP proxy now orders the RTP proxy to open up the RTP traffic by setting up the connection mode as sendrecv. A message is sent in response to the mode change. The SIP proxy now relays the to Agent2. Agent1 and Agent2 can now send and receive media through the RTP proxy.
6.2.2. Terminating a Session Upon receipt of for BYE, the SIP proxy orders the RTP proxy to delete the connections. After deletion, the RTP proxy responds with a message for each delete command. This solution also works for other protocols like H.323, Real Audio, etc., that wish to open and close holes in the firewall. Interestingly, any kind of traffic can flow through it. 6.3. SIP over TLS Solution This solution [8] does not require changes to firewall/nat devices or to their configurations. SIP is run over a TLS (Transport Layer Security) secure channel. The network architecture for this solution is shown in Figure 2. 6.3.1. Initiating a Session The simplest solution is to use a TCP connection to send out and to receive the response over the same connection. In the case of firewall, the connection starts out with the caller initiating a TLS connection on port 443 with the proxy X. Once the connection is secured, the caller sends SIP messages over it. The same connection is used for responses to be sent to the caller by the proxy X. The connection is kept open to avoid re-initiation of the TLS connection for every outgoing call. 6.3.2. Receiving an Invitation to a Session The callee sends both REGISTER and its refresh messages over an open TLS connection. When a call from proxy X arrives, the request will be forwarded over the existing connection. However, this will work only if the callee is able to unambiguously figure out the IP address it is bound to. To resolve finding out the correct IP addresses, it is proposed that, a unique host name value be reserved ("jibufobutbmpu"; [8] has the history of the name). When the callee REGISTERs using "jibufobutbmpu" as the host name (TLS connection goes over NAT), the private IP address is replaced with a global one and the port is changed to some other value. Proxy Y then stores the parameters (address, port and transport) of the incoming connection in a table referencing the TLS connection; it also updates the Contact header. When an incoming comes to the proxy Y, it looks up in the registration database, extracts the Contact and then it proxies the request to the user. The proxy checks to see if an open connection exist; if it exists, the request is proxied over that connection. 6.3.3. Media Flow The media over TLS or TCP is indicated using the keyword RTP/AVP-TLS in SDP. The caller also makes use of direction tag [9] in SDP, advertising whether or not it is behind a firewall/nat. The arrives at the proxy X. It knows that a RTP forwarder has to be made use of. The proxy checks the tag to see if it is active. If the tag is active, the proxy allocates a port and IP address from the RTP forwarder; say, address port pair as A. The proxy changes the tag to "both" and forwards the request. The request is then forwarded to the callee after rewriting the SDP to A. Eventually the response comes from the proxy Y. Proxy X examines the response to check the direction tag. If the tag is "active" and if the original request contained a tag of active but modified to "both" or "passive", the proxy X allocates another port and IP address from the RTP forwarder; say, B. This is because both the caller and the callee are behind firewall/nat boxes and RTP forwarder has to be made use of. Now the proxy creates a binding in the RTP forwarder for A and B. The address port pair B is placed in the SDP and forwarded to the caller. There are four distinct cases in which the connection can be opened: Both caller and callee are behind the firewall/nat. Both attempt to open a connection and they succeed. The media sent by the caller goes to B. The data in B is then forwarded to A. Similarly the media flows from the callee to caller. When the caller is behind the firewall/nat but not the callee the proxy allocates port and IP address from the RTP forwarder. The SDP in the response contains a direction tag of "both" or "passive" and hence the previously allocated port is closed. The callee tries to open a connection with the port in the RTP forwarder. Since the port is not in use the connection cannot be established. The caller initiates a TLS connection with the callee. The media stream is exchanged over this connection.
Caller is not behind the firewall/nat but the callee is. The outgoing SDP is not modified nor is the incoming SDP. The callee tries to open a connection and it succeeds. Both the caller and the callee are not behind the firewall/nat. One or both will successfully open the connection. The rules outlined in [6] are followed regarding the usage and closing of an idle connection. When only one of the two users is behind a NAT, bi-directional RTP is run over UDP. In this, one side initiates a connection and the other side accepts it, like TCP. The caller sitting behind a NAT sends an with direction tag active. The callee sends a with direction tag passive. The caller then sends the first RTP packet to the callee. The RTP packet goes through the NAT and has its source address and port rewritten. After receiving the first RTP packet, the callee sends its RTP packet to the source address and port from which this packet has been received, using the same socket. This packet then traverses through the NAT and has its destination address, port rewritten back to that of the caller. Whether one party or both the parties are behind the firewall, the solution for firewall is same as that of NAT, except that, RTP is carried over TLS or TCP, because UDP will not go through the firewall. 7. SIP Extension for Symmetric Response Routing The extension [10] defines rport parameter for Via header which enables a client to request a server to send the response back to the source address and port the request was sent from. A UAC sends an with rport parameter from source IP address 10.1.1.1 and port 4540: sip:userb@domain.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport As this request is natted, the private IP address is replaced with a routable, 68.44.20.1 and the port is rewritten to 7000. The proxy populates the rport parameter appropriately and forwards the request which looks like: sip:userb@domain.com SIP/2.0 Via: SIP/2.0/UDP proxy.domain.com Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=7000 The proxy strips its Via and then forwards the request to IP address 68.44.20.1 and port 7000: SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=7000 The NAT correctly forwards the response to source IP 10.1.1.1 at port 4540 because it maintains the address binding. This response is received at the UAC. 7.1. Refresh Intervals NAT binding must be kept alive for response routing. Most UDP bindings have timeout of 1 minute. Non- transactions do not have problems. For transactions, the request has to be sent once in every 20 seconds, even after a provisional response, to keep the binding alive. 8. Discovery Protocols 8.1. STUN Simple Traversal of UDP Through NATs [4] (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. 8.2. TURN Traversal Using Relay NAT [11] (TURN) is a simple protocol that allows for an element behind a NAT or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. 9. NAT Scenarios The draft [12] enumerates various scenarios that arise, and for each, it points to some of the existing solutions and explains how it works. 9.1. Scenario: Residence with single NAT 9.1.1. Solution I
To enable service the user has to figure out the public IP address assigned to the router by the provider, the private IP address of phone assigned by the DHCP server, enable DMZ host configuration on the residential NAT and set the host as phone. Configure the SIP phone to use the public IP (router address) in its SIP and SDP messages. Proxy sends the reply to the source IP address and the port in the Via header. This arrives at the NAT. Since the NAT doesn t have any binding for this address, it rewrites the address and forwards the packet to the DMZ host where the phone is listening. Receiving media works the same way. Incoming calls reception works similarly when the Contact header of REGISTER lists the public address of the NAT. 9.1.2. Solution II: Stun in Client Another solution for this scenario would be to upgrade the SIP client to support STUN, and optionally the SIP and SDP extensions for NAT and SDP extension for comedia. This solution also requires the service provider to deploy STUN server. Processing depends on the type of NAT a client is behind. 9.1.2.1. Full Cone or Restricted Cone NATs 9.1.2.1.1. Step 1: Registration A client finds out the IP address and port using. This address is used in the Contact header to register with a registrar and sends the REGISTER request preferably over TCP. If TCP is not available, UDP will be used. In that case, the server has to support rport, otherwise, the response cannot go through the NAT. 9.1.2.1.2. Step 2: Initiating a Session The client queries the STUN server twice to get the address for RTP and RTCP. The RTP and RTCP ports are no longer consecutive hence RTCP attribute in SDP [13] has to be used to support this. In addition, direction attribute has to be supported too. In case of UDP, support for symmetric RTP is mandated because just in case if the peer is behind NAT things will work correctly. The sequences are limned in Figure 3. 9.1.2.1.3. Step 3: Receiving an Invitation to a Session When the invitation arrives at the client, it queries the STUN server to find out the address for both RTP and RTCP. The client also checks the direction attribute in SDP to determine the initiator of the media stream, if it supports comedia extension. The client sends the response back to the proxy and is relayed from there. This is depicted in Figure 4. 9.1.2.1.4. Step 4: Media Flow The user whose direction attribute is active will initiate the media flow. The RTP packet goes through the NAT and arrives at the destination. Upon its arrival the passive user will initiate media transmission. In case of UDP, the media is sent to the source address and port the media came from (symmetric RTP). This media flow may not work for restricted cone type NATs because the NATs will allow incoming packets only if the client has previously sent media to the remote side. The most natural way to handle this problem is to respond to a=direction:both with a=direction:both. By doing this both the sides will initiate media. When both the sides send media, NATs would be primed to receive media from the remote side. Ofcourse, both the sides may not be able to start sending media simultaneously and hence first few packets may not traverse NATs initially. 9.1.2.2. Symmetric NATs 9.1.2.2.1. Step 1: Registration The client includes in its Contact header an address allocated by TURN server along with a Translate header. It is recommended that TCP address be allocated from the TURN server. The client sends the REGISTER request to the proxy using TCP. 9.1.2.2.2. Step 2: Initiating a Session This is similar to that of non-symmetric NATs. If the other participant is not behind the NAT or full-cone or restricted cone NAT, using TURN server as a relay can be avoided so, the client includes a=direction:active attribute. 9.1.2.2.3. Step 3: Receiving an Invitation to a Session Receiving an invitation is same as that for the non-symmetric case described earlier. However,
the client uses a=direction:active in the response if it received passive or both in the request. Another difference would be when the proxy doesn t support SIP extension for NAT. In that case, the Translate header will be ignored and the address in the Contact header will be used. Since the Contact address obtained was allocated by the TURN server the message flows through the server. The initial will cause the proxy to open a TCP connection to the TURN server. From this point forward, the client has to reregister using this connection to keep it alive. This is depicted in Figure 5. 9.1.2.2.4. Step 4: Media Flow Consider the case where the caller is behind a full cone NAT, and the callee is behind a symmetric NAT. The SDP from the caller will have a=direction:both attribute. The callee responds with a=direction:active. The callee sends media to the caller using a socket different that the one allocated from the TURN server. Since the address is never used, the binding will expire at the TURN server for this address. When the caller is behind a restricted cone NAT, the includes a=direction:active attribute. The callee who is behind a symmetric NAT responds with a=direction:passive. In this case, the caller sends media to the address given by the callee. Thus, the media flows to the TURN server and relayed to the callee. The callee sends media back to the caller through the TURN server. 9.1.3. Solution III: STUN in B2BUA The solution II assumes that the client is upgraded to support STUN in addition to a plethora of extensions. Instead, it is affordable to package all of them in an intermediary called B2BUA in SIP terminology that runs a piece of software within the residence. The B2BUA server receives all the requests from the clients, acts as a STUN client to get the public IP address, modifies the request appropriately and forwards the request to the proxy. For the purpose of discussion, the B2BUA server is called STUN Agent. Typically, the agent sits between SIP phones and router and will play the role of an outbound proxy for the SIP phones. 9.1.3.1. Step 1: Registration The phone sends out a normal REGISTER request that looks like: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.1 Contact: sip:user@10.0.1.1:5060 The agent receives the request and queries the STUN server to find out the address. It then rewrites the request to reflect the IP address it learnt from the. The resulting message looks like: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5678 Contact: sip:user@1.2.3.4:5678 Translate: sip:user@1.2.3.4:5678 The agent forwards this message to the proxy through the NAT and the response reaches the agent through NAT. The agent changes the IP addresses in the response back to the private ones before forwarding it to the client. It is important to note that the STUN query needs to be done only for the first REGISTER request. The same binding can be reused for subsequent requests so long as the user name is unique in the Contact header in each registration from different SIP phones. 9.1.3.2. Step 2: Initiating a Session This case is similar to that of STUN in client (9.1.2.1.2) except that a STUN Agent queries a STUN server and when the response has no direction or RTCP attributes, media flows between phones, directly. If the callee has included RTCP attribute, the agent rewrites the SDP giving its address and forwards it to the client. The client sends the media to the given address; in this case it happens to be the agent. The agent then relays the media to the right address. The agent sends the RTP packet from the port it queried the STUN server for RTP media and to send RTCP packet it makes use of the RTCP query port. The media in the reverse direction flows to the ports advertised in the SDP, reaches the NAT, the NAT forwards it to the agent using its binding and relayed to the client from there. In short, the media flows through the STUN agent in and out of the client. 9.1.3.3. Step 3: Receiving an Invitation to a Session
Receiving an invitation parallels the outgoing. If the incoming request calls for the usage of RTCP and direction attribute, the STUN agent rewrites the incoming request and rewrites the response from the client after querying the STUN server for RTP and RTCP addresses in addition to the Contact header. In this case, the agent relays the media to the client. 10. Conclusion This paper attempts to survey possible solutions that are out there in one central place and comments on these approaches. Since security has become paramount to enterprises today, finding a simple solution to NAT/Firewall issue is critical to the wider adoption of SIP-based converged services. Bibliography 1. J.Rosenberg, et.al., "SIP: Session Initiation Protocol," RFC 3261, Jun. 2002. 2. P. Srisuresh, et.al., IP Network Address Translator (NAT) Terminology and Considerations, RFC 2663, August 1999. 7. Fredrik Thernelius, Bertil Engelholm, "SIP Firewall Solution," Internet Draft, Internet Engineering Task Force, Jul. 2000. Work in progress. 8. J. Rosenberg, H. Schulzrinne, "SIP Traversal through Residential and Enterprise NATs and Firewalls," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. 9. D. Yon, Connection-Oriented media transport in SDP, Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. 10. J. Rosenberg, et.al., SIP Extensions for NAT Traversal, Internet Draft, Internet Engineering Task Force, Jul. 2002, Work in progress. 11. J. Rosenberg, et.al., Traversal Using Relay NAT (TURN),, Internet Draft, Internet Engineering Task Force, Nov. 2001, Work in progress. 12. J. Rosenberg, et.al., NAT and Firewall Scenarios and Solutions for SIP,, Internet Draft, Internet Engineering Task Force, Nov. 2001, Work in progress. 13. C. Huitema, RTCP attribute in SDP, Internet Draft, Internet Engineering Task Force, Feb. 2002, Work in progress. 3. J. Rosenberg, et.al., "Getting SIP through Firewalls and NATs," Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. 4. J. Rosenberg, et.al., STUN - Simple Traversal of UDP Through NATs, Internet Draft, Internet Engineering Task Force, Oct. 2001, Work in progress. 5. M. Handley, V. Jacobson, SDP: Session Description Protocol, RFC 2327, April 1998. 6. J. Rosenberg, et.al. Session Initiation Protocol Extension for Session Timer, Internet Draft, Internet Engineering Task Force, Jul. 2002, Work in progress. SIP Proxy X Firewall/NAT UA A Enterprise or Residence A SIP Proxy Y Firewall/NAT UA B Enterprise or Residence B Figure 2: Network Architecture
Client1 SIP Proxy RTP Proxy Client2 100 Trying MGCP (Create Connection #1) MGCP MGCP (Create Connection #2) MGCP MGCP (Create Connection #2) MGCP MGCP (Create Connection #1) MGCP MGCP (Modify Connection: sendrecv) MGCP RTP Traffic RTP Traffic Figure 1: SIP signaling and media flow through SIP and RTP proxies Client NAT STUN Proxy Server src=10.0.1.1:5306 src=1.2.3.4:5679 dst=10.0.1.1:5306 src=10.0.1.1:5307 src=1.2.3.4:5679 src=1.2.3.4:5679 dst=1.2.3.4:5679 src=1.2.3.4:5688 src=1.2.3.4:5688 dst=10.0.1.1:5307 rtp=1.2.3.4:5679 rtcp=1.2.3.4:5688 Contact=1.2.3.4:5:5678 src=1.2.3.4:5688 dst=1.2.3.4:5688 rtp=1.2.3.4:5679 rtcp=1.2.3.4:5688 Contact=1.2.3.4:5:5678 Proxy forwards, response comes back Figure 3: Session initiation with
Client NAT STUN Proxy Server src=10.1.2.3:1928 addr=9.8.7.6:9988 dst=10.1.2.3:1928 src=10.1.2.3:1929 addr=9.8.7.6:8877 dst=10.1.2.3:1929 src=9.8.7.6:9988 addr=9.8.7.6:9988 dst=9.8.7.6:9988 src=9.8.7.6:8877 addr=9.8.7.6:8877 dst=9.8.7.6:8877 rtp=9.8.7.6:9988 rtcp=9.8.7.6:8877 Contact=9.8.7.6:7766 rtp=9.8.7.6:9988 rtcp=9.8.7.6:8877 Contact=9.8.7.6:7766 Figure 4: Receiving an invitation with Client NAT STUN Proxy Server TURN query src=10.1.2.3:1928 TURN query src=15.4.5.6:9988 TURN response addr=15.4.5.6:9988 dst=10.1.2.3:1928 TURN response addr=15.4.5.6:9988 dst=15.4.5.6:9988 TURN query src=10.1.2.3:1929 TURN query src=15.4.5.6:8877 TURN response addr=15.4.5.6:8877 dst=10.1.2.3:1929 TURN response addr=15.4.5.6:8877 dst=15.4.5.6:8877 rtp=15.4.5.6:9988 rtcp=15.4.5.6:8877 Contact=15.4.5.6:7766 rtp=15.4.5.6:9988 rtcp=15.4.5.6:8877 Contact=15.4.5.6:7766 rtp=15.4.5.6:9988 rtcp=15.4.5.6:8877 Contact=15.4.5.6:7766 forwarded upstream Figure 5: Receiving an invitation through Symmetric NATs