Section 13.2. VoIP Trunks | Switching to VoIP

13.2. VoIP Trunks

As you know, a VoIP trunk uses digitized voice in IP packets to link two PBX servers. VoIP trunks can replace legacy trunks only when the two PBXs being linked are VoIP-enabled. A VoIP trunk could run between two IP-enabled PBXs, like the Avaya S8700 and a Nortel Meridian, or between two legacy PBXs that have outboard VoIP media conversion. Outboard conversion devices, like Cisco media gateways, allow legacy PBXs to connect to the local Ethernet network and perform the voice packetizing for the VoIP network since the PBX can't on its own. (The cost of outboard conversion often helps build the case for using VoIP-enabled or native VoIP softPBXs instead.)

Like other IP protocol families, VoIP can be tunneled within VPNs and GRE (generic routing encapsulation)point-to-point tunnels. By now, you know it can be routed, switched, and load-balanced . These qualities, inherited from the Internet-like networks that came before it, give VoIP's trunks greater flexibility than legacy trunks. You'll connect voice systems using VoIP trunks when one or more of the following conditions exist:

Two or more PBX systems on a private network are IP-enabled
Two or more legacy PBX systems on a private network have outboard media conversion (Ethernet interfaces) to link them using a VoIP trunk running on the IP network
The cost of a legacy trunk is prohibitive, especially in long-distance scenarios
IP WAN links exist between sites that have PBX systems
Two sites have broadband connections to the Internet, which can be used as a transport for IP telephony applications

13.2.1. Unwanted Effects of Load Management

Whether you use a completely private WAN or a mix of ATM, frame-relay, and VPN connections, you may employ a few different techniques to preserve or balance traffic between those links. You might use complex multipath routing, or you might use load-splitting or multilink bundling.

The challenge these techniques pose to VoIP is simple. Wherever two physical network paths to the same destination exist, there are likely to be differences in latency and jitter between those two paths. That is to say that, if you have two T1s side by

Squeezing More VoIP Out of VoIP Trunks

You would think getting a couple of 64 kbps voice calls over a 128 kbps link would be a simple matter, but not so in VoIP. IP packetization, RTP, and the framing on the data link itself all introduce overheadso much overhead that a single G.711 call can all but swamp such a slow link.

Aside from using low-bandwidth codecs, here are some tips to ensure your IP-based pathways provide the highest possible capacity for VoIP calls:

Use SigComp (Signaling Compression) if it's supported by your VoIP devices. SigComp is described in RFC 3320.
Use IP header compression over low-capacity links.
Enable silence suppression and voice activity detection to stop the transmission of packets when nobody is speaking.
If trunking a large number of calls between two systems, use IAX2 for the trunk. IAX2 multiplexes much more efficiently than SIP or H.323.

side between point A and point B, they won't always run at exactly the same error rate day in and day out.

13.2.1.1 Traffic diversion (failover circuitsfailover circuits

To illustrate this, let's say that two WAN links between the same point A and point B exist. Let's say one is a full point-to-point T1, while the other is a 512 kbps frame-relay PVC. Ordinarily, the frame-relay connection isn't used. But it provides some geographic diversity and a good outlet for bandwidth overflow. So, when the T1 is maxed out (or down), traffic is diverted across the PVC using a router we'll call an overflow valve . This may be a fine solution for non-real -time IP traffic.

Frame-relay PVCs are not a good backup for point-to-point T1 trunks since they're far more jittery, though they're sometimes cheaper than T1s in long-distance situations.

But frame relay is a much more latent, jittery technology than T1, so during times when the overflow valve is diverting IP traffic to the PVC, things will be noticeably slower and, quite possibly, more jittery than they would ordinarily be. This could result in a situation in which, most of the time, VoIP media channels function fine, but suddenly, once the overflow or diversion point is reached, phone calls start sounding bad. This is a basic example of a precautionary topology decision having a potentially destructive effect in the world of VoIP.

13.2.1.2 Load-splitting

A similar problem can occur with simple load-splitting. Let's say you have two or more point-to-point links that all start and end at the same locations. Let's also say you use IP routers to split the traffic load equally (or unequally) across them. You can use BGP (Border Gateway Protocol) and other routing protocols to accomplish this, but be careful of the potential for variances in jitter and delayespecially if the links run at different speeds or use different data link technologies (like a radio link side by side with an FSO link).

13.2.1.3 Multipath jitter

Jitter that's incurred by complex routing and/or load-balancing can be minimized. Here are three things you want to avoid when setting up WAN links to support VoIP trunks:

Avoid using a multipath routing setup for parallel IP links that use differing transport technologies (i.e., point-to-point T1 and a VPN). While it may be fine to use one or the other as a backup link, daily use will sabotage the consistency of phone calls
Avoid terminating any one end of a call path on more than a single router. This will create jitter. If you want to use multiple routers for disaster preparedness reasons, then take steps to make sure each RTP media stream (in both directions) is being handled by only one of them
Don't do load-splitting across two links of differing latency (like an 802.11b link and an 802.11g link). This exacerbates the jitter problem

13.2.1.4 Multilink PPP

Multilink PPP bundles allow a single router to bond multiple interfaces, so that two or more data links can act as a single cohesive pathway . If four T1s ran from point A to point B, and a router with 4 T1 interfaces existed at each end, then those four T1s could be bonded into a multilink PPP connection. The result would be four times the bandwidth across a single logical linksimilar to the simple load-splitting example before, but with a lower risk of jitter (especially if the four links are of nearly equal speed and latency).

13.2.2. TCP/IP as a Transport for Voice Trunks

So far in this chapter, we've been talking mainly about the physical wide area network connections, or trunks. This is physical and data link layer stuff. But VoIP infrastructure happens at the network layer, too. This is where TCP/IP replaces analog lines and T1 signaling as the voice carrier. The IP carrier can take many formsplain-old, insecure UDP datagrams, VPN connections, GRE tunnels, even SSH tunnels. Some are more well-suited to enterprise voice apps than others, as we'll discuss.

13.2.2.1 Insecure, unencrypted UDP

One of IP telephony's key advantages over traditional telephones is that of security. While it's nearly impossible to secure the access perimeter on the PSTN (see Chapter 10), it's even tougher to secure analog phone conversations against clandestine surveillancethe old-fashioned "phone tap." Legacy telephony's glaring security issues have always been a key selling point for VoIP. Yet, if you want to use IP telephony in an insecure way, it's easy to dojust don't encrypt anything.

Many IP phones now support Secure RTP (SRTP), a protocol that allows them to use encrypted media streams.

If the VoIP network were to replicate the insecurity of the PSTN, it couldn't enroll any secure transport technologies or encapsulation. This means avoiding the use of VPNs and encrypted tunnels. Using unencrypted signaling and media channels means clear-text authentication and eavesdroppable audio signals. So, a G.711 phone call across the Internet between two endpoints that don't support media encryption is quite easily monitored by a third party. These calls are vulnerable to man-in-the-middle attacks, allowing a remote observer to record, and possibly even hijack , them.

13.2.2.2 VPN

Virtual private networks created encrypted connections across the Internet between two private IP networks by encapsulating private traffic into public traffic and sending it between two routers (LAN-to-LAN VPN) or from a remote user to a VPN gateway router ("road warrior " VPN).

The two most common VPN technologies in use today are PPTP and IPSEC. While both can be used for LAN-to-LAN and road warrior setups, it's more common to see IPSEC as a part of high-density or mission-critical solutions because it implements IETF standards. Despite their differences, PPTP and IPSEC are both excellent for securing traditional, non-real-time traffic, and both are poor for securing VoIP traffic, because:

VPNs introduce packetization delay, from 5 ms to 50 ms
When established across the Internet (which is almost always), VPNs are subject to typical Internet traffic delays, making them less suitable for VoIP
The devices used to connect VPN clients (VPN servers and gateway devices) sometimes don't have enough processing power to support a large number of media channels.

But these challenges don't rule VPN out totally. If you're using a VPN connection between two offices that both receive Internet access from the same provider's network, then it's likely that the provider can manage the VPN or guarantee the maximum latency of traffic that doesn't have to leave its network, such as the traffic between the two offices, will always be treated with high priority. Here are some tips for successful VoIP over VPN:

Try to keep VPN traffic between remote locations on the same backbone network to keep the number of router hops down and minimize end-to-end latency. Keeping traffic on a single network may also allow the provider to guarantee you a certain level of service
If using a dedicated device for VPN termination, such as a specialized VPN gateway router or "concentrator," be sure it can tag priority traffic after it's encapsulated into VPN traffic. This way, the CoS information recorded by the telephone endpoint in each LAN packet won't get lost inside the encapsulated VPN packet it ends up in as it travels over the Internet. If your VPN solution doesn't account for CoS, VoIP quality may suffer.

A great source of information about implementing VPNs is O'Reilly's Virtual Private Networks .

13.2.2.3 GRE tunnels

A simple but effective way of linking two disparate networks securely over the Internet is the use of a GRE tunnel. GRE is a simple IP protocol used to encapsulate most kinds of VPN traffic. GRE can be used to tunnel directly between two routers, providing the secure, encrypted transport of a VPN without the need to support a VPN appliance or pricey VPN server. Cisco routers that support 3DES encryption and have the Cisco IP Firewall IOS firmware can create a highly secure GRE tunnel.

Even if your Cisco router can support 3DES encryption and IP Firewall firmware, it may not have enough flash memory to support them both at once. At a minimum, a 16 MB flash memory card is needed.

Consider the following Cisco IOS configuration, which establishes a tunnel using 3DES encryption over an Internet- facing serial interface:

 crypto isakmp key crypt0k3y address 10.10.10.2     !     crypto ipsec transform-set 3des ah-md5-hmac esp-3des     !     crypto map mymap local-address Serial0     !     crypto map mymap 10 ipsec-isakmp      description VPN to Satellite Office      set peer 10.10.10.2      set transform-set 3des      match address satellitevpn      qos pre-classify     !     interface Tunnel0      description ---------- Tunnel to Remote Office      ip address 192.168.1.1 255.255.255.252      tunnel source Serial0      tunnel destination 10.10.10.2      crypto map mymap     !     interface Serial0      description ---------- T-1 to Internet Provider      ip address 10.10.9.2 255.255.255.0      ip nat outside     !     ip access-list extended satellitevpn      permit gre host 10.10.9.2 host 10.10.10.2     !     access-list 150 remark ACL for PBR route-map     access-list 150 permit ip 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255     access-list 150 deny ip any any     !     route-map PBR permit 10      match ip address 150      set interface Tunnel0      set ip next-hop 192.168.1.2     !     ip route 10.0.1.0 255.255.255.0 192.168.1.2     !

The crypto commands at the beginning of the configuration establish the encryption parameters the tunnel will use, called a crypto map. These parameters describe what type of encryption techniques will be used to secure the link and which networks can use the link. In this example, satellitevpn is the name of an access list that defines the address of the remote host allowed for this tunnel.

If you'd like further study in cryptographic features on Cisco routers, and other Cisco knowledge, refer to O'Reilly's Cisco IOS in a Nutshell and No Starch Press's Cisco Routers for the Desperate .

The interface called Tunnel0 is a logical interface established to distinguish tunneled, private traffic from public, unencrypted traffic to and from the Internet. The remote router must have a similar logical tunnel interface to operate the other end of the tunnel (see Figure 13-1).

The configuration for this router establishes a tunnel to a peer router at 10.10.10.2, and sets up an access list that enables it to pass traffic through this router. In this case, the IP Firewall firmware is performing NAT on the Serial0 interface, which puts a NAT firewall between hosts on the remote end of the tunnel and the Internet. ( Serial0 is the interface facing the ISP.)

Figure 13-1. A GRE tunnel between two routers is a relatively easy VPN link to use for VoIP trunking

Once the link is established and able to pass normal IP traffic through the tunnel (tracerouting across the tunnel won't show any intermediate hops other than the local and remote routers), you can put any combination of IP phones and IP/PBX equipment on either end of the tunnel, as long as the capacity and end-to-end latency are acceptable to you. So, like a point-to-point T1 with IP, this tunnel could be used as a trunk between two PBX servers or as a way of connecting several dozen IP phones to a PBX on the other end of the tunnel.

Incidentally, all of the Internet-bound traffic from the remote site will also traverse the tunnel rather than going, unencrypted and directly, to the Internet.

13.2.2.4 IP addressing schemes

You may have a desire not to burden the tunnel with non-voice traffic, but rather tunnel only voice traffic between the two sites. An easy way to distinguish between voice and non-voice traffic is to organize all voice traffic into its own subnetwork and then simply route the non-voice traffic outside of the tunnel. (This has implications for the whole enterprise WAN, not just tunneling.) For example, if your private network address is 10.0.0.0/24, then you could subnet that address range in order to organize by mode of service (data or voice) and location:

 10 .  location  .  mode of service  . 0

So, 10.1.1.0/24 would be for Detroit data, while 10.1.2.0/24 would be for Detroit voice. 10.2.1.0/24 would be for Chicago data, while 10.2.2.0/24 would be for Chicago voice and so forth. Using network addresses to "label" things is a simple convention for managing routing rules and making the address structure admin-friendly. But in a very large network, using a "labeled" address scheme could cause you to run out of address ranges. If you wanted to better preserve available IP addresses, you could do some fancy subnet slicing:

This way, instead of each location using up 65,000 addresses, they'll use only 512. In fact, this example allows growth of 512 more addresses in the future.

Even if you aren't tunneling trafficdifferentiating the mode of service by using different subnets for voice and data is still a good way to organize your network.

Class-of-service prequalification . In the Cisco configuration sample, you can see the cos pre-qualify command. This tells the router to recognize CoS tags within packets inside the tunnel and then tag the encapsulating packets appropriately. This is crucial for VoIP performance. Without prequalification, the layer 2 and 3 class of service tags normally carried by each packet would be encrypted into the tunnel, no longer legible to routers that are handling the tunnel. The effect would be that those routers, which cannot see "inside the tunnel," would think these packets have a regular priority class of service like any other traffic. Prequalification ensures that the tunnel packets retain layer 2 and 3 tags.

Use prequalification and keep your VPN within a single service provider's network, as in Figure 13-1, to avoid delay problems that occur when traffic hops from one Internet provider to another.

13.2.3. Supporting VoIP Road Warriors

A VPN concentrator is a dedicated server or appliance that allows many users to use a VPN for direct connection to a private corporate networkone PC at a time rather than one network at a time, as in the prior examples. The main duty of VPN concentrators is giving road warriors secure access to the main office.

That could mean email access, file and print services, or even monitored web browsing. VPN simplifies the traveling user's configuration experience. The user plugs in his laptop, and once the networking software on the laptop obtains its TCP/IP configuration from DHCP, the user can "dial up" the VPN connectionpreconfigured by an administrator. The user types his password, and off he goes, just as if he were in the office sitting next to the file server.

The notion of "it works anywhere " is available for IP phones, too. Suppose a user accessing the VPN had a softphone running on his laptop. As long at that softphone can register and make calls over the VPN, then he can:

Receive phone calls at the same E.164 number no matter where he is physically, as long as his PC can access the Internet. SIP (or H.323) does the job of signaling incoming calls to the phone once it has registered with the VoIP server through the VPN
Make use of the private dial-plani.e., three-, four-, or five-digit extension dialing and autoattendant features normally used only inside the office
Originate calls from the corporate call center instead of from his hotel. This is useful for traveling salespeople who don't want the hotel's caller ID showing up on their customers' phones when they call. (Or for those who don't wish to pay exorbitant hotel phone fees.)

13.2.3.1 To VPN or not to VPN?

Now, to do all three of the great things listed, you don't really need a VPN. The VPN merely provides security and ease of access for the end user. Setting VPN's niceties aside, you really just need your softphone to be able to register and communicate with the softPBX over the Internet. As long as your softPBX can be accessed from the Internet without a VPN, then you don't need to use one. This probably isn't the most secure idea in the world, however.

In telephony, the VPN trade-off is black and white. With VPN, you gain security. Without it, you (may) gain quality.

TSPs don't use VPN to support their customers because of its negative impact on quality of service and because it's more difficult to maintain. But, in a corporate environment, it's probably a much safer idea to provide VPN's protective wrapper for your telephony app. As long as call quality is acceptable to your road warriors, then VPN does the trick.

13.2.3.2 Soft- or hardphonehardphone

If you use VoIP for your mobile workforce, then you'll have to choose whether each user will be using a hardphone or a softphone. Aside from convenience and preference, the choice is affected by whether you employ a VPN to connect your mobile users.

Since a VPN client runs on a PC, the VPN tends to encapsulate any softphone traffic from that PC. But hardphones are more difficult to use with a VPN. They don't have a built-in VPN client as the PC softphone often does, so the only way to use them with a VPN is to connect them to an offboard VPN router. Try convincing your salespeople to do that . If you opt not to use VPN and decide to support your road warrior with a direct, VPN-free connection, you afford her the option of using a hardphone in her mobile office.

When an IP hardphone is connected to an Ethernet segment, it behaves like a networked PC that's booting up. It contacts a DHCP server, gets its IP configuration, and, if configured for a VoIP network, attempts to register with a VoIP server. It doesn't care where the VoIP server is. It could be in the next room over, or it could be in Manitoba, Canada. Such is the nature of TCP/IP. The point here is that you can set the behavior of the IP hardphone to be identical no matter from where it connects. In theory, if you provide for a consistent registration path from any spot on the Internet, the phone will behave consistently regardless of where it's sitting. (This is what Vonage and BroadVoice have done.)

Like your corporate web site, which can be viewed by mobile users anywhere in the world, it's possible for you to allow your telephony users to access your voice services from anywhere in the world.

But there are a few gotchas to this Utopian road warrior's dream:

There ought to be firewall(s) between the road warrior and his VoIP network. Depending on your network's requirements, you may need to allow TFTP, RTP, IAX, SIP, H.323, SCCP, and the host of VoIP- related traffic (port numbers and protocols can be referenced in Chapter 10)
Don't bet on hotels and other road warrior hotspots offering inline power. Make sure the road warrior carries an AC power adapter for his hardphone
In order to be truly transparent to the end user, you must set up your VoIP network so that road warriors' IP phones can be configured once and not repeatedlyregardless of how many stops they're making or how many days a week they are in the corporate office. Road warriors don't want to have to remember to pop in a certain DNS setting when they're on the road and another when they're in the office

If these issues are making you think twice about skipping VPN, consider sticking with VPN and using a USB handset. These devices provide the look and feel of a real hardphone, but they connect to the PC's laptop so they can be used as a UI element for the softphone. This can save frequent callers the cumbersome task of dialing 11-digit phone numbers on a laptop keyboard, because the USB handset has a 12-key dial-pad. For more information on USB handsets, visit http://www.pc-telephone.com/usb-phone.htm and http://www.eutecticsinc.com/products.