Table Of Contents
CODEC and DTMF Preferential Routing Enhancements
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Prerequisites for Using this Feature
Collecting DTMF Capability Data
Adding DTMF Capability on Trunk Groups
Adding CODEC Capability to a Dial Plan
Modifying DTMF Capability on Trunk Groups
Deleting DTMF Capability on Trunk Groups
Adding the DTMFCAP Result Type
Modifying the DTMFCAP Result Type
Deleting the DTMFCAP Result Type
PROV-ADD/DLT/ED:DtmfCap—Provision the DTMF Capability of an Egress Trunk Group
Obtaining Documentation, Obtaining Support, and Security Guidelines
CODEC and DTMF Preferential Routing Enhancements
Document Release History
Feature History
Release Modification9.7(3)
The CODEC and DTMF Preferential Routing Enhancements feature was introduced on the Cisco MGC software.
This document describes the CODEC and DTMF Preferential Routing Enhancements feature.
This feature is described in the following sections:
•
Supported Standards, MIBs, and RFCs
•
Obtaining Documentation, Obtaining Support, and Security Guidelines
Feature Overview
This feature provides the following:
•
Extends the PGW 2200 ability to influence CODEC selection to IP calls (SIP and H.323).
•
Allow customers to determine that there is no common CODEC or DTMF capability between a certain ingress and egress destination, allowing route advance to an egress destination that can either directly handle the combination, or else an IP-IP gateway that can perform transcoding.
•
Supports route advance when the type of DTMF interworking does not match.
Benefits
This feature provides the following benefits:
Support CODEC Selection for IP-to-IP Calls
Support an extension to the existing CODEC handling so that it works for SIP-to-SIP or SIP-to-H.323 calls.
Allows CODEC List Comparison for Route Advance
The Cisco MGC compares the CODECs list that are provisioned at Level 1 (sigPath), Level 2 (trunk group) or Level 3 (dial plan result type). If no match is found, then the MGC performs a route advance to find a compatible CODECs in another egress destination. You can provision the last route to point to an IP-IP gateway capable of transcoding so the call can proceed.
Note
If there is more than one CODEC selection provisioned, the highest level of CODEC provisioning is used. For example, sigPath CODEC selection is overridden by trunk group, which is overridden by the dial plan CODEC result type.
Allows DTMF Comparison for Route Advance
The Cisco PGW 2200 now allows for route advance when the dual tone multifrequency (DTMF) between the ingress and egress connections do not match. The DTMFCAP result type is used in the dial plan to provision the DTMF capabilities on ingress trunk groups. The DtmfCap trunk group property is used to provision the DTMF capabilities on the egress trunk groups. The DTMF modes supported include out of band DTMF, RFC 2833 DTMF, and ignore DTMF capability.
Related Features and Technologies
The following features and technologies are related to this feature:
•
Routing and Analysis Enhancements
Related Documents
This document contains information that is related to this feature. The documents that contain additional information related to the Cisco Media Gateway Controller (MGC) are at the following url:
http://www.cisco.com/en/US/products/hw/vcallcon/ps2027/tsd_products_support_series_home.html
Supported Platforms
The CODEC and DTMF Preferential Routing Enhancements feature is supported in Cisco MGC Software Release 9.7(3).
The hardware platforms supported for the Cisco MGC software are described in the Cisco Media Gateway Controller Hardware Installation Guide.
Supported Standards, MIBs, and RFCs
This section identifies the new or modified standards, MIBs, or RFCs that are supported by this feature.
Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
For more information on the MIBs used in the Cisco MGC software, refer to the Cisco Media Gateway Controller Release 9 Management Information Base Guide.
RFCs
No new or modified RFCs are supported by this feature.
Prerequisites for Using this Feature
The Cisco PGW 2200 must be running Cisco MGC software Release 9.7(3). Prerequisites for this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.7(3) at:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel9/relnote/rn973.htm.
Provisioning Tasks
The following sections describe the provisioning tasks related to this feature:
Provisioning Prerequisites
This section lists the data that you must gather to successfully provision this feature. For more information on planning the provisioning for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Collecting DTMF Capability Data
The DTMF capability in the egress side is provisioned in the egress trunk group. The DTMF capability in the ingress side is provisioned in the A- or B-number analysis. You must be ready to enter the following data about the DTMF capability:
•
MML name
•
DTMF capability
You can define the parameters for your external nodes in Table 2 in the "Properties" section.
Collecting CODEC Data
Before provisioning CODEC route advance expanded to dial plan level 3, have the following information ready:•
the CODEC name to be provisioned on dial plan (for example, G.711/G.729)
•
provisioned on A number or B number
•
provisioned with M (mandatory) or P (prefer)
Provisioning Procedures
Provision the DTMF capability for the egress trunk group from the Cisco MGC 2200 to another gateway, along with the CODEC on the corresponding level.
This provisioning is performed when you want to make sure that both sides of an IP-to-IP call support the same DTMF method. This section covers the following provisioning topics:
•
Provisioning Basics, page 11
•
Adding DTMF Capability on Trunk Groups
•
Deleting DTMF Capability on Trunk Groups
Provisioning Basics
The procedures in this section describe how to start a provisioning session and how to save and activate the changes you have made.
•
Starting a Provisioning Session
•
Saving and Activating your Provisioning Changes
•
Ending a Provisioning Session Without Activating your Changes
For more detailed information about provisioning your Cisco MGC, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Starting a Provisioning Session
You may need to start a provisioning session as part of your system operations. To do this, log into the active Cisco MGC, start an MML session, and enter the following command:
prov-sta::srcver="curr_ver",dstver="mod_ver"Where:
•
curr_ver—The name of the current configuration version. In place of the name of the current configuration version, you can also enter:
–
new—A new default session configuration; no existing source configuration is available.
–
active—Selects the active configuration as the source for configuration changes.
Note
If you do not know the name of your current configuration session, you can use the procedure described in the "Retrieving Data on the Current Provisioning Session" section on page 7.
•
mod_ver—A new configuration version name that contains your provisioning changes.
For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:
prov-sta::srcver="ver1",dstver="ver2"Once a provisioning session is underway, you may use the prov-add, prov-ed, or prov-dlt MML commands to add, modify, and delete components on your system. This document describes how to provision this feature. For more information on provisioning other components on your Cisco MGC, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
There are two ways to close your provisioning session: saving and activating your provisioning changes, as described in the "Saving and Activating your Provisioning Changes" section or ending your provisioning session without saving and activating your changes, as described in the "Ending a Provisioning Session Without Activating your Changes" section.
Saving and Activating your Provisioning Changes
When you have completed making provisioning changes in your session, you must enter a command to save and activate your changes. There are two different provisioning MML commands that do this: prov-cpy and prov-dply.
CautionUsing the prov-cpy and prov-dply MML commands can severely impact your system's call processing performance, depending on the extent of your provisioning changes. We recommend that these commands be issued during a maintenance window when traffic is minimal.
The prov-cpy MML command is used to save and activate your changes on simplex Cisco MGC (single host) systems.
Note
When you enter the prov-cpy command, your provisioning session is also automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session as described in the "Starting a Provisioning Session" section.
CautionDo not use the prov-cpy command to save and activate your changes on a continuous-service Cisco MGC (active and standby hosts) system. Saving and activating using prov-cpy on such a system would require using the prov-sync MML command to synchronize the provisioning data on the active and standby hosts. The system does not indicate when the synchronization process fails, which would create problems when a switchover operation occurs.
The prov-dply MML command is used to save and activate your changes on the active and standby
Cisco MGCs in a continuous-service system. This command should not be used on a Cisco MGC in a simplex configuration.
Note
When you enter the prov-dply command, your provisioning session is also automatically ended, unless an error occurs during execution. If you want to make additional provisioning changes, you must start a new provisioning session, as described in the "Starting a Provisioning Session" section.
Ending a Provisioning Session Without Activating your Changes
If you want to end a provisioning session without saving and activating the changes you have entered, enter the prov-stp MML command. This command ends your current provisioning session and your changes are not entered.
Retrieving Provisioning Data
You can use the prov-rtrv MML command to retrieve information about your current provisioning settings. The ways you can use this command to retrieve provisioning data are described in the following sections:
•
Retrieving Data for an Individual Component
•
Retrieving Data for All Components
•
Retrieving Data for All Components of a Particular Type
•
Retrieving Data on the Current Provisioning Session
•
Retrieving Data on Supported Signaling Protocols
Retrieving Data for an Individual Component
You can retrieve provisioning data on any individual component on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:component:name=MML_nameWhere:
•
component—The MML component type associated with the desired component. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
•
MML_name—The MML name for the desired component. You can determine the MML names for the various components using the prov-rtrv:all MML command.
For example, to view the provisioning data for a SS7 signaling service called ss7svc1, you would enter the following command:
prov-rtrv:ss7path:name="ss7svc1"The response to the command is dependent upon the component type associated with the desired component. For example, to view the properties for an SUA routing key called suakey1, you would enter the following command:
prov-rtrv:suakey:name="suakey1"Retrieving Data for All Components
You can retrieve data on all of the components provisioned on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:allRetrieving Data for All Components of a Particular Type
You can retrieve provisioning data on all components of a particular type on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:component:"all"Where: component is the MML component type associated with the desired component group. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
For example, to view the provisioning data for all SS7 signaling services, you would enter the following command:
prov-rtrv:ss7path:"all"Retrieving Data on the Current Provisioning Session
You can retrieve provisioning data on the current provisioning session. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:sessionThe system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2004-01-13 13:39:19M RTRV"session=jtest:session"/*Session ID = mml1SRCVER = activeDSTVER = jtest*/Retrieving Data on Supported Signaling Protocols
You can retrieve protocol data for the current provisioning session. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:variantsAdding Components
The following subsections identify the steps required to provision this feature as part of initial provisioning.
Adding DTMF Capability on Trunk Groups
This section contains the procedures that you must perform to add the DTMF capability on an egress trunk group to your Cisco MGC provisioning data.
Note
This feature adds to the PGW 2200 DTMF capability to allow for route advance when the DTMF type supported does not match the egress trunk group.
•
Adding DTMF Capability on an Egress Trunk Group
Adding DTMF Capability on an Egress Trunk Group
To add DTMF capability on an egress trunk group to your provisioning data, perform the following steps:
Step 1
Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 2
Enter the following command to add the DTMF capability on an egress trunk group:
mml> prov-add:trnkgrpprop:name="name",DtmfCap="x"Where:
•
name—The name of a previously defined trunk group. The value range is from 1 through 9999.
•
x—The DTMF capacity selection value: 0—Ignore DTMF capability, 1—RFC 2833, or 2—Out of band DTMF capability.
For example, to add out of band DTMF capacity on the trunk group named 1111, enter the following command:
mml> prov-add:trnkgrpprop:name="1111",DtmfCap="2"Step 3
Repeat Step 2 for each trunk group you want to add out of band DTMF capability to your provisioning data.
Step 4
If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.
Adding CODEC Capability to a Dial Plan
In the PGW 2200, CODEC selection is determined for Level 3 by the CODEC result type, for Level 2 by the GWDefaultCodecString trunk group property, and for Level 1 by the GWDefaultCodecString sigPath property. A mandatory CODEC indication is the highest priority, followed by preferred, then the individual CODEC vales, and NULL indicating no CODEC preference.
Step 1
Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Enter the following command to add the CODEC selection capability to a dial plan:
mml> numan-add:resulttable:custgrpid="xxXX",resulttype="name",dw1="x",setname="yyyy", name="rte2"Where:
•
name—The name you give to the component. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
•
custgrpid—Customer group ID number associated with your dial plan. The value range is a 4-digit alphanumeric string.
•
resulttype—Result type. Indicates the result type being provisioned. Any valid result type name is allowed. The result type for this feature is DTMFCAP.
•
dw1—Dataword1. Indicates the dataword1 value being provisioned, where dw1 can be: 0, 1, or 2. Dataword values are: 0—Ignore DTMF capability, 1—RFC 2833, or 2—Out of band DTMF capability.
•
setname—Result set name. The name you give to the result set. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
or
Enter the following command to add the RFC 2833 DTMF capability for an A-number:
mml> prov-add:sigsvcprop:name="mgcp1",GWDefaultCodecString="G.711a;PCMA"mml> numan-add:resultset:custgrpid="1111",name="set1"mml> numan-add:resulttable:custgrpid="1111",resulttype="DTMFCAP",dw1="1", setname="set1",name="rt1"mml> numan-add:adigittree:custgrpid="1111",digitstring="1", callside="originating",setname="set1"Add CODEC Provisioning
This section contains the procedures that you must perform to add the CODEC capability to your Cisco MGC provisioning data.
•
Adding CODEC on Dial Plan Level 3
•
Adding CODEC on Dial Plan Level 2
•
Adding CODEC on Dial Plan Level 1
Adding CODEC on Dial Plan Level 3
In this case, CODEC is provisioned on dial plan level 3(dial plan level) and trunkgroup level 2, without DTMCAP provisioning or SDP in the first SIP INVITE. The result is CODEC matches.
To provision this CODEC on dial plan level 3, perform the following steps:
Step 1
numan-add:resultset:custgrpid="1111",name="set1"
Step 2
numan-add:resultset:custgrpid="1111",name="set2"
Step 3
prov-add:codecstring:name="codec1",codecstring="G.729"
Step 4
prov-add:codecstring:name="codec2",codecstring="G.721"
Step 5
numan-add:resulttable:custgrpid="1111",resultype="CODEC",dw1="codec1",dw2="1",setname="set1",
name="rt1"Step 6
numan-add:resulttable:custgrpid="1111",resulttype="CODEC",dw1="codec2",dw2="1",setname="set2",
ame="rt1"Step 7
numan-add:resulttable:custgrpid="1111",name="table10",resulttype="ROUTE",dw1="rtlist1",
setname="set2"Step 8
numan-add:adigittree:custgrpid="1111",digitstring="1",callside="originating",setname="set1"
Step 9
numan-add:resulttable:custgrpid="1111",name="table10",resulttype="ROUTE",dw1="rtlist1",
setname="set2"Step 10
numan-add:bdigittree:custgrpid="1111",digitstring="2",callside="originating",setname="set2"
Adding CODEC on Dial Plan Level 2
In this case, CODEC G.723 is provisioned on dial plan level 2 in ingress SIP trunk group:
prov-add:trnkgrpprop:name="1100",custgrpid="1111",GWDefaultCodecString="G723"
In this case, CODEC G.729 is provisioned on dial plan level 2 in the second egress trunk group:prov-add:trnkgrpprop:name="2200",custgrpid="1111",GWDefaultCodecString="G729"
Adding CODEC on Dial Plan Level 1
CODEC on dial plan level 1 is contained by incoming SDP.
CODEC Matching Rules
Step 1
With the CODEC data you provisioned for the dial plan, use Table 1: to calculate the ingress CODEC result
M = mandatory, P = Preferred
Step 2
After you obtain the ingress CODEC result, use the following table to determine if and how the SDP is modified.
* = any value, M = mandatory, P = Prefer
TRUE = CODEC compatibility, FALSE = CODEC incompatibility.The following example describes how to use these matrices:
Assume the following data has been provisioned:
•
CODEC in A number is provisioned with G.729 and is Preferred
•
CODEC in B number is provisioned with G.721 and is Preferred
•
CODEC provisioned in the ingress trunk group is G.711U
According to Table 1:, the ingress codec for this scenario is G.721;G.729;G.711U;P. This result is used as input for Table 2:. Now assume:
•
the incoming SDP carried with CODEC (G.711U,G.721,G.729)
•
the egress codec is provisioned with G.711U;G.721
According to Table 2:, the egress CODEC differs from the CODEC carried by SDP, so the modification on SDP is true. The CODEC capability is set to the intersect set of ingress CODEC and egress CODEC (in this case, G.721;G.711U). The CODEC in SDP is modified to G.721;G.711U.
There are two steps of SDP modification in this function:
1.
Filter CODEC according to IngressCodec and PrefIngress.
a.
If IngressCodec is NULL, nothing is done.
b.
If IngressPref is PREFER, reorder audio codecs in SDP according to IngressCodec
c.
If IngressPref is MANDATORY, delete all audio codecs which are not in IngressCodec.
2.
Filter CODEC according to CodecEgress.
a.
If EgressCodec is NULL, nothing is done.
b.
Delete all audio codecs which are not in EgressCodec.
If some audio codec exists, the function return TRUE. Otherwise, it returns FALSE.
DTMF Matching Rules
In ingress side, DTMF capability is provisioned in A or B number analysis. If DTMF capability isn't provisioned in either A or B number analysis, DTMF capability in ingress side is set to NULL. In egress side, DTMF capability is provisioned in egress trunkgroup. If DTMF capability in egress trunkgroup is compatible with ingress side, the trunkgroup is selected. Otherwise, next trunkgroup is selected and its DTMF capability is checked again. The following table shows how DTMF in ingress side is compatible with egress side.
* = any type of DTMF (NULL, 2833, out of band DTMF)
Egress DTMF Capability is provisioned in egress trunkgroup
Ingress DTMF Capability is provisioned in A or B number analysis
Modifying Components
The following subsections identify the steps required to modify the provisioning data for this feature.
Modifying DTMF Capability on Trunk Groups
To modify the DTMF capability on an egress trunk group in your provisioning data, perform the following steps:
Step 1
Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 2
Enter the following command to modify the DTMF capability on an egress trunk group:
mml> prov-ed:trnkgrpprop:name="name",DtmfCap="x"Where:
•
name—The name of a previously defined trunk group. The value range is from 1 through 9999.
•
x—The DTMF capacity selection value: 0—Ignore DTMF capability, 1—RFC 2833, or 2—Out of band DTMF capability.
For example, to modify the DTMF capacity on the trunk group named 1111, enter the following command:
mml> prov-ed:trnkgrpprop:name="1111",DtmfCap="1"Step 3
Repeat Step 2 for each trunk group you want to modify the DTMF capability to your provisioning data.
Step 4
If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.
Modifying CODEC Provisioning
To modify the CODEC provisioning data on an egress trunk group, perform the following steps:
Step 1
Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 2
Enter the following command to modify CODEC provisioning on an egress or ingress trunk group:
mml> prov-ed:trnkgrpprop:name="name",Gwdefaultcodecstring="x"Where:
•
name—The name of a previously defined trunk group. The value range is from 1 through 9999.
•
x—Any CODEC name (for example, G.729, G.711U, G.723).
For example, to modify the CODEC on the trunk group named 1111, enter the following command:
mml> prov-ed:trnkgrpprop:name="1111",Gwdefaultcodecstring="G.711U"Step 3
Enter the following command to modify the CODEC provision on a dial plan level:
mml> prov-ed:codecstring:name="name",codecstring="x"Where:
•
name—The name of the CODEC string you provisioned using the prov-add:codecstring command. (for example, codec1).
•
x—Any CODEC name (for example, G.729, G.711U, G.723).
For example, to modify the CODEC string named codec1 provisioned on a dial plan level, enter the following command:
mml> prov-ed:codecstring:name="codec1",codecstring="G729"Step 4
If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.
Deleting Components
The following subsections identify the steps required to delete the provisioning data for this feature.
Deleting DTMF Capability on Trunk Groups
To delete DTMF capability from your provisioning data, perform the following steps:
Step 1
Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 2
Enter the following command to delete the DTMF capability on an egress trunk group:
mml> prov-dlt:trnkgrpprop:name="name","property_name"Where:
•
name—The name of a previously defined trunk group. The value range is from 1 through 9999.
•
property_name—Dtmfcap.
For example, to delete the DTMF capacity on the trunk group named 1111, enter the following command:
mml> prov-dlt:trnkgrpprop:name="1111","DtmfCap"Step 3
Repeat Step 2 for each trunk group from which you want to delete the DTMF capability from your provisioning data.
Step 4
If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.
Deleting CODEC Provisioning
To delete CODEC provisioning data on an egress trunk group, perform the following steps:
Step 1
Start a provisioning session, as described in the "Starting a Provisioning Session" section.
Step 2
Enter the following command to remove CODEC provisioning on an egress or ingress trunk group:
mml> prov-dlt:trnkgrpprop:name="name",GwdefaultcodecstringWhere:
•
name—The name of a previously defined trunk group. The value range is from 1 through 9999.
For example, to delete the CODEC on the trunk group named 1111, enter the following command:
mml> prov-ed:trnkgrpprop:name="1100",GwdefaultcodecstringStep 3
Enter the following command to remove the CODEC string:
mml> prov-dlt:codecstring:name="name"Where:
•
name—The name of the CODEC string to remove
For example, to remove the CODEC string named with codec1, enter the following command:
mml> prov-dlt:codecstring:name="codec1"Step 4
If there are no other components that you need to delete, end your provisioning session as described in the "Saving and Activating your Provisioning Changes" section.
Creating Dial Plan Data
The following sections describe the tasks related to creating a dial plan for this feature:
Dial Plan Prerequisites
This section lists the data that you must gather to successfully create a dial plan as part of this feature. For more information on planning dial plans for other functions of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Preparing Trunk Data
During the provisioning process, all the bearer trunks that connect remote switches to all the media gateways attached to the Cisco MGC were defined. Each remote switch is identified by its destination point code (DPC), and each trunk is identified by its trunk ID or Circuit Identification Code (CIC).
You need the following information for your trunks:
•
Trunk ID—Designation assigned to a trunk.
•
Source Signaling Service—MML name of the previously defined source signaling service.
Valid signaling services are ISDN PRI, DPNSS, or any SS7 signaling service.•
Source Span—Number of circuits assigned to the source span (range 0 through 65535).
•
Source Span ID—Identification assigned to the source span (range 0 through 65535).
•
Source Time Slot/CIC—Time slot or Circuit Identification Code (CIC) (range 0 through 31).
•
Destination Signaling Service—MML name of a previously defined destination signaling service.
Valid signaling services are ISDN PRI, DPNSS, or any SS7 signaling service.•
Destination Span—Number of circuits assigned to the destination span (range 0 through 65535).
•
Destination Span ID—Identification assigned to the destination span (range 0 through 65535).
•
Destination Time Slot/CIC—Time slot or Circuit Identification Code (CIC) (range 0 through 31).
•
Line Type—T1 or E1.
•
Multiple Trunk Field—Number of trunks per span (greater than 0, but less than or equal to 31).
The ingress and egress trunk IDs must match the corresponding trunk IDs used on the remote switches. The circuit identification codes (CIC) are the SS7 values representing the trunks and must also match the CIC values defined at the remote switches.
The destination span ID and destination time slot must match the trunk configuration values defined during Cisco MGC configuration. The destination span ID is defined when configuring T1 and E1 controllers and must match the value of the nfas_int parameter. T1 spans use channels (time slots) 1-24 and E1 spans use time slots (channels) 0-31.
To save space, you might want to specify ranges of trunk IDs for each T1 or E1 connection. For large installations, you should make copies of this table or create your own worksheet with these columns.
Dial Plan Basics
The procedures in this section describe how to add, modify, and delete dial plan data and how to retrieve that data.
•
Modifying an Element of your Dial Plan Data
•
Ending a Provisioning Session Without Activating your Changes
For more detailed information about creating a dial plan for your Cisco MGC, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Adding Dial Plan Data
The order in which you provision dial plan tables is important. Many tables refer to other tables that must be defined first. The following list identifies the recommended sequence for dial plan provisioning:
1.
Create the dial plan file (unique CustGrpID)
2.
Provision Digit Modification
3.
Provision the Service
4.
Provision the Result and Result Sets
5.
Provision the A-numbers and B-numbers
6.
Provision CPC
7.
Provision TMR analysis
8.
Provision B-number NOA and NPI analysis
9.
Provision TNS
10.
Provision NANP B-number normalization
11.
Provision the Location value
12.
Provision the Cause value
13.
Provision the A and B Whitelist and Blacklist screening files
To begin the process of creating a dial plan, log into the active Cisco MGC, start an MML session, and enter the following command:
mml> numan-add:component:custgrpid=cust_groupID,param_name="param_value",...Where:
•
component—The name of the component type you want to add to your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
cust_groupID—Customer group ID number associated with your dial plan.
•
param_name—The name of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid parameters for each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
param_value—The value of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid values for the parameters of each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
For example, to provision a route result type called resultone, you would enter the following command:
mml> numan-add:resulttable:custgrpid="t777",resulttype="route",setname="setone", name="resultone",dw1="rtlistone"Modifying an Element of your Dial Plan Data
To modify an existing dial plan, log into the active Cisco MGC, start an MML session, and enter the following command:
mml> numan-ed:component:custgrpid="cust_groupID",param_name="param_value",...Where:
•
component—The name of the component type you want to modify in your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
cust_groupID—Customer group ID number associated with your dial plan.
•
param_name—The name of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid parameters for each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
param_value—The value of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid values for the parameters of each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
For example, to modify a result table, you would enter the following command:
mml> numan-ed:resulttable:custgrpid="t777",resulttype="route",setname="setone", name="resulttwo",dw1="rtlistone"Deleting an Element from your Dial Plan Data
To delete an element from your dial plan, log into the active Cisco MGC, start an MML session, and enter the following command:
mml> numan-dlt:component:custgrpid="cust_groupID",name="MML_name"Where:
•
component—The name of the component type you want to delete from your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
cust_groupID—Customer group ID number associated with your dial plan.
•
MML_name—The MML name of the selected component you want to delete from your dial plan.
For example, to delete a result set called setone, you would enter the following command:
mml> numan-dlt:resultset:custgrpid="t001",name="setone"Retrieving Dial Plan Data
You can use the numan-rtrv MML command to retrieve information about your current dial plan settings. The ways in which you can use this command to retrieve dial plan data are described in the following sections:
•
Retrieving Data for an Individual Component
•
Retrieving Data for All Components of a Particular Type
Note
You can verify dial plans using the translation verification viewer on the Cisco MGC toolbar. For information on using the translation verification viewer, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Retrieving Data for an Individual Component
You can retrieve dial plan data on any individual component on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml> numan-rtrv:component:custgrpid="cust_groupID",name="MML_name"Where:
•
component—The name of the component type you want to retrieve from your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
cust_groupID—Customer group ID number associated with your dial plan.
•
MML_name—The MML name of the selected component you want to retrieve from your dial plan.
For example, to retrieve the settings for a result set called setone, you would enter the following command:
mml> numan-rtrv:resultset:custgrpid="t001",name="setone"Retrieving Data for All Components of a Particular Type
You can retrieve dial plan data on all components of a particular type on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml> numan-rtrv:component:custgrpid="cust_groupID","all"Where:
•
component—The name of the component type you want to retrieve from your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
•
cust_groupID—Customer group ID number associated with your dial plan.
For example, to retrieve the settings for all result sets in your dial plan, you would enter the following command:
mml> numan-rtrv:resultset:custgrpid="t001","all"Dial Plan Procedures
This section contains the procedures required for provisioning the dial plan data for this feature. For more information on creating dial plans for other functions of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Adding the DTMFCAP Result Type
DTMF capability selection is used during A-number and B-number analysis. You can use the numan-add MML command to add the desired DTMF capability to the dial plan.
Note
This feature adds to the PGW 2200 DTMF capability to allow for route advance when the DTMF type supported does not match the ingress trunk group.
To add DTMF capability, complete the following steps:
Step 1
Log into the active Cisco MGC, start an MML session, and enter the following command to add a dial plan:
mml> numan-add:dialplan:custgrpid="dpl1",overdec="yes"Step 2
Enter the following command to add a result set:
mml> numan-add:resultset:custgrpid="dpl1",name="set1"Step 3
Enter the following command to add a result table:
mml> numan-add:resulttable:custgrpid="dpl1",resulttype="DTMFCAP",dw1="0",setname="set1", name="rt1"Step 4
Enter the following command to add an A-number digit string:
mml> numan-add:adigittree:custgrpid="dpl1",digitstring="703484",callside="originating", setname="set1"Where:
•
custgrpid—Customer group ID. A 4-digit alphanumeric string (enclosed in straight quotes) to identify the dial plan.
•
overdec—Over decadic. A 2- or 3-character string that identifies the overdecadic dial plan status. Valid values are: yes (overdecadic) or no (decadic).
•
resulttype—Result type. Indicates the result type being provisioned. Any valid result type name is allowed. The result type for this feature is DTMFCAP.
–
dwx—Dataword. Indicates the dataword being provisioned, where x takes a value of 1. Dataword values for the DTMFCAP result type are: 0—Ignore DTMF capability, 1—RFC 2833, or 2—Out of band DTMF capability. (For example, dw1="0")
•
setname—Result set name. The name you give to the result set. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
•
name—Name. The name you give to the component. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
•
digitstring—Digit string. Identifies the digit string, either the A-number or the B-number, to which the result type is being applied.
•
callside—Calling side. Identifies the calling side of the call, either the originating or the terminating, side to which the result type is being applied.
Step 5
To verify the command was executed successfully, enter the command:
mml> numan-rtrv:adigtree:custgrpid="dpl1",callside="originating",digitstring="703484"MGC-01 - Media Gateway Controller 2006-02-28 01:19:05.685 ESTM RTRV''session=0227:dialplan''/*CustGrpId OverDecadic--------- -----------1111 YESStep 6
Repeat steps 3 and 4, as necessary, to add new rows and new DTMFCAP results to the result table.
Modifying the DTMFCAP Result Type
DTMF capability selection is used during A-number and B-number analysis. You can use the numan-ed MML command to modify the desired DTMF capability.
To modify the DTMF capability, complete the following steps:
Step 1
Log into the active Cisco MGC, start an MML session, and enter the following command to modify the DTMF capability:
Step 2
Enter the following command to add an A-number digit string:
mml> numan-ed:resulttable:custgrpid="dpl1",resulttype="DTMFCAP",dw1="1",setname="set1", name="rt1"Where:
•
custgrpid—Customer group ID. A 4-digit alphanumeric string (enclosed in straight quotes) to identify the dial plan.
•
resulttype—Result type. Indicates the result type being provisioned. Any valid result type name is allowed. The result type for this feature is DTMFCAP.
•
dwx—Dataword. Indicates the dataword being provisioned, where x can be a value from 1 through 4. Dataword values for the DTMFCAP result type are: 0—Ignore DTMF capability, 1—RFC 2833, or 2—Out of band DTMF capability.
•
setname—Result set name. The name you give to the result set. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
•
name—Name. The name you give to the component. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
Step 3
To verify the command was executed successfully, enter the command:
mml> numan-rtrv:adigtree:custgrpid="dpl1",callside="originating",digitstring="703484"MGC-01 - Media Gateway Controller 2006-02-28 01:19:05.685 ESTM RTRV''session=0227:dialplan''/*CustGrpId OverDecadic--------- -----------1111 YESStep 4
Repeat steps 2 and 3, as necessary, to modify the DTMF capability for each result set.
Deleting the DTMFCAP Result Type
DTMF capability selection is used during A-number and B-number analysis. You can use the numan-dlt MML command to delete the desired DTMF capability.
To delete the DTMF capability, complete the following steps:
Step 1
Log into the active Cisco MGC, start an MML session, and enter the following command to delete the DTMF capability:
Step 2
Enter the following command to delete the result set from the result table:
mml> numan-dlt:resulttable:custgrpid="dpl1",setname="set1",name="rt1"Where:
•
custgrpid—Customer group ID. A 4-digit alphanumeric string (enclosed in straight quotes) to identify the dial plan.
•
setname—Result set name. The name you give to the result set. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
•
name—Name. The name you give to the component. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.
Step 3
To verify the command was executed successfully, enter the command:
mml> numan-rtrv:dialplan:"all"Step 4
Repeat step 2, as necessary, to delete the DTMF capability from each result set.
Provisioning Examples
This section provides a provisioning examples for this feature. Additional provisioning examples for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
________________________________________; Add MGCP GWDefaultCodecString value on MGCP signaling path;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;prov-add:sigsvcprop:name="mgcp1",GWDefaultCodecString="G.711a;PCMA"________________________________________; Add ignore DTMF capability on an egress trunk group;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;prov-add:trnkgrpprop:name="1111",DtmfCap="0"________________________________________; Add RFC 2833 DTMF capability on an egress trunk group;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;prov-add:trnkgrpprop:name="1111",DtmfCap="1"________________________________________; Add out of band DTMF capability on an egress trunk group;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;prov-add:trnkgrpprop:name="1111",DtmfCap="2"________________________________________; Modify DTMF capability on an egress trunk group from RFC 2833 to Out of Band;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;prov-add:trnkgrpprop:name="1111",DtmfCap="1"prov-ed:trnkgrpprop:name="1111",DtmfCap="2"________________________________________; Delete DTMF capability on an egress trunk group;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;prov-dlt:trnkgrpprop:name="1111","DtmfCap"________________________________________; Add ignore DTMF capability in A-number analysis;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;numan-add:resultset:custgrpid="1111",name="set1"numan-add:resulttable:custgrpid="1111", resulttype="DTMFCAP",dw1="0",setname="set1",name="rt1"numan-add:adigittree:custgrpid="1111",digitstring="1",callside="originating", setname="set1"________________________________________; Add RFC 2833 DTMF capability in A-number analysis;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;numan-add:resultset:custgrpid="1111",name="set1"numan-add:resulttable:custgrpid="1111", resulttype="DTMFCAP",dw1="1",setname="set1",name="rt1"numan-add:adigittree:custgrpid="1111",digitstring="1",callside="originating", setname="set1"________________________________________; Provisioning out of band DTMF capability in B-number analysis;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;numan-add:resultset:custgrpid="1111",name="set1"numan-add:resulttable:custgrpid="1111", resulttype="DTMFCAP",dw1="2",setname="set1",name="rt1"numan-add:bdigittree:custgrpid="1111",digitstring="1",callside="originating", setname="set1"________________________________________; Modify DTMF capability in B-number analysis from RFC 2833 to Out of Band;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;numan-add:resultset:custgrpid="1111",name="set1"numan-add:resulttable:custgrpid="1111", resulttype="DTMFCAP",dw1="1",setname="set1",name="rt1"numan-add:bdigittree:custgrpid="1111",digitstring="1",callside="originating", setname="set1"numan-ed:resulttable:custgrpid="1111",setname="set1",name="rt1",resulttype="DTMFCAP", dw1="2"________________________________________; Delete DTMF capability in B-number analysis;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;numan-dlt:resulttable:custgrpid="1111",setname="set1",name="rt1"________________________________________; Provisioning CODEC List Comparison for Route Advance;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; add result setnuman-add:resultset:custgrpid="1111",name="set1"numan-add:resultset:custgrpid="1111",name="set2"; add codec stringprov-add:codecstring:name="codec1",codecstring="G.729"prov-add:codecstring:name="codec2",codecstring="G.721"; add codec result typenuman-add:resulttable:custgrpid="1111",resulttype="CODEC",dw1="codec1",dw2="1", setname="set1",name="rt1"numan-add:resulttable:custgrpid="1111",resulttype="CODEC",dw1="codec2",dw2="1", setname="set2",name="rt1"; add route result tablenuman-add:resulttable:custgrpid="1111",name="table10",resulttype="ROUTE",dw1="rtlist1", setname="set2"numan-add:adigittree:custgrpid="1111",digitstring="1",callside="originating", setname="set1"numan-add:resulttable:custgrpid="1111",name="table10",resulttype="ROUTE",dw1="rtlist1", setname="set2"; add b-digitnuman-add:bdigittree:custgrpid="1111",digitstring="4444",callside="originating", setname="set2"; add ingress trunkgroup codec propertyprov-ed:trnkgrpprop:name="2222",gwdefaultcodecstring="G729_A"; add egress trunkgroup codec property prov-ed:trnkgrpprop:name="4444",gwdefaultcodecstring="G711_U"Command Reference
This section documents modified Man-Machine Language (MML) commands. All other MML commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide.
New MML Commands
This section contains the MML commands that were added for the CODEC and DTMF Preferential Routing Enhancements feature.
PROV-ADD/DLT/ED:DtmfCap—Provision the DTMF Capability of an Egress Trunk Group
Reference Information
The following sections contain reference material related to this feature. Information is included on the following areas:
Properties
The properties in this section are used for this feature. For information on other properties for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
The parent objects for the properties involved in this feature are found in Table 1.
Table 1 Software Properties Related to this Feature
Property Name Parent Object AVM DPNSS EISUP IOCC ISDNPRI MGCP RLM SESSION SGCP SIP SS7-ANSI SS7-China SS7-ITU SS7-Japan SS7-UK TALI-IOCC TCAPOverIP TrunkGroup VSIDtmfCap
X
X
X
The property used for this feature is described in Table 2 and the dynamically provisionable status is listed in Table 3.
Note
The two properties listed below are existing properties whose definition was modified for this feature. The valid values and default values have not changed.
Result Type Definitions
Result analysis provides the capability to group actions into result sets that can be attached at different points of analysis. The main attachment points are: Pre-analysis, A-number analysis, B-number analysis, and Cause analysis.
The following result type definitions are added, modified, or deleted for this feature. For information on other result type definitions for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Table 4 shows the result type added for this feature.
Result Type Definitions
The following paragraphs contain definitions of the result types listed in Table 4.
DTMFCAP
The DTMF result type is returned from A-number or B-number analysis indicating the DTMF capability of the number in the dial plan. This result type can be encountered during A-number or B-number analysis and indicates the DTMF capability of the associated number in the dial plan. DTMF capability on B-number analysis overrides DTMF capability on A-number analysis.
Valid DTMFCAP dataword1 values are:
The DTMF capability of egress trunk group. Valid values:
•
0—Ignore DTMF capability
•
1—RFC 2833 DTMF capability
•
2—Out of band DTMF capability
Provisioning Worksheets
This section contains worksheets for the provisioning components required for this feature. For worksheets covering the rest of the provisioning components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Table 5 DtmfCap Worksheet Example
Name DTMF Capacity Description11l1
RFC 2388
DTMF capacity for 1111
Dial Plan Worksheets
This section contains worksheets for the dial plan components required for this feature. For worksheets covering the rest of the dial plan components in the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Table 6 DTMFCAP Result Type Worksheet Example
CustgrpId Result Type DW1 Set Name Digitstring1111
DTMFCAP
1
set1
703484
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Glossary
Table 7 contains definitions of acronyms and technical terms used in this feature module.
This document is to be used in conjunction with the documents listed in the Related Documents section.
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.



