- Fundamentals of Voice over Frame Relay
- 11 Voice over Frame Relay
- 12 Data Fragmentation
- Bandwidth Calculations
- Summary
FRF.11 Voice over Frame Relay
With the basics defined (somewhat), it's time to move on to the good stuff. As mentioned, FRF.11 defines Voice over Frame Relay services. FRF.11 extends Frame Relay application support to include the transport of digital voice payloads.
One of the most common questions that arises is, "Why use VoFR rather than VoIP?" The answer is, of course, "It depends." In a VoFR environment, all the voice-capable routers must be Frame Relay network edge devices, and must be directly connected to the Frame Relay service. With VoIP, however, this is not the case because we can route voice traffic to the individual voice-capable devices just as easily as routing data. The routing process doesn’t change. Is one better than the other? It depends. What are you hoping to accomplish the technology? How is your network laid out? These questions contain too many variables to address in a short document such as this, so those questions will remain unanswered for now.
Frame Relay transports voice traffic over the same PVCs used for data traffic. This is the case unless separate PVCs have been purchased for both voice and data. If separate PVCs are provisioned for both, they can be treated differently (i.e. traffic shaped and prioritized differently if desired). Cisco's recommendation, however, is to purchase adequate bandwidth and keep voice and data on the same PVCs for simplified administration, as well as to allow the VoFR specifications (FRF.11 and FRF.12) to work together properly. A discussion of these specifications follows shortly.
This transport is accomplished by utilizing an association between a DLCI and a destination phone number.
Telephones are attached to Foreign eXchange Station (FXS) ports of the VoFR-capable device. FXS ports are ports into which any type of station equipment (i.e., phone, fax, caller ID box, answering machine, etc.) can be plugged. When an attached phone goes off-hook, the device detects it and returns dial tone. A phone number is dialed, as in any other phone call. The VoFR device must then interpret the digits and forward them if necessary.
If the call is local (i.e., the destination is also attached to the same VoFR-capable device), ring voltage is sent out the appropriate port. Local calling, however, isn't VoFR. The VoFR-capable device is configured with dial-peers—static definitions of phone numbers and their respective DLCIs on the Frame Relay network. The device examines its dial plan configuration for a match (or the longest or closest match) to the dialed numbers. Based on the static mapping of destination phone numbers to active DLCIs, a forwarding decision is made and the dialed digits are forwarded out the appropriate port with the appropriate DLCI.
Once at the other side of the Frame Relay network, the process is repeated. The remote VoFR device receives the call and processes the digits. The determination must be made as to whether this phone number is local or needs to be forwarded along another DLCI. If the destination is local to this device, ring voltage is generated on the appropriate port.
If it is determined that the digits must be forwarded again, the device examines its dial plan configuration. Once a match is found, it is forwarded back into the Frame Relay network on the appropriate DLCI. This process of one device forwarding a call from a remote source to a remote destination is known as tandem switching.
Should a device fail to match the dialed digits to its dial plan configuration at any time, a reorder tone is issued. This is (usually) the three-tone sound you hear just before a telephone company message is played to inform you that a number is no longer in service.
The Frame Relay voice frame is relatively small. Figure 2 illustrates the frame structure.
){kind=link}
Figure 2 Voice over Frame Relay frame structure
The header is identical in voice and data frames. An FRF.11 Voice/Fax header exists that specifies the type of payload contained in the frame. It is important to note that FRF.11 differentiates between primary and supporting (or signaling) payloads. There are three types of primary payloads: encoded voice, encoded fax, and data.
Encoded voice payload is typically G.729 or G.729(a) compressed payload. This is not always the case, however. A single Frame Relay frame can carry a primary payload of three voice payloads. Each voice payload is carried in a sub-frame. This sub-frame has a sub-header, which is where the supporting (or signaling) payload type is indicated. These signaled payloads include information such as dialed digits, channel-associated signaling, in-band encoded FAX relay, and fault indications. Figure 3 illustrates this concept.
){kind=link}
Figure 3 VoFR Frame and Sub-Frame relationship
Each sub-frame consists of a variable length header and a payload. The minimal sub-frame header is a single octet containing the least significant bits of the voice/data channel identification along with extension and length indications. An extension octet (1 Byte) containing the most significant bits of the voice/data channel identification and a payload type is present when the Extension Indication is set. A payload length octet is present when the Length Indication is set.
Dialed Digits
As mentioned previously, dialed digits are transported across in the sub-frame. There are two types of dialing: pulse and Dual-Tone Multi-Frequency (DTMF). Pulse dialing is rare in today's society, so we'll concentrate on DTMF. A common question is, "How are the DTMF tones sent across the network?" The answer is simple—they're converted to a binary value and forwarded as payload in the Frame Relay frame.
There are payload identifiers in the frame that specify a dialed digits payload. A string of 20ms windows is used to encode the edges when digits are turned on and off.
The timing of the transmission of dialed digits is dependent upon the Bellcore standard requiring that tones should be 23ms or shorter, with not less than 40ms of silence between tones. The silence is subject to an inter-digit timeout value, which is a value in seconds that the device collecting the digits should wait after receiving a digit before attempting to make a forwarding decision. If too few digits have been received or the digit pattern is not recognized, a fast busy signal results.
The 20ms window is the delta time—0ms (00000) to 19ms (10011)—from the beginning of the current frame in ms. If there is no transition, the edge location is set to 0 and the digit type of the previous windows is repeated. The dialed digits sub-frame contains a 3-bit digit type field. A value of 000 represents DTMF=OFF, whereas a value of 001 represents DTMF=ON.
When DTMF=ON, another field (digit code) takes the DTMF tone and encodes its equivalent binary value in the digit code field. Table 1 shows the characters and their equivalents.
Table 1 Digit Code Translation
|
Digit Code |
DTMF Digit |
|
00000 |
0 |
|
00001 |
1 |
|
00010 |
2 |
|
00011 |
3 |
|
00100 |
4 |
|
00101 |
5 |
|
00110 |
6 |
|
00111 |
7 |
|
01000 |
8 |
|
01001 |
9 |
|
01010 |
* |
|
01011 |
# |
|
01100 |
A |
|
01101 |
B |
|
01110 |
C |
|
01111 |
D |
|
10000-11111 |
Reserved |
When the transmitter detects a validated digit or has addressing information to send, it will start sending a dialed digit payload every 20ms. Each payload covers 60ms of digit on/off information. There is a sequence number in the sub-frame that is incremented by one in each transmitted payload.
As mentioned, there are other sub-frame types for channel-associated signaling, fax relay, and fault indication. Due to length constraints, however, they will not be addressed in this document.