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:
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
side between point A and point B, they won't always run at exactly the same error rate day in and day out.
184.108.40.206 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.
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.
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).
220.127.116.11 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:
18.104.22.168 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.
22.214.171.124 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.
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.
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:
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:
126.96.36.199 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.
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.
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.
188.8.131.52 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.
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.
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:
184.108.40.206 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.
220.127.116.11 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: