Home > Articles > Cisco Network Technology > IP Communications/VoIP > VoIP Performance Management and Optimization: Managing VoIP Networks

VoIP Performance Management and Optimization: Managing VoIP Networks

Chapter Description

To ensure voice quality and to optimize media delivery over the IP, it is crucial to properly plan, design, implement, and manage the underlying network. This chapter discusses what are the best practices for planning media deployment over IP networks.

To ensure voice quality and to optimize media delivery over the IP, it is crucial to properly plan, design, implement, and manage the underlying network. This chapter discusses what are the best practices for planning media deployment over IP networks starting from how to assess the readiness of the network, traffic engineering, high availability and managing the IP network and of its integrated components that process voice and other media transmissions. Managing VoIP network starts from a discovery process that maps out the entire network by identifying all the network elements and their roles, key performance indicators (KPI’s) to track, establishing baseline, and effectively monitoring it on regular basis. This chapter will cover all the monitoring mechanism available to network administrators and their scope and effectiveness in managing VoIP. All networks are bound to experience outages. Managing outages and correlating network problems with end user problems is critical. This chapter will cover how incident management systems including trouble ticketing systems can be integrated with network management. In essence this chapter establishes the baseline for managing the VoIP networks.

Requirements for Enabling Voice in IP Networks

The task of managing the VoIP networks begins even before implementation phase when the decision is made to deploy Voice over an IP network. Since traditionally voice communications have been regarded as mission critical service supporting public safety access points for emergency services and critical business support over TDM networks, the same level of service is expected out of VoIP networks as they begin to provide the primary method of voice communications.

Network Readiness Assessment

In order to ensure same level of service, the underlying IP network must:

  • Have bandwidth and performance to handle converged services.
  • Meet the demand of high availability voice services by providing resiliency to mitigate the effect of network outages.
  • Should be modular, hierarchical and consistent to promote consistency and manageability.

This pre-deployment infrastructure assessment should address each of these areas. The infrastructure assessment is accomplished by gathering the needed information from network engineering staff to evaluate the current or planned network implementation including hardware, software, network design, security baseline, network links, and power/environment.

The following areas of the infrastructure assessment must be evaluated:

Network Design

  • Hierarchy & modularity- Network hierarchy is perhaps the single most important aspect of network design resiliency. A hierarchical network is easier to understand and easier to support because of consistent expected data flows for all applications occur on the network over similar access, distribution and backbone layers. This reduces overall management requirements of the network, increases understanding and supportability of the network and often results in decreased traffic flow problems, troubleshooting requirements, and improved IP routing convergence times. Network Hierarchy also improves scalability of the network by allowing it to grow without major network changes. Hierarchy also promotes address summarization, important in larger IP routing environments.

    Network modularity can be defined as a consistent building block for each hierarchical layer of the network and should include like devices, like configurations and identical software versions. By using a consistent “model” for each layer of the network, supportability can be improved as it becomes much easier to properly test modules, create troubleshooting procedures, document network components, train support staff and quickly replace broken components. Each defined hierarchical layer should have a basic solution that will be used repeatedly throughout the network. If enhancements or special requirements are added to specific modules then special attention should be paid to testing, documentation and supportability.
  • IP Routing- IP routing is a design issue for all larger network environments. The primary issues are that the routing protocol will converge quickly following various failure scenarios. In addition, the routing scales differently in the particular network environment. The readiness assessment process should include IP routing protocol selection, configuration, IP summarization and IP routing protocol safeguards to prevent IP overhead and undesirable routing loops. In general, Cisco recommends OSPF or EIGRP for improved convergence with added VLSM (variable length subnet mask) support. In environments that anticipate an excess of 100 routes, IP summarization is recommended into the core, generally configured at the distribution layer. For WAN environments additional summarization may be needed at the edge to reduce overhead on slower WAN links. Routing protocol safeguards are also recommended to reduce overhead and prevent unexpected routing behavior, such as routing across user or server VLANs. In larger WAN environments, it is also recommended that only routes from a particular area be routed into the core and that a particular site should not be a potential reroute point for core or other major traffic.

  • IP Addressing- IP addressing scheme’s evaluation should investigate specifically how the allocation of current IP address space will effect the allocation of IP addressing for IP phones and other communications devices. In most cases, an organization will not have available with in its current allocation IP address space within the existing user VLANs or subnets for an IP phone rollout. Several strategies exist for the allocation of space including;

    • Increasing subnet size.
    • Providing additional VLANS and subnets for phones using either additional access ports or 802.1Q trunking on user ports.
    • Use secondary interfaces to allocate additional address space where 802.1q trunking is not supported.
    • Use of Network Address Translation (NAT) should be used with caution. The VoIP network architect should explore the impact on voice signalling protocols when packets from end points with NAT’ed IP address traverse firewalls and proxy servers.
  • HSRP- HSRP, hot standby router protocol, is a software feature that permits redundant IP default gateways on server and client subnets. HSRP is configurable for router prioritization, preempt capability to return gateway back to higher priority router and “backbone track” support to track the availability of a backbone or WAN interface on the router. On user or server subnets that require default gateway support, HSRP provides increased resiliency by providing a redundant level III IP default gateway.

Other redundancy schemes for applications’ servers may include DNS or server load balancing.

  • Quality of Service- Voice quality on a network is ensured by the use of Quality of Service (QoS) features in the network. These features must be enabled and available end-to-end in a network to provide high quality voice services on the converged network.

    Voice quality is affected by two major factors: lost packets and delayed packets. Packet loss causes voice clipping and skips. The industry standard codec algorithms used in Cisco Digital Signal Processors (DSP) can correct for up to 30 ms of lost voice. Cisco VoIP technology uses 20 ms samples of voice payload per VoIP packet. Therefore, for the codec correction algorithms to be effective, only a single packet can be lost during any given time. Packet delay can cause either voice quality degradation due to the end-to-end voice latency or packet loss if the delay is variable. If the delay is variable, such as queue delay in bursty data environments, there is a risk of jitter buffer overruns at the receiving end. To provide consistent voice latency and minimal packet loss, QoS is normally needed (except in cases where bandwidth is always available). The following major rules apply to QoS in campus LAN & WAN environments:
    • Use 802.1Q/p connections for the IP phones and use the auxiliary VLAN for voice
    • Classify voice RTP streams as EF or IP precedence 5 and place them into a second queue (preferably a priority queue) on all network elements
    • Classify voice control traffic as AF31 or IP precedence 3 and place it into a second queue on all network elements.
    • Enable QoS within the campus if LAN buffers are reaching 100% utilization
    • Always provision the WAN properly allowing 25% of the bandwidth for overhead including routing protocols, network management and Layer 2 link information.
    • Use Low Latency Queuing (LLQ) on all WAN interfaces
    • Use Link Fragmentation & Interleaving (LFI) techniques for all link speeds below 768 kbps

Service Providers may employ advanced QoS features such as DQoS or RSVP to manage dynamic nature of voice enabled end points.

Network Infrastructure Services

  • DNS- DNS or Domain Name Services is a critical network naming service within almost all IP networks. Network clients and servers both request connections to other devices by specifying a name. To resolve the name to IP address a request is sent to a configured DNS server and from this point on the client can use the returned IP address. DNS servers should be located centrally within core areas of the network with backup servers available. DNS should also be set up as a hierarchy with a master and secondary so the secondary servers are updated in an appropriate time frame. Devices should also be named and routers should have DNS entries for all ports to avoid IP address conflicts. Network devices should also be set up with backup DNS servers in case the 1st chosen server is down. DNS servers should also be considered critical services within the organization requiring the highest level of security, power backup and potential redundancy. DNS may not be required in Enterprise IP Communications environments as IP addresses are configured in Call Manager and IP phones for access but is useful for managing the overall network environment. In SP networks, DNS functionality is a must as it plays a crucial role in provisioning of voice endpoints such as MTAs. It is also required for establishing voice calls since the voice endpoints rely on DNS to resolve the Call Agent’s FQDN to an IP address.

  • DHCP- DHCP is typically used for client IP addressing. This allows mobility and improves IP address manageability. The only downside is that critical IP Allocation State for many nodes is kept within one file or database on the DHCP server. An organization should have adequate support for DHCP services and treat the DHCP data as highly critical data. Generally DHCP databases should be mirrored or backed up on a continual basis. In addition, an organization should have a plan in case DHCP services fail. This can be mitigated by implementing redundant DHCP servers and distributing the load among different servers, or by configuring backup DHCP servers in case the primary server fails. DHCP servers should also support option 150 for IP phone provisioning. This permits the DHCP server to pass control to the Call Manager to download phone configurations following IP address allocation. In addition, the DHCP server should also support option 43 (vendor-specific information, option 60 (vendor class identifier), option 122 (CableLabs Client Configuration) etc. for provisioning voice endpoints in SP environments.

Network Links

  • WAN Link Redundancy/Diversity- WAN link redundancy and diversity may be a consideration for distributed IP Telephony deployments where WAN links are required for call setup and RTP voice traffic. The organization should determine the backup strategy when the primary WAN link is down. Distributed call processing and gateways or WAN redundancy may accomplish this. WAN redundancy and diversity may include local loop providers as well as long distance providers.

  • Twisted-pair installation- Copper installation standards & testing helps to ensure that the intra-building copper plant meets expected quality and performance expectations. The installation should follow standards and quality guidelines for signal attenuation, near-end cross-talk, bend radius, cable routing, distance, termination standards & components, labeling standards, patch cord routing and building conduit requirements. The current documented standard for category 5 testing requirements is TIA/EIA TSB-67 standards. All verification and testing should be done following this guideline which specifies required values for attenuation and NEXT (near-end cross-talk).

  • Fiber cabling installation- Campus/MAN fiber cabling installation standards and testing, helps to ensure that the inter-building fiber plant meets expected quality and performance expectations. The installation should follow standards and quality guidelines, which include parameters such as dB loss per connection, bend radius, cable routing, termination components or trays, labeling standards, patch cord routing and organization and building conduit requirements. All fibers should be tested following termination to ensure high-quality and minimal signal loss. Campus cabling should generally also offer diversity to prevent disasters caused by cable cuts.

Hardware and Software Considerations

  • Device Selection- Network Infrastructure devices identified for an IP telephony infrastructure should have recommended features for IP telephony and improved network convergence for High Availability. IP telephony features include Inline Power, 802.1Q/p support, hardware priority queuing and QoS. Availability feature include spanning tree convergence features like uplink fast & backbone fast. Devices should also generally have improved backplane capacity, latency and increased bandwidth. This section also looks at the Mean Time Between Failure (MTBF) of the chosen devices to determine theoretical availability. If the number of total devices is known, Cisco can also provide an expected annual failure rate for the devices.

  • Hardware Resiliency- Redundant modules and chassis are a major contributor to network resiliency and allow normal or frequent maintenance on network equipment without service affecting outages in addition to minimizing power, hardware or software failure impact. Redundant chassis can also provide load-sharing capabilities used in conjunction with routing protocols. Default gateway chassis can be redundant when used in conjunction with the HSRP protocol. Many organizations have redundant backbone chassis and redundant distribution models. Redundant modules include power modules, Supervisor modules and interface modules. Redundant modules help insure that individual module failure does not affect network availability. It is recognized that in many cases redundant chassis are cost-prohibitive at the access layer they are often a necessity due to port density with the introduction of IP telephony

  • Hardware redundancy- Redundant modules and chassis are a major contributor to network resiliency and allow normal or frequent maintenance on network equipment without service affecting outages in addition to minimizing power, hardware or software failure impact. Redundant chassis can also provide load-sharing capabilities used in conjunction with routing protocols. Default gateway chassis can be redundant when used in conjunction with the HSRP protocol. Many organizations have redundant backbone chassis and redundant distribution models. Redundant modules include power modules, Supervisor modules and interface modules. Redundant modules help insure that individual module failure does not affect network availability. It is recognized that in many cases redundant chassis are cost-prohibitive at the access layer they are often a necessity due to port density with the introduction of IP telephony

  • Software Resiliency- The software chosen must support the required features for IP telephony and provide the highest software reliability. Software reliability is a factor of software configuration and software version control. For the most part, software reliability is the responsibility of software development and testing groups within Cisco. However, the organization must still validate whether the software is appropriate for their environment by testing or piloting the intended versions. Where possible, Cisco will recommend general deployment versions. The network architect must ensure that these target versions of code have been widely deployed in many customer environments and it is believed that critical and major bugs have been resolved. Software version control is another factor of software reliability. Organizations running a limited number of software versions that have been tested or piloted generally experience higher availability due to lower complexity and reduced bug identification.

  • Software version control- Software version control is the process of testing, validating and maintaining authorized software releases within the network. Most organizations will require a handful of versions due to different platform and feature requirements. A process should be in place to choose release candidates, review potential impacting bugs, test or pilot release candidate software, deploy authorized software and review version accounting information to ensure software version control is being maintained as expected. Large organizations without software version control processes generally have well over 70 software versions within the network, resulting in a higher number of software bugs, unexpected behaviors and hardware/software incompatibility problems. Organizations requiring high availability should also weigh feature requirements with known software stability in general deployment software. Another issue is software age. Older general deployment software is considered more reliable than recently released newer versions with untested production history.

Power and Environment

  • Power protection- Power protection is often a concern in IP telephony environments and may be needed to provide parity to legacy telephone systems. Power protection for IP telephony includes the use of Inline Power to provide backup power to phones for UPS protected LAN switching gear and power protection of all critical networking components. In addition, key networking equipment should have redundant power supplies with connectivity to separate power distribution units to prevent power loss due to a tripped circuit or PDU failure. This may range from 10 minute UPS to prevent failure due to more common short-term power outages to UPS arrays with backup generators to prevent failure due to even long term power outages. The following information from UPC provides availability estimates power with various power protection strategies. In addition, the organization should consider monitoring and servicing of UPS equipment.

  • Environmental conditioning- Environment is a major factor of hardware resiliency as location and temperature of network equipment affects the MTBF, (mean time between failure), of network equipment. Standard operating surface temperatures of most Cisco equipment is approximately 40 degrees centigrade (104 Fahrenheit). When equipment fluctuates more than 10 degree centigrade the MTBF or hardware reliability of the component can be reduced significantly. To maintain documented MTBF estimates, the organization should ensure that proper HVAC (heating, ventilation & air-conditioning) is maintained for critical equipment.

  • Physical security- Physical device security should be done to ensure that unauthorized personnel do not have access to network equipment. Access to equipment allows unauthorized personnel to make unauthorized changes, obtain passwords on equipment and even perform malicious activities. Equipment should be kept in locked rooms, preferably with card access so entrance is logged.

An Audit approach for VoIP Network Readiness

A comprehensive audit of IP network is always recommended pre-deployment and even post-deployment for network optimization. Auditing methodology consists of analyzing network standards for resiliency, modularity, QoS, High Availability, IP Addressing, Security, Software version control as described earlier. The auditor should also analyze operational practices for FCAPS (Fault, Configuration, Accounting, Performance, and Security) as adopted by the organization maintaining the VoIP network.

The preliminary step of this analysis includes interviewing all the stake holders such as network administrators, architects, and network operations center (NOC)staff. The interview process will typically reveal high level information including network topology and ITIL or ISO or their own corporate standards for FCAPS in case of enterprise or commercial deployments. Service Providers may have additional standards as mandated by regulatory bodies. However, this may not present accurate and complete state of the network since compliance to standards is an ongoing process. Large networks constantly go under changes. For example, a corporate or service provider may have the most comprehensive strategy for QoS and security. But they may be in initial phases of implementation at the time of auditing. Appendix C contains the questionnaire that can be used as a starting point to gather information regarding VoIP Network Readiness.

Therefore, a subsequent step should include verification of the actual status of the network as it is deployed. Network Auditing tools are leveraged for this step. These tools are available from Cisco Advanced Services such as Unified Communication Audit Tool (UCAT), Cisco Network Collector – NetAudit, or Cisco Unified Readiness Assessment Manager (CURAM). Similar tools are also available from other vendors, for example, Vivinet Assessor and AppManager from NetIQ.

For large scale networks it becomes necessary to use a controlled sample for expediency. It is recommended to distribute the network into logical models during the interview in the first step. For example, a large international bank may have various lines of businesses, thousands of branch locations, tens of campus locations, and several international subsidiaries. The auditor should make an attempt to categories them logically such as:

  • Campus (with MAN, OC3 uplinks, 3tiered network, 6000+ employees, contact center presence, special considerations for emergency calling)
  • Small Campus (with DS3 links, 2 tiered network, up to 1000 employees, single building)
  • Data Center (with redundant OC12 links, server farms, load balancing servers, UPS, physical security)
  • Branch type A (Small branch with only consumer banking in grocery chains, Frame Relay Circuits)
  • Branch Type B (mid size branch with locker rooms, loan officers, commercial banking services, up to T1 links)
  • Branch type C (large branch with high touch services such as brokerage services, network redundancy, up to 50 employees, and multiple high speed links)

The auditor may choose to audit in detail one campus location, two small campuses where one could be an international location, all the data centers, and three branches of each type to understand the state of the network. In this process auditor must keep the dialogue open with the network administrator to ensure coverage and rectify access issues commonly faced by the assessment tools.

Analyzing Configurations, Versions, and Topology

The audit tool will look for configuration of all the devices to look for the required features as described earlier including QoS settings and redundancy in the form of HSRP or backup links and capability of access switches to provide power over Ethernet to the IP phones in future. The Configuration data will also help validate the topology of the network as it is actually implemented. In absence of such features, the audit tool must be able to evaluate if the current software version will allow the network architect/administrator to enable these features prior to deployment. The auditor should highlight the gaps and flag instances where either the hardware of software cannot fulfill the fundamental requirements for VoIP deployment. Cisco Auditing tools are capable of analyzing the configurations based on the device role according to the established network design best practices.

Traffic Simulations

Media traffic simulation on IP networks provides engineers a clear picture of how voice packets (RTP streams) will behave on the target network that is being prepared to carry voice. Test probes used to simulate and analyze streams use two methods:

  • Deploying traffic generators on the edge of the network where the end points are intended to be installed. These traffic generators are controlled via central console which instructs them to choose appropriate codec, number of media sessions and streams, and the target destination. The central console will then collect metrics including delay, jitter, packet loss and MOS/PESQ score estimates for these calls. This information is collected by means of RTP Control Protocol (RTCP), which provides information about the RTP streams related to packet statistics, reception quality, network delays, and synchronization. The information collection method may involve SNMP MIBs, XML, or even simple commands issued on command line interface (CLI) of the traffic generator by the central console. The central console should attempt to run same number of calls as expected during the busiest hour of the day. All codec variation should be explored for this test
  • Traffic emulation can also be performed using a rather simpler method which imploy a central traffic generator which sets network devices including switches or access routers as “reflectors”. These designated reflectors should be as close to the edge of the network as possible to cover the entire path taken by the RTP packet containing media. The central traffic generator will simulate media streams towards all of these reflector and record same parameters including delay, jitter, packet loss or other voice metrics for analysis. Cisco IOS has a feature called “IP SLA” which can configure a central device to generate traffic towards multiple reflectors. This method can generate large amount of traffic to accurately emulate the expected network load. IP SLA based method compensates for its internal serialization delays to provide accurate statistics.

The transmission statistics including voice quality metrics information is collected by means of RTP Control Protocol (RTCP), which provides information about the RTP streams related to packet statistics, reception quality, network delays, and synchronization. The information collection method may involve SNMP MIBs, XML, or even simple commands issued on command line interface (CLI) of the traffic generator by the central console.

Managing network capacity requirements

In order to perform meaningful capacity planning it is necessary to understand the traffic engineering theory and know what are expected traffic flows in the VoIP network. Call Detail Records (CDR) can provide this information accurately. This data can be helpful in migrating TDM voice networks to VoIP or expandinfg the capacity of existing VoIP networks such that the proper service level agreement (SLA) is preserved.

Traffic Engineering Theory

In traffic engineering theory, you measure traffic load. Traffic load is the ratio of call arrivals in a specified period of time to the average amount of time taken to service each call during that period. These measurement units are based on Average Hold Time (AHT). AHT is the total time of all calls in a specified period divided by the number of calls in that period, as shown in the following example:

  • (3976 total call seconds)/(23 calls) = 172.87 sec per call = AHT of 172.87 seconds

The two main measurement units used today to measure traffic load are erlangs and centum call seconds (CCS). One erlang is 3600 seconds of calls on the same circuit, or enough traffic load to keep one circuit busy for 1 hour. Traffic in erlangs is the product of the number of calls times AHT divided by 3600, as shown in the following example:

  • (23 calls * 172.87 AHT)/3600 = 1.104 erlangs

One CCS is 100 seconds of calls on the same circuit. Voice switches generally measure the amount of traffic in CCS. Traffic in CCS is the product of the number of calls times the AHT divided by 100, as shown in the following example:

  • (23 calls * 172.87 AHT)/100 = 39.76 CCS

Which unit you use depends highly on the equipment you use and what unit of measurement they record in. Many switches use CCS because it is easier to work with increments of 100 rather than 3600. Both units are recognized standards in the field. The following is how the two relate: 1 erlang = 36 CCS. In this document we will use CCS.

Capacity planning in voice networks is based on the busiest hour of the day. In order to determine the traffic load we need determine know how many calls each station makes during the busy hour. This number is known as the number of busy hour call attempts (BHCA). Once BHCA and AHT are known the resulting traffic load in CCS can be calculated using the following formula:

  • CCS = BHCA × AHT/100

Example of Estimating Capacity Requirements

The following section describes what one might call a traffic reference model for the a retail chain’s IP Communications network supporting it’s nationwide retail stores. Currently this retail chain has 225 stores and plan to add275 additional sites to this network. The numbers are based on the Call Detail Records provided by the network administrator of the retailer during for the week of Thank Giving in United States when they expected to do most business. This period was chosen since it represents the busiest time of the year for this retailer. Following calculation are based on this CDR data:

Call Detail Record Analysis

  • Number of sites: 225
  • Call rejected due to Out of bandwidth: None
  • Call rejected due No circuit/channel available: None
  • Total Call Seconds: 1804730
  • Total Calls: 13077
  • Sample size: 6 days (weekly report extracted from the IP PBX covering about 148 hours)
  • Average Hold Time (AHT): (Total Call seconds 1804730/ total calls 13077) = 138 sec.
  • CCS: (13077*138)/100/6 = 3007.7

    (6 is the number of sampled data points)

  • Cumulative Call Attempts: CCS/AHT * 100 = 1076/138 *100 = 2179
  • Total call attempts during busiest hour (Friday after thanksgiving between 12PM and 1PM) = 778
  • Per Device BHCA : 2.8

Network Bandwidth Estimate

Total call attempts during busiest hour (Friday after thanksgiving between 12PM and 1PM) = 778

This was for 225 sites.

For 500 sites we assumed this number can potentially reach up to 1600 for voice calls alone using simple interpolation.

Each G.729 call takes about 28.6Kbps. We round it to 32Kbps for calculations.

G.711 call consumes about 80Kbps. G711 codec was used for calls from fax machines and PoS devices constituting 18% of all calls(932 out of 4831).

(1600 * 32kbps * 0.82) + (1600 * 80kbps * 0.18) = 65.024Mbps

We then projected it for future expansion of the network that is able to support more sites. This estmates is calculated to be around 98Mbps.

The network architect or the administrator must plan for this amount of bandwidth and include any packet overhead given the protocol(s) choice and use of compression methods. All the links that this traffic may traverse should be provisioned accordingly with sufficient overhead to support redundancy. QoS scheme must take into account this capacity so the priority queues on network devices used by RTP packets containing media are adjusted and traffic shaping mechanism is in effect for the correct bandwidth amount.

PSTN Trunk Requirement Calculations

If all of these calls has to egress to PSTN through a gateway at the edge of the VoIP network, Erlang formulas would be used to calculate the trunk requirements. This example is for 23 bearer channel ISDN PRI circuits.

Cumulative Erlang (3150 end points): 268

Per endpoint Erlang: 0.085

Projected Erlang for 500 stores (7000 endpoints):572

Assuming desired blocking rate is no more than 1%, the Erlang B formula will tell us that we need 587 DS0 lines. Please see the Erlang B calculator at the following URL:

Here is a trunk sizing table based on different Erlangs and service level (blocking rate):

Erlang Calculations for Determining PSTN Trunk Capacity Requirement

Erlangs per phone

Total Erlangs

BHCA (7000 users)

Blocking rate (Service level)

Number of Trunks needed

0.085

572

19,600

0.05

557 DS0 or 24 PRIs

0.085

572

19,600

0.01

599 DS0 or 26PRIs

Monitoring Network Resources

It is crucial to proactively monitor the network resources. All call processing systems offer methods to report resource utilization. In Cisco Unified Communications Manager, there are cause-codes defined to monitor. Here is a set of minimum recommended parameters to be monitored regularly:

  • Trunk Resources (cause code 34 – Channel not available)
  • Network Availability (cause code 38 – Network out of order)
  • Conferencing Resources (Cause code 124 – Conference full)
  • Bandwidth starvation (cause code 125 – Out of bandwidth)
  • Other resources such as transcoders (cause code 47)

This table lists the number of calls disconnected for abnormal reason that need further investigation. The reason may include oversubcribed PSTN trunks, conference bridges, or lack of bandwidth. The analysis is done for one hour block of time.

Critical Disconnect Causes by time of the day as reported in CDR

Time of Day

Cause code 34 Channel not available

Cause code 38 Network out of order

Cause code 124 Conference Full

Cause code 125 Out of bandwidth

Cause code 47 Resource unavailable, unspecified

1-2

1

1

2

0

1

2-3

3

4

2

2

2

3-4

4

4

4

4

2

4-5

4

2

5

5

5

5-6

1

1

1

1

1

An Audit for gauging the current VOIP network utilization

The VoIP network utilization can be tracked by looking at device and link utilization as described in this section.

Device Utilization

A baseline identifying current device resource utilization is recommended to determine the potential impact of IP Telephony traffic. A baseline is normally done by monitoring peak (5 minute) utilization using SNMP over an extended period of several days to a week. This is normally done for CPU, memory, backplane utilization and LAN buffers. Most SNMP tools will allow the organization to collect and graph the utilization over this period. The result should identify peak utilization. If peak values exceed 50%, the organization should consult with their Cisco representative to determine the potential impact.

Router Readiness Ratings

The table below shows how router measurements were rated. Ratings should be based on the router result ranges for this assessment:

Router Utilization Measurements

Measurement

Good

Acceptable

Poor

Average CPU Utilization (%)

Less than or equal to 30.0

Less than or equal to 50.0

Any higher value

Average Memory Utilization (%)

Less than or equal to 30.0

Less than or equal to 50.0

Any higher value

Input Queue Drops (%)

Less than or equal to 2.0

Less than or equal to 8.0

Any higher value

Output Queue Drops (%)

Less than or equal to 2.0

Less than or equal to 8.0

Any higher value

Buffer Errors

Less than or equal to 0

Less than or equal to 1

Any higher value

CRC Errors (%)

Less than or equal to 2.0

Less than or equal to 8.0

Any higher value

Switch Readiness Ratings

The table below shows how switch measurements were rated. Ratings should be based on the switch result ranges for this assessment:

Switch Utilization Measurements

Measurement

Good

Acceptable

Poor

Average Backplane Utilization (%)

Less than or equal to 50.0

Less than or equal to 75.0

Any higher value

Average CPU Utilization(%)

Less than or equal to 30.0

Less than or equal to 50.0

Any higher value

Link Utilization

A baseline identifying current trunk link utilization is recommended to determine the potential impact of IP Telephony traffic. A baseline is normally done by monitoring peak (5 minute) utilization using SNMP over an extended period of several days to a week. Most SNMP tools will allow the organization to collect and graph the utilization over this period. The result should identify peak utilization and busy hour data traffic requirements. The organization can then estimate overall requirements based on estimated peak IP Telephony traffic.

Link Readiness Ratings

The table below shows how link measurements were rated. Ratings should be based on the link result ranges for this assessment:

Link Utilization Measurements

Measurement

Good

Acceptable

Poor

Average Bandwidth Utilization (%)

Less than or equal to 30.0

Less than or equal to 50.0

Any higher value

Latency

0-20ms

21ms-120ms

Above 150ms

Jitter

0-20ms

21ms-120ms

Above 150ms

Packet Loss (per hours basis)

Under 15

15-30

Any higher value

Measurements for Network Transmission Loss Plan

Every VoIP network still has to interface with PSTN or PLMN for greater reachability to all the communication devices worldwide. This exposes the TDM-IP hybrid network to even more sources for echo and other quality issues related to voice signal due to power loss, impedance mismatches and excessive delay. Therefore a network transmission loss plan (NTLP) must be established during pilot phase of the VoIP implementation. NTLP maps a complete picture of signal loss in the entire path identifying areas of improvements including signal strength adjustment at various points to help the echo cancellers (ECAN) on media/voice gateways. There are two primary reasons to establish a loss plan:

  • Desire to have the received speech loudness at a comfortable listening level
  • Minimize the effect of echo due to signal reflections that are caused by impedance mismatches at the 2-to-4 wire conversions in the transmission path

NTLP maps a complete picture of signal loss in the entire path identifying areas of improvements including signal strength adjustment at various points to help the echo cancellers (ECAN) on media/voice gateways.

NTLP uses following concepts to make loss calculations in the voice network:

  • Send Loudness Rating (SLR) is defined as the loudness between the Mouth Reference Point (MRP) and the electrical interface
  • Receive Loudness Rating (RLR) is defined as the loudness between the electrical interface and the Ear Reference Point (ERP)
  • The Overall Loudness Rating (OLR) of a connection is the sum of the sending terminal SLR (Sending Loudness Rating), any system or network loss, and the receiving terminal RLR (Receive Loudness Rating). The long-term goal for TELR is 8-12 dB, but because of the mix of technologies, the short-term goal is 8-21 dB. The difference between OLR in both directions should be no more than 8 dB.

    OLR = SLRtalker + [sum]attenuations + RLRlistener

  • Talker Echo Loudness Rating (TELR)— It is the loudness loss between the talker’s mouth and the ear via the echo path. TELR is calculated as follows:

    • TELR(A) = SLR(A) + loss in top path +ERL(B) or TCLw(B) + loss in bottom path + RLR(A), where ERL is the echo return loss of the hybrid or echo canceller, and TCLw is the weighted terminal coupling loss of the digital phone set.

The degree of annoyance of talker echo depends both on the amount of delay as well as on the level difference between the voice and echo signals

The following figure show sample calculations for on-net calls

The following figure show sample calculations for off-net calls

Any Voice Quality test set should be able to measure the above mentioned parameters necessary to develop accurate Network Loss Plan prior to wide scale IP telephony deployment. Sage Instruments probes were used to conduct the tests in the above two examples.

The value of TELR would be plotted against the one way delay measured for the test calls on the chart with “Echo Tolerance Curve” specified by ITU-T G.131 standard for Echo as illustrated in figure 6-3.

An attempt should be made to bring the coordinates above in the acceptable range by modifying gain setting on the TDM voice gateway. Digital Signal Processors (DSP) on Cisco gateways are equipped with echo cancellers providing (ECANe) echo cancelling enhancement to conceal the echo in the speech path.

2. Effectively Monitoring the Network | Next Section