Table Of Contents
VoIP Gateway Trunk and Carrier Based Routing Enhancements
Call Capacity Reporting Updates
Translation Rules and Translation Profiles
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring a Translation Rule
Verifying the Translation Rule Configuration
Troubleshooting Tips for a Translation Rule Configuration
Configuring a Translation Profile
Configuring an ENUM Match Table
Verifying the ENUM Match Table
Verifying the Trunk Group Configuration
Troubleshooting Tips for the Trunk Group Configuration
Configuring a Source VoIP Group
Verifying the Source VoIP Group Configuration
Troubleshooting Tips for the Source IP Group Configuration
Verifying the Voice Port Configuration
Assigning Translation Profiles to Inbound Dial Peers
Configuring Call Blocking on Inbound Dial Peers
Configuring an Outbound POTS Dial Peer
Verifying the Dial Peer Configuration
Configuring an Outbound VoIP Dial Peer
Assigning a Translation Profile to an NFAS Interface
Verifying the NFAS Interface Configuration
Troubleshooting Tips for the NFAS Interface Configuration
Verifying the DS-0 Group Configuration
Troubleshooting Tips for the DS-0 Group Configuration
Configuring a Global Translation Profile for Incoming VoIP Calls
Configuring Call Capacity Reporting for Unsolicited Calls
Monitoring and Maintaining Gateway Trunk and Carrier Based Routing
Troubleshooting VoIP Gateway Trunk and Carrier Based Routing
Why are my trunk or carrier based calls not going through?
Troubleshooting Trunk Group Configurations
Troubleshooting Dial Peer Configurations
Troubleshooting Source IP Group Configurations
Why are incoming calls not blocked as expected?
Why are the number translations not working properly?
Configuring Trunk and Carrier Based Routing on an Originating Gateway: Example
Configuring Trunk and Carrier Based Routing on a Terminating Gateway: Example
VoIP Gateway Trunk and Carrier Based Routing Enhancements
Feature History
This feature module describes the VoIP Gateway Trunk and Carrier Based Routing Enhancements feature functionality in Cisco IOS Release 12.2(11)T, and includes the following sections:
•
Supported Standards, MIBs, and RFCs
•
•
For information on routing enhancements for gatekeepers, see VoIP Gatekeeper Trunk and Carrier Based Routing Enhancements.
Feature Overview
Voice wholesalers use multiple ingress and egress carriers to route traffic. A call coming in to a gateway on a particular ingress carrier must be routed to an appropriate egress carrier. As networks grow and become more complicated, the dial plans needed to route the carrier traffic efficiently become more complex and the need for carrier sensitive routing (CSR) increases.
The Gateway Trunk and Carrier Based Routing Enhancements feature implements CSR for Cisco voice gateways. The gateway feature described in this document adds the following routing features:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The following call handling sequence gives some orientation to these new capabilities.
In a typical scenario, a call from the PSTN arrives at a gateway (the ingress gateway), leaves the gateway as a VoIP call, arrives at a destination gateway (the egress gateway), and leaves that gateway as a PSTN call. For this example, trunk groups and translation rules have been defined using commands described later in this document. Figure 1 illustrates what happens to the call in the ingress gateway. Figure 2 illustrates the call handing activities in the egress gateway. Steps affected by the trunk groups and translation rules implemented in this feature are marked as "new".
Figure 1
Call Processing on the Ingress (Originating) Gateway
Figure 2
Call Processing in the Egress (Terminating) Gateway
The components of the scenarios described in Figures 1 and 2 are detailed in the following sections:
•
Trunk Groups
This software feature provides these characteristics for a trunk group:
•
•
•
•
•
•
In addition to supporting existing trunk group functionality for PRI and BRI interfaces, this trunk and carrier routing enhancements feature adds trunk group support for these interfaces:
•
•
•
This feature adds trunk group support for Non-Facility Associated Signaling (NFAS) interfaces. The interfaces should be added as members of a trunk group to control incoming and outgoing call routing. All the interfaces of an NFAS group must belong to the same trunk group. Multiple NFAS groups can belong to the same trunk group with other PRI and BRI interfaces.
Table 1 lists the different voice platforms and their supported trunk group interfaces.
Table 1 Trunk Group Support on Cisco Platforms
Cisco 1750
ISDN (PRI, BRI)
—
—
—
Cisco 26xx
ISDN(PRI, BRI)
ISDN NFAS-group
CAS
Yes
FXS, FXO, E&M, DID
Cisco 36xx
ISDN(PRI, BRI)
ISDN NFAS-group
CAS
Yes
FXS, FXO, E&M, DID
Cisco AS5300
—
ISDN (PRI)1
ISDN NFAS-group
CAS
—
—
Cisco AS5350
—
ISDN (PRI)1
ISDN NFAS-group
CAS
—
—
Cisco AS5400
—
ISDN (PRI)1
ISDN NFAS-group
CAS
—
—
Cisco AS5800
ISDN(PRI)1
ISDN NFAS-group
CAS
—
—
Cisco AS5850
—
ISDN (PRI)1
ISDN NFAS-group
CAS
—
—
Cisco MC3810
ISDN (PRI, BRI)
—
—
—
1 BRI is not supported on the Cisco AS5300, Cisco AS5350, Cisco AS5400, Cisco AS5800, and Cisco AS5850 platforms.
The trunk group functionality in this feature does not support the existing trunk group functionality on the Cisco 1750 and Cisco MC3810 platforms.
Hunt Schemes
A hunt scheme is a selection procedure for choosing an interface or voice port. A trunk group with several trunk group members uses a hunt scheme to select an idle channel for routing an outgoing call. Several hunt schemes are supported, as illustrated with the following example.
Suppose a trunk group has three trunk group members: A has the smallest preference value, B has the next highest preference value, and C has the highest preference value. Each hunt scheme impacts the trunk group members as described in the following sections.
Least-Used
The software selects the trunk group member that has the highest number of available channels. This high number indicates that the trunk group member is not used as often as other members. If two or more trunk group members have the same number of idle channels, the one with the highest preference (lowest preference value) is searched first. Once the member is selected, the software searches for an idle channel. Optional parameters can modify the search to look in either ascending or descending order for an even-numbered channel, an odd-numbered channel, or either type.
Suppose hunt-scheme least-used even down is enabled. The search goes through the trunk group members in descending order (C, B, A) to determine which member has the highest number of even-numbered idle channels. After selecting that trunk group member, the search looks for an even-numbered idle channel. If successful, the search selects an even-numbered idle channel to use for routing the call. If unsuccessful, the search goes through the trunk group members in the same descending order to select an odd-numbered idle channel. If successful, the search selects an odd-numbered idle channel for routing the call.
Least-Idle
The software searches across all the channels in A, B, and C for the channel that has most recently become available. The precedence of A, B, and C is not important because more than two or more channels cannot be least-idle at the same time. Optional parameters can modify the search to look for an even-numbered channel, an odd-numbered channel, or either type.
Suppose hunt-scheme least-idle even is enabled. The software searches for an even-numbered channel that has just entered the available queue. An even-numbered channel in C has just become available. That channel is used for the call routing.
If no even-numbered channel is available, the software searches for the odd-numbered channel with the longest idle time instead.
Longest-Idle
The software searches across all the channels in A, B, and C for the channel that has been in the available queue the longest. The precedence of A, B, and C is not important because two or more channels cannot be longest-idle at the same time. Optional parameters can modify the search to look for an even-numbered channel, an odd-numbered channel, or either type.
Suppose hunt-scheme longest-idle odd is enabled. The software searches for the odd-numbered channel that has been in the idle queue the longest. An odd-numbered channel in B has been available for the longest time. That channel is used for the call routing.
If no odd-numbered channel is available, the software searches for the even-numbered channel with the least (shortest) idle time instead.
Random
The trunk group members are searched in random order for an idle channel.
This method does not account for one member being busier than another and does not intentionally balance the call load across all members. (In the long term, load balancing is achieved across all members.) The search can not be modified for even- or odd-numbered channels or for ascending or descending order.
Round-Robin
The trunk group members are searched in turn for an idle channel. The history of the previously selected member is saved to identify the next trunk group member to use for a new idle channel request. This method tries to balance the load of channel use across the trunk group members.
Optional parameters can modify the search to look for an even-numbered channel, an odd-numbered channel, or either type. The trunk group members are searched in order of preference.
Suppose hunt-scheme round-robin even is enabled. Trunk group member A is searched first because it has the highest preference. The search looks for an even-numbered idle channel in A. If one is available, that channel is used for the call routing. A new idle channel request would start with member B, which has the next highest precedence value.
If A does not have an available even-numbered channel, the search tries to find an even-numbered channel in the next highest trunk group member, which is B. If successful, that channel is used for the call routing. A new idle channel request would start with C.
If B does not have any available even-numbered channels, the search tries to find an even-numbered channel in the next highest trunk group member, which is C. If successful, that channel is used for the call routing. A new idle channel request would start with A.
If C has no available even-numbered channels, the search repeats the process to find an odd-numbered channel. In this instance, the search would start again with A.
Sequential
This hunt scheme is similar to round-robin, except that a new idle channel request always starts its search with the highest precedence trunk group member, regardless of the member used for the previous request. In our example, A would always be the first trunk group member searched, even if B was successful the last time.
Optional parameters can modify the search to look in either ascending or descending order for an even-numbered channel, an odd-numbered channel, or either type.
Suppose hunt-scheme sequential odd down is enabled. Trunk group member A is searched first because it has the highest precedence value. The search checks A's channels in descending order for an odd-numbered available channel. If successful, the channel is used for the call routing. The next idle channel request starts its search with A.
If A does not have an available even-numbered channel, the search tries to find an even-numbered channel in the next highest trunk group member, which is B. If successful, that channel is used for the call routing. A new idle channel request would start with A.
If B does not have any available even-numbered channels, the search tries to find an even-numbered channel in the next highest trunk group member, which is C. If successful, that channel is used for the call routing. A new idle channel request would start with A.
If C has no available even-numbered channels, the search repeats the process to find an odd-numbered channel. In this instance, the search would start again with A.
Call Capacity Reporting Updates
The gateway automatically sends call capacity information for H.323 calls to the gatekeeper using the H.323 Version 4 protocol. The gateway receiving the H.323 call sends the report as soon as the call arrives.
SIP and TDM calls (non-H.323 calls) arriving at a gateway do not generate an automatic update to the gatekeeper's capacity database. The gateway must be configured to send call capacity updates for these calls at user-defined regular intervals to the gatekeeper.
When periodic call capacity reporting is enabled, the carrier resource manager (CRM) subsystem on the gateway scans the list of carrier IDs or trunk group labels at the user-specified time interval. If the capacity information has changed but has not been reported, the CRM sends a message to the H.323 subsystem on the gatekeeper with the updated information.
If periodic call capacity reporting is enabled, the gateway and gatekeeper call capacity information eventually converges (if no calls connect or disconnect). The following examples illustrate this process.
Sample Call Capacity Updates
Suppose a gatekeeper GK-A has two registered gateways, GW1 and GW2. The two gateways use VoIP to communicate with each other. GW1 uses carrier 1 with a capacity of 23 channels. GW2 uses carrier2 with a capacity of 24 channels. Both gateways have periodic call capacity reporting enabled with a timer interval of 30 seconds.
If no calls are active, the gatekeeper and gateways have the following information:
GK-A# show gatekeeper circuitsCircuit Endpoint Max Calls Avail Calls Resources Zone------- -------- --------- ----------- --------- ----carrier2 Total Endpoints: 1GW2 24 24 Availablecarrier1 Total Endpoints: 1GW1 23 23 AvailableGW1# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier1Max calls:24Max Voice (in) : 23 Cur Voice (in) : 0Max Voice (out): 23 Cur Voice (out): 0Max Data (in) : 23 Cur Data (in) : 0Max Data (out) : 23 Cur Data (out) : 0GW2# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier2Max calls:23Max Voice (in) : 24 Cur Voice (in) : 0Max Voice (out): 24 Cur Voice (out): 0Max Data (in) : 24 Cur Data (in) : 0Max Data (out) : 24 Cur Data (out) : 0Now suppose that six calls are made from GW2 to GW1. Each call starts 30 seconds after the previous call was initiated and each call lasts five minutes. The call capacity reporting interval is 30 seconds.
The following output illustrates the gatekeeper and gateway call capacity information 90 seconds after the first call started:
GK-A# show gatekeeper circuitsCircuit Endpoint Max Calls Avail Calls Resources Zone------- -------- --------- ----------- --------- ----carrier2 Total Endpoints: 1GW2 24 21 Availablecarrier1 Total Endpoints: 1GW1 23 19 AvailableGW1# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier1Max calls:23Max Voice (in) : 23 Cur Voice (in) : 4Max Voice (out): 23 Cur Voice (out): 0Max Data (in) : 23 Cur Data (in) : 0Max Data (out) : 23 Cur Data (out) : 0GW2# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier2Max calls:24Max Voice (in) : 24 Cur Voice (in) : 0Max Voice (out): 24 Cur Voice (out): 4Max Data (in) : 24 Cur Data (in) : 0Max Data (out) : 24 Cur Data (out) : 0At 90 seconds, GW2 has sent out 4 calls, GW1 has received 4 calls, but the fourth call is not yet connected on the PSTN side of GW2. When the scan sends the call capacity update to the gatekeeper, GK-A shows only 3 active calls (21 available channels) for GW2. At the next reporting interval, the scan will show 4 active calls (20 available channels) for GW2.
The last call is connected (after 150 seconds) and all the calls are still active. A snapshot of the call capacity information taken at 180 seconds shows all the statistics match up:
GK-A# show gatekeeper circuitsCircuit Endpoint Max Calls Avail Calls Resources Zone------- -------- --------- ----------- --------- ----carrier2 Total Endpoints: 1GW2 24 18 Availablecarrier1 Total Endpoints: 1GW1 23 17 AvailableGW1# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier1Max calls:23Max Voice (in) : 23 Cur Voice (in) : 6Max Voice (out): 23 Cur Voice (out): 0Max Data (in) : 23 Cur Data (in) : 0Max Data (out) : 23 Cur Data (out) : 0GW2# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier2Max calls:24Max Voice (in) : 24 Cur Voice (in) : 0Max Voice (out): 24 Cur Voice (out): 6Max Data (in) : 24 Cur Data (in) : 0Max Data (out) : 24 Cur Data (out) : 0At 330 seconds (5.5 minutes), the first and second call are disconnected. The call capacity information at this point shows:
GK-A# show gatekeeper circuitsCircuit Endpoint Max Calls Avail Calls Resources Zone------- -------- --------- ----------- --------- ----carrier2 Total Endpoints: 1GW2 24 19 Availablecarrier1 Total Endpoints: 1GW1 23 18 AvailableGW1# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier1Max calls:23Max Voice (in) : 23 Cur Voice (in) : 4Max Voice (out): 23 Cur Voice (out): 0Max Data (in) : 23 Cur Data (in) : 0Max Data (out) : 23 Cur Data (out) : 0GW2# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier2Max calls:24Max Voice (in) : 24 Cur Voice (in) : 0Max Voice (out): 24 Cur Voice (out): 4Max Data (in) : 24 Cur Data (in) : 0Max Data (out) : 24 Cur Data (out) : 0In this case, the gatekeeper has not received an update about the second call being disconnected, which is why the gatekeeper still shows 5 active calls (24-19 and 23-18) while the two gateways show 4 active calls. Once the PSTN on the terminating gateway (GW1) releases the channel, the next call capacity scan will show the release of the second channel.
At 450 seconds (7.5 minutes), all the calls are disconnected. A scan taken at this time shows the following output:
GK-A# show gatekeeper circuitsCircuit Endpoint Max Calls Avail Calls Resources Zone------- -------- --------- ----------- --------- ----carrier2 Total Endpoints: 1GW2 24 23 Availablecarrier1 Total Endpoints: 1GW1 23 23 AvailableGW1# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier1Max calls:23Max Voice (in) : 23 Cur Voice (in) : 0Max Voice (out): 23 Cur Voice (out): 0Max Data (in) : 23 Cur Data (in) : 0Max Data (out) : 23 Cur Data (out) : 0GW2# show crmCRM periodic update enabledCRM periodic updates at interval: 30 secondsCarrier:carrier2Max calls:24Max Voice (in) : 24 Cur Voice (in) : 0Max Voice (out): 24 Cur Voice (out): 0Max Data (in) : 24 Cur Data (in) : 0Max Data (out) : 24 Cur Data (out) : 0The gatekeeper shows GW2 with one active channel. GW2 did not receive the channel release indication from CRM in time for the call capacity scan to update the gatekeeper.
The next scan will show that all the call capacity statistics on the gatekeeper and gateways match.
Carrier IDs
A carrier ID is a new attribute consisting of up to 127 alphanumeric characters that identifies the carrier handling an H.323 or SIP call. One or more trunk groups can refer to the same carrier ID.
To support carrier ID routing, the egress (also called terminating) gateway uses the carrier ID routing tag as a matching key to select an outbound dial peer. In addition, the gateway forwards the call capacity information for the carrier IDs to the gatekeeper connected to a gatekeeper transaction management protocol (GKTMP) server application.
Note
Trunk Group Labels
The gateway trunk and carrier routing enhancements support trunk group routing by enabling a gateway routing tag called trunk group label. This new routing tag co-exists with the carrier ID gateway routing tag.
Carriers have the option of routing using either the trunk group label or carrier ID.
Note
Additional considerations:
•
•
•
All other aspects of implementing carrier ID routing and trunk group label routing remain the same.
If a carrier ID is not configured for a trunk group, the call capacity reporting uses the trunk group label capacity. The capacity message includes an indication that the capacity's source is a trunk group label.
Number Translation
The gateway trunk and carrier routing enhancements implement translation profiles with translation rules in SED expression format. Trunk groups refer to these profiles for incoming and outgoing call number translation.
The ingress (or originating) gateway uses the translation profile to translate POTS call numbers coming in on a voice port or a trunk group. A voice port matches a single interface, DS-0 group, or analog port; a trunk group matches multiple interfaces, DS-0 groups, or analog ports. If the voice port does not have a translation profile but is a member of a trunk group that does have one, the gateway uses the trunk group's translation profile to translation the call. But if a voice port has a translation profile and is a member of a trunk group, the voice port translation profile overrides the trunk group profile.
A translation profile can be defined for one or more individual controllers, also called Non-Facility Associated Signaling (NFAS) interfaces, under voice services. In an NFAS group, all the interfaces share the same voice port, which forces all the interfaces to share the same translation profile. This translation profile translates incoming and outgoing calls on a per-controller basis. When an incoming or outgoing call seizes an NFAS B-channel, the translation profile for the controller overrides the translation profile of the voice port.
Previous number translation schemes performed the number translation after matching the incoming call with an inbound dial peer. The new number translation occurs before matching the inbound dial peer. Translating the call numbers before matching may affect the selection of an inbound dial peer.
After the incoming call is matched with an inbound dial peer, the translation of the dial peer occurs.
In the egress (or terminating) gateway, new number translation is performed on an incoming H.323 or SIP call using the incoming translation profile of a source IP group or a global VoIP incoming translation profile. If an incoming VoIP call is matched with a source IP group that has an incoming translation profile, the source IP group's profile overrides the global VoIP translation profile.
At the terminating end, the gateway matches the outbound call with an outbound dial peer, using one or more trunk groups as a target. The gateway translates the number using the outgoing translation profile of the outbound dial peer. If the outbound dial peer definition contains a voice port or trunk group, the gateway translates the number again based on the outgoing translation profile of the voice port, NFAS interface, or trunk group.
If the call is not routed successfully and the gateway needs to search for another outbound dial peer, the gateway uses the call number available before any previous outbound dial-peer translations. The call number is translated again based on the subsequent outbound dial-peer.
Multiple Trunk Group Support
Multiple trunk group support permits up to 64 trunk groups to be provisioned as a target in a POTS dial-peer. Because the dial peer can have more than one target destination, this capability reduces the number of dial peers that need to be configured.
During a call setup request for an outbound call, the software searches for an idle channel in an outbound dial peer with a list of trunk groups. The trunk groups are searched sequentially by priority. If an idle channel is not available from the highest priority trunk group, the next priority trunk group is searched. When a channel is found, the trunk group member containing the channel is used for the outbound call.
If the call setup returns a glare condition and the software attempts a retry for the call, the search for another idle channel starts from the beginning of the list of multiple trunk groups.
The following examples illustrate the method for selecting a trunk group.
Example 1
In Example 1, trunk group 11 is searched first because it has the highest priority.
dial peer voice 102 POTScarrier-id target xyztrunkgroup 11 1trunkgroup 12 2trunkgroup 13 3translation-profile outgoing 1Example 2
In Example 2, trunk group 12 has no specified preference, so its priority is assumed to be 0, which is the highest preference. Therefore, trunk group 12 is searched first because it has the highest priority. If an idle channel is not available in trunk group 12, trunk group 11 is searched next.
dial peer voice 103 POTScarrier-id target xyztrunkgroup 12trunkgroup 11 1trunkgroup 13 2translation-profile outgoing 1Example 3
In Example 3, trunk group 12 and trunk group 11 have no specified preference, so their priority is assumed to be 0. Trunk groups with equal priority are selected in the order as they appear listed in the dial peer. Therefore, trunk group 12 is searched first because it was configured before trunk group 11. If an idle channel is not available in trunk group 12, trunk group 11 is searched next.
dial peer voice 104 POTScarrier-id target xyztrunkgroup 12trunkgroup 11trunkgroup 13 1translation-profile outgoing 1ENUM Support
The supported implementation of ENUM (E.164 telephone number mapping) for gateway trunk and carrier routing uses a set of user-defined rules to translate the called number into a DNS name for finding an outgoing VoIP dial-peer. Each rule requires a matching pattern, replacement rule, E.164 domain name, and preference number. The rules are collected into a table in order of their preference numbers (the lowest integer is the highest preference).
ENUM Call Flow
The process for handling an ENUM call is described below.
1.
2.
3.
4.
5.
6.
7.
If the DNS server cannot find a match for the FQDN, the translation process repeats in the ENUM match table using the matching pattern with the next highest preference (step 3 above).
8.
ENUM Number Conversion
The gateway uses the ENUM match table configured for the outgoing VoIP dial peer to select a rule for converting the DNIS, or called, number into an E.164 number. The ENUM match table has one or more translation rules containing matching and replacement patterns.
The DNIS number is matched against the matching pattern of the rule with the highest preference. If the called number does not match the first rule, the software looks at the rule with the next highest preference. When a match is found, the called number is translated according to the replacement rule. The result is an E.164 number.
The NAPTR algorithm removes all characters except digits from the E.164 number, reverses the digits, and inserts dots between each digit. The domain name, specified in the ENUM rule, is concatenated to the translated number. This concatenated number forms the DNS name, or FQDN, which the DNS server uses to find the URL of the call's destination. (Refer to RFC 2916 for more information on DNS names and searches.) See the "NAPTR Resource Records" section for an explanation of the NAPTR RRs returned by the DNS server.
ENUM Match Table Rules
An ENUM match table contains one or more rules for converting called (DNIS) numbers into E.164 numbers, which are used by the DNS server for locating a destination target. ENUM supports a maximum of 15 search tables, each with its own set of rules.
Note
Rules can be entered into a table in any order. Each rule contains an identification number, a preference number, a matching pattern, a replacement pattern, and a domain name. The matching and replacement patterns are SED-like expressions. The preference numbers determines how the software searches through the table of rules to find a match. The search sequence can be changed easily by changing the preference numbers of the rules.
To illustrate how this works, suppose the set of rules in Table 2 defines a match table:
The software searches through them in order of preference:
/^9\(1.*\)/
/+\1/
E164.cisco.com
1
/^9011\(.*\)/
/+1408\1/
E164.arpa
3
/\(.*\)/
/\1/
E164.arpa
6
/^201\(.*\)/
/+1201\1/
E164.cisco.com
7
Suppose a call comes in with a called number of "90115325755". The processing sequence is:
1.
2.
3.
4.
If this DNS name does not result in a destination URL for the call, the translation process begins again, starting with the third rule (the one with preference number "6").
NAPTR Resource Records
A NAPTR RR is the response from the DNS server after it has located a destination target for the called number. Following are sample RRs.
ord pr fl service regexp replacement2.1.2.1.5.5.5.8.0.4.1.e164.arpa.IN NAPTR 10 10 "U" "h323+E2U" "/^.*$/h323:5551212@10.1.1.1 /".2.1.2.1.5.5.5.8.0.4.1.e164.arpa.IN NAPTR 30 10 "U" "sip+E2U" "/^.*$/sip:5551212@reno.vegas .com/".2.1.2.1.5.5.5.8.0.4.1.e164.arpa.IN NAPTR 40 10 "S" "h323+E2U" . _potscall._udp.cisco.com.2.1.2.1.5.5.5.8.0.4.1.e164.arpa.IN NAPTR 50 10 "" "sip+E2U" "/^(.*)$/6661313/".2.1.2.1.5.5.5.8.0.4.1.e164.arpa.IN NAPTR 60 10 "U" "h323+E2U" "/^.*$/tel:5551212/".2.1.2.1.5.5.5.8.0.4.1.e164.arpa.IN NAPTR 60 10 "U" "sip+E2U" "/^.*$/tel:5551212/".Table 3 explains the fields in the NAPTR RR.
The gateway sorts the records by order and preference. Then it validates the service, regexp, and replacement fields and applies the regular or replacement expression. The resulting string is the URL for the destination if the lookup is terminal; otherwise, the lookup continues with the resulting string.
Source IP Groups
A source IP group is associated with an incoming VoIP call so that the terminating gateway can initiate appropriate services, such as number translation and incoming call control. The source IP group can be identified using one of several possibilities, in the following order of precedence:
•
•
•
A maximum of 1000 source IP groups can be configured, if the source IP groups do not include an access list. A maximum of 99 source IP groups can be configured using access lists, because each source IP group must refer to a unique access list numbered between 1 and 99.
Blocking Incoming VoIP Calls using Access Lists
Identifying the source IP group for an incoming VoIP call is done before selecting an inbound dial peer. If the source for the call is found using an access list, the rules that define the access list determine whether the call is accepted or rejected.
If the call is rejected, the gateway returns a default "NO SERVICE" message or a user-specified disconnect cause to the source. The following disconnect causes are supported:
•
•
•
•
Number Translation
A source IP group may refer to a translation profile for incoming VoIP call number translation. Even if a global VoIP translation rule is defined, the source IP group's translation profile is used instead.
The terminating gateway performs the number translation before matching the call to an inbound dial peer. This is a change from earlier Cisco IOS software releases that performed the number translation after matching the call to an inbound dial peer. Performing the number translation first may affect the results of the inbound dial peer matching.
Calls Originating from Other IP Sources
Source IP groups that refer to carrier IDs have special procedures to handle incoming H.323 calls that do not contain source carrier IDs or target carrier IDs. This situation occurs when a call comes in from a non-Cisco gateway or an IP client.
The terminating gateway tries to identify the source IP group using an IP address or a zone ID. The gateway saves the source and target carrier IDs of the source IP group and sends that information to its gatekeeper.
If the target carrier ID is "null," the gatekeeper and its GKTMP server application try to find the target carrier ID using the source carrier ID. If the gatekeeper finds the target carrier ID, it sends the target carrier ID back to the gateway. If the gatekeeper cannot find the target carrier ID, it sends a "null" message back to the gateway.
If the terminating gateway receives a "null" message for the target carrier ID, the gateway uses only the destination pattern as the matching key to select an outbound dial peer.
Translation Rules and Translation Profiles
One of the new routing capabilities is the implementation of translation profiles to capture translation characteristics for a set of call numbers. These profiles work with translation rules to provide flexibility in routing calls.
Note
The configuration sequence for defining translation rules and profiles is:
1.
2.
3.
The following sections explain these steps.
Translation Rules
The new set of translation rules has the following attributes:
•
•
•
•
•
•
•
•
Note
Table 4 illustrates some of the translation rules:
Each rule includes a precedence value, a match pattern, a replacement pattern, an optional number type, and an optional number plan. When a rule is invoked, the processing sequence is as follows:
1.
2.
3.
Translation Profiles
A translation profile defines the translation characteristics for a set of calls. Translation profiles associate translation rules for one or more of the following types of call numbers:
•
•
•
Each type of call number in the translation profile can reference a different translation rule.
Trunk and carrier based routing supports up to 1000 translation profiles.
Associating a Translation Profile with a Group or Port
After a translation profile is defined, it can be referenced by any of the following:
•
–
–
•
–
•
–
–
–
•
–
–
•
–
Incoming Call Blocking
Incoming call blocking is available to POTS, VoIP, VoATM, and VoFR dial peers. The gateway blocks the call during the session and IVR applications after the 2-stage dialing or 1-stage dialing is completed.
Note
•
•
To configure incoming call blocking, define a translation rule with a reject keyword. For example:
voice translation-rule 1rule 1 reject /408252*/Apply the rule to a translation profile for called, calling, or redirect-called numbers, such as:
voice translation profile call_block_profiletranslate calling 1Include the translation profile within a dial peer definition. For example:
dial-peer voice 111 potscall-block translation-profile incoming call_block_profilecall-block disconnect-cause incoming invalid_numberIn this example, the gateway blocks any incoming TDM (time-division multiplexing) call that successfully matches inbound dial-peer 111 and has a calling number that starts with 408252. The gateway also returns the disconnect cause "invalid number" to the source of the call. (Other disconnect causes can be assigned: unassigned-number, user-busy, or call-rejected.)
Following are two possible call-blocking scenarios:
Scenario 1: Block Inbound Calls from the PSTN/PBX/CO
We place the rejection profile right on the POTS dial peer that is associated with the voice port on which we expect the inbound call. When the inbound call attempt is made, we see in the CCAPI debugs that POTS dial-peer 9 is matched for the telephony call leg. The call-block rule is checked and we send back user-busy to the switch.
voice translation-rule 1rule 1 reject /9193927582/ <<<<-------- filter out calls from this CallerIDvoice translation-profile reject_ANItranslate calling 1dial-peer voice 9 potsdestination-pattern 9Tdirect-inward-dialport 1/0:23call-block translation-profile incoming reject_ANIcall-block disconnect-cause incoming user-busyScenario 2: Block Inbound VoX Calls from Using Local POTS Resources
We place the rejection profile right on a VoIP/VoATM/VoFR dial peer that matches an inbound VoX call attempt. When the inbound call attempt is made, we see in the CCAPI debugs that VoIP dial-peer 7 is matched for the IP call leg. The call-block rule is checked and we send back user-busy to the switch.
voice translation-rule 1rule 1 reject /9193927582/ <<<<-------- filter out calls from this CallerIDvoice translation-profile reject_ANItranslate calling 1dial-peer voice 7 voipdestination-pattern 7Tsession target ipv4:A.B.C.Dincoming called-number . <<<<-------- force inbound IP call-leg matchcall-block translation-profile incoming reject_ANIcall-block disconnect-cause incoming user-busyCall Detail Record Report
The Call Detail Record (CDR) report has several new attributes.
Number Translations
The Gateway Trunk and Carrier Based Routing feature adds the following attributes to the call active and call history records to resolve billing issues caused by number translations:
•
•
•
GKTMP Server Application Routing
The Gatekeeper Trunk and Carrier Based Routing feature implements carrier sensitive routing functionality through the external GKTMP server application and is closely linked to the Gateway Trunk and Carrier Based Routing feature.
The gatekeeper feature adds the following attributes to the call active and call history records for POTS and VoIP calls:
•
•
•
•
SIP Gateway CSR
SIP CSR for a Single IP Carrier Domain
SIP CSR for a single IP Carrier Domain is useful to you if you do not have a CSR-enabled server or a CSR application in their SIP network. SIP CSR for a single IP Carrier Domain requires the same source IP group and dial-peer configuration enhancements introduced by the Gateway Trunk and Carrier Based Routing Enhancements feature. Also, a SIP VoIP dial peer requires no special configuration to use configured CSR trunk groups, other than specifying SIP as the session protocol on the outbound dial peer. See the "Configuring an Outbound VoIP Dial Peer" section for the complete outbound dial peer configuration.
With SIP CSR, trunk groups are assigned a carrier ID. When a call arrives at an originating gateway, the gateway determines if there is a carrier ID associated with the particular interface group (DS0/trunk group/analog port) that the call came in on. If there is, then the SIP gateway matches the inbound dial-peer based on the previous carrier ID. The SIP gateway uses the outbound dial-peer matching rules and constructs an INVITE message containing the previous carrier ID and sends it to the terminating gateway.
The previous carrier ID is sent in the form of a via-extension parameter in the Via header of the INVITE message. The INVITE message may go through a proxy server before reaching the terminating gateway. The terminating gateway receives the INVITE message containing the previous carrier ID and extracts the previous carrier ID. The terminating gateway also uses it for source IP group matching and determines the target carrier ID. The gateway stores the previous and target carrier ID for later use in the outbound call leg.
During a call setup request for an outbound call, the outbound call leg selects an outbound POTS dial-peer based on the destination carrier ID. Selecting a dial peer allows the call to be routed out the appropriate port and trunk group.
All other aspects of a typical SIP call remain the same.
For backward compatibility purposes, the terminating gateway can receive an INVITE message from an originating gateway that is not CSR-aware. The previous carrier ID is not included in the INVITE message, but the terminating gateway tries to determine a target carrier to use for outbound dial-peer matching. If no target carrier can be determined, normal outbound dial-peer selection is performed.
x-route-tag Parameter
The carrier ID is sent to the terminating gateway in the form of a Via-extension parameter in the Via header of the SIP INVITE message. The Via-extension parameter can be the x-route-tag parameter. It is added if a source carrier ID is configured for the trunk group that the call came in on. The new parameter is ignored by proxy servers and gateways that are not CSR-aware. The terminating gateway parses the Via header and extracts the carrier ID. If it does not find the new parameter in the most recent Via header, it parses each previous Via header until either the parameter is found, or all Via headers have been parsed. The parsing allows for SIP CSR support in SIP deployments that use a proxy server.
x-route-tag = "cid:carrierid@host",where carrierid = carrierid (text) specified in trunk group configuration at the originating gateway (OGW), andhost = ip address or fully qualified domain name (FQDN) of OGWExample Via Header:Via: SIP/2.0/UDP gw1.foo.com:5060;x-route-tag="cid:TrunkGroupName@gw1.foo.com"tsp Parameter
The carrier ID can also be sent to the terminating gateway in the form of the tsp parameter. The tsp parameter is defined in RFC 2806 as a URL parameter.
tsp = "carrierid. fqdn",where carrierid = carrierid (text) specified in trunk group configuration at the OGW,and fqdn = fully qualified domain name of OGWExample Via Header:Via: SIP/2.0/UDP gw1.foo.com:5060;tsp="TrunkGroupName.gw1.foo.com"The terminating gateway parses the Via header for the x-route-tag parameter. If the x-route-tag does not find one, it then parses for the tsp parameter.
Use of Escape Characters
If the source and target carrier IDs contain either the "@" or "."character, SIP gateways escape those characters when adding the x-route-tag parameter to an INVITE message. This is done so the gateway can recognize that those characters are part of the carrier ID and not a separator in the x-route-tag or tsp parameter. The gateway converts the escaped characters back into "@" or "." when extracting the carrier ID from the x-route-tag or tsp parameter of the INVITE message.
Benefits
Streamlined Configuration Process
Customer-defined translation profiles permit dial peers and interfaces to be configured with similar characteristics but without repetitive configuration steps.
Flexible Routing
The gateway trunk and carrier based routing enhancements feature focuses on flexible routing by implementing carrier sensitive routing using incoming and outgoing translation rules.
VoIP routes and POTS routes are treated in a more uniform manner using VoIP source IP groups and POTS trunk groups.
Dial Peer Enhancements for Routing
Trunk groups allow trunks to be grouped under dial peers for routing purposes, permitting more flexibility in doing routing.
Restrictions
Gateway trunk and carrier based routing does not support the following features:
•
•
Related Features and Technologies
•
•
Related Documents
General reference documents:
•
•
Feature documents:
•
Platform documents:
•
•
•
•
•
•
Supported Platforms
•
•
•
•
•
•
Determining Platform Support Through Cisco Feature Navigator
Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.
To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:
Availability of Cisco IOS Software Images
Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.
Supported Standards, MIBs, and RFCs
MIBs
•
–
–
–
–
The Session Target attribute is modified to support ENUM.
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
RFCs
•
•
•
Prerequisites
•
Refer refer to the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, to configure H.323 and SIP gateways.
•
Refer to the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, for information on dial plans.
•
The Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, has information on translation rules, but that information has been modified by this VoIP Gateway Trunk and Carrier Based Routing Enhancements feature. See the earlier section Translation Rules and Translation Profiles, in this document for guidance on translation rules and translation profiles.
•
The Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, has information on source IP groups, but that information has been modified by this VoIP Gateway Trunk and Carrier Based Routing Enhancements feature. See the earlier section Source IP Groups, in this document for guidance on source IP groups.
Configuration Tasks
See the following sections for configuration tasks for this feature. Each task in the list is identified as either required or optional.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring a Translation Rule
Note
Gateway trunk and carrier routing enhancements support a maximum of 128 translation rules. Each translation rule supports a maximum of 15 rule definitions. Follow these steps to configure a translation rule, beginning in global configuration mode:
Verifying the Translation Rule Configuration
See the command descriptions later in this document for sample outputs and their explanation.
•
Router(config)# voice translation-rule 5Router(cfg-translation-rule)# rule 1 /201/ /102/Router(cfg-translation-rule)# exitThe output for the show voice-translation rule would be:
Router# show voice translation-rule 5Translation-rule tag:5Rule 5:Match pattern: 201Replace pattern: 102Match type: none Replace type: noneMatch plan: none Replace plan: none•
Router# test voice translation-rule 5 2015551212Matched with rule 5Original number:2015551212 Translated number:1025551212Original number type: none Translated number type: noneOriginal number plan: none Translated number plan: noneRouter# test voice translation-rule 5 301301Didn't match with anyof rules•
Router(config)# voice translation-rule 10Router(cfg-translation-rule)# rule 1 /^7/ /7/ type any nationalRouter(cfg-translation-rule)# endRouter# test voice translation-rule 1 700%7Error: Couldn't translate number 700%7 using rule 1Router# test voice translation-rule 100 700Error:Ruleset 100 not foundTroubleshooting Tips for a Translation Rule Configuration
Enter debug voice translation to display the trace of the translation rule performance. For example, for a translation rule 5 with rule 1 /201/ /102/ and a test string of 2015551212, the debug output would look like the following.
Router# debug voice translationVoIP Translation Rule debugging is enabled00:51:56:regxrule_stack_pop_RegXruleNumInfo:stack=0x63DECAF4; count=300:51:56:regxrule_stack_push_RegXruleNumInfo:stack=0x63DECAF4; count=000:51:56:regxrule_profile_translate:number=2015551212 type=unknown plan=unknown numbertype=calling00:51:56:regxrule_profile_match:Matched with rule 1 in ruleset 500:51:56:sed_subst:Successful substitution; pattern=2015551212 matchPattern=201 replacePattern=102 replaced pattern=102555121200:51:56:regxrule_subst_num_type:Match Type = none, Replace Type = none Input Type = unknown00:51:56:regxrule_subst_num_plan:Match Plan = none, Replace Plan = none Input Plan = unknownConfiguring a Translation Profile
Gateway trunk and carrier routing enhancements support a maximum of 1000 translation profiles. Follow these steps to define a translation profile. Use at least one of the calling types (called, calling, or redirect-called) in the translation profile, beginning in global configuration mode:
Configuring an ENUM Match Table
Follow these steps to configure an ENUM match table for outbound dial peers, beginning in global configuration mode:
Configuring the ENUM Server
Follow these steps to configure the ENUM server, beginning in global configuration mode:
Step 1
Router(config)# ip name-server ip-address
Designates the server with the specified IP address as the ENUM server.
Verifying the ENUM Match Table
See the command descriptions later in this document for sample outputs and their explanation.
•
Router# show voice enum-match-tablevoice enum-match-table 3rule 1 5 /^9\(1.*\)/ /+\1/ ciscorule 2 4 /^9011\(.*\)/ /+1408\1/ arparule 10 1 /^(.*)/ /\1/ e164.cisco.comvoice enum-match-table 5rule 2 4 /^9011\(.*\)/ /+1408\1/ arparule 10 1 /^(.*)/ /\1/ e164.cisco.comRouter# show voice enum-match-table 5voice enum-match-table 5rule 2 4 /^9011\(.*\)/ /+1408\1/ arparule 10 1 /^(.*)/ /\1/ e164.cisco.com•
Router# test enum 2 4085551212Configuring a Trunk Group
Follow these steps to configure a trunk group, beginning in global configuration mode:
Note
The following example illustrates a trunk group configuration.
Router(config)# trunk group 100Router(config-trunk-group)# description This trunk is for the MAIN carrierRouter(config-trunk-group)# carrier-id mainRouter(config-trunk-group)# max-calls any 100 direction inRouter(config-trunk-group)# max-retry 3Router(config-trunk-group)# hunt-scheme sequentialRouter(config-trunk-group)# translation-profile incoming sanjoseRouter(config-trunk-group)# translation-profile outgoing newyorkRouter(config-trunk-group)# exitVerifying the Trunk Group Configuration
See the command descriptions later in this document for sample outputs and their explanation.
•
Router# show run!!trunk group 100description This trunk is for the MAIN carriercarrier-id mainmax-calls any 100 direction inmax-retry 3hunt-scheme sequentialtranslation-profile incoming sanjosetranslation-profile outgoing newyork!•
Note
Using trunk group 100 configured above, this display appears:
Router# show trunk group 100Trunk group: 100Description: This trunk is for the MAIN carrierCarrier ID:mainTranslation profile (Incoming):sanjoseTranslation profile (Outgoing):newyorkHunt Scheme is sequentialMax Calls (Incoming): 100(Any) NOT-SET(Voice) NOT-SET(Data)Max Calls (Outgoing): NOT-SET(Any) NOT-SET(Voice) NOT-SET(Data)Retries:3Trunk Preference DEFAULTTotal channels available : 23Data = 0, Voice = 0, Pending = 0, Free = 23Total calls for trunk group: Data = 0, Voice = 0, Pend = 0, Free = 23•
–
Max Calls (Incoming): 100(Any) NOT-SET(Voice) NOT-SET(Data)Max Calls (Outgoing): NOT-SET(Any) NOT-SET(Voice) NOT-SET(Data)Retries:3–
Router# show crm!!Trunk Group Label: 100Max calls:400Max Voice (in) : 400 Cur Voice (in) : 0Max Voice (out): 400 Cur Voice (out): 0Max Data (in) : 400 Cur Data (in) : 0Max Data (out) : 400 Cur Data (out) : 0!!See the "Configuring an NFAS Interface" section for the procedure to assign an interface to a trunk group.
Troubleshooting Tips for the Trunk Group Configuration
Do not assign a trunk group label with the same name as an existing carrier ID. You will see the following message while configuring the trunk group.
Router(config)# trunk group maintrunk group label conflicts with carrier IDTo correct this problem, use a different name for the trunk group label.
Configuring a Source VoIP Group
Follow these steps to configure a source VoIP group, beginning in global configuration mode:
Note
Verifying the Source VoIP Group Configuration
See the command descriptions later in this document for sample outputs and their explanation.
•
show voice source-group name to display the details of a specific source IP group. For example:Router# show voice source-groupRouter# show voice source-group abc•
–
–
–
–
Troubleshooting Tips for the Source IP Group Configuration
•
Router(config)# voice source-group 130Router(cfg-source-grp)# carrier-id source MAINError: Input source carrier id is defined as source carrier id in another source group.•
Router# show voice source-group abcSource Group: abcdescription="",carrier-id source="cisco",carrier-id target="",trunk-group-label source="",trunk-group-label target="first",h323zone-id="",access-list=,disconnect-cause="no-service",translation-profile="",Router#The following example illustrates a valid configuration.
Router# show voice source-group abcSource Group: abcdescription="",carrier-id source="cisco",carrier-id target="mainoffice",trunk-group-label source="",trunk-group-label target="",h323zone-id="",access-list=,disconnect-cause="no-service",translation-profile="",Router#If you are using trunk-group-label routing, both trunk-group-label fields would be filled in and the carrier-id fields would be blank.
Configuring a Voice Port
Use a voice port to configure an analog interface to a trunk group. Follow these steps to configure a translation profile for a voice port, beginning in global configuration mode. Include a profile for incoming, outgoing, or both:
The following example illustrates a trunk group configuration for an analog interface.
Router(config)# voice-port 3/0/0Router(config-voiceport)# trunk-group 100Router(config-voiceport)# translation-profile incoming marketingRouter(config-voiceport)# translation-profile outgoing salesRouter(config-voiceport)# exitVerifying the Voice Port Configuration
Enter show voice port number to display the configuration for a specific voice port or
show voice port summary to display the configurations for all voice ports on the gateway. For example:Router# show voice portRouter# show voice port summaryAssigning Translation Profiles to Inbound Dial Peers
Follow these steps to assign a translation profile to incoming VoIP, VoATM, VoFR, and POTS dial peers, beginning in global configuration mode:
Configuring Call Blocking on Inbound Dial Peers
Follow these steps to configure call blocking for inbound POTS and VoIP dial peers, beginning in global configuration mode.
Note
Configuring an Outbound POTS Dial Peer
Follow these steps to assign a translation profile to outbound POTS dial peers, beginning in global configuration mode:
Note
The following example illustrates a trunk group configuration for a POTS dial peer.
Router(config)# dial-peer voice 201 potsRouter(config-dial-peer)# trunkgroup TEXAS 1Router(config-dial-peer)# trunkgroup NEWYORK 2Router(config-dial-peer)# carrier-id source WESTRouter(config-dial-peer)# carrier-id target EASTRouter(config-dial-peer)# translation-profile incoming ca101Router(config-dial-peer)# translation-profile outgoing ca105Router(config-dial-peer)# exitFollowing are a few considerations about this example.
•
•
•
•
•
•
Verifying the Dial Peer Configuration
•
show dial-peer voice summary to display the configurations for all dial peers on the gateway. For example:Router# show dial-peer voice 110See the command descriptions later in this document for sample outputs and their explanation.
•
Router# show dialplan in-carrier WEST potsInbound pots dialpeer Matching based on source carrier-idVoiceEncapPeer201information type=voice,description="",tag = 201, destination-pattern="",answer-address="",peference=0,source carrier-id="WEST", target carrier-id="EAST",source trunk-group-label="", target trunk-group-label="",numbering type="unknown",group=201, Admin state is up, Operation state is up,incoming called-number="", connections/maximum=0/unlimited,DTMF Relay=disabled,Translation profile (incoming):ca101Translation profile (outgoing):ca105incoming call blocking:translation-profile="",disconnect-cause="invalid-number"Resource Monitor and Dial Peers
If you use the resource monitor to display digital signal processor (DSP) and DS-0 resources, the trunk group resources are included in the display only if the dial peer is operationally up. Individual voice ports assigned to the dial peer are displayed regardless of the status of the dial peer. Although a trunk group is a set of voice ports, those resources assigned to the trunk group are displayed only when the dial peer is in an up state.
For example, suppose a gateway has this configuration:
controller T1 7/3framing esflinecode amids0-group 1 timeslots 1-4 type e&m-fgb dtmf dniscas-custom 1trunk-group gw14-tg1dial-peer voice 1 potstrunkgroup gw14-tg1carrier-id target abcdThe trunk group is associated with four timeslots in the DS-0 group and routing is done through a POTS dial peer. If you enter show call resource voice stats, the output when the dial peer is up looks like:
Resource Monitor - Dial-up Resource Statistics InformationUtilization: 0 percenttotal channels: 12Inuse channels: 0Disabled channels: 0Pending channels: 0Free channels: 12DS0 Statistics:Utilization: 0 percentTotal channels: 96Addressable channels: 4Inuse channels: 0Disabled channels: 0Free channels: 4If the dial peer is down, the Addressable channels and Free channels fields would be 0.
To check the status of the dial peer, enter show dial-peer voice number | inc Operation state.
Configuring an Outbound VoIP Dial Peer
Follow these steps to configure an outbound VoIP dial peer, beginning in global configuration mode:
The following example illustrates an outbound VoIP dial peer.
Router(config)# dial-peer voice 2201 voipRouter(config-dial-peer)# destination-pattern 2..Router(config-dial-peer)# session target enum:2Router(config-dial-peer)# translation-profile outgoing ca103Router(config-dial-peer)# exitAssigning a Translation Profile to an NFAS Interface
Follow these steps to assign a translation profile to an NFAS interface, beginning in global configuration mode:
Configuring an NFAS Interface
Follow these steps to configure an NFAS interface as a trunk group member, beginning in global configuration mode:
The following example illustrates assigning an ISDN interface to a trunk group.
Router(config)# interface Serial7/1:23Router(config-if)# trunk-group 100 1Router(config-if)# exitMore than one ISDN interface can be assigned to the same trunk group. For example:
Router(config)# interface Serial7/1:23Router(config-if)# trunk-group 100 1Router(config-if)# exitRouter(config)# interface Serial7/0:23Router(config-if)# trunk-group 100 1Router(config-if)# exitVerifying the NFAS Interface Configuration
•
Router# show run!!interface Serial7/1:23no ip addresstrunk-group 100 1isdn switchtype primary-4essisdn incoming-voice modem!•
Router# show trunk group 100Trunk group: 100Description: This trunk is for the MAIN carrierCarrier ID: mainTranslation profile (Incoming):Translation profile (Outgoing):Hunt Scheme is sequentialMax Calls (Incoming): 100(Any) NOT-SET(Voice) NOT-SET(Data)Max Calls (Outgoing): NOT-SET(Any) NOT-SET(Voice) NOT-SET(Data)Retries: 3Trunk 7/1:D Preference 1Total channels available: 23Data = 0, Voice = 0, Pending = 0, Free = 23Trunk 7/0:D Preference 1Total channels available: 23Data = 0, Voice = 0, Pending = 0, Free = 23Total calls for trunk group: Data = 0, Voice = 0, Pend = 0, Free = 46Notice that the trunk group has two ISDN interfaces assigned to it and both interfaces have the same preference number.
•
Router# show trunk group 100!!!Trunk 7/1:D Preference 1Total channels available: 23Data = 0, Voice = 0, Pending = 0, Free = 23Trunk 7/0:D Preference 1Total channels available: 23Data = 0, Voice = 0, Pending = 0, Free = 0!Verify the status of the serial interface by entering show ISDN stat. If the controller is down, enter shut and no shut on the interface to try to start the interface.
Troubleshooting Tips for the NFAS Interface Configuration
•
Router(config)# interface Serial7/1:23Router(config-if)# trunk-group 200Attempt to add ISDN interface into a TG that contains CAS trunkAssign a different trunk group to this interface.
•
Router(config)# interface Serial7/1:23Router(config-if)# trunk group NEWYORKRouter(config-controller)# exitThis will not add trunk to ISDN interfaceThe trunk group command creates a new trunk group named NEWYORK, but it does not assign NEWYORK to the ISDN interface. Use trunk-group NEWYORK instead.
Configuring a DS-0 Group
Follow these steps to configure DS-0 group as a trunk group member, beginning in global configuration mode:
The following example illustrates assigning a DS-0 group to a trunk group.
Router(config)# controller T1 7/7Router(config-controller)# framing esfRouter(config-controller)# linecode b8zsRouter(config-controller)# ds0-group 1 timeslots 1-23 type e&m-fgb dtmf dnisRouter(config-controller)# cas-custom 1Router(config-controller)# trunk-group ma200Router(config-controller)# exitMultiple DS-0 groups can be assigned to trunk groups. The following example assigns two different DS-0 groups to different trunk groups.
Router(config)# controller T1 7/7Router(config-controller)# framing esfRouter(config-controller)# linecode b8zsRouter(config-controller)# ds0-group 1 timeslots 1-10 type e&m-fgb dtmf dnisRouter(config-controller)# ds0-group 2 timeslots 11-23 type e&m-fgd dtmf dnisRouter(config-controller)# cas-custom 1Router(config-controller)# trunk-group ma200Router(config-controller)# cas-custom 2Router(config-controller)# trunk-group ny150Router(config-controller)# exitThe following example illustrates two different DS-0 groups assigned to the same trunk group.
Router(config)# controller T1 7/7Router(config-controller)# framing esfRouter(config-controller)# linecode b8zsRouter(config-controller)# ds0-group 1 timeslots 1-10 type e&m-fgb dtmf dnisRouter(config-controller)# ds0-group 2 timeslots 11-23 type e&m-fgd dtmf dnisRouter(config-controller)# cas-custom 1Router(config-controller)# trunk-group ny150Router(config-controller)# cas-custom 2Router(config-controller)# trunk-group ny150Router(config-controller)# exitThe following example illustrates two different controllers assigned to the same trunk group.
Router(config)# controller T1 0/1Router(config-controller)# framing esfRouter(config-controller)# linecode b8zsRouter(config-controller)# ds0-group 1 timeslots 1-23 type e&m-fgb dtmf dnisRouter(config-controller)# cas-custom 1Router(config-controller)# trunk-group ny150Router(config-controller)# exitRouter(config)# controller T1 7/7Router(config-controller)# framing esfRouter(config-controller)# linecode b8zsRouter(config-controller)# ds0-group 1 timeslots 1-23 type e&m-fgd dtmf dnisRouter(config-controller)# cas-custom 1Router(config-controller)# trunk-group ny150Router(config-controller)# exit
Note
Verifying the DS-0 Group Configuration
Enter show run to display the gateway configuration. Look for these lines in the output display.
Router# show run!!controller T1 7/7framing esflinecode b8zsds0-group 1 timeslots 1-23 type e&m-fgb dtmf dniscas-custom 1trunk-group ma200!Troubleshooting Tips for the DS-0 Group Configuration
Use the correct command when assigning the DS-0 group to the trunk group. The following example will generate an error message.
Router(config)# controller T1 7/6Router(config-controller)# cas-custom 1Router(config-controller)# trunk group TEXASRouter(config-controller)# exitThis will not add trunk to CAS custom 1The trunk group command creates a new trunk group named TEXAS, but it does not assign TEXAS to the CAS interface. Use trunk-group TEXAS instead.
Configuring a Global Translation Profile for Incoming VoIP Calls
Use this command to assign a translation profile to all incoming VoIP calls, beginning in global configuration mode:
Step 1
Router(config)# voip-incoming translation-profile name
Assigns the translation profile to all incoming VoIP calls.
Configuring Call Capacity Reporting for Unsolicited Calls
Follow these steps to configure call capacity reporting of unsolicited calls, beginning in global configuration mode:
Monitoring and Maintaining Gateway Trunk and Carrier Based Routing
To monitor and maintain the gateway trunk and carrier based routing enhancements, use the following commands in privileged EXEC mode:
Router# debug crm
Displays the Carrier Resource Manager information.
Router# debug csm tgrm
Displays the Call Switching Module trunk group resource manager information.
Router# debug dialpeer
Displays the dial peer information.
Router# debug isdn tgrm
Displays the ISDN trunk group resource manager information.
Router# debug tgrm
Displays trunk group resource manager information.
Router# debug voice enum [detail | summary]
Displays the ENUM match table information.
Router# debug voice source-group
Displays the source IP group information.
Router# debug voice translation
Displays the translation-rule information.
Router# debug voip enum [detail | summary]
Displays the ENUM match table information.
Router# show crm
Displays carrier's call capacities information.
Router# show dialplan number dialstring
Displays the dial peer that is reached when a specific telephone number is dialed.
Router# show trunk group
Displays the channel status of individual trunk group members.
Troubleshooting VoIP Gateway Trunk and Carrier Based Routing
This section provides troubleshooting guidelines for the VoIP Gateway Trunk and Carrier Based Routing feature.
Frequently asked questions regarding trunk and carrier configurations include:
•
•
•
•
Why are my trunk or carrier based calls not going through?
Several causes may contribute to calls not going through. Check the following configuration components:
•
•
•
•
•
Troubleshooting Trunk Group Configurations
Verify the following configuration parameters:
•
Use show trunk group to display the value for Max Calls. If the value is 0, use the max-calls command in the trunk group configuration mode to reset the value. See the "Configuring a Trunk Group" section for the trunk group configuration procedure.
•
Use show trunk group to display the interface associated with the trunk group. If the interface is incorrect, use one of the configuration procedures described earlier in this section to associate the trunk group to the correct interface.
•
Use show trunk group to display the number of available channels. If no channels are available, then do one of the following:
–
–
•
•
•
TGRM: tgrm_tg_get_carrier_id: carrier_id=711! Successfully reserves the intended trunk group and timeslot.TGRM:tgrm_select_by_state() - Success! Reserved tgTag=711,tgmPref#=65,Ts=1Troubleshooting Dial Peer Configurations
Verify the following dial peer parameters:
•
Use show run to display the gateway configuration. Look for source carrier ID lines in the dial peer configurations. Look for lines that include carrier-id source, such as
dial-peer voice 1311 potscarrier-id source s-alphacall-block translation-profile incoming cb_xruletranslation-profile incoming xruleIf you do not see entries such as these, refer to Configuring Call Blocking on Inbound Dial Peers earlier in this section for the procedure to assign a source carrier ID to an inbound dial peer.
•
Use show run to display the gateway configuration. Look for target carrier ID lines in the dial peer configurations. Look for an entry that includes carrier-id target, such as
dial-peer voice 205 potstrunkgroup BOSTONcarrier-id target maintranslation-profile outgoing tx17forward digits allIf you do not see entries such as these, refer to Configuring an Outbound POTS Dial Peer earlier in this section for the procedure to assign a target carrier ID to an outbound dial peer.
•
On the originating gateway, look for indications that the dial peer has been matched. For example,
Router# debug dialpeer!!00:22:28: dpAssociateIncomingPeer_T:Matching route label abc100:22:28: Inside dpMatchCore:!!00:22:28: destination pattn:5108880101 expanded string:510888010100:22:28:MatchNextPeer:Peer 1311 matchedOn the terminating gateway, look for indications that the target carrier id (CID) has been matched. For example,
Router# debug dialpeer!!00:22:28: dpMatchPeersMoreArg: Match Dest. pattern + Target CID; called (1025168853) target CID (abc1)00:22:28: Inside dpMatchCore:00:22:28: destination pattn:1025168853 expanded string:1025168853!!00:22:28:MatchNextPeer:Peer 201 matched•
Troubleshooting Source IP Group Configurations
Verify the following source IP group parameters:
•
•
Router# test source-group carrier-id source abcA source-group is found with source carrier-id abcSource Group: 130description="",carrier-id source="abc"carrier-id target="xyz"trunk-group-label source="",trunk-group-label target="",h323zone-is="",access-list=,disconnect-cause="no-service"translation-profile="abc-profile-sipg",Router#If the carrier ID or trunk-group-label is not found, see Configuring a Source VoIP Group for the procedure to configure the carrier ID or trunk-group-label.
•
!voice source-group 101access-list 1!!access-list 1 permit 10.8.50.13access-list 1 deny 10.8.56.99!Test the permit and deny IP addresses:
Router# test source-group ip-address 10.8.50.13A source group is found with ip address=10.8.50.13Source Group:101description="",carrier-id source="",carrier-id target="",trunk-group-label source="",trunk-group-label target="",h323zone-id="",access-list=1,disconnect-cause="no-service",destination-pattern="",incoming called-number="",translation-profile="",Router# test source-group ip-address 10.8.56.99A source group is found with ip address=10.8.56.99An ip address 10.8.56.99 is rejected with disc-cause="no-service"Source Group:101description="",carrier-id source="",carrier-id target="",trunk-group-label source="",trunk-group-label target="",h323zone-id="",access-list=1,disconnect-cause="no-service",destination-pattern="",incoming called-number="",translation-profile="",•
Why are incoming calls not blocked as expected?
Call blocking requires specific configuration procedures.
•
If call blocking is not configured, use translation rules for an incoming dial peer or use an access list for a source IP group.
–
Router(config)# voice translation-rule 1Router(cfg-translation-rule)# rule 1 reject /912230*/Assign the translation-rule to a profile, such as
Router(config)# voice translation profile blockingRouter(cfg-translation-profile)# translate calling 1Assign the call blocking profile to an inbound dial peer, such as
Router(config)# dial-peer voice 201 potsRouter(config-dial-peer)# call-block translation-profile incoming blockingRouter(config-dial-peer)# call-block disconnect-cause incoming unassigned-numberUse debug voice translation to verify that the call blocking is working. Look in the output display for a call block rule line, such as
Router# debug voice translation!00:51:56:regxrule_stack_pop_RegXruleNumInfo:stack=0x63DECAF4; count=100:51:56:regxrule_profile_match:Matched a call block rule; number 912230456 rule precedence=100:51:56:regxrule_profile_block:Matched with rule 1 in ruleset 100:51:56:regxrule_stack_pop_RegXruleNumInfo:stack=0x63DECAF4; count=0–
Router(config)# access-list 15 deny host 11.0.0.5To add the access list to the source IP group, the commands would be
Router(config)# voice source-group 115Router(cfg-source-grp)# access-list 15Use show voice source-group to ensure that the access list is configured and that the source IP group does not have a source carrier ID or source trunk-group-label.
•
•
Why are the number translations not working properly?
The following factors can account for number translations not working properly.
•
•
•
•
•
•
•
Why is ENUM not working?
Check the following ENUM configuration components.
•
•
•
•
•
Configuration Examples
This section provides the following configuration examples:
•
•
Configuring Trunk and Carrier Based Routing on an Originating Gateway: Example
The following output shows how to configure trunk and carrier based routing on the originating gateway.
!version 12.2no service single-slot-reload-enableno service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internal!hostname first!!resource-pool disable!!voice-fastpath enableip subnet-zerono ip domain-lookupip host dirt 192.168.254.254ip name-server 172.20.140.108!no ip dhcp-client network-discoverylcp max-session-starts 0isdn switch-type primary-5ess!voice enum-match-table 1rule 1 5 /^9\(1.*\)/ /+\1/ e164.cisco.comrule 10 1 /^(.*)/ /\1/ e164.cisco.com!voice translation-rule 1rule 1 /408/ /804/rule 2 /804/ /732/rule 3 /875/ /785/!voice translation-rule 2rule 1 /785/ /786/rule 2 /786/ /875/rule 3 /732/ /408/!voice translation-rule 3rule 1 /303/ /330/rule 2 /330/ /331/!voice translation-rule 4rule 1 reject /4087775555/rule 2 reject /6503232222/!voice translation-profile cb_xruletranslate called 4translate calling 4translate redirect-called 4!voice translation-profile xruletranslate calling 1translate called 2translate redirect-called 3!fax interface-type modemmta receive maximum-recipients 0!controller T1 7/0framing sflinecode ami!controller T1 7/1framing esflinecode amids0-group 1 timeslots 1-4 type e&m-fgb dtmf dnisds0-group 2 timeslots 5-8 type e&m-fgb dtmf dnisds0-group 3 timeslots 9-12 type e&m-fgb dtmf dnisds0-group 4 timeslots 13-16 type e&m-fgb dtmf dnisds0-group 5 timeslots 17-20 type e&m-fgb dtmf dnisds0-group 6 timeslots 21-24 type e&m-fgb dtmf dniscas-custom 1trunk-group 11cas-custom 2trunk-group 11cas-custom 3trunk-group 11cas-custom 4trunk-group 11cas-custom 5trunk-group 11cas-custom 6trunk-group 11!controller T1 7/2framing esflinecode b8zspri-group timeslots 1-24!controller T1 7/3framing esflinecode b8zspri-group timeslots 1-24!controller T1 7/4framing esflinecode b8zspri-group timeslots 1-24 nfas_d primary nfas_int 1 nfas_group 1!controller T1 7/5framing esflinecode b8zspri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 1!controller T1 7/6framing sflinecode ami!controller T1 7/7framing sflinecode ami!!interface FastEthernet0/0ip address 172.16.50.13 255.255.0.0no ip route-cacheno ip mroute-cacheduplex autospeed auto!interface FastEthernet0/1ip address 172.20.140.96 255.255.0.0no ip route-cacheno ip mroute-cacheduplex autospeed auto!interface Serial7/2:23no ip addresstrunk-group 12isdn switch-type primary-5essisdn incoming-voice modem!interface Serial7/3:23no ip addresstrunk-group 13isdn switch-type primary-5essisdn incoming-voice modemisdn T310 60000no cdp enable!interface Serial7/4:23no ip addresstrunk-group 13isdn switch-type primary-5essisdn incoming-voice modemisdn guard-timer 3000isdn T306 30000isdn T310 10000no cdp enable!ip classlessip route 0.0.0.0 0.0.0.0 172.16.0.1ip route 192.168.254.0 255.255.255.0 FastEthernet0/0no ip http server!!trunk group 11carrier-id s-mci!trunk group 12carrier-id s-att!trunk group 13carrier-id s-sprint!voice-port 7/1:1!voice-port 7/1:2!voice-port 7/1:3!voice-port 7/1:4!voice-port 7/1:5!voice-port 7/1:6!voice-port 7/2:D!voice-port 7/3:D!voice-port 7/4:D!dial-peer voice 5108888 voipdestination-pattern 510888....session protocol sipv2session target ipv4:172.16.50.14!dial-peer voice 1311 potscarrier-id source s-alphacall-block disconnect-cause incoming user-busycall-block translation-profile incoming cb_xruletranslation-profile incoming xruledirect-inward-dial!dial-peer voice 1312 potscarrier-id source s-betacall-block translation-profile incoming cb_xruletranslation-profile incoming xrule!dial-peer voice 1313 potscarrier-id source s-gammacall-block translation-profile incoming cb_xruletranslation-profile incoming xruledirect-inward-dial!dial-peer voice 510889 voipdestination-pattern 510889....session protocol sipv2session target enum:1!dial-peer voice 510890 voipdestination-pattern 510890....session target enum:1!dial-peer voice 999 voipdestination-pattern 510........session target ipv4:172.16.50.14!exec-timeout 0 0logging synchronousline aux 0logging synchronousline vty 0 4loginline 1/00 1/107no flush-at-activationmodem InOutline 3/00 3/107no flush-at-activationmodem InOut!scheduler allocate 10000 400endConfiguring Trunk and Carrier Based Routing on a Terminating Gateway: Example
The following output shows how to configure trunk and carrier based routing on the terminating gateway.
!version 12.2no service single-slot-reload-enableno service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internal!hostname second!!resource-pool disabledial-tdm-clock priority 1 freerun!voice-fastpath enableno ip subnet-zerono ip domain-lookupip host second 192.168.254.254 255.255.255.0ip name-server 172.21.188.171!no ip dhcp-client network-discoverylcp max-session-starts 0isdn switch-type primary-dms100voice call carrier capacity activevoice call carrier capacity timer interval 45!voice source-group sg-alphacarrier-id source s-alphacarrier-id target t-alphadescription route calls from source alpha to target alphatranslation-profile incoming xrule!voice source-group sg-betacarrier-id source s-betacarrier-id target t-betadescription route calls from source beta to target betatranslation-profile incoming xrule!voice source-group sg-gammacarrier-id source s-gammacarrier-id target t-gammadescription route calls from source gamma to target gammatranslation-profile incoming xrule!voice source-group sg-ipaccess-list 1translation-profile incoming xrule!voice translation-rule 1rule 1 reject /5108880101/rule 2 /^510888\(01..\)/ /\10101/rule 3 /5108880.../ /5108880101/!voice translation-rule 2rule 1 /51088802../ /5108880101/rule 2 /51088803../ /5108880101/rule 3 /510889..../ /5108880101/rule 4 /510890..../ /5108880101/!voice translation-rule 3rule 1 /65088801../ /6508880101/!voice translation-profile xruletranslate called 1translate calling 2translate redirect-called 3!fax interface-type modemmta receive maximum-recipients 0!trunk activate port-threshold 33!controller T1 7/0framing sflinecode ami!controller T1 7/1framing esflinecode amids0-group 1 timeslots 1-4 type e&m-fgb dtmf dnisds0-group 2 timeslots 5-8 type e&m-fgb dtmf dnisds0-group 3 timeslots 9-12 type e&m-fgb dtmf dnisds0-group 4 timeslots 13-16 type e&m-fgb dtmf dnisds0-group 5 timeslots 17-20 type e&m-fgb dtmf dnisds0-group 6 timeslots 21 type e&m-fgb dtmf dnisds0-group 7 timeslots 22 type e&m-fgb dtmf dnisds0-group 8 timeslots 23 type e&m-fgb dtmf dnisds0-group 9 timeslots 24 type e&m-fgb dtmf dnisds0 busyout 22-23 hardcas-custom 1trunk-group 11 1cas-custom 2trunk-group 11 2cas-custom 3trunk-group 11 3cas-custom 4trunk-group 11 4cas-custom 5trunk-group 11 5cas-custom 6trunk-group 12 1cas-custom 7trunk-group 12 2cas-custom 8trunk-group 12 3cas-custom 9trunk-group 12 4!controller T1 7/2framing esflinecode b8zspri-group timeslots 1-24 nfas_d primary nfas_int 1 nfas_group 1!controller T1 7/3framing esflinecode b8zspri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 1!controller T1 7/4framing esflinecode amids0-group 1 timeslots 1-4 type e&m-fgb dtmf dnisds0-group 2 timeslots 5-8 type e&m-fgb dtmf dnisds0-group 3 timeslots 9-12 type e&m-fgb dtmf dnisds0-group 4 timeslots 13-16 type e&m-fgb dtmf dnisds0-group 5 timeslots 17-20 type e&m-fgb dtmf dnisds0-group 6 timeslots 21 type e&m-fgb dtmf dnisds0-group 7 timeslots 22 type e&m-fgb dtmf dnisds0-group 8 timeslots 23 type e&m-fgb dtmf dnisds0-group 9 timeslots 24 type e&m-fgb dtmf dnisds0 busyout 21-22,24 hardcas-custom 1trunk-group 11 5cas-custom 2trunk-group 11 6cas-custom 3trunk-group 11 7cas-custom 4trunk-group 11 8cas-custom 5trunk-group 12 5cas-custom 6trunk-group 12 5cas-custom 7trunk-group 12 5cas-custom 8trunk-group 12 5cas-custom 9trunk-group 12 5!controller T1 7/5framing esflinecode b8zspri-group timeslots 1-24!controller T1 7/6framing sflinecode ami!controller T1 7/7framing sflinecode ami!interface FastEthernet0/0ip address 172.16.50.14 255.255.0.0no ip mroute-cacheduplex autospeed auto!interface FastEthernet0/1ip address 10.0.0.211 255.0.0.0no ip route-cacheno ip mroute-cacheshutdownduplex autospeed auto!interface Serial7/2:23no ip addressisdn switch-type primary-dms100!ip classlessip route 0.0.0.0 0.0.0.0 172.16.0.1ip route 192.168.254.0 255.255.255.0 FastEthernet0/0ip route 192.168.254.0 255.255.255.0 172.16.0.1no ip http server!access-list 1 permit 172.16.50.12!!trunk group 11carrier-id t-alphahunt-scheme longest-idle!trunk group 12carrier-id t-alphahunt-scheme least-idle!trunk group 13carrier-id t-betahunt-scheme random!trunk group 14carrier-id t-gammahunt-scheme random!call rsvp-sync!voice-port 7/1:1!voice-port 7/1:2!voice-port 7/1:3!voice-port 7/1:4!voice-port 7/1:5!voice-port 7/1:6!voice-port 7/1:7!voice-port 7/1:8!voice-port 7/1:9!voice-port 7/2:D!voice-port 7/4:1!voice-port 7/4:2!voice-port 7/4:3!voice-port 7/4:4!voice-port 7/4:5!voice-port 7/4:6!voice-port 7/4:7!voice-port 7/4:8!voice-port 7/4:9!voice-port 7/5:D!mgcp profile default!dial-peer voice 20001 voipcarrier-id source alpha!dial-peer voice 20002 voipcarrier-id source beta!dial-peer voice 20003 voipcarrier-id source gamma!dial-peer voice 10001 potstrunkgroup 11 1trunkgroup 12 2translation-profile outgoing 1carrier-id target t-alphaforward-digits all!dial-peer voice 10002 potstrunkgroup 13translation-profile outgoing 2carrier-id target t-beta!dial-peer voice 10003 potstrunkgroup 14translation-profile outgoing 1carrier-id target t-gammaforward-digits all!line con 0exec-timeout 0 0logging synchronousline aux 0logging synchronousline vty 0 4loginline 1/00 1/107no flush-at-activationmodem InOut!scheduler allocate 10000 400endCommand Reference
All commands used with this feature are documented in the Cisco IOS Voice Command Reference, Release 12.3.
Guest
