http://www.networkworld.com/news/2005/112805-voip-ice.html


VoIP scheme gets big backers

By Phil Hochmuth
Network World

11/28/05




Cisco, which sells the most IP telephony gear, and Microsoft , which seeks 
a greater corporate VoIP role, recently agreed to work together to add 
capabilities in software that lets IP voice traffic more easily run across 
firewall-protected networks.

The two companies will support and implement Interactive Connectivity 
Establishment (ICE) technology, which is a proposed IETF standard for 
allowing VoIP calls to traverse firewalls without compromising security. At 
issue is network address translation (NAT ), which is one of the most basic 
methods for protecting client and other network-based devices behind a 
firewall. NAT distributes internal IP addresses to nodes and then 
translates the addresses to publicly routable IP addresses when traffic 
traverses the Internet. This can prevent a VoIP call from being set up 
because NAT makes each IP endpoint in a VoIP connection handshake seem 
unreachable to the other.

Many companies have worked around NAT/VoIP compatibility issues by 
tunneling IP voice traffic through VPN connections. This is common for 
remote users with softphone clients and laptops, who connect to a corporate 
IP PBX through a home firewall or a hotel broadband connection with a VPN 
link. Site-to-site VoIP setups also use tunneling, virtual LAN (VLAN ) 
segments over VPNs or point-to-point links to connect VoIP calls to offices 
protected via NAT firewalls.

But some observers and standards crafters say such methods are stopgaps, 
and that VoIP connectivity should work as seamlessly across the Internet as 
browsing a Web site, sending e-mail or as in instant-messaging sessions.

This is where ICE comes in. The technology works by discovering the 
internal IP address schemes of networks that the two VoIP endpoints are 
attached to, behind NAT firewalls. To do this, ICE uses existing protocols 
and IP address discovery mechanisms, such as Simple Traversal of UDP 
through NAT (STUN), Traversal Using Relay NAT (TURN) and Realm Specific IP. 
This requires servers that can accept STUN and TURN requests and broker 
these connections for VoIP devices, which are called initiators in the ICE 
model.

STUN and TURN "by nature of their design, are difficult to operate through 
NAT," according to Jonathan Rosenberg, a Cisco engineer and author of the 
IETF Internet draft for ICE.

"ICE makes use of STUN and TURN, but uses them in a specific methodology, 
which avoids many of the pitfalls of using any one alone," Rosenberg writes 
in the ICE IETF draft proposal.

The potential for any-to-any VoIP connectivity without impediment from NAT 
firewalls has strong promise for consumer VoIP technology, according to Don 
Proctor, senior vice president of the Voice Technology Group at Cisco. 
"Microsoft's and Cisco's endorsement of ICE standards bodes well for our 
mutual customers," he said in a statement. This is especially true 
considering that most home networks with broadband have Microsoft operating 
systems, are protected by broadband router/NAT firewalls and connect to 
carrier networks with Cisco gear.


For some companies that run their business phone systems on IP networks, 
the concepts behind ICE pose some security issues, and the problem ICE 
proposes to solve is not one that is very pressing for companies that use 
IP PBXs and IP phones.

"We run VoIP so that all of our traffic runs on our internal network," says 
Irving Tyler, CTO for Quaker Chemical, an industrial chemical manufacturer 
in Conshohocken, Pa. His firm uses Avaya IP phones, IP-enabled PBXs and 
Cisco switches and routers to connect users in the company's main office 
and satellite sales offices. Any VoIP calls made on the network run inside 
Quaker Chemical's firewall boundaries and over point-to-point WAN links. 
When calls leave the network, they're translated to digital public switch 
telephone network voice signals.

The concept behind ICE - allowing IP communication devices to link with IP 
devices over the Internet, regardless of firewall configurations - might be 
a neat trick, but not an application his company is interested in now, 
Tyler says.

Also, the methodology of ICE, in which behind-the-NAT IP addresses are 
discovered and shared among connecting parties, is something that 
businesses might be hesitant to explore.

"I could see people being leery about doing that," he says. If a carrier or 
VoIP vendor could provide security for such exchanges, "I think companies 
would be more likely to look into opening up their internal IP addresses."

Proponents of the standard say the benefits of ICE will become more 
apparent when wide adoption of VoIP happens, and IP PBX installations 
become more mature. As more companies build security within network 
boundaries, ICE could play a role in simplifying voice-traffic management, 
says Cullen Jennings, a Cisco engineer.

Like Quaker, most VoIP traffic in businesses runs behind the edge firewall. 
But "many enterprises are looking at deploying, or are already using, lots 
of NATs inside the network," he says. This could be a large company that 
shares one large network, but separates divisions or departments with 
internal firewalls for security, or IP address management.

Branch offices sometime use NATs, so that devices can receive IP addresses 
from a local DHCP server, instead of a centralized source. ICE would help 
simplify VoIP connectivity in this case, as well, he adds.

As for when ICE will show up in VoIP products, Jennings says this is a ways 
off.

"ICE is still a draft, not even an RFC yet, so no one can really say they 
support it," he says. "But [Cisco has] products that we are working on with 
a prestandard implementations of ICE."


================================
George Antunes, Political Science Dept
University of Houston; Houston, TX 77204
Voice: 713-743-3923  Fax: 713-743-3927
antunes at uh dot edu



Reply with a "Thank you" if you liked this post.
_____________________________

MEDIANEWS mailing list
[email protected]
To unsubscribe send an email to:
[EMAIL PROTECTED]

Reply via email to