There's a potential problem that would-be Internet telephony clients may run into when they jump into the ins and outs of implementing a calling solution or service. In an acronym, that problem goes by NAT, short for Network Address Translation, a technique commonly used on many networks. Though by itself NAT is nothing more than an "address-hiding" technology (it obscures the true originating address with that of the gateway that serves as the Internet access point for network users in most implementations), it's often used in conjunction with
Requires Free Membership to View
SearchUnifiedCommunications.com members gain immediate and unlimited access breaking industry news, expert advice on UC, technical guides, and more -- all at no cost. Join me on SearchUnifiedCommunications.com today!
Kate Gerwig, Editorial Director
RFC 1918 private IP addresses (which permit the same IP addresses to be used in many locations since by definition private IP addresses aren't routable across the public Internet). NAT's appeal in this particular case is that it permits companies to select from a single Class A IP address (10.0.0.0), 16 Class Bs (172.16.0.0 - 172.31.0.0), or 256 Class Cs (192.168.0.0 - 192.168.255.0) when allocating IP addresses for internal use, all available at no cost.
The problem comes into play when you seek to attach a soft phone or a properly connected handset to a network that uses private IP addresses. In some cases, this causes problems at the firewall, because end-to-end connections required to make telephony work can't be established. Some implementations require special border controllers to be deployed at network edges when private IP addresses are in use, or when reverse UDP mapping is disabled or not allowed at the network periphery.
This is a situation for which various vendors have varying solutions. In some cases, the handset or softphone must be physically attached to the Internet gateway (which works OK for small office/home office situations, but isn't too workable for larger, more complex configurations). In other cases, additional hardware or software is required to make the connection work on a larger scale (as in the Jasomi story reported on SearchNetworking.com on 5/15/2002).
Another option is Xten Networks XTunnels which works as a combination NAT, firewall, and private proxy traversal solution for SIP endpoints. Softphones and handsets that incorporate Xtunnels can send and receive call through NAT-enabled firewalls without requiring further infrastructure adjustments (such as opening specific ports on the firewall for call access and use). This solution avoids the use of session border gateways or the need to replace existing firewalls with solutions that can handle NAT services for inbound and outbound calls. The developer of the technology, Xten Networks, makes XTunnels available at no charge in exchange for signing the company's licensing agreement. The company's softphones are widely used in VoIP implementations by Vonage, Plantronics, HP, Clarisys, SIPphone, and others. More information on XTunnels is available at the Wiki Forum for that technology.
Ed Tittel is a regular contributor to numerous TechTarget Web sites, and the author of over 100 books on a wide range of computing subjects from markup languages to information security. He's also a contributing editor for Certification Magazine, and edits Que Publising's Exam Cram 2 series of cert prep books. E-mail Ed at etittel@techtarget.com.
This was first published in October 2004