Voice/Fax over Frame Relay vs.Voice/Fax over IP

INTRODUCTION

The development of very fast, inexpensive microprocessors and special purpose switching chips, coupled with highly reliable fiber optic transmission systems, have made it possible to build economical, ubiquitous, high-speed packet-based data networks. Similarly, the development of very fast, inexpensive digital signal processors (DSPs) has made it practical to digitize and compress voice and fax signals into data packets. The natural evolution of these two developments has been to combine digitized voice and fax packets with packet data, creating integrated data/voice networks.

This convergence of telecommunications and data communications has been motivated primarily by the cost savings that accrue from operating a single, shared network. A corporation with a wide area packet data network extending to each of its branch offices can often integrate its intracompany voice and fax traffic with its data network and save enough in intracompany toll-calls to pay for the DSP-based integration equipment in less than one year. The overall savings usually results in an effective toll-rate of 1-to-2 cents per minute averaged over the five-year life of the network.

The total savings often adds up to tens of thousands of dollars per remote site; a 50 branch international network can readily enjoy better than a million dollars of cost savings. Even an integrated, domestic-only North American network, where toll-costs are already low, can save over $10,000 per remote site over a five-year period.

Packet Data Networks
There are a several different types of wide area packet data networks that can support integrated voice/fax traffic, with varying degrees of success. The principal data network technologies in use today are X.25, Frame Relay, ATM, SNA, Novell/IPX, TDM, and TCP/IP. Because TDM is not a packet technology, it is much less efficient than the other technologies, and is rapidly being replaced by them. X.25 and SNA, based on older packet technologies, are too slow and delay-prone to effectively carry voice and fax traffic. The Novell/IPX technology was designed primarily for LAN applications and does poorly in the WAN environment; it is quickly being replaced by TCP/IP.

The remaining packet technologies - Frame Relay, ATM, and TCP/IP - are the principal networking techniques companies use today to build new wide area data networks. Today's WANs are constructed using leased lines running these three technologies, and using public data network services based on them. By a substantial margin, Frame Relay and TCP/IP are used the most, both over leased lines and as public data services.

WAN Market
According to the December 1997 issue of Data Communications magazine, the largest WAN market segment is leased-line services, at worldwide revenues of $15.6 billion forecast for 1998, followed by Frame Relay services at $6.2 billion, commercial TCP/IP services at $6.2 billion, and ATM services at $0.6 billion. The corresponding growth rates (1997 to 1998) are forecast at 10% for leased lines, 59% for Frame Relay, 30% for commercial TCP/IP services, and 109% for ATM.

ATM, Frame Relay, and TCP/IP are each able to carry voice and fax traffic. ATM has been designed from the beginning to carry voice/fax traffic, while Frame Relay and TCP/IP were originally designed to carry only data. Because adding voice and fax to Frame Relay and TCP/IP has been an 'after market' activity, there are areas of caution and even concern that must be addressed when companies build integrated WANs using Frame Relay or TCP/IP.

This paper discusses these issues, provides guidelines for voice/data integration, and furnishes recommendations for the best course of action in three networking scenarios:

◆ When adding voice and fax traffic to an existing corporate data network.
◆ When building a new integrated corporate voice/data network.
◆ When building a new voice/fax packet network to carry public voice/fax calls.

CORPORATE VOICE/DATA INTEGRATION

Adding voice and fax to corporate Frame Relay (hereafter, FR) networks or TCP/IP (hereafter, just IP) networks require the deployment of a voice/data integration device (VDID) at each corporate location. For Frame Relay, the device is a voice/fax-enabled router or Frame Relay access device (FRAD) (see Figure 1a). For IP, the device is a voice over IP (VoIP) gateway (see Figure 1b).

In both cases, the device connects to legacy telephony equipment, usually a PBX, key telephone system (KTS), or a fax machine on one side, and to the network on the other side. The VoIP gateway connects to the location's LAN, not directly to the WAN. VoIP gateways are fundamentally LAN devices, relying on existing non-voice/fax-enabled routers to provide WAN access. The FRAD, on the other hand, connects directly to the WAN as well as the telephony equipment. In addition, it can also provide routing functionality as well as legacy connectivity over the WAN.

Figure 1a: Typical voice over Frame Relay network

Figure 1b: Typical voice over IP network

Digitized Voice and Fax
Analog and digital voice and fax signals enter the VDID where they are processed by a DSP and converted into data packets. Analog voice is first digitized at 64Kbps using the PCM format, compressed into a reduced format (typically 8Kbps CELP), and placed into the appropriate packet type (FR or IP). Digital voice from the PBX is already in PCM format, thus the PCM conversion step is omitted. The far-end VDID reverses the process, taking the compressed packets, decompressing them to 64Kbps, and playing the information out in the appropriate format (analog or digital). The process operates simultaneously at both ends for full-duplex speech. The term 'CODEC' is used to represent the COmpression/DECompression technique or process.

Analog fax is also digitized at 64Kbps into the PCM format, then demodulated by the DSP back into the original digital format it had inside the fax machine and placed into the appropriate packet type. At the remote VDID, the digital stream is remodulated back into the fax's original format.

All DSP activity occurs in real-time. Digitized voice/fax packets are placed onto the LAN by the VoIP gateway and onto the WAN by the voice/fax-enabled router/FRAD (RFRAD). The VDID telephony connections are either analog or digital trunks. There are usually 2-to-4 analog VDID trunks at smaller remote sites, 4-to-8 analog or digital trunks at regional locations, and 8-to-24/30 or more digital trunks at a headquarters location.

Determining VDID Trunk Requirements
Since the cost to integrate voice/fax with data depends largely on the cost of the VDID equipment required at each site, and the VDID cost is proportional to the number of VDID trunks, only the minimum necessary number of trunks is provisioned. Two trunks will handle about 3 hours of intracompany phone/fax communications over an 8-hour day with a 95% likelihood of the caller receiving dial-tone on the first try; four trunks will handle about 12 hours, and so on. Table 1 summarizes VDID trunk capacity information.

From experience, the 95% dial-tone availability figure is just high enough not to frustrate the user from using the VDN (and thereby defeating the cost savings). Higher percentages can be used, but the increased number of VDID trunks required increasingly negates the cost savings.

	Number of VDID Phone/Fax Trunks
Period	2	4	8	12	24
1 Hour	0.4	1.45	4.32	7.6	19
2 Hours	0.7	2.9	8.64	15.2	38
4 Hours	1.5	5.8	17.28	30.4	76
6 Hours	2.2	8.7	25.92	45.6	114
8 Hours	2.9	11.6	34.56	60.8	152
9 Hours	3.3	13.05	38.88	68.4	171
	Number of Hours of 95%-available Dial Tone per Period

Table 1: Synopsis of VDID trunk capacity

At the headquarters location, the trunk count is often derived as a percentage of the total number of branch trunks. For example, 20 remote branches with two trunks each, totaling 40 trunks, would in most cases require only 15-to-20 trunks at headquarters. The branch trunks would contend for the pool of headquarters trunks, with a contention ratio between 8-to-3 (40-to-15) to 2-to-1 (40-to-20). Table 2 summarizes some common contention ratios.

Number of Remote Trunks	Number of Remote Sites with Two Trunks per Site	Typical Number of Headquarters Trunks	Typical Contention Ratios
2	1	2	1:01
4	2	3-4	1.3:1 - 1:1
6	3	4	1.5:1
8	4	5-6	1.6:1 - 1.8:1
10	5	5-6	1.7:1 - 2:1
16	8	8-9	1.8:1 - 2:1
24	12	10-13	1.8:1 - 2.4:1
32	16	13-16	2:1 - 2.5:1
64	32	24-29	2.2:1 - 2.7:1

Table 2: Contention ratios of total remote trunks to HQ trunks

Calling Over the Voice/Data Network
To place a call using the voice/data network (VDN), a user in one location calls a party at another location by first dialing a fixed, published access number, usually a '6' or '8.' This instructs the caller's PBX to select the next available trunk connecting the PBX to the location's VDID. The VDID immediately generates dial tone to the caller's ear. The caller keys-in the telephone number of the called party. This is usually a location number and an extension. The VDID translates the number into the network address of the called party's VDID (remote VDID) and forwards the extension to this VDID.

The remote VDID feeds the extension number to the called party's PBX, which rings the called party's phone. The two VDIDs establish a packet telephony circuit between them across the VDN, and conversation commences. If the called party's phone is busy, or the VDIDs cannot find or connect to each other, appropriate busy tones are generated by the calling VDID. When one or both parties are connected to KTS's instead of PBX's, the calling sequence is similar, except the caller punches the appropriate key to select the VDN, and there is no called-party extension when the remote VDID connects to a KTS.

Importance of User-Transparency and Legacy Telephony Interoperability
The entire calling sequence is transparent to both parties, as if they were using PBX tie lines, KTS off-premise extensions, or speed-dial buttons. This is very important in corporate VDN environments because the cost to retrain users on how to make phone calls would negate much of the intended savings. In the above scenario, the telecom manager only needs to publish a one-page memo with brief instructions and a list of the branch location numbers.

Furthermore, if a user has to go through an involved, new calling sequence, such as those involved when using a PC as a telephone, in most cases the user would take the easier approach and just use the PSTN, frustrating any cost savings. In the business environment, a user will not tolerate any reduction in the level of telephony service just to reduce the company's phone bill. The user is measured on getting the task done, not on reducing overhead expenses. At home, the consumer may well tolerate less convenient or reduced quality telephone connections to reduce personal telephony costs, but that willingness does not translate to the business environment, where telephony costs are not personal.

Another key characteristic of corporate voice/data integration is the use of existing, legacy telephony equipment. If the VDID or VDN require new telephony equipment, the cost savings from toll avoidance would be offset by the cost of the new equipment, nullifying the integration proposition. The new equipment, moreover, would require user retraining, already a non-starter. For these reasons, corporate WAN voice/data integration does not incorporate the desktop PC as a mainstream telephony device.

VOICE/DATA INTEGRATION DEVICE FUNCTIONALITY

Most VDIDs (RFRADs and VoIP gateways) interface to legacy telephony equipment in similar ways and perform the similar DSP-based voice and fax signal processing. Although a specific vendor's VDID will have its own particular set of features, there is a minimal set of functionality that is required to achieve the basic goals of user-transparency, legacy telephony interoperability, low bandwidth consumption, and attractive cost savings.

Basic Functionality

◆ FXS, FXO, and E&M analog trunk interfaces, 2&4 wire, ground start and loop start. These connect to PBX's, KTS's, or directly to telephones and fax machines.
◆ T1 and E1 digital trunk interfaces for PBX connectivity. Both T1 and E1 should include basic Channel Associated Signaling (CAS) and Common Channel Signaling (CCS) support.
◆ Ability to generate dial tone, busy tone, and trunk busy tone to the calling party, and ringing signaling to the called party instrument.
◆ Last packet replay (for voice only) to make up for late, corrupted, or dropped voice packets. Replaying the last voice packet smoothes over the gap, and the listener usually does not notice this when it occurs infrequently. Corporate networks are normally well behaved, with very low packet loss.
◆ Port contention with hunt groups, allowing a local VDIC to access the next available trunk on a remote VDIC. The trunks can be grouped, allowing controlled access within a specific group.
◆ Automatic trunk busy-out when the VDIC detects a problem with one of its trunks, with itself, or with the WAN. This presents as a busy signal or trunk-busy signal to the caller.
◆ Speech compression supporting natural speech conversations with excellent full duplex voice quality, at a compression rate of 8Kbps or less (not including any packet overhead).
◆ Silence suppression with low-bandwidth (1Kbps or less) comfort noise or background noise regeneration. Silence suppression should reduce bandwidth requirements by at least 50%; it should not introduce any noticeable clipping at the beginning of speech activity.
◆ Echo cancellation. This is not acoustic echo cancellation, rather it is reflected-energy cancellation. When a two-wire telephone cable connects to a four-wire PBX interface or to a telco central office (CO) interface, a special electrical circuit called a hybrid is used to convert between 2-wires and 4-wires. Although hybrid circuits are very efficient in their conversion ability, a small percentage of telephony energy is not converted but instead is reflected back to the caller. This is called echo.
◆ When the caller is near the PBX or CO switch, the echo comes back so quickly that the speaker cannot discern it. However, when the delay is more than about 10 milliseconds, the caller can hear an echo. To prevent this, VDID's include special DSP code that listens for the echo signal and subtracts it from the incoming audio signal. Echo cancellation is especially important because network delays can easily be 40-50 milliseconds, so the echo from the far-end hybrid can be quite pronounced at the near end. Far-end echo cancellation eliminates this.
◆ Fax support in real time for G3 fax, to 9.6Kbps.
◆ Accurate Dual Tone Multi-Frequency (DTMF) tone regeneration, sufficient for most voice-mail and similar applications.
◆ Digit store-and-forward (no second dial tone) for transparent dialing plan implementation.
◆ Call setup time of less than 3 seconds.
◆ Support for at least one Ethernet LAN connection.
◆ Centralized control of all VDIDs, for alarm, status monitoring, diagnostics, database maintenance and operating code maintenance.
In addition to these VDID necessities, the better voice/data integration devices also support several enhancements that improve the user experience, reduce costs, expand the level of telephony interoperability, and improve manageability.

Enhanced Functionality

◆ Cross-platform port contention, transparent to the caller. When a local VDID is requesting a trunk from a far-end VDID, and there are none available (all are in use or otherwise busied-out), VDIDs with cross-platform port contention will select another VDID until a trunk is found.
◆ Support for Token Ring LANs.
◆ SMNP support, allowing standards-based network management.
◆ Voice/fax on any port, at no extra cost. Voice or fax is auto-detected without user intervention, based on the nature of the signal.
◆ Dynamic jitter buffering, automatically self-adjusting to the delay characteristics of the WAN. See below for a discussion of delay and jitter.
◆ Country-specific tone and ringing signaling. This allows VDID users in different countries to hear tones they are familiar with, reducing any retraining issues and promoting VDN usage.
◆ Flash-hook pass-through, allowing a remote user to control special PBX functions that depend on the usage of the flash-hook. These can include voice mail and other call-processing functions.
◆ Precise DTMF or Multi-Frequency (MF) tone detection and regeneration, both at the beginning of a call and during the call. This guarantees the caller can control all far-end telephony applications that use DTMF.
◆ Any of DTMF, MF, or pulse at one end to any of DTMF, MF, or pulse at the other end.
◆ Centrex support, for FXO to FXO call disconnect supervision. This assures that the call will be disconnected.
◆ No central point of failure. A central directory server, for example, that does not have a redundant back-up unit somewhere else in the network would be a central point of failure. Many VDIDs distribute directory information to the individual VDIDs, avoiding this problem.
◆ Scalability to many VDIDs, for large VDNs. Networks where hundreds of VDIDs are currently installed.
◆ Force connect or equivalent (sometimes called ring-down), enabling a caller to cause a pre-determined far-end phone to ring whenever the caller goes off-hook.
◆ Call inhibit and receive inhibit settings, controlling who can make certain calls and who can receive certain calls.
◆ Full gain control including input level gain and output level gain settings, to tune the quality of the speech that is affected by the relative strength of the electrical telephony signal entering and exiting the VDID.
◆ Controllable ringing frequency, to customize the ringing of the telephone.
◆ Fully packaged platform (versus just selling boards or software). Some VDID vendors only sell boards or software, requiring a customer to buy from a systems integrator, introducing the possibility of finger pointing when there is a problem.
◆ Redundant power supply option, for added integrity at large sites. For smaller sites, with less than 8 VDID trunks, the site can use the PSTN as a backup if something in the VDN or data network fails; redundancy is usually not required. For larger sites, however, PSTN access as a backup for a large number of failed VDID trunks is usually unavailable, so reliability and redundancy are key.
◆ Call-accounting for corporate bill-backs. Some users will bill the remote branch offices to recover the cost of deploying the VDIDs and any costs for extra VDN bandwidth.
◆ Local emulation capability so that one site can have any interface with any protocol independent of other sites on the network. This is not possible with 'transparent passthrough.'
◆ A variety of signaling-system support within CAS and CCS. There are several different signaling-systems that are specific to certain PBX's or country conventions.
Because VoFR has been mainstream for over five years, FRADs are usually more fully featured than VoIP gateways when compared on a similar cost-per-trunk basis. The feature gap, however, is closing and will probably be negligible in 2 to 3 years. Beyond the feature gap, though, there are other important differences that are intrinsic in the nature of each VDID's packet technology.

COMPARING VoFR AND VoIP PACKET TECHNOLOGIES

There are four main areas of material differences between VoIP and VoFR packet management technologies:

◆ Packet overhead
◆ WAN access-line carrying capacities and associated cost implications
◆ Packet prioritization
◆ Packet segmentation or fragmentation and its effect on data packet sizes
Each area of difference presents more of a challenge to the VoIP gateway approach than the VoFR approach, both because VoFR is more mature and because VoIP has a few inherent technological handicaps.

Comparing VoFR and VoIP Packet Overhead
The main handicap is the greater packet overhead required by IP. Both FR and IP packets are constructed with packet header information, voice/fax header information, and the digitized, compressed voice and fax information (the payload).

Each payload represents a fragment of speech called a 'talk spurt.' Representing a long talk spurt requires the VDID to accumulate the speech information over an extended period of time, and possibly introducing delay into the conversation. Conversations with added delay sound unnatural and cause the corporate telephony user to bypass the VDN, defeating any hoped-for cost savings. This delay-limiting requirement dictates a maximum talk spurt size for voice (and consequently, fax) of 50 bytes at a compressed data rate of 8Kbps (1000 bytes per second, or one byte per millisecond). Fifty bytes represent 50 milliseconds of speech activity, the longest practical period without contributing too much to the overall delay.

Tables 3a and 3b show the bandwidth consumed in Kbps for FR and IP telephony packets. The speech compression CODEC is assumed to need 8Kbps. The sum of the CODEC bandwidth and the packet overhead is the peak bandwidth consumed by an active conversation. The peak only occurs for a few seconds and is replaced by 0Kbps during the natural periods of silence in a typical conversation. While one person talks, the other listens, yielding silence about 50% of the time over a 20-30 second period. Pauses and interruptions in the conversation contribute another 10%. The net bandwidth consumption averaged over the 20-30 second period is about 40% of the peak bandwidth. These figures are borne out in studies done at Bell Labs.

The method in which silence suppression is implemented can affect both the perception of voice quality and bandwidth consumed. Absence of sound is often perceived as a broken connection because the listener is accustomed to hearing a certain minimal level of background noise or 'comfort noise'. There are two methods of solving this problem. The first is to inject white noise generated by the VDID at either end of the connection to let the listener know that the connection is alive. The advantage of this method is that it does not consume any bandwidth over the WAN link. However, it results in a reduced level of perceived voice quality. The other method involves actually sampling the background noise. This method produces a significant improvement in voice quality, but consumes more bandwidth. The way that the comfort noise feature is implemented differs with each vendor and can often be configured by the network manager. Bandwidth consumption can vary from 0 to 2Kbps, plus overhead.

Typical CODEC Bandwidth	8Kbps
Frame Relay and Voice/Fax Packet Overhead	2Kbps
Total FR Bandwidth	10Kbps
Less 60% Silence	- 6Kbps
Net Bandwidth Consumption Averaged over a 20-30 Second Period for an Active Speech Conversation	4Kbps

Table 3a: VoFR packet overhead and average bandwidth consumption

Typical CODEC Bandwidth	8Kbps
IP/UDP and Voice/Fax Packet Overhead	7Kbps
Total IP Bandwidth	15Kbps
Less 60% Silence	- 9Kbps
Net Bandwidth Consumption Averaged over a 20-30 Second Period for an Active Speech Conversation	6Kbps

Table 3b: VoIP packet overhead and average bandwidth consumption

The IP packet overhead is an estimate for the WAN environment. It can range up to 9Kbps when the IP packet is encapsulated in another protocol, such as Frame Relay's RFC 1490. If the router accessing the WAN performs header compression, the overhead will be reduced. Because of the wide mix of routers in corporate networks, we will assume the routers do not have header compression, and use the 7Kbps figure. The overhead in the LAN environment can be as high as 9Kbps due to Ethernet or Token Ring encapsulation, but LAN bandwidth consumption is usually unimportant.

Comparing VoFR and VoIP Bandwidth Consumption
The preceding figures indicate that IP telephony traffic consumes about 50% more WAN bandwidth than FR telephony traffic. Actual measurements bear this out. The implications for the corporate VDN are two-fold: fewer active virtual voice/fax trunks on the WAN access line, and less bandwidth left over for non-telephony traffic ('residual bandwidth'). The first implication comes from simply dividing the WAN access line's bandwidth by the peak trunk bandwidth. On a 64Kbps FR WAN access line, for example, there can be a maximum of 64/10 = 6 active voice trunks, compared to a maximum of 64/15 = 4 active voice trunks for a 64Kbps IP line.

If the comfort noise feature is used to improve voice quality, the difference between VoIP and VoFR bandwidth consumption becomes even more pronounced. A 1Kbps background noise sample transmitted during periods of silence, would mean adding 4.8Kbps (1Kbps + 7Kbps overhead = 8Kbps, less 40% active speech = 4.8Kbps) to the net bandwidth consumed for VoIP and 1.8Kbps (1Kbps + 2Kbps overhead = 3Kbps, less 40% active speech = 1.8Kbps) for VoFR. This would bring the total average bandwidth consumed to 10.8Kbps and 5.8Kbps for VoIP and VoFR respectively, a significant advantage for VoFR.

The method of simply dividing the WAN bandwidth by the peak trunk bandwidth assures there will never be voice trunks competing for bandwidth, assuming there is no high priority data traffic (see below for this case). This simple division approach does not, however, take into account the beneficial effects of statistical multiplexing. With stat mux effects, the trunk count will go up, depending on the original trunk count and the acceptable level of dropped voice/fax packets.

The stat mux effect only applies to higher speed WAN lines. For example, a T1 (1.5Mbps) line will support about 150 trunks according to the division method, but about 185 stat muxed with 99.9% packet integrity. Because the level of packet integrity required can vary by application, and because the trunk counts in corporate data/voice networks are rarely this high, we will disregard the stat mux effect in corporate applications and consider it only in pure voice/fax applications. The second implication is slightly more complicated, and requires a discussion of the duty cycle of a voice/fax trunk. When the VDIC trunk is not in use, the net bandwidth consumption is 0Kbps. The actual amount to time a VDIC trunk is in use is called the trunk's 'duty cycle.' It varies according to the number of VDIC trunks, and normally does not exceed a loading factor that corresponds to the appropriate 95% dial-tone availability figure.

Table 4 shows the likely maximum average duty cycles for various trunk counts, assuming an 8-hour day. In Table 4, for example, the maximum average percent of time a single VDIC trunk is active is 36% over an 8-hour day (as one of 4 trunks carrying the maximum amount of traffic consistent with a 95% dial-tone availability target). The 36% average usually develops over a 20-30 minute period (this is different from the 20-30 second period mentioned above for silence suppression), and implies that the amount of bandwidth the trunk consumes on average over this period is 36% of 6Kbps (for IP) or 4Kbps (for FR), that is, 2.2Kbps for IP or 1.4Kbps for FR.

Number of VDIC Trunks	2	4	8	12	24
Maximum Average Percent of Time ('Duty Cycle') Trunks are Active	18%	36%	54%	63%	79%

Table 4: Maximum average duty cycles for various trunk counts

By taking the appropriate duty cycle for each trunk count, the minimum average amount of residual bandwidth that is available for other data traffic can be calculated. For example, with 2 FR trunks, each trunk has an 18% duty cycle. Both trunks combined can support 2.9 hours per 8-hour day of 95% available dial tone. Each trunk consumes 10Kbps peak, 4Kbps with silence suppression, and 0.72Kbps (4K x 18%) averaged over 20-30 minutes. The residual bandwidth on a 64Kbps line would be 64.0-0.72 = 63.28Kbps.

Comparing VoFR and VoIP WAN Telephony Trunk Capacity (With Data Integration)
Table 5 shows the residual bandwidth that is available for data averaged over a 20-30 minute period (this is access bandwidth less the total of the trunk duty-cycle bandwidths) for both FR and IP approaches. It also shows the number of VDIC telephony trunks that will fit in a given WAN access bandwidth (access bandwidth divided by total peak trunk bandwidth) for both FR and IP.

The amount of residual bandwidth determines whether it will be necessary to increase the WAN access bandwidth to support adding voice and fax traffic to the existing data traffic. The goal, when adding voice and fax to corporate data networks, is to avoid having to add bandwidth if at all possible. The extra cost to add bandwidth can significantly reduce the savings that come from the 'free' phone and fax calls. If the corporate data network has enough spare bandwidth, then there will be no additional bandwidth costs.

For a given access speed, the residual data bandwidth for FR and IP are similar, within 7% of each other. The difference is in the number of VDIC trunks that the line will carry. Note that the figures given for the number of telephony trunks at the higher WAN access speeds (above 256Kbps) are conservative; no allowance has been made for the beneficial effects on the trunk capacity by statistically multiplexing voice/fax traffic.

	Frame Relay Packet with Overhead		IP Packet with Overhead
WAN Access Bandwidth (Kbps)	Maximum # Router or FRAD Trunks**	Residual Bandwidth (Kbps)*	Maximum# VoIP Gateway Trunks**	Residual Bandwidth (Kbps)*
28.8	2	27.4	1	27.7
33.6	2	32.2	2	31.4
56	5	47.6	3	51
64	6	53	4	55.4
128	12	98	8	102
256	25	176	17	184
384	38	247	25	264

Table 5: WAN access link packet trunk carrying capacity
* Residual bandwidth averaged over a 20-30 minute period; 8-hour day is assumed.
** Voice/fax trunks, analog or channelized digital, connected to the PBX, KTS, CO, or fax machine. No allowance is made for the beneficial effects of stat muxing trunks.

Another useful way to view this information is by trunk count, as shown in Table 6. Although the amount of bandwidth consumed by VoIP is 50% higher than VoFR, when the application is voice/data integration (versus just voice/fax) this has less of an impact than it might seem. Because the average residual bandwidths are so high, the percentage differences between them are fairly small.

For example, 4 trunks require a minimum of 40/60Kbps (FR/IP). They leave only 24/4Kbps out of a 64Kbps line at their peak bandwidth consumption (all 4 speakers speaking in the same direction at the same time). This is a large difference in favor of FR - by a margin of 6 to 1. However, they leave an average of 58.2/55.2Kbps residual bandwidth, only a 5 percent advantage for FR. Even with 24 trunks running over a 512Kbps trunk, the FR residual-bandwidth advantage is just 10%.

			Residual Bandwidth (Kbps) FR/IP
Voice Trunks	Minimum Bandwidth Req'd (Kbps) FR/IP	Avg. with Silence Suppression (Kbps) FR/IP	Avg. with Duty Cycle (Kbps) FR/IP	28.8Kbps WAN	56Kbps WAN	64Kbps WAN	128Kbps WAN	256Kbps WAN	512Kbps WAN
2	20/30	8/12	1.4/2.2	27.3/NF	55/54	63/62	127/126	255/254	511/510
4	40/60	16/24	5.8/8.6	NF/NF	50/NF	58/55	122/119	250/247	506/503
8	80/120	32/48	17/26	NF/NF	NF/NF	NF/NF	111/102	239/230	495/486
12	120/180	48/72	30/45	NF/NF	NF/NF	NF/NF	98/NF	226/211	482/467
24	240/360	96/144	76/114	NF/NF	NF/NF	NF/NF	NF/NF	180/NF	436/398

Table 6: Bandwidth consumption
* NF denotes not enough bandwidth for the VDIC trunks' minimum bandwidth to fit (no fit); 8-hour day assumed.

Integrating Voice/Fax with Background and Real-Time Data
The preceding discussion was based on the assumption that real-time, low-delay voice and fax traffic on VDNs is given priority over non-real-time data (sometimes called background data). This includes e-mail, file transfer, and browser traffic. By-and-large, background traffic can be briefly (seconds, not minutes) delayed in favor of real-time traffic without impacting the end-user. This has been borne-out in field measurements.

In fact, the marriage of voice/fax and data over WAN links has a mutually advantageous relationship. For low-speed WAN access, data is usually background and voice/fax is real-time. For high-speed access, there is often a mixture of real-time and background data with real-time voice/fax. But, there is no material real-time data vs. real-time voice/fax conflict because voice/fax consumes a small amount of bandwidth. Prioritizing it first does not usually adversely slow down real-time data on high-speed lines, whether FR or IP.

This way of combining voice/fax and data has changed considerably from the past. Before the advent of DSP and packet technologies, voice/fax typically consumed a constant 64Kbps without the possibility of silence suppression or the duty-cycle factor. Data consumed a small amount of bandwidth and was added onto voice/fax networks. Today, voice/fax averages 1-3Kbps, around 2-4% of 64Kbps (as much as a 50-fold improvement).

When there are real-time or quasi-real-time data applications, such as SNA, running over a low speed WAN access line, it is necessary to subtract the real-time data's bandwidth from the line's bandwidth to determine how much residual bandwidth is available for voice and fax. For example, if a 19.2Kbps SNA data stream is running over a 56Kbps link, the residual 36.8Kbps could be used for voice/fax traffic. This would allow two (IP) or three (FR) VDIC trunks (50% more for FR, a significant difference). The remaining bandwidth would be available for background data.

Moreover, because of gaps in the SNA data stream - usually about 50%, or 9.6Kbps in this case - another 9.6Kbps would be available for additional background data communications. With 2 VDIC trunks, voice/fax would average 1-2Kbps, SNA would average 9.6Kbps, and a total average of 44Kbps would be available for background data communications.

Comparing VoFR and VoIP WAN Telephony Trunk Capacity (Without Data Integration)
Heretofore we have compared VoFR and VoIP in an integrated data/voice environment. Although the voice/fax IP packet size is 50% more than the VoFR packet size, the residual bandwidth remaining for data is similar, especially at access speeds of 56Kbps or higher. The main disadvantage is the reduced number of VoIP telephony trunks that can be carried on a WAN access line compared to the number for VoFR, potentially a serious handicap at access speeds lower than 64Kbps.

When the discussion turns to a pure packet voice/fax environment, the situation is substantially more favorable toward VoFR. If a company is just running voice and fax on a WAN line - with no data - the residual bandwidth is of no value. In this case, Table 5 shows that VoFR maintains a consistent 50% advantage over VoIP, directly corresponding to the packet-length ratio.

For example, on a T1-speed connection between the US and Japan, VoFR will support 153 simultaneously active voice/fax connections, with an 8Kbps CODEC, compared with 102 for VoIP, not counting any statistical multiplexing advantages (which would accrue proportionally). If this connection were part of a commercial international telephony-bypass operation that sells toll-minutes to the public or other carriers, profits would be seriously impacted.

In the corporate voice/data setting, only rarely would a T1 line to a remote office be expected to carry more than, say, 60 voice/fax conversations; typically this would be more like 15-30. A substantial majority of the bandwidth would be used for data. In this case, the residual bandwidth figures would predominate, and FR would not be heavily favored over IP.

Network Delay and Jitter
One of the key ingredients of good voice quality and high user acceptance is low voice delay. Delay is introduced by several means: by the VDID's CODEC, by the VDID's WAN/LAN functions, by the WAN itself (both the WAN devices and WAN media), and by telephony equipment. In almost no cases does the LAN introduce any material delay.

Delay is often discussed in terms of both the average delay and the variation in delay. The variation in delay is called jitter. Average delay describes the average length of time a VDN packet takes to move from a local VDID to a remote VDID. Jitter describes the variability in the arrival time of VDN packets. Latency is a term often used to describe the sum of the average delay and the jitter.

As VDN latency exceeds about 200-250 ms, the two parties will increasingly adopt a half-duplex communications mode, where one speaks, the other listens and pauses to make sure the speaker is done. If the pauses are ill timed, they end up 'stepping' on each other's speech. This is the problem that occurs when two people converse over a satellite telephony connection. The result is a reduction in perceived voice quality.

When a VDID packet is inordinately delayed and does not arrive at the far-end in time to fit into the voice stream playing out from of the far-end VDID, it is discarded, and the previous packet is replayed. If this happens too often or twice in a row, the listener will perceive reduced voice quality.

To allow for variable packet arrival time and still produce a natural stream of speech, the far-end VDID does not play out the speech as soon as the first packet (after a period of silence) arrives. Instead, it holds the packet for a certain time in part of its memory, called the jitter buffer, and then plays it out. The amount of this hold time is the measure of the jitter buffer, e.g., a 50 ms hold time implies a 50 ms jitter buffer.

The jitter-buffer hold time adds to the overall delay, so if the network has high jitter, the overall effect will be a long perceived delay in the voice stream. For example, a VDN might have a moderately average delay of 130 ms and a variability of 5 ms. The VDN is said to have 5 ms of jitter, a low figure. The jitter buffer-hold time is only 5 ms so the effective latency will only be 135 ms, still moderate.

On the other hand, if a VDN has a low average delay of 50 ms, but 10% of the time the delay goes out to a long 200-250 ms (while 90% of the time the delay is a brief 33 ms), the jitter buffer would have to be 200-250 ms and the latency would be 250 ms, a high figure. Jitter can be more important than average delay in VDN applications.

While a high jitter buffer will compensate for chronically late packets, it adds to the latency. A low jitter buffer will reduce the latency but may be so small it frequently misses slightly delayed packets. It can be difficult to pick the right jitter buffer because VDN jitter conditions can change throughout the day. For this reason, the better VDIDs use dynamic jitter buffering that is constantly adjusting to the smallest size that is consistent with good voice quality.

Comparing VoFR and VoIP Packet Prioritization
For voice/data integration to work well over corporate VDNs, the VDN's jitter and average delay (together, latency) must be low; less than about 200 ms. One of the key means of achieving low latency is voice/fax packet prioritization. The means of achieving prioritization, however, are different for IP and FR. In general, the FR approach is easier than the IP approach.

With VoIP, the router that connects the site's LAN to its WAN access line is instructed to look for voice/fax IP packets and put them ahead of any data packets waiting in the router's transmit queue. This way, a string of outgoing data packets will not add to the variability of the arrival time of voice packets. Voice/fax packet prioritization is especially important at WAN access speeds of 56/64Kbps - 512Kbps. At T1/E1 speeds, it may not be required.

There are two methods of instructing the router to prioritize voice/fax IP packets. In the first, the network administrator explicitly programs the router to look for the VoIP gateway's 'well known UDP port number.' The 'well known UDP port number' is a reserved port number registered by the gateway manufacture for its exclusive use worldwide. In the second approach, a prioritization protocol that is understood by both the router and the gateway is used. An example of such a protocol is RSVP, a new prioritization standard that certain router vendors are now including in the operating software for some of their routers.

With ReSourcereserVation Protocol (RSVP), when the gateway determines it needs to place or receive a voice/fax call, it establishes an RSVP session with the router, using the LAN to pass information. The gateway instructs the router to prioritize the voice/fax packets for the duration of the call. When the call is terminated, the gateway instructs the router to cease the prioritizing. RSVP, however, is not yet in widespread deployment.

RSVP also includes provisions for constraining packet delay and guarantying bandwidth availability, but on a well-managed corporate IP network, only the prioritization feature needs to be used by the gateway. It is usually only necessary to prioritize the voice/fax packet at the edge of the VDN, where the WAN access speed is usually the lowest, and the potential for conflict, the greatest.

With Frame Relay, the prioritizing of the voice/fax packets ahead of data packets is done automatically in the voice-enabled FRAD, without any user setup or involvement. Moreover, when there are multiple active voice/fax trunks, some FR implementations can prioritize at different levels within the mix of active trunks, while the IP approach usually has only one priority level. Although the effects of prioritization are the same with FR and IP, FR has the edge in manageability and possibly multi-level prioritization.

The prioritization of voice/fax packets ahead of data packets will cause the data packets to be delayed in WAN transmission wherever there are active conversations on VDID trunks. The effects on WAN data packets are negligible for background data. For real-time data, it is possible that voice/fax prioritization could interfere with their timely delivery. It is important to arithmetically subtract the real-time data bandwidth requirements before calculating the number of voice/fax trunks that the WAN access line can accommodate. Because of its lower packet overhead, FR has an advantage here, as aforementioned.

The effects on LAN data packets, however, are negligible, because the bandwidth per active trunk is so low compared to LAN speeds (15Kbps vs. 10-100Mbps) and because there is no VoIP packet prioritization on the LAN. With VoFR, the voice/fax packets are generated inside the RFRAD and forwarded directly to the WAN, without transiting the LAN.

Comparing VoFR and VoIP Packet Segmentation
Packet prioritization is important to prevent data packets waiting to transmit to the WAN from delaying voice/fax packets. A similar problem exists when a single long data packet has begun to transmit and a voice/fax packet is now ready to transmit. The v/f packet must wait until the data packet is out the door. This can cause enough jitter to increase the latency by a large margin. For example, waiting for a 1500 byte Ethernet packet to transmit over a 56Kbps-access line can take more than 200 ms. Longer Token Ring packets can add even more delay.

It is important therefore for the VDID to segment any long data packets when there are active voice/fax calls, especially for lower-speed WAN access lines. The maximum sizes of data packets consistent with good voice quality, for various access speeds, are shown in Table 7.

WAN Access Speed (Kbps)	Maximum WAN Packet Size (bytes)
56/64	256
128	512
192	768
256	1024
384	1536
512	2048*
1544	6144*

Table 7: Maximum packet sizes
* Ethernet packets do not exceed 1536 bytes. In an Ethernet LAN environment, packet segmentation is not needed above WAN access speeds of 256Kbps.

The consequence of segmenting data packets is a reduction in WAN access data transmitting efficiency. Since there is a fixed packet header for each packet, FR or IP, creating smaller packets increases the percentage of WAN access used for packet headers at the expense of useful data. In other words, the packet header as a percentage of payload, goes up, and WAN efficiency goes down. When there is active packet segmentation, the advantage is to FR since the header is smaller. With IP, the overhead can reduce WAN efficiency by 10-15%; with FR, by 2-4%.

With FR, packet segmentation occurs automatically within the RFRAD whenever there is an active call. During the call, all data packets are segmented according to information similar to that shown in Table 7. When there are no active calls, packet segmentation stops and long packets resume.

With VoIP, packet segmentation is achieved by instructing the WAN-access router to segment outbound data packets, also according to information similar to that shown in Table 7. The router is instructed to segment voice/fax IP packets either by the network administrator's explicit programming of the router to segment all packets, both voice/fax and data, all of the time, or by using a gateway-to-router protocol such as RSVP.

With RSVP, in a fashion similar to packet prioritizing, when the gateway determines it needs to place or receive a voice/fax call, it establishes an RSVP session with the router. The gateway instructs the router to segment both the voice/fax and data packets, but only for the duration of the call. Packet segmentation stops and long packets resume when there are no active calls, as in the RFRAD.

Without a protocol such as RSVP, the reduced WAN efficiency is constant and applied to all data packets. Today's routers do not segment differently depending on UDP port numbers. Since most routers and VoIP gateways do not support RSVP or a similar control protocol, VoIP will average about 10%-15% lower WAN efficiency on lower speed lines, regardless of whether or not there are active voice/fax calls. This is the second inherent disadvantage of VoIP compared to VoFR. For Ethernet packets on WAN access lines faster than 256Kbps, there are no VoIP packet segmentation disadvantages.

COMPARING FRAME RELAY AND IP WAN SERVICES

WANs are usually built using leased lines, Frame Relay services, and/or IP WAN services. For leased lines, there are no new differences to discuss between FR over leased lines and IP over leased lines. The packet technology differences discussed above determine the advantages of one over the other in the leased line environment.

There are several different types of FR and IP WAN services available. For FR, there are standard and premium grades of service from several North American vendors. Standard grade services deliver acceptable levels of service for most VoFR applications, with network delays typically in the 55ms to 130ms range, depending on WAN access speeds, and packet corruption levels less than 0.5%. Premium grade services reduce the delays by about 15 ms and improve the packet corruption levels to less than 0.01%. They generally cost an additional 10-20%, and are not needed in most applications.

IP WAN services are a little more complicated. There are several different types of IP network services, and different grades of service within them. Many corporate IP networks use routers running IP over FR networks (IP over FR or IPoFR), in which case they fall under the preceding discussion. The method of encapsulating IP packets inside Frame Relay frames can be vendor proprietary or based on a standard, such as the Internet Engineering Task Force's (IETF) RFC 1490.

In fact, the typical voice/fax-enabled RFRAD will send voice and fax in native frames and encapsulate IP for maximum efficiency. To the casual observer, who sees an IP LAN connected to the RFRAD and some voice lines connected to the RFRAD, the impression can be that the voice is part of an IP WAN connection. Thus the observer can draw the incorrect conclusion that the voice is VoIP rather than VoFR.

Some corporate IP networks use the relatively new IP VPNs (virtual private networks) that are supplied by several vendors. These IP VPNs, which usually run over ATM, Sonet, or FR, offer similar levels of service guarantees as the Frame Relay services. The main differences from Frame Relay services are availability and cost. FR is widely available around the world at speeds up to T1/E1, and selectively at speeds up to T3/E3. IP VPNs are readily available in the US and selectively internationally, at similar speeds.

FR and IP VPN cost differences vary according to the corporate network's topology, discussed later on in this section. In other regards, their differences come from their different packetizing technologies, discussed previously. For a mix of voice and data, where the data has a lower priority, they are similar regarding bandwidth efficiency. For a traffic mix of voice and delay-sensitive or high priority data, FR excels.

There are also corporate networks that use the Internet to transmit interoffice data, using firewalls for information security. Because the Internet has very high jitter and intermittently large packet losses, it is not suitable for corporate interoffice telephony. It can, however, be used for interoffice corporate voice messaging and interoffice fax.

The Internet can also be used to provide a reduced-quality telephony service for consumers willing to trade-off quality for price. This is especially appealing in the international arena. In these applications, a PC is used as a telephone. The PC accesses the Internet, and connects to another PC on the Internet. There is no charge for this service beyond the access charges. In a variation on this, the Internet-connected PC accesses a VoIP gateway on the Internet in a specific city, and, using the city's PSTN, calls a legacy telephone in that city via the gateway. There is an additional charge for this, but usually fairly small.

In yet another variation, a legacy telephone dials a VoIP gateway in a nearby location, instructs the gateway to connect to another gateway in a distant location, and dials out using the PSTN to a legacy telephone. Local toll charges apply. This is pure legacy long-distance using the Internet to carry the call between the two locations. Some service providers improve voice quality by using high-speed, semi-dedicated IP bandwidth, not the normal Internet, but market the service as Internet telephony because of the Internet's marketing appeal.

In this application, however, the inefficiency of VoIP compared to VoFR for pure voice applications, as discussed above, can reduce the advantage of using semi-dedicated IP bandwidth. It is not clear whether this enhanced consumer-grade VoIP service will continue to use semi-dedicated IP bandwidth; some service providers are switching to voice over Frame Relay or voice over ATM to reduce network costs.

Comparing VoFR and VoIP Network Topologies and Costs
There is a fundamental difference between FR and IP network topologies; FR is connection oriented, while IP is connectionless. In a FR network, each router/FRAD (voice-enabled or not) that connects to the FR service has one or more virtual connections (VCs) through the service to one or more distant RFRADs. The VCs are either permanent (PVCs) or switched (SVCs). They act like permanent or temporary leased lines connecting the RFRADs together. In the great majority of FR-based networks, the connections are PVCs; SVCs are fairly new and are not widely available, nor are SVC-ready RFRADs.

With Frame Relay, the user pays for the WAN access line (according to the bandwidth and distance of the line) to the FR service, for the port into the service (according to the bandwidth of the access line), and for each PVC between each RFRAD. The WAN access line from the RFRAD to the FR service can carry multiple PVCs. In many cases, there are several PVCs from one RFRAD to another and/or to multiple other RFRADs.

For large networks with fully meshed PVCs (each site connected to every other site with at least one PVC), the costs can skyrocket. A fully meshed 10-site network, for example, would have only 45 PVCs. A fully meshed 100-site network would have 4950 PVCs, while a fully meshed 1000 site network would have 4,999,500 PVCs.

In an IP network, the routers and level-3 switches within the network determine the next router to send the IP packet to according to header information, bandwidth availability and other factors. Unlike Frame Relay, where each frame in a PVC travels the same route, IP frames from the same source to the same destination can take a different route each time. They can even arrive out of order, and are subsequently placed in the correct order.

This has an advantage over FR of avoiding the VC concept and associated meshing costs. However, it has the disadvantage of potentially higher jitter from variable routing. This is especially apparent in the Internet, where there are huge variations in possible packet routes. In most corporate IP networks, however, the variable routing does not appreciably add to the jitter because most corporate IP WANs are not bandwidth constrained and similar direct routes are usually available for consecutive packets.

For corporate networks, therefore, the main difference between public FR and IP VPNs is in the cost of the services and the network topology. When the network topology is primarily 'homerun' or 'hub-and-spoke,' where each branch communicates mainly with headquarters and branch-to-branch communications can be accomplished by routing through headquarters, the FR PVC count is proportional to the number of branch sites. For these network topologies, PVC count is fairly small and public FR costs less than public IP.

For larger, more fully meshed network topologies, where many FR PVCs would be used, public FR costs more than public IP. Table 8 summarizes the costs for separate FR and IP connections and for several networks based on FR and IP WAN services from two prominent North American carriers who offer both.

	Carrier A		Carrier B
Single Connection (Kbps)	Frame Relay (4)	IP	Frame Relay (4)	IP
56	$277	$480	$282	$700
128	487	764	482	1,100
512	1,047	1,321	1,042	1,900
TI (1544)	2,217	1,780	2,207	2,700
10-site Hub & Spoke (1)	3,785	6,121	3,830	8,900
25-site Hub & Spoke	9,110	13,780	9,225	20,200
50-site Hub & Spoke	18,220	27,560	18,450	40,400
100-site Hub & Spoke	36,440	55,120	36,900	80,800
1000-site Hub & Spoke (5)	355,660	544,080	360,300	797,200
10-site Fully Meshed (2)	3,890	4,800	3,940	7,000
25-site Fully Meshed	15,725	12,000	15,850	17,500
25-site Partially Meshed (3)	10,925	12,000	11,051	17,500
50-site H&S, 6 PVCs/site	26,220	27,560	26,450	40,400

Table 8: A comparison of VoFR and VoIP network costs
1. Using 56K access line to each site, plus appropriate higher speed line to hub location; one multiplexed PVC per remote site for Frame Relay.
2. Using 56K to each site; no hub location, one PVC from each site to every other site.
3. 12 PVCs to each site.
4. Using suitable CIR for data/voice integration.
5. Using dual T3 access at hub, but with multi-T1 pricing.
Costs do not include LEC access charges. No allowances made for any special pricing or discounts.

For most corporate networks, which are usually hub-and-spoke, with a normal mix of data and voice, public FR is less expensive than IP by 35-50%. For predominately voice/fax traffic in hub-and-spoke or point-to-point networks, FR has an even greater advantage because less WAN bandwidth is required. Only for larger, more highly meshed networks (around 25-50 remote sites) do IP VPNs have a cost advantage.

For networks designed with leased lines, WAN costs are identical for the same FR and IP bandwidth. In a typical application where most of the traffic is background data, the bandwidth requirements will be similar, so the WAN costs should be the same. The topology should not favor FR or IP. For pure voice/data networks, IP bandwidth requirements will be about 50% greater, so the IP WAN costs will also be greater, again independent of topology. In many cases, the increase will be in the 25-50% range, and sometimes as much as 60-80%, or more.

Both public FR and IP VPNs are available with WAN access speeds up to T3 (45Mbps). Higher speeds are also available for IP VPNs, an advantage for large networks. There are about 50-60 thousand corporate voice/data public FR networks currently deployed worldwide, while the number of VoIP networks, running as IP over leased lines, IP over public FR, and as IP directly connected to IP VPNs, is in the neighborhood of 2-4 thousand.

Comparing VoFR and VoIP Standards Activity
There are standards committees for both VoFR and VoIP. The work in standardizing VoFR commenced about 5 years ago under the auspices of the Frame Relay Forum (FRF). The FRF has produced two Implementation Agreements (IAs). The first IA is FRF.11, providing for multiplexed PVCs, speech compression using G.726 (ADPCM) and G.729 (8K CS-ACELP), fax demodulation, and the format for carrying multiple voice samples in single frames.

The second IA is FRF.12, providing for frame segmentation across a Frame Relay network. This standardizes an approach to managing the long-packet problem mentioned earlier. The FRF is continuing to work on expanding these standards. They are not yet rich enough to provide for full multivendor interoperability, but several vendors have implemented the FRF standards thus far. In fact, an IA is not really a 'standard,' rather it is an agreement by vendors that can form the basis for a subsequent standard produced by a recognized standards body.

The work in standardizing VoIP is more recent, about 2 years old, and is carried on under the auspices of the IMTC VoIP Forum. The IMTC has recently produced its first VoIP Interoperability Implementation Agreement, IA 1.0. IA 1.0 is based on the ITU H.323 conferencing standard. While H.323 is in fact a standard, IA 1.0 is only an agreement, a precursor to a standard.

The VoIP IA 1.0 specifies agreements in four areas: VoIP connections using the H.323 protocol suite with H.225 for dynamic address mapping; VoIP CODECs G.723.1 and G.711; how to process and transport DTMF signals; and how to manage silence suppression. As with the FRF IAs, IA 1.0 is not yet rich enough to provide for full multivendor interoperability. The work has already begun on IA 2.0.

On the other hand, H.323 is sufficiently complete to provide interoperability with respect to basic voice conferencing using PCs as telephones and a PC client such as Microsoft NetMeeting (H.323 compliant). This application, however, is designed primarily for voice over the Internet, and is not often found in corporate VoIP implementations, as discussed earlier. H.323 Rev 2 is also sufficient to provide the interoperable gatekeeper or directory services for VoIP gateways to 'find' each other across an IP network. This is useful in a multivendor VoIP corporate environment.

SUMMARY

Both VoIP and VoFR offer viable approaches to add voice and fax traffic to corporate data networks. Both also offer viable approaches for building pure voice/fax networks. For most applications, there are no major differences in the quality of the voice/fax communications, assuming the traffic is not being carried over the Internet. There can be, however, material differences in the costs to implement and operate VoIP and VoFR solutions. The differences vary according to the application; voice/fax over corporate data networks and pure voice/fax networking.

On the VDID side, the differences arise from the two inherent VoIP disadvantages: the larger IP packet header; and the lack of a widely deployed router control protocol, such as RSVP, to control packet segmentation. On the WAN services side, the differences arise from the substantial price premium for IP VPN services over FR services. Both differences are summarized according to the application.

Summarizing VoFR and VoIP in Corporate Voice/Data Networks
For corporate voice/data networks, voice/fax-enabled RFRADs with richer functionality are more widely available than similarly equipped VoIP gateways. For some networks, the added functionality is important. In addition, the channel expertise and support for VoFR is better than VoIP, because of the significantly larger installed base and more extensive experience.

IP's larger packet header materially affects the voice/data solution when the WAN access line runs at lower speeds. In the 19.2Kbps - 56/64Kbps range, the effect is especially noticeable. The number of VoIP trunks the line can carry is materially less than the number of VoFR trunks. Above 128Kbps, the effect is marginal, because these WAN access speeds will usually accommodate all of the voice/fax trunks needed at the remote site, whether VoFR or VoIP. The packet segmentation problem is also only material for lower speed lines. For speeds in the 19.2Kbps - 56/64Kbps range, the problem can reduce efficiency by 10-15%. Above 256Kbps, the problem is immaterial.

In most cases, building corporate networks using IP VPNs is more expensive than using public FR services. This is true regardless of voice/fax integration. The exceptions are larger, highly meshed networks, where IP's connectionless nature overcomes FR's costs for large numbers of PVCs. Another advantage of IP VPNs over public FR services is the IP VPNs' availability for dial-in access from scattered remote locations. This can be very valuable for certain organizations, but has little application for branch office networking and affords few opportunities for voice/data integration.

To build integrated corporate voice/data networks when there is an existing IP data network with in-place routers or FRADs, use VoIP gateways. In general, the cost to discard the existing routers and FRADs and install new voice/fax-enabled RFRADs is more expensive than adding VoIP gateways, and there is less disruption deploying the LAN-attached gateway than deploying new WAN devices. This conclusion assumes the WAN access speeds are sufficient to accommodate the added IP voice/fax traffic. If WAN bandwidth must be increased for VoIP but not for VoFR, the cost advantage in VoIP gateway deployment can quickly disappear.

When building a new network for IP data traffic (or for non-IP traffic) that will also carry added voice and fax, use voice/fax-enabled RFRADs and public Frame Relay services. In general, this will be less expensive than using data-only routers or FRADs and VoIP gateways, and will yield better WAN access efficiencies. The voice and fax traffic will traverse the WAN as native FR frames, while the IP data traffic will be encapsulated, probably with the RFC 1490 standard.

The VoFR approach is also better when expanding an existing IP data network by a significant amount, or when upgrading the router equipment of an existing IP data network. Both scenarios offer an opportunity to install voice/fax-enabled RFRADs. VoFR is also the better approach when adding voice and fax traffic to an existing non-IP data network, such as SNA.

With either approach, avoid IP VPNs unless dial-access or some other inherent need for dynamic IP access is required, or the network is large and highly meshed. The FR services are less expensive and more widely available.

Characteristic	Frame Relay	IP
VDID Functionality	Rich	Improving
Channel	Experienced	Young
Installed Base	Large	Small
Voice Quality	Very Good	Very Good
Delay	Low	Low
Jitter	Small	Small
Voice/Fax Packet Overhead	Low	High
WAN Access V/F Channel Capacity
- Lower Speed Lines	Adequate	Marginal
- Higher Speed Lines	Adequate	Adequate
WAN Access Efficiency Degradation
- Lower Speed Lines	2-4%	10-15%
- Higher Speed Lines	0-2%	0-5%