Table Of Contents
Adding SS7 Signaling Route Components
Adding a Destination Point Code
Understanding Point Code Addressing
24-Bit Address (ANSI and China)
Cisco PGW 2200 Softswitch Point Code Storage
Adding an SS7 Signaling Service
Adding a FAS Signaling Service
Adding Signaling Link Components
Adding Media Gateway Control Links
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 ISDN BRI Backhaul Connections
Verifying Next Hop Parameter Configuration
Adding Cisco Access Server External Nodes
Verifying Next Hop Parameter Configuration
Adding Cisco Access Server External Nodes
Adding DPNSS Signaling Services
Adding DPNSS Supplementary Services
Adding Trunks, Trunk Groups, and Routing
Adding a Nailed Trunk (Bearer Channel)
Adding Mapping to Multiple Trunk Groups
Provisioning Reserving Incoming Bandwidth
Provisioning Bearer Capability
Provisioning Least Cost Routing
Overriding the Trunk Group Property
Enabling Overdecadic 32 Digit Operation
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
Retrieving Multiple Nailed Trunks
Adding Multiple Trunk Groups and Bearer Channels
Removing Multiple Trunk Groups and Bearer Channels
Deleting a Trunk Group Profile
Suppressing Caller ID in a SIP Environment
Provisioning ATM Profiles Result Types
Provisioning Trunk Group Properties
Provisioning SigPath Properties
Adding a SIP Signaling Service
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 Timer for Incoming SIP Trunk Groups
Modifying Session Timer for Outgoing SIP Trunk Groups
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
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
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 M3UA and SUA Signaling Gateway Processes
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
Dynamically Configuring the Input/Output Channel Controller
Configuring Two IP Addresses on the MGW to One IP Address on a NAS
Adding Components with MML
Revised: October 2, 2009, OL-1110-19This 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
•
•
•
•
Before starting an actual configuration, refer to 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.
•
•
•
•
•
•
•
•
•
•
•
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:
•
•
•
•
Note
To add a component, do the following:
Step 1
Step 2
Step 3
mml> prov-add:componentType:name="name",desc="description",paramName=valueWhere:
•
•
•
•
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
To add a destination point code to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:dpc:name="dpc1",netaddr="214.110.80",netind=2,desc="dpc1"Step 2
mml> prov-add:dpc:name="dpc2",netaddr="214.110.90",netind=2,desc="Dest Switch 1"Step 3
Tip
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.
•
Note
•
•
•
•
•
•
•
•
•
•
•
To add another point code to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:opc:name="opc1",desc="OPC1",netaddr="1.2.1",netind=2,type="trueopc"Step 2
mml> prov-add:opc:name="opc1a",desc="CAPOPC",netaddr="1.2.2",netind=2,type="capopc", trueopc="opc1"Step 3
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="10.82.80.129",PORT =7000,PEERPORT=7000,NEXTHOP1="0.0.0.0",NETMASK1="255.255.255.255",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="10.82.80.130",PORT =7000,PEERPORT=7000,NEXTHOP1="0.0.0.0",NETMASK1="255.255.255.255",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",if="enif2",ipaddr="IP_Addr2",port=2427,pri=1,peeraddr="10.10.8.150",peerport=24 27,svc="mgcpsvc1",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 =24prov-add:switchtrnk:name="02",trnkgrpnum="2",span="ffff",cic=1,cu="mgcp1",endpoint="s1/ds1-2/1@sim",spansize= 24prov-add:rttrnkgrp:name="1",type=1,reattempts=3,queuing=0,cutthrough=1prov-add:rttrnk:name="rt1",trnkgrpnum=1prov-add:rtlist:name="rtlist1",rtname="rt1"prov-add:rttrnkgrp:name="2",type=1,reattempts=3,queuing=0,cutthrough=1prov-add:rttrnk:name="rt2",trnkgrpnum=2prov-add:rtlist:name="rtlist2",rtname="rt2"prov-cpyprov-stpUnderstanding 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.
•
•
•
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
Note
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)
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 bitsArea/network identification
8 bitsSignaling 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
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
Note
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
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.
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
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.
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 on page 2-14.
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 on page 2-15.
To add a linkset to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:lnkset:name="linkset1",desc="linkset 1 to STP-A",apc="STP-A",type="IP", proto="SS7-ANSI"Step 2
mml> prov-add:lnkset:name="linkset2",desc="linkset 2 to STP-B",apc="STP-B",type="IP", proto="SS7-ANSI"Step 3
Tip
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 on page 2-15.
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",s lsTimer="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 on page 2-20.
To add an SS7 subsystem to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:ss7subsys:name="mate1",svc="STPA",matedapc="STPB",proto="SS7-ANSI",pri=1, desc="mate STPA to STPB"Step 2
mml> prov-add:ss7subsys:name="mate2",svc="STPB",matedapc="STPA",proto="SS7-ANSI",pri=2, desc="mate STPB to STPA"Step 3
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=2mml> prov-add:APC:NAME="STPB-5-83-231",DESC="STPB LA 5-83-231",NETADDR="5.83.231",NETIND=2mml> 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=1mml> 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=1mml> prov-add:SS7ROUTE:NAME="route-STPA",DESC="route to STPA",OPC="opc-itxc-la", DPC="stpA-5-83-231",LNKSET="ls1",PRI=1mml> prov-add:SS7ROUTE:NAME="route-stpB",DESC="route to STPB",OPC="opc-itxc-la", DPC="STPB-5-83-230",LNKSET="ls2",PRI=1
Tip
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 on page 2-20.
To add a subsystem number to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
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
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
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 on page 2-22.
To add an SS7 route to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:ss7route:name="rte1DPC1",opc="OPC",dpc="DestSW1PC",lnkset="linkset1", pri=1,desc="route 1 to DestSW1 thru STP-A"Step 2
mml> prov-add:ss7route:name="rte2DPC1",opc="OPC",dpc="DestSW1PC",lnkset="linkset2", pri=1,desc="route 2 to DestSW1 thru STP-B"Step 3
Tip
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 on page 2-22.
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
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 on page 2-39.
Note
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=1Use 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
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 on page 2-30.
Note
To add an interface card to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:card:name="Ethernet1",type="EN",slot=0,desc="Ethernet Card 1"Step 2
mml> prov-add:card:name="Ethernet2",type="EN",slot=1,desc="Ethernet Card 2"Step 3
Tip
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 on page 2-30.
Note
To add an Ethernet interface to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD command as follows:
Step 1
mml> prov-add:enetif:name="EtherIF1",desc="Ethernet IF 1",card="Ethernet1"Step 2
mml> prov-add:enetif:name="EtherIF2",desc="Ethernet IF 2",card="Ethernet2"Step 3
Tip
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 on page 2-33.
Tip
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
Tip
Note
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=0Use 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 on page 2-31.
Note
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=64Use the PROV-RTRV command to verify the TDM card was added.
Table 5-1 shows typical parameters based on card type.
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
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
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 on page 2-35.
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
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
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
Note
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 on page 2-39.
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
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 on page 2-39.
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=1Use 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 on page 2-39.
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, refer to Table A-69 on page A-113 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 on page 2-39.
Note
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
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 on page 2-41.
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
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.
•
•
•
•
•
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="10.82.80.129",PORT=7000,PEERPORT=7000,NEXTHOP1="0.0.0.0",NETMASK1="255.255.255. 255",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 ESTM RTRV"session=wags2:sessionset"/*NAME = c7-2600-1-1DESC = Session Set c7-2600-1 Backhaul Link 1EXTNODE = va-2600-stim1IPADDR = IP_Addr1PORT = 7000PEERADDR = 10.82.80.129PEERPORT = 7000NEXTHOP = 0.0.0.0NETMASK = 255.255.255.255TYPE = BSMV0Adding 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:
•
•
•
Note
To add two back up D-channels to the media gateway configuration, use the PROV-ADD command as follows:
Step 1
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=0Step 2
Note
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=0Use 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 neverRefer to the documentation for your voice gateway for more information.
Note
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
Step 2
mml>prov-add:extnode:name="va-3640-01",desc="BRI 3640",type="C3640",isdnsigtype="na"Step 3
Step 4
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
Step 5
mml>prov-add:tcplink:NAME="britcp1",DESC="BRI TCP link 1",TYPE="BRI",IPADDR="IP_Addr1", PORT="1024",PEERADDR="10.82.80.187",PEERPORT="1024",extnode="va-3640-01,IPROUTE="iprte1"Step 6
Step 7
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
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:
•
•
•
Note
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
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Note
Step 4
Step 5
Step 6
/etc/init.d/CiscoMGC stopStep 7
/etc/init.d/CiscoMGC startStep 8
mml> sw-over::confirmSite 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
Adding Cisco Access Server External Nodes
To add Cisco access server external nodes to your provisioning data, perform the following steps:
Step 1
Step 2
mml> prov-add:extnode:name="va-5400-36",desc="AS5400",type="AS5400",isdnsigtype="iua"Step 3
Step 4
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
Step 2
mml> prov-add:naspath:NAME="nassvc1",DESC="IUA NAS path",extnode="va-5400-37",sigport=45, sigslot=10Step 3
Step 4
Otherwise, you may:
•
•
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
Step 2
mml> prov-add:IPROUTE:NAME="iprte1",DESC="IP Route 1",dest="10.82.80.0",ipaddr="IP_Addr1", netmask="255.255.255.0",nexthop="10.82.82.1"Step 3
Step 4
Otherwise, proceed to Adding SCTP Associations.
Adding SCTP Associations
To add SCTP associations to your provisioning data, perform the following steps:
Step 1
Step 2
mml> prov-add:ASSOCIATION:NAME="nasassoc1",DESC="NAS Association 1",TYPE="IUA", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164", extnode="va-5400-37,IPROUTE1="iprte1",IPROUTE2="iprte2"
Note
Step 3
Step 4
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:
•
•
•
•
Note
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
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Note
Step 4
Step 5
Step 6
/etc/init.d/CiscoMGC stopStep 7
/etc/init.d/CiscoMGC startStep 8
mml> sw-over::confirmSite 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
Adding Cisco Access Server External Nodes
To add Cisco access server external nodes to your provisioning data, perform the following steps:
Step 1
Step 2
mml> prov-add:extnode:name="va-5400-36",desc="AS5400",type="AS5400",isdnsigtype="iua"Step 3
Step 4
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
Step 2
mml> prov-add:IPROUTE:NAME="iprte1",DESC="IP Route 1",dest="10.82.80.0",ipaddr="IP_Addr1", netmask="255.255.255.0",nexthop="10.82.82.1"Step 3
Step 4
Otherwise, proceed to Adding SCTP Associations.
Adding SCTP Associations
To add SCTP associations to your provisioning data, perform the following steps:
Step 1
Step 2
mml> prov-add:ASSOCIATION:NAME="nasassoc1",DESC="NAS Association 1",TYPE="IUA", IPADDR1="IP_Addr1",IPADDR2="IP_Addr2",PEERADDR1="10.82.80.187",PEERADDR2="10.82.81.164", extnode="va-5400-37",IPROUTE1="iprte1",IPROUTE2="iprte2"
Note
Step 3
Step 4
Otherwise, proceed to Adding DPNSS Signaling Services.
Adding DPNSS Signaling Services
To add DPNSS signaling services, perform the following steps:
Step 1
Step 2
mml> prov-add:dpnssspath:NAME="dpnsssvc1",DESC="IUA DPNSS path",extnode="va-3660-20", sigport=45,sigslot=10Step 3
Step 4
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
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 on page 2-50.
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
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 on page 2-50.
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=1Use the PROV-RTRV command to verify the nailed trunk was added.
Tip
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 on page 2-58.
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
To add routing files to the Cisco PGW 2200 Softswitch configuration, use the PROV-ADD commands as follows:
Step 1
mml> prov-add:rttrnkgrp:name="501",type=7,reattempts=1,queuing=0,cutthrough=2Step 2
mml> prov-add:rttrnk:name="rt513",trnkgrpnum=513Step 3
mml> prov-add:rtlist:name="rtlist501",rtname="rt501"Step 4
Tip
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
mml> prov-add:bearercap:name="bearer1",bearercap="12;05;31"Step 2
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
mml> prov-add:rrttrnkgrp:name="1",type=1,reattempts=3,queuing=0,cutthrough=1, bearercapname="bearer1"Step 4
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 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 GMTM RTRV"session=nexttrnkgrp:rttrnk"/*routeName---------routeatrunkGroup nextTrunkGroup---------- --------------2000 30003000 40004000 50005000*/=======================================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=2000MGC-01 - Media Gateway Controller 2002-02-23 01:17:00.944 GMTM COMPLD"rttrnk";mgc4 mml> prov-rtrv:rttrnk:name="routea"MGC-01 - Media Gateway Controller 2002-02-23 01:17:03.039 GMTM RTRV"session=nexttrnkgrp:rttrnk"/*routeName---------routeatrunkGroup nextTrunkGroup---------- --------------5000 20002000 30003000 40004000*/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=3000MGC-01 - Media Gateway Controller 2002-02-23 01:21:34.762 GMTM COMPLD"rttrnk";mgc4 mml> prov-rtrv:rttrnk:name="routea"MGC-01 - Media Gateway Controller 2002-02-23 01:21:36.854 GMTM RTRV"session=nexttrnkgrp:rttrnk"/*routeName---------routeatrunkGroup nextTrunkGroup---------- --------------5000 20002000 40004000*/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
mgc4 mml> prov-ed:rttrnk:name="routea",trnkgrpnum=3000MGC-01 - Media Gateway Controller 2002-02-23 01:22:17.770 GMTM COMPLD"rttrnk";mgc4 mml> prov-rtrv:rttrnk:name="routea"MGC-01 - Media Gateway Controller 2002-02-23 01:22:19.621 GMTM RTRV"session=nexttrnkgrp:rttrnk"/*routeName---------routeatrunkGroup nextTrunkGroup---------- --------------5000 20002000 40004000 30003000*/;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=5000MGC-01 - Media Gateway Controller 2002-02-23 01:47:24.965 GMTM COMPLD"rttrnk";mgc4 mml> prov-rtrv:rttrnk:name="routea"MGC-01 - Media Gateway Controller 2002-02-23 01:47:26.551 GMTM RTRV"session=nexttrnkgrp:rttrnk"/*routeName---------routeatrunkGroup nextTrunkGroup---------- --------------3000 50005000 20002000 40004000*/;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 on page 2-61.
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
Note
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
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
mml> prov-add:trnkgrpprop:name="1000",OD32DigitSupport="1"
Note
Step 2
Media Gateway Controller - MGC-03 2003-02-17 14:25:56M COMPLD "trnkgrp"Step 3
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
mml> prov-rtrv:trnkgrpprop:name="1000"Step 2
Media Gateway Controller - MGC-03 2003-02-17 14:27:52M RTRV"session=trnkgrpprop"/*BOrigStartIndex = 0BTermStartIndex = 1CarrierIdentity = 0CLLI = STEVECompressionType = 1CotPercentage = 0CustGrpId = 0000EchoCanRequired = 0ExtCOT = LoopGLARE = 0Npa = 0RingNoAnswer = 255000SatelliteInd = 0ScreenFailAction = 0···OD32DigitSupport = 1*/;
Provisioning SUBSCRIBE/NOTIFY Methods
Note
The procedures for provisioning the SUBSCRIBE/NOTIFY methods are in the following sections:
•
•
Enabling SUBSCRIBE/NOTIFY Methods
Use the following steps to enable the SUBSCRIBE/NOTIFY methods:
Step 1
Step 2
mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",SubscribeNotifySupport=1For 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=1Step 3
Disabling SUBSCRIBE/NOTIFY Methods
Use the following steps to disable the SUBSCRIBE/NOTIFY methods:
Step 1
Step 2
mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",SubscribeNotifySupport=0For 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=0Step 3
Provisioning Unsolicited Notifications
Note
The procedures for provisioning unsolicited notifications are in the following sections:
•
•
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
Step 2
mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",UnsolicitedNotifyMethod=1For 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=1Step 3
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
Step 2
mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid",UnsolicitedNotifyMethod=0For 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=0Step 3
Provisioning Subscription Duration
Note
The procedures for provisioning the duration data for subscriptions are in the following sections:
•
•
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
Step 2
mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid", MinEventSubscribeDuration=minsubFor 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=200Step 3
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
Step 2
mml> prov-ed:trnkgrpprop:name="trnkgrpnum",custgrpid="grpid", MaxSubscriptionDuration=maxsubFor 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=3600Step 3
Enabling/Disabling Information Extraction from SDP
Note
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
Step 2
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
Disabling Support of Information Extraction from SDP
Use the following steps to disable extracting SDP information for billing purposes.
Step 1
Step 2
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
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 on page 2-58. 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"
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=6The previous command added the six nailed trunks shown in Table 5-4.
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
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
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=2Use 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:
•
•
•
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
Adding a Trunk Group Profile
Only specify the NAME and PROFILENAME parameters to add a trunk group profile for the specified trunk group.
Note
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
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 Appendix A, "Profile," 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 Appendix A, "Protocol Variants." 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:
•
•
•
•
•
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-6 GN Suppression in a SIP Environment
(in IAM)
Displayname field
Username fieldNot 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-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.
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 ATMProfilesatmprof1 ITU1;cust100Provisioning 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
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="10.0.14.145",sipport=5063, trnkgrpNum=1000Use the PROV-RTRV to verify the incoming trunk group properties.
For more information about the IPINMAPPING component, see IPINMAPPING, page A-22.
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=0Use 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="10.82.81.75",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="10.82.81.75",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="10.82.81.75",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="10.82.80.58",srvrr=0,sipproxyport=5060,version="2.0" ,cutthrough=1,extsupport=1prov-add:siprttrnkgrp:name="706",url="10.82.80.58",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=707prov-add:rttrnk:name="route706",trnkgrpnum=706prov-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-stpModifying 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 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
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Note
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
Note
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
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
Step 7
Step 8
/etc/init.d/CiscoMGC stopStep 9
/etc/init.d/CiscoMGC startStep 10
mml> sw-over::confirmSite 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
Step 12
Step 13
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
To provision virtual IP address(es) on your SIP IP links, perform the following steps:
Step 1
Step 2
Step 3
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 adress 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
mml> set-iplnk:name:OOSWhere 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
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
Step 7
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
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
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
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
Step 12
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
Perform the following steps to disable the virtual IP addresses on your SIP IP links, :
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Step 4
Step 5
Step 6
Step 7
/etc/init.d/CiscoMGC stopStep 8
/etc/init.d/CiscoMGC startStep 9
mml> sw-over::confirmSite 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
Step 11
mml> set-iplnk:name:OOSWhere 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
Step 13
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
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
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
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
Adding SIP-T and SIP-GTD Support
Note
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 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
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
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_stringThe 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 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
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
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:
•
•
•
•
•
•
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 127For 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=10The 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
Adding an NOA Value to the LineXlate File for Inbound Calls
Perform the following steps to provision the Configurable NOA Mapping Feature.
Step 1
mml> prov-sta::srcver="linexlt1",dstver="mml_01"
Caution
Step 2
mml> prov-add:linexlate:name="noa1",desc="noa in calling 10",svc="ss7svc1",
direction="in",number="calling",intnoa=17,extnoa=10Step 3
mml> prov-cpyStep 4
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
mml> prov-sta::srcver="01",dstver="mml_02"Step 2
mml> prov-dlt:linexlate:name="noa1"Step 3
mml> prov-cpyStep 4
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
mml> prov-sta::srcver="02",dstver="mml_03"Step 2
mml> prov-add:linexlate:name="noa2",desc="noa in calling 10",svc="ss7svc1",
direction="out",number="called",intnoa=17,extnoa=10Step 3
mml> prov-cpyStep 4
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
mml> prov-sta::srcver="03",dstver="mml_04"Step 2
mml> prov-dlt:noaxlate:name="noa2"Step 3
mml> prov-cpyStep 4
mml> prov-rtrv:linexlate:name="noa2"
Validation Rules
•
•
•
•
Note
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
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
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
Add a DPC named dpc1 by entering the following MML command.
mml> prov-add:DPC:NAME="dpc1",DESC="DPC1",NETADDR="1.1.5",NETIND=2Add an APC named apc1 by entering the following MML command.
mml> prov-add:apc:NAME="apc1",DESC="apc1",NETADDR="1.2.4",NETIND=2Adding 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=10Add 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=20Adding 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=40Adding 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=48Adding 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="10.82.80.0",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="10.82.80.187", PEERADDR2="10.82.81.164"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
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
prov-stpprov-sta::srcver="new",dstver="ver1"prov-add:loclabel:name="loclbl1",desc="local label 1",calllimit=2345prov-add:loclabel:name="loclbl2",desc="local label 2",calllimit=6000prov-rtrv:loclabel:name="loclbl1"prov-rtrv:loclabel:name="loclbl2"prov-rtrv:loclabel:"all"locationLabel.dat005f0001 2345005f0002 6000prov-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=2prov-add:DPC:NAME="dpc2",DESC="Dest. point code",NETADDR="3.3.3",NETIND=2prov-add:EXTNODE:NAME="dpnss-gw1",DESC="nas 2600 Backhaul",TYPE="C2600", ISDNSIGTYPE="IUA",GROUP=0prov-add:EXTNODE:NAME="eisup1",DESC="external node - eisup",TYPE="MGC", ISDNSIGTYPE="N/A",GROUP=0prov-add:EXTNODE:NAME="ipfas1",DESC="external node - ipfas",TYPE="C2600", ISDNSIGTYPE="N/A",GROUP=0prov-add:EXTNODE:NAME="ss7sg1",DESC="external node - ss7sg",TYPE="TALISS7", ISDNSIGTYPE="N/A",GROUP=0prov-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:SGNode:NAME="sgnode1",TYPE="TALISS7"prov-add:SGNode:NAME="sgnode2",TYPE="TALISS7"prov-add:SGPair:NAME="sgpair1",SGNODE="sgnode1",MATEDSGNODE="sgnode2"prov-add:ss7sgpath:name="ss7sg-sigpath",mdo="ANSISS7_STANDARD",desc="SS7SGP sigpath", CUSTGRPID="1111",SIDE="network",DPC="dpc2",OPC="opc",SGPAIR="sgpair1", 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 EDTM RTRV"session=egw-2:sippath"/*NAME = sip-pathDESC = sip pathMDO = IETF_SIPORIGLABEL =TERMLABEL =*/;sigPath.dat00150001 SS7-ANSI ANSISS7_STANDARD 1111 0101 0 network n 2 00130002 00130001 00000000 00000000 0 005f0001 005f000200190001 EISUP EISUP 0000 0101 0 network n 2 00000000 00000000 00000000 00000000 0 005f0001 005f000200340001 dummy 0000 0101 0 network n 2 00000000 00000000 00000000 00000000 0 005f0001 005f0002003e0001 SIP IETF_SIP 0000 0101 0 network n 2 00000000 00000000 00000000 00000000 0 005f0001 005f000200420001 SS7-ANSI ANSISS7_STANDARD 1111 0101 0 network n 2 00130003 00130001 00410001 00000000 0 005f0001 005f000200550001 DPNSS DPNSS_BTNR188 1111 0101 26 network n 2 00000000 00000000 00000000 00000000 513 005f0001 005f0002prov-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 EDTM RTRV"session=begon-base1:trnkgrp"/*NAME = 3000CLLI = stim-dpnss1SVC = sip-sigpathTYPE = SIP_INSELSEQ = LIDLORIGLABEL =TERMLABEL =*/;trunkGroup.dat00200001 3000 0000 0000 003e0001 SIP_IN LIDL 0 N 0/0/0/0 0/0/0/0 005f0001 005f0002components.dat00570001 00010001 "LI" "LI Radius Protocol Family"005f0001 00010001 "loclbl1" "local label 1"005f0002 00010001 "loclbl2" "local label 2"
Note
Applying Call Limiting Over DPNSS
The following provisioning example, see Figure 5-4, 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=10prov-add:DPNSSPATH:NAME="dpnss-path1",DESC="dpnss va-3745-2",EXTNODE="va-3745-2", CUSTGRPID="1111",SIGSLOT=1,SIGPORT=0prov-add:trnkgrp:name="7000",type="TDM_DPNSS",svc="dpnss_path1",clli="7000',selseq="ASC", qable="N",origlabel="location2",termlabel="location2"Figure 5-4 DPNSS Call Limiting Scenario
Applying Call Limiting to Incoming and Outgoing Trunk Groups
The following provisioning scenario, see Figure 5-5, 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 limitprov-add:loclabel:name="location1",calllimit=12numan-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 limitnuman-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-5 Incoming and Outgoing Trunk Group Call Limiting Scenario
B-number Based Call Limiting Scenario
The following provisioning scenario, see Figure 5-6, 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=100numan-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-6 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 10prov-add:loclabel:name="location1",calllimit=10//provision SIP pathprov-add:SIPPATH:NAME="sip-path",DESC="SIP path",MDO="IETF_SIP",ORIGLABEL="",TERMLABEL=""//provision SIP linkprov-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="10.0.1.2",version="2.0",cutthrough=2,srvrr=2, extsupport=1 //provision outgoing call limit for SIP trunk groupprov-add:trnkgrp:name="7000",type="IP_SIP",svc="sip-path",clli="",selseq="LIDL", origlabel="location1",termlabel="location1"//provision incoming call limit for SIP trunk groupprov-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 HSIprov-add:EISUPPATH:NAME="eisup-hsi",DESC="to orchid",EXTNODE="sh-hsi",CUSTGRPID="1111" //provision call limit for H.323 trunk groupprov-add:trnkgrp:name="6000",CLLI="sh-daisy",svc="eisup-hsi",type="IP",selseq="ASC", qable="N",origlabel="location2",termlabel="location2"
Note
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 pathprov-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 groupprov-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 10prov-add:loclabel:name="location1",calllimit=10//provision both incoming and outgoing call limit for SS7 trunk groupprov-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 groupprov-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 groupprov-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 provisioningnuman-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2",interval="3", locationstring="xyz.aud"//provision local announcementnuman-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 resultsetnuman-add:resultset:custgrpid="1111",name="set200"//provision call limit location label in resultsetnuman-add:resulttable:resulttype="LOC_LABEL",dw1="location2",setname="set200", custgrpid="1111",name="resultloc200"//provision route resulttablenuman-add:resulttable:custgrpid="1111",name="result200",resulttype="ROUTE",dw1="rtlist2", setname="set200"//provision Bdigtree for B-number 300XXXnuman-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 resultsetnuman-add:resulttable:resulttype="LOC_LABEL",dw1="location2",setname="set201", custgrpid="1111",name="resultloc201"//provision Adigtree for A-number 300XXXnuman-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 7000prov-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 8000prov-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 9000prov-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 10.0.1.1, 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 pathprov-add:EISUPPATH:NAME="eisup-orkid",DESC="to orchid",EXTNODE="sh-orchid",CUSTGRPID="1111",ORIGLABEL="location5",TERMLABEL="location5"//provision EISUP IP linkprov-add:IPLNK:NAME="elinkorchid1",DESC="Link to orchid",SVC="eisup-orchid", IPADDR="IP_Addr1",PORT=8001,PEERADDR="10.0.1.1",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=100prov-add:EISUPPATH:NAME="eisup-orkid",DESC="to orchid",EXTNODE="sh-orchid", CUSTGRPID="1111"//provision EISUP IP linkprov-add:IPLNK:NAME="elinkorchid1",DESC="Link to orchid",SVC="eisup-orchid", IPADDR="IP_Addr1",PORT=8001,PEERADDR="10.0.1.1",PEERPORT=8001,PRI=1,IPROUTE=""//provision call limit in EISUP trunk groupprov-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 10.0.1.2, 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 pathprov-add:SIPPATH:NAME="sip-path",DESC="SIP path",MDO="IETF_SIP",ORIGLABEL="",TERMLABEL="" //provision SIP linkprov-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="10.0.1.2",version="2.0",cutthrough=2,srvrr=2, extsupport=1//provision call limit in SIP trunk groupprov-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 10.0.1.4, 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 pathprov-add:MGCPPATH:NAME="mgcp530011",DESC="MGCP service to AS-5300-11",EXTNODE="va-5300-11"//provision IP linkprov-add:IPLNK:NAME="clink11-1",DESC="MGCPlink to sh-5300-11",SVC="mgcp530011", IPADDR="IP_Addr1",PORT=2427,PEERADDR="10.0.1.4",PEERPORT=2427,PRI=1,IPROUTE=""//provision call limit for SS7 sigPathprov-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 provisioningnuman-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2",interval="3", locationstring="xyz.aud"//local announcementnuman-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
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.
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
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",confirmprov-add:CARD:NAME="MBRD",DESC="Motherboard",TYPE="EN",SLOT=0prov-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=2prov-add:apc:name="stp2",DESC="Own pointcode",NETADDR="1.1.2",NETIND=2prov-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=2prov-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=1prov-add:SS7ROUTE:NAME="rte2",DESC="opc-stp1-dpc2",OPC="opc",DPC="dpc2",LNKSET="ls1",PRI=1prov-add:SS7ROUTE:NAME="rte3",DESC="opc-stp2-dpc1",OPC="opc",DPC="dpc1",LNKSET="ls2",PRI=1prov-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=0prov-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-cpyprov-stpThe 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 0framing esfclock source line primarylinecode b8zspri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 0!controller T1 1framing esfclock source line secondary 1linecode b8zspri-group timeslots 1-24 nfas_d none nfas_int 1 nfas_group 0!controller T1 2framing esflinecode b8zspri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 0!controller T1 3framing esflinecode b8zspri-group timeslots 1-24 nfas_d none nfas_int 3 nfas_group 0!! !interface Serial0:23no ip addressisdn switch-type primary-niisdn incoming-voice modemisdn rlm-group 1no isdn send-status-enquiryisdn negotiate-bchan resend-setupfair-queue 64 256 0no cdp enable!interface FastEthernet0description production 100 Mbit hubip address 10.82.81.29 255.255.255.0no ip route-cacheno ip mroute-cacheduplex fullspeed auto !ip classlessip route 0.0.0.0 0.0.0.0 10.82.81.1 !rlm group 1server va-kentlink address 10.82.82.53 source FastEthernet0 weight 2link address 10.82.83.53 source FastEthernet0 weight 1server va-surreylink address 10.82.82.55 source FastEthernet0 weight 2link 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 UGH10.82.82.0 255.255.255.0 10.82.82.53 hme0 U10.82.83.0 255.255.255.0 10.82.83.53 hme1 U224.0.0.0 240.0.0.0 10.0.1.10 hme0 Udefault 0.0.0.0 10.82.82.1 UG127.0.0.1 255.255.255.255 127.0.0.1 lo0 UHIf 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 UGH10.82.82.0 255.255.255.0 10.82.82.53 hme0 U10.82.83.0 255.255.255.0 10.82.83.53 hme1 U224.0.0.0 240.0.0.0 10.0.1.10 hme0 Udefault 0.0.0.0 10.82.82.1 UG127.0.0.1 255.255.255.255 127.0.0.1 lo0 UHIf 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.
