Network Address Translation presents a number of problems for SIP and VoIP, stemming from the fact that NAT addresses are not routable on the Internet.
This doesn't stop clients with NAT addresses from accessing a Web server using a simple protocol like HTTP, for example, because the NAT device substitutes its own external, routable return address before transmitting to the Web server. The Web server then sends a response to the NAT device's external address. Because the NAT device keeps track of the initial request, it knows to which internal NAT address to forward the packet when it arrives.
The same process, however, does not work for SIP, because of the way SIP deals with IP addresses. When a SIP client initiates a session with another client or server, it puts its IP address in the application layer of its initial request. This is because SIP is designed so that it can reroute responses to different paths than the requests (see "It's Time To Take a Look at SIP," for an in-depth explanation of the SIP protocol). When the receiver is sending back its response, it uses this return IP address (which it gleans from the application layer of the initial request) as the destination address of the IP packet that it sends back.
In contrast, HTTP or SMTP rely on the source address in the IP layer for the response that is returned. This creates a problem if the client initiating the session is using NAT. The NAT address will be placed in the application layer when the client initiates the session, and the receiver will attempt to use this NAT address as the destination IP address of the response.
But because NAT is not routable, the response will not arrive. Even though a NAT device is smart enough to substitute its own external, routable address in the IP layer of the packets that it transmits, this intelligence does not extend to substituting its address in the application layer.
The other problem NAT poses is that, by default, it's impossible to initiate any connectivity from the Internet to a device with a NAT address. Although this has some security benefits, it can create confusion. If the Web server in the above example had a NAT address,
a client on another network would have no way to direct a request to the server because it would be using a nonroutable IP address. One way to solve this problem is to configure the NAT device manually to send all requests on Port 80 to a particular device on the internal NAT network. The external IP address can then be published as the address of the Web server. But this approach requires a high level of expertise to configure. In addition, it doesn't scale well if a lot of devices are involved. This is a big problem with SIP phones on a NAT network--they won't be able to receive calls.
Fortunately, better solutions exist:
• Far-End NAT traversal: This deals with the NAT problem on the provider's network and is your best bet to use with typical home users. It deals with both of the problems outlined above and can eliminate most support issues.
A Far-End NAT traversal product resides on the same network as the SIP Proxy and intercepts all SIP messages before forwarding them to the SIP Proxy. It solves the return-address problem by putting the IP source address into the SIP header, which the proxy server looks at to determine where to send its response. The proxy server now sends its response to the NAT gateway's routable, external IP address, which then forwards it to the client.
The other problem is getting a SIP Invite message into a NAT gateway to initiate a call to a phone inside the network. If an external device wants to initiate a call to a device with a NAT address, it cannot route the request to the target device's private address. This can be fixed by having a device on the provider's network maintain an opening, sometimes called a pinhole, through the NAT device. It can't be done, however, until traffic is first initiated from inside the NAT network. Once that happens, a NAT traversal product on the ISP's network can trick the NAT device into maintaining an opening for return traffic for the specific pair of IP addresses and ports. It can then use that opening to initiate a connection back into the network. This is done by sending SIP notify messages into the network frequently enough to maintain the opening, or by causing the SIP client to register often enough to maintain the opening. BroadSoft provides this service using NAT traversal products from Kagoor Networks and Acme Packet.
• Universal Plug and Play: UPnP is a standard based on an industry consortium backed by Microsoft, Intel and others. It is designed to let devices in a home network discover one another's capabilities and inform one another of necessary configuration changes. All devices on a home network have to be UPnP-enabled, of course. In our scenario, an IP phone could discover the external, routable IP address of a DSL or cable-router NAT device and use that address in the SIP layer when it constructs an Invite message. It could also instruct the router to open up an IP address/port to allow access into the network from a particular SIP proxy server. The Snom phone we tested had this feature and could communicate with the NetGear NAT device on our network and find out its external address. The phone then used that external address in the SIP layer when it initiated a request, such as an SIP Invite. It also sent a message to the router to open up access from the proxy server's address so that calls could be initiated from outside the network.
• Simple Traversal of UDP Through NATs: STUN, which requires that the client understand STUN and that there be a STUN server available outside of the network, works by having the client send packets to the server, which looks at the source IP address that is used. It then informs the client. The client compares this address with its local IP address, and if they are different, can conclude that it is on a NAT network. It can then use the external IP address discovered by the STUN server in the SIP header.
• Application Layer Gateway: Using an ALG involves building intelligence about specific protocols into a firewall so that it can make the necessary adjustments. For example, the ALG can rewrite the IP address in the SIP layer with its external, routable address before sending it out. It can then keep track of return packets and let them through. It also can be configured to allow specific access to devices behind it.
• Manual configuration: Some NAT devices allow manual configuration. In this case, it is possible to put in rules that would allow incoming traffic from the IP proxy's address on the SIP port (5060). However, this requires some technical expertise and isn't very scalable. It also doesn't solve the problem of NAT address as the return IP address. You would not want to ask a telecommuter to implement this solution nor attempt to support it remotely.
REPORTS
ANALYTICS
Follow 
