Enterprises are rapidly adopting IP telephony for cost savings, productivity gains and business innovation. But delivering a high-quality voice service takes more than just buying the latest IP telephony equipment. Successfully deploying IP telephony to your enterprise also means understanding the requirements for delivering toll-quality voice over your company’s network infrastructure, and then appropriately planning for, choosing and deploying the right IP telephony solution. Ensuring the network is ready for IP telephony is a critical success factor.

To ensure an optimal IP telephony experience, Flexnet requires that customers undergo thorough assessment of their networks. Flexnet engineers are specially trained to assist with this assessment. As a result, Flexnet customers enjoy high standards of usability and manageability, while reducing their total communications costs.

Here are the straight facts about planning for, and deploying, IP telephony in your enterprise.

Network Requirements for Toll-Quality Voice

The LAN/WAN infrastructure must deliver sufficient throughput and meet latency, jitter and packet loss requirements.

Deliver sufficient throughput:

• The International Telecommunications Union (ITU) G.711 codec is commonly used in LAN deployments where LAN bandwidth is plentiful. With G.711 and RTP header compression, each call requires 82 Kbps.

• ITU G.729 is commonly used in a WAN environment because it uses substantially less bandwidth. With G.729 and no header compression, each call requires 26 Kbps.

  The selection of G.729 across the WAN reflects the much reduced bandwidth available between company sites. Where LAN’s nominally run at 100Mbps or 1Gbps WAN bandwidth may be as low as 512Kbps. The number of concurrent calls allowed in and out across the WAN, the encoding and the data traffic requirements need careful consideration and planning.

• With ADPCM and no RTP header compression, each call requires 52 Kbps.

Meet latency and jitter requirements:

Latency is the time from mouth to ear. It is the time it takes for a person’s voice to be sampled, packetized, sent over the IP network, de-packetized and replayed to the other person.

• Physical distance on the WAN circuit. The laws of physics dictate the speed of data travelling over copper and optic fibre.

• The IP ‘cloud’ presented by vendors all look the same but it is essential that there is a fully meshed infrastructure connecting all states to minimise the transmission paths and switch hops to arrive at its destination.

  In addition the bandwidth’s in the core need to be sufficient to carry the traffic without delay and congestion.

• The bandwidth at each site is the most obvious consideration but as noted above the cloud is also critical. The lower the site bandwidth the higher the clocking delays in transmitting the data across the link.

  For example	on a 512Kbps link a 100byte packet takes 100/512000 = 0.19ms
  	on a 4Mbps link the packet takes 100/4000000 = 0.025ms

• Finally a good quality router is essential to minimise delay. This is even more important if advanced features such as processor intensive QoS are turned on.

If latency is too high, it interrupts the natural conversation flow and can cause the two parties to confuse latency for pauses in speech. Latency must not exceed 100 milliseconds (ms) one way for toll-quality voice and must not exceed 150 ms one way for acceptable quality voice. At 150 ms, delays are noticeable, but callers can still carry on a conversation. Users hear jitter as degraded voice quality.

Jitter is variation in latency over the LAN and WAN, as the IP telephony packets arrive in uneven patterns at their destination. Jitter has many sources, including network congestion, queuing methods used in routers and switches, and routing options such as MPLS or frame relay used by carriers.

The WAN vendors existing network performance, ability to scale as their combined customer base grows its data volumes and the fundamental design factors discussed above all affect the ability of the network to provide consistent performance minimising jitter.

Packet loss requirements:

Packet loss results in a metallic sound or dropouts in the conversation. Packet loss is caused by congestion, poor line quality and geographical distance. Since IP telephony is a real-time audio service that uses the Real Time Protocol (RTP) running over the User Datagram Protocol (UDP), there’s no way to recover lost packets. If even 1 or 2 percent of IP telephony packets drop, voice quality degrades.

Specific consideration for selecting the WAN technology.

• The IP ‘cloud’ must be fully meshed connecting all states to minimise the transmission paths and switch hops to arrive at its destination.

  In addition the bandwidth’s in the core need to be sufficient to carry the traffic without delay and congestion.

• Site access technology is critical. Vendors offer a wide variety of technologies to meet a range of price and performance needs.

  • ADSL is generally accepted as the lowest cost solution but is a contention based technology. This means you are guaranteed to loose some voice UDP packets as the data passes between the site and the core network. ADSL is not recommended unless there is no other alternative.

  • G.SHDSL or SHDSL can provide a non-contended access minimising the potential for packet loss. Care must be taken to ensure a 1:1 ratio and that the offer is not just symmetric ADSL.

  • Frame Relay and Ethernet technologies also deliver excellent non-contended performance.

  • Wireless technologies are also an option for primary or back-up connections. They fall into two bread categories:

    • Microwave point to point services. These are affected by weather, transmission distance, local terrain and topology and can be problematic.
    • Mobile phone network based 3G data is emerging as a popular solution. While an excellent solution for data back-up the underlying variability of performance makes it unsuitable as a primary voice path.

  Performing a Network Assessment”

  Flexnet’s IP Telephony Network Assessment is a complete service available to help you plan, design and implement an IP telephony solution that meets your organization’s specific needs and helps ensure that IP telephony will run smoothly. The assessment is performed by qualified engineering team and is required prior to deployment.

  Flexnet’s IP Telephony Network Assessment combines real-time and simulated testing, which results in the pre-emptive discovery of network faults and potential performance problems. Flexnet uses a network performance industry leading management tools that use active application traffic to monitor and test actual applications and servers. It also collects passive performance information from IP PBXs, gateways and other network components. This provides repeatable, real-world tests for the most comprehensive performance assessment.

  The tests simulate IP telephony and the ability of the network to handle latency, jitter and packet loss (see Table 2). Flexnet also reports on voice quality in the form of a mean opinion score (MOS), which is a five-point scale established by the ITU in which 1 represents the poorest voice quality and 5 represents perfect voice quality.

  MEASUREMENT	GOOD	ACCEPTABLE	POOR
  MOS	Above 4.0	4.0 to 3.6	Below 3.6
  MEASUREMENT	GOOD		POOR
  Delay (msec)	Below 150		Above 150
  Jitter (msec)	Below 30		Above 30
  Loss (percent)	Below 1		Above 1

  
  

  By performing a pre-deployment network assessment, organizations gain an end-user perspective of network behaviour. The management tools agents allow almost immediate performance testing all the way to the desktop without the time, expense and security concerns of deploying physical resources or installing client software.

  The initial results of a network assessment are delivered in minutes, although a thorough assessment test typically runs for several days. It is vital that assessments be performed during peak operation hours to ensure an accurate picture of the network traffic. If trouble spots arise before deployment or during ongoing operations, these tools enable your solution provider or IT team to rapidly isolate the source of the problem.