IPT Calling on a Bad WANIPT Calling on a Bad WAN

The vendors have implemented very little or no technology workaround to compensate for poor WAN call connections.

There is no argument that the data WAN produces problems for IP Telephony when it does not work properly. So what happens when there is poor WAN QoS or the WAN has failed?I surveyed a number of IP Telephony vendors to see how their systems reacted to the WAN problems. My queries were divided into two parts:

1. What is the response by the VoIP endpoints/server if the WAN connection to the server is lost before or during a call?

2. What is the response by the VoIP endpoints when the call quality degrades during a call but the WAN connection to the server and other endpoint remains operational?

Most of the vendors replied. This blog will discuss the responses, not compare one vendor's solution to another vendor's solution.

All of the vendors have one or more solutions for the loss of the server WAN connection. I learned that endpoints have a "keep alive" message that is sent to the server periodically, about every 30 to 60 seconds. This keep alive message informs the server that there is a usable signaling connection to the endpoint. The server responds to the keep alive message, within a limited period of time, to the endpoint informing that the server still has a useable signaling connection.

This keep alive message runs continuously. When about three keep alive messages do not generate a response, the endpoint attempts to register to the backup server. It does not matter whether there is a call in progress or not.

There is another keep alive message operating between the primary and backup servers. When this keep alive message disappears, then the backup server takes over in tens of seconds. Check with your vendor to learn of this operation and its speed of execution.

There is a switchover time when the endpoint moves to the backup server. This switchover time varies by vendor solution (seconds to tens of seconds). The enterprise should investigate how long the switchover takes. The switchover may not be noticeable in an enterprise if the phone calls are not frequent. In a call center, the switchover time could cause a noticeable downtime that would affect the efficiency of the call center. One vendor has a distributed signaling function that eliminates the switchover time. Other vendors have an option in the endpoints--dual registration. This speeds up the switchover time. During the switchover, the calls in progress will not be lost in the SIP signaling systems. If your implementation uses a proprietary signaling protocol or possibly H.323, check with your vendor to see if the calls stay up during the switchover.

The second problem, poor QoS, presents more issues for the vendors. Most of the vendors' endpoints collect WAN performance information: latency, jitter and packet loss. Some collect the information using the standard, Real Time Control Protocol (RTCP). Other vendors use proprietary information collection techniques. A few collect more performance information using the standard RTCP XR (eXtended Reporting). This means that there is sufficient information to determine if the WAN is producing QoS problems during the call. Some vendors use this collected information to calculate a Mean Opinion Score (MOS) for the call at the end of the call for later analysis, but not during the call.

Here are the possible responses to a poor QoS WAN connection occurring during the call:

*The server could establish a new call path to compensate. This would require the endpoints to report WAN performance in real time, not at the end of the call. I did not find a vendor that did this.

* The endpoints could create smaller packets and/or change to a non-compressed voice packet during the call so that the call could tolerate poorer WAN performance. I did not find a vendor that did this.

* The server could block future calls over this WAN connection to avoid poor quality calls. Some vendors do this. However, this solution does not allow new calls to be made over the WAN.

* As an alternative to the blocked WAN calls, the next call could be passed to the PSTN to complete the call. Some vendors perform this call-around feature over the PSTN.

* The server could move the call from a poor WAN path to PSTN path in real time (without interrupting the call) thereby supporting the call in progress. No vendor does this.

What I found was that the vendors appear to address the WAN QoS as a design problem for the WAN. The vendors have implemented very little or no technology workaround to compensate for poor WAN call connections. One vendor said they or the customer could write an application to perform some of the suggested responses. I have heard, "the intelligence in the network" often, but here is a case where little or no intelligence is applied. This further demonstrates that the management of IP Telephony networks need more work by the IPT vendors and/or third party management software vendors.The vendors have implemented very little or no technology workaround to compensate for poor WAN call connections.