Welcome to another edition of “Notes from Downstream,” where I discuss the issues impacting the network performance of the various data and multimedia streams flowing through your network. While optimizing the network for both data and voice is crucial, so is monitoring the quality of experience that your users perceive from VoIP and video applications. In this column, I will focus on a vital part of this quality of experience: call setup performance.

 

Why should you be concerned about call setup performance? The reason is that the user’s first perception of the availability of a phone system is typically based on the call setup performance. From a user’s perspective, phone system availability can be summarized with the following basic criteria:

 

·        Do I get a dial tone when I pick up the phone?

·        Does the call connect successfully?

·        If so, does it connect within a reasonable amount of time?

 

To understand this aspect of user experience, you need some metrics beyond those used for traditional networked applications. IP telephony experts rely on three metrics that relate directly to call setup performance to help them measure the likely user experience when interacting with the system: delay to dial tone, post-dial delay, and call setup failures.

 

The first user experience with a phone is likely the audible presence of a dial tone. To produce a dial tone, the IP phone sends a message to the call server letting it know that the phone is now off hook. And the call server sends a message back to the phone instructing it to play the dial tone. The time it takes for the off-hook message to be sent and the call-server response to be received is called the ?delay to dial tone.

 

The components involved in the delay to dial tone metric are the network round trip time (NRTT) and some amount of server processing time required to receive the off hook message and send the response. Network congestion and/or server congestion can both be culprits when delay to dial tone values are excessive. An overloaded call server can be slow to respond with the message telling the phone to play a dial tone.

 

How much delay is too much when waiting for a dial tone? A reasonable time is 2 to 4 seconds. Any delay beyond 4 seconds may cause the user to think that the phone system is down. The delay to dial tone metric usually only applies to outbound IP call legs. By contrast, an inbound, voice gateway call leg would not have a delay to dial tone metric because the dial tone for the PSTN phone is nearly instantaneous. And there are other cases where a delay to dial tone metric may not be applicable. For example, many voice-integrated unified communications applications provide “click to dial” features that let you dial a number by pressing a button or clicking on an icon. In these cases, you may not get a dial tone; the call is dialed immediately.

 

After the user dials a phone number, the next thing he or she expects is to hear a ringing or busy tone. The post-dial delay is the time elapsed between when the last digit of the phone number is dialed and when the user hears the call indication (ringing or busy). The PSTN has set the bar for post-dial delay quite high (or low, as the case may be). Calls on the PSTN usually connect in a very short period of time.

 

In a VoIP network, this same level of performance can be achieved, with some careful tuning and management. Some guidelines have been established for the post-dial delay metric and are accepted industry-wide. The ITU E.721 standard defines target values for different call types.

 

The post-dial delay metric depends on the protocol flows that occur after the user has entered the last digit of the phone number.

 

When examining the post dial delay metric, you should not factor in user time. For example, a caller may start dialing a number and then pause to look up the rest of the number. Post-dial delay calculation begins after the last digit in the number is pressed, or in some cases after the entire number is sent in a single flow.

 

Perhaps the first thing to look at more closely when investigating a performance issue with excessive post-dial delay is the configuration of the dial plan in the phone system. The dial plan is configured at the call server and/or gateway. It contains the information needed to route calls to their destination. The way the dial plan is structured can actually introduce an unnecessary delay in call processing.

 

In a variable-length dial plan, for instance, the call server or gateway must wait to make sure that the user will not enter more digits. For example, you might have a dial plan that allows numbers like 42xx or 42xxx. If a user dialed the number 4203, it could match either one of the two patterns: 42xx or 42xxx. Anytime a number is dialed, the call server or gateway must therefore wait to make sure that the user is not going to enter another digit. This delay is often called the interdigit timeout, and it is usually a configurable parameter on the call server and gateway. The default value may be as high as 10-15 seconds. This means that a user could enter the last digit of a phone number, but the phone would not ring until 10-15 seconds later, when the interdigit timeout expired and the call server or gateway let the call proceed.

 

 

In addition to delay to dial tone and post-dial delay, the final aspect of call setup performance that requires VoIP-specific measurements is whether the calls are actually connecting successfully. When a call fails during the setup phase, often a “fast busy” tone is played by the phone. A call can fail to connect for many reasons. Cisco (News - Alert) has a lengthy list of call failure cause codes in “Cisco Unified CallManager Call Detail Record Definitions.”

 

A call setup failure in some cases may be expected. Access lines to the PSTN are a valuable, limited resource—a fixed cost for any organization. Because it is too cost-prohibitive and inefficient to provide a dedicated PSTN line for each employee, most enterprises operate on the assumption that not all users are on the phone at any given time. Depending on the calling patterns and volume at your enterprise, this is probably a good assumption. Traditional telecom professionals have a set of established metrics for tracking the percentage of time that a telephone user attempts to make a call and cannot get an outbound line (call setup failure code = 34). For a given phone system, the probability that an attempted call will be blocked is called the Grade of Service (GoS). One way of calculating GoS is shown by the following equation:

 

 

A common metric used in telecom SLAs, GoS is expressed as a decimal fraction. A GoS of <= 0.01 is the typical benchmark. This value means that 1% or less of the call attempts failed.

 

Proactive monitoring of the key user experience metrics for call setup – delay to dial tone, post dial delay, and call setup failures – is an important part of any management plan. In my next column, I will discuss how to troubleshoot call setup performance issues.