Dial Peer Features and Configuration

Your dial peer configuration cannot function until you have logically assigned a voice port to one or more dial peers. Assigning voice ports to dial peers identifies the physical hardware in the router that will be employed to complete voice communication to and from associated voice network endpoints.

• Assigning Voice Ports
  

The session target is the network address of the remote router to which you want to send a call once a local voice-network dial peer is matched. It is configured in voice-network dial peers by using the session target command. For outbound dial peers, the destination pattern is the telephone number of the remote voice device that you want to reach. The session target represents the path to the remote router that is connected to that voice device. The figure below illustrates the relationship between the destination pattern and the session target, as shown from the perspective of the originating router.

Figure 1

Relationship Between Destination Pattern and Session Target

The address format of the session target depends on the type of voice-network dial peer:

• VoIP--IP address, host name of the Domain Name System (DNS) server that resolves the IP address, ras for registration, admission, and status (RAS) if an H.323 gatekeeper resolves the IP address, or settlement if the settlement server resolves the IP address
• VoFR--Interface type and number and the data link connection identifier (DLCI)
• VoATM--Interface number, and ATM virtual circuit
• MMoIP--E-mail address

Note	For inbound dial peers, the session target is ignored.

• Configuring Session Targets
  

The destination pattern associates a dialed string with a specific telephony device. It is configured in a dial peer by using the destination-pattern command. If the dialed string matches the destination pattern, the call is routed according to the voice port in POTS dial peers, or the session target in voice-network dial peers. For outbound voice-network dial peers, the destination pattern may also determine the dialed digits that the router collects and then forwards to the remote telephony interface, such as a PBX, a telephone, or the public switched telephone network (PSTN). You must configure a destination pattern for each POTS and voice-network dial peer that you define on the router.

• Configuring Destination Patterns
  
• Digit Manipulation
  

1.    enable

2.    configure terminal

3.    dial-peer data tag pots

4.    incoming called-number string

1.    enable

2.    configure terminal

3.    dial-peer search type {data voice | voice data | none}

To match inbound call legs to dial peers, the router uses three information elements in the call setup message and four configurable dial peer attributes. The three call setup elements are:

• Called number or dialed number identification service (DNIS)--A set of numbers representing the destination, which is derived from the ISDN setup message or channel associated signaling (CAS) DNIS.
• Calling number or automatic number identification (ANI)--A set of numbers representing the origin, which is derived from the ISDN setup message or CAS ANI.
• Voice port--The voice port carrying the call.

The five configurable dial peer attributes are:

• Incoming called number--A string representing the called number or DNIS. It is configured by using the incoming called-numberdial-peer voice configuration command in POTS or multimedia mail over IP (MMoIP) dial peers.
• Answer address--A string representing the calling number or ANI. It is configured by using the answer-address dial-peer voice configuration command in POTS or VoIP dial peers and is used only for inbound calls from the IP network.
• Destination pattern--A string representing the calling number or ANI. It is configured by using the destination-pattern dial-peer voice configuration command in POTS or voice-network dial peers.
• Application--A string representing the predefined application that you wish to enable on the dial peer. It is configured by using the applicationdial-peer voice configuration command on inbound POTS dial peers.
• Port--The voice port through which calls to this dial peer are placed.

The router selects an inbound dial peer by matching the information elements in the setup message with the dial peer attributes. The router attempts to match these items in the following order:

1. Called number with the incoming called-number command
2. Calling number with the answer-address command
3. Calling number with the destination-pattern command
4. Incoming voice port with the configured voice port

The router must match only one of these conditions. It is not necessary for all the attributes to be configured in the dial peer or that every attribute match the call setup information; only one condition must be met for the router to select a dial peer. The router stops searching as soon as one dial peer is matched and the call is routed according to the configured dial peer attributes. Even if there are other dial peers that would match, only the first match is used.

Note

For a dial peer to be matched, its administrative state must be up. The dial peer administrative state is up by default when it is configured with at least one of these commands: incoming called-number, answer-address, or destination-pattern. If the destination-patterncommand is used, the voice port or session target must also be configured.

• Variable-Length Matching
  
• Configuring the incoming called-number Command
  
• answer-address Command
  
• Configuring the destination-pattern Command
  
• Configuring the port Command
  

The method a router uses to select an outbound dial peer depends on whether ISDN DID is configured in the inbound POTS dial peer. If DID is not configured in the inbound POTS dial peer, the router collects the incoming dialed string digit by digit. As soon as one dial peer is matched, the router immediately places the call using the configured attributes in the matching dial peer.

If DID is configured in the inbound POTS dial peer, the router uses the full incoming dial string to match the destination pattern in the outbound dial peer. With DID, the setup message contains all the digits necessary to route the call; no additional digit collection is required. If more than one dial peer matches the dial string, all of the matching dial peers are used to form a rotary group. The router attempts to place the outbound call leg using all of the dial peers in the rotary group until one is successful.

• Using Default Routes
  

With two-stage dialing, when a voice call enters the network, the originating router collects dialed digits until it can match an outbound dial peer. As soon as the router matches a dial peer, it immediately places the call and forwards the associated dial string. No additional dialed digits are collected. The digits and wildcards that are defined in the destination pattern determine how many digits the originating router collects before matching the dial peer. Any digits dialed after the first dial peer is matched are dropped.

For example, if the dialed string is "1234599" and the originating router matches a dial peer with a destination pattern of 123.., then the digits "99" are not collected. The call is placed immediately after the digit "5" is dialed, and the dial string "12345" is forwarded to the next call leg.

On the terminating router, the left-justified digits that explicitly match the terminating POTS dial peer are stripped off. Any trailing wildcard digits are considered excess digits. The terminating router forwards these excess digits to the telephony interface. For example, if the dial string "1234599" is matched on a terminating router to a destination pattern of "123..," the digits "4599" are excess digits and are forwarded to the telephony interface.

The figure below illustrates how the originating router collects a dial string and the terminating router forwards the digits to the telephony device.

Figure 7

Collecting and Forwarding Dialed Digits

The examples in the table below demonstrate how the originating router collects dialed digits for a given destination pattern in the outbound voice-network dial peer.

• Direct Inward Dialing
  

The router supports the concept of hunt groups, sometimes called rotary groups , in which multiple dial peers are configured with the same destination pattern. Because the destination of each POTS dial peer is a single voice port to a telephony interface, hunt groups help ensure that calls get through even when a specific voice port is busy. If the router is configured to hunt, it can forward a call to another voice port when one voice port is busy.

For example, in the following configuration for Router A, four POTS dial peers are configured with different destination patterns. Because each dial peer has a different destination pattern, no backup is available if the voice port mapped to a particular dial peer is busy with another call.

With a hunt group, if a voice port is busy, the router hunts for another voice port until it finds one that is available. In the following example for Router B, each dial peer is configured using the same destination pattern of 3000, forming a dial pool to that destination pattern.

dial-peer voice 1 pots
 destination-pattern 3001
 port 1/1
!
dial-peer voice 2 pots
 destination-pattern 3002
 port 1/2
!
dial-peer voice 3 pots
 destination-pattern 3003
 port 1/3
!
dial-peer voice 4 pots
 destination-pattern 3004
 port 1/4

dial-peer voice 1 pots
 destination pattern 3000
 port 1/1
 preference 0
!
dial-peer voice 2 pots
 destination pattern 3000
 port 1/2
 preference 1
!
dial-peer voice 3 pots
 destination pattern 3000
 port 1/3
 preference 2
!
dial-peer voice 4 pots
 destination pattern 3000
 port 1/4
 preference 3

To give specific dial peers in the pool a preference over other dial peers, you can configure the preference order for each dial peer by using the preference command. The router attempts to place a call to the dial peer with the highest preference. The configuration example given for Router B shows that all dial peers have the same destination pattern, but different preference orders.

The lower the preference number, the higher the priority. The highest priority is given to the dial peer with preference order 0. If the same preference is defined in multiple dial peers with the same destination pattern, a dial peer is selected randomly.

By default, dial peers in a hunt group are selected according to the following criteria, in the order listed:

1. Longest match in phone number--Destination pattern that matches the greatest number of dialed digits. For example, if one dial peer is configured with a dial string of 345.... and a second dial peer is configured with 3456789, the router would first select 3456789 because it has the longest explicit match of the two dial peers.
2. Explicit preference--Priority configured by using the preferencedial peer command.
3. Random selection--All destination patterns weighted equally.

You can change this default selection order or choose different methods for hunting dial peers by using the dial-peer hunt global configuration command. An additional selection criterion is "least recent use," which selects the destination pattern that has waited the longest since being selected.

You can mix POTS and voice-network dial peers when creating hunt groups. Mixing dial peer types can be useful if you want incoming calls to be sent over the packet network, except that if network connectivity fails, you want to reroute the calls back through the PBX to the PSTN. This type of configuration is sometimes referred to as hairpinning . Hairpinning is illustrated in the figure below.

Figure 9

Voice Call Using Hairpinning

The following configuration shows an example of sending calls to the PSTN if the IP network fails:

dial-peer voice 101 voip
 destination-pattern 472....
 session target ipv4:192.168.100.1
 preference 0
!
dial-peer voice 102 pots
 destination-pattern 472....
 prefix 472
 port 1/0:1
 preference 1

You cannot use the same preference numbers for POTS and voice-network dial peers within a hunt group. You can set a separate preference order for each dial peer type, but the preference order does not work on both at the same time. For example, you can configure preference order 0, 1, and 2 for POTS dial peers, and you can configure preference order 0, 1, and 2 for the voice-network dial peers, but the two preference orders are separate. The system resolves preference orders among POTS dial peers first.

• Configuring Dial Peer Hunting Options
  
• Configuring Dial Peer Hunting Options
  

Like T.38 Fax Relay and Modem Relay, Modem Pass Through functionality can be enabled and configured on a per-dial peer basis. Modem Pass Through behavior enables you to take advantage of features such as the following:

• Repressing bandwidth- and resource-consuming functions like compression, echo cancellation, high-pass filtering, and voice activity detection (VAD).
• Automatically sending redundant packets to minimize the possibility of packet loss.
• Employing automatic static jitter buffers to protect against clock skew.
• Identifying signals that are for modem calls versus voice or fax calls.

The figure below illustrates a network featuring Modem Pass Through capability.

Figure 10

Modem Pass Through Connection Example

When a call over the network is identified as a modem call, both the originating and terminating voice gateway routers automatically "roll over" to using the G.711 codec for the duration of the modem call. Once the modem call has ceased, the digital signal processors (DSPs) in both the originating and terminating voice gateways revert to default operation, enabling fax and voice calls to be placed and received using those DSPs. The version of the G.711 codec you use (either a-law or u-law) is determined by the type of network on which your voice gateways are operating and the configuration you specify using the modem passthrough command in dial-peer voice configuration mode.

• Configuring Modem Pass Through Capability for Individual Dial Peers
  

Dual tone multifrequency (DTMF) tones are generated when a button on a touch-tone phone is pressed. When the tone is generated, it is compressed, transported to the other party, and then decompressed. If a low-bandwidth codec, such as G.729 or G.723, is used without a DTMF relay method, the tone may be distorted during compression and decompression.

DTMF relay sends DTMF tones out of band, or separately from the voice stream. Cisco gateways currently support the following methods of DTMF relay:

• Using a Cisco-proprietary Real-Time Transport Protocol (RTP). DTMF tones are sent in the same RTP channel as voice data. However, the DTMF tones are encoded differently from the voice samples and are identified by a different RTP payload type code. Use of this method accurately transports DTMF tones, but because it is proprietary, it requires the use of Cisco gateways at both the originating and terminating endpoints of the H.323 call.
• Using either the H.245 signal or H.245 alphanumeric method. These methods separate DTMF digits from the voice stream and send them through the H.245 signaling channel instead of through the RTP channel. The tones are transported in H.245 User Input Indication messages. The H.245 signaling channel is a reliable channel, so the packets that transport the DTMF tones are guaranteed to be delivered. However, because of the overhead of using a reliable protocol, and depending on network congestion conditions, the DTMF tones may be slightly delayed. All H.323 version 2-compliant systems are required to support the "h245-alphanumeric" method: support of the "h245-signal" method is optional.
• Using Named Telephone Events (NTEs). Using NTE to relay DTMF tones provides a standardized means of transporting DTMF tones in RTP packets according to section 3 of RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals , developed by the IETF Audio/Video Transport (AVT) working group. RFC 2833 defines formats of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints. With the NTE method, the endpoints perform per-call negotiation of the DTMF relay method. They also negotiate to determine the payload type value for the NTE RTP packets.

Cisco H.323 gateways advertise capabilities using the H.245 capabilities messages. By default, they advertise that they can receive all DTMF relay modes. If the capabilities of the remote gateway do not match, the Cisco H.323 gateway sends DTMF tones as in-band voice. Configuring DTMF relay on the Cisco H.323 gateway sets preferences for how the gateway handles DTMF transmission. If multiple methods are configured, the priority is as follows:

• Cisco RTP
• RTP NTE
• H.245 signal
• H.245 alphanumeric

In addition to support for NTE, DTMF Relay provides support for asymmetrical payload types. Payload types can differ between local and remote endpoints. Therefore, the Cisco gateway can transmit one payload type value and receive a different payload type value.

• Configuring DTMF Relay and Payload Type
  

You can configure dial peers on your Cisco voice gateway router to take advantage of one-way and two-way private-line automatic ringdown (PLAR) functionality. By using the connection plar command you can enhance your voice network to offer a number of useful features including the following:

• Providing an off-premises extension (OPX) from a PBX, thus simulating direct connections between FXS port users on a voice gateway router and the PBX.
• Providing dial-tone from a remote PBX in order to offer toll-bypass functionality. Instead of relying on the gateway routers in your voice network to provide dial-tone, you can employ PLAR behavior to enable remote sites to behave as though they have a direct connection to a PBX.
• Connection PLAR behavior eliminates the need for user dialing, because both of the endpoints for the VoIP call are statically configured.

In addition to the features described, connection PLAR behavior does not dedicate bandwidth to a call unless one or the other of the privately associated endpoints goes off-hook.

Note	The Connection PLAR and Connection Trunk feature behavior is configured on a per-voice-port basis. Therefore, you cannot employ the same voice port for both Connection PLAR or trunk mode and collect-dialed-digits mode.

• Configuring Connection PLAR
  
• Connection PLAR Design Considerations
  

In addition to configuring Connection PLAR, you can configure your dial peers to employ the Connection Trunk feature using the connection trunk command. Connection Trunk functionality offers some of the same advantages as Connection PLAR, such as eliminating the need for user dialing because both of the endpoints for the VoIP call are statically configured. In addition, Connection Trunk behavior offers you the ability to pass supplemental call signaling capability like hookflash and point-to-point Hoot-n-Holler between endpoints on the trunk.

However, unlike Connection PLAR, Connection Trunk endpoints are always active (or off-hook) as far as the voice network is concerned, so bandwidth is always being allocated to a trunk that you have configured.

Note	The Connection PLAR and Connection Trunk feature behavior is configured on a per-voice-port basis. Therefore, you cannot employ the same voice port for both Connection PLAR or trunk mode and collect-dialed-digits mode.

• Configuring Connection Trunk
  

The Class of Restrictions (COR) feature provides the ability to deny certain call attempts based on the incoming and outgoing class of restrictions provisioned on the dial peers. This functionality provides flexibility in network design, allows users to block calls (for example, to 900 numbers), and applies different restrictions to call attempts from different originators.

COR is used to specify which incoming dial peer can use which outgoing dial peer to make a call. Each dial peer can be provisioned with an incoming and an outgoing COR list. The incoming COR list indicates the capability of the dial peer to initiate certain classes of calls. The outgoing COR list indicates the capability required for an incoming dial peer to deliver a call via this outgoing dial peer. If the capabilities of the incoming dial peer are not the same or a superset of the capabilities required by the outgoing dial peer, the call cannot be completed using this outgoing dial peer.

A typical application of COR is to define a COR name for the number that an outgoing dial peer serves, then define a list that contains only that COR name, and assign that list as corlist outgoing for this outgoing dial peer. For example, dial peer with destination pattern 5T can have a corlist outgoing that contains COR 5x, as shown in the following configuration.

The next step, in the typical application, is to determine how many call permission groups are needed, and define a COR list for each group. For example, group A is allowed to call 5x and 6x, and group B is allowed to call 5x, 6x, and 1900x. Then, for each incoming dial peer, we can assign a group for it, which defines what number an incoming dial peer can call. Assigning a group means assigning a corlist incoming to this incoming dial peer.

dial-peer cor custom
 name 5x
 name 6x
 name 1900x
!
dial-peer cor list listA
 member 5x
 member 6x
!
dial-peer cor list listB
 member 5x
 member 6x
 member 1900x
!
dial-peer cor list list5x
 member 5x
!
dial-peer cor list list6x
 member 6x
!
dial-peer cor list list1900x
 member 1900x
! outgoing dialpeer 100, 200, 300
dial-peer voice 100 pots
 destination-pattern 5T
 corlist outgoing list5x
dial-peer voice 200 pots
 destination-pattern 6T
 corlist outgoing list6x
dial-peer voice 300 pots
 destination-pattern 1900T
 corlist outgoing list1900x
!
! incoming dialpeer 400, 500 
dial-peer voice 400 pots
 answer-address 525....
 corlist incoming listA
dial-peer voice 500 pots
 answer-address 526
 corlist incoming listB

Note	To configure classes of restrictions for dial peers, use the following commands beginning in global configuration mode:

1.    Router(config)# dial-peer cor custom

2.    Router(config-dp-cor)# name class-name

3.    Router(config-dp-cor)# exit

4.    Router(config)# dial-peer cor list list-name

5.    Router(config-dp-corlist)# member class-name

6.    Router(config-dp-corlist)# exit

7.    Router(config)# dial-peer voice number {pots | voip}

8.    Router(config-dial-peer)# corlist incoming cor-list-name

9.    Router(config-dial-peer)# corlist outgoing cor-list-name

• Verifying Classes of Restrictions
  

This section includes the following tasks:

• Configuring an iLBC Codec on a Dial Peer
  
• Configuring an iLBC Codec in the Voice Class