Introduction To Voip; A Few Tips For Those Considering Voip Deployments
Before you can deploy a certified VoIP solution, you need a network assessment to verify you have properly prepared your network for the VoIP traffic that will be running on it. Unless you have a vast deal of experience in deploying VoIP, an assessment is suggested and if your plan is that “with this great bandwidth, we don’t need QoS”, then you ABSOLUTELY need an assessment.
So, my first part is ….
The Network Assessment:
Performing a data network assessment is very different than performing a VoIP network assessment. Although the purpose of both VoIP and Data only networks is to move bits from host A to host B a very real dissimilarity exists in the requirements of each type of network. The function of VoIP technologies requires very strict standards that don’t necessarily exist in a Data only network. Those standards, if not adhered to, will noticeably affect call quality.
Only in the last several years has the IT community generally accepted that VoIP Technologies are ready for the office environment and since its acceptance, have companies honest begun to welcome VoIP technology. The slow acceptance of this emerging technology is despite the fact that same compression algorithms and standards for VoIP have been around for years. By far the largest reason that VoIP technology was not “ready for the real world” lies in the network that carried VoIP traffic not being ready. Even still today, if the requirements outlined in this and documents similar to this network assessment are not strictly adhered to, many companies gain that they are not satisfied with the performance of their VoIP implementation.
Top 10 Best practices / standards (more detail below)
1- Dedicated VLAN’s for VoIP to retain VoIP isolated from other data traffic.
2- Fragmentation of serial links less than 768Kb.
3- Use “no ip-redirects” on all routing interfaces that will carry VoIP traffic.
4- If load-balancing several links to aggregate bandwidth, use “per-destination” method (such as on MFR / multilink-frame-relay interfaces).
5- Use DSCP / ToS as the mechanism for VoIP prioritization rather than just prioritizing one subnet or IP over the other traffic.
6- Lock all switch ports; don’t leave as auto-negotiation. Most all Avaya products support 100/Full settings (Excluding Intuity AUDIX VM systems but including Intuity LX systems).
7- Enable MLS QoS not unbiased WAN QoS. Enabling QoS for LAN’s isn’t always a requirement since bandwidth is often far excessive of what is required.
8- Verify all interfaces are configured for QoS. Trusting DSCP / COS values at the switch port where an IP phone or MedPro connects to the LAN/WAN is a requirement; but preserving DSCP / COS and trusting those values throughout the network (on all inter-switch trunks) is also very important.
9- Employ dot1Q trunks between all switches. ISL and other trunking methods may not support all open standards as well as the standardized dot1Q trunking protocol.
10- Ensure that any PoE switch / inline device can supply Class 3 (15.4 watts) of power to the IP phones.
*********************************************************************
General Guidelines for VoIP:
In an average data network, a packet arriving with up to several full seconds of latency (delay in transmission over the LAN and WAN links) could not be noticed or would normally be accepted as “uninteresting network day” by most users. Even in networks currently using MS Terminal Services or Citrix Metaframe (a RDP-TCP connection socket over TCP port 3389; which is considered a real-time data application) a slight delay in receiving a packet can be accepted depending on how the application is configured. Even if a session is lost, connectivity in RDP-TCP applications can usually resume the session from where the user left off. In such a scenario users may not even report that they were experiencing such problems.
TCP vs. UDP:
With any VoIP network the transmission of information must be real-time and remain so through-out the duration of a call. The biggest difference in VoIP from standard data traffic is that VoIP uses UDP not TCP communications. The consume of UDP over TCP allows for faster transmission of voice packets because packets arriving leisurely are discarded and receipt confirmation is not primary. UDP’s lack of confirmation that a packet reached its destination leaves VoIP to rely on the network and its QoS mechanisms to make sure that packets advance their destination and in the right order. Failure of the network to provide QoS will result in perceived problems with the VoIP phone system which actually lie in the network.
While it is mistaken, the traditional perception regarding QoS has been that with high speed LAN or WAN links, QoS can be considered as optional or something to be implemented at a later time if there are problems with network congestion. And so many VoIP implementation organizations have perceived LAN based QoS as optional as well. Empire Technology’s bear experience however is that while on an average day this may be correct, QoS is a very respectable view and strongly recommended even on LAN links. Since about the same time that Y2K issues were on the big IT story network administrators noticed an increase in worm virus attacks on their networks where Trojan’s had previously been the leader in Virus problems. Worms use the LAN and WAN to self replicate have wreaked havoc on VoIP systems which do not utilize QoS because of the amount of traffic a worm can generate once it has infected as little as a 2-5% of computers on a network. While a data network queues all traffic at the same priority, data will continue to eventually make it to its destination should a WORM flood the network with traffic. In a VoIP network, should the same occur, the VoIP application will be nearly 100% useless in the same scenario. By the time the phone system can setup the call, there will be no more bandwidth for the bearer signal of that call available. NO CALLS WILL GET THROUGH in this worst case, but relatively common, scenario. When you consider that in many cases the first step in identifying a network problem is calling a vendor for attend, not being able to make a phone call can be a critical problem.
Enabling QoS on a LAN for most offices may be as simple as providing a separate subnet for voice users and devices. Avaya IP Phones, IP Console, IP Softphone, and all gateways / call servers will tag packets for QoS LAN based switching however there should be no special configurations necessary for ensuring QoS from one host to another host on the same subnet. Cisco’s Auto QoS can easily match Avaya’s QoS mapping so it is suggested to use Cisco’s Auto-QoS on all Cisco gear and not creating any special mappings.
QoS on all WAN links is a definite requirement. Some people have suggested that simply increasing the WAN’s CIR to be large enough to handle all data traffic then add whatever bandwidth is needed for VoIP would save them the anguish of implementing QoS. Those people have learned the same lessons that each of us have learned when purchasing our first PC: You will never find “a hard-drive so big that I’ll NEVER fill that up.” And, nor will you acquire enough bandwidth that no one will be able to use it up. Eventually someone takes up the entire bandwidth leaving none left for voice. It is strongly recommended you remember one thing: QoS is a requirement if the goal is “Quality recount Service”.
Beyond a well-planned QoS policy several additional factors will also play a roll in voice quality. As mentioned earlier in this document VoIP relies on UDP to transfer audio from one user to another. Devices that transmit data using UDP which lack a packet delivery confirmation, do not listen for delivery confirmation as well as packet redirection information. This means that Cisco routed networks will require the statement “no ip redirects” on all routing interfaces which will have VoIP traffic flowing through it to prevent a router from dropping packets after sending a redirection quiz to the transmitting VoIP device. Failure to set the “no ip redirects” statement on a routing interface could result in the router telling the VoIP device to use a different routing interface for all future packets and then stop forwarding packets from that host thus assuming that the VoIP traffic has been redirected. Since the VoIP device did not listen for the redirection interrogate from the router, the VoIP traffic is in fact not being transmitted past the router. This can also happen in 1 direction but not the return direction resulting in 1 way audio (where a caller can be heard but cannot hear the person who was called).
A proper configuration of “Load Balanced” links is also required for VoIP. Though there are several methods for aggregating multiple links to increase bandwidth such as “MFR” or “Multi-link Frame-relay” which allows for multiple T1 / Serial links to be used to exceed the 1.54Mbit limit of a single T1, not all implementations of this technology are compatible with VoIP. In any “Load Balancing” scenario it is important to make sure that all traffic between VoIP end-points flow over the same links during the entire phone call. The slight difference in delivery of packets traversing 1 T1 as opposed to a 2nd, 3rd, etc T1 will cause audible “jitter” since the VoIP packets are not placed in the salubrious sequence. For example, if saying the work “the” if the sound of “e” got to the destination be fore the “th” then the word would sound garbled.
In addition to the aforementioned configuration requirements, WAN VoIP traffic should back fragmentation on serial WAN links smaller than 768Kb. The fragmentation allows the router to break through tremendous packets to send a packet of higher priority VoIP information between the now “fragmented” large data packet. Not applying this will result in dropped and disordered VoIP packets, which will be audible to parties on the call. This suggestion applies to frame, point-to-point, MPLS, and all WAN connection types. Avaya and Cisco’s recommended fragmentation for serial links is as follows:
L3 Packet Size (MTU on network) >>>>Larger
WAN Link 64 bytes 128 bytes 256 bytes 512 bytes 1024 bytes 1500 bytes
Speed
56 kbps 9 ms 18 ms 36 ms 72 ms 144 ms 214 ms
64 kbps 8 ms 16 ms 32 ms 64 ms 128 ms 187 ms
128 kbps 4 ms 8 ms 16 ms 32 ms 64 ms 93 ms
256 kbps 2 ms 4 ms 8 ms 16 ms 32 ms 46 ms
512 kbps 1 ms 2 ms 4 ms 8 ms 16 ms 23 ms
768 kbps (NA) 1.28 ms 2.56 ms 5.12 ms 10.24 ms 15 ms
Alternatives to QoS, Fragmentation, and other requirements for VoIP:
Should the requirements described in this document not be feasible, cost justified, or possible for any reason, it is strongly recommended as an alternative that a separate instruct only IP network be implemented which will hurry in parallel to the existing infrastructure. Several large organizations have decided to implement a similar, dispute only, IP networks to help with their implementations of VoIP. Although this is an alternative, it should be noted that this is not usually the least expensive method and is usually only chosen by as a means for VoIP connectivity for political and feasibility reasons.
Guidelines for Power over Ethernet
The standards for PoE have only recently been adopted which now allows Avaya phones to be powered on inaugurate standard 802.3AF versions of Cisco PoE devices. Cisco’s proprietary use of PoE supports 7watts per phone (per port) however the Avaya phones exercise 15watts max (8.5watts nominal). Because of this discrepancy, although many of Cisco’s products can provide PoE power up to 15watts, when using the 15watt phones, not all the ports on Cisco’s PoE cards and switches can supply the full-required 15 watts. Often a 48 port PoE switch can only supply 24 ports with the 15watts of power and no power on the remaining ports.
Even beyond the stated number of ports that can supply the 15watts of power on a specific card or switch, Cisco’s power supplies for switches with modular power supplies, are available in different wattages. Often it is necessary to upgrade the power supplies for a switch as well as the cards in a switch to truly support the PoE features. Empire Technologies has experienced that even with the upgraded power supplies and using only 1/2 the PoE ports on each card, some systems will serene not serve PoE for all (of the 1/2 PoE card’s) ports.
Since the standards for PoE have only recently been ratified and since Cisco often releases newer or modified versions of software and hardware it is critical that before selecting hardware or software for PoE applications to verify how the solution will wait on 15watt PoE (especially Cisco’s Catalyst 4500r 3560 series switches).
IOS Guidelines:
Unless otherwise stated, the IOS chosen for each site at a minimum should be IOS 12.2 with IP+ feature region to support dot1Q trunking and QoS prioritization. (Company Name) should verify that their routing protocols and other applications not discussed in this document are also supported by the chosen IOS (for example Cisco’s “scream” IOS’s typically does not support EIGRP).
Verification of recommended changes
It will be assumed that all requirements for VoIP, which are outlined in this document, will be implemented as arraigned by (Company Name) unless Empire Technologies is notified otherwise. If assistance is required in implementing the changes in this document Empire Technologies can provide a proposal for these services if such has not already been provided.
Assumptions to be considered VoIP ready:
- All locations will have a separate VLAN added for VoIP. The first 30 IP’s on this VLAN will not be dynamically assigned and will be reserved for static assignment. Note: VoIP networks should have at least 23 bits of sub-netting. This will serve in keeping VoIP engines and IP Phones within tolerable CPU utilization ranges
- DHCP – Server to be located at each office on a separate server except in small offices where DHCP can be provided by the local router. Having a separate DHCP scope which is reachable after a WAN link failure is important to being able to re-boot phones and maintain the ability to make and take calls (using local gateway) until the WAN becomes available again.
- TFTP – Will be centralized on a customer provided server. Must be available for all firmware updates, rolling out novel phones, and performing backups.
- FTP – Will be centralized on a customer provided server. Must be available for backup and restore of all LSP’s and Communication Manager Servers.
- Fax – All faxes are to be sent with full 10 digit dialing over PSTN (9+1+10 digit number e.g.: 9-1-212-555-1212) rather than over the WAN links.
- Modems – All modems will spend POTS line and not be connected to any PBX analog ports.
- No inbound or outbound call centers are in employ and there will be no need to overflow calling groups between locations.
- CIR – The basis for all calculations is CIR (also referred to as CAR by some service providers); as the delay that may be artificially applied to data traffic by waiting for the CIR to transmit data at a slower rate or to begin transferring data slowly at the CIR rate then additional burst bandwidth becomes available is not acceptable for VoIP. Burst speeds are only considered for data traffic as burst is not guaranteed to be available.
- Applications – The basis of this assessment is that users are running the following applications:
-Exchange for e-mail traffic (higher bandwidth)
-Explorer for HTTP traffic (normal bandwidth)
-MS File sharing
- LAN / WAN and Telephony equipment at all sites will be on UPS or UPS with generator backup.
Related Posts
Filed under Voip Phone System by on Jan 19th, 2012. 