Helping VoIP blast off: new IP systems will solve the peering problem - Network Edge

Telecommunications, June, 2002 by Jasson Casey

Ubiquitous VoIP call capabilities from public-to-private networks or private-to-private networks are only possible with native IP peering. However, interconnecting networks is a stringent task--one with which today's VoIP equipment architectures are not prepared to deal. VoIP will continue to experience inhibited growth unless vendors effectively solve the VoIP peering problem.

Data and voice networks can peer to provide transport capabilities, but several problems occur when trying to interconnect two or more VoIP networks--especially if providers want to offer ubiquitous IP services. While VoIP does not have parity with existing voice and data peering models, the ability to peer VoIP networks enables carriers to utilize their cheaper, flexible data infrastructures for voice and reduce their reliance on the telephony network, thereby providing a number of benefits: maintenance of a single network, cost reduction in equipment and services, and the advantage of new VoIP services such as instant voice conferencing. Most importantly, VoIP peering brings about the much-needed PSTN parity to VoIP deployments.

A number of problems must be solved first involving firewalls, NAT (network address translation) devices, GAG (call admission control), SDRs (session detail records) and QoS. Firewalls and NATs are common network elements, but current deployments do not enhance or benefit VoIPs operational model. There is little, if any, differentiation between VoIP and other types of IP traffic on the network, and carriers have tried to maintain QoS by expensive over-provisioning. Another problem is the inability to provide carriers with specific insight into their traffic mix. Some VoIP end-point vendors provide mechanisms that determine a few voice performance metrics, but they lack critically detailed, real-time reporting capabilities. For example, one of the more important measurements for peering networks is to determine if voice quality degradation is occurring before or after the interconnection point. These problems must be solved as traffic ingresses or egresses the carrier network.

The simple, elegant solution to these problems is a single system at the network edge that performs all functions. The carrier has one system (potentially two for redundancy) to manage all VoIP traffic entering or leaving the network. The system must be flexible enough to handle multiple applications (e.g., voice, video) and offer sufficient scalability to handle full pipe congestion.

Current resolutions are point-solution, stopgap platforms that do not provide the single, flexible, scalable, reliable system needed for carrier-class VoIP deployments. To achieve all requirements necessary for successful VoIP production, advancements in network processing and new equipment architectures are required.

It is well-documented that VoIP does not work well with firewalls and NATs. These devices break down in the VoIP environment due to embedded IP addresses they cannot recognize. For example, a VoIP signaling packet--or call setup--contains an embedded IP address and port, which describes where the calling party wishes to receive the voice flow. The firewall is then configured to allow the signaling to pass the filter, but the voice flow is not as lucky. The signaling packet passes through the firewall because it is going to a well-known server and/or port, however the voice flow is being sent to an arbitrary address and port. Since a firewall has no knowledge of the signaling packet destination, it will discard the voice packets because their profiles do not match any of the provisioned firewall rules. An easy solution: Give the firewall some concept of VoIP. Then, when a signaling packet is received, it records the embedded IP address and port and uses that information to provision a dynamic filter rule. Thi s allows the firewall to maintain its integrity, while enabling voice flows to traverse the firewall for the duration of a call.

The NAT problem is similar. Instead of being discarded for not matching rules, the voice packets are transmitted to unreachable IP addresses, because of the embedded IF address and ports within the signaling packet. As the signaling packet crosses the NAT boundary, the destination and return addresses are modified, but the embedded IP and port stay the same and are not valid once they cross. A simple fix is to provide the NAT device with some concept of VoIP. When the VoIP-enhanced NAT device receives a signaling packet, it rewrites the embedded IP address and port to an address and port that it owns. Then the voice flow is directed toward the NAT device instead of to the invalid IF address and port. This allows the VoIP-enhanced NAT device to perform NAT on the voice flow to ensure it gets to the intended party.

Besides fixing connectivity, a viable product must support strong QoS. If data and voice are going to share the network, the busy hour for voice must be added to the total data bandwidth consumed to yield the necessary bandwidth for service throughout the day (see Figure 1). However, that leaves 23 hours with plenty of unused bandwidth. This drives the cost of operation up, while the network is grossly underutilized. A solution is classification as VoIP, as opposed to generic data traffic, and priority scheduling of these important packets. By recognizing both the signaling and voice flows across the network boundary, an edge device can appropriately mark (e.g., DiffServ, MPLS) and queue the packet. This allows the network edge to be oversubscribed and, depending on performance of the edge device, maintain voice packets while delaying less time-critical packets (e.g., SMTP, HTTP). GAG goes hand-in-hand with QoS. Calls should never be admitted to the network if a particular customer has reached its bandwidth/ concurrent call limit. Galls should always be flagged with appropriate QoS.