Mixing Voice & Date(Part One)
By Dr. Peter Welcher, Senior Consultant-Instructor

Cisco is starting to have quite a story concerning mixing voice and data traffic. Cisco announced a partnership with NEC America to integrate voice and data networks and they also have partnerships with Symbol Technologies, Inc. concerning Voice over IP, andwith GRIC Communications, Inc. concerning Internet phone gateways and settlement services.

This two part article will condense the vast amount of information available into a high level overview. Part one will focus on the history, technology and some options.

But StrataCom has also focused on voice technology. They have several pieces of technology that enhance their voice offerings: mature echo cancellation, various choices of voice compression, and voice activity detection (VAD). The idea is to compress voice, suppress echo (in effect, reflected signal), and squeeze out periods of silence. The other end of the link needs to insert "pink noise", little active sounds that we all listen for to tell us the phone circuit is active. All of these affect our perception of the quality of the voice circuit.

When you compress voice, it has to be uncompressed so a typical PBX can deal with it. In so-called Tandem PBX voice networks, voice traffic is routed through one PBX to get to another. The ensuing double compression degrades the quality of the voice signal. To help with this, StrataCom has Voice Network Services (VNS), whereby you can use your StrataCom ATM network and PNNI routing to route voice traffic directly from one PBX to another. The single hop between PBX's improves compression quality. It eliminates redundant voice trunks needed for Tandem PBX switching. And ATM PNNI provides rapid dynamic re-routing when there is an outage.

Cisco / StrataCom has been doing voice for 11 years; this is mature technology. What's changing fast now is the cost of implementing it, and the platforms it is implemented on.

Voice compression can give good quality at 8 Kbps, especially if multiple compression cycles are avoided.

Technical issues in dealing with voice compression include delay and delay variation (jitter), echo cancellation, background noise, silence suppression, and language sensitivity. Other issues: avoiding double compression cycles (Tandem PBX's), and distinguishing modem and fax traffic (which can't be compressed, or can't be compressed in the same way).

Of these issues, delay and jitter, and double compression are network design issues. They impose constraints on where voice networking is going to work as well as desired. For now, note that Voice over the internet is probably not going to give you the quality you'd like - unless the cost savings out weigh the poor quality. We will return to this topic later.

The remainder is technical issues, quality of the voice coding circuitry and software. Note that silence suppression saves at least 50 percent of the one-way bandwidth, since there's only one speaker at a time. Using compression offers the prospect of trading standard PCM at 64 Kbps for silence suppressed CS ACELP at perhaps 4 Kbps or less.

Let's convert that to the (over-simplified) sales argument for this. If your company has multiple T1's carrying voice circuits between sites, and you can reduce your leased line charges to 4/64 = 1/16 or 8/64 = 1/8 of what they are now, well, that could be a healthy amount of money. Realistically, the savings aren't that simple, because there are other benefits and costs. You should look at the numbers in relation to your own setting, voice and data traffic, and carrier pricing.

There are alternatives: buying dedicated gear that does voice only over trunks, between PBX's. Doing it yourself offers the chance to combine voice and data trunks, reducing leased line costs and perhaps combining some of the operations and management overhead as well. You may be able to deliver a higher quality of service as well.

From the corporate perspective, there's a basic choice if you're going to mix your voice and data traffic. Do you try to do your own trunking between sites, or does a service provider do it for you?

The argument for doing it yourself is cost, control, and perhaps quality. If you aren't getting the quality of service you want, persuading a service provider to give better service could be a bit tough. Perhaps in the future we'll be able to pay more and get lower latency; that market is still trying to emerge. The argument against doing it yourself is cost (staff, staff skills, equipment and management, maintenance, etc.).(See Figure 3)

The multiflex trunk divides the T1 by time slots, allowing N x DS0 for Frame Relay or HDLC, M x DS0 for PCM voice, and K x DS0 for TDM channels or video. The multiflex can alternatively be used to do T1 or E1 ATM instead. ATM use supports MPOA, CES voice, or compressed voice in AAL5 cells. Built in channel bank allows cross-connects from the serial interfaces and the voice modules to slots on the multiflex trunk (MFT). Signaling is similar to the 3600 voice card, see below.

You can put a 3810 at a remote site, and have the remote phones look like home phones connected to extensions on a central site phone switch. You could also have some calls go off-net. You can also route data and provide CES video if needed: an all-in-one box!

Local: calls within the same system
On-net: interoffice calls
Off-net: connection to "outside line" (PSTN) (dial 9)
PLAR: automatically dials an extension
Tie line: tie-line replacement between PBXs
Autoconnect: connect PBX to outside line
On-Net to Off-Net: reroutes calls off net

Using the multiflex capability, you or your service provider could connect to you via T1. The T1 could be set up so that it provides 6 voice circuits to the public phone net (PSTN), and Internet link, 384 K for video, and 256 K Frame Relay carrying data and voice to a central site.

The StrataCom IGX voice modules will provide somewhat similar capabilities for voice in an ATM setting, at higher densities. Larger enterprises needing more than 24 compressed voice channels may want to investigate this further. The MC3810 capabilities are designed to interoperate with Universal Voice Module (UVM) cards for the IGX.

Be careful to distinguish here between ATM circuit emulation (CES), and compressed voice. In the former, the ATM switch acts as super-mux, providing some fixed amount of bandwidth. You set up a 64K CBR circuit - unused bandwidth can be used for data. Voice compression and so on do not apply to CES. Compressed voice is treated as (special) data, potentially saving bandwidth. You can send compressed voice over ATM, as ABR AAL5 traffic. Relevant standards: FRF.12 (Frame Fragmentation) and FRF.11 (Voice Signaling Carried in Frame Relay). The first of these is appropriate to fragment large Frame Relay frames into small frames, so that the small voice frames can leave the router faster, without waiting for an entire 1500 byte data frame to be transmitted. The second is so one compliant device can signal another across Frame Relay. The Cisco devices are, I believe, not FRF.11-compliant, since Cisco needs an extra byte for Voice Network Signaling (VNS), to allow Tandem PBX bypass. This may change. The virtue is that with this you can have only one compression cycle in a Frame Relay Star topology - tandem switch traffic never hits the central PBX! Currently, the MC3810 requires static mapping of E.164-like addresses to Frame Relay PVC's if Frame Relay is used. There is a design issue here: do you use a full mesh of Frame Relay PVC's, to carry voice traffic directly to its destination, or do you route via a central site, at the cost of two hops and poorer voice quality? Your choice! The practical issue: finding a Frame Relay service provider who can sell you low-delay PVC's. Article continued in next issue of The Network Monitor