Cisco MGC Software Software 9.2 Featurettes and Enhancements

Table Of Contents

Software Release 9.2(x) - 9.4(1)Enhancements

Dual Ethernet Support

SLT Software Release

MML Command Changes

MML Command Examples

Creating an External Node

Creating Point Codes

Creating an SS7 Signaling Path

Creating a Link Set

Creating a Route Set

Creating a Session Set

Creating C7IPLink

Creating Session Property

Protocol Family-Specific Default Property Override

Software Release 9.2(2) Enhancements

Country Code Prefix Trunk Group Capability

GTD NOA Override

dat file Changes

Time Conditional Routing

Bug Fixes

Software Release 9.4(1) Enhancements

INSERVICE

Intelligent Network Service Creating Examples

Intelligent Network Service Editing Example

Intelligent Network Service Deleting Example

Intelligent Network Service Retrieving Examples

SS7 Subsystem

OD32DigitSupport Property

Software Release 9.2(x) - 9.4(1)Enhancements

---

The following sections contain an description of the dual Ethernet support (for Release 9.2(1)) when used with the Cisco PGW 2200.

Dual Ethernet Support

Dual Ethernet support enhances MGC-to-SLT interface reliability. Typically, communication between SLT and the MGC is carried over an IP network (a single Ethernet interface on the SLT) using RUDP. Presently the RUDP connection is established over a single Ethernet interface (IP and port pair), thereby making the interface a single point of failure. Using two Ethernet interfaces on the SLT enhances the reliability between the MGC and the SLT.

SLT Software Release

The dual Ethernet function is supported on the SLT with the Version 12.1(5)XM SLT image.

MML Command Changes

Using the MML commands, sessions and session sets can be provisioned (for example, added, deleted, edited, and retrieved). The MML commands can also be used to retrieve the backhaul links status. The changes to MML commands are as follows:

•Prov-add:extnode has SLT added as a type, as listed in Table C-1.

•The following parameters are no longer valid for the C7iplnk prov-add or prov-ed MML command: PORT, IPADDR, PEERADDR, NEXTHOP, and NETMASK.

•The parameter SESSIONSET is added to the prov-add and prov-ed C7iplnk MML commands.

Table C-1 External Node Type Choices 

MML Parameter Name	Voice Services Provisioning Tool Parameter Name	Default Value	Description
TYPE		None	Identifies the type of external node in the left column. Acceptable values are shown in the left column. The right columns show the associated signaling type: •AS3660 MGCP SGCP IPFAS NAS •AS5200 IPFAS NAS •AS5300 MGCP SGCP IPFAS NAS •AS5350 MGCP SGCP IPFAS NAS BSMV0 •AS5400 MGCP SGCP IPFAS NAS BSMV0 •AS5800 IPFAS NAS •AS5850 IPFAS NAS •AS7200 MGCP SGCP IPFAS NAS •CAT8510 MGCP SGCP •CAT8540 MGCP SGCP •H323 EISUP •LS1010 MGCP SGCP •MC3810 MGCP IPFAS •MGC EISUP •MGX8260 MGCP IPFAS NAS •MGX8850 MGCP SGCP IPFAS •SCP TCAPIP •SLT BSMV0 •TALISS7 SS7SG •UNKNOWN UNKNOWN

MML Command Examples

The following sections contain MML command examples used to add an SLT external node and accompanying session set.

Creating an External Node

prov-add:extnode:name="ss7node",type="SLT",desc="2600 SLT"

Creating Point Codes

prov-add:opc:name="opc",netaddr="1.1.3",netind=2,type="TRUEOPC",desc="Own Pointcode"

prov-add:dpc:name="dpc1",netaddr="1.1.1",netind=2,desc="pdc1 apc1"

Creating an SS7 Signaling Path

Prov-add:ss7path:name="ss7svc1",mdo="ANSISS7_STANDARD",dpc="dpc1",opc="opc",desc="SS7 
service to dpc1"

Creating a Link Set

prov-add:lnkset:name="ls1",desc="link set 1 to stp1",apc="dpc1",type="IP",proto="SS7-ANSI"

Creating a Route Set

prov-add:ss7route:name="rte1",desc="route rte1",dpc="dpc1",lnkset="ls1",opc="opc"

Creating a Session Set

prov-add:sessionset:name="set1",ipaddr1="IP_Addr1",ipaddr2="IP_Addr2",port=7000, 
peeraddr1="peer11",peeraddr2="peer12",peerport=8001,extnode="ss7node",type="BSMV0"

Creating C7IPLink

prov-add:c7iplnk:name="ls1link1",sessionset="set1",pri=1,slc=0,lnkset="ls1",desc="link 0 
of ls1 to 2600-1",timeslot=0

Creating Session Property

prov-add:sessionprop:name="set1-2",rudpNumRetx="8",rudpRetxTimer="8"

prov-add:sessionprop:name="set1-1",rudpNumRetx="9",rudpRetxTimer="9"

Protocol Family-Specific Default Property Override

In Release 9.2(1)T, use the prov-ed command to override the protocol family default property settings. This provides the capability of modifying the linkset properties for the SS7 protocol families (that is, SS7-ANSI, SS7-China, SS7-ITU, SS7-Japan, and SS7-UK). Linkset properties include timers and signaling service properties. Use the following syntax format for overriding default properties.

prov-ed:lnksetprop:name="<prot fam>",<prop name>="<prop val>"

The following MML command is a linkset property override example.

prov-ed:lnksetprop:name="SS7-ANSI",mtp2LssuLen"2",mtp2T2="55"

Similarly, you can use the prov-rtrv command to retrieve signaling service default property values. The following syntax format is used to retrieve default link set property values.

prov-rtrv:lnkset:name="<prot fam>"

The following MML command is a signaling service property override example.

prov-ed:sigsrvprop:name="SS7-ANSI",CGBA2="1",CLIPEss="1"

Software Release 9.2(2) Enhancements

The following sections contain information regarding enhancements and caveats supported in the software Release 9.2(2).

Country Code Prefix Trunk Group Capability

To support the country code prefix trunk group capability for national and international switching applications, the properties listed in Table C-2 have been added.

---

Note The new properties are only required when the property domain is SigPath or LinkSet.

---

Table C-2 Properties 

Property	Definition
*.ADigitCCPrefix	Enables or disables the ability to apply a country code prefix to the calling party number before sending the call forward. Values are 0 or 1, where 0 is disabled and 1 is enabled. Default: 0
*.BDigitCCPrefix	Enables or disables the ability to apply a country code prefix to the called party number before sending the call forward. Values are 0 or 1, where 0 is disabled and 1 is enabled. Default: 0
*.BDigitCCrm	To provide a country code digit string to which the called party number's leading digits can be compared and if matched have those digits removed from the front of the number. This modification is made before sending the call forward. Value range: NULL, or a maximum 5-digit string. Default: NULL
*.CCOrigin	To provide against the origin Trunk Group of a call the Country code digits which if needed can be prefixed on a number before sending the call forward. Values are 0 or 1, where 0 is disabled and 1 is enabled. Value range: NULL, or a maximum 5-digit string. Default: NULL

GTD NOA Override

The Generic Transparency Descriptor (GTD) Nature of Address (NOA) feature is used to specify a set of GTD fields that MGC desires to override the corresponding ISDN 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.

dat file Changes

compTypes.dat

A new component type is defined to support GTD parameters in this static file.

CompTypeID	CompTypeName	CompTypeDescription
0037	"GTD Parameter"	"GTD Parameter"

gtdParam.dat (new)

This file is created to support GTD parameter subsets. The file contains three columns: component ID, GTD Parameter String for building, and GTD override fields string.

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

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

gtdParamString = NONE | ALL | build_string

---

Note The default value of gtdParamString is NONE.

---

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

gtdOverrideFieldsString = NONE | override_string

The parameters contained in gtdParamString indicate all the GTD parameters the MGC supports for the specified NAS sigpath. The parameters contained in gtdOverrideFieldsString indicate all the GTD fields that the MGC overrides for the specified NAS sigpath.

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

ACL | ADI | APP | ATP |

BCI | BSG | BVN | CAI |

CCN | CCS | CDI | CDN |

CDT | CGL | CGN | CHI |

CHN | CIC | CID | CIN |

CMI | CNF | CNN | CNR |

COL | COR | CPC | CPN |

CRF | CSI | CSP | CTI |

CTN | CTR | DIS | ECI |

EGR | EVI | FAI | FCI |

FDC | FVN | GCI | GEA |

GED | GEN | GIC | GNO |

GRF | HOC | HTR | INI |

IRI | ISC | JUR | LON |

LPI | LSP | MCI | MCR |

MLP | MRI | NET | NMC |

NOC | NPF | NRN | NSF |

OBI | OCI | OCN | OCT |

OFI | OLI | OSI | OTN |

PBI | PCA | PCI | PCT |

PDC | PFI | PRI | PRN |

PVS | QOR | RBI | RCT |

RDC | RDS | RFI | RGN |

RMO | RNI | RNN | RNR |

SCF | SCI | SEA | SEG |

SPC | SPR | SRI | SUN |

TID | TMP | TMR | TMU |

TNS | TRR | UCI | UFC |

UID | USI | USP | UTI |

UUI | UUS | VER

---

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

---

An example of the content of gtdParam.dat:

CompTypeID	gtdParamString	overrideString
00370001	CPC,CGN,CDN,BCI,RGN,CID	CDN.noa,CGN.noa,RGN.noa
00370002	ALL	NONE
00370003	CPC,CGN,CDN	CGN.#,CGN.si
00370004	NONE	CDN.noa

properties.dat

Entries corresponding to the additional entries defined in the propSet.dat can be found in properties.dat. For example:

nassrv1.GtdCapTypeProp = t3

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 the MML interface commands. No validation is performed on the input of GTD parameters.

An MML command with TID gtdParam supports the configurable GTD parameters. For example:

  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"

The user can also define GtdCapTypeProp to be associated with a NAS sigpath. This property is used by the SC2200 as a pointer to the subset of GTD parameters that the user desires. The default value the GtdCapTypeProp is "t0", which stands for no GTD support.

The property GtdMsgFmt is associated with isdnpri sigpath. The value is string type:

c = compact (default)
v = verbose

The property CorrelationCallIDFormat is associated with isdnpri sigpath. The value is integer type:

0 = H323 (default)
1 = SIP

The property IsupTransEarlyBackwardDisabled is associated with isdnpri sigpath. The value is integer type.

0 = Enabled (default)
1 = Disabled

The property IsupTransParencyDisabled is associated with isdnpri sigpath. The value is integer type.

0 = Enabled (default)
1 = Disabled

GTD Provisioning Examples

The following is a GTD override provisioning example.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 provision session enables partial GTD support indicated by gtdcaptypeprop=t3 for the sigpath nassrv1.

Prov-sta::srcver="new",dstver="cfg-1"

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"

prov-cpy

prov-stp

For partial GTD support, the following provision session enables partial GTD support indicated by gtdcaptypeprop=t3 for the sigpath nassrv1.

The following is a GTD provisioning example disabling GTD override. The following provision session turns off GTD support for nassrv1. The value of gtdcaptypeprop is set back to default t0 for sigpath naasrv1.

Prov-sta::srcver="cfg-1",dstver="cfg-2"

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

Prov-cpy

Prov-stp

For default setting, 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.

Prov-sta::srcver="cfg-2",dstver="cfg-3"

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

Prov-cpy

Prov-stp

Time Conditional Routing

Time conditional routing allows the route lists to be selected depending upon the day of week and Holidays (special days) and a time interval. The requirement provides the means to provision a table that provides the time and day dependency to the route list selection.

Time conditional routing is invoked from pre-analysis, B-number analysis, or cause analysis stages. The result type COND_ROUTE controls this routing option. It is possible for given pass through B-Number Analysis to encounter more than one of each result type. To accommodate multiple result types, the longest match result is be taken. As a result, the last COND_ROUTE or ROUTE result encountered in B-Number Analysis is performed and any other ROUTE or COND_ROUTE results encountered are ignored.

If a COND_ROUTE result is retrieved, then Conditional Routing Analysis processing occurs during the pre-analysis, B-number analysis, or cause analysis stage before route analysis is performed to convert the COND_ROUTE into a ROUTE result.

The Route Holiday table provides the means to separately provision holidays for routing purposes. It is a two-column table (Date and Day Number) that is used to determine the holiday day value to be used for the current day.

The Conditional Routing table contains entries for each Conditional Routing block defined and resides in the routing data file. When B-Number analysis encounters a COND_ROUTE result, the result contains information for the Conditional Routing table that is the starting point of the block of entries to use. Each block is 11 entries long with the first entry as the default entry, the next seven entries are the day entries, and the final three entries are the holiday entries.

Each Conditional Routing table entry consists of time-dependent routing instructions. Any day or holiday not defined in the Conditional Routing table consists of an empty string.

The COND_ROUTE result always contains the integer CondRouteIdx and not a string identifier.

Table C-3

Field Name	Data Type	Max Length	Specific Instructions and Exceptions
CondRouteBlock	Integer		This number is a positive integer
condRouteName	String	20	This is the conditional route name

The CondRouteIdx is the value retrieved from the dialplan COND_ROUTE result type and the Dayindex is a value in range 0-10 representing respectively by the day names Default, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, Hol1, Hol2, and Hol3.

Table C-4

Field Name	Data Type	Max Length	Specific Instructions and Exceptions
CondRouteName	String		This conditional route name is up to 20 alphanumeric.
StartIndex	Integer		This number is a positive integer that points start of the condRoute block in the condRoute table.

Example for the layout of the condRouteName and condRoute properties in the routeAnalysis.dat file are as follows.

$condRouteName

# CiscoMGC:   01

#name                block

test1                1

test2                2

$condRoute

# CiscoMGC:   01

#rteid1   time1 rteid2   time2 rteid3   time3 rteid4   time4 rteid5

# block1

"21       0800  22       1800  24"

"21"

"24"

"21       0800  23       1800  24"

""

""

""

""

"23"

"22"

"22       1200 55        1800  22"       

# block2

"1"

""

""

""

""

""

""

""

""

""

""

When provisioning the conditional routing data, observe the following sequence to ensure that the data is logically associated.

1. Define the conditional routing data (in routeAnalysis.dat) using the MML commands associating the data with a naming convention to identify this data, for example condName1, condName2.

2. Define the COND_ROUTE result type to associate the result with the required "condName" entry.

MML Component Name CONDRTE

Table C-5

Parameter MML Name	Parameter Description	Parameter Values (default)
NAME	Conditional Routing name	Up to 20 Alphanumeric
DOW	Day of week	The value can be one of the following strings: DEFAULT MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY SUNDAY HOL1 HOL2 HOL3
RTEDESC	Conditional Routing descriptor	Up to 124 Alphanumeric providing time ordered options to use a particular result set (from the dialplan result table). Format is: setName1 setTime1 ... SetName_n SetTimeChange_n

For all days of the week the user has to enter as the first value in the set a conditional route name. This can be followed optionally by up to four pairs of time change and conditional route names. The time changes can be configure in the range 0015 to 2345 and must be in 15 minute intervals. A check is performed to ensure the times are added only in ascending order.

The following MML commands are used to add, edit, delete and retrieve from the Conditional Routing table.

Add an entry to the table (and create the table if it does not exist):

PROV-ADD:CONDRTE:NAME="condName1",DOW="DEFAULT",RTEDESC="set21  0800  set22 1800 set 24"

Edit an already existing entry in the table:

PROV-ED:CONDRTE:NAME="condName1",DOW="DEFAULT",RTEDESC="set21  0800  set22 1830 set 24"

Delete an entry in the table:

PROV-DLT:CONDRTE:NAME="condName1",DOW="DEFAULT"

Delete the whole conditional route in the table:

PROV-DLT:CONDRTE:NAME="condName1"

Retrieve a specific entry in the table:

PROV-RTRV:CONDRTE:NAME="condName1",DOW="DEFAULT"

Retrieve the whole conditional route in the table:

PROV-RTRV:CONDRTE:NAME="condName1"

Retrieve all entries in the table:

PROV-RTRV:CONDRTE:"all"

The MML Configuration of Intermediate COND_ROUTE results in the result table complies with current practice and an example is given below:

NUMAN-ADD:RESULTTABLE:CUSTGRPID="T002",NAME="result39",RESULTTYPE="COND_ROUTE",DW1="condNa
me1",SETNAME="condsetName1"

Addition of the routeHoliday table to the Dial Plan file

The routeHoliday table is added to the Dial Plan (<customer group ID>.dialplan file) which contains all the valid holidays for a given customer.

Each row in the routeHoliday table consists of two values: a date (in the form yyyymmdd) as a string and a dayIndex as an integer of the set 8, 9, and 10. The dayIndex values correspond with the holiday values HOL1, HOL2, and HOL3 respectively.

Table C-6

Field Name	Data Type	Max Length	Specific Instructions and Exceptions
HolidayDate	String	8	The date is entered in the format yy.mm.dd. Valid values: - yyyy = 2000-9999 - mm = 01-12 - dd = 01-31
HolidayDay	Integer		This number is a positive integer indicates the holiday day. Valid values: 8 (Hol1), 9 (Hol2), 10 (Hol3)

Example for the layout of the routeHoliday section in the <CustomerGroupID>.dialplan file.

$routeHoliday

# Customer: T002

# Date Holiday_Index

20011225 8

20010101 8

20010704 8

20010903 10

Table C-7

Component MML Name	Parameter MML Name	Parameter Description	Parameter Values (default)
RTEHOLIDAY	DATE	The date of the holiday	Format for the date is: yy.mm.dd
	HDAY	Holiday day	The value can be one of the following strings: HOL1 HOL2 HOL3

The following MML commands are used to add, edit, delete, and retrieve from the Route Holiday table.

Add a Holiday entry:

NUMAN-ADD:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.08.12",HDAY="HOL2"

Edit an the holiday day in an already existing entry in the table:

NUMAN-ED:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.08.12",HDAY=HOL1

Delete an entry in the table:

NUMAN-DLT:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.08.12"

Retrieve a specific entry in the table:

NUMAN-RTRV:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.08.12"

Retrieve all entries in the table:

NUMAN-RTRV:RTEHOLIDAY:CUSTGRPID="T002","all"

Provisioning example for Conditional Routing

Add entries to route holiday table:

NUMAN-ADD:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.12.25",HDAY="HOL1"

NUMAN-ADD:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.01.01",HDAY="HOL1"

NUMAN-ADD:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.07.04",HDAY="HOL2"

NUMAN-ADD:RTEHOLIDAY:CUSTGRPID="T002",DATE="2001.09.03",HDAY="HOL3"

Conditional Routing Processing actions derived from the above MML commands:

The conditional routing will use the hol1 day of the week for Christmas day and New Years day. For Independence Day the conditional routing will use the hol2 day of the week. And for Labor Day the conditional routing will use the hol3 day of the week.

Add a conditional route:

PROV-ADD:CONDRTE:NAME="condName20",DOW="DEFAULT",RTEDESC="set22"

PROV-ED:CONDRTE:NAME="condName20",DOW="MONDAY",RTEDESC="set21  0800  set22 1800 set 24"

PROV-ED:CONDRTE:NAME="condName20",DOW="TUESDAY",RTEDESC="set21  0800  set22 1800 set 24"

PROV-ED:CONDRTE:NAME="condName20",DOW="WEDNESDAY",RTEDESC="set21 0800  set22 1800 set24"

PROV-ED:CONDRTE:NAME="condName20",DOW="HOL1",RTEDESC="set23"

PROV-ED:CONDRTE:NAME="condName20",DOW="HOL2",RTEDESC="set22"

PROV-ED:CONDRTE:NAME="condName20",DOW="HOL3",RTEDESC="set22  1200 set55 1800 set22"

The following MML commands show how to configure the COND_ROUTE results making the association with the data in the Conditional Routing table previously defined.

NUMAN-ADD:RESULTTABLE:CUSTGRPID="T002",NAME="result39",RESULTTYPE="COND_ROUTE",DW1=" 
condName20",SETNAME="condsetName"

Conditional Routing Processing actions derived from the above MML commands:

On Monday, Tuesday, and Wednesday:

From 0000-0800, the Routing option is result set "set21" which provides RouteList21 as the entry point into Routing analysis.

From 0801-1800, the Routing option is result set "set22" which provides Routelist22 as the entry point for Routing analysis.

From 1801-2359, the Routing option is result set "set24" which provides RouteList24 as the entry point into Routing analysis.

On a Holiday of type "HOL1"

From 0000-2359, the Routing option is "set23" which provides RouteList23 as the entry point into Routing analysis.

On a Holiday of type "HOL2"

From 0000-2359, the Routing option is "set22" which provides RouteList22 as the entry point into Routing analysis.

On a Holiday of type "HOL3"

From 0000-1200, the Routing option is result set "set22" which provides RouteList22 as the entry point into Routing analysis.

From 1201-1800, the Routing option is result set "set55" which provides Routelist55 as the entry point for Routing analysis.

From 1801-235, 9 the Routing option is result set "set22" which provides RouteList22 as the entry point into Routing analysis.

On a Default case

This means the Routing for any undefined Days in this case Thursday, Friday, Saturday, and Sunday.

From 0000 - 0800, the Routing option is result set "set22" which provides Routelist22 as the entry point for Routing analysis.

From 0801-2359, the Routing option is result set "set55" which provides Routelist55 as the entry point for Routing analysis.

Bug Fixes

Table C-8 Caveats

DDTS Number	Description	Resolution
CSCdv54082	With netind=0 configured, SS7 controller still sends out netind=2.	When creating or editing a linkset, be sure the network indicator is the same for the OPC and the APC connected to the linkset. If the APC is connected to an SS7 route, the network indicator cannot be changed. If the OPC is connected to an SS7 route, the network indicator cannot be changed.
CSCdv23570	Standby system does not come up.
CSCds22843	Unable to override the protocol family-specific default settings	In Release 9.2(1)T, use the prov-ed command to override the protocol family default property settings.

Software Release 9.4(1) Enhancements

The following sections contain information regarding enhancements and caveats supported in the software Release 9.4(1).

INSERVICE

The Intelligent Network service component type represents the IN service information and remote subsystem number. Its MML name is as follows:

•MML Name—INSERVICE

The Intelligent Network service component structure is shown in Table C-10.

Table C-9 Intelligent Service Component Structure 

Parameter MML Name	Parameter Description	Parameter Values (Default)
NAME	Intelligent Network service name	Up to 20 alphanumeric characters.
SERVICEKEY	Service key	0-65535 (0). Service key value specifying the feature that caused the IN service trigger table to be accessed (ITU or ETSI INAP only).
GTORSSN	Global title (GT) or Subsystem Number (SSN)	Global title or Subsystem Number. The user provisions the string value. For example: ROUTEBYGT. 0 = ROUTEBYGT (Route by global title.) 1 = ROUTEBYSSN (Route by subsystem number.)
GTFORMAT	Global title format	Global title format. 0-4. How to use Global Title; SCCP Called Party Address address indicator field. Provision the string value. For example, NOGT. 0 = NOGT (Use no global title. This is selected when routing by SSN.) 1 = GTTTNBRENC (Use global title translation type numbering scheme encoding scheme.) 2 = GTTT (Use global title translation type.) 3 = GTONLY (Use global title only.) 4 = UNKNOWN (Unknown.)
MSNAME	Message Sending Name	Up to 20 alphanumeric characters.

Intelligent Network Service Creating Examples

Example of creating intelligent network service entries:

prov-add:inservice:name="serviceone",servicekey=37,gtorssn="routebygt",gtformat="gttt", 
msname="generic_lnp"

prov-add:inservice:name="servicetwo",servicekey=0,gtorssn="routebyssn",gtformat="nogt"

Intelligent Network Service Editing Example

To add a entry for intelligent network service one:

prov-ed:inservice:name="serviceone",servicekey=255

Intelligent Network Service Deleting Example

To delete the intelligent network service:

prov-dlt:inservice:name="serviceone"

Intelligent Network Service Retrieving Examples

To retrieve all of the intelligent network services:

prov-rtrv:inservice:"all"

To retrieve the intelligent network service one:

prov-rtrv:inservice:name="serviceone"

SS7 Subsystem

The SS7 subsystem component type represents an SS7 subsystem. It is used for specifying mated STPs and to provide LNP support through a SCP. Its MML name is as follows:

•MML Name—SS7SUBSYS

The SS7 subsystem component structure is shown in Table C-10.

Table C-10 SS7 Subsystem Component Structure 

Parameter MML Name	Parameter Description	Parameter Values (Default)
SVC	MML name of Adjacent point code or TCAP/IP service	MML name of a previously defined adjacent point code, or MML name of a previously defined TCAP/IP service.
PROTO	Protocol family	SS7-ANSI or SS7-ITU when creating an AIN subsystem.
MATEDAPC	Adjacent point code of the mated STP	MML name of a previously defined adjacent point code used when mating STPs. Not used when creating an AIN subsystem.
PRI	Priority	Integer greater than 0; (1). Not used when mating STP pairs.
LOCALSSN	Subsystem number	Integer from 2 through 254;(0) Can be set to non-zero only for SS7-ANSI, SS7-ETSI, or SS7-ITU. If set to 0, the subsystem is used for mating two STPs. Not allowed if ROUTING_KEY_ID is specified.
STPSCPIND	STP/SCP index used for IN triggers	Integer greater than 0; (0). Not used when mating STP pairs.
TRANSPROTO	Transport protocol	SCCP or TCPIP. If SVC is an APC, SCCP should be used. If SVC is a TCAP over IP service then TCPIP should be used; (SCCP). Not used when mating STP pairs.
OPC	Originating point code MML name of the mated STP	MML name of a previously defined originating point code. Either OPC or ROUTING_KEY_ID can be specified.
ROUTING_KEY_ID	Routing key ID MML name	MML name of a previously defined routing key ID. Not allowed if OPC is specified.
REMOTESSN	Remote subsystem number	Integer from 2 through 254;(0). Can be set to non-zero only for SS7-ANSI, SS7-ETSI, or SS7-ITU. If set to 0, the subsystem is used for mating two STPs. Use LOCALSSN if not specified.

OD32DigitSupport Property

In software Release 9.4(1), the sigpath and trunk group property OD32DigitSupport was added to allow 32 digits and overdecadic digits (A through F) support for the ANSI, Q.761, and Q.767 protocol variants. The default value (1) enables 32 digit and overdecadic support. Setting this value to 0 disables 32 digits and overdecadic support.

The following section describes the implementation for the OD32DigitSupport property used in the Cisco MGC to add the following functionality:

•Allows as many as 32 digits for parameters containing address signal (digit) fields.

–Applies to the ANSI and ITU protocols of the ISUP protocol variants.

–The target IDs (TIDs)AWHITE, BWHITE, ABLACK, BBLACK, TERMTBL, ANUMDPSEL, and ACHGORIGIN support the Calling Line Identity (CLI) up to 20 digits only. Also, the TID PORTTBL supports the called number and routing number up to 20 digits.

---

Note For the Called Party Number (CDPN) parameter, the existing global property TmaxDigits also supports 32 so up to 32 digits can be sent out by the Cisco MGC as this property determines how many digits are sent out. Thus, if the terminating side protocol variant maximum number of digits is 32, only as many digits are included in the CDPN parameter as this property allows.

---

---

Note Note that handling of cause code 14 applies to the "ITU" protocol family and only consists of adding this cause code in the cause mapping table of the protocol files, as the LNP functionality currently exists in the PGW2200 software.

---

The default value of 1 (enabled) for this property allows the overdecadic and 32 digits support, while it is possible to support the 20-digit functionality by setting the property to 0 (disabled) on a sigpath or trunk group basis.

The 32digits support is applied to all ANSI protocol variants and all ITU protocol variants that conform to the Q.761 and Q.767 recommendations. Note that this functionality does not apply to the protocol variants of the Q.721 since there exists a 4-bit field for the number (length) of the address signals contained in each parameter, thus making it impossible to have any parameter with more than 16 digits.

The overdecadic digits supportis applied to all ANSI protocol variants and all ITU protocol variants that conform to the Q.721, Q.761, and Q.767 recommendations.

Table C-11 shows the parameters, in each protocol family, that are affected by the overdecadic and 32 digits support.

Table C-11 Parameters affected by Overdecadic and 32 Digit Support

Protocol Family	Parameters	32 Digits Support	Overdecadic Digits Support
ANSI
	Called Party Number	Yes	Yes
	Calling Party Number	Yes	Yes
	Carrier Identification	No (3 or 4 digits)	No (see Note1)
	Charge Number	Yes	Yes
	Generic Address	Yes	Yes
	Jurisdiction Information	No (6 digits)	No
	Original Called Number	Yes	Yes
	Outgoing Trunk Group Number	No (6 digits)	No
	Redirecting Number	Yes	Yes
	Redirection Number	Yes	Yes
	Transit Network Selection	No (3 or 4 digits)	No (see Note1)
Q.721
	Additional Identity* (French ISUP)	No (see Note2)	Yes
	Called Party Number	No (see Note2)	Yes
	Calling Line Identity (Calling Party Number)	No (see Note2)	Yes
	Original Called Number	No (see Note2)	Yes
	Subsequent Address Message (Subsequent Number)	No (see Note2)	Yes
	Subsequent Address Message with One signal	No (1 digit)	Yes
	Transit Exchange Identity	No (see Note2)	No
Q.761
	Called Party Number	Yes	Yes
	Calling Party Number	Yes	Yes
	Carrier Selection* (German ISUP)	No (3 or 4 digits)	Yes
	Charge Area Information (Japanese ISUP)	Yes	Yes
	Connected Number	Yes	Yes
	Contract Number* (Japanese ISUP)	Yes	Yes
	Generic Number	Yes	Yes
	Last Diverting Line Identity* (UK ISUP)	Yes	Yes
	Location Number	Yes	Yes
	Original Called Number	Yes	Yes
	Presentation Number* (UK ISUP)	Yes	Yes
	Redirecting Number	Yes	Yes
	Redirection Number	Yes	Yes
	Subsequent Number	Yes	Yes
	Transit Network Selection	No (3 or 4 digits)	Yes
Q.767
	Called Party Number	Yes	Yes
	Calling Party Number	Yes	Yes
	Connected Number	Yes	Yes
	Generic Number* (Italian Interconnect and Russian ISUPs)	Yes	Yes
	Location Number* (Colombia, Russian, Spanish and Swedish ISUPs)	Yes	Yes
	Original Called Number* (Colombia, Indonesia, Mexican, Russian, Spanish and Swedish ISUPs)	Yes	Yes
	Redirecting Number* (Colombia, Indonesia, Mexican, Russian, Spanish and Swedish ISUPs)	Yes	Yes
	Redirection Number* (Colombia, Indonesia, Mexican, Russian, Spanish and Swedish ISUPs)	Yes	Yes
	Subsequent Number	Yes	Yes
	Transit Network Selection* (Colombia and Mexican ISUPs)	No (3 or 4 digits)	Yes

Parameters marked with an (*), are specific to only the protocol variants that appear in parenthesis meaning that the base variant of the protocol family does not support the parameter.

Note1: The overdecadic support for these parameters only applies when the Cisco MGC (configured for Signaling Mode) receives an SS7 call and terminates to the Network Access Server (NAS) gateway or vice versa. In other words, an SS7-to-SS7 call does not support overdecadic digits.

Note2: There is a 4-bit wide length field associated with the number of address signals (digits) within the parameter bit string, making 16 digits the maximum allowed.

The Japanese ISUP variants consist of NTT, TOKYO, JAPAN, and JAPAN_JT protocol variants.