|
|
This chapter explains how to configure Voice over IP (VoIP) on Cisco 3600 series routers and contains the following sections:
All of these tasks are described in the following sections.
Voice over IP offers the following benefits:
Channel Associated Signaling (CAS)---A form of signaling used on a T1 line. With CAS, a signaling element is dedicated to each channel in the T1 frame. This type of signaling is sometimes called Robbed Bit Signaling (RBS) because a bit is taken out (or robbed) from the user's data stream to provide signaling information to and from the switch.
CODEC---Coder-decoder compression scheme or technique. In Voice over IP, it specifies the voice coder rate of speech for a dial peer.
Dial peer---An addressable call endpoint. In Voice over IP, there are two kinds of dial peers: POTS and VoIP.
DS0---A 64K channel on an E1 or T1 WAN interface.
DTMF---Dual tone multifrequency. Use of two simultaneous voice-band tones for dial (such as touch tone).
Multilink PPP---Multilink Point-to-Point Protocol. This protocol is a method of splitting, recombining, and sequencing datagrams across multiple logical data links.
PBX---Private Branch Exchange. Privately-owned central switching office.
POTS dial peer---Dial peer connected via a traditional telephony network. POTS peers point to a particular voice port on a voice network device.
PSTN---Public Switched Telephone Network. PSTN refers to the local telephone company.
PVC---Permanent Virtual Circuit.
QoS---Quality of Service, which refers to the measure of service quality provided to the user.
RSVP---Resource Reservation Protocol. This protocol supports the reservation of resources across an IP network.
VoIP dial peer---Dial peer connected via a packet network; in the case of Voice over IP, this is an IP network. VoIP peers point to specific VoIP devices.
Before you can configure your Cisco 3600 series router to use Voice over IP, you must first:
After you have analyzed your dial plan and decided how to integrate it into your existing IP network, you are ready to configure your network devices to support Voice over IP.
Before configuring Voice over IP on your Cisco 3600 series router, it helps to understand what happens at an application level when you place a call using Voice over IP. The general flow of a two-party voice call using Voice over IP is as follows:
1. The user picks up the handset; this signals an off-hook condition to the signaling application part of Voice over IP in the Cisco 3600 series router.
2. The session application part of Voice over IP issues a dial tone and waits for the user to dial a telephone number.
3. The user dials the telephone number; those numbers are accumulated and stored by the session application.
4. After enough digits are accumulated to match a configured destination pattern, the telephone number is mapped to an IP host via the dial plan mapper. The IP host has a direct connection to either the destination telephone number or a PBX that is responsible for completing the call to the configured destination pattern.
5. The session application then runs the H.323 session protocol to establish a transmission and a reception channel for each direction over the IP network. If the call is being handled by a PBX, the PBX forwards the call to the destination telephone. If RSVP has been configured, the RSVP reservations are put into effect to achieve the desired quality of service over the IP network.
6. The CODECs are enabled for both ends of the connection and the conversation proceeds using RTP/UDP/IP as the protocol stack.
7. Any call-progress indications (or other signals that can be carried in-band) are cut through the voice path as soon as end-to-end audio channel is established. Signaling that can be detected by the voice ports (for example, in-band DTMF digits after the call setup is complete) is also trapped by the session application at either end of the connection and carried over the IP network encapsulated in RTCP using the RTCP APP extension mechanism.
8. When either end of the call hangs up, the RSVP reservations are torn down (if RSVP is used) and the session ends. Each end becomes idle, waiting for the next off-hook condition to trigger another call setup.
To configure Voice over IP on the Cisco 3600 series, you need to perform the following steps:
Step 1 Configure your IP network to support real-time voice traffic. Fine-tuning your network to adequately support VoIP involves a series of protocols and features geared toward Quality of Service (QoS). To configure your IP network for real-time voice traffic, you need to take into consideration the entire scope of your network, then select and configure the appropriate QoS tool or tools:
Refer to "Configure IP Networks for Real-Time Voice Traffic" section for information about how to select and configure the appropriate QoS tools to optimize voice traffic on your network.
Step 2 (Optional) If you plan to run Voice over IP over Frame Relay, you need to take certain factors into consideration when configuring Voice over IP for it to run smoothly over Frame Relay. For example, a public Frame Relay cloud provides no guarantees for QoS. Refer to the "Configure Frame Relay for Voice over IP" section for information about deploying Voice over IP over Frame Relay.
Step 3 Use the num-exp command to configure number expansion if your telephone network is configured so that you can reach a destination by dialing only a portion (an extension number) of the full E.164 telephone number. Refer to the "Configure Number Expansion" section for information about number expansion.
Step 4 Use the dial-peer voice command to define dial peers and switch to the dial-peer configuration mode. Each dial peer defines the characteristics associated with a call leg. A call leg is a discrete segment of a call connection that lies between two points in the connection. An end-to-end call is comprised of four call legs, two from the perspective of the source access server, and two from the perspective of the destination access server. Dial peers are used to apply attributes to call legs and to identify call origin and destination. There are two different kinds of dial peers:
Refer to the "Configure Dial Peers" section and the "Optimize Dial Peer and Network Interface Configurations" section for additional information about configuring dial peers and dial-peer characteristics.
Step 5 You need to configure your Cisco 3600 series router to support voice ports. In general, voice-port commands define the characteristics associated with a particular voice-port signaling type. voice ports on the Cisco 3600 series support three basic voice signaling types:
Under most circumstances, the default voice-port command values are adequate to configure FXO and FXS ports to transport voice data over your existing IP network. Because of the inherent complexities involved with PBX networks, E&M ports might need specific voice-port values configured, depending on the specifications of the devices in your telephony network. For information about configuring voice ports, refer to the "Configuring Voice Ports" section.
The important thing to remember is that QoS must be configured throughout your network---not just on the Cisco 3600 series devices running VoIP---to improve voice network performance. Not all QoS techniques are appropriate for all network routers. Edge routers and backbone routers in your network do not necessarily perform the same operations; the QoS tasks they perform might differ as well. To configure your IP network for real-time voice traffic, you need to take into consideration the functions of both edge and backbone routers in your network, then select the appropriate QoS tool or tools.
In general, edge routers perform the following QoS functions:
In general, backbone routers perform the following QoS functions:
Scalable QoS solutions require cooperative edge and backbone functions.
Although not mandatory, some QoS tools have been identified as being valuable in fine-tuning your network to support real-time voice traffic. To configure your IP network for QoS using these tools, perform one or more of the following tasks:
Each of these tasks is discussed in the following sections.
RSVP can be equated to a dynamic access list for packet flows.
You should configure RSVP to ensure QoS if the following conditions exist in your network:
To minimally configure RSVP for voice traffic, you must enable RSVP on each interface where priority needs to be set.
By default, RSVP is disabled so that it is backward compatible with systems that do not implement RSVP. To enable RSVP on an interface, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
Enable RSVP for IP on an interface. |
This command starts RSVP and sets the bandwidth and single-flow limits. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount reservable by a flow can be up to the entire reservable bandwidth.
On subinterfaces, this applies the more restrictive of the available bandwidths of the physical interface and the subinterface.
Reservations on individual circuits that do not exceed the single flow limit normally succeed. If, however, reservations have been made on other circuits adding up to the line speed, and a reservation is made on a subinterface which itself has enough remaining bandwidth, it will still be refused because the physical interface lacks supporting bandwidth.
Cisco AS5300s running VoIP and configured for RSVP request allocations per the following formula:
bps=packet_size+ip/udp/rtp header size * 50 per second
For G.729, the allocation works out to be 24,000 bps. For G.711, the allocation is 80,000 bps.
For more information about configuring RSVP, refer to the "Configuring RSVP" chapter of the Cisco IOS Release 11.3 Network Protocols Configuration Guide, Part 1.
The following example enables RSVP and sets the maximum bandwidth to 100 kbps and the maximum bandwidth per single request to 32 kbps (the example presumes that both VoIP dial peers have been configured):
interface serial 1/0/0 ip rsvp bandwidth 100 32 fair-queue end ! dial-peer voice 1211 voip req-qos controlled-load ! dial-peer voice 1212 voip req-qos controlled-load
In general, Multilink PPP with interleaving is used in conjunction with weighted fair queuing and RSVP or IP Precedence to ensure voice packet delivery. Use Multilink PPP with interleaving and weighted fair queuing to define how data will be managed; use RSVP or IP Precedence to give priority to voice packets.
You should configure Multilink PPP if the following conditions exist in your network:
Multilink PPP support for interleaving can be configured on virtual templates, dialer interfaces, and ISDN BRI or PRI interfaces. To configure interleaving, you need to complete the following tasks:
To configure Multilink PPP and interleaving on a configured and operational interface or virtual interface template, use the following commands in interface mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ppp multilink | Enable Multilink PPP. | ||
| ppp multilink interleave | Enable real-time packet interleaving. | ||
| ppp multilink fragment-delay milliseconds | Optionally, configure a maximum fragment delay. | ||
| ip rtp reserve lowest-UDP-port range-of-ports [maximum-bandwidth] | Reserve a special queue for real-time packet flows to specified destination User Datagram Protocol (UDP) ports, allowing real-time traffic to have higher priority than other flows. This is only applicable if you have not configured RSVP. |
For more information about Multilink PPP, refer to the "Configuring Media-Independent PPP and Multilink PPP" chapter in the Cisco IOS Release 11.3 Dial Solutions Configuration Guide.
The following example defines a virtual interface template that enables Multilink PPP with interleaving and a maximum real-time traffic delay of 20 milliseconds, and then applies that virtual template to the Multilink PPP bundle:
interface virtual-template 1 ppp multilink encapsulated ppp ppp multilink interleave ppp multilink fragment-delay 20 ip rtp reserve 16384 100 64 multilink virtual-template 1
Real-Time Transport Protocol (RTP) is used for carrying packetized audio traffic over an IP network. RTP header compression compresses the IP/UDP/RTP header in an RTP data packet from 40 bytes to approximately 2 to 4 bytes (most of the time), as shown in Figure 2-1.
This compression feature is beneficial if you are running Voice over IP over slow links. Enabling compression on both ends of a low-bandwidth serial link can greatly reduce the network overhead if there is a lot of RTP traffic on that slow link.
Typically, an RTP packet has a payload of approximately 20 to 160 bytes for audio applications that use compressed payloads. RTP header compression is especially beneficial when the RTP payload size is small (for example, compressed audio payloads between 20 and 50 bytes).
You should configure RTP header compression if the following conditions exist in your network:
To use RTP header compression, you need to enable compression on both ends of a serial connection. To enable RTP header compression, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ip rtp header-compression [passive] | Enable RTP header compression. |
If you include the passive keyword, the software compresses outgoing RTP packets only if incoming RTP packets on the same interface are compressed. If you use the command without the passive keyword, the software compresses all RTP traffic.
By default, the software supports a total of 16 RTP header compression connections on an interface. To specify a different number of RTP header compression connections, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
Specify the total number of RTP header compression connections supported on an interface. |
The following example enables RTP header compression for a serial interface:
interface 0 ip rtp header-compression encapsulation ppp ip rtp compression-connections 25
For more information about RTP header compression, see the "Configuring IP Multicast Routing" chapter of the Cisco IOS Release 11.3 Network Protocols Configuration Guide, Part 1.
16384 = 4(number of voice ports in the Cisco 3600 series router)
Custom Queuing and other methods for identifying high priority streams should be configured for these port ranges. For more information about custom queuing, refer to the "Managing System Performance" chapter in the Cisco IOS Release 11.3 Configuration Fundamentals Configuration Guide.
In general, weighted fair queuing is used in conjunction with Multilink PPP with interleaving and RSVP or IP Precedence to ensure that voice packet delivery. Use weighted fair queuing with Multilink PPP to define how data will be managed; use RSVP or IP Precedence to give priority to voice packets. For more information about weighted fair queuing, refer to the "Managing System Performance" chapter in the Cisco IOS Release 11.3 Configuration Fundamentals Configuration Guide.
For Frame Relay links with slow output rates (less than or equal to 64 kbps), where data and voice are being transmitted over the same PVC, we recommend the following solutions:
In Cisco IOS Release 11.3, Frame Relay Traffic Shaping is not compatible with RSVP. We suggest one of the following workarounds:
interface Serial0/0 mtu 300 no ip address encapsulation frame-relay no ip route-cache no ip mroute-cache fair-queue 64 256 1000 frame-relay ip rtp header-compression interface Serial0/0.1 point-to-point mtu 300 ip address 40.0.0.7 255.0.0.0 ip rsvp bandwidth 48 48 no ip route-cache no ip mroute-cache bandwidth 64 traffic-shape rate 32000 4000 4000 frame-relay interface-dlci 16 frame-relay ip rtp header-compression
In this configuration example, the main interface has been configured as follows:
The subinterface has been configured as follows:
For more information about Frame Relay, refer to the "Configuring Frame Relay" chapter in the Cisco IOS Release 11.3 Wide-Area Networking Configuration Guide.
In Figure 2-2, a small company wants to use Voice over IP to integrate its telephony network with its existing IP network. The destination pattern (or expanded telephone number) associated with Access Server 1 (located to the left of the IP cloud) is (408) 526-xxxx, where xxxx identifies the individual dial peers by extension. The destination pattern (or expanded telephone number) associated with Access Server 2 (located to the right of the IP cloud) is (729) 422-xxxx.
Table 2-1 shows the number expansion table for this scenario.
| Extension | Destination Pattern | Num-Exp Command Entry |
|---|---|---|
5.... | 40852..... | num-exp 5.... 408525.... |
6.... | 40852..... | num-exp 6.... 408526.... |
7.... | 40852..... | num-exp 7.... 408527.... |
1... | 729422.... | num-exp 2.... 729422.... |
The information included in this example needs to be configured on both Access Server 1 and Access Server 2.
To define how to expand an extension number into a particular destination pattern, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
num-exp extension-number extension-string | Configure number expansion. |
You can verify the number expansion information by using the show num-exp command to verify that you have mapped the telephone numbers correctly.
After you have configured dial peers and assigned destination patterns to them, you can verify number expansion information by using the show dialplan number command to see how a telephone number maps to a dial peer.
The key point to understanding how Voice over IP functions is to understand dial peers. Each dial peer defines the characteristics associated with a call leg, as shown in Figure 2-3 and Figure 2-4. A call leg is a discrete segment of a call connection that lies between two points in the connection. All of the call legs for a particular connection have the same connection ID.
There are two different kinds of dial peers:
An end-to-end call is comprised of four call legs, two from the perspective of the source access server as shown in Figure 2-3, and two from the perspective of the destination access server as shown in Figure 2-4. A dial peer is associated with each one of these call legs. Dial peers are used to apply attributes to call legs and to identify call origin and destination. Attributes applied to a call leg include QoS, CODEC, VAD, and fax rate.
For inbound call legs, a dial peer might be associated to the calling number or the port designation. Outbound call legs always have a dial peer associated with them. The destination pattern is used to identify the outbound dial peer. The call is associated with the outbound dial peer at setup time.
POTS peers associate a telephone number with a particular voice port so that incoming calls for that telephone number can be received and outgoing calls can be placed. VoIP peers point to specific devices (by associating destination telephone numbers with a specific IP address) so that incoming calls can be received and outgoing calls can be placed. Both POTS and VoIP peers are needed to establish Voice over IP connections.
Establishing communication using Voice over IP is similar to configuring an IP static route: you are establishing a specific voice connection between two defined endpoints. As shown in Figure 2-5, for outgoing calls (from the perspective of the POTS dial peer 1), the POTS dial peer establishes the source (via the originating telephone number or voice port) of the call. The VoIP dial peer establishes the destination by associating the destination telephone number with a specific IP address.
To configure call connectivity between the source and destination as illustrated in Figure 2-5, enter the following commands on router 10.1.2.2:
dial-peer voice 1 pots destination-pattern 1408526.... port 1/0/0 dial-peer voice 2 voip destination-pattern 1310520.... session target ipv4:10.1.1.2
In the previous configuration example, the last four digits in the VoIP dial peer's destination pattern were replaced with wildcards. This means that from access server 10.1.2.2, calling any number string that begins with the digits "1310520" will result in a connection to access server 10.1.1.2. This implies that access server 10.1.1.2 services all numbers beginning with those digits. From access server 10.1.1.2, calling any number string that begins with the digits "1408526" will result in a connection to access server 10.1.2.2. This implies that access server 10.1.2.2 services all numbers beginning with those digits. For more information about stripping and adding digits, see the "Outbound Dialing on POTS Peers" section.
Figure 2-6 shows how to complete the end-to-end call between dial peer 1 and dial peer 4.
To complete the end-to-end call between dial peer 1 and dial peer 4 as illustrated in Figure 2-6, enter the following commands on router 10.1.1.2:
dial-peer voice 4 pots destination-pattern 1310520.... port 1/0/0 dial-peer voice 3 voip destination-pattern 1408526.... session target ipv4:10.1.2.2
Using the example in Figure 2-2, Router 1, with an IP address of 10.1.1.1, connects a small sales branch office to the main office through Router 2. There are three telephones in the sales branch office that need to be established as dial peers. Access Server 2, with an IP address of 10.1.1.2, is the primary gateway to the main office; as such, it needs to be connected to the company's PBX. There are four devices that need to be established as dial peers in the main office, all of which are basic telephones connected to the PBX. Figure 2-2 shows a diagram of this small voice network.
Table 2-2 shows the peer configuration table for the example illustrated in Figure 2-2.
| Commands | |||||||
|---|---|---|---|---|---|---|---|
| Dial Peer Tag | Ext | Dest-Pattern | Type | Voice Port | Session-Target | CODEC | QoS |
Access Server 1 |
|
|
|
|
|
|
|
1 | 6.... | +1408526.... | POTS |
|
|
|
|
10 |
| +1729422.... | VoIP |
| IPV4 10.1.1.2 | G.729 | Best Effort |
Access Server 2 |
|
|
|
|
|
|
|
11 |
| +1408526.... | VoIP |
| IPV4 10.1.1.1 | G.729 | Best Effort |
4 | 2.... | +1729422.... | POTS |
|
|
|
|
Once again, POTS peers enable incoming calls to be received by a particular telephony device. To configure a POTS peer, you need to uniquely identify the peer (by assigning it a unique tag number), define its telephone number(s), and associate it with a voice port through which calls will be established. Under most circumstances, the default values for the remaining dial-peer configuration commands will be sufficient to establish connections.
To enter the dial-peer configuration mode (and select POTS as the method of voice-related encapsulation), use the following command in global configuration mode:
| Command | Purpose |
|---|---|
dial-peer voice number pots | Enter the dial-peer configuration mode to configure a POTS peer. |
The number value of the dial-peer voice pots command is a tag that uniquely identifies the dial peer. (This number has local significance only.)
To configure the identified POTS peer, use the following commands in dial-peer configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| destination-pattern string | Define the telephone number associated with this POTS dial peer. | ||
| port controller number:D | Associate this POTS dial peer with a specific logical dial interface. |
For example, suppose there is a voice call whose E.164 called number is 1(310) 767-2222. If you configure a destination-pattern of "1310767" and a prefix of "9," the router will strip out "1310767" from the E.164 telephone number, leaving the extension number of "2222." It will then append the prefix, "9," to the front of the remaining numbers, so that the actual numbers dialed is "9, 2222." The comma in this example means that the router will pause for one second between dialing the "9" and the "2" to allow for a secondary dial tone.
For additional POTS dial-peer configuration options, refer to the "Voice over IP Commands for the Cisco 3600 Series" section.
Direct inward dial (DID) is used to determine how the called number is treated for incoming POTS call legs. As shown in Figure 2-7, incoming means from the perspective of the router. In this case, it is the call leg coming into the access server to be forwarded through to the appropriate destination pattern.
Unless otherwise configured, when a call arrives on the access server, the server presents a dial tone to the caller and collects digits until it can identify the destination dial peer. After the dial peer has been identified, the call is forwarded through the next call leg to the destination.
There are cases where it might be necessary for the server to use the called-number (DNIS) to find a dial peer for the outgoing call leg---for example, if the switch connecting the call to the server has already collected the digits. DID enables the server to match the called-number with a dial peer and then directly place the outbound call. With DID, the server does not present a dial tone to the caller and does not collect digits; it forwards the call directly to the configured destination.
To use DID and incoming called-number, a dial peer must be associated with the incoming call leg. Before doing this, it helps if you understand the logic behind the algorithm used to associate the incoming call leg with the dial peer.
The algorithm used to associate incoming call legs with dial peers uses three inputs (which are derived from signaling and interface information associated with the call) and four defined dial peer elements. The three signaling inputs are:
The four defined dial peer elements are:
Using the elements, the algorithm is as follows:
For all peers where call type (VoIP versus POTS) match dial peer type: if the type is matched, associate the called number with the incoming called-number else if the type is matched, associate calling-number with answer-address else if the type is matched, associate calling-number with destination-pattern else if the type is matched, associate voice port to port
This algorithm shows that if a value is not configured for answer-address, the origin address is used because, in most cases, the origin address and answer-address are the same.
To configure DID for a particular POTS dial peer, use the following commands, initially in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| dial-peer voice number pots | Enter the dial-peer configuration mode to configure a POTS peer. | ||
| direct-inward-dial | Specify direct inward dial for this POTS peer. |
For additional POTS dial-peer configuration options, refer to the "Voice over IP Commands for the Cisco 3600 Series" chapter.
Once again, VoIP peers enable outgoing calls to be made from a particular telephony device. To configure a VoIP peer, you need to uniquely identify the peer (by assigning it a unique tag number), define its destination telephone number and destination IP address. As with POTS peers, under most circumstances, the default values for the remaining dial-peer configuration commands will be adequate to establish connections.
To enter the dial-peer configuration mode (and select VoIP as the method of voice-related encapsulation), use the following command in global configuration mode:
| Command | Purpose |
|---|---|
dial-peer voice number voip | Enter the dial-peer configuration mode to configure a VoIP peer. |
The number value of the dial-peer voice voip command is a tag that uniquely identifies the dial peer.
To configure the identified VoIP peer, use the following commands in dial-peer configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| destination-pattern string | Define the destination telephone number associated with this VoIP dial peer. | ||
| session-target {ipv4:destination-address | dns:host-name} | Specify a destination IP address for this dial peer. |
For additional VoIP dial-peer configuration options, refer to the "Voice over IP Commands for the Cisco 3600 Series" chapter. For examples of how to configure dial peers, refer to the chapter, "Voice over IP Configuration Examples for the Cisco 3600 Series."
You can check the validity of your dial-peer configuration by performing the following tasks:
The Cisco 3600 currently provides only analog voice ports for its implementation of Voice over IP. The type of signaling associated with these analog voice ports depends on the interface module installed into the device. The Cisco 3600 series router supports either a two-port or four-port voice network module (VNM); VNMs can hold either 2 or 4 voice interface cards (VICs).
Each VIC is specific to a particular signaling type; therefore, VICs determine the type of signaling for the voice ports on that particular VNM. This means that even though VNMs can hold multiple VICs, each VIC on a VNM must conform to the same signaling type. For more information about the physical characteristics of VNMs and VICs or how to install them, refer to the installation document, Voice Network Module and Voice Interface Card Configuration Note, that came with your VNM.
Voice ports on the Cisco 3600 series support three basic voice signaling types:
In general, voice port commands define the characteristics associated with a particular voice port signaling type. Under most circumstances, the default voice port command values are adequate to configure FXO and FXS ports to transport voice data over your existing IP network. Because of the inherent complexities involved with PBX networks, E&M ports might need specific voice port values configured, depending on the specifications of the devices in your telephony network.
Under most circumstances the default voice port values are adequate for both FXO and FXS voice ports. If you need to change the default configuration for these voice ports, perform the following tasks. Items included in Step 1 and Step 2 are required; items included in Step 3 are optional.
Step 1 Identify the voice port and enter the voice-port configuration mode by using the voice-port command.
Step 2 Configure the following mandatory voice-port parameters by using the indicated commands:
Step 3 Configure one or more of the following optional voice-port parameters by using the indicated commands:
To configure FXO and FXS voice ports, use the following commands beginning in privileged EXEC mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| configure terminal | |||
| voice-port slot-number/subunit-number/port | Identify the voice port you want to configure and enter the voice-port configuration mode. | ||
| dial-type {dtmf | pulse} | (For FXO ports only) Select the appropriate dial type for out-dialing. | ||
| signal {loop-start | ground-start} | Select the appropriate signal type for this interface. | ||
| cptone country | Select the appropriate voice call progress tone for this interface. The default for this command is us. For a list of supported countries, refer to the Voice, Video, and Home Applications Command Reference. | ||
| ring frequency {25 | 50} | (For FXS ports only) Select the appropriate ring frequency (in Hertz) specific to the equipment attached to this voice port. | ||
| ring number number | (For FXO ports only) Specify the maximum number of rings to be detected before answering a call. | ||
| connection plar string | (Optional) Specify the private line auto ringdown (PLAR) connection, if this voice port is used for a PLAR connection. The string value specifies the destination telephone number. | ||
| music-threshold number | (Optional) Specify the threshold (in decibels) for on-hold music. Valid entries are from -70 to -30. | ||
| description string | (Optional) Attach descriptive text about this voice port connection. | ||
| comfort-noise | (Optional) Specify that background noise will be generated. |
You can check the validity of your voice-port configuration by performing the following tasks:
Depending on the specifics of your particular network, you might need to adjust voice parameters involving timing, input gain, and output attenuation for FXO or FXS voice ports. Collectively, these commands are referred to as voice-port tuning commands.
To configure voice-port tuning for FXO and FXS voice ports, perform the following steps:
Step 1 Identify the voice port and enter the voice-port configuration mode using the voice-port command.
Step 2 For each of the following parameters, select the appropriate value using the commands indicated:
To fine-tune FXO or FXS voice ports, use the following commands beginning in privileged EXEC mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| configure terminal | |||
| voice-port slot-number/subunit-number/port | Identify the voice-port you want to configure and enter the voice-port configuration mode. | ||
| input gain value | Specify (in decibels) the amount of gain to be inserted at the receiver side of the interface. Acceptable values are from -6 to 14. | ||
| output attenuation value | Specify (in decibels) the amount of attenuation at the transmit side of the interface. Acceptable values are from 0 to 14. | ||
| echo-cancel enable | Enable echo-cancellation of voice that is sent out the interface and received back on the same interface. | ||
| echo-cancel coverage value | Adjust the size (in milliseconds) of the echo-cancel. Acceptable values are 16, 24, and 32. | ||
| non-linear | Enable non-linear processing, which shuts off any signal if no near-end speech is detected. (Non-linear processing is used with echo-cancellation.) | ||
| timeouts initial seconds | Specify the number of seconds the system will wait for the caller to input the first digit of the dialed digits. Valid entries for this command are from 0 to 120. | ||
| timeouts interdigit seconds | Specify the number of seconds the system will wait (after the caller has input the initial digit) for the caller to input a subsequent digit. Valid entries for this command are from 0 to 120. | ||
| timing digit milliseconds | If the voice-port dial type is DTMF, configure the DTMF digit signal duration. The range of the DTMF digit signal duration is from 50 to 100. The default is 100. | ||
| timing inter-digit milliseconds | |||
| timing pulse-digit milliseconds | |||
| timing pulse-inter-digit milliseconds |
Unlike FXO and FXS voice ports, the default E&M voice-port parameters most likely will not be sufficient to enable voice data transmission over your IP network. E&M voice-port values must match those specified by the particular PBX device to which it is connected.
To configure an E&M voice port, perform the following steps. Items included in Step 1 and Step 2 are required; items included in Step 3 are optional.
Step 1 Identify the voice port and enter the voice-port configuration mode using the voice-port command.
Step 2 For each of the following required parameters, select the appropriate parameter value using the commands indicated:
Step 3 Select one or more of the following optional parameters, using the indicated commands:
To configure E&M voice ports, use the following commands beginning in privileged EXEC mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| configure terminal | |||
| voice-port slot-number/subunit-number/port | Identify the voice port you want to configure and enter the voice-port configuration mode. | ||
| dial-type {dtmf | pulse} | Select the appropriate dial type for out-dialing. | ||
| signal {wink-start | immediate | delay-dial} | Select the appropriate signal type for this interface. | ||
| cptone {australia | brazil | china | finland | france | germany | japan | northamerica | unitedkingdom} | Select the appropriate voice call progress tone for this interface. | ||
| operation {2-wire | 4-wire} | Select the appropriate cabling scheme for this voice port. | ||
| type {1 | 2 | 3 | 5} | Select the appropriate E&M interface type. Type 1 indicates the following lead configuration:
Type 2 indicates the following lead configuration:
Type 3 indicates the following lead configuration:
Type 5 indicates the following lead configuration:
| ||
| impedance {600c | 600r | 900c | complex1 | complex2} | Specify a terminating impedance. This value must match the specifications from the telephony system to which this voice port is connected. | ||
| connection plar string | (Optional) Specify the private line auto ringdown (PLAR) connection, if this voice port is used for a PLAR connection. The string value specifies the destination telephone number. | ||
| music-threshold number | (Optional) Specify the threshold (in decibels) for on-hold music. Valid entries are from -70 to -30. | ||
| description string | (Optional) Attach descriptive text about this voice port connection. | ||
| comfort-noise | (Optional) Specify that background noise will be generated. |
You can check the validity of your voice-port configuration by performing the following tasks:
Depending on the specifics of your particular network, you may need to adjust voice parameters involving timing, input gain, and output attenuation for E&M voice ports. Collectively, these commands are referred to as voice-port tuning commands.
To configure voice-port tuning for E&M voice ports, perform the following steps:
Step 1 Identify the voice port and enter the voice-port configuration mode by using the voice-port command.
Step 2 For each of the following parameters, select the appropriate value, using the commands indicated:
To fine-tune E&M voice ports, use the following commands beginning in privileged EXEC mode:
| Step | Command | Purpose |
|---|---|---|
| 1 | configure terminal | |
| 2 | voice-port slot-number/subunit-number/port | Identify the voice port you want to configure and enter the voice-port configuration mode. |
| 3 | input gain value | Specify (in decibels) the amount of gain to be inserted at the receiver side of the interface. Acceptable values are from -6 to 14. |
| 4 | output attenuation value | Specify (in decibels) the amount of attenuation at the transmit side of the interface. Acceptable values are from 0 to 14. |
| 5 | echo-cancel enable | Enable echo-cancellation of voice that is sent out the interface and received back on the same interface. |
| 6 | echo-cancel coverage value | Adjust the size (in milliseconds) of the echo-cancel. Acceptable values are 16, 24, and 32. |
| 7 | non-linear | Enable non-linear processing, which shuts off any signal if no near-end speech is detected. (Non-linear processing is used with echo-cancellation.) |
| 8 | timeouts initial seconds | Specify the number of seconds the system will wait for the caller to input the first digit of the dialed digits. Valid entries for this command are from 0 to 120. |
| 9 | timeouts interdigit seconds | Specify the number of seconds the system will wait (after the caller has input the initial digit) for the caller to input a subsequent digit. Valid entries for this command are from 0 to 120. |
| 10 | timing clear-wait milliseconds | Specify timing parameters. Valid entries for clear-wait are from 200 to 2000 milliseconds. Valid entries for delay-duration are from 100 to 5000 milliseconds. Valid entries for delay-start are from 20 to 2000 milliseconds. Valid entries for dial-pulse min-delay are from 0 to 5000 milliseconds. Valid entries for digit are from 50 to 100 milliseconds. Valid entries for inter-digit are from 50 to 500 milliseconds. Valid entries for pulse are from 10 to 20. Valid entries for pulse-inter-digit are 100 to 1000 milliseconds. Valid entries for wink-duration are from 100 to 400 milliseconds. Valid entries for wink-wait are from 100 to 5000 milliseconds. |
To give real-time voice traffic precedence over other IP network traffic, use the following commands, beginning in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| dial-peer voice number voip | Enter the dial-peer configuration mode to configure a VoIP peer. | ||
| ip precedence number | Select a precedence level for the voice traffic associated with that dial peer. |
In IP Precedence, the numbers 1 through 5 identify classes for IP flows; the numbers 6 through 7 are used for network and backbone routing and updates.
For example, to ensure that voice traffic associated with VoIP dial peer 103 is given a higher priority than other IP network traffic, enter the following:
dial-peer voice 103 voip ip precedence 5
In this example, when an IP call leg is associated with VoIP dial peer 103, all packets transmitted to the IP network via this dial peer will have their precedence bits set to 5. If the networks receiving these packets have been configured to recognize precedence bits, the packets will be given priority over packets with a lower configured precedence value.
If you have configured your WAN or LAN interfaces for RSVP, you must configure the QoS for any associated VoIP peers. To configure quality of service for a selected VoIP peer, use the following commands, beginning in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| dial-peer voice number voip | Enter the dial-peer configuration mode to configure a VoIP peer. | ||
| req-qos [best-effort | controlled-load | guaranteed-delay] | Specify the desired quality of service to be used. |
For example, to specify guaranteed delay QoS for VoIP dial peer 108, enter the following:
Dial-peer voice 108 voip destination-pattern +1408528 req-qos controlled-load session target ipv4:10.0.0.8
In this example, every time a connection is made through VoIP dial peer 108, an RSVP reservation request is made between the local router, all intermediate routers in the path, and the final destination router.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| dial-peer voice number voip | Enter the dial-peer configuration mode to configure a VoIP peer. | ||
| acc-qos [best-effort | controlled-load | guaranteed-delay] | Specify the QoS value below which an SNMP trap will be generated. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| dial-peer voice number voip | Enter the dial-peer configuration mode to configure a VoIP peer. | ||
| codec [g711alaw | g711ulaw | g729r8] | Specify the desired voice coder rate of speech. |
The default for the codec command is g729r8; normally the default configuration for this command is the most desirable. If, however, you are operating on a high bandwidth network and voice quality is of the highest importance, you should configure the codec command for g711alaw or ulaw. Using this value will result in better voice quality, but it will also require higher bandwidth requirements for voice.
For example, to specify a CODEC rate of G.711a-law for VoIP dial peer 108, enter the following:
Dial-peer voice 108 voip destination-pattern +1408528 codec g711alaw session target ipv4:10.0.0.8
| Step | Command | Purpose | ||
|---|---|---|---|---|
| dial-peer voice number voip | Enter the dial-peer configuration mode to configure a VoIP peer. | ||
| vad | Disable the transmission of silence packets (enabling VAD). |
The default for the vad command is enabled; normally the default configuration for this command is the most desirable. If you are operating on a high bandwidth network and voice quality is of the highest importance, you should disable vad. Using this value will result in better voice quality, but it will also require higher bandwidth requirements for voice.
For example, to enable VAD for VoIP dial peer 108, enter the following:
Dial-peer voice 108 voip destination-pattern +1408528 vad session target ipv4:10.0.0.8
To configure Voice over IP to support NetMeeting, create a VoIP peer that contains the following information:
To configure NetMeeting to work with Voice over IP, complete the following steps:
Step 1 From the Tools menu in the NetMeeting application, select Options. NetMeeting will display the Options dialog box.
Step 2 Click the Audio tab.
Step 3 Click the "Calling a telephone using NetMeeting" check box.
Step 4 Enter the IP address of the Cisco 3600 series router in the IP address field.
Step 5 Under General, click Advanced.
Step 6 Click the "Manually configured compression settings" check box.
Step 7 Select the CODEC value CCITT ulaw 8000Hz.
Step 8 Click the Up button until this CODEC value is at the top of the list.
Step 9 Click OK to exit.
To initiate a call using Microsoft NetMeeting, perform the following steps:
Step 1 Click the Call icon from the NetMeeting application. Microsoft NetMeeting will open the call dialog box.
Step 2 From the Call dialog box, select call using H.323 gateway.
Step 3 Enter the telephone number in the Address field.
Step 4 Click Call to initiate a call to the Cisco 3600 series router from Microsoft NetMeeting.
|
|