Table of Contents:

Definition and Overview

1. Introduction

2. Universal Port Overview

3. Universal Port Architecture

4. Universal Port Implementation Challenges

5. Selecting an RAS Solution Partner

6. Summary

7. References

8. Universal Port Software Features

Self-Test

Glossary

PDF of this tutorial

Modem

It is important for an RAS platform to support not only the latest International Telecommunications Union (ITU) standards but also older standards as a result of the wide array of legacy modems and applications that adhere to these older standards. For example, credit-card authorizations for point-of-sales (PoS) transactions use low-speed modems (e.g., V.21 and V.22). These older modems cost very little to implement in PoS terminals. Moreover, the time required to establish a connection is much shorter than with a V.90 modem because the modulation scheme is much simpler. Because credit-card authorization requires little information to be exchanged (e.g., credit-card number and the purchase amount of transaction), the lower throughput of the modem connection is not an issue. It is the call holding time of each credit-card transaction that is more important.

Considering that there are literally hundreds of brands and models of modems in use, interoperability and performance testing, often referred to as hardening, is absolutely essential to provide an effective RAS platform. The hardening process consists of functional testing, stress testing, soak and stability testing, and performance testing, including extensive live-line testing in the field. Key performance metrics for modems include connection success rate and throughput versus different network models representing real-world conditions and modem interoperability.

There are many poorly implemented dialup modems in use around the world. These modems often violate ITU standards and contain software bugs that cause misbehavior. New soft modems that use the PC’s main processor to perform modem functions are notorious for bad behavior, as a result of interactions between the modem software and other applications running on the PC.

RAS equipment manufacturers do not have the luxury of telling a service provider that their customers must replace these bad modems. Instead, the RAS equipment manufacturer must develop modem software that is forgiving and can connect successfully with all modems. Thus, it is important for the modem software to be tested continually with hundreds of different modems to ensure interoperability under different line conditions. It is also important for the modem software to support built-in remote trace and debug capabilities to diagnose problems when they occur, both for development and deployment of the actual system.

Fax

Fax software hardening is similar to dialup modem hardening. Interoperability with bad fax modems and machines is a requirement. For fax relay, it is important to note that fax machines were designed for the analog PSTN and do not handle the delay and jitter conditions of packet networks very well. Therefore, the fax relay software must perform additional processing to overcome the effects of packet networks.

The delay of fax packets through a packet network causes the precise timing that is required for the fax protocol to be skewed and can result in a dropped call. Although the fax-relay protocols are able to compensate for this skewed timing to help ensure that calls are carried to completion, additional processing steps are required to reduce the risk even further. One technique is called spoofing. It emulates a continual conversation between the sender and receiver, ensuring that neither fax machine drops a call inadvertently.

Lost packets can be a more serious problem for fax relay than for VoP. In a voice conversation, lost packets can be addressed by replaying last packets and by other methods of interpolation. Fax relay conversations, however, have more severe constraints on the loss of data because the fax protocol can fail if information is lost. The severity of the problem varies depending on the type of fax machine and whether error correction mode is enabled.

The fax-relay software must be tested over various network conditions, including delay, jitter, and lost packets, to make sure that the protocol software is robust and that the proprietary fax machine spoofing techniques are able to ensure successful connection between fax machines. These techniques must also provide successful page transfer (including multiple pages) and good-quality images at the receiving fax machine. It is also important to conduct interoperability testing with other vendors' implementation of the fax-relay protocol standards (e.g., T.38).

Voice

Latency causes two problems: echo and talker overlap. Echo is caused by the signal reflections of the speaker’s voice. Echo becomes a significant problem when delay is greater than 50 milliseconds. Because echo is a major quality problem, RAS equipment providers must implement echo cancellation for VoP solutions. Talker overlap becomes significant if one-way delay is greater than 250 milliseconds, so every effort must be made to minimize delay. The sources of delay in a packet network include the following:

This delay is caused by the need to collect a frame of voice samples to be processed by the voice coder. It varies from a single sample time (.125 microseconds) to many milliseconds. Standard voice coders (and their frame times) include the following:

• G.728 LD–code excited linear prediction (CELP)—2.5 milliseconds
• G.729 CS–ACELP—10 milliseconds

This delay is caused by the actual process of encoding and collecting samples into a packet for transmission. The encoding delay is a function of both the processor execution time and the type of algorithm used. Often, multiple voice-coder frames will be collected in a single packet to reduce overhead. This is useful when the different voice conversations go to the same destination, as can be the case for a trunking application. For example, three frames of G.729 compressed speech, equaling 30 milliseconds of speech, may be collected and packed into a single packet. Thus, the protocol overhead is reduced by two-thirds, as one packet containing three voice frames is sent rather than three packets of one frame each. This process of encapsulating several small packets into a single larger frame is called concatenation.

Network delay is a function of the processing that occurs as packets are sent across a network. This delay is caused by the transmission time across the physical medium, the accumulated delays introduced by the networking equipment (routers and switches) used to transmit the voice data, and the buffers used to remove packet jitter on the receive side. These jitter buffers are used to remove the variable time between packets (jitter) created by the varying times at which each packet arrives. This delay can be a significant part of the overall delay, as it can be as high as 70 to 100 milliseconds.

One of the keys to good VoP quality is having a hardened line echo canceller that can properly cancel echo. Echo is present even in a conventional POTS network. However, it is acceptable because delay is less than 50 milliseconds, and the echo is masked by the normal side tone that every telephone generates. PSTN standards require echo cancellation if the delays exceed 50 milliseconds. Echo becomes a problem when packet networks and the PSTN are used together, because the delay in packet networks is often greater than 50 milliseconds. Due to the network topography, however, the PSTN echo cancellers do not perceive the delays from the packet network, so they do not attempt to perform echo cancellation. Thus, echo-cancellation techniques within the packet domain must be used. The ITU defines performance requirements that are required for echo cancellers. The original standard for echo cancellers was ITU Recommendation G.165. A more stringent set of requirements is provided in ITU Recommendation G.168. These standards provide a series of objective performance tests but do not describe how to implement an echo canceller, nor do they address the subjective performance of an echo canceller. A good echo canceller must have the following attributes:

• removes echo well—This includes removing echo at the start of a call as well as preventing any form of echo during a call.
• handles doubletalk well—Doubletalk occurs when both sides talk simultaneously. It can be handled by not clipping the voice at the beginning or end of a doubletalk voice spurt.
• handles background noise well—This includes handling high background noise and variable background noise.

Echo in the form of speech that is reflected back to the speaker is generated toward the packet network from the remote PSTN. The echo canceller compares the voice data received from the PSTN with voice data being transmitted to the packet network. The echo from the telephone network is removed by a digital filter on the transmit path into the packet network.

The delay problem is compounded by the need to remove jitter (i.e., variable interpacket timing caused by the fact that packets do not all cross the network at the same speed). Removing jitter requires collecting packets and holding them long enough to recreate the original speech without annoying gaps in the audio. Obviously, holding the packets causes additional delay, but the quality of the speech is dramatically enhanced. The conflicting goals of minimizing delay and removing jitter have led to various schemes aimed at dynamically adapting the size of the jitter buffer to minimize its impact on latency.

QoS techniques are evolving that will give priority treatment to voice in a packet network, but until these enhancements are widely deployed in the network switches and routers, voice packets will be treated exactly like data. Under peak loads and congestion, voice packets may be dropped just like data packets. The data packets, however, are not time-sensitive, and dropped packets can be recovered through a retransmission protocol such as TCP. Lost voice packets are not handled in the same manner as data because voice retransmission causes unnecessary delay. Some techniques used by VoP software to address the lost-packet problem are as follows:

Interpolate for lost speech packets by replaying the last packet received during the interval when the lost packet was supposed to be played out. This technique is a simple method that fills the time between noncontiguous speech frames. The time interval that is being filled is normally so small that the ear does not perceive that the information has been repeated. It works well when the incidence of lost frames is infrequent. It does not work very well if there are a number of consecutive lost packets or a burst of lost packets.

Send redundant information at the expense of bandwidth utilization. The basic approach replicates and sends the nth packet along with the (n+1)th packet. This method has the advantage of being able to correct for the lost packet exactly. However, this approach uses more bandwidth and also creates greater delay.

A hybrid approach uses a lower-bit-rate voice codec to provide redundant information carried along in the (n+1)th packet. This reduces the problem of bandwidth consumption but does not solve the problem of delay. In addition, the voice quality may be negatively impacted by the lower resolution of the low bit-rate codec and may introduce compatibility issues if a nonstandard voice codec is used.

Often overlooked amidst the many technical challenges and considerations of voice, fax, and modem is the issue of patent infringement. While many people may assume this is a minor issue or simply a matter for lawyers to address, the fact is that this is a very significant business consideration for equipment providers in the IP market. There are literally thousands of patents that cover the implementation of hardware, protocols, software, and other technologies associated with packet-based communications.

It is not an exaggeration to say that it is nearly impossible to deliver a complete universal port system without confronting this issue at some point. Depending on the particular patents and the parties involved, the cost could be high enough to force a company to scrap its product plans altogether. Increasingly, equipment providers are looking to silicon and software developers to provide indemnification against patent issues that may arise regarding technology implementation. In a world in which litigation is commonplace, this is a harsh reality for technology firms that may never have faced such issues in the past.