-- not used -- Cisco Media Gateway Controller Software Release 9 Provisioning Guide
Chapter 5 Adding System Components with MML
Downloads: This chapterpdf (PDF - 1.13MB) The complete bookPDF (PDF - 9.74MB) | Feedback

Adding Components with MML

Table Of Contents

Adding Components with MML

Adding SS7 Signaling Route Components

Adding a Destination Point Code

Adding Multiple OPCs

Understanding Point Code Addressing

14-Bit Address (ITU)

16-Bit Address (Japan)

24-Bit Address (ANSI and China)

Cisco PGW 2200 Softswitch Point Code Storage

Adding an Adjacent Point Code

Adding a Linkset

Adding a Linkset Property

Adding an SS7 Subsystem

Adding Subsystem Numbers

Adding an SS7 Route

Adding an SS7 Signaling Service

Adding a FAS Signaling Service

Adding Signaling Link Components

Adding an Interface Card

Adding an Ethernet Interface

Adding a C7 IP Link

Adding a TDM Interface

Adding a TDM Link

Adding Media Gateway Control Links

Adding an External Node

Adding a Card

Adding an Ethernet Interface

Adding an E-ISUP Signaling Service

Adding an IPFAS Transport Service

Adding an MGCP Signaling Service

Modifying an MGCP Signaling Service Property

Adding a NAS Signaling Service

Adding an IP Link

Adding a Session Set

Adding D-channels

Adding ISDN BRI Backhaul Connections

Adding IUA Connections

Verifying Next Hop Parameter Configuration

Adding Cisco Access Server External Nodes

Adding NAS Signaling Services

Adding IP Routes (Optional)

Adding SCTP Associations

Adding DPNSS Connections

Verifying Next Hop Parameter Configuration

Adding Cisco Access Server External Nodes

Adding IP Routes (Optional)

Adding SCTP Associations

Adding DPNSS Signaling Services

Adding DPNSS Supplementary Services

Adding Trunks, Trunk Groups, and Routing

Adding Files

Adding a Nailed Trunk (Bearer Channel)

Adding a Trunk Group

Adding Mapping to Multiple Trunk Groups

Routing

Provisioning Reserving Incoming Bandwidth

Provisioning Bearer Capability

Provisioning Least Cost Routing

Overriding the Trunk Group Property

Enabling Overdecadic 32 Digit Operation

Provisioning the Generic LNP Protocol Enhancements: 32 Digits, Overdecadics, and Cause 14 Mapping Feature

Verifying the Generic LNP Protocol Enhancements: 32 Digits, Overdecadics, and Cause 14 Mapping Feature

Provisioning SUBSCRIBE/NOTIFY Methods

Enabling SUBSCRIBE/NOTIFY Methods

Disabling SUBSCRIBE/NOTIFY Methods

Provisioning Unsolicited Notifications

Enabling Unsolicited Notifications

Disabling Unsolicited Notifications

Provisioning Subscription Duration

Provisioning Minimum Subscription Duration for Telephony Event

Provisioning Maximum Duration for SUBSCRIBE

Enabling/Disabling Information Extraction from SDP

Enabling Support of Information Extraction from Sockets Direct Protocol (SDP)

Disabling Support of Information Extraction from SDP

Adding a Switched Trunk (Multiple Switched Trunks)

Retrieving Multiple Switched Trunks

Adding Multiple Nailed Trunks

Retrieving Multiple Nailed Trunks

Adding Multiple Trunk Groups and Bearer Channels

Removing Multiple Trunk Groups and Bearer Channels

Creating a Profile

Adding a Trunk Group Profile

Deleting a Trunk Group Profile

Adding an ISUP Timer Profile

Suppressing Caller ID in a SIP Environment

Adding an ATM Profile

Provisioning ATM Profiles

Provisioning ATM Profiles Result Types

Provisioning Trunk Group Properties

Provisioning SigPath Properties

Adding SIP Components

Adding a SIP Signaling Service

Adding a SIP Signaling Link

Adding a SIP Trunk Group

Adding SIP Trunk Group Properties

Adding Mapping to Multiple IP Trunks

Adding SIP Routing Trunk Group Properties

Adding SIP Domain Name System Properties

Modifying a SIP Signaling Service

Modifying Session Timers

Modifying Session Timer for Incoming SIP Trunk Groups

Modifying Session Timer for Outgoing SIP Trunk Groups

Adding Dual Presentation CLI

Adding Automatic Switchover Using Dual-VLAN

Verifying Parameter Settings and Re-configuring Cisco PGW 2200 Softswitch Software

Enabling SIP Automatic Switchover Using Dual-VLAN

Disabling SIP Automatic Switchover Using Dual-VLAN

Adding SIP-T and SIP-GTD Support

Adding SIP-T and SIP-GTD Support

Enabling the Early Backward ISUP Message

GTD NOA Override

GTD Provisioning Examples

NOA Configurable Mapping

Provisioning the NOA Configurable Mapping Feature

Adding an NOA Value to the LineXlate File for Inbound Calls

Deleting an NOA Value from the LineXlate File

Adding an NOA Value to the LineXlate File for Outbound Calls

Deleting an NOA Value from the LineXlate File

Validation Rules

Adding M3UA and SUA Connections

Adding a Cisco ITP External Node

Adding Point Codes (OPC, DPC, and APC)

Adding M3UA and SUA Routing Keys

Adding SS7 Signaling Services

Adding M3UA and SUA Routes

Adding SS7 Subsystems

Adding M3UA and SUA Signaling Gateway Processes

Adding IP Routes (optional)

Adding SCTP Associations

Optimizing PGW-to-ITP Routing with MAP Query

Adding Location Labels

Adding Location Labels to Trunk Groups and Sigpaths

Applying Call Limiting Over DPNSS

Applying Call Limiting to Incoming and Outgoing Trunk Groups

B-number Based Call Limiting Scenario

Applying Call Limiting to a SIP Trunk Group

Applying Call Limiting to an H.323 Trunk Group

Applying Call Limiting to the DPNSS Trunk Groups

Applying Call Limiting to an SS7 ISUP Trunk Group

Applying Call Limiting to Digit Strings in a Dial Plan

Applying Call Limiting to Multiple Trunk Groups

Applying Call Limiting to IP Addresses

Applying Call Limiting to an MGCP Gateway

Playing an Announcement when the Call Limiting Threshold is Exceeded

Scaling System Components

Dynamically Configuring the Input/Output Channel Controller

Provisioning Examples

Configuring Two IP Addresses on the MGW to One IP Address on a NAS

A-number Country Code Digit Removal

Call Reporting

CODEC Capabilities and DTMF Preferential Routing

Digit Buffering for International Gateways

DPNSS Service Interworking with Cisco CallManager Over QSIG Tunneling

Provisioning Route Optimization Transit

Provisioning Route Optimization Initiated by the Cisco PGW 2200 Softswitch

Provisioning Route Optimization Responded by the Cisco PGW 2200 Softswitch

Provisioning Call Completion

Provisioning Message Waiting Indicator (with no QSIG Tunneling)

Provisioning Message Waiting Indicator (with QSIG Tunneling)

Provisioning a Customer VPN ID in a Trunk Group

Provisioning a Customer VPN ID in the Dial Plan

Provisioning Feature Transparency on QSIG Trunk Groups or sigPaths

Provisioning an H.323 EISUP Trunk Group or sigPaths for Transparent Annex M1 (Tunneled QSIG)

Enhanced Local Number Portability and Dial Plan Selection

Full Number Translations

Global Titles

Provisioning H.248 Protocol

Lawful Intercept

Provisioning LI for the Service Provider

Provisioning a Wiretap Entry for the Medication Device

Location Mapping

Provisioning Location Values

Provisioning Internal Cause Value Mapping

Provisioning Cause Value Mapping

Cause Value Mapping Based on Received Cause and Location Values

Cause and Location Value Mapping to Different Values

Cause Value Mapping to Different Cause and Location Values

Multiple Inbound IP Trunks

Creating a New Inbound SIP Trunk

Creating a New Inbound ISUP Trunk

Support of HSI Non-RAS Mode

Provisioning Cisco PGW 2200 Softswitch

Provisioning Cisco HSI

Presentation Number Modification

Provisioning PN Modification for PSTN to SIP Calls

Provisioning PN Modification for PSTN to SIP Calls

RADIUS Enhancement for Accounting

SIP and ISUP Interworking for Call Hold and Terminal Portability

SIP Overlap Signaling

SIP Remote Party ID and P-Asserted Support

SIP Service Handling and Feature Interworking Enhancement

Take Back and Transfer

QoS for Signaling Traffic


Adding Components with MML


Revised: February 25, 2010, OL-1110-23

This chapter describes how to add components, describes how to verify the addition of the components, and gives tips that can help you solve problems. It includes the following sections:

Adding SS7 Signaling Route Components

Adding Signaling Link Components

Adding Media Gateway Control Links

Adding Trunks, Trunk Groups, and Routing

Adding SIP Components

Adding SIP-T and SIP-GTD Support

Adding Location Labels

Scaling System Components

Provisioning Examples

Before starting an actual configuration, see Chapter 2 "Planning for Provisioning" for instructions and worksheets for configuring your system. That chapter describes the system components that can be configured on the Cisco PGW 2200 Softswitch. Each component has a specified type, name, and description, and may have additional configuration parameters.

When adding components, add the components in the following order.

Add external nodes for each device connected to the network

Add point codes (OPC, DPC, and APC)

Add the interface cards

Add SS7 signaling service

Add media gateway signaling service

Add linksets

Add C7 IP links (redundant)

Add links (IP or SIP)

Add SS7 routes

Add SS7 subsystem

Add trunks (x24 or x31)

This chapter also provides basic provisioning procedures for the following features on the Cisco PGW 2200 Softswitch Release 9.7(3):

A-number Country Code Digit Removal

Call Reporting

CODEC Capabilities and DTMF Preferential Routing

Digit Buffering for International Gateways

DPNSS Service Interworking with Cisco CallManager Over QSIG Tunneling

Enhanced Local Number Portability and Dial Plan Selection

Full Number Translations

Global Titles

Provisioning H.248 Protocol

Lawful Intercept

Location Mapping

Multiple Inbound IP Trunks

Support of HSI Non-RAS Mode

Presentation Number Modification

RADIUS Enhancement for Accounting

SIP and ISUP Interworking for Call Hold and Terminal Portability

SIP Overlap Signaling

SIP Remote Party ID and P-Asserted Support

SIP Service Handling and Feature Interworking Enhancement

Take Back and Transfer

QoS for Signaling Traffic

Adding SS7 Signaling Route Components

Your first task is to configure SS7 signaling routes that link the Cisco PGW 2200 Softswitch to the SS7 network nodes (signaling points). This process is described in the following sections:

Adding a Destination Point Code

Adding an Adjacent Point Code

Adding a Linkset

Adding an SS7 Subsystem

Adding an SS7 Route

Adding an SS7 Signaling Service

Adding a FAS Signaling Service


Note When provisioning, fully define all components before deploying a configuration.


To add a component, do the following:


Step 1 Start an MML session.

Step 2 Start a provisioning session as described in the"Starting a Provisioning Session" section. The source configuration that you chose during startup determines the configuration to which you can add components.

Step 3 Enter the following command:

mml> prov-add:componentType:name="name",desc="description",paramName=value 
 
   

Where:

componentType is the type of component you want to create,

description is the long name assigned that can be as many as 128 alphanumeric characters in length.

name is the name you want to give to the component. The name can be as many as 20 characters long and can contain numbers, letters, and the dash (-) symbol.

value is the parameter value of the component.


Adding a Destination Point Code

A point code is an SS7 network address that identifies an SS7 network node, such as a switch, SCP, STP, or SSP. Its MML name is DPC. A point code can be the Cisco PGW 2200 Softswitch originating point code (OPC), the adjacent point code (APC), or the destination point code (DPC) of a remote node with which the Cisco PGW 2200 Softswitch communicates.


Note For information on point code parameters, refer to Table 2-2.


To add a destination point code to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:dpc:name="dpc1",netaddr="214.110.80",netind=2,desc="dpc1"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:dpc:name="dpc2",netaddr="214.110.90",netind=2,desc="Dest Switch 1"
 
   

Step 3 Use the PROV-RTRV command to verify the OPC was added.



Tip Point codes provide the addressing scheme for the SS7 network. ITU point codes are 14 bits long, and ANSI point codes are 24 bits long.


Adding Multiple OPCs

Depending on your system configuration, you may have to assign more than one OPC to a single Cisco PGW 2200 Softswitch. When adding multiple OPCs, keep the following information in mind.

ITU point codes contain 14 bits and ANSI point codes contain 24 bits.


Note Use care when provisioning point codes since they are not checked in the provisioning session.


A maximum of 6 true OPCs can be supported per Cisco PGW 2200 Softswitch.

For each true OPC, there can be a maximum of 8 capability OPCs.

For each OPC added, you must specify a different local port number for each C7 IP link on the same interface.

For each OPC added, you must create a duplicate DPC with a different name but with the same point code.

Enter the OPC before creating the C7 IP link.

When specifying a local port number, it must be greater than 1024 (for example, 7000).

Each OPC requires its own linkset (a linkset cannot be shared by 2 OPCs).

A maximum of 2 Session Manager sessions (1 active and 1 standby) can be supported per Cisco PGW 2200 Softswitch (1 session per link).

A maximum of 192 links can be supported per Cisco PGW 2200 Softswitch.

A maximum of 16 linksets can be included per Control Channel.

A maximum of 4096 DS0s (CICs) can be supported per OPC-DPC pair for ITU or a maximum of 16, 384 DS0s (CICs) for ANSI.

To add another point code to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:opc:name="opc1",desc="OPC1",netaddr="1.2.1",netind=2,type="trueopc"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:opc:name="opc1a",desc="CAPOPC",netaddr="1.2.2",netind=2,type="capopc", 
trueopc="opc1"
 
   

Step 3 Use the PROV-RTRV command to verify the OPC was added.


Due to the number of commands involved to add an additional OPC, the commands have been included in the following series of commands.

prov-sta::srcver="new",dstver="2lnks11"
prov-add:card:name="hme0",type="EN",slot=0,desc="Ethernet Card 1"
prov-add:enetif:name="enif1",desc="Ethernet Interface",card="hme0"
prov-add:card:name="hme1",type="EN",slot=1,desc="Ethernet Card 2"
prov-add:enetif:name="enif2",desc="Ethernet Interface",card="hme1"
prov-add:opc:name="opc1",netaddr="1.2.1",netind=2,desc="OPC1",type="trueopc"
prov-add:opc:name="opc1a",netaddr="1.2.2",netind=2,desc="OPC1",type="capopc",trueopc="opc1"
prov-add:dpc:name="dpc1",netaddr="2.2.2",netind=2,desc="DPC1"
prov-add:dpc:name="dpc2",netaddr="1.1.2",netind=2,desc="DPC2"
prov-add:dpc:name="apc1",netaddr="3.3.3",netind=2,desc="apc1"
prov-add:dpc:name="apc2",netaddr="3.3.2",netind=2,desc="apc2"
prov-add:ss7path:name="c7s-1",desc="C7 Service to 
INET",mdo="ANSISS7_STANDARD",dpc="dpc1",custgrpid="1122",side="network",opc="opc1"
prov-add:ss7path:name="c7s-2",desc="C7 Service to 
SIM",mdo="ANSISS7_STANDARD",dpc="dpc2",custgrpid="1122",side="network",opc="opc1"
prov-add:lnkset:name="ls-1",desc="Linkset 1",apc="dpc1",type="IP",proto="SS7-ANSI"
prov-add:lnkset:name="ls-2",desc="Linkset 2",apc="dpc2",type="IP",proto="SS7-ANSI"
prov-add:EXTNODE:NAME="va-2600-stim1",DESC="stim1-2600 SLT",TYPE="SLT"
prov-add:SESSIONSET:NAME="c7-2600-1",EXTNODE="va-2600-stim1",IPADDR1="IP_Addr1",PEERADDR1="192.0.2.5",PORT=70
00,PEERPORT=7000,NEXTHOP1="0.0.0.0",NETMASK1="255.255.255.0",TYPE="BSMV0"
prov-add:EXTNODE:NAME="va-2600-stim2",DESC="stim1-2600 SLT",TYPE="SLT"
prov-add:SESSIONSET:NAME="c7-2600-2",EXTNODE="va-2600-stim2",IPADDR1="IP_Addr1",PEERADDR1="192.0.2.6",PORT=70
00,PEERPORT=7000,NEXTHOP1="0.0.0.0",NETMASK1="255.255.255.0",TYPE="BSMV0"
prov-add:ss7route:name="r1",opc="opc1",dpc="dpc1",lnkset="ls-1",pri=1,desc="SS7 Route"
prov-add:ss7route:name="r2",opc="opc1",dpc="dpc2",lnkset="ls-2",pri=1,desc="SS7 Route"
prov-add:c7iplnk:name="ip-ch1",pri=1,slc=0,lnkset="ls-1",desc="INET SS7",timeslot=0,sessionset="c7-2600-1"
prov-add:c7iplnk:name="ip-ch2",pri=1,slc=1,lnkset="ls-1",desc="INET SS7",timeslot=1,sessionset="c7-2600-1"
prov-add:c7iplnk:name="ip-ch3",pri=1,slc=3,lnkset="ls-2",desc="SIM SS7",timeslot=0,sessionset="c7-2600-2"
prov-add:c7iplnk:name="ip-ch4",pri=1,slc=4,lnkset="ls-2",desc="SIM SS7",timeslot=1,sessionset="c7-2600-2"
prov-add:trnkgrp:name="1",svc="c7s-1",type="TDM_ISUP",selseq="MIDL",clli="trk-1"
prov-add:trnkgrp:name="2",svc="c7s-2",type="TDM_ISUP",selseq="MIDL",clli="trk-2"
prov-add:extnode:name="mgcp1",type="CAT8510",desc="SIM"
prov-add:mgcppath:name="mgcpsvc1",extnode="mgcp1",desc="MGCP to SIM"
prov-add:iplnk:name="mgcplk1",ipaddr="IP_Addr2",port=2427,pri=1,peeraddr="192.0.2.10",peerport=2427,svc="mgcp
svc1",desc="IP Link for MGCP"
prov-add:switchtrnk:name="01",trnkgrpnum="1",span="ffff",cic=1,cu="mgcp1",endpoint="s1/ds1-1/1@inet",spansize
=24
prov-add:switchtrnk:name="02",trnkgrpnum="2",span="ffff",cic=1,cu="mgcp1",endpoint="s1/ds1-2/1@sim",spansize=
24
prov-add:rttrnkgrp:name="1",type=1,reattempts=3,queuing=0,cutthrough=1
prov-add:rttrnk:name="rt1",trnkgrpnum=1
prov-add:rtlist:name="rtlist1",rtname="rt1"
prov-add:rttrnkgrp:name="2",type=1,reattempts=3,queuing=0,cutthrough=1
prov-add:rttrnk:name="rt2",trnkgrpnum=2
prov-add:rtlist:name="rtlist2",rtname="rt2"
prov-cpy
prov-stp

Understanding Point Code Addressing

Point codes are used in SS7 networks as addresses for each element. The following three different point code address lengths are used in SS7 networks.

14-bit address

16-bit address

24-bit address

Each point code addressing type has unique formats that are used to provide a structure for the network, where the lowest order bits in the address identify a particular signaling point, the highest order bits identify the wider "zone", and the bits in-between identify an "area" or "network." For example, ANSI SS7 uses 24-bit addresses with a format of 8-bits for each field (8-8-8).


Note An exception to this is found in Japanese ISUP, in which the order is reversed (that is, the lowest order bits identify the wider "zone" and the highest order bits identify a particular signaling point).



Note Another exception is found in some National ITU SS7 variants, where there may be more or less than three fields used in the point code format. However, the ordering concept for the bits (bits in lower order fields are lower in the network hierarchy) still applies.


You can find more information about point code addressing and how it is handled in the Cisco PGW 2200 Softswitch software in the following sections:

14-Bit Address (ITU)

16-Bit Address (Japan)

24-Bit Address (ANSI and China)

Cisco PGW 2200 Softswitch Point Code Storage

14-Bit Address (ITU)

The 14-bit address is used to identify point codes in countries that conform to the ITU SS7 recommendations. In ITU SS7 networks, there are two types of point code: International and National. International point codes always conform to the format (3-bits/8-bits/3-bits or 3-8-3) defined in ITU Recommendation Q.704, which is illustrated in Figure 5-1. There are many formats used to define National point codes. For example, the Singapore National point code format is 6-4-4. The formats for National point codes are defined in each ITU SS7 National variant recommendation.

Figure 5-1 14-bit Address Point Code Format - International Point Code

13

12

11

10

9

8

7

6

5

4

3

2

1

0

Zone identification
3 bits

Area/network identification
8 bits

Signaling point identification
3 bits


The decimal value of the maximum point code for an International 14-bit address is 7.255.7. The decimal value of the maximum point code for a National 14-bit address varies. For a Singapore National point code maximum value would be 63.15.15.


Note When you provision an ITU point code on the Cisco PGW 2200 Softswitch, you must use the International point code format. If the point code provided to you is in a National point code format, convert the point code into International format using the procedure in "Converting National Point Codes To International Point Code Values" section.


Converting National Point Codes To International Point Code Values

The key to converting ITU National point codes to ITU International point code values is knowing the format of the National point codes, which can be found in the National SS7 variant recommendations.

To convert an ITU National point code to an International point code value, perform the following steps:


Step 1 Convert the decimal value of the National point code into binary, using the associated point code format as a reference.


Note If you do not know the format for a National point code, you must consult the recommendations for that National SS7 variant.


For example, if you wanted to convert a Singapore National point code of 54-3-3 to its binary value, you would apply the Singapore National point code format, which is 6-4-4. This would result in a binary value of 110110.0011.0011 or 11011000110011, with the National point code format removed.

Step 2 Apply the International point code format to the binary number, and convert back to decimal.

Staying with the above example, you would apply the International point code format, which is 3-8-3, to the binary value 11011000110011, or 110.11000110.011. This would result in a decimal value of 6.198.3.


16-Bit Address (Japan)

A 16-bit address is used to identify point codes in Japan. There are two standards agencies in Japan, the Telecommunications Technology Committee (TTC) and Nippon Telephone and Telegraph (NTT). The 16-bit address point code format is defined in the JT-Q704 and NTT-Q704-b recommendations. These documents divide the point code into three fields (7-4-5), as seen in Figure 5-3.

Figure 5-2 16-bit Address Point Code Format

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

Signaling point identification
(Unit Number)
7 bits

Area/network identification
(Sub Number Area)
4 bits

Zone identification
(Main Number Area)
5 bits


The TTC recommendation (JT-Q704) uses the same terminology to describe the sub-fields as the ITU Recommendation Q.704. The NTT recommendation (NTT-Q704-b) uses unique terms for these sub-fields. The NTT names for these sub-fields appear in Figure 5-2 in parenthesis.


Note Point codes in the Cisco PGW 2200 Softswitch software are all provisioned in the zone.area/network.signaling point format. When you provision a point code for Japanese ISUP on the Cisco PGW 2200 Softswitch, the order of the fields must be reversed to match that format. For example, if you want to connect to a destination that uses Japanese ISUP with a point code of 78.9.20, you would provision a DPC on the Cisco PGW 2200 Softswitch with a point code of 20.9.78. The Cisco PGW 2200 Softswitch transmits the DPC address in the correct order (78.9.20).


The decimal value of the maximum point code for a 16-bit address is 127.15.31. However, since Japanese point code values must be reversed when provisioned on the Cisco PGW 2200 Softswitch, the maximum point code value you can provision is 31.15.127.

24-Bit Address (ANSI and China)

The 24-bit address is used to identify point codes in China and countries that conform to the ANSI SS7 recommendations. The 24-bit address is divided into three 8-bit fields (8-8-8), as defined in the Chinese GF001-9001 and ANSI T1.111.4 recommendations, which can be seen in Figure 5-3.

Figure 5-3 24-bit Address Point Code Format

23

22

21

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

Zone identification
(Network Octet)
8 bits

Area/Network identification (Cluster Octet)
8 bits

Signaling Point identification (Member Octet)
8 bits


The Chinese GF001-9001 recommendation uses the same terminology to describe the sub-fields as the ITU Recommendation Q.704. The ANSI T1.111.4 recommendation (uses unique terms for these sub-fields. The ANSI names for these sub-fields appear in Figure 5-3 in parenthesis.

The decimal value of the maximum point code for a 24-bit address is 255.255.255.

Cisco PGW 2200 Softswitch Point Code Storage

The Cisco PGW 2200 Softswitch uses a 32-bit field to store point code addresses. When you provision a point code on the Cisco PGW 2200 Softswitch, the format used depends upon the associated protocol. The Cisco PGW 2200 Softswitch software pads the unused bits in the field with zeros when the point code is saved.

For example, if you provisioned a DPC of 6.198.3 for an ITU SS7 network, it would have a binary equivalent of 110.11000110.011, and would be stored in the Cisco PGW 2200 Softswitch as 00000000000000000011011000110011.

Adding an Adjacent Point Code

An adjacent point code (APC) defines an SS7 STP through the Cisco PGW 2200 Softswitch to which it is connected. The APC is the SS7 network address of the STP. Its MML name is APC.

For information on point code parameters, refer to Table 2-2.

To add an APC to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:apc:name="STP-A",netaddr="214.111.0",desc="STP A pointcode",netind=2, 
type="trueopc"
 
   

Use the PROV-RTRV command to verify the APC was added.

Adding a Linkset

A linkset is the group of all signaling links between two point codes. Its MML name is LNKSET. For information on linkset parameters, refer to Table 2-3.

To add a linkset to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:lnkset:name="linkset1",desc="linkset 1 to STP-A",apc="STP-A",type="IP", 
proto="SS7-ANSI"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:lnkset:name="linkset2",desc="linkset 2 to STP-B",apc="STP-B",type="IP", 
proto="SS7-ANSI"
 
   

Step 3 Use the PROV-RTRV command to verify the linkset was added.



Tip Setting up linksets is a two-step process that consists of first adding the linkset and then adding links to the linkset.


Adding a Linkset Property

Linksets have a number of properties associated with them. Using the linkset property MML command, properties for a linkset can be changed one at a time or several at one time. Its MML name is LNKSETPROP. For information on linkset parameters, refer to Table 2-3.

To add a linkset property to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:lnksetprop:name="SS7-ANSI",layerRetries="6",layerTimer="6", 
sendAfterRestart="6", slsTimer="6",sstTimer="302",dialogRange="2",standard="ITU90"

Adding an SS7 Subsystem

The SS7 subsystem is a logical entity that mates two STPs. When two STPs are defined as mates within the Cisco PGW 2200 Softswitch, the controller can use either STP for communications to a destination device. Its MML name is SS7SUBSYS. For information on SS7 subsystem parameters, refer to Table 2-5.

To add an SS7 subsystem to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:ss7subsys:name="mate1",svc="STPA",matedapc="STPB",proto="SS7-ANSI",pri=1, 
desc="mate STPA to STPB"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:ss7subsys:name="mate2",svc="STPB",matedapc="STPA",proto="SS7-ANSI",pri=2, 
desc="mate STPB to STPA"
 
   

Step 3 Use the PROV-RTRV command to verify the SS7 subsystem was added.

The following MML commands provide an example of other components to add when adding a mated STP.

mml> prov-add:APC:NAME="STPA-5-83-230",DESC="STPA LA 5-83-230",NETADDR="5.83.230",NETIND=2 
mml> prov-add:APC:NAME="STPB-5-83-231",DESC="STPB LA 5-83-231",NETADDR="5.83.231",NETIND=2 
mml> prov-add:LNKSET:NAME="ls1",DESC="Linkset from STPA to pgw2200",APC="STPA-5-83-230", 
PROTO="SS7-ANSI",TYPE="IP" 
mml> prov-add:LNKSET:NAME="ls2",DESC="Linkset from STPB to pgw2200",APC="STPB-5-83-231", 
PROTO="SS7-ANSI",TYPE="IP" 
 
   
mml> prov-add:SS7ROUTE:NAME="ss7rte1-la",DESC="SS7 route set on ls1 to LA switch", 
OPC="opc-itxc-la",DPC="dpc-la",LNKSET="ls1",PRI=1 
mml> prov-add:SS7ROUTE:NAME="ss7rte2-la",DESC="SS7 route set on ls2 to LA switch", 
OPC="opc-itxc-la",DPC="dpc-la",LNKSET="ls2",PRI=1 
 
   
mml> prov-add:SS7ROUTE:NAME="route-STPA",DESC="route to STPA",OPC="opc-itxc-la", 
DPC="stpA-5-83-231",LNKSET="ls1",PRI=1 
mml> prov-add:SS7ROUTE:NAME="route-stpB",DESC="route to STPB",OPC="opc-itxc-la", 
DPC="STPB-5-83-230",LNKSET="ls2",PRI=1 
 
   


Tip Protocol families must be the same for mated subsystems. If one pair of STPs handles both ITU and ANSI variants, you must configure two pairs of STPs: one for ITU and the other for ANSI.


Adding Subsystem Numbers

You can also use the SS7 subsystem to define an SCP using TCAP. For TCAP applications, TRANSPROTO is set to TCPIP and the subsystem number is set to a value greater than 0 to support AIN. You also must set STPSCPIND to route to the appropriate SCP. For information on SS7 subsystem parameters, including STPSCPIND, refer to Table 2-5.

To add a subsystem number to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:ss7subsys:name="LNP-1",svc="stpa",transproto="SCCP",proto="SS7-ANSI",pri=1, 
ssn=231,desc="LNP231 for STP A"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:ss7subsys:name="AIN-1",svc="stpb",transproto="SCCP",proto="SS7-ANSI",pri=1, 
ssn=241,desc="AIN8xx for STP B"
 
   

Step 3 Use the PROV-RTRV command to verify the subsystem number was added.


Adding an SS7 Route

An SS7 route is a path from the Cisco PGW 2200 Softswitch to another Cisco PGW 2200 Softswitch or SSP switch. Its MML name is SS7ROUTE. For information on SS7 route parameters, refer to Table 2-6.

To add an SS7 route to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:ss7route:name="rte1DPC1",opc="OPC",dpc="DestSW1PC",lnkset="linkset1", 
pri=1,desc="route 1 to DestSW1 thru STP-A"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:ss7route:name="rte2DPC1",opc="OPC",dpc="DestSW1PC",lnkset="linkset2", 
pri=1,desc="route 2 to DestSW1 thru STP-B"
 
   

Step 3 Use the PROV-RTRV command to verify the SS7 route was added.



Tip You must create a route for each DPC-OPC combination.


Adding an SS7 Signaling Service

An SS7 signaling service specifies the protocol variant and the path that the Cisco PGW 2200 Softswitch uses to communicate with a remote switch (SSP) sending bearer traffic to the media gateways. Its MML name is SS7PATH. For information on signaling service parameters, refer to Table 2-7.

To add an SS7 signaling service to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:ss7path:name="ss7svc1",mdo="ANSISS7_STANDARD",dpc="dpc1",opc="opc1", 
desc="SS7 svc to dpc1"
 
   

Use the PROV-RTRV command to verify the SS7 signaling service was added.


Tip Do not change the default values for CUSTGRPID and CUSTGRTBL; they are used for DPNSS feature transparency.


CUSTGRPID also associates variants and dial plans. Use the RTRV-VARIANTS command to see valid variants.

Adding a FAS Signaling Service

The facility associated signaling (FAS) service is the signaling path to a particular destination when you are using either ISDN-PRI or DPNSS. Its MML name is FASPATH. For information on signaling service parameters, refer to Table 2-15.


Note FASPATH is not provisionable in software Release 9.4(1).


To add an FAS path to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> PROV-ADD:FASPATH:NAME="FASPATH1",SIDE="network",MDO="ETSI_300_102", 
CUSTGRPID="1000",CUSTGRPTBL="0101",DESC="FASPATH 1",ABFLAG="a",CRLEN=1
 
   

Use the PROV-RTRV command to verify the FAS path was added.

Adding Signaling Link Components

After configuring the SS7 signaling routes, you need to configure the signaling link components. These components link the Cisco PGW 2200 Softswitch to the STPs and to the media gateways. The configuration process is described in the following sections:

Adding an Interface Card

Adding an Ethernet Interface

Adding a C7 IP Link

Adding a TDM Interface

Adding a TDM Link

Adding an Interface Card

This is a network interface card or adapter that is operating in the Cisco PGW 2200 Softswitch host. Its MML name is CARD. For information on interface card parameters, refer to Table 2-9.


Note The CARD component is not provisionable in software Release 9.4(1).


To add an interface card to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:card:name="Ethernet1",type="EN",slot=0,desc="Ethernet Card 1"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:card:name="Ethernet2",type="EN",slot=1,desc="Ethernet Card 2"
 
   

Step 3 Use the PROV-RTRV command to verify the card component was added.



Tip You must configure the adapter card before you configure its corresponding interface.


Adding an Ethernet Interface

The Ethernet interface provides the physical line interface between a Cisco PGW 2200 Softswitch Ethernet network card/adapter and the physical Ethernet network. You configure parameters that control communications between the network card/adapter and the Ethernet. Its MML name is ENETIF. For information on Ethernet interface parameters, refer to the Table 2-10.


Note ENETIF is not supported in software Release 9.4(1).


To add an Ethernet interface to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:enetif:name="EtherIF1",desc="Ethernet IF 1",card="Ethernet1"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:enetif:name="EtherIF2",desc="Ethernet IF 2",card="Ethernet2"
 
   

Step 3 Use the PROV-RTRV command to verify the Ethernet interface was added.



Tip You must configure the adapter/card before configuring the interface.


Adding a C7 IP Link

A C7 IP link component identifies a link between a Cisco ITP-L IP address and port and the SS7 network (SSP or STP). Its MML name is C7IPLNK. For information on C7 IP link parameters, refer to Table 2-12.


Tip For SS7 provisioning, keep the following points in mind.
A maximum of 6 OPCs that can be supported.
Enter routing information for the OPC before creating the C7 IP link.
For each OPC added, you must specify a different local port for each C7 IP link.
Provision a maximum of 32 links per local port number. Specify another port number for each additional group of 32 links.
Use the same port number for links in the same linkset.



Tip When expanding a network past 32 links, spreading the links evenly across the ports is recommended to prevent service interruption.



Tip Use this component only when the Cisco PGW 2200 Softswitch uses Cisco ITP-Ls to communicate SS7 messages over IP.



Note Provision the ITP-L as an external node, then provision your sessionsets before adding the C7 IP links.


To add a C7 IP link to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:c7iplnk:name="lkset1SLC0",desc="SS7ANSI",sessionset="slt1", 
lnkset="linkset1",slc=0,pri=1,timeslot=0
 
   

Use the PROV-RTRV command to verify the C7 IP link was added.

For more information, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.

Adding a TDM Interface

The TDM interface provides the physical line interface between a Cisco PGW 2200 Softswitch TDM network card/adapter and the physical TDM network. Its MML name is TDMIF. For information on TDM interface parameters, refer to Table 2-11.


Note TDMIF is not supported in software Release 9.4(1) and later software revisions.


To add a TDM interface to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:tdmif:name="card1lif1",desc="V35 LIF 1",card="card1",lifnum=2, 
sigtype="V.35",datarate=64
 
   

Use the PROV-RTRV command to verify the TDM card was added.

Table 5-1 shows typical parameters based on card type.

Table 5-1 TDM Interfaces

Card Type
LIFNUM
RESIST
Data Rate/
Clock
DTEDCE
Line Coding
Format/
Framing
Signal Type
I/HDLC

ITK (T1)

1

75

 

NA

B8ZS

ESF

T1

IHDLC

ITK (E1)

1

120

 

NA

HDB3

CRC4

CEPT

IHDLC

V.35

2

0

64/EXT

DTE

NA

NA

V.35

DEFAULT


Adding a TDM Link

A TDM link is a communications link between a TDM interface card on the Cisco PGW 2200 Softswitch and TDM hardware element. For each link, you need to specify the card interface to which the link connects. Its MML name is TDMLNK.


Note TDMLNK is not supported in software Release 9.4(1).


To add a TDM link to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:tdmlnk:name="tdmlink1",if="card1lif1",pri=2,slc=2,svc="ls-1", 
desc="signal link 1"
 
   

Use the PROV-RTRV command to verify the TDM link was added.

Adding Media Gateway Control Links

Now you need to configure media gateway control links. The Cisco PGW 2200 Softswitch uses these links to control the bearer traffic that passes between each media gateway. You typically add media gateway control links by:

Adding an External Node

Adding a Card

Adding an Ethernet Interface

Adding an E-ISUP Signaling Service

Adding an IPFAS Transport Service

Adding an MGCP Signaling Service

Adding a NAS Signaling Service

Adding an IP Link

Adding an External Node

An external node is a media gateway with which the Cisco PGW 2200 Softswitch communicates. Its MML name is EXTNODE. For information on external node parameters, refer to Table 2-13.

To add an external node to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:extnode:name="mgx-8850",type="MGX8850"desc="MGX 8850"
 
   

Use the PROV-RTRV command to verify the external node has been added.


Tip You must create an external node for each media gateway.


Adding a Card

The card being referred to is a network card or adapter that is operating in the Cisco PGW 2200 Softswitch. Its MML name is CARD.


Note CARD is not provisionable in software Release 9.4(1) and later software revisions.


To add an adapter card to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:card:name="home1",type="EN",slot=0,desc="MGC1 Ethernet card"
 
   

Use the PROV-RTRV command to verify the Ethernet card was added.

Adding an Ethernet Interface

The Ethernet interface provides the physical line interface between an Cisco PGW 2200 Softswitch Ethernet network card/adapter and the physical Ethernet network. You configure parameters that control communications between the network card/adapter and the Ethernet. Its MML name is ENETIF.

Each SS7 link in the node must be associated with an Ethernet interface component, which must be associated with a network card. The Ethernet interface represents a physical network connection on the network card.


Note In the Cisco PGW 2200 Softswitch, the same cards and interfaces can be used for communication with Cisco ITP-Ls and media gateways. When configured this way, separate links are assigned for Cisco ITP-L and media gateway communications.



Note ENETIF is not supported in software Release 9.4(1) and later software revisions.


To add an adapter card to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:enetif:name="en1",desc="MGC1 Ethernet card1",card="home1"
 
   

Use the PROV-RTRV command to verify the Ethernet card was added.

Adding an E-ISUP Signaling Service

The E-ISUP signaling service or signaling path is the signaling path to an externally located Cisco PGW 2200 Softswitch (destination). Its MML name is EISUPPATH. For information on signaling service parameters, refer to Table 2-15.

To add an E-ISUP signaling service to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:eisuppath:name="eisupsrv1",extnode="extseq1",desc="EISUP Service to Ext Seq 
Node1"
 
   

Use the PROV-RTRV command to verify the EISUP signaling service was added.


Note To ensure correct failover operation in a configuration with two local MGCs (one active and one standby) and a remote Cisco PGW 2200 Softswitch, you need a minimum of two E-ISUP links from the remote Cisco PGW 2200 Softswitch to each Cisco PGW 2200 Softswitch redundant pair.


Adding an IPFAS Transport Service

The FAS over IP transport service or signaling path is the transport service from a Gateway to a Cisco PGW 2200 Softswitch. Its MML name is IPFASPath. For information on signaling service parameters, refer to Table 2-15.

To add an IPFAS transport service to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:ipfaspath:name="ipfassvc1",extnode="nas1",desc="PRI Backhaul Service to 
NAS1",mdo="ETSI_300_172",custgrpid="1111",abflag="a",crlen=1
 
   

Use the PROV-RTRV command to verify the IPFAS transport service was added.

Adding an MGCP Signaling Service

The MGCP signaling service or signaling path is the signaling service to a trunking gateway. Its MML name is MGCPPATH. For information on signaling service parameters, refer to Table 2-15.

To add an MGCP signaling link to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:mgcppath:name="mgcpsrv1",extnode="cu1",desc="MGCP Service to CU 1"
 
   

Use the PROV-RTRV command to verify the MGCP signaling service was added.

Modifying an MGCP Signaling Service Property

The MGCP signaling service property is the signaling service to a trunking gateway. The following is an example of how to change the codec used between an ingress and egress MGW. Ensure the GWDefaultCodecString value matches the codec value of the device to which the Cisco PGW 2200 Softswitch is connected. Its MML name is GWDefaultCodecString. For information on signaling service parameters, see to Chapter 6, "Properties", of Cisco PGW 2200 Softswitch MML Command Reference for a list of possible values.

To change an MGCP signaling service property to the media gateway configuration, use the PROV-ED command as follows:

mml> prov-ed:sigsvcprop:name="mgcsrv1",GWDefaultCodecString="G.711u",desc="MGC Signaling 
Service to MGW1"
 
   

Use the PROV-RTRV command to verify the MGCP signaling service was changed.

Adding a NAS Signaling Service

The network access server (NAS) signaling path is the Q.931 protocol path between the Cisco PGW 2200 Softswitch and the media gateway. Its MML name is NASPATH. For information on signaling service parameters, refer to Table 2-15.


Note If you are configuring a redundant system, you must define two redundant link manager links between each Cisco PGW 2200 Softswitch and media gateway. Each redundant link manager group must be associated with a different port number and a different NASPATH, but the same EXTNODE.


To add a NAS signaling service to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:naspath:name="nassrv1",extnod="nas1",desc="Service to 
NAS1",mdo="BELL_1268_C3"
 
   

Use the PROV-RTRV command to verify the NAS signaling service was added.


Tip For the NASPATH component, there is only one protocol: Bell_1268_C2 (for software Revision 9.3(2) or Bell_1268_C3 for earlier software revisions.


Adding an IP Link

The IP link is an IP connection between an Cisco PGW 2200 Softswitch's Ethernet interface and an media gateway. Its MML name is IPLNK. For information on IP link parameters, refer to Table 2-18.

To add an IP link to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:iplnk:name="Iplink1",if="en-1lif1",ipaddr="IP_Addr1",port=3001, 
peeraddr="192.12.214.10",peerport=3001,svc="nassvc1",desc="IP link for NAS service to 
NAS1"
 
   

Use the PROV-RTRV command to verify the IP link was added.


Tip When configuring two IP links to the same NAS, you need to configure two different Ethernet IP addresses on both the Cisco PGW 2200 Softswitch and the NAS.


Adding a Session Set

You must specify one or two (if the IPADDR2 and PEERADDR2 parameters are specified) backhaul IP links. Keep the following rules in mind when provisioning a session set.

SESSIONSETs that share a peer address (that is, PEERADDR, PEERADDR1, or PEERADDR2) must be assigned directly or indirectly to the same external node.

The PORT attribute cannot be set to the same value as the PORT attribute of another SESSIONSET with a different TYPE value.

If IPADDR2 or PEERADDR2 is specified then they must both be specified. You cannot have one local address and two remote addresses, or two local addresses and one remote address.

Another SESSIONSET with a different EXTNODE cannot use the resolved value of PEERADDR1 or PEERADDR2.

When an IP Route is specified in a link object for SESSIONSET, the IPADDR must match the IPADDR of the link. And when an IP Route is specified in a link object for SESSIONSET, the IP address resolved from the PEERADDR attribute must be the same as the DESTINATION and NETMASK attributes to verify the IPROUTE is valid.

In the following example, one session set is added.

To add a session set to the media gateway configuration, use the PROV-ADD command as follows:

mml> prov-add:sessionset:NAME="c7-2600-1",EXTNODE="va-2600-stim1",IPADDR1="ip_addr1",
PEERADDR1="192.0.2.11",PORT=7000,PEERPORT=7000,NEXTHOP1="0.0.0.0", 
NETMASK1="255.255.255.0",TYPE="BSMV0"
 
   

Use the PROV-RTRV command to verify the session set was added. Keep in mind that although IPADDR1 and PEERADDR1 are specified in the provisioning command, the 1 is not included in the retrieved response.

MGC1 mml> prov-rtrv:sessionset:name="c7-2600-1"
   MGC-01 - Media Gateway Controller 2002-09-26 07:24:05.845 EST
M  RTRV
   "session=wags2:sessionset"
   /* 
NAME = c7-2600-1-1
DESC = Session Set c7-2600-1 Backhaul Link 1
EXTNODE = va-2600-stim1
IPADDR = IP_Addr1
PORT = 7000
PEERADDR = 192.0.2.11
PEERPORT = 7000
NEXTHOP = 0.0.0.0
NETMASK = 255.255.255.255
TYPE = BSMV0

Adding D-channels

To configure two D-channels from the Cisco PGW 2200 Softswitch to a Cisco MGX8850, MGX 8880, or AS5xxx, you can provision two D-channels and designate one D-channel as the primary and the other D-channel as the secondary.

For a Primary Rate Interface (PRI) with a Facility Associated Signaling (FAS) that uses only one D-channel for each T1/E1 interface, the single D-channel becomes a single point of failure. By provisioning a backup D-channel, the single point of failure is removed and allows a D-channel on one PRI interface to carry signaling for the B-channels on the other PRI interfaces, which allows all the channels on the other PRI interfaces to be used as B-channels.

When provisioning D-channels keep the following in mind:

The maximum number of D-channels per channel controller is controlled by maxNumDChansPerIOCC as defined in XECfgParm.dat.

A session set cannot span channel controllers. Therefore all the D-channels assigned to a session set must be on one channel controller.

The maximum number of session sets per channel controller is 50.


Note Create the external node, IPFAS signaling path, and session set before adding the D-channels.


To add two back up D-channels to the media gateway configuration, use the PROV-ADD command as follows:


Step 1 With an open provisioning session, use the following MML command to add an two D-channels to the PGW 2200.

prov-add:DCHAN:NAME="dchan1a-207-3",DESC="Primary DCHAN for 
PRI-Svc1",SVC="prisvc1",PRI=1,SESSIONSET="sset-207-3",SIGSLOT=0,SIGPORT=1,SUBUNIT=0
 
   

Step 2 Use the following MML command to provision the secondary (backup) D-channel for IPFASPATH service with the second D-channel having a priority of 2, and using line 2 of the VXSM on slot 3.


Note This step is only required for a NFAS with a backup D-channel.


prov-add:DCHAN:NAME="dchan1b-207-3",DESC="Primary DCHAN for 
PRI-Svc1",SVC="prisvc1",PRI=2,SESSIONSET="sset-207-3",SIGSLOT=0,SIGPORT=2,SUBUNIT=0
 
   

Use the PROV-RTRV command to verify the D-channels were added. Use the following MML command to retrieve all provisioned D-channels:

prov-rtrv:dchan:"all"
 
   

Adding ISDN BRI Backhaul Connections

To enable ISDN BRI backhaul connections on the Cisco PGW 2200 Softswitch, the connected Cisco ISDN BRI voice gateway must be configured such that the switchback function is disabled. This prevents the voice gateway from automatically reconnecting with the active Cisco PGW 2200 Softswitch. The switchback function is disabled using the following command:

Gateway(config)#ccm-manager switchback never
 
   

Refer to the documentation for your voice gateway for more information.


Note If your network supports both PRI and BRI backhaul signaling, we recommend that you maintain the PRI and BRI interfaces on different media gateways. PRI signaling backhaul configurations typically use redundant links between the Cisco PGW 2200 Softswitch and the media gateway, and BRI signaling backhaul configurations use a single link between the Cisco PGW 2200 Softswitch and the media gateway.

If you decide to configure PRI and BRI signaling backhaul on the same media gateway, we recommend that you use a single link between the media gateway and the Cisco PGW 2200 Softswitch. If you do not remove a link from your PRI signaling backhaul provisioning, and one of those links should fail and be restored, you will need to set the service state of the related MGCP signaling service to OOS, and then set it to IS to restore both links to full functioning.


Perform the following steps to add an ISDN BRI backhaul connection.


Step 1 Start a provisioning session.

Step 2 Enter the following command to add a Cisco BRI voice gateway external node named va-3640-01:

mml>prov-add:extnode:name="va-3640-01",desc="BRI 3640",type="C3640",isdnsigtype="na" 
 
   

Step 3 Repeat Step 2 for each Cisco BRI voice gateway external node you want to add to your provisioning data.

Step 4 Enter the following command to add an ISDN BRI signaling service named brisvc1.

mml>prov-add:bripath:name="brisvc1",extnode="bri-3640-01",desc="BRI service to C2600", 
mdo="ETS_300_172",side="network",custgrpid="V123",crlen="2" 

Note Up to 2000 ISDN BRI signaling services can be provisioned on your Cisco PGW 2200 Softswitch.


Step 5 Enter the following command to add a backhaul TCP link named britcp1.

mml>prov-add:tcplink:NAME="britcp1",DESC="BRI TCP link 1",TYPE="BRI",IPADDR="IP_Addr1", 
PORT="1024",PEERADDR="192.0.2.12",PEERPORT="1024",extnode="va-3640-01,IPROUTE="iprte1" 
 
   

Step 6 Repeat Step 5 for each Backhaul TCP link you want to add to your provisioning data.

Step 7 Enter the following command to add an ISDN BRI D-channel named bridchan1.

mml>prov-add:dchan:NAME="bridchan1",DESC="ISDN BRI D channel 1",SVC="BRI",PRI="1", 
TCPLINK="britcp1",sigslot="4",sigport="1",subunit="1" 

Note Set the sigslot parameter to 0 for ISDN BRI D-channels when the associated external node is a C17xx.


If there are no other components that you need to provision, end your provisioning session.


Adding IUA Connections

The following sections contain the procedures that you must perform to add IUA connections to your Cisco PGW 2200 Softswitch provisioning data. When provisioning the components that enable the Cisco PGW 2200 Softswitch to support IUA, perform the procedures in the following order:

Verifying Next Hop Parameter Configuration

Adding Cisco Access Server External Nodes

Adding NAS Signaling Services

Adding IP Routes (Optional)

Adding SCTP Associations


Note This functionality is available starting in software Release 9.4(1).


Verifying Next Hop Parameter Configuration

To ensure proper functioning of the Support for IUA with SCTP feature, verify the next hop IP address parameters in the XECfgParm.dat file. These IP addresses are used when the next hop router IP addresses on the Cisco PGW 2200 Softswitch hosts do not match. To enter next hop IP addresses, perform the following steps:


Caution Do not modify the other XECfgParm.dat parameters associated with this feature.


Step 1 Log in to the standby Cisco PGW 2200 Softswitch as root and change directories to the etc subdirectory by entering the following UNIX command:

cd /opt/CiscoMGC/etc
 
   

Step 2 Open the XECfgParm.dat using a text editor, such as vi.

Step 3 Search for the *.IP_NextHop1 parameter and enter the IP address of your first next hop destination.


Note The IP address should be expressed in dotted decimal notation (for example, 192.0.2.2).


Step 4 Repeat Step 3 for every next hop destination (*.IP_NextHop2, *.IP_NextHop3, and so forth) that you want to identify. You can specify up to eight next hop IP addresses.

Step 5 Save your changes and close the text editor.

Step 6 Manually stop the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following UNIX command:

/etc/init.d/CiscoMGC stop
 
   

Step 7 Once the software shutdown is complete, manually start the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following command:

/etc/init.d/CiscoMGC start
 
   

Step 8 Log in to the active Cisco PGW 2200 Softswitch, start an MML provisioning session, and enter the following command:

mml> sw-over::confirm
 
   

Site alarms are automatically set until the out-of-service (OOS) Cisco PGW 2200 Softswitch host is returned to an in-service (IS) state.

Step 9 Repeat steps 2 through 8 for the newly standby Cisco PGW 2200 Softswitch host.


Adding Cisco Access Server External Nodes

To add Cisco access server external nodes to your provisioning data, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add a Cisco access server external node named va-5400-36.

mml> prov-add:extnode:name="va-5400-36",desc="AS5400",type="AS5400",isdnsigtype="iua" 
 
   

Step 3 Repeat Step 2 for each Cisco access server external node you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.

Otherwise, proceed to Adding NAS Signaling Services.


Adding NAS Signaling Services

To add NAS signaling services to your provisioning data, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add a NAS signaling service named nassvc1.

mml> prov-add:naspath:NAME="nassvc1",DESC="IUA NAS path",extnode="va-5400-37",sigport=45, 
sigslot=10
 
   

Step 3 Repeat Step 2 for each NAS signaling service you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.

Otherwise, you may:

Proceed to Adding IP Routes (Optional) if your Cisco PGW 2200 is on a different subnet from the associated access server; or

Proceed to the Adding SCTP Associations if your Cisco PGW 2200 is on the same subnet as the associated access server.


Adding IP Routes (Optional)

IP routes are required in your provisioning data if your Cisco PGW 2200 Softswitch hosts are not on the same subnet as the Cisco access servers. To add IP routes, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add an IP route named iprte1.

mml> prov-add:IPROUTE:NAME="iprte1",DESC="IP Route 1",dest="192.0.2.12",ipaddr="IP_Addr1", 
netmask="255.255.255.0",nexthop="209.165.200.225"
 
   

Step 3 Repeat Step 2 for each IP route you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.

Otherwise, proceed to Adding SCTP Associations.


Adding SCTP Associations

To add SCTP associations to your provisioning data, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add an SCTP association nasassoc1.

mml> prov-add:ASSOCIATION:NAME="nasassoc1",DESC="NAS Association 1",TYPE="IUA", 
IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",PEERADDR1="209.165.200.226", 
PEERADDR2="209.165.201.2",extnode="va-5400-37,IPROUTE1="iprte1",IPROUTE2="iprte2"
 
   

Note The parameters listed above are those required for the creation of an SCTP association for an IUA interface. For a complete list of parameters for this component, refer to the "Association" section.


Step 3 Repeat Step 2 for each SCTP association you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.


Adding DPNSS Connections

The following sections contain the procedures that you must perform to add DPNSS connections to your Cisco PGW 2200 Softswitch provisioning data. When provisioning the components that enable the Cisco PGW 2200 Softswitch to support DPNSS, perform the procedures in the following order:

Verifying Next Hop Parameter Configuration

Adding Cisco Access Server External Nodes

Adding IP Routes (Optional)

Adding SCTP Associations

Adding DPNSS Signaling Services

Adding DPNSS Supplementary Services


Note This functionality is available starting in software Release 9.4(1).


Verifying Next Hop Parameter Configuration

To ensure proper functioning of the Support for IUA with SCTP feature, verify the next hop IP address parameters in the XECfgParm.dat file. These IP addresses are used when the next hop router IP addresses on the Cisco PGW 2200 Softswitch hosts do not match. To enter next hop IP addresses, perform the following steps:


Caution Do not modify the other XECfgParm.dat parameters associated with this feature.


Step 1 Log in to the standby Cisco PGW 2200 Softswitch as root and change directories to the etc subdirectory by entering the following UNIX command:

cd /opt/CiscoMGC/etc
 
   

Step 2 Open the XECfgParm.dat using a text editor, such as vi.

Step 3 Search for the *.IP_NextHop1 parameter and enter the IP address of your first next hop destination.


Note The IP address should be expressed in dotted decimal notation (for example, 192.0.2.2).


Step 4 Repeat Step 3 for every next hop destination (*.IP_NextHop2, *.IP_NextHop3, and so forth) that you want to identify. You can specify up to eight next hop IP addresses.

Step 5 Save your changes and close the text editor.

Step 6 Manually stop the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following UNIX command:

/etc/init.d/CiscoMGC stop
 
   

Step 7 Once the software shutdown is complete, manually start the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following command:

/etc/init.d/CiscoMGC start
 
   

Step 8 Log in to the active Cisco PGW 2200 Softswitch, start an MML provisioning session, and enter the following command:

mml> sw-over::confirm
 
   

Site alarms are automatically set until the out-of-service (OOS) Cisco PGW 2200 Softswitch host is returned to an in-service (IS) state.

Step 9 Repeat steps 2 through 8 for the newly standby Cisco PGW 2200 Softswitch host.


Adding Cisco Access Server External Nodes

To add Cisco access server external nodes to your provisioning data, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add a Cisco access server external node named va-5400-36.

mml> prov-add:extnode:name="va-5400-36",desc="AS5400",type="AS5400",isdnsigtype="iua" 
 
   

Step 3 Repeat Step 2 for each Cisco access server external node you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.

Otherwise, proceed to Adding NAS Signaling Services.


Adding IP Routes (Optional)

IP routes are required in your provisioning data if your Cisco PGW 2200 Softswitch hosts are not on the same subnet as the Cisco access servers. To add IP routes, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add an IP route named iprte1.

mml> prov-add:IPROUTE:NAME="iprte1",DESC="IP Route 1",dest="192.0.2.13",ipaddr="IP_Addr1", 
netmask="255.255.255.0",nexthop="209.165.200.227"
 
   

Step 3 Repeat Step 2 for each IP route you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.

Otherwise, proceed to Adding SCTP Associations.


Adding SCTP Associations

To add SCTP associations to your provisioning data, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add an SCTP association nasassoc1.

mml> prov-add:ASSOCIATION:NAME="nasassoc1",DESC="NAS Association 1",TYPE="IUA", 
IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",PEERADDR1="209.165.200.228", 
PEERADDR2="209.165.201.4",extnode="va-5400-37",IPROUTE1="iprte1",IPROUTE2="iprte2"
 
   

Note The parameters listed above are those required for the creation of an SCTP association for an IUA interface. For a complete list of parameters for this component, refer to the "Association" section.


Step 3 Repeat Step 2 for each SCTP association you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.

Otherwise, proceed to Adding DPNSS Signaling Services.


Adding DPNSS Signaling Services

To add DPNSS signaling services, perform the following steps:


Step 1 Start a provisioning session.

Step 2 Enter the following MML command to add a DPNSS signaling service named dpnsvc1.

mml> prov-add:dpnssspath:NAME="dpnsssvc1",DESC="IUA DPNSS path",extnode="va-3660-20", 
sigport=45,sigslot=10
 
   

Step 3 Repeat Step 2 for each DPNSS signaling service you want to add to your provisioning data.

Step 4 If there are no other components that you need to provision, save your changes and end your provisioning session.


Adding DPNSS Supplementary Services

Use the following MML commands to provision the DPNSS supplementary services, which are available in software Release 9.6(1),

mml> prov-add:sigsvcprop:name="dpnsssv1",InhibitIncomingCallingNameDisplay="1"
mml> prov-add:trnkgrpprop:name="2222",InhibitIncomingCallingNameDisplay="1"
mml> prov-add:sigsvcprop:name="dpnsssv1",InhibitOutgoingCallingNameDisplay="1"
mml> prov-add:trnkgrpprop:name="2222", nhibitOutgoingCallingNameDisplay="1"
mml> prov-add:sigsvcprop:name="dpnsssvc2",LoopAvoidanceCounter="3"
mml> prov-add:trnkgrpprop:name="3333",LoopAvoidanceCounter="3"
mml> prov-add:sigsvcprop:name="dpnsssvc2",LoopAvoidanceSupport="1"
mml> prov-add:trnkgrpprop:name="3333",LoopAvoidanceSupport="1"
mml> prov-add:sigsvcprop:name="dpnsssvc2",MwiStringON="*58*AN*0#"
mml> prov-add:sigsvcprop:name="dpnsssvc2",MwiStringOFF="*58*AN*1#"
 
   
mml> numan-add:digmodstring:custgrpid="1111",name="mwion",digstring="4085556666" 
mml> numan-add:digmodstring:custgrpid="1111",name="mwioff",digstring="4085556667" 
mml> numan-add:resulttable:custgrpid="1111",name="rtab1t49",resulttype="BNBRMODMWI", 
dw1="mwion",dw2="mwioff",setname="rset1"
 
   

Adding Trunks, Trunk Groups, and Routing

You now need to configure trunks, trunk groups, and routing. The Cisco PGW 2200 Softswitch uses this information for determining the call traffic on each trunk between the switches and the media gateways. The procedures for configuring trunks, trunk groups, and trunk routes are described in the following sections:

Adding Files

Adding a Nailed Trunk (Bearer Channel)

Routing

Adding Files

The FILES component consists of customer-specific flat files that you can use to provision trunk groups, trunk routes, trunks, and dial plans. The MML name is FILES. For information on file parameters, refer to the "Provisioning Trunk Groups and Trunks" section.

To add a file to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:files:name="BCFile",file="trunkCust.dat",action="import"
 
   


Note When you are importing screening files, for example AWhite list or BBlack list, the import file name must be one of the following: <custGrpId>.awhite, <custGrpId>.bwhite, <custGrpId>.ablack, or <custGrpId>.bblack.


Use the PROV-RTRV command to verify the flat file was added.

Adding a Nailed Trunk (Bearer Channel)

The nailed trunk component is for adding individual nailed bearer channels in a dial access configuration. Its MML name is NAILEDRNK. For information on routing parameters, refer to the "Provisioning Trunk Groups and Trunks" section.

To add a nailed trunk to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:nailedtrnk:name="101",srcsvc="ss7svc1",srctimeslot=101,dstsvc="nassrv1", 
dstspan=3,dsttimeslot=1
 
   

Use the PROV-RTRV command to verify the nailed trunk was added.


Tip Use the FILES component with flat files to provision trunks; use the NAILEDTRNK component with an individual trunk.


Adding a Trunk Group

The trunk group component is for provisioning individual trunk groups. Its MML name is TRNKGRP. For information on TRNKGRP parameters, refer to Table 2-29.

To add a trunk group to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:trnkgrp:name="1000",clli="tttt-ss-xxx",svc="ss7svc1",type="tdm_gen", 
selseq="lidl",qable="n"
 
   

Use the PROV-RTRV command to verify the trunk group was added.

Adding Mapping to Multiple Trunk Groups

To add mapping to multiple trunk groups on an incoming SIP or EISUP sigpath, see Adding Mapping to Multiple IP Trunks.

Routing

This section is used to configure the routing file. Three components are necessary to configure routing. Their MML names are RTTRNKGRP, RTTRNK, and RTLIST.


Tip The examples listed below illustrate the syntax and sequence of these commands. For detailed descriptions of the individual command parameters, and additional guidance on using these commands, see the "Route Analysis" section, including Table 2-32, Table 2-33, and Table 2-34.


To add routing files to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD commands as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:rttrnkgrp:name="501",type=7,reattempts=1,queuing=0,cutthrough=2
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:rttrnk:name="rt513",trnkgrpnum=513
 
   

Step 3 Use the following MML command to add the component and required parameters.

mml> prov-add:rtlist:name="rtlist501",rtname="rt501"
 
   

Step 4 Use the PROV-RTRV command to verify the routing files were added.



Tip All the route lists, route trunks, and route trunk groups information can be retrieved by using the prov-rtrv:rtlist:"all" command. The all option cannot be used with other parameters.


Provisioning Reserving Incoming Bandwidth

In countries where 2-way trunk groups are used between a carrier's network and an incumbent's network, these trunk groups carry outgoing traffic as well as incoming traffic to and from the incumbent.

When a trunk group toward a certain access area becomes congested, reserving incoming bandwidth allows the carrier to re-direct outing traffic away from the congested trunk group and toward less congested trunk groups. Thus a carrier can reserve a configurable percentage (in 1% increments) of circuits for incoming calls and redirect outgoing traffic away when a trunk group is congested. This maximizes the carrier's opportunity to bring in revenue generating traffic, or to reserve circuits (increase availability) for premier customers.

When calculating the percentage of idle circuits and the percentage of the busy circuit, all circuits that are available for call processing are used as the 100% base. The circuits that are available for call processing are the circuits in service and not blocked. Circuits that are blocked (local, remote, or gateway) or not in service are not considered.

For example, if there are 25 blocked circuits, 40 idle circuits, and 60 circuits with calls in progress (includes both incoming and outgoing), the total configured circuit is 125 in the trunk group, and the circuit available for call processing is 100. Therefore the percentage of the idle circuit is 40% (since 25 circuits are blocked and therefore not counted) and the percentage of the busy circuit is 60%. If the ResIncPerc property configured against the trunk group is 30%, no outgoing circuit is selected if the percentage of the idle circuit is less than 30%. When the percentage of the idle circuit is equal to or more than 30%, new outgoing calls are allowed for the trunk group.

You can reserve a percentage of the available circuits (in service and not blocked) for incoming calls only when the number of idle and available circuits is equal to or below the reserved incoming percentage. If the ResIncPerc is set higher (that is reserving more incoming trunk groups), no calls are dropped to increase the current number of idle circuits, but no new outgoing calls are placed on the trunk group until the number of idle circuits drops below the new reserved incoming percentage value.

If alternative routing trunk groups are specified, the call is routed using the alternative trunk group if the number of idle circuits is less than the configured ResIncPerc threshold. However, if no alternative routing trunk group is specified, the call is dropped.

The range for this property is from 0 to 100%. The property value is saved during the routing data commit. The following MML command example sets the percentage of trunks in the routing trunk group that are reserved for incoming calls to 65%, if the trunk group name was 1000.

mml> prov-add:rttrnkgrp:name="1000",type="0",reattempts="5",queuing="1",cutthrough="1", 
resincperc="65"

Provisioning Bearer Capability

This section is used to configure the bearer capability for each trunk group.

To provision bearer capabilities to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD commands as follows:


Step 1 Use the following MML command to add the component and required parameters.

mml> prov-add:bearercap:name="bearer1",bearercap="12;05;31"
 
   

Step 2 Use the following MML command to add the component and required parameters.

mml> prov-add:siprttrnkgrp:name="2222",url="128.107.132.143",srvrr=0,sipproxyport=5060, 
version="2.0",cutthrough=1,extsupport=1,bearercapname="bearer1"
 
   

Step 3 Use the following MML command to add the component and required parameters.

mml> prov-add:rrttrnkgrp:name="1",type=1,reattempts=3,queuing=0,cutthrough=1, 
bearercapname="bearer1"
 
   

Step 4 Use the PROV-RTRV command to verify the bearer capability file was modified.


Provisioning Least Cost Routing

When provisioning the routing components in the Cisco PGW 2200 Softswitch, it is possible to modify and change the order of trunk groups (rttrnkgrp) in a route (rttrnk), or routes (rttrnk) in a route list (rtlist). These commands can be very useful in dynamically adjusting Least Cost Routing.


Note The inserted route or trnkgrp appears before the next trunk group name.


The following MML command examples show a route defined with four trunk groups.

mgc4 mml> prov-rtrv:rttrnk:name="routea"
   MGC-01 - Media Gateway Controller 2002-02-23 01:16:43.381 GMT
M  RTRV
   "session=nexttrnkgrp:rttrnk"
   /* 
routeName
---------
routea
 
   
     trunkGroup     nextTrunkGroup
     ----------     --------------
     2000           3000
     3000           4000
     4000           5000
     5000           
   */
 
   
 
   
=======================================

If you discover you are required to change the trunk group order (that is, trunk group 5000 is the best value), start a provisioning session and perform the following MML commands.

mgc4 mml> prov-ed:rttrnk:name="routea",trnkgrpnum=5000,nexttrkgrp=2000
   MGC-01 - Media Gateway Controller 2002-02-23 01:17:00.944 GMT
M  COMPLD
   "rttrnk"
   ;
mgc4 mml> prov-rtrv:rttrnk:name="routea"
   MGC-01 - Media Gateway Controller 2002-02-23 01:17:03.039 GMT
M  RTRV
   "session=nexttrnkgrp:rttrnk"
   /* 
routeName
---------
routea
 
   
     trunkGroup     nextTrunkGroup
     ----------     --------------
     5000           2000
     2000           3000
     3000           4000
     4000           
   */
 
   

As a result of executing the previous MML commands, trunk group 5000 is now first. Commit the provisioning MML changes by performing the prov-cpy/dply sequence.

If you discover that you now need to remove trunk group 3000 entire from the list, start a provisioning session and perform the following MML commands.

mgc4 mml> prov-dlt:rttrnk:name="routea",trnkgrpnum=3000
   MGC-01 - Media Gateway Controller 2002-02-23 01:21:34.762 GMT
M  COMPLD
   "rttrnk"
   ;
mgc4 mml> prov-rtrv:rttrnk:name="routea"
   MGC-01 - Media Gateway Controller 2002-02-23 01:21:36.854 GMT
M  RTRV
   "session=nexttrnkgrp:rttrnk"
   /* 
routeName
---------
routea
 
   
     trunkGroup     nextTrunkGroup
     ----------     --------------
     5000           2000
     2000           4000
     4000           
   */
 
   

As a result of performing the preceding MML commands, trunk group 3000 no longer in the list. Commit the provisioning MML changes by performing the prov-cpy/dply sequence.

However, if you discover you want to add in trunk group 3000 again, open a provisioning session and perform the following MML commands.


Note Trunk group 3000 is appended to the bottom of the route list.


mgc4 mml> prov-ed:rttrnk:name="routea",trnkgrpnum=3000
   MGC-01 - Media Gateway Controller 2002-02-23 01:22:17.770 GMT
M  COMPLD
   "rttrnk"
   ;
mgc4 mml> prov-rtrv:rttrnk:name="routea"
   MGC-01 - Media Gateway Controller 2002-02-23 01:22:19.621 GMT
M  RTRV
   "session=nexttrnkgrp:rttrnk"
   /* 
routeName
---------
routea
 
   
     trunkGroup     nextTrunkGroup
     ----------     --------------
     5000           2000
     2000           4000
     4000           3000
     3000           
   */
   ;
mgc4 mml> 
===================================================================

If, after adding trunk group 3000, you want to make it the primary choice trunk group, open a provisioning session and perform the following MML commands.

mgc4 mml> prov-ed:rttrnk:name="routea",trnkgrpnum=3000,nexttrkgrp=5000
   MGC-01 - Media Gateway Controller 2002-02-23 01:47:24.965 GMT
M  COMPLD
   "rttrnk"
   ;
mgc4 mml> prov-rtrv:rttrnk:name="routea"
   MGC-01 - Media Gateway Controller 2002-02-23 01:47:26.551 GMT
M  RTRV
   "session=nexttrnkgrp:rttrnk"
   /* 
routeName
---------
routea
 
   
     trunkGroup     nextTrunkGroup
     ----------     --------------
     3000           5000
     5000           2000
     2000           4000
     4000           
   */
   ;
mgc4 mml> 
 
   

Overriding the Trunk Group Property

The trunk group component is used to provision trunk group properties. Its MML name is TRNKGRPPROP. In the following example, the trunk group property NPA is overridden for trunk group number 1000. For information on TRNKGRPPROP properties, refer to Table 2-30.

To override the Cisco PGW 2200 Softswitch trunk group properties, use the PROV-ADD command as follows:

mml> prov-add:TRNKGRPPROP:NAME="1000",NPA="703"
 
   

Use the PROV-RTRV command to verify the specified trunk group property has been overridden.

Enabling Overdecadic 32 Digit Operation

Enabling the 32-digit overdecadic feature extends protocol-specific developments to all supported protocols for 32-digits and overdecadic digits (A through F), and to support number portability when receiving and generating Cause 14. Refer to Table 5-2 for a list of supported parameters per protocol family.


Note The 32-digit functionality does not apply to the protocol variants of the Q.721 protocol, since these protocols have a 4-bit field for the number (length) of the address signals contained in each parameter, thus it is not possible to have any parameter with more than 16 digits.



Note This functionality is available starting in software Release 9.4(1).


Table 5-2 Parameters Affected by Overdecadic and 32 Digits Support 

Protocol Family
Parameters
32 Digits Support
Overdecadic
Digits Support

ANSI

 

 

 

 

Called Party Number

Yes

Yes

 

Calling Party Number

Yes

Yes

 

Carrier Identification

No (3 or 4 digits)

No (see Note 1)

 

Charge Number

Yes

Yes

 

Generic Address

Yes

Yes

 

Jurisdiction Information

No (6 digits)

No

 

Original Called Number

Yes

Yes

 

Outgoing Trunk Group Number

No (6 digits)

No

 

Redirecting Number

Yes

Yes

 

Redirection Number

Yes

Yes

 

Transit Network Selection

No (3 or 4 digits)

No (see Note 1)

Q.721

 

 

 

 

Additional Identity* (French ISUP)

No (see Note 2)

Yes

 

Called Party Number

No (see Note 2)

Yes

 

Calling Line Identity (Calling Party Number)

No (see Note 2)

Yes

 

Original Called Number

No (see Note 2)

Yes

 

Subsequent Address Message (Subsequent Number)

No (see Note 2)

Yes

 

Subsequent Address Message with One signal

No (1 digit)

Yes

 

Transit Exchange Identity

No (see Note 2)

No

Q.761

 

 

 

 

Called Party Number

Yes

Yes

 

Calling Party Number

Yes

Yes

 

Carrier Selection* (German ISUP)

No (3 or 4 digits)

Yes

 

Charge Area Information (Japanese ISUP)

Yes

Yes

 

Connected Number

Yes

Yes

 

Contract Number* (Japanese ISUP)

Yes

Yes

 

Generic Number

Yes

Yes

 

Last Diverting Line Identity* (UK ISUP)

Yes

Yes

 

Location Number

Yes

Yes

 

Original Called Number

Yes

Yes

 

Presentation Number* (UK ISUP)

Yes

Yes

 

Redirecting Number

Yes

Yes

 

Redirection Number

Yes

Yes

 

Subsequent Number

Yes

Yes

 

Transit Network Selection

No (3 or 4 digits)

Yes

Q.767

 

 

 

 

Called Party Number

Yes

Yes

 

Calling Party Number

Yes

Yes

 

Connected Number

Yes

Yes

 

Generic Number* (Italian Interconnect and Russian ISUPs)

Yes

Yes

 

Location Number* (Colombia, Russian, Spanish, and Swedish ISUPs)

Yes

Yes

 

Original Called Number* (Colombia, Indonesia, Mexican, Russian, Spanish, and Swedish ISUPs)

Yes

Yes

 

Redirecting Number* (Colombia, Indonesia, Mexican, Russian, Spanish, and Swedish ISUPs)

Yes

Yes

 

Redirection Number* (Colombia, Indonesia, Mexican, Russian, Spanish, and Swedish ISUPs)

Yes

Yes

 

Subsequent Number

Yes

Yes

 

Transit Network Selection* (Colombia and Mexican ISUPs)

No (3 or 4 digits)

Yes

Note 1: The overdecadic support for the listed parameters was introduced previously in software Release 9. Overdecadic support only applies when the Cisco PGW 2200 Softswitch (configured for Signaling Mode) receives an SS7 call and terminates to the Network Access Server (NAS) gateway or vice versa; and does not apply to an SS7-to-SS7 call, which does not support overdecadic digits.

Note 2: There is a 4-bit length field associated with the number of address signals (digits) within the bit string of the parameter, thus not making it possible to have more than 16 digits.

Parameters marked with an (*), are only specific to the protocol variants that appear in parenthesis meaning that the base variant of the protocol family does not support the parameter. The Japanese ISUP consists of the NTT, TOKYO, JAPAN, and JAPAN_JT protocol variants.


To support up to 32 digits and overdecadic digits (A through F) in called and calling numbers across all supported protocols, set the TMaxDigits property (set on the sigpath) as follows:

mml> prov-add:sigsvcprop="ss7svc1",TMaxDigits="32" 

Note MML targets of AWHITE, BWHITE, ABLACK, BBLACK, TERMTBL, ANUMDPSEL, and ACHGORIGIN only support the Calling Line Identity (CLI) up to 20 digits. The MML target of PORTTBL supports the called number and routing number up to 20 digits as well.


Provisioning the Generic LNP Protocol Enhancements: 32 Digits, Overdecadics, and Cause 14 Mapping Feature

With a provisioning session active, perform the following steps to provision the Generic LNP Protocol Enhancements: 32 Digits, Overdecadics, and Cause 14 Mapping Feature.


Step 1 Assuming the 32-digit overdecadic feature is disabled, dynamically change the OD32DigitSupport property for 32-digit and overdecadic support.
mml> prov-add:trnkgrpprop:name="1000",OD32DigitSupport="1"


Note Setting the value of the OD32DigitSupport property to 0 disables overdecadic 32 digit support. The default property value is 1 (enabled).


Step 2 A response similar to the following is returned:
Media Gateway Controller - MGC-03 2003-02-17 14:25:56

M COMPLD 
"trnkgrp" 

Step 3 Commit the provisioning session changes.
mml> prov-cpy


Verifying the Generic LNP Protocol Enhancements: 32 Digits, Overdecadics, and Cause 14 Mapping Feature

After you have provisioned the Generic LNP Protocol Enhancements: 32 Digits, Overdecadics, and Cause 14 Mapping Feature, perform the following steps to verify its setting.


Step 1 With an provisioning session active, use prov-rtrv:trnkgrpprop:name="1000" to verify the trunk group property is correctly provisioned.
mml> prov-rtrv:trnkgrpprop:name="1000"

Step 2 A response, similar to the following, is returned:

Media Gateway Controller - MGC-03 2003-02-17 14:27:52
M RTRV
"session=trnkgrpprop"
/*
BOrigStartIndex = 0
BTermStartIndex = 1
CarrierIdentity = 0
CLLI = STEVE
CompressionType = 1
CotPercentage = 0
CustGrpId = 0000
EchoCanRequired = 0
ExtCOT = Loop
GLARE = 0
Npa = 0
RingNoAnswer = 255000
SatelliteInd = 0
ScreenFailAction = 0
·
·
·
OD32DigitSupport = 1 
*/
;

Provisioning SUBSCRIBE/NOTIFY Methods


Note This functionality is available starting in software Release 9.4(1).


The procedures for provisioning the SUBSCRIBE/NOTIFY methods are in the following sections:

Enabling SUBSCRIBE/NOTIFY Methods

Disabling SUBSCRIBE/NOTIFY Methods

Enabling SUBSCRIBE/NOTIFY Methods

Use the following steps to enable the SUBSCRIBE/NOTIFY methods:


Step 1 Start a provisioning session.

Step 2 Enable the SUBSCRIBE/NOTIFY methods on a SIP trunk group with the following command:

mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",SubscribeNotifySupport=1
 
   

For example, to enable the SUBSCRIBE/NOTIFY methods on a SIP trunk group called 3333, you would enter the following command:

mml> prov-ed:trnkgrpprop:name="3333",custgrpid="1111",SubscribeNotifySupport=1
 
   

Step 3 If there are no other components that you need to provision, end your provisioning session.


Disabling SUBSCRIBE/NOTIFY Methods

Use the following steps to disable the SUBSCRIBE/NOTIFY methods:


Step 1 Start a provisioning session.

Step 2 Disable the SUBSCRIBE/NOTIFY methods on a SIP trunk group with the following command:

mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",SubscribeNotifySupport=0
 
   

For example, to disable the SUBSCRIBE/NOTIFY methods on a SIP trunk group called 3333, you would enter the following command:

mml> prov-ed:trnkgrpprop:name="3333",custgrpid="1111",SubscribeNotifySupport=0
 
   

Step 3 If there are no other components that you need to provision, end your provisioning session.


Provisioning Unsolicited Notifications


Note This functionality is available starting in software Release 9.4(1).


The procedures for provisioning unsolicited notifications are in the following sections:

Enabling Unsolicited Notifications

Disabling Unsolicited Notifications

Enabling Unsolicited Notifications

Use the following steps to enable the Unsolicited NOTIFY method for SIP DTMF digits by the Cisco PGW 2200 Softswitch:


Step 1 Start a provisioning session.

Step 2 Enable unsolicited notifications on a SIP trunk group using the following command:

mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",UnsolicitedNotifyMethod=1
 
   

For example, to enable unsolicited notifications on a SIP trunk group called 3333, you would enter the following command:

mml> prov-ed:trnkgrpprop:name="3333",custgrpid="1111",UnsolicitedNotifyMethod=1
 
   

Step 3 If there are no other components that you need to provision, end your provisioning session.


Disabling Unsolicited Notifications

Use the following steps to disable the Unsolicited NOTIFY method for SIP DTMF digits by the Cisco PGW 2200 Softswitch:


Step 1 Start a provisioning session.

Step 2 Disable unsolicited notifications on a SIP trunk group using the following command:

mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",UnsolicitedNotifyMethod=0
 
   

For example, to disable unsolicited notifications on a SIP trunk group called 3333, you would enter the following command:

mml> prov-ed:trnkgrpprop:name="3333",custgrpid="1111",UnsolicitedNotifyMethod=0
 
   

Step 3 If there are no other components that you need to provision, end your provisioning session.


Provisioning Subscription Duration


Note This functionality is available starting in software Release 9.4(1).


The procedures for provisioning the duration data for subscriptions are in the following sections:

Provisioning Minimum Subscription Duration for Telephony Event

Provisioning Maximum Duration for SUBSCRIBE

Provisioning Minimum Subscription Duration for Telephony Event

Use the following steps to define the minimum duration for which a telephony event can exist before it can be re-subscribed:


Step 1 Start a provisioning session.

Step 2 Set the minimum duration of a telephony event on a SIP trunk group:

mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid", 
MinEventSubscribeDuration=minsub
 
   

For example, to provision a telephony event to last a minimum of 200 ms on a SIP trunk group called 3333, you would enter the following command:

mml> prov-ed:trnkgrpprop:name="3333",custgrpid="1111",MinEventSubscribeDuration=200
 
   

Step 3 If there are no other components that you need to provision, end your provisioning session.


Provisioning Maximum Duration for SUBSCRIBE

Use the following steps to define the maximum duration for which the subscription can exist before it needs a re-subscription:


Step 1 Start a provisioning session.

Step 2 Set the maximum duration time for a subscription on a SIP trunk group:

mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid", 
MaxSubscriptionDuration=maxsub
 
   

For example, to provision a subscription to last a maximum of 3600 seconds on a SIP trunk group called 3333, you would enter the following command:

mml> prov-ed:trnkgrpprop:name="3333",custgrpid="1111",MaxSubscriptionDuration=3600
 
   

Step 3 If there are no other components that you need to provision, end your provisioning session.


Enabling/Disabling Information Extraction from SDP


Note This functionality is available starting in software Release 9.4(1).


The procedures required to enable or disable extracting information from the SD P is in the following sections.

Enabling Support of Information Extraction from Sockets Direct Protocol (SDP)

Use the following steps to enable extracting SDP information for billing purposes.


Step 1 Start a provisioning session.

Step 2 Enter the following command to enable SDP information extraction:

mml> prov-ed:trnkgrpprop:name="trnk_num",populateSDPInfoInCDR="1"
 
   

Where: trnk_num—The number of the trunk to be modified.

For example, to enable SDP information extraction on a trunk group called 5000, you would enter the following command:

mml> prov-add:trnkgrpprop:name="5000",populateSDPInfoInCDR="1"
 
   

Step 3 Repeat Step 2 for each trunk group you want to modify.


Disabling Support of Information Extraction from SDP

Use the following steps to disable extracting SDP information for billing purposes.


Step 1 Start a provisioning session.

Step 2 Enter the following command to disable SDP information extraction:

mml> prov-ed:trnkgrpprop:name="trnk_num",populateSDPInfoInCDR="0"
 
   

Where: trnk_num—The number of the trunk to be modified.

For example, to disable SDP information extraction on a trunk group called 5000, you would enter the following command:

mml> prov-add:trnkgrpprop:name="5000",populateSDPInfoInCDR="0"
 
   

Step 3 Repeat Step 2 for each trunk group you want to modify.


Adding a Switched Trunk (Multiple Switched Trunks)

The trunk (switched bearer channel) component is used for provisioning multiple switched trunks. Its MML name is SWITCHTRNK. For information on SWITCHTRNK parameters, refer to the "Creating the Trunk Group" section. The following command adds the six switched trunks shown in Table 5-3.

To add switched trunks to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows

mml> prov-add:switchtrnk:name="1",trnkgrpnum="1000",span="ffff",cic=25,cu="gw1", 
spansize=6,endpoint="S0/DS1-1/6@li-5300-3"
 
   

Table 5-3 Switched Trunk Command Result 

Trunk Group Number
Trunk Group Member
Span
CIC
Endpoint
CLI

1000

1

ffff

25

S0/DS1-1/7@li-5300-3

gw1

1000

2

ffff

26

S0/DS1-1/8@li-5300-3

gw1

1000

3

ffff

27

S0/DS1-1/9@li-5300-3

gw1

1000

4

ffff

28

S0/DS1-1/10@li-5300-3

gw1

1000

5

ffff

29

S0/DS1-1/11@li-5300-3

gw1

1000

6

ffff

30

S0/DS1-1/12@li-5300-3

gw1


Use the PROV-RTRV command to verify the switched trunks were added.

Retrieving Multiple Switched Trunks

To retrieve multiple switched trunks based on the trunk group number, span, or coding unit name, use the PROV-RTRV command as follows:

mml> prov-rtrv:switchtrnk:trnkgrpnum="1000"
 
   

Adding Multiple Nailed Trunks

To add multiple nailed trunks based on source service, source span, destination service, and destination span, use the PROV-ADD command as follows:

mml> prov-add:nailedtrnk:name="100",srcsvc="SC-1",dstsvc="PC-7-200-7",srcspan="0", 
dstspan="ffff",srctimeslot="1",dsttimeslot="4065",spansize=6
 
   

The previous command added the six nailed trunks shown in Table 5-4.

Table 5-4 Nailed Trunk Command Result 

Name
SRCSVC
SRCSPAN
SRCTIMESLOT
DSTSVC
DSTSPAN
DSTTIMESLOT

1

SC-1

0

1

PC-7-200-7

ffff

4065

2

SC-1

0

2

PC-7-200-7

ffff

4066

3

SC-1

0

3

PC-7-200-7

ffff

4067

4

SC-1

0

4

PC-7-200-7

ffff

4068

5

SC-1

0

5

PC-7-200-7

ffff

4069

6

SC-1

0

6

PC-7-200-7

ffff

4070


Use the PROV-RTRV:nailedtrnk:srcsvc="sc-1" command to verify the nailed trunk groups were added.

Retrieving Multiple Nailed Trunks

To retrieve multiple nailed trunks, use the PROV-RTRV command as follows:

mml> prov-rtrv:nailedtrnk:srcsvc="SC-1"
 
   

Observe the screen to verify the command was successful.


Note Only one source service, destination service, source span, or destination span is allowed at a time.


Adding Multiple Trunk Groups and Bearer Channels

The multiple trunk group component is for provisioning multiple PRI trunk groups and bearer channels. Its MML name is MLTTRNKGRP.

To add multiple trunk groups and bearer channels to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:mlttrnkgrp:name="1000",svc="bsc1",clli="5300E4011",numtrnkgrp=2,spansize=4, 
trnkmemnum=1,span=0,cic=1,endpoint="S10/DS1-0/1@mgx-8850,cu="mgx-east"
 
   

Use the PROV-RTRV command to verify multiple trunk groups and bearer channels were added.


Note You cannot provision other trunk group types (for example, TDM or IP) with MLTTRNKGRP.


Removing Multiple Trunk Groups and Bearer Channels

Only specify the NAME and NUMTRNKGRP parameters to remove several multiple trunk groups and associated bearer channels.

To remove multiple trunk groups and bearer channels from the Cisco PGW 2200 Softswitch configuration, use the PROV-DLT command as follows:

mml> prov-dlt:mlttrnkgrp:name="1000",numtrnkgrp=2
 
   

Use the PROV-RTRV command to verify the multiple trunk groups and bearer channels were removed.

To verify the component added to the port table, use the NUMAN-RTRV command.

Creating a Profile

A profile must be created before a property, which belongs to a profile, can be added. Profile types are:

GRPROFILE

ISUPTMRPROFILE

ATMPROFILE

When configuring a profile, you can attach a profile to a signaling service, but both the profile and the signaling service must belong to the same variant. However, you can create a profile even though the signaling service does not exist.

A profile allows one or more properties to be set once and then reused multiple times. To create a profile, use the PROV-ADD command as follows:

mml> prov-add:profile:name="profile1",type="grprofile",hopon="0"defaultBC="3_1_KHZ", 
confusion="1"
 
   

Note A GR317 profile must be created before a trunk group can be associated with the profile.


Adding a Trunk Group Profile

Only specify the NAME and PROFILENAME parameters to add a trunk group profile for the specified trunk group.


Note A profile must be created before a trunk group can be associated with the profile.


To add a profile type, use the PROV-ADD command as follows:

mml> prov-add:trnkgrpprof:name="1000",grprofile="profile1"
 
   

Use the PROV-RTRV command to verify the specified trunk group property profile has been overridden.

Deleting a Trunk Group Profile

Only specify the NAME and PROFILENAME parameters to delete a trunk group profile for the specified trunk group.

To delete a profile type, use the PROV-DLT command as follows:

mml> prov-dlt:trnkgrpprof:name="1000","grprofile"
 
   

Use the PROV-RTRV command to verify the specified trunk group property profile has been deleted. To retrieve all profile types, use the PROV-RTRV:profiletypes command.

Adding an ISUP Timer Profile

Before you can configure ISUP timers, you must first create an ISUP timer profile by using the following MML command.

mml> prov-add:profile:name="set1",type="ISUPTMRPROFILE",variant="Q761_BASE", 
validation="off",T1="5",T2="7"
 
   

Note The validation parameter is added in software Release 9.5(2), This parameter is valid only for ISUP timer profiles. When the validation parameter is set to off, ISUP timer values can be entered that are outside the valid range as defined by the specification. During an export (prov-exp), if any of the timer values are out of range, the validation parameter is exported with its value set to off.


Use the following MML commands to retrieve, delete, edit, and attach an ISUP timer profile.

mml> prov-rtrv:profile:name="set1" 
 
   

The profile can be deleted if it is not attached to a component using the following MML command.

mml> prov-dlt:profile:name="set3" 
 
   

The profile edit command does not need variant information with it.

The profile edit command causes the change to parameters if it is already existing with profile. If it is a new property, it is added against this profile.

mml> prov-ed:profile:name="prof1",type="isuptmrprofile",T6="13",T7="24",T25="3" 
 
   

The prov-edit command shows the defaults and the over-ridden values.

The following MML command attaches a profile to a sigpath:

mml> prov-add:sigpathprof:name="ss7svc1",isuptmrprofile="set1" 
 
   

Refer to "Components and Properties," for a list the valid ranges and default values of each configurable ISUP timer for each supported protocol variant.

When configuring an ISUP timer profile, you must specify a protocol variant listed in "Components and Properties." However, you can create a profile even though the signaling service does not exist.

Suppressing Caller ID in a SIP Environment

In software Revision 9.2(2) and above, you can control how the system suppresses (restricts) the information contained in the following calling-party identity parameters:

Calling Line Identification (CLI)

Generic Name (GN)

Presentation Number (PN)

Redirecting Number (RDN)

Original Called Number (OCN)

To suppress the CLID, GN, or PN in a SIP environment, set the cgpnInclude trunk group property to 0. See Table 5-5, Table 5-6, and Table 5-7 for a list of CLID, GN, and PN suppression values based upon the incoming PSTN signaling settings for a SIP terminated call through a SIP trunk group.

Table 5-5 CLID Suppression in a SIP Environment 

cgpnInclude Value (of terminating/outgoing SIP trunk group)
Received CLI
(in IAM)
Received CLIR
(in IAM)
Outgoing FROM header
Displayname field
Outgoing FROM header
Username field

Not applicable

Not available

Not available

Unknown

Unknown

0 (do not include)

Available

0 (no restriction)

CLID

CLID

0 (do not include)

Available

1 (restriction)

Anonymous

Anonymous

1 (include)

Available

0 (no restriction)

CLID

CLID

1 (include)

Available

1 (restriction)

Anonymous

CLID


Table 5-6 GN Suppression in a SIP Environment 

cgpnInclude Value (of terminating/outgoing SIP trunk group)
Received GN
(in IAM)
Received GN APRI 1 (in IAM)
Outgoing FROM header
Displayname field
Outgoing FROM header
Username field

Not applicable

Not available

Not available

Unknown

Unknown

0 (do not include)

Available

0 (no restriction)

Address signal of GN

Address signal of GN

0 (do not include)

Available

1 (restriction)

Anonymous

Anonymous

1 (include)

Available

0 (no restriction)

Address signal of GN

Address signal of GN

1 (include)

Available

1 (restriction)

Address signal of GN

Address signal of GN

1 APRI = Address Presentation Restricted Indicator


Table 5-7 PN Suppression in a SIP Environment 

cgpnInclude Value (of terminating/outgoing SIP trunk group)
Received PN
(in IAM)
Received PN APRI (in IAM)
Outgoing FROM header
Displayname field
Outgoing FROM header
Username field

Not applicable

Not available

Not available

Unknown

Unknown

0 (do not include)

Available

0 (no restriction)

PN, if present for the ISUP variant

PN, if present for the ISUP variant

0 (do not include)

Available

1 (restriction)

Anonymous

Anonymous

1 (include)

Available

0 (no restriction)

PN, if present for the ISUP variant

PN, if present for the ISUP variant

1 (include)

Available

1 (restriction)

Anonymous

PN, if present for the ISUP variant


Table 5-8 and Table 5-9 show the mapping of the RDN and OCN parameters from PSTN signaling to SIP Diversion Header with different settings for the SIP trunk group property cgpnInclude.

Table 5-8 RDN-to-SIP Diversion Header Mapping 

RDN
(in IAM)
Presentation Indicator
(in RDN)
cgpnInclude
(on originating SIP trunk group)
displayname
(Diversion header)
username
(Diversion header)

Available

0 (no restriction)

0 (do not include if its presentation is set to restricted)

RDN

RDN

Available

1 (restricted or unavailable)

0 (do not include if its presentation is set to restricted))

Anonymous

Anonymous

Available

0

1 (always include)

RDN

RDN

Available

1

1 (always include)

Anonymous

RDN


Table 5-9 OCN-to-SIP Diversion Header Mapping 

OCN
(in IAM)
Presentation Indicator
(in OCN)
cgpnInclude
(on originating SIP trunk group)
displayname
(Diversion header)
username
(Diversion header)

Available

0 (no restriction)

0 (do not include if its presentation is set to restricted)

OCN

OCN

Available

1 (restricted or unavailable)

0 (do not include if its presentation is set to restricted)

Anonymous

Anonymous

Available

0

1 (always include)

OCN

OCN

Available

1

1 (always include)

Anonymous

OCN


Adding an ATM Profile

ATM profiles are used on the Cisco PGW 2200 Softswitch to change the network Service Level Agreement. You can add an ATM profile in routeAnalysis.dat by using the following MML command:

mml> prov-add:atmprofiles:name="atmprof1",atmprofiles="ITU1;custom100"
 
   

The following example represents the result of the previous MML command in routeAnalysis.dat:

$ATMProfiles
# CiscoMGC:   01
#name                ATMProfiles
atmprof1            ITU1;cust100
 
   

Provisioning ATM Profiles

After an ATM profile has been created, you can edit, delete, or retrieve an ATM profile you created in routeAnalysis.dat by using the following MML commands:

mml> prov-ed:atmprofiles:name="atmprof1",atmprofiles="ITU1;custom200"
mml> prov-dlt:atmprofiles:name="atmprof1"
mml> prov-rtrv:atmprofiles:name="atmprof1"
mml> prov-rtrv:atmprofiles:"all"

Provisioning ATM Profiles Result Types

Provision ATM profiles result types by using the following MML commands:

mml> numan-add:resulttable:custgrpId="T002",name="result59", 
resulttype="ATM_ORIG_PROFILE",dw1="atmprof1",dw2="1",setname="set1"
 
   
mml> numan-add:resulttable:custgrpId="T002",name="result60", 
resulttype="ATM_TERM_PROFILE",dw1="atmprof1",dw2="1",setname="set1"

Provisioning Trunk Group Properties

Provision trunk group properties by using the following MML commands:

mml> prov-add:trnkgrp:name="1000",svc="ss7svc1",type="ATM"
mml> prov-ed:trnkgrpprop:name="1000",playannouncement="0"
mml> prov-ed:trnkgrpprop:name="1000",GWDefaultATMProfile="profile1;profile2"
mml> prov-ed:trnkgrpprop:name="1000",NetworkType="1"
mml> prov-ed:trnkgrpprop:name="1000",AtmConnectionType="4"

Provisioning SigPath Properties

Provision the SigPath properties by using the following MML commands:

mml> prov-add:mgcppath:name="mgcpsvc1",extnode="AS5400",desc="MGCP service"
mml> prov-add:sigsvcprop:name="mgcpsvc1",GWProtocolVersion="MGCP 1.0"
 
   

Adding SIP Components

For calls from the PSTN to the SIP domain, E164 numbers must be mapped to the URL of the Session Initiation Protocol (SIP) proxy server that will handle the call. Each SIP trunk group is associated with a URL of a SIP proxy server. There may be multiple trunk groups and each trunk group may be mapped to a different SIP proxy server.

E164 numbers must be associated with route groups. Each route group may contain one or more routes. And in turn, each route may be associated with a SIP trunk group. The E164 number to SIP trunk group association must be provisioned. In addition, the SIP signaling path between the Cisco PGW 2200 Softswitch and the SIP server must be provisioned. These procedures are described in the following sections.

Adding a SIP Signaling Service

The SIP signaling service is the connection between an Cisco PGW 2200 Softswitch and a SIP server. Its MML name is SIPPATH.

To add a SIP signaling service for the signaling gateway from the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:sippath:name="sip-path",mdo="IETF_SIP",desc="SIP sigpath"
 
   

Use the PROV-RTRV command to verify that the SIP signaling service was added.

Adding a SIP Signaling Link

The SIP signaling link is the connection between an Cisco PGW 2200 Softswitch and a SIP server. Its MML name is SIPLNK.

To add a SIP signaling link for the SG from the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:siplnk:name="sip-sipchan",ipaddr="IP_Addr1",svc="sip-sigpath", 
port=5060,pri=1,desc="SIP sigchan"
 
   

Use the PROV-RTRV command to verify that the SIP signaling link was added.


Note If the Virtual IP Address, in XECfgParm.dat, is configures with the 0.0.0.0, a fail over does not create the new logical interface, thus not enable the SIP failover support feature and does not block creation of a second SIP signaling link.


Adding a SIP Trunk Group

The SIP trunk group is the trunk group for incoming SIP calls. Its MML name is TRNKGRP.

To add a SIP trunk group for the signaling gateway from the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:trnkgrp:name="1111",svc="sip-sigpath",type="SIP_IN"
 
   

Use the PROV-RTRV command to verify that the SIP trunk group was added.

Adding SIP Trunk Group Properties

The SIP trunk group properties are for incoming SIP calls. Its MML name is TRNKGRPPROP.

To add a SIP trunk group property for the signaling gateway from the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:trnkgrpprop:name="1111",custgrpid="1122",MGCdomain="mgc.cisco.com", 
mgcsipversion="2.0",Localport="5060",InvitetimerT1="2000",gentimerT1="800", 
genTimerT2="7000",maxRedirectCnt="9",Support183="4",Fromfield="anonymous", 
DefaultsessionTimer="500000",MaxSessionTimer="800000",holdtimer="400000"
 
   

Use the PROV-RTRV command to verify that the SIP trunk group property was added.

Adding Mapping to Multiple IP Trunks

The IPINMAPPING sigpath property allows you define mapping between a single SIP or EISUP interface and multiple IP trunk groups using incoming IP address, subnet mask, and port number. To add a new mapping entry, use the PROV-ADD:IPINMAPPING command as follows:

Prov-add:ipinmapping:name="sipinmapping-1",sigsvc="sippath-1",allowedIP="192.0.2.14", 
sipport=5063, trnkgrpNum=1000
 
   

Use the PROV-RTRV to verify the incoming trunk group properties.

For more information about the IPINMAPPING component, see IPINMAPPING.

For more information on the provisioning procedures for multiple inbound IP trunks, see the "Multiple Inbound IP Trunks" section.

Adding SIP Routing Trunk Group Properties

The SIP routing trunk group properties are for incoming SIP calls. Its MML name is SIPRTTRNKGRP.

To add a SIP routing trunk group property for the signaling gateway from the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:siprttrnkgrp:name="2222",url="ss1.wrong.com",srvrr=1,sipproxyport=5060, 
version="2.0",cutthrough=3,extsupport=0
 
   

Use the PROV-RTRV command to verify the SIP routing trunk group property was added.

Adding SIP Domain Name System Properties

The SIP domain name system (DNS) properties are for provisioning DNS-related parameters. Its MML name is DNSPARAM.

To add a SIP DNS property for the signaling gateway from the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:

mml> prov-add:dnsparam:dnsserver1="172.22.1.1",dnsserver2="143.83.1.1",cachesize="500", 
ttl="3600",policy="hierarchy",querytimeout="1000",icmptimeout="30",keepalive="30"
 
   

Use the PROV-RTRV command to verify that the SIP DNS property was set.

The following is a sample MML test script for provisioning SIP:

prov-sta::srcver="new",dstver="ems"
 
   
prov-add:card:name="enet-card",type="EN",slot=0,desc="Ethernet card",type="EN"
prov-add:enetif:name="enet-if",desc="Ethernet interface",card="enet-card"
;
; provision SIP sigpath
;
prov-add:sippath:name="sip-path",mdo="IETF_SIP",desc="SIPsigpath"
;
: provision SIP link
;
prov-add:siplnk:name="sip-link",ipaddr="IP_Addr1",svc="sip-path", 
port=5060,pri=1,desc="SIPlink"
;
;provision trunk group for incoming SIP calls
;
prov-add:trnkgrp:name="1701",svc="sip-path",type="SIP_IN"
prov-add:TRNKGRPPROP:name="1701",CustGrpId="1133",MGCdomain="192.0.2.15",mgcsipversion="2.
0",Localport="5060",InvitetimerT1="1000",gentimerT1="500"
,genTimerT2="4000",maxRedirectCnt="5",Support183="4",Fromfield="sip-network",holdtimer="40
0000"
;
;provision trunk group for outgoing SIP calls
;
prov-add:trnkgrp:name="707",svc="sip-path",type="IP_SIP"
prov-add:TRNKGRPPROP:name="707",CustGrpId="1133",MGCdomain="192.0.2.15",mgcsipversion="2.0
",Localport="5060",InvitetimerT1="1000",gentimerT1="500",
genTimerT2="4000",maxRedirectCnt="5",Support183="4",Fromfield="sip-network",holdtimer="400
000"
;
;provision trunk group for outgoing SIP calls
;
prov-add:trnkgrp:name="706",svc="sip-path",type="IP_SIP"
prov-add:TRNKGRPPROP:name="706",CustGrpId="1133",MGCdomain="192.0.2.15",mgcsipversion="2.0
",Localport="5060",InvitetimerT1="1000",gentimerT1="500",
genTimerT2="4000",maxRedirectCnt="5",Support183="4",Fromfield="pstn-network",holdtimer="40
0000"
prov-add:siprttrnkgrp:name="707",url="192.0.2.16",srvrr=0,sipproxyport=5060,version="2.0",
cutthrough=1,extsupport=1
prov-add:siprttrnkgrp:name="706",url="192.0.2.16",srvrr=0,sipproxyport=5060,version="2.0",
cutthrough=1,extsupport=1
;
; provision DNS parameters
;
prov-add:dnsparam:dnsserver1="64.102.6.247",cachesize="500",ttl="3600",policy="hierarchy",
querytimeout="1000",keepalive="30"
prov-add:rttrnk:name="route707",trnkgrpnum=707
prov-add:rttrnk:name="route706",trnkgrpnum=706
prov-add:rtlist:name="list707",rtname="route707"
prov-add:rtlist:name="list706",rtname="route706"
numan-add:resultset:custgrpid="1133",name="set707"
numan-add:resultset:custgrpid="1133",name="set706"
numan-add:resulttable:custgrpid="1133",name="result707",resulttype="ROUTE",dw1="list707",s
etname="set707"
numan-add:resulttable:custgrpid="1133",name="result706",resulttype="ROUTE",dw1="list706",s
etname="set706"
numan-add:bdigtree:custgrpid="1133",callside="originating",digitstring="707",setname="set7
07"
numan-add:bdigtree:custgrpid="1133",callside="originating",digitstring="706",setname="set7
06"
 
   
prov-stp
 
   

Modifying a SIP Signaling Service

The SIP signaling service is the connection between a Cisco PGW 2200 Softswitch and a SIP server. Its MML name is SIPPATH.

To modify a SIP signaling service for the signaling gateway from the Cisco PGW 2200 Softswitch configuration, use the PROV-ED command as follows:

mml> prov-ed:sippath:name="sip-path",mdo="IETF_SIP",desc="SIP sigpath"
 
   

Use the PROV-RTRV command to verify that the SIP signaling service was modified.

Modifying Session Timers

The following two procedures indicate the MML command used for modifying the session timer for incoming and outgoing SIP trunk groups.

Modifying Session Timer for Incoming SIP Trunk Groups

Use the following MML command to modify the session timer for an incoming SIP trunk group called 3333.

mml> prov-ed:trnkgrpprop:name="3333",InSessionTimer="26000"
 
   

Modifying Session Timer for Outgoing SIP Trunk Groups

Use the following MML command to modify the session timer for an outgoing SIP trunk group called 3333.

mml> prov-ed:trnkgrpprop:name="3333",OutSessionTimer="26000"
 
   

Adding Dual Presentation CLI

For networks providing PC-to-phone capabilities, a requirement to populate dual CLI fields in the outgoing IAM message field exists.The following MML command is used to populate the Generic Number CLI in the transmitted IAM for UK-ISUP.

 
   
mml> prov-add:trnkgrpprop:name="2222",...,AInternationalPrefix="1234567890" 

Adding Automatic Switchover Using Dual-VLAN


Note This functionality is available starting in software Release 9.4(1).


This feature is not supported for systems where the active and standby Cisco PGW 2200 Softswitch hosts are geographically separated. This feature is only supported for systems where the active and standby Cisco PGW 2200 Softswitch hosts are configured as part of the same set of subnets. Systems that have geographically separated Cisco PGW 2200 Softswitch hosts must use the existing methodology, using two IP addresses each for the active and standby Cisco PGW 2200 Softswitch hosts.

Verifying Parameter Settings and Re-configuring Cisco PGW 2200 Softswitch Software

Perform the following steps to verify parameter settings and re-configure the Cisco PGW 2200 Softswitch software to support the SIP Automatic Switchover Using Dual-VLAN feature:


Caution Re-configuration of the Cisco PGW 2200 Softswitch software requires that the system software be shut down. In a simplex system, calls cannot be processed during system shutdown. In a continuous service system, your system loses the ability to maintain calls during a critical event if the system software on one of the Cisco PGW 2200 Softswitch hosts is shut down.


Step 1 Log in to the standby Cisco PGW 2200 Softswitch as root and change directories to the etc subdirectory by entering the following UNIX command:

cd /opt/CiscoMGC/etc
 
   

Step 2 Open the XECfgParm.dat using a text editor, such as vi.

Step 3 Search for the *.Virtual_IP_Addr1 parameter and ensure that the current setting is a virtual address within the subnet of the IP address defined in the IP_Addr1 parameter.


Note The IP address should be expressed in dotted decimal notation (for example, 192.0.2.2).


If the value of the parameter is correct, proceed to Step 4. Otherwise, correct the value of the parameter and then proceed to Step 4.

Step 4 If you have not configured a second virtual IP address, proceed to Step 6. Otherwise, search for the *.Virtual_IP_Addr2 parameter and ensure that the current setting is a virtual address within the subnet of the IP address defined in the IP_Addr2 parameter.


Note The IP address should be expressed in dotted decimal notation (for example, 192.0.2.2).


If the value of the parameter is correct, proceed to Step 5. Otherwise, correct the value of the parameter and then proceed to Step 5.

Step 5 Search for the *.sipFailover parameter and ensure that the current setting is true.

If the value of the parameter is correct, proceed to Step 6. Otherwise, correct the value of the parameter and then proceed to Step 7.

Step 6 If you have made any changes to the parameter values, proceed to Step 7. Otherwise, close the text editor and proceed to Step 10.

Step 7 Save your changes and close the text editor.

Step 8 Manually stop the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following UNIX command:

/etc/init.d/CiscoMGC stop
 
   

Step 9 Once the software shutdown is complete, manually start the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following command:

/etc/init.d/CiscoMGC start
 
   

Step 10 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:

mml> sw-over::confirm
 
   

Site alarms are automatically set until the out-of-service (OOS) Cisco PGW 2200 Softswitch host is returned to an in-service (IS) state.

Step 11 Repeat steps 1 through 5 for the newly standby Cisco PGW 2200 Softswitch host.

Step 12 If you have not made any changes to the parameter values, proceed to Step 13. If you have made any changes to the parameter values, repeat steps 7 through 10. Once you have completed step 10, the procedure is complete.

Step 13 Contact the Cisco Technical Assistance Center (TAC) for assistance in resolving this problem. Information on contacting the Cisco TAC can be found in the Obtaining Documentation and Submitting a Service Request.


Enabling SIP Automatic Switchover Using Dual-VLAN

This section contains the procedure you perform to add SIP Automatic Switchover Using Dual-VLAN support to your Cisco PGW 2200 Softswitch software provisioning data. For more information on this feature, see the SIP Automatic Switchover Using Dual-VLAN feature module at

http://cisco.com/en/US/docs/voice_ip_comm/pgw/9/feature/module/9.4_1_/FMvlan.html


Note The XECfgParm.dat parameters for this feature must be configured before you can provision virtual IP addresses for SIP IP links. If you have not configured the parameters, perform the steps in the "Verifying Parameter Settings and Re-configuring Cisco PGW 2200 Softswitch Software" section before performing the following procedures.


To provision virtual IP address(es) on your SIP IP links, perform the following steps:


Step 1 Start a provisioning session.

Step 2 If you are provisioning SIP IP links for the first time, proceed to Step 9. Otherwise, proceed to Step 3.

Step 3 Enter the following command to display the settings for your SIP IP links:

mml> prov-rtrv:siplnk:"all"
 
   

The system returns a response that lists the settings for all of your provisioned SIP IP links. Take note of the IP address settings (ipaddr1 and ipaddr2) for each link. Identify the SIP IP links that do not have an IP address setting of Virtual_IP_Addr1.

Step 4 The identified SIP IP links must be taken out-of-service. To do this, enter the following command:

mml> set-iplnk:name:OOS
 
   

Where name is the MML name of a SIP IP link provisioned with standard IP addressing. Repeat this step for each affected SIP IP link.

Step 5 The identified SIP IP links must be deleted. Enter the following command to delete one SIP IP link:

mml> prov-dlt:siplnk:name="name" 
 
   

Where name is the MML name of a SIP IP link to be deleted.

Repeat this step for each SIP IP link you are to delete.

Step 6 If any of the SIP IP links have an IP address setting of Virtual_IP_Addr1, proceed to Step 9. Otherwise, proceed to Step 7.

Step 7 Delete the signaling service associated with the deleted SIP IP links. To do this, enter the following MML command:

mml> prov-dlt:sippath:name="name" 
 
   

Where name is the MML name of a SIP signaling service to be deleted.

Repeat this step for each SIP signaling service you delete.

Step 8 Enter the following command to provision a new SIP signaling service:

mml> prov-add:sippath:name="name",mdo="ietf_sip" 
 
   

Where name is the MML name of the new SIP signaling service.

For example, to provision a new SIP signaling service called sipsrv1, enter the following command:

mml> prov-add:sippath:name="sipsrv1",mdo="ietf_sip" 
 
   

Step 9 Enter the following command to provision a virtual IP address on a SIP IP link:

mml> prov-add:siplnk:name="name",desc="description",ipaddr="addr",svc="sigsrv", 
port=port=pnum,pri=priority,desc="description" 
 
   

For example, to provision a SIP IP link that supports a virtual IP address, enter the following MML command:

mml> prov-add:siplnk:name="sip-sigchan1",ipaddr="Virtual_IP_Addr1",svc="sip-sigpath", 
port=5060,pri=1,desc="SIP sigchan 1" 
 
   

Step 10 If you want to create a second virtual IP address, enter the following command. Otherwise, proceed to
Step 11.

mml> prov-add:siplnk:name="sip-sigchan2",ipaddr="Virtual_IP_Addr2",svc="sip-sigpath", 
port=5060,pri=1,desc="SIP sigchan 2" 
 
   

Step 11 Repeat steps 2 through 10 for each SIP IP link you provision with a virtual IP address.

Step 12 Save and activate your new provisioning settings.


Disabling SIP Automatic Switchover Using Dual-VLAN

This section contains the procedure you perform to disable SIP Automatic Switchover Using Dual-VLAN support in your system.


Note Start an MML provisioning session.


Perform the following steps to disable the virtual IP addresses on your SIP IP links:


Step 1 Log in to the standby Cisco PGW 2200 Softswitch as root and change directories to the etc subdirectory by entering the following UNIX command:

cd /opt/CiscoMGC/etc
 
   

Step 2 Open the XECfgParm.dat using a text editor, such as vi.

Step 3 Search for the *.Virtual_IP_Addr1 parameter and set the value to 0.0.0.0.

Step 4 If you have not configured a second virtual IP address, proceed to Step 5. Otherwise, search for the *.Virtual_IP_Addr2 parameter and set the value to 0.0.0.0.

Step 5 Search for the *.sipFailover parameter and set the value to false.

Step 6 Save your changes and close the text editor.

Step 7 Manually stop the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following UNIX command:

/etc/init.d/CiscoMGC stop 
 
   

Step 8 Once the software shutdown is complete, manually start the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch by entering the following command:

/etc/init.d/CiscoMGC start
 
   

Step 9 Log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:

mml> sw-over::confirm
 
   

Site alarms are automatically set until the out-of-service (OOS) Cisco PGW 2200 Softswitch host is returned to an in-service (IS) state.

Step 10 Repeat steps 1 through 8 for the newly standby Cisco PGW 2200 Softswitch host.

Step 11 The affected SIP links must be taken out-of-service. To do this, enter the following command:

mml> set-iplnk:name:OOS 
 
   

Where name is the MML name of a SIP IP link provisioned with virtual IP addressing. Repeat this step for each affected SIP IP link.

Step 12 Log in to the active Cisco PGW 2200 Softswitch host, start an MML session, and begin a provisioning session.

Step 13 To change from virtual IP addressing to standard IP addressing, delete the SIP IP links provisioned with virtual IP addressing. Enter the following command to delete an affected SIP IP link:

mml> prov-dlt:siplnk:name="name" 
 
   

Where name is the MML name of a SIP IP link provisioned with virtual IP addressing. Repeat this step for each affected SIP IP link.

Step 14 Enter the following command to delete the associated SIP signaling service:

mml> prov-dlt:sippath:name="name" 
 
   

Where name is the MML name of a SIP signaling service associated with the SIP IP links provisioned with virtual IP addressing.

Step 15 Enter the following command to provision a new SIP signaling service:

mml> prov-add:sippath:name="name",mdo="ietf_sip" 
 
   

Where name is the MML name of the new SIP signaling service.

For example, to provision a new SIP signaling service called sipsrv1, enter the following command:

mml> prov-ed:sippath:name="sipsrv1",mdo="ietf_sip" 
 
   

Step 16 Enter the following command to enable the IP addresses on a SIP IP link:

mml> prov-add:siplnk:name="name",ipaddr="addr",ipaddr="addr" 
 
   

Where name is the MML name of the affected SIP IP link; addr is the first local IP address for a LAN interface. IP address should be IP_Addr1, IP_Addr2, IP_Addr3, or IP_Addr4, as defined in the XECfgParm.dat file.

For example, to enable an IP address on a SIP IP link, you would enter the following command:

mml> prov-add:siplnk:name="sip-sigchan1",ipaddr="IP_Addr1" 
 
   

Repeat this step for each SIP IP link you provision with standard IP addressing.

Step 17 Save and activate your provisioning session.


Adding SIP-T and SIP-GTD Support


Note This functionality is available starting in software Release 9.4(1).


This section contains the procedures you perform to add SIP-T and SIP-GTD support to your Cisco PGW 2200 Softswitch software provisioning data. When provisioning the components that enable the Cisco PGW 2200 Softswitch software to support SIP-T and SIP-T, perform the procedures in the following order.

Adding an SS7 Signaling Service

Adding an External Node

Adding a SIP Signaling Service

Adding a SIP Signaling Link

Adding a Trunk Group

Adding a Switched Trunk (Multiple Switched Trunks)

Adding SIP-T and SIP-GTD Support

GTD Provisioning Examples

Enabling the Early Backward ISUP Message

Enabling Partial GTD Support

Adding SIP Domain Name System Properties

Adding SIP-T and SIP-GTD Support

To add SIP-T or SIP-GTD support to your system, you must set two properties in both the ingress SS7 trunk group and in the SIP trunk group. To do this, use the following MML commands.

Enter the following command to enable SIP-T or SIP-GTD on an ingress SS7 trunk group.

mml> prov-add:trnkgrpprop:name="550",sipMimeBodySupport="1",IsupTransparencyDisabled=0 
 
   

Note The IsupTransparencyDisabled property appears in the MML command because enabling SIP-T/SIP-GTD support requires that ISUP transparency be enabled on the selected trunk group.


Repeat the MML command for the SIP trunk groups for which you want to activate SIP-T or SIP-GTD support.

Enabling the Early Backward ISUP Message

To enable the early backward ISUP message on GTD-enabled SIP trunk groups, perform the following MML command.

mml> prov-ed:trnkgrpprop:name="1000",IsupTransEarlyBackwardDisabled="0" 
 
   

Where name is the number of a previously provisioned trunk group.

GTD NOA Override

The Generic Transparency Descriptor (GTD) Nature of Address (NOA) feature is used to specify a set of GTD fields that the Cisco PGW 2200 Softswitch desires to override the corresponding ISDN Information Element (IE) fields. NOA is one of the override fields. The override fields are specified in a string. For fields not specified in the string, ISDN IE fields take precedence.

The GTD parameter string for building is a single string of GTD parameters separated by comma(s). The maximum length of this string is 460 bytes (4x115). The ALL string stands for all GTD parameters and the NONE string (the default) stands for null or no GTD parameters.

The following is the GTD parameter string syntax for building the GTD parameter string, where the parameter is in three uppercase letters:

gtdParamString = NONE | ALL | build_string

Note The default value of gtdParamString is NONE.


GTD override fields string is a single string of GTD parameters, as well as fields separated by comma. The maximum length of this string is 256 bytes. A special string "NONE" stands for null string. The following is the syntax of GTD override fields string where the filed should be in lower case letters of varying length:

gtdOverrideFieldsString = NONE | override_string
 
   

The GTD parameter names that can be entered in the override_string are:

RGN.noa | OCN.noa | CPN.noa | CGN.noa |

BCI.inter | BCI.acc | OBI.inb | CAI.loc | ATP.dat


Note The override_string GTD command is not valid for use with SIP.


The parameters contained in gtdParamString indicate all the GTD parameters the Cisco PGW 2200 Softswitch supports for the specified NAS sigpath. The parameters contained in gtdOverrideFieldsString indicate all the GTD fields that the Cisco PGW 2200 Softswitch overrides for the specified NAS sigpath.

The GTD parameter names that can be entered in the build_string are:

ACL | ADI | APP | ATP |

BCI | BSG | BVN | CAI |

CCN | CCS | CDI | CDN |

CDT | CGL | CGN | CHI |

CHN | CIC | CID | CIN |

CMI | CNF | CNN | CNR |

COL | COR | CPC | CPN |

CRF | CSI | CSP | CTI |

CTN | CTR | DIS | ECI |

EGR | EVI | FAI | FCI |

FDC | FVN | GCI | GEA |

GED | GEN | GIC | GNO |

GRF | HOC | HTR | INI |

IRI | ISC | JUR | LON |

LPI | LSP | MCI | MCR |

MLP | MRI | NET | NMC |

NOC | NPF | NRN | NSF |

OBI | OCI | OCN | OCT |

OFI | OLI | OSI | OTN |

PBI | PCA | PCI | PCT |

PDC | PFI | PRI | PRN |

PVS | QOR | RBI | RCT |

RDC | RDS | RFI | RGN |

RMO | RNI | RNN | RNR |

SCF | SCI | SEA | SEG |

SPC | SPR | SRI | SUN |

TID | TMP | TMR | TMU |

TNS | TRR | UCI | UFC |

UID | USI | USP | UTI |

UUI | UUS | VER


Note MML validates the length of gtdParamString and overrideString, but does not validate the syntax. The parameters and fields with invalid syntax are ignored.


An example of the content of gtdParam.dat:

CompTypeID

gtdParamString

overrideString

00370001

CPC,CGN,CDN,BCI,RGN,CID

CDN.noa,CGN.noa,RGN.noa

00370002

ALL

NONE

00370003

CPC,CGN,CDN

CGN.#,CGN.si

00370004

NONE

CDN.noa


To support sigpath as well, the existing Trunk Group property ISUP Transparency Disabled (IsupTransParencyDisabled) permits disabling the ISUP transparency feature and supports NAS sigpath and SS7 sigpaths.

The possible values are 1 (Disabled) or 0 (Enabled). The default value is 1 (Disabled). The value is a string type.

In addition, another property (IsupTransEarlyBackwardDisabled) is used by ISDN PRI sigpath to indicate if Early Backward Call Setup Message supported.

The possible values are 1 (Disabled) or 0 (Enabled). The default value is 1 (Disabled).

You can provision a subset of GTD parameters using a set of MML interface commands. No validation is performed on the input of GTD parameters.

An MML command with the TID gtdParam supports the configurable GTD parameters. The following are examples of adding, editing, and deleting GTD parameters.

prov-add:gtdParam:name="t3",gtdParamString="BCI,CPC,CGN,CIC,CPN,MCR" 
prov-ed:gtdParam:name="t3",gtdParamString="BCI,CPC,CGN,UUI",
overridestring="RGN.noa,CGN.noa"
prov-dlt:gtdParam:name="t3"
 
   

You can also define GtdCapTypeProp to be associated with a NAS sigpath. This property is used by the Cisco PGW 2200 Softswitch as a pointer to the subset of GTD parameters that you have already defined. The default value the GtdCapTypeProp is "t0", which stands for no GTD support.

The property GtdMsgFmt is associated with isdnpri sigpath. The value is a string, where c = compact (default).

The property CorrelationCallIDFormat is associated with isdnpri sigpath. The value is an integer, where 0 = H323 (default) and 1 = SIP.

The property IsupTransEarlyBackwardDisabled is associated with isdnpri sigpath. The value is integer type, where 0 = Enabled and 1 = Disabled (default).

The property IsupTransParencyDisabled is associated with isdnpri sigpath. The value is an integer, where 0 = Enabled and 1 = Disabled (default).

For SS7-to-SS7 calls, GTD transports the backward call indicator (BCI) and optional backward call indicators within the facility indicator parameter. However; unless specified in the override string, the default setting is for the ISUP data to populate the BCI fields. Use the following MML command to populate the BCI fields with GTD data.

mml> prov-add:gtdparam:name="t1",gtdparamstring="ALL",overridestring="BCI.acc,OBI.inb, 
BCI.inter"
 
   

where:

BCI.acc is used to override the ISDN ACCESS IND field in the BCI

BCI.inter is used to override INTERWORKING field in the BCI

OBI.inb is used to override INBAND INFO field in the optional backward call indicators

GTD Provisioning Examples

If the system has no GTD related provisioning, all sigpaths have the default value of gtdcaptypeprop set to t0, which means there is no GTD support. The following provisioning session enables partial GTD support indicated by gtdcaptypeprop = t3 for the sigpath nassrv1 by specifying only some of the GTD parameters.

Enabling Partial GTD Support

The following MML commands enable partial GTD support indicated by gtdcaptypeprop = t3 for sigpath nassrv1.

prov-add:extnode:name="nas1",type="AS5300",desc="NAS 1"
prov-add:naspath:name="nassrv1",desc="Service to nas1",extnode="nas1",mdo="BELL_1268_C3"
prov-add:gtdparam:name="t3",desc="GTD subset 3", 
gtdparamstring="CPC,CGN,BCI,CPN,CID,OBI,OCN,RBI,CHN,HOC,RGN",
overrideString="CGN.noa,CPN.noa"
prov-add:gtdparam:name="t1",gtdparamstring="ALL"
prov-add:gtdparam:name="t5",gtdparamstring="CPN,CGN,CIC,CPC,BCI"
prov-add:sigsvcprop:name="nassrv1",gtdcaptypeprop="t3"

Note If you enable GTD on your system, the following ISUP parameter codes are always allowed, regardless of your individual selections: EVI, GCI, PCI, PRN, MCI, and FDC.


Changing from Partial to All GTD Support

The following MML command changes GTD support from gtdcaptypeprop = t3 to gtdcaptypeprop = t1. All GTD is supported as indicated by gtdcaptypeprop = t1 for nassrv1.

prov-ed:sigsvcprop:name="nassrv1",gtdcaptypeprop="t1"

Disabling GTD Support

The following MML command disables GTD support for nassrv1. The value of gtdcaptypeprop is set to default (t0) for sigpath naasrv1.

prov-dlt:sigsvcprop:name="nassrv1","gtdcaptypeprop"

NOA Configurable Mapping

The configurable NOA mapping is supported in Cisco PGW 2200 Softswitch software Release 9.4(1) and allows you to translate an external NOA value to any internal NOA value for inbound or outbound calls. This mapping is limited to protocols (and variants) that support NOA, which are: Q.761, Q.761-97, Q.767, and ANSI.

Configurable NOA mapping is determined by how you configure Configurable (NOA) Translation Tables (CTT) for inbound line values to internal CC NOA values (See "DefaultDNNOA" in "Planning for Provisioning" for internal NOA values) and internal CC NOA values to outbound line values. The CTT can be added on a per sigpath basis.

Though the NOA is present in many parameters in different protocols, only the following numbers are supported:

Called party number

Calling party number

Original called party number

Redirecting number

Redirection number

Generic number

Each number has an inbound and outbound CTT. Although in most cases the inbound and out bound NOA translation values would be the same, they can be different.

Depending on the CTT configuration, Type B (calls between the same SS7 protocol variant) exchange operation may be affected. For example, without CTT configured, for some non-called party numbers, a line NOA value may be out of range, and this information would be passed from the ingress to the egress and populated in the egress message.

However, if an inbound CTT is configured that translates the inbound line out-of-range NOA value to a value that is in range, the call is then handled as a normal call. The outbound message on the egress side may or may not contain the same line NOA value as the ingress depending on the outbound CTT.

The following sections describe the MML commands used to provision the NOA configurable mapping feature and the corresponding line translate file (linexlate.dat).

Provisioning the NOA Configurable Mapping Feature

The following MML command syntax is used to add an entry to the linexlate.dat file.

mml> prov-add:linexlate:name=<MML name>,DESC=<Description>,SVC=<MML name>,PARAMETER=<param value>, 
DIRECTION=<param value>,NUMBER=<param value>,INTNOA=<param value>,EXTNOA=<param value>
 
   

where:

MML name = an NOA translate table entry name, as many as 20 characters in length, or "all"
Description = a more descriptive name for the entry, which can be as many as 128 characters in length
Parameter = 1
Direction = 0 or 1
Number = 0 through 5
Intnoa = 0 through 52
Extnoa = 0 through 127

For adding an entry, none of the parameters are optional, all must be present, as shown in the following example.

mml> prov_add:linexlate:name="noa1",desc="noa in calling 10",svc="ss7svc1",parameter="1", 
direction="in",number="calling",intnoa=17,extnoa=10
 
   

The following MML command syntax is used to delete an entry from the linexlate.dat file.

mml> prov-dlt:linexlate:name=<MML name>
 
   

Where MML name is the NOA translate table entry.

For example:

mml> prov-dlt:linexlate:name="noa1"
 
   

The following MML command syntax is used to retrieve an entry in the linexlate.dat file.

prov-rtrv:linexlate:name=<MML name>
 
   

Where the MML name is the name of an NOA translate table entry.


Note The line translation table contains no default entries, since all parameters must be entered to create a configuration entry.


Adding an NOA Value to the LineXlate File for Inbound Calls

Perform the following steps to provision the Configurable NOA Mapping Feature.


Step 1 Open a provisioning session by using the following MML command:
mml> prov-sta::srcver="linexlt1",dstver="mml_01"


Caution Do not name the destination directory "active" or "new." The names "active" and "new" have special meanings in the Cisco PGW 2200 Softswitch software. Starting a provisioning session with a source version name of "new", is to be done only the first time provisioning is performed.

Step 2 Dynamically add the internal NOA and line NOA property for LineXlate.
mml> prov-add:linexlate:name="noa1",desc="noa in calling 10",svc="ss7svc1",
direction="in",number="calling",intnoa=17,extnoa=10

Step 3 Commit the changes.
mml> prov-cpy

Step 4 Use prov-rtrv:linexlate:name="noa1" to verify the property was added correctly.
mml> prov-rtrv:linexlate:name="noa1"


For more information on provisioning for the rest of the Cisco PGW 2200 Softswitch software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Deleting an NOA Value from the LineXlate File

Perform the following steps to delete the configured provisioned LineXlate entry dynamically.


Step 1 Open a provisioning session by using the following MML command:
mml> prov-sta::srcver="01",dstver="mml_02"

Step 2 Dynamically delete the internal NOA and line NOA property for LineXlate.
mml> prov-dlt:linexlate:name="noa1"

Step 3 Commit the changes.
mml> prov-cpy

Step 4 Use prov-rtrv:linexlate:name="noa1" to verify the property was deleted correctly.
mml> prov-rtrv:linexlate:name="noa1"


Adding an NOA Value to the LineXlate File for Outbound Calls

Perform the following steps to provision the line NOA and internal NOA property for an outbound message.


Step 1 Open a provisioning session by using the following MML command:
mml> prov-sta::srcver="02",dstver="mml_03"

Step 2 Dynamically add the internal NOA and line NOA property for LineXlate.
mml> prov-add:linexlate:name="noa2",desc="noa in calling 10",svc="ss7svc1",
direction="out",number="called",intnoa=17,extnoa=10

Step 3 Commit the changes.
mml> prov-cpy

Step 4 Use prov-rtrv:linexlate:name="noa2" to verify the property was added correctly.
mml> prov-rtrv:linexlate:name="noa2"


Deleting an NOA Value from the LineXlate File

Perform the following steps to delete the configured provisioned LineXlate entry dynamically.


Step 1 Open a provisioning session by using the following MML command:
mml> prov-sta::srcver="03",dstver="mml_04"

Step 2 Dynamically delete the LineXlate table entry.
mml> prov-dlt:noaxlate:name="noa2"

Step 3 Commit the changes.
mml> prov-cpy

Step 4 Use prov-rtrv:linexlate:name="noa2" to verify the property is deleted correctly.
mml> prov-rtrv:linexlate:name="noa2"


Validation Rules

All parameters must be present.

The sigpath must have been provisioned.

Parameter, direction, number, intnoa, and linenoa are range validated.

A check is made to verify there is not a duplicate entry.


Note The Configured Translation table contains no default entries since all parameters must be entered to create a configuration entry.


Adding M3UA and SUA Connections

This section contains the procedures to perform to add M3UA and SUA connections to your Cisco PGW 2200 Softswitch. Provision the components that enable the Cisco PGW 2200 Softswitch to support M3UA and SUA in the following order.

Adding a Cisco ITP External Node

Adding Point Codes (OPC, DPC, and APC)

Adding M3UA and SUA Routing Keys

Adding SS7 Signaling Services

Adding M3UA and SUA Routes

Adding SS7 Subsystems

Adding M3UA and SUA Signaling Gateway Processes

Adding IP Routes (optional)

Adding SCTP Associations

Adding a Cisco ITP External Node

Add a Cisco IP Transfer Point (ITP) external node named itp1 by enter the following MML command.

mml> prov-add:extnode:name="itp1",desc="2651 ITP",type="itp",group=1 

Note Only as many as two ITPs are allowed in the same group.


Adding Point Codes (OPC, DPC, and APC)

Add an OPC named opc1 by entering the following MML command.

mml> prov-add:opc:name="opc1",desc="Originating PC 1",netaddr="2.1.4",netind=2, 
type="trueopc" 
 
   

Note To support M3UA and SUA interfaces, the value of the type parameter must be set to trueopc.


Add a DPC named dpc1 by entering the following MML command.

mml> prov-add:DPC:NAME="dpc1",DESC="DPC1",NETADDR="1.1.5",NETIND=2 
 
   

Add an APC named apc1 by entering the following MML command.

mml> prov-add:apc:NAME="apc1",DESC="apc1",NETADDR="1.2.4",NETIND=2 

Adding M3UA and SUA Routing Keys

Add an M3UA routing key named m3uakey1 by entering the following MML command.

mml> prov-add:M3UAKEY:NAME="m3uakey1",OPC="opc1",DPC="dpc1",SI="ISUP",ROUTINGCONTEXT=10 
 
   

Add an SUA routing key named suakey1 by entering the following MML command.

mml> prov-add:SUAKEY:NAME="suakey1",OPC="opc1",APC="apc1",localssn=200,ROUTINGCONTEXT=20 

Adding SS7 Signaling Services

Add an SS7 signaling service named ss7svc1 by entering the following MML command.

mml> prov-add:SS7PATH:NAME="ss7svc1",DESC="OPC1 to INET DPC1",M3UAKEY="m3uakey1", 
DPC="dpc1",MDO="Q761_BASE" 

Adding M3UA and SUA Routes

Add an M3UA route named m3uarte1 by entering the following MML command.

mml> prov-add:M3UAROUTE:NAME="m3uarte1",DESC="M3UA Rte 1",OPC="opc1",DPC="dpc1", 
EXTNODE="itp1" 
 
   

Add an SUA route named suarte1 by entering the following MML command.

mml> prov-add:SUAROUTE:NAME="suarte1",DESC="SUA Rte 1",APC="apc1",OPC="opc1", 
EXTNODE="itp1",remotessn=40 

Adding SS7 Subsystems

Add an SS7 subsystem named prepaid by entering the following MML command.

mml> prov-add:SS7SUBSYS:NAME="prepaid",DESC="prepaid rte-ssn 48",SUAKEY="suakey1", 
SVC="scp",PROTO="SS7-ITU",TRANSPROTO="SUA",stpscpind=2,remotessn=48 

Adding M3UA and SUA Signaling Gateway Processes

Add an SGP for an SUA path named sua-sgp1 by entering the following MML command.

mml> prov-add:SGP:NAME="sua-sgp1",DESC="SUA SGP 1 - ITP1",EXTNODE="itp1" 

Adding IP Routes (optional)

IP routes are required if your Cisco PGW 2200 Softswitch hosts are not on the same subnet as the Cisco access servers.

Add an IP route named iprte1 by entering the following MML command.

mml> prov-add:IPROUTE:NAME="iprte1",DESC="IP Route 1",dest="192.0.2.17",ipaddr="IP_Addr1", 
netmask="255.255.255.0",nexthop="10.82.82.1" 

Adding SCTP Associations

Add an SUA association named sua-assoc1 by entering the following MML command.

mml> prov-add:ASSOCIATION:NAME="sua-assoc1",DESC="M3UA Association 1",TYPE="SUA", 
SGP="sua-sgp1",IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",PEERADDR1="209.165.200.229", 
PEERADDR2="209.165.201.5" 
 
   

Optimizing PGW-to-ITP Routing with MAP Query

This feature allows the Cisco PGW 2200 Softswitch to optimize routing based on a subscriber's location within a mobile network. If the ItpActionRequest property is set to map-app, the system sends a customized SIP invite to the ITP to return the location of the mobile subscriber. The customized SIP invite causes the ITP (if it is capable) to send an SS7 Mobile Application Part (MAP) query to the service provider home location register (HLR) for the mobile subscriber's current mobile station roaming number (MSRN). The Cisco PGW 2200 Softswitch then routes the call to the closest gateway mobile switching center (MSC) based upon the new MSRN.

Figure 5-4 shows a typical deployment for this feature.

Figure 5-4 Typical Deployment for PGW-to-ITP Routing with MAP Query

If the Cisco PGW 2200 Softswitch is unable to optimize the call routing based on the MSRN, it continues to route calls based on the mobile subscriber's MSISDN (telephone number). The Cisco PGW 2200 Softswitch routes calls based on an MSISDN by means of cause analysis.

The following procedure provisions the Cisco PGW 2200 Softswitch to send the customized SIP invite to the ITP, requesting a MAP query of the subscriber's MSRN. It also sets up alternative routing based on the subscriber's MSISDN; the system uses the alternative routing if it does not receive an MSRN from the ITP.


Step 1 Create two trunk groups, one for the MSRN (when the ITP returns an MSRN), and a second trunk group for the MSISDN (when the ITP does not return an MSRN). In the following examples, trunk group 907 is for the MSRN and trunk group 1001 is for the MSISDN (or if routing on trunk group 907 fails):

mml> prov-add:rttrnk:weightedTG="OFF",name="rg907",trnkgrpnum=907
mml> prov-ed:rttrnk:name="rg907",trnkgrpnum=1001
mml> prov-add:rtlist:name="rlst907",rtname="rg907",distrib="OFF"
 
   

Step 2 Enter the following command to enable the MAP request on the trunk group for the MSRN:

mml> prov-ed:trnkgrpprop:name="xxx",ItpActionRequest="map-app"
 
   

Note If you need to disable the MAP request, enter the following command
prov-dlt:trnkgrpprop:name="xxx", "ItpActionRequest"


Step 3 (Optional) Advance the trunk for failed calls using the following MML commands:

mml> numan-add:resultset:custgrpid="DP00",name="tgadvset"
mml> numanadd:resulttable:custgrpid="DP00",name="tgadvset",resulttype="RETRY_ACTION", 
dw1="tgadvance",setname="tgadvset"
mml> numan-ed:cause:custgrpid="DP00",causevalue=176,setname="tgadvset"
 
   
/* The value for the internal cause code, IC_ITP_QUERY_FAIL, is 176. */
 
   

Step 4 (Optional) Switch to new a new dial plan for failed calls using the following MML commands:

mml> numan-add:dialplan:custgrpid="DP01",OVERDEC="NO"
mml> numan-add:resultset:custgrpid="DP01",name="rset-1"
mml> numan-add:resulttable:custgrpid="DP01",name="rtab-1",resulttype="ROUTE", 
dw1="rtlist1",setname="rset-1"
mml> numan-add:bdigtree:custgrpid="DP01",callside="originating",digitstring="12", 
setname="rset-1"
 
   
mml> numan-add:dpsel:custgrpid="DP00", newdp="DP01"
mml> numan-add:resultset:custgrpid="DP00",name="SwToDP01"
mml> numan-add:resulttable:custgrpid="DP00",name="SwitchDP1",resulttype="NEW_DIALPLAN", 
dw1="DP01",dw2="2",setname="SwToDP01"
mml> numan-ed:cause:custgrpid="DP00",causevalue=176,setname="SwToDP01"
 
   
/* The value for the internal cause code, IC_ITP_QUERY_FAIL, is 176. */
 
   

The provisioning examples for ITP as a MAP proxy for this feature are as follows:

cs7 variant itu
cs7 point-code 5.3.5
 
   
interface ethernet 0/0
  ip address 209.165.200.224 255.255.255.224
 
   
cs7 mapua SIP_MAP_GW sip
  client 192.0.2.1
  map-source-addr digits 1234567890 tt 0 gti 2
  gsm-send-routing-info version 2
    invoke-timer 20
 
   

For more information on the ITP provisioning, see the "Implementing a PGW SIP MAP Gateway" section in Cisco IP Transfer Point (ITP) in IOS Software Release 12.4(I5)SW4 at

http://www.cisco.com/en/US/docs/wireless/itp/itp_12_2_18_ipx/PDFs/12415sw4.pdf

You can use the following three commands to monitor ITP for this feature:

Display SIP MAP gateway information.

show cs7 mapua statistics [name of the MAP UA] 
 
   

Display Cisco IOS SIP stack statistics.

show cs7 sip statistics
 
   

Debug the MAP gateway function.

debug cs7 map-ua {all | error | packet | api}
 
   
 
   

Adding Location Labels

Using location labels allows call limiting to or from a location to ensure quality of service is maintained.

The following sections provide call limiting provisioning examples

Adding Location Labels to Trunk Groups and Sigpaths

Applying Call Limiting to a SIP Trunk Group

Applying Call Limiting to an H.323 Trunk Group

Applying Call Limiting to the DPNSS Trunk Groups

Applying Call Limiting to an SS7 ISUP Trunk Group

Applying Call Limiting to Digit Strings in a Dial Plan

Applying Call Limiting to Multiple Trunk Groups

Applying Call Limiting to IP Addresses

Applying Call Limiting to an MGCP Gateway

Playing an Announcement when the Call Limiting Threshold is Exceeded

Adding Location Labels to Trunk Groups and Sigpaths

The following MML commands were used to provision examples of location labels at sigPath and trunk group levels and is the first provisioning session started on the Cisco PGW 2200 Softswitch:


Caution Do not name the destination directory "active" or "new." The names "active" and "new" have special meanings in the Cisco PGW 2200 Softswitch software. Starting a provisioning session with a source version name of "new", is to be done only the first time provisioning is performed.

prov-stp
 
   
prov-sta::srcver="new",dstver="ver1"
 
   
prov-add:loclabel:name="loclbl1",desc="local label 1",calllimit=2345
prov-add:loclabel:name="loclbl2",desc="local label 2",calllimit=6000
 
   
prov-rtrv:loclabel:name="loclbl1"
prov-rtrv:loclabel:name="loclbl2"
 
   
prov-rtrv:loclabel:"all"
 
   
locationLabel.dat 
005f0001  2345  
005f0002  6000 
 
   
 
   
prov-add:OPC:NAME="opc",DESC="The PGW point code",NETADDR="1.1.1",NETIND=2,TYPE="TRUEOPC"
prov-add:DPC:NAME="dpc1",DESC="Orig. point code",NETADDR="2.2.2",NETIND=2
prov-add:DPC:NAME="dpc2",DESC="Dest. point code",NETADDR="3.3.3",NETIND=2
prov-add:EXTNODE:NAME="dpnss-gw1",DESC="nas 2600 Backhaul",TYPE="C2600", 
ISDNSIGTYPE="IUA",GROUP=0
prov-add:EXTNODE:NAME="eisup1",DESC="external node - eisup",TYPE="MGC", 
ISDNSIGTYPE="N/A",GROUP=0
prov-add:EXTNODE:NAME="ipfas1",DESC="external node - ipfas",TYPE="C2600", 
ISDNSIGTYPE="N/A",GROUP=0
 
   
prov-add:SS7PATH:NAME="ss7svc1",DESC="SS7 service to DPC-2-2-2",MDO="ANSISS7_STANDARD", 
CUSTGRPID="1111",SIDE="network",DPC="dpc1",OPC="opc",M3UAKEY="",ORIGLABEL="loclbl1", 
TERMLABEL="loclbl2"
 
   
prov-add:DPNSSPATH:NAME="dpnss1",DESC="backhaul to nas2600",EXTNODE="dpnss-gw1", 
CUSTGRPID="1111",SIGSLOT=2,SIGPORT=1,ORIGLABEL="loclbl1", TERMLABEL="loclbl2"
 
   
prov-add:EISUPPATH:NAME="eisup-mgc01",DESC="signal service - mgc",EXTNODE="eisup1", 
CUSTGRPID="1111",ORIGLABEL="loclbl1",TERMLABEL="loclbl2"
 
   
prov-add:ipfaspath:name="ipfas-sigpath",mdo="dummy",desc="IPFAS sigpath",EXTNODE="ipfas1", 
ORIGLABEL="loclbl1",TERMLABEL="loclbl2"
 
   
 
   
prov-add:sippath:name="sip-sigpath",mdo="IETF_SIP",desc="SIP sigpath",ORIGLABEL="loclbl1", 
TERMLABEL="loclbl2"
 
   
prov-rtrv:sippath:name="sip-path"
 
   MGC-2 - Media Gateway Controller 2005-07-06 16:22:32.107 EDT
M  RTRV
   "session=egw-2:sippath"
   /* 
NAME = sip-path
DESC = sip path
MDO = IETF_SIP
ORIGLABEL =
TERMLABEL =
   */
   ;
 
   
sigPath.dat 
00150001 SS7-ANSI  ANSISS7_STANDARD  1111  0101  0  network  n  2  00130002  00130001  
00000000  00000000  0 005f0001 005f0002 
00190001 EISUP  EISUP  0000  0101  0  network  n  2  00000000  00000000  00000000  
00000000  0 005f0001 005f0002 
00340001   dummy  0000  0101  0  network  n  2  00000000  00000000  00000000  00000000  0 
005f0001 005f0002 
003e0001 SIP  IETF_SIP  0000  0101  0  network  n  2  00000000  00000000  00000000  
00000000  0 005f0001 005f0002 
00420001 SS7-ANSI  ANSISS7_STANDARD  1111  0101  0  network  n  2  00130003  00130001  
00410001  00000000  0 005f0001 005f0002 
00550001 DPNSS  DPNSS_BTNR188  1111  0101  26  network  n  2  00000000  00000000  00000000  
00000000  513 005f0001 005f0002 
 
   
 
   
prov-add:trnkgrp:name="3000",svc="sip-sigpath",type="SIP_IN",ORIGLABEL="loclbl1", 
TERMLABEL="loclbl2",selSeq="LIDL"
 
   
prov-rtrv:trnkgrp:name="3000"
 
   
MGC-01 - Media Gateway Controller 2005-07-06 16:25:36.691 EDT
M  RTRV
   "session=begon-base1:trnkgrp"
   /*
NAME = 3000
CLLI = stim-dpnss1
SVC = sip-sigpath
TYPE = SIP_IN
SELSEQ = LIDL
ORIGLABEL =
TERMLABEL =
   */
   ;
 
   
trunkGroup.dat 
00200001  3000  0000  0000  003e0001  SIP_IN  LIDL  0  N  0/0/0/0  0/0/0/0  005f0001  
005f0002 
 
   
 
   
components.dat
 
   
00570001 00010001 "LI"                 "LI Radius Protocol Family"
005f0001 00010001 "loclbl1"            "local label 1" 
005f0002 00010001 "loclbl2"            "local label 2" 
 
   

Note The XECfgParm.dat parameter, engine.CallLimitingControl controls call limiting for the Cisco PGW 2200 Softswitch platform. The parameter default value is 0, where 0 is false (call limiting disabled) and 1 is true (call limiting enabled). The following provisioning examples require engine.CallLimitingControl to be enabled (set to 1).


Applying Call Limiting Over DPNSS

The following provisioning example, see Figure 5-5, shows two gateways that are configured to be redundant with a total of 60 DS0s to PBX-2. The following sample provision shows that the service provider sets the call limiting of 10 toward PBX-2 over DPNSS from Cisco Call Managers (CCM) CCM-X and CCM-Y.

prov-add:loclabel:name="location2",calllimit=10
prov-add:DPNSSPATH:NAME="dpnss-path1",DESC="dpnss va-3745-2",EXTNODE="va-3745-2", 
CUSTGRPID="1111",SIGSLOT=1,SIGPORT=0
prov-add:trnkgrp:name="7000",type="TDM_DPNSS",svc="dpnss_path1",clli="7000',selseq="ASC", 
qable="N",origlabel="location2",termlabel="location2"

Figure 5-5 DPNSS Call Limiting Scenario

Applying Call Limiting to Incoming and Outgoing Trunk Groups

The following provisioning scenario, see Figure 5-6, is useful when multiple enterprises are sending their traffic through the same trunking media gateway. Call limiting used in this example can enforce limits so a certain enterprise cannot use too many trunking ports to the exclusion of other enterprises connected to the PSTN by the Cisco PGW 2200 Softswitch.

To provision this, create a label, for example LABELCCMY with a value of 12, then in the B-number analysis, set the LOC_LABEL to the label (LABELCCMY) you just created. In the A-number analysis, select a dial plan based on the LOC_LABEL to the XX LABEL.

If the CCM has a prefix of 300XXX, the incoming calling limit for 300XXXX is 100 and the outgoing calling limit for 300XXXX is 12.

This allows you to define the incoming and outgoing trunk group call limiting separately.

//For outgoing call limit
prov-add:loclabel:name="location1",calllimit=12
numan-add:resultset:custgrpid="1111",name="set300"
numan-add:resulttable:resulttype="LOC_LABEL",dw1="location1",setname="set300", 
custgrpid="1111",name="resultloc300"
numan-add:resulttable:custgrpid="1111",name="result300",resulttype="ROUTE",dw1="rtlist3", 
setname="set300"
numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="300", 
setname="set300"   
 
   
//For incoming call limit
numan-add:Numan-add:resultset:custgrpid="1111"?name="set301"
numan-add:resulttable:resulttype="LOC_LABEL",dw1="location1",setname="set301", 
custgrpid="1111",name="resultloc301"
numan-add:adigtree:custgrpid="1111",callside="originating",digitstring="300", 
setname="set301" 

Figure 5-6 Incoming and Outgoing Trunk Group Call Limiting Scenario

B-number Based Call Limiting Scenario

The following provisioning scenario, see Figure 5-7, is useful when limiting the number of calls based on B-numbers. If the B-number is 300XXX and call limiting for 300XXXX is 100.

prov-add:loclabel:name="location1",calllimit=100
numan-add:resultset:custgrpid="1111",name="set300"
numan-add:resulttable:resulttype="LOC_LABEL",dw1="location1",setname="set300", 
custgrpid="1111",name="resultloc300"
numan-add:resulttable:custgrpid="1111",name="result300",resulttype="ROUTE",dw1="rtlist3", 
setname="set300"
numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="300", 
setname="set300"
 
   

Figure 5-7 B-number Based Call Limiting Scenario

Applying Call Limiting to a SIP Trunk Group

The following provisioning example shows that call limiting of 10 is applied to the incoming and outgoing SIP trunk groups.

//location label for call limiting of 10 
prov-add:loclabel:name="location1",calllimit=10  
//provision SIP path 
prov-add:SIPPATH:NAME="sip-path",DESC="SIP path",MDO="IETF_SIP",ORIGLABEL="",TERMLABEL="" 
//provision SIP link
prov-add:SIPLNK:NAME="sip-link",DESC="SIP link",SVC="sip-path",IPADDR="IP_Addr1", 
PORT=5060,PRI=1 
//provision SIP route trunk 
prov-add:siprttrnkgrp:name="7000",url="192.0.2.18",version="2.0",cutthrough=2,srvrr=2, 
extsupport=1  
//provision outgoing call limit for SIP trunk group 
prov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", 
origlabel="location1",termlabel="location1" 
//provision incoming call limit for SIP trunk group 
prov-add:trnkgrp:name="7000",type="SIP_IN",svc="sip-path",clli="",selseq="LIDL", 
origlabel="location1",termlabel="location1" 

Applying Call Limiting to an H.323 Trunk Group

The following provisioning example shows that call limiting is applied to an H.323 trunk group for both incoming and outgoing trunk groups (for example, call limit for the H.323 side is 20).

prov-add:loclabel:name="location2",calllimit=20
//provision EISUP path to HSI, PGW are connected with H.323 network by HSI 
prov-add:EISUPPATH:NAME="eisup-hsi",DESC="to orchid",EXTNODE="sh-hsi",CUSTGRPID="1111" 
//provision call limit for H.323 trunk group
prov-add:trnkgrp:name="6000",CLLI="sh-daisy",svc="eisup-hsi",type="IP",selseq="ASC", 
qable="N",origlabel="location2",termlabel="location2" 

Note Either the EISUP path or the HSI trunk group can be provisioned with location label.


Applying Call Limiting to the DPNSS Trunk Groups

The following provisioning example shows that call limiting is applied to the DPNSS trunk groups (for example, call limit for DPNSS trunk group is 30) on both terminating and originating trunk groups.

prov-add:loclabel:name="location3",calllimit=30
//provision DPNSS path
prov-add:DPNSSPATH:NAME="dpnss-path2",DESC="dpnss va-3745-2",EXTNODE="va-3745-2", 
CUSTGRPID="1111",SIGSLOT=1,SIGPORT=1,ORIGLABEL="",TERMLABEL="" 
//provision call limit for DPNSS trunk group
prov-add:trnkgrp:name="5331",type="TDM_DPNSS",svc="dpnss-path1",clli="va-3745-2", 
selseq="ASC",qable="N",origlabel="location3",termlabel="location3" 

Applying Call Limiting to an SS7 ISUP Trunk Group

The following provisioning example shows that call limiting is applied to SS7 (for example, the call limit for the SS7 trunk group is 40) either incoming or outgoing, and make an announcement when the number of calls exceeds the call limit threshold.

//call limit is 10 
prov-add:loclabel:name="location1",calllimit=10 
//provision both incoming and outgoing call limit for SS7 trunk group
prov-add:trnkgrp:name="7000",type="TDM_ISUP",svc="ss7svc1",clli="7000',selseq="ASC", 
qable="N",origlabel="location1",termlabel="location1" 
 
   
//The following is to provision incoming call limiting
 
   
//provision incoming call limit for SS7 trunk group
prov-add:trnkgrp:name="7000",type="TDM_ISUP",svc="ss7svc1",clli="7000',selseq="ASC", 
qable="N",origlabel="location1",termlabel="" 
 
   
//The following is to provision outgoing call limiting 
 
   
//provision outgoing call limit for SS7 trunk group
prov-add:trnkgrp:name="7000",type="TDM_ISUP",svc="ss7svc1",clli="7000',selseq="ASC", 
qable="N",origlabel="",termlabel="location1" 
 
   
//The following is to play an announcement when calls are rejected due to exceeding 
threshold set by limiting
 
   
//announcement provisioning 
numan-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2",interval="3", 
locationstring="xyz.aud" 
//provision local announcement
numan-add:resulttable:custgrpId="1111",name="result60",resulttype="ANNOUNCEMENT", 
dw1="123",dw2="0",dw4="1",setname="set1" 
//call limit reject internal code is "171"
numan-add:cause:custgrpid="1111",causevalue="171",setname="set1" 

Applying Call Limiting to Digit Strings in a Dial Plan

The following provisioning examples show that call limiting applied to A- and B-numbers by the dial plan and digits analysis.

1. This is the example that all incoming calls that B-numbers have prefix of 300XXX, calling limiting for 300XXXX is set to 100.

prov-add:loclabel:name="location2",calllimit=100
// provision a resultset 
numan-add:resultset:custgrpid="1111",name="set200"
//provision call limit location label in resultset 
numan-add:resulttable:resulttype="LOC_LABEL",dw1="location2",setname="set200", 
custgrpid="1111",name="resultloc200" 
//provision route resulttable
numan-add:resulttable:custgrpid="1111",name="result200",resulttype="ROUTE",dw1="rtlist2", 
setname="set200" 
//provision Bdigtree for B-number 300XXX
numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="300", 
setname="set200"
 
   

2. For example, if all incoming calls that A-numbers have prefix of 300XXX, calling limiting for 300XXXX is set to 100.

numan-add:resultset:custgrpid="1111"ÅCname="set201" 
//provision call limit location label in resultset 
numan-add:resulttable:resulttype="LOC_LABEL",dw1="location2",setname="set201", 
custgrpid="1111",name="resultloc201" 
//provision Adigtree for A-number 300XXX
numan-add:adigtree:custgrpid="1111",callside="originating",digitstring="300", 
setname="set201" 

Applying Call Limiting to Multiple Trunk Groups

The following provisioning example shows that one calling label can be applied to multiple trunks and trunk groups, which are either incoming or outgoing.

prov-add:loclabel:name="location3",calllimit=100
//location label 3 can be used as SIP incoming trunk group 7000 
prov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", 
origlabel="location3" 
//location label 3 can be used as SIP outgoing trunk group 8000 
prov-add:trnkgrp:name="8000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", 
termlabel="location3" 
//location label 3 can be used as DPNSS trunk group 9000
prov-add:trnkgrp:name="9000",type="TDM_DPNSS",svc="dpnss-path1",clli="va-3745-2", 
selseq="ASC",qable="N",origlabel="location3",termlabel="location3" 

Applying Call Limiting to IP Addresses

The following provisioning example shows that the call limiting feature can be applied to source and destination IP addresses indirectly by the dial plans.

1. Call limiting to the other peer PGW IP addresses.

Assuming a peer Cisco PGW 2200 Softswitch IP address is 192.0.2.19, call limiting for EISUP is 100, call limiting can be provisioned in EISUP for the sigPath or trunk group.

Option 1: Setting call limiting with an EISUP sigPath.

prov-add:loclabel:name="location5",calllimit=100
//provision call limit in EISUP path 
prov-add:EISUPPATH:NAME="eisup-orkid",DESC="to orchid",EXTNODE="sh-orchid", 
CUSTGRPID="1111",ORIGLABEL="location5",TERMLABEL="location5" 
//provision EISUP IP link 
prov-add:IPLNK:NAME="elinkorchid1",DESC="Link to orchid",SVC="eisup-orchid", 
IPADDR="IP_Addr1",PORT=8001,PEERADDR="192.0.2.19",PEERPORT=8001,PRI=1,IPROUTE=""
 
   

Option 2: Set call limiting with an EISUP trunk group, for example, the trunk group is 6000.

prov-add:loclabel:name="location5",calllimit=100
prov-add:EISUPPATH:NAME="eisup-orkid",DESC="to orchid",EXTNODE="sh-orchid", 
CUSTGRPID="1111"
//provision EISUP IP link 
prov-add:IPLNK:NAME="elinkorchid1",DESC="Link to orchid",SVC="eisup-orchid", 
IPADDR="IP_Addr1",PORT=8001,PEERADDR="192.0.2.20",PEERPORT=8001,PRI=1,IPROUTE=""
//provision call limit in EISUP trunk group
prov-add:trnkgrp:name="6000",type="IP",svc="eisup-daisy",clli="sh-daisy",selseq="ASC", 
origlabel="location5",termlabel="location5" 
 
   

2. Call limiting for other SIP servers.

Assuming a SIP proxy IP address is 192.0.2.21, call limiting is set to 100, call limiting can be provisioned in the trunk group, for example, trunk group 7000.

prov-add:loclabel:name="location6",calllimit=100
//provision SIP path 
prov-add:SIPPATH:NAME="sip-path",DESC="SIP path",MDO="IETF_SIP",ORIGLABEL="",TERMLABEL="" 
//provision SIP link
prov-add:SIPLNK:NAME="sip-link",DESC="SIP link",SVC="sip-path",IPADDR="IP_Addr1", 
PORT=5060,PRI=1 
//provision SIP route trunk 
prov-add:siprttrnkgrp:name="7000",url="192.0.2.21",version="2.0",cutthrough=2,srvrr=2, 
extsupport=1 
//provision call limit in SIP trunk group
prov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", 
origlabel="location6",termlabel="location6"

Applying Call Limiting to an MGCP Gateway

The following example shows that call limiting is applied to an MGCP gateway with IP address of 192.0.2.22, the gateway has 4 trunk groups, which are controlled by ss7svc1, and the call limiting is set to 20.

prov-add:loclabel:name="location8",calllimit=20
//provision MGCP path 
prov-add:MGCPPATH:NAME="mgcp530011",DESC="MGCP service to AS-5300-11",EXTNODE="va-5300-11" 
//provision IP link
prov-add:IPLNK:NAME="clink11-1",DESC="MGCPlink to sh-5300-11",SVC="mgcp530011", 
IPADDR="IP_Addr1",PORT=2427,PEERADDR="192.0.2.22",PEERPORT=2427,PRI=1,IPROUTE="" 
//provision call limit for SS7 sigPath
prov-add:ss7path:name="ss7svc1",desc="ss7 path",dpc="dpc1",opc="opc",mdo="Q761_BASE", 
SIDE="network",origlabel="location8",termlabel="location8" 

Playing an Announcement when the Call Limiting Threshold is Exceeded

The following example shows that an announcements can be made when calls are rejected due to exceeding the threshold set by call limiting.

//announcement provisioning 
numan-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2",interval="3", 
locationstring="xyz.aud" 
//local announcement
numan-add:resulttable:custgrpId="1111",name="result60",resulttype="ANNOUNCEMENT", 
dw1="123",dw2="0",dw4="1",setname="set1" 
//call limit reject internal code is "171"
numan-add:cause:custgrpid="1111",causevalue="171",setname="set1" 
 
   

Scaling System Components

After you have configured your system components, you can begins scaling your system. Keep the following in mind when scaling.


Tip A maximum of 6 OPCs can be supported per Cisco PGW 2200 Softswitch.
Enter routing information for the OPC before creating the C7 IP link.
For each OPC added, you must specify a different local port for each C7 IP link.
Provision a maximum of 32 links per local port number. Specify another port number for each additional group of 32 links. As many as 192 links can be supported per Cisco PGW 2200 Softswitch.
Planning for future network expansion by spreading the linksets evenly across the Control Channels is suggested. Failure to do so will require the linksets to be removed from service to add more links.
As many as 256 NASs can be supported. When creating IP links to the NASs, increment the MGC port number after 32 links have been added. Be sure to set the NAS RLM to match the MGC RLM port value.


Dynamically Configuring the Input/Output Channel Controller

When dynamically configuring the IOCC, evenly distribute number of channels associated with one channel controller. For different signaling service, there are different rules when associating channels with channel controllers. The number of links associated with a channel controller is configurable on a protocol family basis through parameters contained in XECfgParm.dat. If the number of links exceeds the limit defined in XECfgParm.dat, a new instance of channel controller is created.

The naming convention for creating a new channel controller is the first five characters of the protocol family, plus a dash (-), and <num>, where num is number of channel controllers per protocol family created so far.

Table 5-10 Scaling Links per Protocol Family 

Signaling Type
Protocol Family
Criteria for a Unique IOCC
Criteria for a Valid Link (Channel)
Parameter in XECfgParm.dat (Default maximum number of links)

NAS

PRIIP

Port number.

Number of links.

When a channel controller is created, the RLM port number is created as the property port for this channel with the value of the actual port number (minus 1) in properties.dat. The format is:

<IOCC MML Name>.port = <port number> - 1

Local port and peer port must be the same.

The port number must always be an odd number.

The number of links on the same port cannot exceed the maximum number of links specified in XECfgParm.dat.

Links associated with the same signaling service must use the same port number. (that is, redundant links).

Redundant links do not count when validating the maximum number of links per IOCC.

MaxNumLinks

(32)

IPFAS

PRIL3

Number of links.

Links associated with the same port number cannot be split over different channel controllers.

The number of links on the same port cannot exceed the maximum number of links specified in XECfgParm.dat.

Links associated with the same signaling service must use the same port number. (that is, redundant links).

Redundant links do not count when validating the maximum number of links per IOCC.

MaxNumPRIL3Links

(168)

MGCP

MGCP

Number of links.

Links associated with the same port number cannot split over different channel controllers.

The number of links on the same port cannot exceed the maximum number of links specified in XECfgParm.dat.

Links associated with the same signaling service must use the same port number. (that is, redundant links).

Redundant links do not count when validating the maximum number of links per IOCC.

MaxNumMGCPLinks

(1000)

SGCP

SGCP

Number of links.

 

MaxNumLinks (32)

EISUP

EISUP

Number of links.

 

MaxNumLinks (32)

FAS

ISDNPRI

DPNSS

Number of links.

 

MaxNumLinks (32)

TCAP
OverIP

TCAP
OverIP

Number of links.

 

MaxNumLinks (32)

S77

SS7-ANSI

SS7-UK

SS7-ITU

SS7-China

SS7-Japan

Protocol Family

Switch Type

OPC

Number of links.

Protocol Family

Switch Type

MaxNumLinks (32)

 

 

 

SS7-ANSI

0

 

 

 

 

SS7-China

0, 5

 

 

 

 

SS7-ITU

0, 5

 

 

 

 

SS7-Japan

0, 10

 

 

 

 

SS7-UK

0, 5

 


Table 5-11 Maximum Scaling Limits for the SS7 Components 

Component
Scaling Limit

SS7 IOCC Instances

6

Linksets per SS7 IOCC

16

Links per SS7 IOCC

32

DPCs per SS7 IOCC

256

True OPCs per SS7 IOCC

1

Routes per SS7 IOCC

512

Protocol families per SS7 IOCC

1

Switch types per SS7 IOCC

1

Links per Cisco PGW 2200 Softswitch*

192

Linksets per Cisco PGW 2200 Softswitch*

96

True OPCs per Cisco PGW 2200 Softswitch*

6

DPCs per Cisco PGW 2200 Softswitch*

600

Routes per Cisco PGW 2200 Softswitch*

1200

Capability point codes (8 per IOCC)

48

M3UA true OPCs per Cisco PGW 2200 Softswitch

64

M3UA routes per OPC/DPC pair per Cisco PGW 2200 Softswitch

2

M3UA SGPs per Cisco PGW 2200 Softswitch

96

M3UA signaling services per Cisco PGW 2200 Softswitch

1536

* Indicates the component must be spread evenly across the maximum number of IOCC instances.


Provisioning Examples

The following sections provide provisioning examples for Cisco PGW 2200 Softswitch operating conditions.

Configuring Two IP Addresses on the MGW to One IP Address on a NAS

When configuring an Cisco PGW 2200 Softswitch with dual Ethernet interfaces to a NAS with a single IP address, there is not IP redundancy between the Cisco PGW 2200 Softswitch and the NAS. Even though there are two signal paths defined from the Cisco PGW 2200 Softswitch to the NAS, in the Solaris environment, only one path is recognized. This means only one IP address on the NAS is used for RLM signaling. Thus, a single Ethernet interface failure at the Cisco PGW 2200 Softswitch can be a single point of failure between the Cisco PGW 2200 Softswitch and the NAS even though the Cisco PGW 2200 Softswitch has another Ethernet interface that could communicate with the NAS.

The reason for this is that the Solaris routing table does not use two different routes to the same destination at the same time. The Solaris routing tables does not use the source address to determine the path just the destination address. Since both Cisco PGW 2200 Softswitch signal channels have the same destination, they are assigned the same route. However, since both signal channels from the NAS have different destinations, they are assigned two different paths.

This feature allows the I/O Channel Manager process of the Cisco PGW 2200 Softswitch to change the Solaris routing table based on the state of the Ethernet interfaces of the Cisco PGW 2200 Softswitch. If the hme0 interface fails, then the Solaris routing table is been updated to use the hme1 interface to get to the NAS. This affects the routes of both signal channels. The routes used from the NAS to the Cisco PGW 2200 Softswitch has not changed, therefore the signal channel that uses hme0 will be out of service.

To establish two signal paths in the Solaris environment, two IPLNKs must be provisioned on the Cisco PGW 2200 Softswitch for each NASPATH to the NAS. These two IPLNKs have the same PORT, PEERPORT, PEERADDR, NETMASK, and SVC values. However, the two IPLNKs have different IPADDR, IF, and NEXTHOP values.

For each IPLNK, the NEXTHOP is the IP address of the router on the subnet of the IPADDR that is used to get to the NAS. Be sure the IF of each IPLNK matches the ENETIF corresponding to the IP address of the IPADDR.

The Cisco PGW 2200 Softswitch uses the NEXTHOP, PEERADDR, and NETMASK values of the IPLNK to define a static IP route to be put in the Solaris routing table. The destination of the IP route is determined by ANDing the NETMASK with the PEERADDR.

The NETMASK value determines if the IP route is for a subnet or for an individual NAS. The default value of 255.255.255.255 causes an IP route to be defined for each individual NAS. If a subnet NETMASK is used, multiple NASs on the same subnet share the same two IP routes.

Only one of the two IP routes to the same destination and NETMASK are in the Solaris routing table at a time. If both interfaces are in service, the Cisco PGW 2200 Softswitch picks one of the two IP routes to the NAS. If the Ethernet interface associated with the IP route that is in the Solaris routing table fails, the Cisco PGW 2200 Softswitch deletes that IP route from the Solaris routing table and puts the other IP route to the same destination and NETMASK in the Solaris routing table. The original IP route is not restored when the Ethernet interface associated with it is restored. The new IP route remains in the Solaris routing table unless the interface associated with it fails.


Note If you want to use proxy ARP and host routes, the NEXTHOP parameter can be set to the local address by using one of the following special strings: IP_Addr1 or IP_Addr2. This is translated into an actual local address in the same way as the IPADDR parameter. The NETMASK is set to 255.255.255.255 to produce a host route instead of a subnet route.


The following three alarms are associated with this configuration.

The first alarm, IP RTE FAIL, is generated against an IPLNK or IPSESSION that is provisioned with a next hop address if the system failed to add the required route. This could be due to an invalid or conflicting parameter.

The second alarm, IP CONF RTE FAIL, is generated when an IPLNK or IPSESSION is not using the route that it is configured to use. A conflicting route generated by another signal channel or by another process can cause this.

The Cisco PGW 2200 Softswitch sets the third alarm, LIF FAIL, when it determines that the Ethernet interface used by the IPSESSON or IPLNK object is non-operational. It is cleared when the Ethernet interface becomes operational.

When set, the LIF FAIL alarm is accompanied by a log message, GEN_ERR_IPINTF_FAIL, that includes the provisioning name and operating system name of the failed Ethernet interface. An example of the provisioning name is IP_Addr1. An example of the operating system name is hme0. The error message also contains the failure cause. A cause of "Link Down" indicates the interface has lost the carrier. This can be caused by removing the cable or a failure at the Ethernet switch. A cause of "Admin Down" indicates that the interface was taken down using the UNIX command "ifconfig <interface name> down".

When cleared, the LIF FAIL alarm is accompanied by a log message, GEN_INFO_IPINTF_RECOV, that also includes the provisioning name and the operating system name of the interface.

The following is an example oh how to configure the Cisco PGW 2200 Softswitch and NAS when there are two IP address on the Cisco PGW 2200 Softswitch and one IP address on the NAS. Each NAS in the example has one NFAS group and therefore one RLM group.

The following is the example Cisco PGW 2200 Softswitch configuration file for provisioning. The NAS portion of the configuration is shown in bold.

prov-sta::srcver="new",dstver="dualEnetMGCsingleEnetGW",confirm
prov-add:CARD:NAME="MBRD",DESC="Motherboard",TYPE="EN",SLOT=0
prov-add:ENETIF:NAME="hme0",DESC="IP_Addr1,ipAddrLocalA",CARD="MBRD"
prov-add:ENETIF:NAME="hme1",DESC="IP_Addr2,ipAddrLocalB",CARD="MBRD"
 
   
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7 External Node
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:extnode:name="va-2600-56",type="SLT",desc="2611 SLT V.35"
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Point Codes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:apc:name="stp1",DESC="Own pointcode",NETADDR="1.1.1",NETIND=2
prov-add:apc:name="stp2",DESC="Own pointcode",NETADDR="1.1.2",NETIND=2
 
   
prov-add:opc:name="opc",DESC="Own pointcode",NETADDR="1.1.3",NETIND=2,type="TRUEOPC"
 
   
prov-add:dpc:name="dpc1",DESC="Destination pointcode1",NETADDR="1.1.4",NETIND=2
prov-add:dpc:name="dpc2",DESC="Destination pointcode2",NETADDR="1.1.5",NETIND=2
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Signal Services to Inet via SLT
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7PATH:NAME="ss7svc1",DESC="SS7 to dpc1",DPC="dpc1", 
         OPC="opc",MDO="Q761_BASE"
prov-add:SS7PATH:NAME="ss7svc2",DESC="SS7 to dpc2",DPC="dpc2", 
         OPC="opc",MDO="Q761_BASE"
 
   
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7 linksets
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:LNKSET:NAME="ls1",DESC="linkset 1 to stp1",APC="stp1", 
         PROTO="SS7-ITU",TYPE="IP"
prov-add:LNKSET:NAME="ls2",DESC="linkset 2 to stp2",APC="stp2",
         PROTO="SS7-ITU",TYPE="IP"
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; SS7 route
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:SS7ROUTE:NAME="rte1",DESC="opc-stp1-dpc1",
         OPC="opc",DPC="dpc1",LNKSET="ls1",PRI=1
prov-add:SS7ROUTE:NAME="rte2",DESC="opc-stp1-dpc2",  
         OPC="opc",DPC="dpc2",LNKSET="ls1",PRI=1
prov-add:SS7ROUTE:NAME="rte3",DESC="opc-stp2-dpc1",
         OPC="opc",DPC="dpc1",LNKSET="ls2",PRI=1
prov-add:SS7ROUTE:NAME="rte4",DESC="opc-stp2-dpc2",  
         OPC="opc",DPC="dpc2",LNKSET="ls2",PRI=1
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Session Sets
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:sessionset:name="c7sset1",ipaddr1="IP_Addr1",ipaddr2="IP_Addr2", 
         port=7000,peeraddr1=""10.82.82.124",peeraddr2="10.82.83.123", 
         peerport=7000,extnode="va-2600-56",TYPE="BSMV0"
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; C7IPLinks
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:C7IPLNK:NAME="ls1lk1",DESC="SS7ANSI",LNKSET="ls1",sessionset="c7sset1",
         SLC=0,PRI=1,TIMESLOT=0
prov-add:C7IPLNK:NAME="ls2lk1",DESC="SS7ANSI",LNKSET="ls2",sessionset="c7sset1",
         SLC=0,PRI=1,TIMESLOT=1
 
   
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; NAS External Nodes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:EXTNODE:NAME="va-5300-36",TYPE="AS5300",DESC="remote NAS 5300"
prov-add:EXTNODE:NAME="va-5300-37",TYPE="AS5300",DESC="remote NAS 5300"
 
   
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; NAS Signal Paths
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:NASPATH:NAME="nassrv36",DESC="remote NAS sigpath 1", 
         EXTNODE="va-5300-36",MDO="BELL_1268_C3"
 
   
prov-add:NASPATH:NAME="nassrv37",DESC="remote NAS sigpath 2",
         EXTNODE="va-5300-37",MDO="BELL_1268_C3"
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; NAS IP Links 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
   
prov-add:IPLNK:NAME="nas-lnk36a",DESC="IP link A to va-5300-36",
         SVC="nassrv36",IF="hme0",IPADDR="IP_Addr1",PORT=3001,
         PEERADDR="10.82.81.29",PEERPORT=3001,PRI=1, 
         nexthop="10.82.82.1",netmask="255.255.255.0"
 
   
prov-add:IPLNK:NAME="nas-lnk36b",DESC="IP link B to va-5300-36",
         SVC="nassrv36",IF="hme1",IPADDR="IP_Addr2",PORT=3001,
         PEERADDR="10.82.81.29",PEERPORT=3001,PRI=1, 
         nexthop="10.82.83.1",netmask="255.255.255.0"
 
   
prov-add:IPLNK:NAME="nas-lnk37a",DESC="IP link A to va-5300-37",SVC="nassrv37",
         IF="hme0",IPADDR="IP_Addr1",PORT=3001,
         PEERADDR="10.82.81.30",PEERPORT=3001,PRI=1,
         nexthop="10.82.82.1",netmask="255.255.255.0"
 
   
prov-add:IPLNK:NAME="nas-lnk37b",DESC="IP link B to va-5300-37",
         SVC="nassrv37",IF="hme1",IPADDR="IP_Addr2",PORT=3001, 
         PEERADDR="10.82.81.30",PEERPORT=3001,PRI=1,             
         nexthop="10.82.83.1",netmask="255.255.255.0"
 
   
 
   
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Bearer Channels
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
prov-add:files:name="BCFile",file="dualEnetMGCsingleEnetGW-bearChan.import",
         action="import"
 
   
prov-cpy
prov-stp
 
   
 
   

The following is the portion of one of a AS5300 configuration that deals with the IP connectivity to the Cisco PGW 2200 Softswitch and defining the NFAS and RLM groups.

!
controller T1 0
 framing esf
 clock source line primary
 linecode b8zs
 pri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 0
!
controller T1 1
 framing esf
 clock source line secondary 1
 linecode b8zs
 pri-group timeslots 1-24 nfas_d none nfas_int 1 nfas_group 0
!
controller T1 2
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 0
!
controller T1 3
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 nfas_d none nfas_int 3 nfas_group 0
!
! 
!
interface Serial0:23
 no ip address
 isdn switch-type primary-ni
 isdn incoming-voice modem
 isdn rlm-group 1
 no isdn send-status-enquiry
 isdn negotiate-bchan resend-setup
 fair-queue 64 256 0
 no cdp enable
!
interface FastEthernet0
 description production 100 Mbit hub
 ip address 10.82.81.29 255.255.255.0
 no ip route-cache
 no ip mroute-cache
 duplex full
 speed auto 
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.82.82.1 
!
rlm group 1
 server va-kent
  link address 10.82.82.53 source FastEthernet0 weight 2
  link address 10.82.83.53 source FastEthernet0 weight 1
 server va-surrey
  link address 10.82.82.55 source FastEthernet0 weight 2
  link address 10.82.83.55 source FastEthernet0 weight 1
!
!
 
   

The Solaris routing table on the Cisco PGW 2200 Softswitch is modified as a result of this configuration. This can be verified using the "netstat -rvn" command from the unix prompt. The following is a sample output based on above example for MGC1 with both Ethernet interfaces operating. The Cisco PGW 2200 Softswitch chooses the IP route associated with "IP_Addr1" (that is, hme0). Some columns have been omitted for clarity. The new entry is in bold text:

IRE Table: 
Destination	 Mask 	Gateway	Device	Flags 
------------- ---------------- ------------- ------   ----- 
10.0.81.1	255.255.255.0	10.82.82.1		UGH
10.82.82.0	255.255.255.0	10.82.82.53	hme0	U
10.82.83.0	255.255.255.0	10.82.83.53	hme1	U
224.0.0.0	240.0.0.0	10.0.1.10	hme0	U
default	0.0.0.0	10.82.82.1		UG
127.0.0.1	255.255.255.255	127.0.0.1	lo0	UH

If the hme0 interface fails, the Solaris routing table is modified to reach the NASs by hme1. The Solaris routing table from the above example appears as follows:

IRE Table: 
Destination	Mask	Gateway	Device	Flags 
--------------- ---------------- ------------- ------   ----- 
10.0.81.1	255.255.255.0	10.82.83.1		UGH
10.82.82.0	255.255.255.0	10.82.82.53	hme0	U
10.82.83.0	255.255.255.0	10.82.83.53	hme1	U
224.0.0.0	240.0.0.0	10.0.1.10	hme0	U
default	0.0.0.0	10.82.82.1		UG
127.0.0.1	255.255.255.255	127.0.0.1	lo0	UH
 
   

If the hme0 interface on MGC1 fails while the platform is active, the rtrv-iplnk shows the c7sset1-1, nas-lnnk36a, and nas-lnk37a in the OOS state.

The nas-lnk36a and nas-lnk37 have the LIF FAIL and SC FAIL alarms set. The c7sset1-1 has the LIF FAIL and IP CONNECTION FAIL alarms set. There is also be a PEER LINK A FAILURE alarm set against the ipAddrPeerA.

The C7IPLNKs, SS7PATH, and NASPATH destinations would still be in-service.

A-number Country Code Digit Removal

If the A-number Nature of Address (NOA) of the following number is international, then the Cisco PGW 2200 Softswitch can remove from 1 up to 5 leading digits (country codes):

Calling Party Number (CgPN)

Generic Number Additional Calling Party Number (GN_ACgPN)

Redirecting Number (RDN)

Original Called Number (OCN)

Presentation Number (PN)

In addition to removing the country code, the Cisco PGW 2200 Softswitch modifies the NOA value in the ISUP message from international to national.

In the following example, the user remove 12345 if the outgoing A-number contains 12345 as the leading digits (country code) on the trunk group 8000.

To use remove the A-number country code, perform the following provisioning procedure:


Step 1 Start a provisioning session as described in "Starting a Provisioning Session" section.

Step 2 Provision the digits (country code) that you want to remove from the outgoing A-number on the trunk group 8000.

mml> prov-add:trnkgrpprop:adigitccrm="12345",name="8000"
 
   

Step 3 Repeat Step 2 for each outgoing A-number digit string you want to remove.

Step 4 End the provisioning session as described in "Stopping a Configuration Session" section.


Call Reporting

You can find the provisioning procedure in the "Provisioning Call Reporting" section of Chapter 4, Provisioning Dial Plans with MML, in Cisco PGW 2200 Softswitch Release 9 Dial Plan Guide (through Release 9.7).

CODEC Capabilities and DTMF Preferential Routing

The Cisco PGW 2200 Softswitch can influence CODEC selection to IP calls (SIP and H.323 calls). Users can also 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. The Cisco PGW 2200 Softswitch supports route advance when the type of DTMF interworking does not match.

To add CODEC capabilities and DTMF preferential routing, perform the following procedure:


Step 1 Start a provisioning session as described in "Starting a Provisioning Session" section.

Step 2 Add the DTMF capability on an egress trunk group:

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 Add Level 1 (signaling path) CODEC capabilities:

mml> prov-add:sigsvcprop:name="mgcp1",GWDefaultCodecString="G.711a;PCMA" 
 
   

Step 5 Add Level 2 (trunk group) CODEC capabilities on the ingress SIP trunk group:

mml> prov-add:trnkgrpprop:name="1100",custgrpid="1111",GWDefaultCodecString="G723"
 
   

Step 6 Add Level 2 (trunk group) CODEC capabilities on the second trunk group:

mml> prov-add:trnkgrpprop:name="2200",custgrpid="1111",GWDefaultCodecString="G729"
 
   

Step 7 Add two result sets for Level 3 (dial plan) CODEC capabilities:

mml> numan-add:resultset:custgrpid="1111",name="set1"
mml> numan-add:resultset:custgrpid="1111",name="set2"
 
   

Step 8 Add two codec strings, G.729, and G.721:

mml> prov-add:codecstring:name="codec1",codecstring="G.729"
mml> prov-add:codecstring:name="codec2",codecstring="G.721"
 
   
 
   

Step 9 Add the results of the CODEC result type:

mml> numan-add:resulttable:custgrpid="1111",resultype="CODEC",dw1="codec1",dw2="1", 
setname="set1",name="rt1"
mml> numan-add:resulttable:custgrpid="1111",resulttype="CODEC",dw1="codec2",dw2="1",
setname="set2",name="rt1"
 
   

Step 10 Add the results of the ROUTE result type:

mml> numan-add:resulttable:custgrpid="1111",name="table10",resulttype="ROUTE", 
dw1="rtlist1",setname="set1"
mml> numan-add:resulttable:custgrpid="1111",name="table10",resulttype="ROUTE",
dw1="rtlist1",setname="set2"
 
   

Step 11 Add entries in the A digit tree and the B digit tree:

mml> numan-add:adigittree:custgrpid="1111",digitstring="1",callside="originating",
setname="set1"
 
   
mml> numan-add:bdigittree:custgrpid="1111",digitstring="2",callside="originating",
setname="set2"
 
   
 
   

Step 12 End the provisioning session as described in "Stopping a Configuration Session" section.


Digit Buffering for International Gateways

A sigPath property (TBufferDigitLength) that allows you to limit the digit length of the called party number (B-number) in the outgoing ISUP IAM and subsequent address message (SAM(s)). If the number of digits in the next SAM is also greater than the limit, the number of digits in the SAM is limited again, until all digits are passed in SAM(s). This is required for proper interconnection to certain international networks.

To provision digit buffering for international gateways, perform the following steps:


Step 1 Start a provisioning session as described in "Starting a Provisioning Session" section.

Step 2 Set the digit length limit by using the following MML command:

mml> prov-ed:sigsvcprop:name="ss7svc1",tbufferdigitlength="16" 
 
   

Step 3 End the provisioning session as described in "Stopping a Configuration Session" section.


DPNSS Service Interworking with Cisco CallManager Over QSIG Tunneling

This feature added a new interface for the DPNSS service interworking with Cisco CallManager using QSIG tunneling feature. It also enhances signaling interworking and feature transparency between Cisco CallManagers (CCM) and TDM-based PBXs over DPNSS and QSIG interfaces. The Cisco PGW 2200 Softswitch in this application works with single or multiple clusters of CCM over H.323 interface by using the H.323 Signaling Interface (HSI) and TDM-based private branch exchanges (PBXs) over DPNSS and QSIG. The Feature Transparency mode enables full end-to-end Route Optimization for mixed CCM and DPNSS PBX networks and also provides significant benefits by enabling call back services through QSIG tunneling.


Note Cisco CallManager (CCM) was the old name for Cisco Unified Communications Manager (CUCM).


Before you provision DPNSS service interworking with CCM over QSIG tunneling, configure the *.DisableCCBSoverTunneledQSIG parameter in the XECfgParm.dat file.

The default value (0) uses the Tunnel QSIG interface for Callback service. Setting a value of 1 selects the QBE interface for Callback service.


Note For procedures on configuring parameters in the XECfgParm.dat file, see the "Changing XECfgParm.dat File Parameters in a Running Fault Tolerant System" section of Cisco PGW 2200 Softswitch Release 9.7 Software Installation and Configuration Guide.


In the following sections, you can find the following provisioning procedures:

Provisioning Route Optimization Transit

Provisioning Route Optimization Initiated by the Cisco PGW 2200 Softswitch

Provisioning Route Optimization Responded by the Cisco PGW 2200 Softswitch

Provisioning Call Completion

Provisioning Message Waiting Indicator (with no QSIG Tunneling)

Provisioning Message Waiting Indicator (with QSIG Tunneling)

Provisioning a Customer VPN ID in a Trunk Group

Provisioning a Customer VPN ID in the Dial Plan

Provisioning Feature Transparency on QSIG Trunk Groups or sigPaths

Provisioning an H.323 EISUP Trunk Group or sigPaths for Transparent Annex M1 (Tunneled QSIG)

Provisioning Route Optimization Transit

This section describes the provisioning procedure for route optimization transit. Figure 5-8 shows a sample diagram for DPNSS route optimization transit.

Figure 5-8 DPNSS Route Optimization Transit

To provision DPNSS route optimization transit, perform the following steps:


Step 1 Start a provisioning session by using the following MML command:

mml> prov-sta::srcver="ro1",dstver="ROPR001"
 
   

Step 2 Add the DPNSS media gateway, the association, and the DPNSS signaling path:

mml> prov-add:extnode:name="va-3745-2",desc="MGW for dpnss",type="3745",isdnsigtype="IUA", 
group=0
 
   
mml> prov-add:association:name="assoc-dpnss-gw",desc="siemens pbx", extnode="va-3745-2", 
sgp="",type="IUA",ipaddr1="IP_Addr1", ipaddr2="N/A",port=9904,peeraddr1="192.0.2.30", 
peeraddr2="0.0.0.0",peerport=9904,iproute1="",iproute2="",rcvwin=18000, 
maxinitretrans=10,maxinitrto=2000,maxretrans=5,cumsackto=300,bundleto=100,minrto=300, 
maxrto=3000,hbto=2000,ipprecedence="routine",dscp="AF31",maxretransdest=3
 
   
mml> prov-add:dpnsspath:name="dpnss-path-1",desc="dpnss sigpath to Siemens PBX", 
extnode="va-3745-2",mdo="DPNSS_BTNR188",custgrpid="1111",sigslot=2,sigport=0,origlabel="",
termlabel="",subunit=0
 
   

Step 3 Modify the signaling service properties on the DPNSS signaling path:

mml> prov-add:sigsvcprop:name="dpnss-path-1",DpnssRORoutingNumberLength="3"
mml> prov-add:sigsvcprop:name="dpnss-path-1",FeatureTransparencyDisabled="1"
mml> prov-add:sigsvcprop:name="dpnss-path-1",OwnRoutingNumber="488"
 
   

Step 4 Add MGCP signaling path to the DPNSS media gateway:

mml> prov-add:MGCPPATH:name="dpnss-mgcp1",DESC="Nothing defined",extnode="va-3745-2"
mml> prov-add:IPLNK:name="dpnss-1",DESC="mgcp link to 3745",SVC="dpnss-mgcp1", 
ipaddr="IP_Addr1",port=2427,peeraddr="192.0.2.31",peerport=2427,pri=1,IPROUTE=""
mml> prov-add:SIGSVCPROP:name="dpnss-mgcp1",mgcpDomainNameRemote="S2/DS1-0/1@192.0.2.255"
 
   
 
   

Step 5 Add trunk groups, and trunks to the DPNSS media gateway:

mml> prov-add:TRNKGRP:name="3100",clli="dpnss",svc="dpnss-path-1",type="TDM_DPNSS", 
SELseq="LIDL"
 
   
mml> prov-add:SWITCHTRNK:name="1",trnkgrpnum="3100",span="ffff",cic=1,cu="va-3745-2", 
spansize=31,endpoint="s2/ds1-0/1@192.0.2.255"
mml> prov-add:RTTRNKGRP:name="3100",type=6
mml> prov-add:RTTRNK:name="rt-dpnss-3725",trnkgrpnum=3100
mml> prov-add:RTLIST:name="rtlist-dpnss-3745",rtname="rt-dpnss-3725",distrib="OFF"
mml> prov-ed:TRNKGRPPROP:name="3100",custgrpid="1111",MGCdomain="192.0.2.40"
 
   

Step 6 Add the HSI external node, sh-bighead:

mml> prov-add:EXTNODE:name="sh-bighead",desc="HSI sh-bighead",type="H323", 
isdnsigtype="N/A",GROUP=0
 
   

Step 7 Add the EISUP signaling path to the HSI:

mml> prov-add:EISUPPATH:name="eisup-bighead",desc="EISUP to HSI sh-bighead", 
extnode="sh-bighead",custgrpid="1111",origlabel="",termlabel=""
 
   
mml> prov-add:IPLNK:name="ip-bighead",desc="IP lnk to HSI sh-bighead",svc="eisup-bighead", 
ipaddr="IP_Addr1",port=8003,peeraddr="192.0.2.31",peerport=8003,pri=1,IPROUTE=""
 
   
mml> prov-add:SIGSVCPROP:name="eisup-bighead",AllowH323Hairpin="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",FeatureTransparencyDisabled="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",H323AdjunctLink="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",OOverlap="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",OwnRoutingNumber="488"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",QSIGTunnelVariant="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",TOverlap="0"
 
   

Step 8 Add trunks and trunk groups to the HSI:

mml> prov-add:TRNKGRP:name="9300",clli="EISUP2B",svc="eisup-bighead",type="IP"
mml> prov-add:RTTRNKGRP:name="9300",type=4
mml> prov-add:RTTRNK:weightedtg="OFF",name="eisup-bighead",trnkgrpnum=9300
mml> prov-add:RTLIST:name="rtlist-bighead",rtname="eisup-bighead"
 
   
mml> prov-add:TRNKGRPPROP:name="9300",QSIGTunnelVariant="1"
mml> prov-add:trnkgrpprop:name="9300",OwnRoutingNumber="488"
 
   

Step 9 Add the dial plan, 1111:

mml> numan-add:DIALPLAN:custgrpid="1111",overdec="NO"
 
   

Step 10 Add a result of the ROUTE result type for HSI:

mml> numan-add:RESULTSET:custgrpid="1111",name="eisup-set4"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="eisup-result4",resulttype="ROUTE", 
dw1="rtlist-bighead",setname="eisup-set4"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="4", 
setname="eisup-set4"
 
   

Step 11 Add a result of the ROUTE result type for the DPNSS media gateway:

mml> numan-add:RESULTSET:custgrpid="1111",name="dpnss-rs-1"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="dpnss-route1",resulttype="ROUTE", 
dw1="rtlist-dpnss-3745",setname="dpnss-rs-1"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="3", 
setname="dpnss-rs-1"
 
   

Step 12 Add a result of the RTRN_START_ANALresult type:

mml> numan-add:RESULTSET:custgrpid="1111",name="self-set02"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="self-result02", 
resulttype="RTRN_START_ANAL",dw1="2",setname="self-set02"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="02", 
setname="self-set02"
 
   

Step 13 Add the result of the ROUTE result type for the CCM whose routing number for is 446:

mml> numan-add:RESULTSET:custgrpid="1111",name="446"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="446",resulttype="ROUTE", 
dw1="rtlist-bighead",setname="446"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="446", 
setname="446"
 
   

Step 14 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning Route Optimization Initiated by the Cisco PGW 2200 Softswitch

To do route optimization originating provisioning, perform the following steps:


Step 1 Start the provisioning by using the following MML command:

mml> prov-sta::srcver="roo1",dstver="ROPR001"
 
   

Step 2 Add OPC, DPC, and the SS7 signaling path:

mml> prov-add:OPC:name="opc",desc="PGW point code",netaddr="2.5.5",netind=2,type="TRUEOPC"
mml> prov-add:DPC:name="dpc1",desc="INET point code 2.4.4",NETADDR="2.4.4",netind=2
 
   
mml> prov-add:SS7PATH:name="ss7svc1",desc="SS7 service to DPC 2.4.4",mdo="ISUPV3", 
custgrpid="1111",side="network",dpc="dpc1",opc="opc",m3uakey="",origlabel="",termlabel=""
 
   

Step 3 Add the Cisco ITP-L external node:

mml> prov-add:EXTNODE:name="slt7",desc="sh-2600-7",type="SLT",isdnsigtype="N/A",group=0
mml> prov-add:LNKSET:name="linkset1",desc="Linkset 1 to INET",apc="dpc1",proto="SS7-ITU", 
type="IP"
mml> prov-add:SS7ROUTE:name="ss7route1",desc="Route to DPC-2-4-4",opc="opc",dpc="dpc1", 
lnkset="linkset1",PRI=1
mml> prov-add:SESSIONSET:name="c7sset7",extnode="slt7",ipaddr1="IP_Addr1", 
peeraddr1="192.0.2.32",port=7000,peerport=7000,type="BSMV0"
mml> prov-add:C7IPLNK:name="ss7link1",desc="Signal link",lnkset="linkset1",slc=0,pri=1, 
timeslot=2,sessionset="c7sset7"
 
   

Step 4 Add the external node, Cisco AS5300 media gateway.

mml> prov-add:EXTNODE:name="sh-5300-5",desc="mgw 
sh-5300-5",type="AS5300",isdnsigtype="N/A",group=0
mml> prov-add:MGCPPATH:name="mgcppath5300-5",desc="MGCP service to AS-5300-5", 
extnode="sh-5300-5"
mml> prov-add:IPLNK:name="mgcplink-5",desc="MGCP link to AS-5300-5",SVC="mgcppath5300-5", 
ipaddr="IP_Addr1",port=2427,peeraddr="192.0.2.33",peerport=2427,PRI=1,iproute=""
mml> prov-add:SIGSVCPROP:name="mgcppath5300-5",mgcpDomainNameRemote="s0/ds1-1/1@sh-5300-5"
mml> prov-add:SIGSVCPROP:name="mgcppath5300-5",srcpIpPortLocal="2428"
 
   

Step 5 Add trunks, and route lists:

mml> prov-add:TRNKGRP:name="1100",clli="INET-DPC1",svc="ss7svc1",type="TDM_ISUP", 
SELseq="LIDL"
mml> prov-add:SWITCHTRNK:name="1",trnkgrpnum="1100",span="ffff",cic=1,cu="sh-5300-5", 
spansize=31,endpoint=s0/ds1-1/1@192.0.2.254
mml> prov-add:RTTRNKGRP:name="1100",type=1
mml> prov-add:RTTRNK:name="rt-ss7-1",trnkgrpnum=1100
mml> prov-add:RTLIST:name="rtlist-ss7-1",rtname="rt-ss7-1",distrib="OFF"
mml> prov-ed:TRNKGRPPROP:name="1100",custgrpid="1111",MGCdomain="192.0.2.42"
 
   

Step 6 Add the HSI external node, sh-bighead:

mml> prov-add:EXTNODE:name="sh-bighead",desc="HSI sh-bighead",type="H323", 
isdnsigtype="N/A",group=0
mml> prov-add:EISUPPATH:name="eisup-bighead",desc="EISUP to HSI sh-bighead", 
extnode="sh-bighead",custgrpid="1111",origlabel="",termlabel=""
mml> prov-add:IPLNK:name="ip-bighead",desc="IP lnk to HSI sh-bighead",svc="eisup-bighead", 
ipaddr="IP_Addr1",port=8003,peeraddr="192.0.2.33",peerport=8003,pri=1,iproute=""
mml> prov-add:SIGSVCPROP:name="eisup-bighead",AllowH323Hairpin="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",FeatureTransparencyDisabled="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",H323AdjunctLink="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",OOverlap="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",OwnRoutingNumber="545"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",QSIGTunnelVariant="1"
mml> prov-add:SIGSVCPROP:name="eisup-bighead",TOverlap="0"
 
   

Step 7 Add trunk groups and rout e lists to the HSI:

mml> prov-add:TRNKGRP:name="9300",clli="EISUP2B",svc="eisup-bighead",type="IP"
mml> prov-add:RTTRNKGRP:name="9300",type=4
mml> prov-add:RTTRNK:weightedtg="OFF",name="eisup-bighead",trnkgrpnum=9300
mml> prov-add:RTLIST:name="rtlist-bighead",rtname="eisup-bighead"
 
   
mml> prov-add:TRNKGRPPROP:NAME="9300",QSIGTunnelVariant="1"
mml> prov-add:TRNKGRPPROP:NAME="9300",OwnRoutingNumber="545"
 
   

Step 8 Add a dial plan and digit modifications:

mml> numan-add:DIALPLAN:custgrpid="1111",overdec="NO"
mml> numan-add:DIGMODSTRING:custgrpid="1111",name="ccm02",digstring="6"
mml> numan-add:DIGMODSTRING:custgrpid="1111",name="ccm3003",digstring="02"
mml> numan-add:DIGMODSTRING:custgrpid="1111",name="a6",digstring="6"
 
   

Step 9 Add the result of the ROUTE result type for SS7:

mml> numan-add:RESULTSET:custgrpid="1111",name="ss7-set1"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="ss7-result1",resulttype="ROUTE", 
dw1="rtlist-ss7-1",setname="ss7-set1"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="1", 
setname="ss7-set1"
 
   

Step 10 Add a result of the ROUTE result type for HSI:

mml> numan-add:RESULTSET:custgrpid="1111",name="eisup-set4"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="eisup-result4",resulttype="ROUTE", 
dw1="rtlist-bighead",setname="eisup-set4"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="4", 
setname="eisup-set4"
 
   

Step 11 Add a result of the RTRN_START_ANAL result type:

mml> numan-add:RESULTSET:custgrpid="1111",name="self-set02"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="self-result02", 
resulttype="RTRN_START_ANAL",dw1="02",setname="self-set02"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="02", 
setname="self-set02"
 
   

Step 12 Add the result of the ROUTE result type for the Cisco PGW 2200 Softswitch whose routing number for is 545:

mml> numan-add:RESULTSET:custgrpid="1111",name="545"
mml> numan-add:RESULTTABLE:custgrpid="1111",name="545",resulttype="RTRN_START_ANAL", 
dw1="3",setname="545"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="545", 
setname="545"
 
   

Step 13 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning Route Optimization Responded by the Cisco PGW 2200 Softswitch

To do route optimization terminating provisioning, perform the following steps:


Step 1 Follow Step 1 to Step 11 in the previous procedure described in "Provisioning Route Optimization Initiated by the Cisco PGW 2200 Softswitch" section.

Step 2 Add the result of the ROUTE result type for the CCM whose routing number for is 446:

mml> numan-add:RESULTSET:custgrpid="1111",name="446"
mnl> numan-add:RESULTTABLE:custgrpid="1111",name="446",resulttype="ROUTE",
dw1="rtlist-bighead",setname="446"
mml> numan-add:BDIGTREE:custgrpid="1111",callside="originating",digitstring="446",
setname="446"
 
   

Step 3 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning Call Completion

To provision call completion, perform the following steps:


Step 1 Follow Step 1 to Step 6 in the previous procedure described in "Provisioning Route Optimization Transit" section.

Step 2 Add the EISUP signaling path to the HSI:

mml> prov-add:eisuppath:name="eisup-bighead",desc="EISUP to HSI sh-bighead", 
extnode="sh-bighead",custgrpid="1111",origlabel="",termlabel=""
 
   
mml> prov-add:iplnk:name="ip-bighead",desc="IP lnk to HSI sh-bighead",svc="eisup-bighead", 
ipaddr="IP_Addr1",port=8003,peeraddr="192.0.2.34",peerport=8003,pri=1,iproute=""
 
   
mml> prov-add:sigsvcprop:name="eisup-bighead",AllowH323Hairpin="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",FeatureTransparencyDisabled="0"
mml> prov-add:sigsvcprop:name="eisup-bighead",H323AdjunctLink="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",OOverlap="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",QSIGTunnelVariant="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",TOverlap="0"
mml> prov-add:sigsvcprop:name="eisup-bighead",EnableCCBSpathReservation="1"
 
   

Step 3 Add trunk groups and route lists:

mml> prov-add:trnkgrp:name="9300",clli="EISUP2B",svc="eisup-bighead",type="IP"
mml> prov-add:rttrnkgrp:name="9300",type=4
mml> prov-add:rttrnk:weightedtg="OFF",name="eisup-bighead",trnkgrpnum=9300
mml> prov-add:rtlist:name="rtlist-bighead",rtname="eisup-bighead"
 
   
mml> prov-add:trnkgrpprop:name="9300",FeatureTransparencyDisabled="0"
mml> prov-add:trnkgrpprop:name="9300",CustomerVPNid="longan"
mml> prov-add:trnkgrpprop:name="9300",customervpnoffnettblnum="5"
mml> prov-add:trnkgrpprop:name="9300",customervpnonnettblnum="5"
mml> prov-add:trnkgrpprop:name="9300",EnableCCBSpathReservation="1"
 
   

Step 4 Add the dial plan, 1111:

mml> numan-add:dialplan:custgrpid="1111",overdec="NO"
 
   

Step 5 Add the result of the ROUTE result type for HSI:

mml> numan-add:resultset:custgrpid="1111",name="eisup-set4"
mml> numan-add:resulttable:custgrpid="1111",name="eisup-result4",resulttype="ROUTE",
dw1="rtlist-bighead",setname="eisup-set4"
mml> numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="4",
setname="eisup-set4"
 
   

Step 6 Add the result of the ROUTE result type for DPNSS:

mml> numan-add:resultset:custgrpid="1111",name="dpnss-rs-1"
mml> numan-add:resulttable:custgrpid="1111",name="dpnss-route1",resulttype="ROUTE", 
dw1="rtlist-dpnss-3745",setname="dpnss-rs-1"
mml> numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="3", 
setname="dpnss-rs-1"
 
   

Step 7 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning Message Waiting Indicator (with no QSIG Tunneling)

To provision message waiting indicator, with no QSIG tunneling enabled, perform the following steps:


Step 1 Start a provisioning session:

mml> prov-sta:srcver="qsig1",dstver="QSIGdis"
 
   

Step 2 Add the Cisco 5400 external node for DPNSS:

mml> prov-add:extnode:name="sh-stim-001",desc="sh-stim-3001 for dpnss",type="AS5400", 
isdnsigtype="IUA",group=0
 
   

Step 3 Add the MGCP signaling path, the association, and the DPNSS path:

mml> prov-add:mgcppath:name="mgcp-stim-dpnss001",desc="MGCP",extnode="sh-stim-001"
mml> prov-add:iplnk:name="sh-stim-dpnss1",desc="link 1 to 
sh-stim-001",svc="mgcp-stim-dpnss001",ipaddr="IP_Addr1",port=2427,peeraddr="192.0.2.35", 
peerport=2427,pri=1,iproute=""
 
   
mml> prov-add:sigsvcprop:name="mgcp-stim-dpnss001", 
mgcpDomainNameRemote="s0/ds1-0/1@192.0.2.252"
 
   
mml> prov-add:association:name="stim-dpnss1",desc="",extnode="sh-stim-001",sgp="", 
type="IUA",ipaddr1="IP_Addr1",port=9903,peeraddr1="192.0.2.36",peerport=9903,iproute1="", 
rcvwin=18000,maxinitretrans=10,maxinitrto=2000,maxretrans=5,cumsackto=300,bundleto=100, 
minrto=300,maxrto=3000,hbto=2000,maxretransdest=3
 
   
 
   
mml> prov-add:dpnsspath:name="dpnss-pathin1",desc="dpnss sh-001",extnode="sh-stim-001", 
mdo="DPNSS_BTNR188",custgrpid="1111",sigslot=0,sigport=0
 
   
mml> prov-add:sigsvcprop:name="dpnss-pathin1",CustomerVPNOnNetTblNum="5"
mml> prov-add:sigsvcprop:name="dpnss-pathin1",CustomerVPNOffNetTblNum="5"
mml> prov-add:sigsvcprop:name="dpnss-pathin1",customervpnid="1"
mml> prov-ed:sigsvcprop:name="dpnss-pathin1",ownroutingnumber="488"
mml> prov-ed:sigsvcprop:name="dpnss-pathin1",MgcpBehavior="2",name="mgcp-stim-dpnss001"
 
   
mml> prov-ed:sigsvcprop:name="dpnss-pathin1",MwiStringOFF ="*58*AN*1"
mml> prov-ed:sigsvcprop:name="dpnss-pathin1",MwiStringON ="*58*AN*0"
 
   

Step 4 Add trunk groups for DPNSS:

mml> prov-add:trnkgrp:name="3600",svc="dpnss-pathin1",type="TDM_DPNSS",selseq="ASC", 
qable="N"
mml> prov-add:trnkgrpprop:name="3600",CustGrpId="1111",gatewayrbtonesupport="1"
mml> prov-add:trnkgrpprop:name="3600",customervpnid="1"
mml> prov-add:trnkgrpprop:name="3600",FeatureTransparencyDisabled ="0"
mml> prov-add:switchtrnk:name="3600",trnkgrpnum="3600",spansize=31,span="ffff",cic=1, 
endpoint="S0/ds1-0/1@192.0.2.250",cu="sh-stim-001"
mml> prov-add:rttrnkgrp:name="3600",type=6,reattempts=2,queuing=30,cutthrough=3
 
   
mml> prov-add:trnkgrpprop:name="3600",MwiStringOFF ="*58*AN*1"
mml> prov-add:trnkgrpprop:name="3600",MwiStringON ="*58*AN*0"
 
   

Step 5 Add the Cisco HSI external node, and the EISUP signaling path:

mml> prov-add:extnode:name="sh-bighead",desc="HSI sh-bighead",type="H323", 
isdnsigtype="N/A",group=0
mml> prov-add:eisuppath:name="eisup-bighead",desc="EISUP to HSI sh-bighead", 
extnode="sh-bighead",custgrpid="1111",origlabel="",termlabel=""
mml> prov-add:iplnk:name="ip-bighead",desc="IP lnk to HSI sh-bighead", 
svc="eisup-bighead",ipaddr="IP_Addr1",port=8003,peeraddr="192.0.2.36", 
peerport=8003,pri=1,iproute=""
 
   
mml> prov-add:sigsvcprop:name="eisup-bighead",AllowH323Hairpin="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",FeatureTransparencyDisabled="0"
mml> prov-add:sigsvcprop:name="eisup-bighead",H323AdjunctLink="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",OOverlap="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",QSIGTunnelVariant="0"
mml> prov-add:sigsvcprop:name="eisup-bighead",TOverlap="0"

Step 6 Add trunk groups and route lists for Cisco HSI:

mml> prov-add:trnkgrp:name="9300",clli="EISUP2B",svc="eisup-bighead",type="IP"
mml> prov-add:rttrnkgrp:name="9300",type=4
mml> prov-add:rttrnk:weightedtg="OFF",name="eisup-bighead",trnkgrpnum=9300
mml> prov-add:rtlist:name="rtlist-bighead",rtname="eisup-bighead"
 
   

Step 7 Add the dial plan, 1111:

mml> numan-add:dialplan:custgrpid="1111",overdec="NO"
 
   

Step 8 Add results, a B digit tree entry, and digit modifications for Cisco HSI:

mml> numan-add:resultset:custgrpid="1111",name="eisup-set4"
mml> numan-add:resulttable:custgrpid="1111",name="eisup-result4",resulttype="ROUTE", 
dw1="rtlist-bighead",setname="eisup-set4"
mml> numan-add:resulttable:custgrpid="1111",name="tab33",resulttype="BNBRMODMWI",
dw1="mwion", dw2="wioff",setname="rset33"
 
   
mml> numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="4", 
setname="eisup-set4"
 
   
mml> numan-add:digmodstring:custgrpid="1111",name="mwioff",digstring="5719"
mml> numan-add:digmodstring:custgrpid="1111",name="mwion",digstring="5718"
 
   

Step 9 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning Message Waiting Indicator (with QSIG Tunneling)

The following MML commands are an example of message waiting indicator, with QSIG tunneling enabled, provisioning.


Step 1 Follow Step 1 to 4 in the previous procedure described in "Provisioning Message Waiting Indicator (with no QSIG Tunneling)" section.

Step 2 Add the Cisco HSI external node and the EISUP signaling path:

mml> prov-add:extnode:name="sh-bighead",desc="HSI sh-bighead",type="H323", 
isdnsigtype="N/A", group=0
mml> prov-add:eisuppath:name="eisup-bighead",desc="EISUP to HSI sh-bighead", 
extnode="sh-bighead",custgrpid="1111",origlabel="",termlabel=""
mml> prov-add:iplnk:name="ip-bighead",desc="IP lnk to HSI sh-bighead",svc="eisup-bighead", 
ipaddr="IP_Addr1",port=8003,peeraddr="192.0.2.37",peerport=8003,pri=1,iproute=""
 
   

Step 3 Modify property values of the EISUP signaling path:

mml> prov-add:sigsvcprop:name="eisup-bighead",AllowH323Hairpin="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",FeatureTransparencyDisabled="0"
mml> prov-add:sigsvcprop:name="eisup-bighead",H323AdjunctLink="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",OOverlap="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",OwnRoutingNumber="545"
mml> prov-add:sigsvcprop:name="eisup-bighead",QSIGTunnelVariant="1"
mml> prov-add:sigsvcprop:name="eisup-bighead",TOverlap="0"
 
   

Step 4 Add trunk groups and route lists for Cisco HSI:

mml> prov-add:trnkgrp:name="9300",clli="EISUP2B",svc="eisup-bighead",type="IP"
mml> prov-add:rttrnkgrp:name="9300",type=4
mml> prov-add:rttrnk:weightedtg="OFF",name="eisup-bighead",trnkgrpnum=9300
mml> prov-add:rtlist:name="rtlist-bighead",rtname="eisup-bighead"
 
   
mml> prov-add:trnkgrpprop:name="9300",FeatureTransparencyDisabled="0"
mml> prov-add:trnkgrpprop:name="9300",CustomerVPNid="longan"
mml> prov-add:trnkgrpprop:name="9300",customervpnoffnettblnum="5"
mml> prov-add:trnkgrpprop:name="9300",customervpnonnettblnum="5"
 
   

Step 5 Add the dial plan, 1111:

mml> numan-add:dialplan:custgrpid="1111",overdec="NO"
 
   

Step 6 Add results and a B digit tree entry in the dial plan 1111:

mml> numan-add:resultset:custgrpid="1111",name="eisup-set4"
mml> numan-add:resulttable:custgrpid="1111",name="eisup-result4",resulttype="ROUTE", 
dw1="rtlist-bighead",setname="eisup-set4"
mml> numan-add:bdigtree:custgrpid="1111",callside="originating",digitstring="4", 
setname="eisup-set4"
 
   

Step 7 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning a Customer VPN ID in a Trunk Group

To provision a VPN ID in a trunk group, use the following MML commands in an open provisioning session:

mml> prov-add:trnkgrpprop:name="9300",FeatureTransparencyDisabled="0"
mml> prov-add:trnkgrpprop:name="9300",CustomerVPNid="longan"
mml> prov-add:trnkgrpprop:name="9300",customervpnoffnettblnum="5"
mml> prov-add:trnkgrpprop:name="9300",customervpnonnettblnum="5"

Provisioning a Customer VPN ID in the Dial Plan

To provision a VPN ID in a dial plan, perform the following steps:


Step 1 Create the dial plan by using the following MML commands in an open provisioning session:

mml> numan-add:dialplan:custgrpid="T002" 
 
   

Step 2 Add entries in the customer VPN ID table and the result set:

mml> numan-add:customervpnid:custgrpid="T002",name="Abbey"
mml> numan-add:resultset:custgrpid="T002",name="VpnCust1"
mml> numan-add:resulttable:custgrpid="T002",name="result1",resulttype="ORIG_VPN_ID", 
dw1="Abbey",dw2="5",dw3="5",setname="VpnCust1" 
 
   

Step 3 Add an A-number digit tree entry to the result set:

mml> numan-add:adigtree:custgrpid="T002",digitstring="0",callside="originating", 
setname="VpnCul" 
 
   

Step 4 Add B-number NPI and NOA results in the pre-analysis:

mml> numan-add:bnpi:custgrpid="T002",npiblock=1,setname="VpnCust1" 
mml> numan-add:bnoa:custgrpid="T002",noavalue=1,npiblock=1 
 
   

Step 5 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning Feature Transparency on QSIG Trunk Groups or sigPaths

To provision feature transparency on QSIG trunk groups or sigPaths, perform the following steps:


Step 1 Enable feature transparency by using the following MML commands:

mml> prov-ed:sigsvcprop:name="Q-PBX-1",FeatureTransparencyDisabled="0" 
 
   

Step 2 Assign a customer VPN ID and profile indexes:

mml> prov-ed:sigsvcprop:name="Q-PBX-1",CustomerVPNid="CUST-1" 
mml> prov-ed:sigsvcprop:name="Q-PBX-1",CustomerVPNOnNetTblNum="5" 
mml> prov-ed:sigsvcprop:name="Q-PBX-1",CustomerVPNOffNetTblNum="6" 
 
   

Step 3 Enable the path replacement and route optimization:

mml> prov-ed:sigsvcprop:name="Q-PBX-1",OwnRoutingNumber="1234" 
 
   

Step 4 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning an H.323 EISUP Trunk Group or sigPaths for Transparent Annex M1 (Tunneled QSIG)

To provision an H.323 EISUP trunk group or sigPaths for Transparent Annex M1 (Tunneled QSIG), perform the following steps:


Step 1 Enable QSIG tunneling by using the following MML command:

mml> prov-ed:sigsvcprop:name="EISUP-HSI-1",QSIGTunnelVariant="1" 
 
   

Step 2 Assign a customer VPN ID and profile indexes:

mml> prov-ed:sigsvcprop:name="EISUP-HSI-1",CustomerVPNid="CUST-1" 
mml> prov-ed:sigsvcprop:name="EISUP-HSI-1",CustomerVPNOnNetTblNum="5" 
mml> prov-ed:sigsvcprop:name="EISUP-HSI-1",CustomerVPNOffNetTblNum="6" 
 
   

Step 3 Enable path replacement and route optimization:

mml> prov-ed:sigsvcprop:name="EISUP-HSI-1",OwnRoutingNumber="1234" 
 
   

Step 4 Disable feature transparency for CCM interworking:

mml> prov-ed:sigsvcprop:name="EISUP-HSI-1",FeatureTransparencyDisabled="1" 
 
   

Step 5 End the provisioning session as described in "Stopping a Configuration Session" section.


Note If QBE is to be used for CCBS instead of tunnel, change the value of the *.DisableCCBSoverTunneledQSIG property to a value of 1 in the XECfgParm.dat file.



Enhanced Local Number Portability and Dial Plan Selection

Enhanced Local Number Portability (LNP) and dial plan selection extend the table look up capability to provide searches with longest match and partial (substring) matches for the ported number and A number dial plan selection tables.

To provision enhanced LNP and dial plan selection, perform the following steps:


Step 1 Add entries in the ported number table by using the following MML commands:

mml> numan-add:porttbl:digitstring="9981234",routenum="44",minlength=6,maxlength=20
mml> numan-add:porttbl:digitstring="9991234",routenum="44",minlength=6,maxlength=20
 
   

Step 2 Add A-number dial plan selection:


Note If full A-number matches the digit string provisioned in the CLI parameter, the Cisco PGW 2200 Softswitch chooses the new dial plan provisioned in the newdp parameter.


mml> numan-add:anumdpsel:custgrpid="1111",cli="99712345",newdp="2222"
 
   

Step 3 Add the result of the E_PORTED_NUM result type in dial plan 1111:

mml> numan-add:resultset:custgrpid="1111",name="rtsetlnp99812"
mml> numan-add:resulttable:custgrpid="1111",name="rtblnp99812",resulttype="E_PORTED_NUM", 
setname="rtsetlnp99812"
 
   

Step 4 Add the result of the DB_XLATED result type in dial plan 1111:

mml> numan-add:resulttable:custgrpid="1111",name="rtblnp99912",resulttype="DB_XLATED",
dw1=6,dw2="dp01",dw3="dp02",setname="rtsetlnp99812"
 
   

Note Dw1 = 6 indicates that any longest match search searches down from the currently received number of digits to a digit length of 6 for potential matches. Dw2 & 3 respectively, indicate the dial plan to move into according to matching (dp01) or not matching (dp02).


Step 5 Add the result of the A_NUM_DP_TABLE result type in dial plan 1111:

mml> numan-add:resultset:custgrpid="1111",name="rtsetdpsel996"
mml> numan-add:resulttable:custgrpid="1111",setname="rtsetdpsel996",name="rttbldpsel996", 
resulttype="A_NUM_DP_TABLE",dw1="5"
 
   

Note Dw1 = 5 indicates that a database longest match query searches down from the currently received number of digits to a digit length of 5 for potential matches. If dw1 is omitted or set to zero, the existing functionality with exact matching applies.


Step 6 Add entries in B digit tree:

mml> numan-add:bdigtree:custgrpid="1111",digitstring="99812",callside="originating", 
setname="rtsetlnp99812"
 
   
mml> numan-add:bdigtree:custgrpid="1111",digitstring="9961234",callside="originating", 
setname="rtsetdpsel996"
 
   

Step 7 End the provisioning session as described in "Stopping a Configuration Session" section.


Full Number Translations

You can find the provisioning procedure in the "Provisioning Full Number Translations" section of Chapter 4, Provisioning Dial Plans with MML, in Cisco PGW 2200 Softswitch Release 9 Dial Plan Guide (through Release 9.7).

Global Titles

You can find the provisioning procedure in the "Provisioning Global Titles" section of Chapter 4, Provisioning Dial Plans with MML, in Cisco PGW 2200 Softswitch Release 9 Dial Plan Guide (through Release 9.7).

Provisioning H.248 Protocol

The H.248 feature provides a gateway control interface between the PGW 2200 and the VXSM gateways. It supplements the MGCP protocol. This new interface is based on the ITU-SG16/IETF specification of H.248 which defines a decomposed gateway architecture.

Although H.248 is designed to be generic in its support for many different kinds of media, the Cisco PGW 2200 Softswitch is mainly designed to act as an MGC and only interwork with trunking gateways. This feature addresses only the functionality of the interworking of the Cisco PGW 2200 Softswitch with trunking gateways. Figure 5-9 shows an overview of this system.

Figure 5-9 H.248 Protocol in the SS7 Network

Before you provision H.248 protocol feature, configure the following parameters in the XECfgParm.dat file:

H248.maxNumH248Links = 500 
H248.maximumActionsInTransaction=64 
H248.localMID = cisco.com 
H248.MgcHeaderAddrType = 2
 
   

To provision H.248 protocol on the Cisco PGW 2200 Softswitch, perform the following steps:


Step 1 Start the provisioning by using the following MML command:

mml> prov-sta::srcver="base1",dstver="H248"
 
   

Step 2 Follow either of the two following steps to add H.248 sigPath:

H.248 sigPath based on UDP transport

mml> prov-add:EXTNODE:NAME="h248-VXSM-01",DESC="VXSM-01",TYPE="VXSM"
mml> prov-add:H248PATH:NAME="h248-sigpath-UDP",DESC="Service to H248", 
EXTNODE="h248-VXSM-01"
mml> prov-add:IPLNK:NAME="h248-udp-link-1",DESC="UDP link to h248-sigpath-UDP", 
SVC="h248-sigpath-UDP",IPAddr="IP_Addr1",PORT=2944,PEERADDR="192.0.2.38", 
PEERPORT=2944, PRI=1

Note Unlike MGCP, only one UDP link is allowed between the Cisco PGW 2200 Softswitch and the media gateway for H.248 sigPath.


H.248 sigPath based on SCTP Transport

mml> prov-add:EXTNODE:NAME="h248-VXSM-02",DESC="VXSM-02",TYPE="VXSM"
mml> prov-add:H248PATH:NAME="h248-sigpath-sctp",DESC="Service to H248",EXTNODE=" 
h248-VXSM-02"
mml> prov-add: iproute:name="iproute-h248-1",dest="192.0.2.39", 
netmask="255.255.255.0", ipaddr="IP_Addr1",nexthop="209.165.200.240",pri=1
mml> prov-add: iproute:name="iproute-h248-2",dest="192.0.2.39", 
netmask="255.255.255.0", ipaddr="IP_Addr2",nexthop="209.165.201.16",pri=2
 
   
mml> prov-add:association:NAME="h248-sctp-2",DESC="link 1 to VXSM-02",type="H248", 
sgp="N/A",ipaddr1="IP_Addr1", port=2944,iproute1="iproute_h248_1",ipaddr2="IP_Addr2", 
port=2944,iproute1="iproute_h248_2",peeraddr1="192.",extnode="h248-VXSM-02"
 
   

Step 3 Add SS7 sigPaths:

mml> prov-add:OPC:NAME="opc",DESC="Own Point Code",NETADDR="1.0.1",NETIND=2,TYPE="TRUEOPC"
mml> prov-add:DPC:NAME="sp1",DESC="SP1 Point Code",NETADDR="4.0.1",NETIND=2
mml> prov-add:DPC:NAME="sp2",DESC="SP2 Point Code",NETADDR="4.0.2",NETIND=2
 
   
mml> prov-add:SS7PATH:NAME="ss7svc1",DESC="SS7SigPathtoSP1",MDO="Q761_BASE", 
CUSTGRPID="1111", SIDE="network",DPC="sp1",OPC="opc",M3UAKEY=""
mml> prov-add:SS7PATH:NAME="ss7svc2",DESC="SS7SigPathtoSP2",MDO="Q761_BASE", 
CUSTGRPID="1111",SIDE="network",DPC="sp2",OPC="opc",M3UAKEY=""
 
   
mml> prov-add:LNKSET:NAME="lnkset1",DESC="LinkSet to SP1",APC="sp1",PROTO="SS7-ITU", 
TYPE="IP"
mml> prov-add:LNKSET:NAME="lnkset2",DESC="LinkSet to SP2",APC="sp2",PROTO="SS7-ITU", 
TYPE="IP"
 
   
mml> prov-add:SS7ROUTE:NAME="route1",DESC="Route to SP1", OPC="opc",DPC="sp1", 
LNKSET="lnkset1",PRI=1
mml> prov-add:SS7ROUTE:NAME="route2",DESC="Route to SP2", OPC="opc",DPC="sp2", 
LNKSET="lnkset2",PRI=1
 
   
mml> prov-add:EXTNODE:NAME="sh-2600-3",DESC="SLT-2600-3",TYPE="SLT",ISDNSIGTYPE="N/A"
mml> prov-add:SESSIONSET:NAME="c7-2600-3",EXTNODE="sh-2600-3",IPADDR1="IP_Addr1", 
PORT=7000,PEERADDR1="192.0.2.40", PEERPORT=7000,TYPE="BSMV0"
mml> prov-add:C7IPLNK:NAME="c7iplnk1-1",DESC="SS7Link1inLinkSet1",LNKSET="lnkset1",SLC=0, 
PRI=1,TIMESLOT=0,SESSIONSET="c7-2600-3"
mml> prov-add:C7IPLNK:NAME="c7iplnk2-1",DESC="SS7Link1inLinkSet2",LNKSET="lnkset2",SLC=0,
PRI=1,TIMESLOT=1,SESSIONSET="c7-2600-3"
 
   

Step 4 Add trunk groups and trunks:

mml> prov-add:trnkgrp:name="1111",clli="NULL",svc="ss7svc1",type="TDM_ISUP"
mml> prov-ed:trnkgrpprop:name="1111",custgrpid="1111"
 
   
/* For OC3 with Descriptive Text */
mml> prov-add:switchtrnk:name="1",trnkgrpnum="1111",span="ffff",cic=1,cu="h248-vxsm-01-1", 
spansize=15,endpoint="DS/OC3_1/T1_7/1"
 
   
/* For OC3 without Descriptive Text */
mml> prov-add:switchtrnk:name="1",trnkgrpnum="1111",span="ffff",cic=1,cu="h248-vxsm-01-1", 
spansize=15,endpoint="DS/ 1/7/1"
 
   
/* For STM with Descriptive Text */
mml> prov-add:switchtrnk:name="16",trnkgrpnum="1111",span="ffff",cic=16, 
cu="h248-vxsm-01-1",spansize=15,endpoint="DS/STM_1/T1_7/1"
 
   
/* For STM without Descriptive Text */
mml> prov-add:switchtrnk:name="16",trnkgrpnum="1111",span="ffff",cic=16,
cu="h248-vxsm-01-1",spansize=15,endpoint="DS/1/7/1"
 
   
/* For T1 with Descriptive Text */
mml> prov-add:switchtrnk:name="62",trnkgrpnum="1111",span="ffff",cic=62,
cu="h248-vxsm-01-1",spansize=15,endpoint="DS/T1_2/7"
 
   
/* For T1 without Descriptive Text */
mml> prov-add:switchtrnk:name="62",trnkgrpnum="1111",span="ffff",cic=62,
cu="h248-vxsm-01-1",spansize=15,endpoint="DS/2/7"
 
   
/* For T3 with Descriptive Text */
mml> prov-add:switchtrnk:name="62",trnkgrpnum="1111",span="ffff",cic=62,
cu="h248-vxsm-01-1",spansize=15,endpoint="DS/T3_1/T1_2/7"
 
   
/* For T3 without Descriptive Text */
mml> prov-add:switchtrnk:name="62",trnkgrpnum="1111",span="ffff",cic=62,
cu="h248-vxsm-01-1",spansize=15,endpoint="DS/1/2/7"
 
   

Step 5 Modify H.248 related properties:

mml> prov-ed:trnkgrpprop:name="1111",H248GatewayReserveValue="0"
 
   

Note The property H248GatewayReserveValue is deleted in Release 9.7P23 and later.


mml> prov-ed:sigsvcprop:name="h248-vxsm-01-1",GWProtocolVersion="H248 V2"
mml> prov-ed:sigsvcprop:name="h248-vxsm-01-1",h248DomainNameRemote="<VXSM.CISCO.COM>"
mml> prov-ed:sigsvcprop:name="h248-sigpath-01", h248inactivitytimer="1000"
 
   

Step 6 End the provisioning session as described in "Stopping a Configuration Session" section.


Lawful Intercept

The lawful intercept (LI) feature on the Cisco PGW 2200 Softswitch allows personnel authorized by a Law Enforcement Agency (LEA) to intercept data from targeted calls and send the call data to an LI Mediation Device.

Lawful Intercept on Cisco PGW 2200 Softswitch works within the architecture of the Cisco Service Independent Intercept (SII).

Figure illustrates how the Cisco PGW 2200 Softswitch fits into the Cisco Service Independent Intercept (SII) architecture.

Figure 5-10 Cisco PGW 2200 Softswitch in Cisco Service Independent Intercept (SII) Architecture

Cisco SII dissociates call content requests from the signaling architecture. This is done by having the LI Mediation Device make call content requests through the SNMPV3 from the voice gateway.

When a call is made on the Cisco PGW 2200 Softswitch that matches a trunk group, full number, or partial number on the target list, the Cisco PGW 2200 Softswitch sends the call data to the LI Mediation Device. The LI Mediation Device is triggered when it receives the call data from the Cisco PGW 2200 Softswitch.

There are two different types of commands that you can use to interact with the Cisco PGW 2200 Softswitch when implementing the LI features. The first set of commands are used by the service provider organization to provision the Cisco PGW 2200 Softswitch to be able to handle lawful intercept or wiretap. These provisioning commands involve adding LI sigpaths and IP links.

The second set of commands is used by someone authorized by the LEA to add, modify, delete and retrieve wiretapped numbers.

Provisioning LI for the Service Provider

To provision lawful intercept on the Cisco PGW 2200 Softswitch, perform the following steps:


Step 1 Configure the Cisco PGW 2200 Softswitch with the IP addresses of the Mediation Device(s) that it will contact for call interception.

Step 2 Edit the XECfgParm.dat file and set the LISupport parameter value to enable. The default value is *.LISupport=disable.

Step 3 Provision the LI Mediation Device Communication Path.


Note Provision a wiretap Channel Controller and associated IP Link before adding wiretap entries. Do not use the user ID meant for controlling wiretap entries (liusr).


Step 4 Add the LI mediation device as an external node in an open provisioning session:

mml> prov-add:EXTNODE:NAME="LI-node",TYPE="LIMD", DESC="LI Mediation Device"
 
   

Step 5 Add the LI mediation device signaling path:

mml> prov-add:LIPATH:NAME="LIsigPath",DESC="SigPath to the LI",EXTNODE="LI-node"
 
   

Step 6 Add the LI mediation device IP Link:


Note This MML command defines an IP link to the LI mediation device and associates an LI sigPath to the IP link.


mml> Prov-add:IPLNK:NAME="lilink", DESC="IP link to the LI",  SVC="lipath", 
IPADDR="IP_addr1", PORT="1813", PEERADDR="192.0.2.41", PEERPORT="1813"
 
   

The local_address and local_port are parameters in the existing Cisco PGW 2200 Softswitch two-way communications IP link object. In this case, the LI Channel Controller does not use the local_port, thus the local port value is ignored.

Step 7 End the provisioning session as described in "Stopping a Configuration Session" section.


Provisioning a Wiretap Entry for the Medication Device

You must be an authorized LI user and logged in as liusr to add a wiretap entry. Only one MML session per LI user is allowed at any time to log in to the Cisco PGW 2200 Softswitch.

In the following example, the wiretap call data is sent to the LI mediation device at IP address 192.0.2.42, and port number 1813 (which was configured as an IP link to an external node of type LI).

You can use one of the following three commands to add a wiretap entry:

Add a wiretap entry for an individual number:

wiretap-add:subscriber:number="7035551234",type="calldata",cdc_ip="192.0.2.42", 
cdc_port="1813"
 
   

Add a wiretap entry for a trunk group ID:

wiretap-add:trunkgroup:name="3700",type="calldata",cdc_ip="192.0.2.42",
cdc_port="1813"
 
   

Add a wiretap entry based on a partial number:

wiretap-add:partialnumber:number="partial_number",type="calldata", 
cdc_ip="192.0.2.42",cdc_port="1813"
 
   
 
   

Location Mapping

Location mapping on the Cisco PGW 2200 Softswitch allows you to

Map to different cause and location values based on received cause values and location values.

Map to a different cause value based on the received cause value and location values.

Map cause value to new values without changing location values (existing).

Map to a new cause value and location value based on received cause value.

Override the default location value with a new location value.

Use the default location value if no location value is set.

Map a location value to new values without changing cause values, with the use of wildcard of cause value.

Provisioning Location Values

To use location in the cause analysis, perform the following steps:


Step 1 Add the dial plan, Nat1, in an open provisioning session by using the following MML command:

mml> numan-add:dialplan:custgrpid="Natl"
 
   

Step 2 Add a service, TollFree:

mml> numan-add:service:custgrpid="Natl",name="TollFree"
 
   

Step 3 Add the result set, chCause, in dial plan Nat1:

mml> numan-add:resultset:custgrpid="Natl",setname="chCause"
 
   

Step 4 And cause analysis data:

mml> numan-add:resulttable:custgrpid="Natl",setname="chCause", resulttype="CAUSE", 
name="cause1",dw1=8,dw2=7

Note Dw1 specifies the cause value 8. Dw2 specifies the location value 7.


Step 5 Associate the result set, chCause, with the location block 1 and location block value 2 in the location table:

mml> numan-add:location:custgrpid="Natl",locationblock=1,blockvalue=2, setname="chCause"
 
   

Note In this procedure, if the cause code in the Release message is 8, and the mapped-to internal location value from the external location value in Release message is 3, then the Cisco PGW 2200 Softswitch uses the chCause result set. The blockvalue in numan-add:location should be one less than the intended internal value.



Note For detailed information on Cause and Location, see the "Cause Analysis" section in Chapter 1, Dial Plan and Routing, of the Cisco PGW 2200 Softswitch Release 9 Dial Plan Guide (through Release 9.7).


Step 6 Add an entry in the cause table, with cause value 8, and location block 1:

mml> numan-add:cause:custgrpid="Natl",causevalue=8,locationblock=1
 
   

Note For any cause value that has no value entered in the Cause table, or has a value of 0, the default Cause table is used.



Provisioning Internal Cause Value Mapping

To map internal cause 1 (Unallocated Number) and location 3 to internal cause 36 (Number Changed), perform the following steps:


Step 1 Add the result set, chCause, in an open provisioning session by using the following MML command:

mml> numan-add:resultset:custgrpid="Natl",setname="chCause"
 
   

Step 2 Add cause analysis data (cause value 36):

mml> numan-add:resulttable:custgrpid=" Natl",setname="chCause",resulttype="CAUSE", 
name="cause1",dw1=36
 
   

Step 3 Associate the result set, chCause, with the location block 1 and location block value 2 in the location table:

mml> numan-add:location:custgrpid="Natl",locationblock=1,blockvalue=2,setname="chCause"
 
   

Note The blockvalue in numan-add:location should be one less than the intended internal value. For detailed information on Cause and Location, see the "Cause Analysis" section in Chapter 1, Dial Plan and Routing, of the Cisco PGW 2200 Softswitch Release 9 Dial Plan Guide (through Release 9.7).


Step 4 Add an entry in the cause table, with cause value 1, and location block 1:

mml> numan-add:cause:custgrpid="Natl",causevalue=1,locationblock=1
 
   

Provisioning Cause Value Mapping

Cause Value Mapping Based on Received Cause and Location Values

To map from SIP cause 408 and 504 to SS7 cause 20 (Subscriber Absent), perform the following steps:


Step 1 Add the result set, chgCause, in an open provisioning session by using the following MML command:

mml> numan-add:resultset:custgrpid="Natl",name="chgCause"
 
   

Step 2 Add cause analysis data (cause value 91):

mml> numan-add:resulttable:custgrpid="Natl",name="SubAbsent",resulttype="CAUSE",dw1=91, 
setname="chgCause"
 
   

Step 3 Associate the result set, chgCause, with the cause value 40:

mml> numan-add:cause:custgrpid="Natl",causevalue=40,setname="chgCause"

Note On the Cisco PGW 2200 Softswitch, internal cause and location values are used for provisioning. In this example, SIP cause 408 and 501 both map to internal cause 40 IC_RECOVERY_ON_TIMER_EXPIRY. Internal cause 40 is mapped to internal cause 91 IC_SUB_ABSENT, which is cause 21 in SS7. For a complete list of all SIP, ISUP, and Cisco PGW 2200 Softswitch internal cause and location values and how they are mapped to each other, see Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.



Cause and Location Value Mapping to Different Values

To map all cause and location values of 3 to cause value 40 and location value 4, perform the following steps:


Step 1 Add the result set, chCause2, in an open provisioning session by using the following MML command:

mml> numan-add:resultset:custgrpid="1111",name="chCause2"
 
   

Step 2 Add cause analysis data (cause value 40 and location value 4):

mml> numan-add:resulttable:custgrpid="1111",setname="chCause2",resulttype="CAUSE", 
name="cause1",dw1=40,dw2=4
 
   

Step 3 Associate the result set, chCause2, with the location block 1 and location block value 2 in the location table:

mml> numan-add:location:custgrpid="1111",locationblock=1,blockvalue=2,setname=chCause2"
 
   

Note The blockvalue in numan-add:location should be one less than the intended internal value. For detailed information on Cause and Location, see the "Cause Analysis" section in Chapter 1, Dial Plan and Routing, of the Cisco PGW 2200 Softswitch Release 9 Dial Plan Guide (through Release 9.7).


Step 4 Add an entry in the cause table, with cause value 0, and location block 1:

mml> numan-add:cause:custgrpid="1111",causevalue="0",locationblock=1
 
   

Cause Value Mapping to Different Cause and Location Values

To map cause value 1 with any location value to cause value 40 and location value 4, perform the following steps:


Step 1 Add the result set, chCause1, in an open provisioning session by using the following MML command:

mml> numan-add:resultset:custgrpid="custid",name="chCause1"
 
   

Step 2 Add cause analysis data (cause value 40 and location value 4)

mml> numan-add:resulttable:custgrpid="1111",setname="chCause1",resulttype="CAUSE",
name="cause1",dw1=40,dw2=4

Step 3 Associate the result set, chCause1, with the cause value 1:

mml> numan-add:cause:custgrpid="custid",causevalue="1",setname="chCause1"
 
   

Multiple Inbound IP Trunks

The Multiple Inbound IP Trunks feature extends the Cisco PGW 2200 Softswitch ability to separate Session Initiation Protocol (SIP) and Extended ISUP (EISUP) traffic into multiple inbound trunk groups on a single interface. You can define inbound trunk groups based on source address, subnet, port number, or a combination of these items.

Separating incoming IP traffic into distinct trunk groups allows you to apply unique provisioning properties to each trunk group. This feature is useful in a multivendor SIP environment because it allows you to manage multiple SIP implementations.

The Multiple Inbound IP Trunks feature also improves security by adding the option to discard new messages that do not match the characteristics of defined inbound trunk groups. You can apply this option to SIP INVITE, REFER, and NOTIFY messages and EISUP Initial Address Message (IAM) messages.

This feature does not affect the provisioning commands used to create SIP and EISUP links or define inbound trunk groups.

Creating a New Inbound SIP Trunk

The instructions to create a SIP path, SIP link, and inbound trunk group are optional—they apply only if you do not have existing SIP links and inbound trunk groups. This feature does not affect the provisioning commands used to create SIP connections or inbound trunk groups.

To add a new inbound SIP trunk, perform the following steps:


Step 1 Add a SIP signaling path in an open provisioning session by using the following MML command:

mml> prov-add:sippath:name="sippath-1",mdo="IETF_SIP",desc="SIP sigpath"
 
   

Step 2 Add SIP links:


Note You can create up to 2 SIP IP links and edit them to add up to 100 new listening ports per SIP IP link.


mml> prov-add:SIPLNK:NAME="sip-sigchan-1", DESC="SIP link 1",SVC="sip-sigpath",
IPADDR="Virtual_IP_Addr1",PORT=5060,PRI=1
mml> prov-add:SIPLNK:NAME="sip-sigchan-2",DESC="SIP link 2",SVC="sip-sigpath", 
IPADDR="Virtual_IP_Addr2",PORT=5060,PRI=2
mml> prov-ed:SIPLNK:NAME="sip-sigchan-1",PORT=5061
mml> prov-ed:SIPLNK:NAME="sip-sigchan-2",PORT=5061
 
   

Note You must define all SIP IP links with the same set of listening ports. In the preceding example, the port parameter was edited twice, one per SIP IP link.


Step 3 (Optional) Add nonstandard port numbers:

mml> prov-add:siplnk:name="siplnk1",svc="sippath-1",ipaddr="IP_ADDR1",port=5060
mml> prov-ed:siplnk:name="siplnk1", port=5076
 
   

Note You must apply the same set of nonstandard port numbers to each SIP link. When you use a nonstandard port number, you must apply the prov-ed:SIPLNK command to each SIP link you define.


Step 4 Add new trunk groups for inbound SIP traffic:

mml> prov-add:trnkgrp:name="1000", svc="sippath-1", type="SIP_IN"
mml> prov-add:trnkgrp:name="1010", svc="sippath-1", type="SIP_IN"
mml> prov-add:trnkgrp:name="1040", svc="sippath-1", type="SIP_IN"
 
   

Step 5 Map IP traffic to trunk groups:


Note In this step, you define the traffic that the Cisco PGW 2200 Softswitch forwards to the new trunk group. You can define the incoming SIP traffic based on incoming IP address, subnet mask, port number (the SIP port on the PGW), or a combination of these elements.


mml> prov-add:ipinmapping:name="sipinmapping-1", sigsvc="sippath-1", 
allowedIP="192.0.2.43",sipport=5063, trnkgrpNum=1000
 
   
mml> prov-add:ipinmapping:name="sipinmapping-3", sigsvc="sippath-1", sipport=5064, 
trnkgrpNum=1010
 
   
mml> prov-add:ipinmapping:name="sipinmapping-2",sigsvc="sippath-1", 
allowedIP="192.0.2.44",allowedIPNetmask="255.255.255.0", trnkgrpNum=1040
 
   
mml> prov-ed:siplnk:name="siplnk1",port=5063
mml> prov-ed:siplnk:name="siplnk1",port=5064
 
   

Step 6 (Optional) Map multiple IP ranges to a single trunk group:

mml> prov-add:ipinmapping:name="sipinmapping-1",sigsvc="sippath-1", 
allowedIP="209.165.200.245",allowedIPNetmask="255.255.255.224",trnkgrpNum=1040
 
   
mml> prov-add:ipinmapping:name="sipinmapping-2", sigsvc="sippath-1", 
allowedIP="209.165.201.21",allowedIPNetmask="255.255.255.224", trnkgrpNum=1040
 
   

Step 7 Enable inbound trunk groups and specify that the Cisco PGW 2200 Softswitch discards incoming traffic that does not match existing incoming IP trunk groups:

mml> prov-add:sigsvcprop:name="sippath-1",ipinscreening=1
 
   

Note The ipinscreening property specifies whether the Cisco PGW 2200 Softswitch permits traffic that does not match defined incoming IP trunk group properties. For detailed information on this property, see Chapter 6, Properties, of Cisco PGW 2200 Softswitch Release 9 MML Command Reference.



Creating a New Inbound ISUP Trunk

The instructions to create an external node, IP path, IP link, and inbound trunk group are optional—they apply only if you do not have existing EISUP links and inbound trunk groups. This feature does not affect the provisioning commands used to create EISUP connections or inbound trunk groups.


Step 1 Add an Cisco PGW 2200 Softswitch external node in an open provisioning session by using the following MML command:

mml> prov-add:extnode:name="pgw-1",type="MGC",desc="External Node PGW2200-1"
 
   

Step 2 Add an EISUP signaling path:

mml> prov-add:eisuppath:name="eisuppath-1",desc="Eisuppath signalling service to PGW-1", 
extnode="pgw-1",custgrpid="tr01"
 
   

Step 3 Add an IP link:

mml> prov-add:iplnk:name="eisuplnk-1",desc="Iplnk#1 to PGW-1",svc="eisuppath-1", 
ipaddr="IP_Addr1",port=5001,peeraddr="192.0.2.43",peerport=5001, pri=1,iproute=""
 
   

Step 4 Add a new trunk group for inbound EISUP traffic:

mml> prov-add:trnkgrp:name="2000",svc="eisuppath-1",type=IP
 
   

Step 5 Map IP traffic to a trunk group:


Note In this step, you define the traffic that the Cisco PGW 2200 Softswitch forwards to the new trunk group. You can define the incoming EISUP traffic based on incoming IP address, subnet mask, port number (the SIP port on the PGW), or a combination of these elements.


mml> prov-add:ipinmapping:name="eisupinmapping-1",sigsvc="eisuppath-1", 
allowedIP="192.0.2.43",trnkgrpNum=2000
 
   

Step 6 Enable the inbound trunk group and specify that the Cisco PGW 2200 Softswitch discards incoming traffic that does not match existing incoming IP trunk groups:

mml> prov-add:sigsvcprop:name="eisuppath-1",ipinscreening=1

Note The ipinscreening property specifies whether the Cisco PGW 2200 Softswitch permits traffic that does not match defined incoming IP trunk group properties. For detailed information on this property, see Chapter 6, Properties, of Cisco PGW 2200 Softswitch Release 9 MML Command Reference.



Support of HSI Non-RAS Mode

In non-Registration, Admission, and Status (RAS) mode, the Cisco PGW 2200 Softswitch converts called numbers into one or two IP addresses in the dial plan to support load sharing over multiple HSIs, which supports H.323 endpoints that have multiple IP addresses. With such support, when the primary IP address does not work, a subsequent attempt is made with the alternative IP address for the same endpoint.

If the Cisco PGW 2200 Softswitch sends an IP address to the HSI over E-ISUP, the HSI sends a SETUP directly to the endpoint. In addition, the Cisco PGW 2200 Softswitch stores the H.323 destination IP address in the Cisco PGW 2200 Softswitch Call Detail Record (CDR).

Cisco PGW 2200 Softswitch Support of HSI non-RAS Mode enables a Cisco PGW 2200 Softswitch to be deployed with a connected Cisco HSI without a gatekeeper in networks that do not require admission or location of the H.323 endpoint. Cisco PGW 2200 Softswitch Support of HSI non-RAS Mode is also used when selection of the endpoint does not benefit from H.323 mechanisms such as Resource Availability Indication (RAI). Examples of such deployments include Cisco Unified Communications Manager (CUCM), H.323 ITS, or cases in which an H.323 gateway provides the only connection to a PBX.

Provisioning Cisco PGW 2200 Softswitch

To enable non-RAS mode on the Cisco PGW 2200 Softswitch, you must provision the sigPath/Trunk group property identified as H323Destination. Non-RAS mode supports two destination addresses configuration, a primary IP address and an alternative IP address.

To provision non-RAS support on the Cisco PGW 2200 Softswitch, perform the following steps:


Step 1 Modify the value of the h323adjunctlink property to 1 to indicate the EISUP signaling path between the Cisco PGW 2200 Softswitch and the Cisco HSI in an open provisioning session by using the following MML command:

mml> prov-add:SIGSVCPROP:name="eisupsvc1",h323adjunctlink="1" 
 
   

Step 2 Use one of the three following options to configure IP addresses:

Configure a primary destination IP address

mml> prov-add:TRNKGRPPROP:name="111",H323Destination="192.168.80.2:1721" 
 
   

Configure a primary destination IP address and an alternative destination IP address

mml> prov-add:TRNKGRPPROP:name="111",H323Destination="192.168.80.2;192.168.80.3" 
mml> prov-add:rttrnkgrp:name="111",type=4,reattempts=1,queuing=0,cutthrough=2, 
resincperc=0
 
   

Note When two destinations are used for a route trunk group, the reattempt value must be set to 1, as in the previous MML command.


Configure gatekeeper mode for the trunk group

mml> prov-add:TRNKGRPPROP:name="111",H323Destination="0.0.0.0" 
 
   

Provisioning Cisco HSI

For the Cisco HSI software configuration required to support the Non-RAS Mode of operation, see Cisco H.323 Signaling Interface User Guide, for Release 4.2.

To enable non-RAS mode on the Cisco HSI, use the following MML command:

mml> prov-add:name=RAS,manualRAS
 
   

Presentation Number Modification

The Presentation Number Modification feature enables a service provider to configure the Cisco PGW 2200 Softswitch to modify the presentation number (PN) for calls between a PSTN network on one side and a SIP server on the other.

Provisioning PN Modification for PSTN to SIP Calls

Figure 5-11 presents a diagram that shows the Cisco PGW 2200 Softswitch properties that the service provider must configured on trunk groups to enable the PN modification feature to convert PNs properly for PSTN-to-SIP Calls.

Figure 5-11 Trunk Group Configuration for PSTN-to-SIP Calls

To enable PN modification for PSTN-to-SIP calls, perform the following steps:


Step 1 Set the value of the trunk group property CCOrigin to 44 on the origination side by using the following MML command:

mml> prov-ed:trnkgrpprop:name="1000",ccorgin="44"
 
   

Step 2 Set the value of the trunk group property ADigitCCPrefix to 1, and BDigitCCPrefix to 1 on the terminating side:


Note Setting ADigitCCPrefix to 1 enables the Cisco PGW 2200 Softswitch to add the prefix country code to both the PN and CgPn. Setting BDigitCCPrefix to 1 enables Cisco PGW 2200 Softswitch to add the prefix country code to the called number.


mml> prov-ed:trnkgrpprop:name="2222",adigitccprefix="1"
mml> prov-ed:trnkgrpprop:name="2222",bdigitccprefix="1"
 
   

Step 3 Add the required country code digit strings for B-number modification:

mml> numan-add:digmodstring:custgrpid="t001",name="ccUK",digstring="44"
 
   

Step 4 Add the result of the CC_DIG result type to the dial plan (identified as t001 in this example):

mml> numan-add:resulttable:custgrpid="t001",name="result2",resulttype="CC_DIG", dw1=UK, 
setname="set5"
 
   

Step 5 Set the value of the MapCLItoSipHeader property to 0 on the terminating side:

mml> prov-ed:trnkgrpprop:name="2222",mapclitosipheader="0"

Note Setting MapCLItoSipHeader to 0 enables the Cisco PGW 2200 Softswitch to map the PN to the display name and the CgPn to the user name in the From Header of the SIP message. If you set the property MapCLItoSipHeader to 3, the Cisco PGW 2200 Softswitch maps the PN to the display name and user name in the From header of the SIP message and the CgPn to the P-Asserted-ID header.


Step 6 Set the value of the cgpnInclude property to either 0 or 1 to alter number display behavior when the presentation indicator is ''presentation restricted.''

mml> prov-add:grprofile:name="grprof",cgpninclude="0"
mml> prov-add:trnkgrpprof:name="2222",grprofile="grprof"

Note A service provider sets the property cgpnInclude to meet the requirements of its network:

If you set cgpnInclude = 0, and the SIP network is not trusted, the From header has SIP URI as: Anonymous <sip:Anonymous@anonymous.invalid>

If you set cgpnInclude = 1, and the SIP network is trusted, and honors the anonymous setting by not passing the CLI to the SIP end point, the From header has URI as Anonymous <sip:CGPN@PGW_HOST>



Provisioning PN Modification for PSTN to SIP Calls

Figure 5-12 presents a diagram that shows the PGW 2200 properties that the service provider must configure on trunk groups to enable the PN Modification feature to convert PNs properly for SIP-to-PSTN calls.

For detailed information on property descriptions, see Chapter 6, Properties, of Cisco PGW 2200 Softswitch Release 9 MML Command Reference.

Figure 5-12 Trunk Group Configuration for SIP to PSTN Calls

To enable PN modification for SIP-to-PSTN calls, perform the following steps:


Step 1 Set the value of the InhibitSipFromMapping property to 3 on the originating side by using the following MML command:

mml> prov-ed:trnkgrpprop:name="2000",custgrpid="DP00",InhibitSipFromMapping="3", 
ADigitCCPrefix="1"
 
   

Step 2 Set the value of the ADigitCCRm (country code to remove in the A-number) and BDigitCCRm (country code to remove in B-number) to 44:

mml> prov-add:trnkgrpprop:name="1000",adigitccrm="44",bdigitccrm="44"
 
   

Step 3 Set the value for the trunk group property CliSelectionForCodeOfPractice3 to provision the level of calling line identity (CLI).

mml> prov-ed:trnkgrpprop:name="1000",cliselectionforcodeofpractice3="2"
 
   

RADIUS Enhancement for Accounting

This feature provides RADIUS interface support on the Cisco PGW 2200 Softswitch for Call Detail Record (CDR) data. CDR data is sent to a preconfigured RADIUS server at the end of the call. CDR data for PSTN-to-IP calls as well as IP-to-PSTN calls is supported. The Cisco PGW 2200 Softswitch can be configured for both RADIUS and normal CDR.

Before you provision the RADIUS enhancement, configure the following parameters in the XECfgParm.dat file:

# Radius Accounting Parameters 
#-------------------------------- 
RadiusAccounting.output = off
RadiusAccounting.numberPort = 20
RadiusAccounting.smSize = 30
 
   

For details on parameter descriptions and configuration procedures, see Cisco PGW 2200 Softswitch Release 9 Software Installation and Configuration Guide (through Release 9.7).

To enable the RADIUS enhancement for accounting, perform the following steps:


Step 1 Add a RADIUS accounting server as an external node in an open provisioning session by using the following MML command:

mml> prov-add:EXTNODE:NAME="ranode",TYPE="RACLUSTER",DESC="Radius accounting server 
cluster"
 
   

Step 2 Add a signaling path to a RADIUS accounting server cluster (made up of one or multiple RADIUS servers):

mml> prov-add:RAPATH:NAME="racluster",DESC="Radius accounting server cluster", 
EXTNODE="ranode"
 
   

Step 3 Add signal channels to the RADIUS accounting server:

mml> prov-add:RASERVER:NAME="raserver1",DESC="radius accounting server1",SVC="racluster", 
IPADDR="IP_Addr1",PORT=1660,PEERADDR="192.0.2.46",PEERPORT=1660,IPROUTE="",ORDER=1, 
KEY="Cisco-h323",TIMEOUT=5,RETRYCOUNT=2,username="Cisco",password="cisco123",authport=1661
 
   
mml> prov-add:RASERVER:NAME="raserver2", DESC="radius accounting server2",SVC="racluster", 
IPADDR="IP_Addr1",PORT=1660,PEERADDR="192.0.2.47",PEERPORT=1660,IPROUTE="",ORDER=2, 
KEY="Cisco-h323",TIMEOUT=10,RETRYCOUNT=4,username="Cisco",password="cisco123",
authport=1661
 
   

SIP and ISUP Interworking for Call Hold and Terminal Portability

This feature supports the message mapping between SIP and ISUP for call hold and terminal portability (TP) supplementary services on the Cisco PGW 2200 Softswitch. The implementation is based on Q.1912.5 Annex B.10 for Call Hold and Annex B.13 for Terminal Portability (TP). ISUP and HSI interworking for Call hold and TP is also supported. The ISUP call hold and TP messages are mapped to EISUP notification message.

To provision SIP and ISUP interworking for call hold and TP, perform the following steps:


Step 1 Add a SIP signaling path in an open provisioning session by using the following MML command:

mml> prov-add:SIPPATH:NAME="sip-path",DESC="Nothing defined",MDO="IETF_SIP"
mml> prov-add:SIPLNK:NAME="sip-lnk",DESC="notSet",SVC="sip-path", 
IPADDR="Virtual_IP_Addr1",PORT=5060,PRI=1
 
   

Step 2 Modify the signaling path properties:

mml> prov-ed:sigsvcprop:name="sip-path",callholdinterworkingenabled="1"
mml> prov-ed:sigsvcprop:name="sip-path",sipcallholdmethod="0"
 
   

Step 3 Add an external node of Cisco HSI type:

mml> prov-add:EXTNODE:NAME="HSI-1",DESC="EISUP to HSI",TYPE="H323",ISDNSIGTYPE="N/A", 
GROUP=0
 
   

Step 4 Add the EISUP signaling path to the Cisco HSI:

mml> prov-add:EISUPPATH:NAME="eisup-hsi-1",DESC="Path to HSI-1",EXTNODE="HSI-1", 
CUSTGRPID="4444"
 
   
mml> prov-add:IPLNK:NAME="eisuplnk-hsi-1",DESC="IP link to HSI-1",SVC="eisup-hsi-1", 
IPADDR="IP_Addr1",PORT=8003,PEERADDR="192.0.2.48",PEERPORT=8003,PRI=1,IPROUTE=""
 
   

Step 5 Add trunks and trunk groups to the Cisco HSI:

mml> prov-add:trnkgrp:name="7000",type="IP",svc="eisup-hsi-1"
mml> prov-add:trnkgrpprop:name="7000",CustGrpId="4444",btechprefix="null"
 
   

On the Cisco HSI, you need to do the following configurations:

SYS_CONFIG_STATIC.VSCA_IPADDR1 = 192.0.2.49
SYS_CONFIG_STATIC.VSCA_PORT_NUMBER1 = 8003
SYS_CONFIG_DYNAMIC.InitiateTCSAfterFSCall = 1
SYS_CONFIG_DYNAMIC.TransmitTCSAfterFSCall = 1
 
   

SIP Overlap Signaling

This feature supports SIP overlap signaling between the Cisco PGW 2200 Softswitch and the Cisco BTS 10200 Softswitch product using a derivative of draft-zhang-sipping-overlap-01, a method for overlap signaling in SIP.

Both the Cisco PGW 2200 Softswitch and the Cisco BTS 10200 support the sending and receiving of overlap dialed digits over SIP. The Cisco PGW 2200 Softswitch also supports the sending and receiving of overlap digits over the SS7 network.

For detailed information on property descriptions, see Chapter 6, Properties, of Cisco PGW 2200 Softswitch Release 9 MML Command Reference.

To provision SIP overlap signaling, perform the following steps:


Step 1 Add the originating trunk group, 444, and the terminating trunk group, 666 using the existing SIP signaling path, sippath1:

mml> prov-add:trnkgrp:name="444",type="SIP_IN",svc="sippath1"
mml> prov-add:trnkgrp:name="666",type="IP_SIP",svc="sippath1"
 
   

Step 2 Enable SIP overlap signaling on both trunk groups:

mml> prov-ed:trnkgrpprop:name="444",toverlap="1" 
mml> prov-ed:trnkgrpprop:name="666",ooverlap="1" 
 
   

Step 3 Set OMinDigits, OMaxDigits, TMinDigits, and TMaxDigits accordingly:

mml> prov-ed:trnkgrpprop:name="444",tmindigits="0",tmaxdigits="20",support183="3",
supportreliable100="SUPPORTED"
mml> prov-ed:trnkgrpprop:name="666",omindigits="0",omaxdigits="20",support183="3", 
supportreliable100="SUPPORTED"
 
   

Step 4 Set the OverlapDigitTime property:

mml> prov-ed:trnkgrpprop:name="444",overlapdigittime="30"
 
   

SIP Remote Party ID and P-Asserted Support

This feature provides support on the Cisco PGW 2200 Softswitch of the ISDN User Part (ISUP)-to-Session Initiation Protocol (SIP) mapping of calling line identity (CLI) to the SIP Remote Party ID header or the P-Asserted ID header. It also updates the generic handling of the SIP-to-ISUP and ISUP-to-SIP mapping of CLI, generic number (GN), and redirecting number (RN).

For detailed information on property descriptions, see Chapter 6, Properties, of Cisco PGW 2200 Softswitch Release 9 MML Command Reference.

Scenario 1

The Cisco PGW 2200 Softswitch maps the calling party number to the SIP From header and ignores the ACgPN if it is presented in the ISUP message. If Presentation in the calling party number is restricted, the Cisco PGW 2200 Softswitch maps the calling party number to the SIP From header as "Anonymous <sip:Anonymous@anonymous.invalid>".

To provision SIP remote party ID and P-asserted support, perform the following steps:


Step 1 Modify the value of the mapclitosipheader property to 0 in an open provisioning session by using the following MML command:

mml> prov-ed:sigsvcprop:name="sip-path",mapclitosipheader="0" 
 
   

Note The default value of mapclitosipheader is 0. If this property is not modified, or you are provisioning from "new", this command is not needed.


Step 2 Add a GRprofile with cgpninclude property value set to 0:

mml> prov-add:PROFILE:NAME="sippro",TYPE="grprofile",cgpninclude="0"
 
   

Step 3 Attach the GRprofile to the outgoing IP trunk group 5600:

mml> prov-add:TRNKGRPPROF:name="5600",grprofile="sippro"
 
   

Scenario 2

The Cisco PGW 2200 Softswitch maps the calling party number to the SIP From header and ignores the ACgPN if it is presented in the ISUP message. If Presentation in the calling party number is restricted, the Cisco PGW 2200 Softswitch maps the calling party number to the SIP From header as "Anonymous <sip:CGPN@PGW_HOST>".

To provision SIP remote party ID and P-asserted support, perform the following steps:


Step 1 Modify the value of the mapclitosipheader property to 0 in an open provisioning session by using the following MML command:

mml> prov-ed:sigsvcprop:name="sip-path",mapclitosipheader="0" 
 
   

Note The default value of mapclitosipheader is 0. If this property is not modified, or you are provisioning from "new", this command is not needed.


Step 2 Add a GRprofile with cgpninclude property value set to 1:

mml> prov-add:PROFILE:NAME="sippro",TYPE="grprofile",cgpninclude="1"
 
   

Step 3 Attach the GRprofile to the outgoing IP trunk group 5600:

mml> prov-add:TRNKGRPPROF:name="5600",grprofile="sippro"
 
   

Scenario 3

The Cisco PGW 2200 Softswitch maps the calling party number to the SIP From header and the P-Asserted ID header. If ACgPN is presented and Presentation is allowed, the Cisco PGW 2200 Softswitch overwrites the SIP From header with the ACgPN. If Presentation is restricted in ACgPN, the Cisco PGW 2200 Softswitch overwrites the SIP From header as "Anonymous <sip:Anonymous@anonymous.invalid>". If Presentation is NA in ACgPN, the Cisco PGW 2200 Softswitch does not overwrite the SIP From header.

To provision SIP remote party ID and P-asserted support, perform the following steps:


Step 1 Modify the value of the mapclitosipheader property to 3 in an open provisioning session by using the following MML command:

mml> prov-ed:sigsvcprop:name="sip-path",mapclitosipheader="3" 
 
   

Step 2 Add a GRprofile with cgpninclude property value set to 0:

mml> prov-add:PROFILE:NAME="sippro",TYPE="grprofile",cgpninclude="0"
 
   

Step 3 Attach the GRprofile to the outgoing IP trunk group 5600:

mml> prov-add:TRNKGRPPROF:name="5600",grprofile="sippro"
 
   

Scenario 4

The Cisco PGW 2200 Softswitch maps the calling party number to the SIP From header and the Remote Party ID header. If ACgPN is presented and Presentation is allowed, the Cisco PGW 2200 Softswitch overwrites the SIP From header with the ACgPN. If Presentation is restricted in ACgPN, the Cisco PGW 2200 Softswitch overwrites the SIP From header as "Anonymous <sip:Anonymous@anonymous.invalid>". If Presentation is NA in ACgPN, the Cisco PGW 2200 Softswitch does not overwrite the SIP From header.

To provision SIP remote party ID and P-asserted support, perform the following steps:


Step 1 Modify the value of the mapclitosipheader property to 1 in an open provisioning session by using the following MML command:

mml> prov-ed:sigsvcprop:name="sip-path",mapclitosipheader="1" 
 
   

Step 2 Add a GRprofile with cgpninclude property value set to 0:

mml> prov-add:PROFILE:NAME="sippro",TYPE="grprofile",cgpninclude="0"
 
   

Step 3 Attach the GRprofile to the outgoing IP trunk group 5600:

mml> prov-add:TRNKGRPPROF:name="5600",grprofile="sippro"
 
   

SIP Service Handling and Feature Interworking Enhancement

This feature introduces a Back to Back User Agent (B2BUA) mode of operation for SIP-to-SIP calls on the Cisco PGW 2200 Softswitch. It also enhances the existing mid-call service handling to better interwork SIP signaling for mid-call services. This feature allows Cisco PGW 2200 Softswitch handling of SIP-to-SIP calls, including intrusive replacement of E.164 addresses appearing in various headers and configurable handling of REFER and 3xx redirect messaging. In addition, this feature enhances the Cisco PGW 2200 Softswitch mid-call service handling for interworking of SIP redirection and transfers with SIP to SIP and SIP to other protocols.

Before you provision SIP service handling and feature interworking enhancement, configure the *.sipModeSelectionControl parameter in the XECfgParm.dat file as follows:

*.sipModeSelectionControl = 1
 
   
# 1 - B2BUA mode, allow later selection of proxy mode via the dial plan.
# 2 - Fixed Proxy mode, always work in proxy mode.
 
   

For detailed descriptions on this parameter and configuration procedures, see Cisco PGW 2200 Softswitch Release 9 Software Installation and Configuration Guide.

To provision SIP service handling and feature interworking enhancement, perform the following steps:


Step 1 Add a result set within the dial plan 1111 in an open provisioning session by using the following MML command:

mml> numan-add:resultset:name="rset1",custgrpid="1111"
 
   

Step 2 Use one of the following commands to add the result of the FACILITY result type:

Proxy mode:

mml> numan-add:resulttable:custgrpid="1111",name="fac01",resulttype="FACILITY", 
dw1="1",setname="rset1"
 
   

Back the backward transit of the Redirection is not supported. The existing redirection mechanism (that is, into Cause analysis) applies:

mml> numan-add:resulttable:custgrpid="1111",name="fac01",resulttype="FACILITY", 
dw1="2",dw2="1",setname="rset1"
 
   

Always support backward transit of the redirection:

mml> numan-add:resulttable:custgrpid="1111",name="fac01",resulttype="FACILITY", 
dw1="2",dw2="2",setname="rset1"
 
   

The backward transit of the Refer is conditionally supported if the received Refer-To header domain in the REFER message (term side) matches the domain in the From header received within the original INVITE on the OCC side:

mml> numan-add:resulttable:custgrpid="1111",name="fac01",resulttype="FACILITY", 
dw1="3",dw2="3",setname="rset1"
 
   

Step 3 Add the entry in the B digit tree:

mml> numan-add:bdigtree:custgrpid="1111",digitstring="612456",callside="originating", 
setname="rset1"

Take Back and Transfer

The Cisco PGW 2200 Softswitch is able to support the following take back and transfer functions with TDM-based and SIP trunks as the calling party and/or the transferring party:

Basic Take Back and Transfer (TNT)

Intelligent Blind Transfer (iTNT) Under INAP Control

Network Blind Transfer (NBT) Under INAP Control

Network Consultation Transfer (NCT) Under INAP Control

No provisioning requirements are required for NBT or NCT. This section provides a provisioning example for iTNT on SIP trunks. Provisioning for TNT is similar to the provisioning of iTNT. However, the route list provisioned for TNT must be a real route list, whereas the route list provisioned for iTNT can be any existing route list. This difference is also pointed out in the following example.


Step 1 Add an overdecadic dial plan for the mid-call service in an open provisioning session by using the following MML command:

mml> numan-add:dialplan:custgrpid="2222",overdec="yes"
 
   

Step 2 Set the value of MidCallServiceCustID to the mid-call dial plan ID:

mml> prov-add:sigsvcprop:name="sipsvc1",MidCallServiceCustID="2222"
 
   

Step 3 Add a result set for iTNT:

mml> numan-add:resultset:custgrpid="2222",name="rset-itnt"
 
   

Step 4 Add the result of the DIGIT_REQ result type:

mml> numan-add:resulttable:custgrpid="2222",name="digit-len",resulttype="DIGIT_REQ",
setname="rset-itnt",dw1="7"
 
   

Note In the preceding command, the total length of digits is 7 (including the length of the string "*8") for intelligent blind transfer service.


Step 5 Add the result of the BMODDIG result type to modify the B number:

mml> numan-add:resulttable:custgrpid="2222",name="itnt-bmod",resulttype="BMODDIG",dw1="1", 
dw2="2",setname="rset-itnt"
 
   

Step 6 Add the result of the ROUTE result type to route the call:

mml> numan-add:resulttable:custgrpid="2222",name="itnt-rte",resulttype="ROUTE", 
dw1="rtlist99", setname="rset-itnt"
 
   

Note For TNT, a real route list name is required in the above command; for iTNT, you can enter any existing route list name in the preceding command.


Step 7 Add an entry in the B digit tree:

mml> numan-add:bdigtree:custgrpid="2222",callside="originating",digitstring="B82", 
setname="rset-itnt"
 
   

Note The digit string "*82xxxx" invokes the mid-call service and transfers the call. The string "*8" is removed from the digits after the digit analysis.


Step 8 Add the result set rset-err for playing announcement:

mml> numan-add:resultset:custgrpid="2222",name="rset-err"
 
   

Step 9 Add a result of the result type INC_NUMBERING:

mml> numan-add:resulttable:custgrpid="2222",name="max-len",resulttype="INC_NUMBERING", 
setname="rset-err",dw1="0",dw2="2",dw3="2"
 
   

Note The result type INC_NUMBERING is used to return an announcement immediately.


Step 10 Add a result of the ANNOUCEMENT result for playing announcement:

mml> numan-add:resulttable:custgrpid="2222",name="itnt-ann",resulttype="ANNOUNCEMENT",
setname="rset-err",dw1="33",dw2="0",dw4="2"

Note For the mid-call announcement, the dw2 must be 0 and dw4 must be 2 (local and final announcement). This announcement is played to the transferring party if the digit string is matched.


Step 11 Add an entry in the B digit tree:

mml> numan-add:bdigtree:custgrpid="2222",callside="originating",digitstring="B9",
setname="rset-err"

Note The string "*9" is not a valid transferred-to number prefix. The provisioned announcement is played when "*9" is dialed.


Step 12 Add the announcement ID in the TimesTen database announcement table:

mml> numan-add:announcement:annId=33,gwtype="AS5350",locationstring="ann_id_22.au",
playduration=10,repeat=1,interval=20
 
   

Step 13 End the provisioning:

mml> prov-cpy
 
   

QoS for Signaling Traffic

The Cisco PGW 2200 Softswitch supports provisionable QoS over all signaling links as well as intra-Cisco PGW 2200 Softswitch traffic.

Use the following MML command in an open provisioning session to add QoS:

mml> prov-add:tos:dscp=CS3
 
   

For detailed information on this MML command, see Chapter 4, PROV: Commands for Provisioning Signaling and Trunking Components, of Cisco PGW 2200 Softswitch Release 9 MML Command Reference.