Table Of Contents
Voice over Frame Relay
VoFR Overview
VoFR Dial Peers
Switched Calls
Tandem Switching
Dynamic-Switched Calls
Cisco Trunk Calls
Permanent Calls
Frame Relay Fragmentation
End-to-End FRF.12 Fragmentation
Frame Relay Fragmentation Using FRF.11 Annex C
Cisco Proprietary Voice Encapsulation
Map Classes and Voice Packet Queues
Traffic Shaping
VoFR Configuration Considerations
VoFR Prerequisite Tasks
VoFR Configuration Task List
Configuring Frame Relay to Support Voice
Configuring a Map Class to Support Voice Traffic
Configuring a Map Class for Traffic-Shaping Parameters
Configuring VoFR Dial Peers
Configuring Switched Calls
Tandem Switching of Switched Calls
Configuring Cisco Trunk Calls
Configuring FRF.11 Trunk Calls
Verifying the Voice Connections
Verifying the Frame Relay Configuration
Troubleshooting Tips
Monitoring and Maintaining the VoFR Configuration
VoFR Configuration Examples
Two Routers Using Frame Relay Fragmentation Example
Two Routers Using a VoFR PVC Example
Router Using VoFR PVCs Connected to Cisco MC3810s Before 12.1(2)T Example
Cisco Trunk Calls Between Two Routers Example
FRF.11 Trunk Calls Between Two Routers Example
Tandem Configuration Examples
Cisco Trunk Call with Hunt Groups Example
Voice over Frame Relay
This chapter describes the configuration of Voice over Frame Relay (VoFR) and contains the following sections:
•
VoFR Overview
•VoFR Configuration Considerations
•VoFR Prerequisite Tasks
•VoFR Configuration Task List
•VoFR Configuration Examples
For a description of the VoFR configuration commands using the FRF.11 implementation agreement, refer to the Cisco IOS Voice Command Reference, Release 12.3. For additional information about the FRF.12 implementation agreement and wide-area networks (WANs), refer to the Cisco IOS Wide-Area Networking Configuration Guide and Cisco IOS Wide-Area Networking Command Reference. For information about voice port configurations, refer to the "Configuring Voice Ports" chapter.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and CiscoIOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
VoFR Overview
VoFR enables a router to carry voice traffic (for example, telephone calls and faxes) over a Frame Relay network, using the FRF.11 protocol. This specification defines multiplexed data, voice, fax, dual tone multi frequency (DTMF) digit-relay, and channel-associated signaling (CAS)/robbed-bit signaling frame formats. The Frame Relay backbone must be configured to include the map class and Local Management Interface (LMI).
The Cisco VoFR implementation enables dynamic- and tandem-switched calls and Cisco trunk calls. Dynamic-switched calls have dial-plan information included that processes and routes calls based on the telephone numbers. The dial-plan information is contained within dial-peer entries. For more information, see "Switched Calls" section.
Tandem-switched calls are switched from incoming VoFR to an outgoing VoFR enabled data-link connection identifier (DLCI) and tandem nodes enable the process. The nodes also switch Cisco trunk calls.
Permanent calls are processed over Cisco private-line trunks and static FRF.11 trunks that specify the frame format and coder types for voice traffic over a Frame Relay network. For more information, see "Permanent Calls" section.
VoFR connections depend on the hardware platform and type of call. The types of calls are:
•Switched (user dialed or auto-ringdown and tandem)
•Permanent (Cisco trunk or static FRF.11 trunk)
Note Calls to Cisco MC3810 multiservice concentrators running Cisco IOS releases before 12.0(7)XK and 12.1(2)T require specific procedures for VoFR configuration and are described in separate sections.
VoFR Dial Peers
Dial peers are addressable call endpoints that identify the origin and destination of a call. Dial peers define the characteristics applied to each call leg in the call connection. A call leg is a logical connection between two routers or between a router and a telephony device.
A traditional voice call over the Public Switched Telephone Network (PSTN) uses a dedicated 64K circuit end-to-end. In contrast, a voice call over the packet network is made up of call legs. A voice call has four call legs, two from the perspective of the originating router and two from the perspective of the destination router, as shown in Figure 91.
Figure 91 Dial Peer Call Legs
A dial peer is associated with each call leg. Attributes that are defined in a dial peer and applied to the call leg include codec, Quality of Service (QoS), voice activity detection (VAD), and fax rate. To complete a voice call, you must configure a dial peer for each of the four call legs in the call connection.
Two kinds of dial peers are possible in VoFR configurations:
•POTS—Dial peer describing the characteristics of a traditional telephony network connection. POTS dial peers map a dialed string to a specific voice port on the local router, normally the voice port connecting the router to the local PSTN, PBX, or telephone.
•VoFR—Dial peer that is connected between a Frame Relay WAN backbone and a specific voice-network device. VoFR dial peers map a dialed string to the destination router.
VoFR peers point to specific voice-network devices by associating destination telephone numbers with a specific Frame Relay DLCI so that outgoing calls can be placed. Both POTS and VoFR dial peers are needed to establish VoFR connections if the sending and receiving of calls are required.
Understanding the the relationship between the destination pattern and the session target is critical to understanding VoFR dial peers. The destination pattern is the telephone number of the voice device attached to the voice port. The session target defines the route to a serial port on the peer router at the other end of the Frame Relay connection.
Note For tandem voice nodes, POTS dial peers are not configured.
For additional information on POTS dial peers, see the "Configuring Dial Plans, Dial Peers, and Digit Manipulation" chapter.
Switched Calls
The Cisco-switched VoFR protocol handles call setup and parameter negotiation for both endpoints and intermediate nodes within the multihop call path. The call setup mechanism originally implemented in the Cisco MC3810 multiservice concentrator can be used for permanent-switched (Cisco trunk) or dynamic-switched calls. The Cisco VoFR protocol includes forwarding of the called telephone number and supports tandem switching of the call over multiple Frame Relay permanent virtual connection (PVC) hops.
Cisco addresses the lack of end-to-end call parameter negotiation and call setup syntax in FRF.11 by implementing a proprietary Q.931-like session protocol running on a user-configurable channel ID (CID) of an FRF.11-format multiplexed DLCI.
Tandem Switching
Dynamic switching of voice calls between VoFR or VoATM PVCs and subchannels is also called tandem switching (often encountered in multihop VoFR call connection paths). Tandem switching uses nodes that are intermediate router nodes within the Frame Relay call path.
Each node switches the frames from one PVC subchannel to another (from one VoFR dial peer to another VoFR dial peer) as the frames traverse the network. Use of tandem router nodes avoids the need to have complete dial-plan information present on every router.
Dynamic-Switched Calls
Dynamic-switched calls are regular telephone calls in which the switching is performed by the Cisco router. The destination endpoint of the call is selected by the router based on the dialed telephone number and the dial peer configuration entries. This implementation is different from permanent calls (Cisco trunk calls) in which the call endpoints are permanently fixed at configuration time. The dial peer uses the Cisco proprietary session protocol.
Cisco Trunk Calls
A Cisco trunk call is a dynamic-switched call of indefinite duration that uses a fixed-destination telephone number and includes optional transparent end-to-end signaling. The telephone number of the destination endpoint is permanently configured into the router so that it always selects a fixed destination. Once established, at boot-up or when configured, the call stays up until one of the voice ports or network ports is shut down or until a network disruption occurs. The dial peer is configured to invoke the Cisco proprietary session protocol.
Permanent Calls
Permanent calls are transmitted and received on FRF.11 and Cisco trunks. FRF.11 trunk interoperability for standards-based vendors enables specification of the frame format and coder types to be used when sending voice traffic through a Frame Relay network. However, FRF.11 does not have specifications for end-to-end negotiation, call setup process, or any other form of communication between the Frame Relay nodes.
As a result, static FRF.11 trunks are set up by manually configuring each router within the voice trunk path with compatible parameters: a voice port and a specific subchannel on a DLCI are explicitly bound on each end router. Signaling information is packed and sent transparently end-to-end.
The two ends of an FRF.11 call must use the same compatible speech compression codecs. If not, the call exists and voice packets are sent and received, but no usable voice path is created.
When configured, a static FRF.11 trunk remains up until the voice or serial port is shut down or until a network disruption occurs. The FRF.11 specification does not include any standardized methods for performing Operation, Administration, and Maintenance (OAM) functions. There is no standard protocol for detecting faults and providing rerouting of connection paths.
FRF.11 enables up to 255 subchannels to be multiplexed onto a single Frame Relay DLCI. The current implementation supports the multiplexing of a single data channel with many voice channels. However, subchannels from zero to three are reserved and cannot be configured for voice or data.
Frame Relay Fragmentation
Cisco has developed three methods of performing Frame Relay fragmentation that are described in the following sections:
•End-to-End FRF.12 Fragmentation
•Frame Relay Fragmentation Using FRF.11 Annex C
•Cisco Proprietary Voice Encapsulation
FRF.11 can only be used when an end-to-end PVC is available between the voice ports at each end of the connection. At intermediate Frame Relay nodes, the entire PVC must be routed. Because the entire PVC is routed, no prioritization of voice packets is possible at the intermediate Frame Relay. Connection ID-based routing (individual channel-ID switching) is not supported.
FRF.11 specifies that a device can pack multiple FRF.11 subframes within a single Frame Relay frame; however, the Cisco implementation of VoFR currently does not support multiple subframes within a frame. VoFR frames are never fragmented, regardless of size. If fragments arrive out of sequence, packets are dropped. Fragmentation is performed after frames are removed from the weighted fair queuing (WFQ). WFQ at the PVC level is the only queueing strategy that can be used.
Frame Relay Traffic Shaping (FRTS) must be configured to enable Frame Relay fragmentation.
Frame Relay fragmentation can be configured in conjunction with VoFR or independently of it. For additional information regarding FRF.12 fragmentation and the implementation commands, refer to the Cisco IOS Wide-Area Networking Configuration Guide and Cisco IOS Wide-Area Networking Command Reference.
VoFR provides support for various FRF.11 features depending on the hardware platform used (see Table 30).
Table 30 FRF.11 Forum Features Supported by Hardware Platform
FRF.11 Forum Features
|
Cisco MC3810 Multiservice Concentrator
|
Cisco 2600/3600 Series Routers
|
Cisco 7500 Series Routers with VIP Support
|
Class 1-Compliance Requirements (sec. 4.1)
|
Not supported
|
Not supported
|
Not supported
|
Class 2-Compliance Requirements (sec. 4.2)
|
Supported
|
Supported
|
Supported
|
Annex A-Dialed Digits Transfer Syntax
|
Supported
|
Supported
|
Supported
|
Annex B-Signaling Bit Transfer Syntax
|
Supported
|
Supported
|
Supported
|
Annex C-Data Transfer Syntax
|
Supported
|
Supported
|
Supported
|
Annex D-Fax Relay Transfer Syntax
|
Supported
|
Supported
|
Supported
|
Annex E-CS-ACELP Transfer Syntax (G.729/G.729A)
|
|
|
|
•Sequence Number
|
Supported
|
Supported
|
Supported
|
•Packing Factor
|
Supported
|
Supported
|
Supported
|
Annex F-Generic PCM/ADPCM Voice Transfer Syntax
|
Supported
|
Supported
|
Supported
|
Annex G -G.727 Discard-Eligible E-ADPCM Voice Transfer Syntax
|
Not supported
|
Not supported
|
Not supported
|
Annex H-G.728 LD-CELP Transfer Syntax
|
Not supported
|
Supported
|
Supported
|
Annex I-G.723.1 Dual Rate Speech Coder
|
Not supported
|
Supported
|
Supported
|
Transmission and reception of multiple subframes within a single Frame Relay frame
|
Not supported
|
Not supported
|
Not supported
|
End-to-End FRF.12 Fragmentation
FRF.12 fragmentation is defined by the FRF.12 standard. The FRF.12 implementation agreement enables long data frames to be fragmented into smaller pieces and interleaved with real-time frames. In this way, real-time voice and nonreal-time data frames can be carried together on lower-speed links without causing excessive delay to the real-time traffic.
Use this fragmentation type when the PVC is not carrying voice, but is sharing the link with other PVCs that are carrying voice. The fragmentation header is included only for frames that are greater than the fragment size configured. FRF.12 is the recommended fragmentation for VoIP packets.
Note VoIP packets should not be fragmented. However, VoIP packets can be interleaved with fragmented packets.
The Cisco 2600 series, 3600 series, and 7200 series routers and the Cisco MC3810 multiservice concentrator support end-to-end fragmentation on a per-PVC basis. Fragmentation is configured through a map class that applies to one or many PVCs, depending on how the class is applied.
When end-to-end FRF.12 fragmentation is used, the VoIP packets do not include the FRF.12 header, provided the size of the VoIP packet is smaller than the fragment size configured. However, when FRF.11 Annex C or Cisco proprietary fragmentations are used, VoIP packets do include the fragmentation header.
Frame Relay Fragmentation Using FRF.11 Annex C
When VoFR and fragmentation are configured on a PVC, the Frame Relay fragments are sent in the FRF.11 Annex C format. FRF.11 fragmentation is used when voice traffic is sent on the PVC, and Annex C format is used for data. With FRF.11, all data packets contain fragmentation headers, regardless of size. This form of fragmentation is not recommended for use with VoIP.
Cisco Proprietary Voice Encapsulation
Cisco proprietary voice encapsulation was implemented for the Cisco MC3810 multiservice concentrator and was used for data packets on a PVC and voice traffic. This fragmentation type is used on data packets on PVCs that carry voice traffic.
When VoFR is configured on a DLCI and fragmentation is enabled on a map class, the Cisco 7500 series router with Versatile Interface Processor (VIP) can interoperate with Cisco 2600 series, 3600 series, 7200 series, and other 7500 series routers as tandem nodes, but it cannot perform call termination with Cisco MC3810 multiservice concentrators running Cisco IOS releases before 12.0(3)XG or 12.0(4)T.
Map Classes and Voice Packet Queues
You must create and configure a Frame Relay map class before configuring a Frame Relay DLCI for voice traffic. The map class has configuration information about voice bandwidth, fragmentation size, and traffic shaping attributes. These attributes are required for sending voice traffic on the PVC.
Traffic Shaping
When a Frame Relay PVC is configured to support voice traffic, the carrier must be able to accommodate the traffic rate or profile sent on the PVC. If too much traffic is sent at once, the carrier might discard frames causing disruptions to real-time voice traffic. The carrier might also deal with traffic bursts by queueing up the bursts and delivering them at a metered rate. Excessive queueing also causes disruption to real-time voice traffic. Traffic shaping compensates for this condition and is necessary to prevent the carrier from discarding eligible discard bits on ingress and to prevent excessive burst data from affecting voice quality.
When the outgoing Excess Burst (Be) size is configured, the Committed Burst (Bc) size and the committed information rate (CIR) values must be obtained from the carrier. The configured values on the router must match those of the carrier.
VoFR Configuration Considerations
You must consider certain factors when configuring VoIP to ensure that it runs smoothly over Frame Relay. A public Frame Relay cloud provides no guarantees for QoS. For real-time traffic to be sent in a timely manner, the data rate must not exceed the committed information rate (CIR) or packets may be dropped. In addition, Frame Relay traffic shaping and RSVP are mutually exclusive. Remembering this is particularly important if multiple data link connection identifiers (DLCIs) are carried on a single interface.
For Frame Relay links with slow output rates (less than or equal to 64 kbps) in which data and voice are being sent over the same permanent virtual circuit (PVC), we recommend the following solutions:
•Separate DLCIs for voice and data—By providing a separate subinterface for voice and data, you can use the appropriate QoS tool for each line. For example, with each DLCI using 32 kbps of a 64-kbps line, you could do the following:
–Apply adaptive traffic shaping to both DLCIs.
–Use RSVP or IP Precedence to prioritize voice traffic.
–Use compressed RTP to minimize voice packet size.
–Use weighted fair queueing to manage voice traffic.
•Lower the maximum transmission unit (MTU) size—Voice packets are generally small. With a lower MTU size (for example, 300 bytes), large data packets can be broken up into smaller data packets that can more easily be interwoven with voice packets.
Note Some applications do not support a smaller MTU size. If you decide to lower the MTU size, use the ip mtu command; this command affects only IP traffic.
Note Lowering the MTU size affects data throughput speed.
•CIR equal to line rate—Make sure that the data rate does not exceed the CIR. One way you can make sure that the data rate does not exceed the CIR is through generic traffic shaping. For example, you could do the following:
–Use IP precedence to prioritize voice traffic.
–Use compressed RTP to minimize voice packet header size.
•Traffic shaping—Use adaptive traffic shaping to throttle back the output rate based on the backward explicit congestion notification (BECN). If the feedback from the switch is ignored, both data and voice packets might be discarded. Because the Frame Relay switch does not distinguish between voice and data packets, voice packets could be discarded, resulting in a deterioration of voice quality. For example, you could do the following:
–Use compressed RTP, reduced MTU size, and adaptive traffic shaping based on BECN to hold the data rate to the CIR.
–Use generic traffic shaping to obtain a low interpacket wait time. For example, set Bc to 4000 to obtain an interpacket wait of 125 ms.
VoFR Prerequisite Tasks
Before configuring the router for VoFR, perform the following tasks:
•Complete the company dial plan and establish a working telephony network based on the dial plan:
–Integrate the dial plan and telephony network into the existing Frame Relay network topology. Make routing or dialing transparent to the user; for example, avoid secondary dial tones from secondary switches, where possible.
–Contact the PBX vendor for instructions on how to reconfigure the appropriate PBX interfaces.
•Establish a working IP and Frame Relay network. For more information about configuring IP, see the "IP Overview," "Configuring IP Addressing," and "Configuring IP Services" chapters in the Cisco IOS IP Configuration Guide. For more information about configuring Frame Relay, see the Cisco IOS Wide-Area Networking Configuration Guide.
•Configure the required codecs and POTs dial peer configurations in "Configuring Dial Peers, Dial Plans, and Digit Manipulation" chapter.
•Configure voice ports. For more information, see the "Configuring Voice Ports" chapter.
•Configure the clock source interfaces. For more information, refer to the "Configuring Synchronous Clocking" appendix.
VoFR Configuration Task List
This section describes the following tasks:
•Configuring Frame Relay to Support Voice
•Configuring VoFR Dial Peers
•Configuring Switched Calls
•Configuring Cisco Trunk Calls
For information regarding the configuring of voice ports and dial peers, refer to the "Configuring Voice Ports" and "Configuring Voice Dial Peers, Dial Plans, and Digit Manipulation" chapters.
Configuring Frame Relay to Support Voice
To configure Frame Relay to support voice, a map class must be applied to a single DLCI or to a group of DLCIs, depending on how the class has been applied to the virtual circuit. If there is a large number of PVCs to configure, assign the same traffic-shaping properties to the PVCs. The values for each PVC are not statically defined. Multiple map classes with different variables for each map class can also be created.
When the frame-relay voice bandwidth command is entered, a special queue is created for voice packets only so that time-sensitive voice packets have preference over data packets.
This section describes the configuration of map classes as follows:
•Configuring a Map Class to Support Voice Traffic
•Configuring a Map Class for Traffic-Shaping Parameters
To configure the map class to support FRF.12 fragmentation, refer to the Cisco IOS Wide-Area Networking Configuration Guide and Command Reference for more information.
Configuring a Map Class to Support Voice Traffic
When you are configuring a Frame Relay map class to support voice traffic, you must reserve the appropriate amount of voice bandwidth. If there is not enough bandwidth reserved, new calls are rejected. When calculating the amount of required voice bandwidth, include the voice packetization overhead and not just the raw compressed speech codec bandwidth.
Remember that there are a six or seven bytes of total overhead per voice packet, including standard Frame Relay headers and flags. For subchannels (CIDs) numbered less than 64, the overhead is 6 bytes. For subchannels numbered greater than or equal to 64, the overhead is 7 bytes. Add one byte if voice sequence numbers are enabled in the voice packets.
To determine the required voice bandwidth, use the following calculation:
required_bandwidth = codec_bandwidth * (1 + overhead/payload_size)
This calculation addresses the amount of bandwidth consumed on the physical network interface. The figure does not necessarily represent the amount of connection bandwidth used within the Frame Relay network itself, which may be higher because the overhead of switching small packets.
When 30-ms duration voice packets are used, an approximate general rule is to add 2000 bps overhead to the raw voice compressed speech codec rate. With the 32 kbps G.726 adaptive differential pulse code modulation (ADPCM) speech coder, a 30-ms speech frame uses 120 bytes voice payload plus 6 to 7 bytes overhead, and the overall bandwidth requirement is about 34 kbps for each call.
To configure a Frame Relay map class to support voice traffic on DLCIs, use the following commands beginning in global configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# map-class frame-relay map-class-name
|
Creates a map class name to assign to a group of PVCs and enters map-class configuration mode. A map class name must be unique.
|
Step 2
|
Router(config-map-class)# frame-relay voice
bandwidth bps_reserved
|
Enters the bandwidth in bits per second (bps) and determines the number of voice calls enabled on the DLCIs where the map class is associated. The keywords and arguments are as follows:
•bps_reserved—Reserved bandwidth. Valid range is from 8,000 to 45,000,000 bps. The default is 0 (disables all voice calls).
|
Note It is recommended that the bps be no higher than the minimum CIR if the voice quality is impacted when burst is being sent.
Configuring a Map Class for Traffic-Shaping Parameters
To configure a Frame Relay map class for the traffic shaping parameters for one or more DLCIs, use the following commands in map-class configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config-map-class)# frame-relay bc out bits
|
Configures the outgoing bc size for this group of PVCs. Configure the bits value to a minimum of 1000 for voice traffic. Ensure that the bc size matches the carrier to prevent the carrier from discarding DE bits on ingress.
|
Step 2
|
Router(config-map-class)# frame-relay be out bits
|
Configures the outgoing be size for this group of PVCs. Ensure that the Excess Burst size matches the carrier to prevent the carrier from discarding DE bits on ingress.
|
Step 3
|
Router(config-map-class)# frame-relay min-cir {in |
out} bps
|
Configures the minimum acceptable incoming or outgoing CIR for this group of PVCs.
|
Step 4
|
Router(config-map-class)# frame-relay cir out bits
|
Configures the outgoing excess CIR for this group of PVCs. Configured the CIR size to match your carrier to prevent the carrier from discarding DE bits on ingress.
|
Step 5
|
Router(config-map-class)# frame-relay cir in bits
|
(Optional) Configures the incoming CIR size for this group of PVCs.
|
Step 6
|
Router(config-map-class)# frame-relay adaptive
shaping becn
|
(Optional) Configures the adaptive traffic rate adjustment to support backward explicit congestion notification (BECN) on this group of PVCs.
|
Configuring VoFR Dial Peers
To configure a VoFR dial peer, you must uniquely identify the peer (by assigning it a unique tag number) and define the outgoing serial port number and the virtual circuit number.
Depending on your dial plan configuration, you might need to consider how to configure voice networks with variable-length dial plans, number expansion, excess digit playout, forward digits, and default voice routes, or use hunt groups with dial peer preferences.
Note On the Cisco MC3810 multiservice concentrator, a voice class can be configured to assign idle state and out-of-service (OOS) signaling attributes to a VoFR dial peer. For more information, see the "Configuring Trunk Connections and Conditioning Features" chapter.
To configure a VoFR dial peer, use the following commands beginning in global configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# dial-peer voice number vofr
|
Defines a VoFR dial peer and enters dial peer configuration mode. All subsequent commands that are entered in dial peer voice configuration mode before exiting apply to this dial peer.
The number argument identifies the dial peer and must be unique on the router. Do not duplicate a specific tag number.
|
Step 2
|
Router(config-dial-peer)#
destination-pattern[+]string[T]
|
Configures the dial peer destination pattern. The same restrictions for the string listed in the POTS dial peer configuration also apply to the VoFR destination pattern. Also configures standard VoFR dial peers for switched calls on the tandem routers.
•Plus sign (+)—(Optional) Indicates an E.164 standard number. The plus sign (+) is not supported on the Cisco MC3810 multiservice concentrator.
•string—Specifies the E.164 or private dialing plan telephone number. Valid entries are the digits 0 through 9, the letters A through D, and the following special characters:
–Asterisk (*) and pound sign (#) that appear on standard touch-tone dial pads.
–Comma (,) inserts a pause between digits.
–Period (.) matches any entered digit (this character is used as a wildcard).
•T—(Optional) Indicates that the destination-pattern value is a variable length dial-string.
Note Tandem-switched calls are not allowed when the call type is an FRF.11 trunk call. The Cisco 7200 series routers can serve only as tandem nodes in the VoFR network using Cisco IOS Release 12.1. This is the only dial peer procedure supported on the Cisco 7200 series.
|
Step 3
|
Router(config-dial-peer)# session target interface
dlci [cid]
|
Configures the Frame Relay session target for the dial peer.
Note The cid argument is required for FRF.11 trunk calls.
|
Step 4
|
Router(config-dial-peer)# session protocol
{cisco-switched | frf11-trunk}
|
(Optional) Configures the session protocol to support switched calls or FRF.11 trunk calls. If FRF.11 trunk calls are sent over the Frame Relay network, the VoFR dial peers must be statically configured on both sides of the trunk specifically to support FRF.11 trunk calls.
FRF.11 trunk calls cannot be used in conjunction with dial plans or be sent through tandem nodes.
Note The cisco-switched keyword is the default.
|
Step 5
|
Router(config-dial-peer)# codec {type} [bytes
payload_size]
|
Specifies the voice coder rate of speech and payload size for the dial peer. The default dial peer codec is g729r8. The keywords and arguments are as follows:
•type—Specifies the coder rate of speech. The rates are hardware-specific. Refer to the Cisco IOS Voice, Video, and Fax Command Reference.
•bytes—(Optional) Specifies the payload size. Each codec type defaults to a different payload size if a value is not specified.
•payload_size—(Optional) Specifies the payload size by entering the bytes value. Each codec type defaults to a different payload size if a value is not specified. To obtain a list of the default payload sizes, enter the codec command and the bytes option followed by a question mark (?).
|
| |
|
Note The Cisco MC3810 multiservice concentrator is limited to a maximum of 12 calls when using g729r8. Use g729ar8 to support up to 24 calls on the Cisco MC3810 multiservice concentrator.
Note If configuring switched voice calls on the Cisco MC3810 multiservice concentrator, configure the codec type on the voice port.
Note For FRF.11 trunk calls, the codec values must be set the same on both sides of the connection.
|
Step 6
|
Router(config-dial-peer)# dtmf-relay
|
(Optional) Specifies support for the DTMF relay to improve end-to-end transport of the DTMF tones, if the codec type configured is a low bit-rate codec such as g729 or g723. DTMF tones do not always propagate reliably with low bit-rate codecs.
DTMF relay is disabled by default.
|
Step 7
|
Router(config-dial-peer)# signal-type {cas | cept |
ext-signal | transparent}
|
If Cisco trunk permanent calls are being configured, the signal type is required. The signal type defines the ABCD signaling packets that are generated by the voice port and sent to the data network. Use the cas, cept, ext-signal, and transparent keywords.
To configure FRF.11 calls, use only the cas and ext-signal keywords. These keywords are optional on Cisco 2600/3600 series routers and configure the signal type on these routers for FXS-FXS trunks. The keywords are as follows:
•cas—Default signaling type that is North American CAS/robbed-bit signaling.
•cept—Provides basic E1 ABCD protocol, primarily Conférence Européenne des Postes et des Télécommunications (CEPT) E&M signaling, on the Cisco MC3810 multiservice concentrator. This keyword is used for European voice networks. If the keyword is used with FXS or FXO voice ports, the signaling is equivalent to Mercury Exchange Limited (MEL) CAS. The keyword is not supported on the Cisco 2600/3600 series.
•ext-signal—Used for required external signaling channels (for example, common channeling signaling), or when no signaling information is sent over a permanent "dumb" voice pipe (for example, carrying audio for a public address system).
|
| |
|
•transparent—Used on the Cisco MC3810 multiservice concentrator with digital voice ports when the ABCD signaling bits are copied and passed transparently from the T1/E1 interface without interpretation (also known as transparent FRF.11 signaling). The keyword enables the Cisco MC3810 multiservice concentrator to handle or transport unknown signaling protocols.
On the Cisco MC3810 multiservice concentrator with analog voice ports, the transparent keyword does not apply and is equivalent to the cept keyword. This keyword is not supported on the Cisco 2600 series and 3600 series in Cisco IOS Release 12.2.
Note By default, the Cisco MC3810 multiservice concentrator, when configured using transparent, operates the voice path in a permanently open state so that voice packets are sent (and network bandwidth consumed) regardless of the state of the call.
The signal type must be configured in such a way that the signal type is the same at both ends of the permanent voice call. When a permanent connection is configured between a T1/E1 Cisco MC3810 multiservice concentrator and an analog voice port on a Cisco 2600 or Cisco 3600 series routers, the signal type should be set to cas, which is the default.
|
Step 8
|
Router(config-dial-peer)# called-number
termination-string
|
Required for the Cisco 2600/3600 series routers only. Configures the termination string for FRF.11 trunk calls. This command is required to enable the router to establish an incoming trunk connection.
This command applies only when the session protocol command is set to frf11-trunk.
Note Although this command is visible on the Cisco MC3810 multiservice concentrator, the command is disabled.
|
Step 9
|
Router(config-dial-peer)# no vad
|
(Optional) Disables VAD on the dial peer. This command is enabled by default.
|
Step 10
|
Router(config-dial-peer)# sequence-numbers
|
(Optional) Enables the voice sequence number if required for your configuration. This command is disabled by default.
|
Step 11
|
Router(config-dial-peer)# preference value
|
(Optional) Configures a preference for the VoFR dial peer. The value argument is a number from 0 to 10 where the lower the number, the higher the preference in hunt groups.
|
Step 12
|
Router(config-dial-peer)# fax rate {2400 | 4800 |
7200 | 9600 | 14400 | disable | voice}
|
(Optional) Configures the transmission speed (in bps) at which a fax will be sent to the dial peer.
The default is voice, which specifies the highest possible transmission speed allowed by the voice rate.
|
To configure another VoFR dial peer, exit dial peer configuration mode and repeat Steps 1 through 10.
Note Repeat this procedure on the destination router on the other side of the FRF.11 trunk.
Configuring Switched Calls
To configure switched calls on Cisco 2600, 3600, and 7200 series routers and Cisco MC3810 multiservice concentrators, use the following commands beginning in interface configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config-if)# frame-relay interface-dlci dlci
|
Enters the DLCI configuration mode.
|
Step 2
|
Router(config-fr-dlci)# vofr [data cid]
[call-control][cid]
|
Configures the Frame Relay DLCI to support VoFR. When the vofr command is used, all subchannels on the DLCI are configured for FRF.11 encapsulation The keywords and arguments are as follows:
•data—Selects a subchannel (CID) for data other than the default subchannel (CID 4). The recommended setting is vofr data 4 call-control 5.
•cid—Specifies the subchannel to use for data. Valid values are from 4 to 255. The default is 4. If data is specified, a valid CID must be entered.
•call-control—(Optional) Specifies that a subchannel is reserved for call-control signaling. Call-control is not supported on Cisco MC3810 multiservice concentrators.
•cid—(Optional) Specifies the subchannel to use for call-control signaling. Valid values are from 4 to 255. The default is 5. If call-control is specified and a CID is not entered, the default CID is used. If the vofr command is entered without any keywords or arguments, the data subchannel (cid) is 4 and there is no call-control subchannel.
Note The vofr command uses WFQ at the PVC level. If the vofr cisco command is used, WFQ cannot be disabled.
|
| |
or
|
|
| |
Router(config-fr-dlci)# vofr cisco
|
Configures the DLCI and the Cisco proprietary voice encapsulation for switched calls to Cisco MC3810 multiservice concentrators. When this command is entered, data CID 4 and call-control CID 5 are automatically assigned.
|
| |
|
If user-dialed calls are being configured, stop here. If auto-ringdown calls are being configured, continue to the next step.
|
Step 3
|
Router(config)# voice-port
|
Identifies the voice port to configure and enters the voice-port configuration mode.
Note The voice-port command is hardware specific. For more information, refer to the Cisco IOS Voice, Video, and Fax Command Reference.
|
Step 4
|
Router(config-voice-port)# connection [plar |
tie-line] destination-string
|
Configures the private-line, auto-ringdown (PLAR) or tie-line connection, specifying the telephone number in the destination-string.
|
Table 31 lists the supported VoFR connections and the appropriate commands to configure switched calls.
Table 31 Supported VoFR Connections for Switched Calls
Switched Calls
(User-Dialed or Auto-Dialed)
|
Data Fragmentation Supported
|
Frame Relay DLCI Command 1
|
Session Protocol Command 2
|
Voice Port
Command
|
To routers supporting VoFR
|
FRF.11 Annex C
|
vofr [data cid] [call-control [cid]]3
|
session protocol cisco-switched4
|
For user-dialed calls: none
For auto-ringdown calls:
connection plar destination-string
|
To a Cisco MC3810 multiservice concentrator running Cisco IOS Releases before 12.1(2)T
|
Cisco proprietary5
|
vofr cisco6
|
session protocol cisco-switched
|
For user-dialed calls: none
For auto-ringdown calls:
connection plar destination-string
|
Tandem Switching of Switched Calls
Depending on which router is the end node and which is the tandem node, the correct Frame Relay PVC type must be configured. Table 32 shows the router combinations that can serve as end and tandem nodes and the command that is required to enable VoFR.
Table 32 VoFR End and Tandem Node Combinations
End Node
|
Tandem Node
|
Required VoFR Command
|
Cisco 2600, Cisco 3600, or Cisco 7200 and Cisco MC3810 multiservice concentrator
|
Cisco 2600, Cisco 3600, or Cisco 7200 and Cisco MC3810 multiservice concentrator
|
vofr call-control
|
Cisco 2600 or Cisco 3600 and Cisco MC3810 multiservice concentrator
|
Cisco MC3810 multiservice concentrator running Cisco IOS releases before 12.1(2)T
|
vofr cisco
|
Cisco MC3810 multiservice concentrator running Cisco IOS releases before 12.1(2)T
|
Cisco 2600, Cisco 3600, or Cisco 7200
|
vofr cisco
|
Note When you are creating voice networks with a mixture of router types, the Cisco MC3810 multiservice concentrator must be running Cisco IOS Release 12.0(3)XG, 12.0(4)T, or later releases, to act as a tandem node. For each configured tandem node, two VoFR dial peers must be configured, one for each tandem connection.
To configure VoFR dial peers on tandem routers, use the following commands beginning in global configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# dial-peer voice number vofr
|
Defines a VoFR dial peer and enters dial peer configuration mode. All subsequent commands that are entered in dial peer voice configuration mode before exiting apply to this dial peer.
|
Step 2
|
Router(config-dial-peer)# destination-pattern
[+]string[T]
|
Configures the dial peer destination pattern. The same restrictions for the string listed in the POTS dial peer configuration also apply to the VoFR destination pattern.
|
Step 3
|
Router(config-dial-peer)# session target interface
dlci
|
Configures the Frame Relay session target for the dial peer.
|
Step 4
|
Router(config-dial-peer)# preference value
|
(Optional) Configures a preference for the VoFR dial peer. The value argument is a number from 0 to 10 where the lower the number, the higher the preference in hunt groups.
|
To configure the next VoFR dial peer, exit dial peer configuration mode by entering exit, and repeat Steps 1 through 4. On tandem nodes, at least two VoFR dial peers are required, one for each call leg.
Configuring Cisco Trunk Calls
Before configuring the Cisco trunk calls, consider the following restrictions and recommendations:
•VoFR dial peers must be configured to send Cisco trunk calls over the Frame Relay network. Cisco trunk calls are permanent calls. One critical task is configuring the signal type for the dial peer. It must be the same at both ends of the permanent voice call. See the "Configuring Dial Peers, Dial Plans, and Digit Manipulation" chapter for more information.
•When a permanent connection between a T1/E1 Cisco MC3810 multiservice concentrator and an analog voice port on a Cisco 2600 or Cisco 3600 series routers is configured, the default signal type is cas.
•Use of Cisco trunks for permanent calls is recommended over FRF.11 trunk calls unless FRF.11 compliant standards-based interworking is required with non-Cisco devices. The Cisco trunk protocol is a superset of the FRF.11 protocol and contains Cisco proprietary extensions designed to support switched call routing and other advanced features.
Table 33 lists the supported VoFR connections and the commands to enter.
Table 33 VoFR Connections for Cisco Trunk Calls
Cisco Trunk Calls
|
Data Fragmentation Supported
|
VoFR
Command
|
Session Protocol Command 1
|
Voice Port
Command
|
To routers supporting VoFR
|
FRF.11 Annex C
|
vofr data cid call-control cid
|
session protocol cisco-switched
|
connection trunk destination-string [answer mode]
|
To a Cisco MC3810 multiservice concentrator running Cisco IOS Releases before 12.0(7) XK and 12.1(2)T
|
Cisco proprietary
|
vofr cisco2
|
session protocol cisco-switched
|
connection trunk destination-string [answer mode]
|
To configure Cisco trunk permanent calls, use the following commands beginning in interface configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config-if)# frame-relay interface-dlci dlci
|
Configures the DLCI to support VoFR.
Note The voice-encap option of the frame-relay interface-dlci command on the Cisco MC3810 multiservice concentrator is no longer supported beginning in Cisco IOS 12.2.
|
Step 2
|
Router(config-if)# vofr [[cisco] | [[data cid]
[call-control][cid]]]]
|
Enables VoFR on the DLCI. If the vofr command is entered without any keywords or arguments, the data subchannel is CID 4, and there is no call-control subchannel.
Note When the vofr command is used, all subchannels on the DLCI are configured for FRF.11 encapsulation. This configuration uses the standard FRF.11 Annex C fragmentation.
The vofr command uses WFQ at the PVC level. If the vofr cisco command is used, WFQ cannot be disabled.
If only tandem calls are being configured, stop here, otherwise proceed to Step 3.
|
Step 3
|
Router(config]# voice-port
|
Identifies the voice port to configure and enters voice-port configuration mode.
Note The voice-port command is hardware specific. See the Cisco IOS Voice, Video, and Fax Command Reference Guide for more information.
|
Step 4
|
Router(config-voice-port)# connection trunk
destination-string [answer-mode]
|
Configures the trunk connection by specifying the telephone number in destination-string. One side must be the call initiator (master) and the other side is the call answerer (slave). By default, the voice port is the master. The answer-mode keyword specifies the voice port that operates in slave mode.
|
Step 5
|
Router(config-voice-port)# shutdown
|
Shuts down the voice port.
|
Step 6
|
Router(config-voice-port)# no shutdown
|
Reactivates the voice port to enable the trunk connection.
|
Note When the connection trunk or no connection trunk command is entered, the voice port must be toggled by entering shutdown, and then no shutdown before the changes take effect.
Configuring FRF.11 Trunk Calls
On the Cisco MC3810 multiservice concentrators and Cisco 2600 and 3600 series routers, FRF.11 trunk calls to a second router can be configured, except tandem FRF.11 trunk calls. Configuring FRF.11 trunk calls to a second router requires that the session protocol dial peer configuration command be set to frf11-trunk.
Table 34 lists the supported VoFR connections and the required commands to configure FRF.11 trunk calls.
Table 34 VoFR Connections for FRF.11 Trunk (Private-Line) Calls
FRF.11 Trunk Calls
|
Data Fragmentation Supported
|
|
Session Protocol Command
|
Voice Port
Command
|
To routers supporting VoFR
|
FRF.11 Annex C
|
vofr [data cid] [call-control cid]2
|
session protocol frf11-trunk
|
connection trunk destination-string [answer mode]
|
To configure FRF.11 trunk calls, use the following commands beginning in interface configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config-if)# frame-relay interface-dlci dlci
|
Configures the DLCI and enters DLCI configuration mode.
|
Step 2
|
Router(config-fr-dlci)# vofr [data cid]
[call-control cid]
|
Configures the DLCI and optionally enters the data and call-control CIDs. When the keywords and arguments are configured, all subchannels on the DLCI are configured for FRF.11 encapsulation except the data subchannel. If no keywords or arguments are entered, the data subchannel is CID 4, and there is no call-control subchannel.
|
Step 3
|
Router(config)# voice-port
|
Identifies the voice port to configure and enters voice-port configuration mode.
Note The voice-port command is hardware specific. Refer to the Cisco IOS Voice, Video, and Fax Command Reference publication for more information.
|
Step 4
|
Router(config-voice-port)# connection trunk
destination-string [answer-mode]
|
Configures the trunk connection by specifying the telephone number in destination-string. One side of a call must act as the call initiator (master) and the other side as the call answerer (slave). By default, the voice port is the master.
|
Step 5
|
Router(config-voice-port)# shutdown
|
Shuts down the voice port.
|
Step 6
|
Router(config-voice-port)# no shutdown
|
Reactivates the voice port to enable the trunk connection.
|
Note When the connection trunk or no connection trunk command is entered, the voice port must be toggled by entering shutdown, and then no shutdown before the changes take effect.
Verifying the Voice Connections
To verify switched calls voice connections, perform the following tasks:
•Pick up the telephone handset and verify that there is a dial tone.
•Call from a local telephone to the configured dial peer and verify that the call completes.
To verify the FXO-FXS trunk calls to a remote PBX, perform the following tasks:
•Pick up the telephone and listen for a dial tone from the remote PBX.
•Dial a telephone number, so that the remote PBX routes the call.
To verify the voice connections, perform the following tasks:
•Check the validity of the dial peer and voice port configuration by performing the following tasks:
–Enter the show dial-peer voice command to verify that the data configured is correct.
–Enter the show dial-peer voice summary command to check the validity of the dial peer configurations.
–Enter the show voice port command to show the status of the voice ports.
–Enter the show call active voice with the keyword brief to show the call status for all voice ports.
–Enter the show voice call command to check the validity of the voice port configuration.
–Enter the show voice dsp command to show the current status of all DSP voice channels.
–Enter the show voice permanent command to show the status of Cisco trunk permanent calls.
–Enter the show call history command to show the active call table.
•Check the validity of the VoFR configuration on the DLCI by performing the following task:
–Enter the show frame-relay vofr [interface [dlci [cid]]] command to show the VoFR configuration. This command is not supported on the Cisco MC3810 multiservice concentrator when the vofr cisco command is configured.
Verifying the Frame Relay Configuration
Check the validity of the configuration by performing the following tasks:
•Enter the show frame-relay pvc command to show the status of the PVCs.
•Enter the show frame-relay vofr command with the arguments interface, dlci, and cid to show statistics and information on the open subchannels. This command does not display if the vofr cisco command is entered on the Cisco MC3810 multiservice concentrator.
•Enter the show frame-relay fragment command with the arguments interface number and dlci to show the Frame Relay fragmentation configuration.
•Enter the show traffic-shape queue command to display the traffic-shaping information if Frame Relay traffic shaping is configured. The queue option displays the queueing statistics.
Troubleshooting Tips
To troubleshoot and
resolve configuration issues, perform the following tasks:
•If no calls are going through, ensure that the frame-relay voice bandwidth command is configured.
•If VoFR is configured on a PVC and there are problems with data connectivity on that PVC, ensure that the frame-relay fragment command has been configured.
•If data is not being transmitted but fragmentation is configured, ensure that Frame Relay traffic shaping is turned on.
•If the problem is with the dial plan or the dial peers, use the show dial-plan number command with the argument dial string to display which dial peers are being used when a specific number is called.
•If there are problems connecting an FRF.11 trunk call, ensure that the session protocol dial peer command is set to frf11-trunk.
•If FRF.11 trunk calls on the Cisco 2600 or Cisco 3600 series routers are being configured, verify that the called-number vofr dial peer command is configured and that its number matches the destination pattern of the corresponding POTS dial peer.
•Ensure that the voice port is set to no shutdown.
•Ensure that the serial port or the T1/E1 controller is set to no shutdown.
•Toggle the voice port by first entering shutdown, and then no shutdown every time the connection trunk or no connection trunk command is entered.
Monitoring and Maintaining the VoFR Configuration
To monitor and maintain the VoFR configuration, use the following commands in EXEC mode as needed:
Command
|
Purpose
|
Router# show call active voice [brief]
|
Displays the active call table.
|
Router# show call history voice [last number] | [brief]
|
Displays the call history table.
|
or
|
Router# show call history voice record
|
Router# show dial-peer voice
|
Displays configuration information and call statistics for dial peers.
|
Router# show frame-relay fragment
|
Displays information about the Frame Relay fragmentation taking place in the Cisco router.
|
Router# show frame-relay pvc
|
Displays statistics about PVCs for Frame Relay interfaces.
|
Router# show frame-relay vofr
|
Displays the FRF.11 subchannels information on VoFR DLCIs.
|
Router# show interfaces serial
|
Displays information about a serial interface.
|
Router# show traffic-shape queue
|
Displays information about the elements queued at a particular time at the VC (DLCI) level.
|
Router# show voice call
|
Displays the call status for all voice ports on the Cisco MC3810 multiservice concentrators.
|
Router# show voice permanent-call
|
Displays information about the permanent calls on a voice interface.
|
VoFR Configuration Examples
This section provides specific configuration examples for VoFR connections and includes:
•Two Routers Using Frame Relay Fragmentation Example
•Two Routers Using a VoFR PVC Example
•Router Using VoFR PVCs Connected to Cisco MC3810s Before 12.1(2)T Example
•Cisco Trunk Calls Between Two Routers Example
•FRF.11 Trunk Calls Between Two Routers Example
•Tandem Configuration Examples
•Cisco Trunk Call with Hunt Groups Example
Two Routers Using Frame Relay Fragmentation Example
Figure 92 shows an example of Frame Relay fragmentation between two routers. This configuration uses FRF.12 fragmentation.
Figure 92 Two Routers Using Frame Relay Fragmentation
Router A
|
Router B
|
ip address xxx.xxx.xxx 255.255.255.0
frame-relay traffic shaping
frame-relay interface-dlci 100
map-class frame-relay toto
encapsulation frame-relay
|
ip address xxx.xxx.xxx 255.255.255.0
frame-relay traffic shaping
frame-relay interface-dlci 100
map-class frame-relay toto
encapsulation frame-relay
|
Two Routers Using a VoFR PVC Example
Figure 93 shows an example of two routers that use FRF.11 Annex C fragmentation with connections using a VoFR PVC.
Figure 93 Two Cisco 3600 Series Routers Using a VoFR PVC
Router A
|
Router B
|
frame-relay traffic shaping
frame-relay interface-dlci 100
map-class frame-relay toto
frame-relay voice-bandwidth t
|
frame-relay traffic shaping
frame-relay interface-dlci 100
map-class frame-relay toto
frame-relay voice-bandwidth t
|
Router Using VoFR PVCs Connected to Cisco MC3810s Before 12.1(2)T Example
Figure 94 shows an example of a Cisco 3600 series router with connections to a Cisco MC3810 multiservice concentrator running a Cisco IOS release before12.1(2)T. In this example, the VoFR interface on both the Cisco 3600 series router and the Cisco MC3810 multiservice concentrator is configured by using the vofr cisco command. This configuration uses FRF.11 Annex C fragmentation.
Figure 94 Router Using VoFR PVCs Connected to a Cisco MC3810 Multiservice Concentrator
Router A
|
Router B
|
|
|
ip address xxx.xxx.xxx
255.255.255.0
|
ip address xxx.xxx.xxx
255.255.255.0
|
frame-relay traffic shaping
|
frame-relay traffic shaping
|
|
|
frame-relay interface-dlci 100
|
|
|
frame-relay interface-dlci 100
|
|
|
|
|
map-class frame-relay toto
|
map-class frame-relay toto
|
frame-relay voice-bandwidth t
|
frame-relay voice-bandwidth t
|
|
|
|
|
|
|
|
|
Cisco Trunk Calls Between Two Routers Example
Figure 95 shows an example of VoFR Cisco trunk calls between two routers.
Figure 95 Cisco Trunk (Private-Line) Calls Between Two Routers
Router A
|
Router B
|
|
|
ip address xxx.xxx.xxx
255.255.255.0
|
ip address xxx.xxx.xxx
255.255.255.0
|
encapsulation frame-relay
|
encapsulation frame-relay
|
frame-relay traffic shaping
|
frame-relay traffic shaping
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 100
|
|
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
|
|
map-class frame-relay voice
|
map-class frame-relay voice
|
|
|
|
|
frame-relay voice bandwidth v
|
frame-relay voice bandwidth v
|
|
|
|
|
|
|
|
|
connection trunk 6001 answer-mode
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
session protocol cisco-switched
|
session protocol cisco-switched
|
|
|
FRF.11 Trunk Calls Between Two Routers Example
Figure 96 shows an example of FRF.11 trunk calls configured between two routers.
Figure 96 FRF.11 Trunk Calls Between Two Routers
Router A
|
|
ip address xxx.xxx.xxx 255.255.255.0
encapsulation frame-relay
frame-relay traffic shaping
frame-relay interface-dlci 100
map-class frame-relay voice
frame-relay voice bandwidth v
session protocol frf11-trunk
|
ip address xxx.xxx.xxx 255.255.255.0
encapsulation frame-relay
frame-relay traffic shaping
frame-relay interface-dlci 100
map-class frame-relay voice
frame-relay voice bandwidth v
session protocol frf11-trunk
|
Tandem Configuration Examples
Figure 97 shows an example of a tandem configuration with two Cisco 3600 series routers as endpoints and a third Cisco 3600 series router as a tandem node.
Figure 97 Tandem Configuration with Three Routers for Switched Calls
Router A Endpoint
|
Router C Tandem Node
|
Router B Endpoint
|
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 100
vofr data 4 call-control 5
map-class frame-relay voice
frame-relay voice bandwidth c
session target serial 0/0 100
|
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 100
vofr data 4 call-control 5
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 200
map-class frame-relay voice
frame-relay voice bandwidth c
session target serial 0/0 100
session target serial 0/1 200
|
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 100
vofr data 4 call-control 5
map-class frame-relay voice
frame-relay voice bandwidth c
session target serial 0/0 200
|
Figure 98 shows an example of a tandem configuration with a Cisco MC3810 multiservice concentrator acting as a tandem node.
Figure 98 Tandem Configuration with a Cisco MC3810 Multiservice Concentrator Tandem Node for Switched Calls
Router A Endpoint
|
Router C Tandem Node
|
Router B Endpoint
|
|
|
|
encapsulation frame-relay
|
encapsulation frame-relay
|
encapsulation frame-relay
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 100
|
|
|
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
|
|
|
map-class frame-relay voice
|
|
map-class frame-relay voice
|
|
encapsulation frame-relay
|
|
|
frame-relay traffic-shaping
|
|
|
frame-relay interface-dlci 200
|
|
frame-relay voice bandwidth c
|
|
frame-relay voice bandwidth c
|
|
vofr data 4 call-control 5
|
|
|
|
|
|
map-class frame-relay voice
|
|
|
|
|
|
|
|
|
|
|
|
frame-relay voice bandwidth c
|
|
|
|
|
|
|
|
session target serial 0/0 100
|
|
session target serial 0/0 200
|
|
|
|
|
session target serial 0/0 100
|
|
|
|
|
|
|
|
|
|
|
|
session target serial 0/1 200
|
|
Figure 99 shows an example of a tandem configuration with a Cisco MC3810 multiservice concentrator acting as an endpoint node for Cisco trunk calls. When a Cisco MC3810 multiservice concentrator is on a VoFR network, the configuration for connections to and from the Cisco MC3810 multiservice concentrator is slightly different than for other routers that support VoFR. The vofr cisco command is required for those connections.
Figure 99 Tandem Configuration with a Cisco MC3810 Multiservice Concentrator Endpoint Node
Router A Endpoint
|
Router C Tandem Node
|
Router B Endpoint
|
|
|
|
encapsulation frame-relay
|
encapsulation frame-relay
|
encapsulation frame-relay
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 200
|
|
|
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
|
|
|
map-class frame-relay voice
|
|
map-class frame-relay voice
|
|
encapsulation frame-relay
|
|
|
frame-relay traffic-shaping
|
|
|
frame-relay interface-dlci 200
|
|
frame-relay voice bandwidth c
|
|
frame-relay voice bandwidth c
|
|
vofr data 4 call-control 5
|
|
|
|
|
|
map-class frame-relay voice
|
|
destination-pattern 1001A
|
|
destination-pattern 2001A
|
|
|
|
|
|
|
|
frame-relay voice bandwidth c
|
|
|
|
|
session target serial 0/0 100
|
|
session target serial 0 200
|
|
|
|
|
|
|
connection trunk 2001A answer-mode
|
session target serial 0/0 100
|
|
|
|
|
|
|
|
|
|
|
|
session target serial 0/1 200
|
|
Figure 100 shows an example of a tandem configuration with Cisco MC3810 multiservice concentrators as both endpoint and tandem nodes.
Note When a Cisco MC3810 multiservice concentrator running Cisco IOS software releases earlier than 12.1(2)T are used on a VoFR network, the configuration for connections to and from that Cisco MC3810 multiservice concentrator is slightly different from what is used for other routers that support VoFR. The vofr cisco command is required for these connections on the Cisco MC3810 multiservice concentrator.
Figure 100 Configuration with All Cisco MC3810 Multiservice Concentrators as Endpoint and Tandem Nodes
Router A Endpoint
|
Router C Tandem Node
(Cisco IOS Releases Before 12.1(2)T)
|
Router B Endpoint
|
|
|
|
encapsulation frame-relay
|
encapsulation frame-relay
|
encapsulation frame-relay
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 200
|
|
|
|
|
|
|
|
|
|
map-class frame-relay voice
|
|
map-class frame-relay voice
|
|
encapsulation frame-relay
|
|
|
frame-relay traffic-shaping
|
|
frame-relay voice bandwidth c
|
frame-relay interface-dlci 200
|
frame-relay voice bandwidth c
|
|
|
|
|
|
|
|
|
|
|
map-class frame-relay voice
|
|
|
|
|
|
|
|
|
|
|
|
frame-relay voice bandwidth c
|
|
|
|
|
session target serial 0 100
|
|
session target serial 0 200
|
|
|
|
|
|
|
|
session target serial 0 100
|
|
|
|
|
|
|
|
|
|
|
|
session target serial 1 200
|
|
Cisco Trunk Call with Hunt Groups Example
Figure 101 shows an example of a Cisco trunk call with hunt groups configured. In this example, the two routers are in master-slave mode with a backup path. Router B is configured as a slave and Router A is configured as the master. The master makes periodic attempts to establish the trunk until the trunk is established.
Two dial peers match the destination string configured in the voice port, but one dial peer has a higher preference, so the call setup is attempted through that dial peer. If the call setup fails, the master can continue attempting call setups using the next available dial peer. After all dial peers are exhausted, the master can continue following the list cyclically by starting again from the dial peer with the highest preference.
Figure 101 Cisco Trunk Call with Hunt Groups
Router A
|
Router B
|
|
|
encapsulation frame-relay
|
encapsulation frame-relay
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay interface-dlci 100
|
frame-relay interface-dlci 100
|
|
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
|
|
|
|
encapsulation frame-relay
|
encapsulation frame-relay
|
frame-relay traffic-shaping
|
frame-relay traffic-shaping
|
frame-relay interface-dlci 200
|
frame-relay interface-dlci 200
|
|
|
vofr data 4 call-control 5
|
vofr data 4 call-control 5
|
|
|
map-class frame-relay voice
|
map-class frame-relay voice
|
|
|
|
|
frame-relay voice bandwidth c
|
frame-relay voice bandwidth c
|
|
|
|
|
|
|
destination-pattern 1001A
|
destination-pattern 2001A
|
|
|
|
|
|
|
|
|
session target serial0 100
|
session target serial0 100
|
|
|
|
|
|
|
|
|
session target serial1 200
|
session target serial1 200
|
|
|
|
|
|
|
|
|
|
connection trunk 1001A answer-mode
|
|
|
|
|
