The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document provides details for the configuration of the Generic Transparency Descriptor (GTD) ISUP Transparency. It also explains the configuration and troubleshooting items for the transparent transport mechanism for the Cisco PGW 2200 to pass ISUP information.
Readers of this document should have knowledge of these topics:
The information in this document is based on these software and hardware versions:
Cisco PGW 2200 Software Releases 9.3(2) and 9.4(1)
Cisco IOS® Software Release 12.3 or 12.3T
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
ISUP Transparency provides the capability to transfer ISUP messages and information elements from an ingress Cisco PGW 2200 (SG1) across an IP network to an egress Cisco PGW 2200 (SG2) where the ISUP messages are re-packaged and sent out to the PSTN/SS7 network. This feature is important because it enables the transport of calls from the PSTN network through an IP network back out to a PSTN network without any loss of signaling information. ISUP Transparency is achieved with the use of Cisco's GTD mechanism. GTD provides a means to specify messages of various protocols used in the PSTN network in plain text format. This is so they can be easily understood by the network elements within the IP network or lie on the boundary between PSTN and IP.
Note: If an SS7 overlap Subsequent Address Message (SAM) is used on SG1 (Figure 1), the NI2+ is limited to the use of only Enbloc and not Overlap sending. This is due to NI2+ specifications. This means that if the SS7 link on SS7 receives an SS7 Initial Address Message (IAM) followed by SAM, the terminated SG2 forwards the information out on the SS7 link as Enbloc, or one IAM message.
Figure 1
NI2+ is part of Bell_1268, Telcordia Technologies Technical Reference TR-NWT-001268 Issue 1, December 1991. On page 23/434, this technical reference explains that the procedures and states associated with Overlap Sending are not supported. Only Enbloc is supported for this solution. GTD fills in the gaps to carry data, but does not override any of the interworking implementation. If there are issues where the interworking mapping differs from GTD carried information, the native protocol should supercede GTD.
Complete these steps.
Create the GTD information on the PGW 2200.
demask mml>prov-sta::srcver="active",dstver="gtd2" MGC-01 - Media Gateway Controller 2004-05-17 12:16:08.470 MET M COMPLD "PROV-STA" ; demask mml>prov-add:gtdparam:name="ISUP",gtdparamstring="All" MGC-01 - Media Gateway Controller 2004-05-17 12:16:18.438 MET M COMPLD "gtdparam" ;
Note: If you enable GTD on your system, thses ISUP parameter codes are always allowed, regardless of your individual selections:
Event Information (EVI)
Known Field Compatibility Information (FDC)
Global Call Identification (GCI)
Message Compatibility Information (MCI)
Parameter Compatibility Information (PCI)
Protocol Name (PRN)
For example, to modify a GTD parameter set to support all of the GTD parameters, enter this command:
mml>prov-add:gtdparam:name="ISUP",gtdparamstring="ALL"
In another example, enter this command to modify a GTD parameter set to support select GTD parameters:
mml>prov-ed:gtdparam:name="ISUP", gtdparamstring="BCI, CPC, CGN, CIC, CPN, MCR" demask mml> prov-add:sigsvcprop:name="signas1",gtdcaptypeprop="ISUP" MGC-01 - Media Gateway Controller 2004-05-17 12:16:31.402 MET M COMPLD "sigsvcprop: WARNING: Restart may be needed based on the property(s) added/modified. Refer to MGC Provisioning Guide." ; demask mml> prov-add:sigsvcprop:name="ss7path",IsupTransparencyDisabled="0" MGC-01 - Media Gateway Controller 2004-05-28 11:32:14.557 MET M COMPLD "sigsvcprop: WARNING: Restart may be needed based on the property(s) added/modified. Refer to MGC Provisioning Guide." ; demask mml> prov-cpy MGC-01 - Media Gateway Controller 2004-05-17 12:16:52.642 MET M COMPLD "PROV-CPY" ;demask mml>
You need to restart if you changed/modified any property values in order for the changes to take effect. See Table 4-4 in the MML Basics documentation for additional information.
Verify the GTD configuration on the PGW 2200.
Note: The items in bold type are important items associated with GTD in the MML prov-rtrv:gtdparam:name="isup" command.
Figure 2: FastConnect Property Informationdemask mml> prov-rtrv:gtdparam:name="isup" MGC-01 - Media Gateway Controller 2004-05-17 12:17:30.914 MET M RTRV "session=gtd2:gtdparam" /* NAME = isupDESC = notSet GTDPARAMSTRING = ALL OVERRIDESTRING = NONE */ ; !--- Check the profile to the Network Access Server (NAS) !--- Redundant Link Manager (RLM) group (NASPATH). demask mml> prov-rtrv:sigsvcprop:name="signas1" MGC-01 - Media Gateway Controller 2004-05-17 12:21:30.549 MET M RTRV "session=gtd2:sigsvcprop" /* ADigitCCPrefix = 0 AInternationalPrefix = NULL ANationalPrefix = NULL BcInitState = OOS BDigitCCPrefix = 0 BDigitCCrm = NULL BInternationalPrefix = NULL BNationalPrefix = NULL BothwayWorking = 1 CCOrigin = NULL CGBA2 = 0 CLIPEss = 0 CompressionType = 1 CorrelationCallIDFormat = 0 CotInTone = 2010 CotOutTone = 2010 <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output> CotPercentage = 0 ExtCOT = Loop FastConnect = 0
Figure 3: Example for FastConnect = 0
FastConnect - The default value that locally maps significant 'call-proceeding' to the Address Complete Message (ACM). This local mapping prevents egress ACM from being transparently mapped on the ingress side. Embedded GTD in egress ACM arrives later when ingress ACM has already been sent
FastConnect = 1 - This prevents locally generated NI2+ 'call-proceeding' messages (without GTD information) from triggering SS7 ACM. Ingress ACM is triggered by Egress ACM and holds all GTD information. This is the recommended value when GTD is enabled. See Cisco bug ID CSCdx23349 (registered customers only) .
ForwardCLIinIAM = 1 ForwardSegmentedNEED = 1 GLARE = 0 GRA2 = 0 GtdCapTypeProp = ISUP GtdMsgFmt = c !--- GtdMsgFmt can be ‘c’ (compact) or ‘v’ (verbose).
IsupTransEarlyACMEnable = 0 See Cisco bug ID CSCea87770 (registered customers only) . This adds the NASPATH property IsupTransEarlyACMEnable (per Q.699 and H.246) where ACM does not map to anything (no Progress or Alerting). In this case, ISUP Transparency is lost.
This happens when these paramaters are set in the ACM's BCI:
Called Party Status = No Indication
ISUP Indicator = ISUP all the way
ISDN Access Indicator = Terminating access ISDN
No InBand Info available
For this situation a Progress message is sent with ProgressIndicator=9. This is across NI2c when no message is normally mapped. PI=9 is an "Empty" progress message; no progress information is actually relayed. It is an empty message that enables you to relay the GTD information to take care of ISUP transparency, in an instance where H.246 normally has no message mapped.
Progress with PI=9 is sent under these conditions for early ACM:
IsupTransEarlyACMEnable Flag is set to 1 for this sigPath.
The remote GTD protocol is an ISUP protocol.
The BCI parameters do not map to a progress/alerting message per Q.699/H.246.
This is made configurable with the addition of a new NASPATH property:
IsupTransEarlyACMEnable (default = 0)
It is set to 1 to enable this empty progress message to be sent on early ACM.
PI=9 on the IOS gateway is associated with Cisco bug ID CSCea86191 (registered customers only) . If Progress validation is not turned on in the gateway, IOS does not check PI values. This fix is available in Cisco IOS Software Releases 12.3 and 12.3T.
IsupTransEarlyBackwardDisabled = 1 - For information on this parameter, refer to Support of SIP-T and SIP-GTD Feature Overview.
lapdDropErr = true lapdKval = 7 lapdN200 = 6l apdN201 = 260l apdT200 = 10l apdT203 = 500 NatureOfAddrHandling = 0 Normalization = 0 OMaxDigits = 24 <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output> OMinDigits = 0 OOverlap = 0 OverlapDigitTime = 6 PostConnectToneDuration = 0 PostConnectToneValue = 0 PropagateSvcMsgBlock = true RedirectingNbrMap = 0 RedirMax = 5 ReleaseMode = Async resumeAckTimer = 1 RoutePref = 0 rudpAck = enable rudpKeepAlives = enable rudpNumRetx = 2 rudpRetxTimer = 6 rudpSdm = enable rudpWindowSz = 32 sessionPauseTimer = 8 spanId = ffff SuppressCLIDigits = 0 <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output> T309Time = 90000 T310Time = 30000 TMaxDigits = 24 TMinDigits = 0 TOverlap = 0 VOIPPrefix = 0 */ ; demask mml> !--- Check the ISUP Transparency on the SS7 link (SS7PATH). demask mml>prov-rtrv:sigsvcprop:name="ss7path" MGC-01 - Media Gateway Controller 2004-05-28 09:55:54.186 MET M RTRV "session=gtd2:sigsvcprop" /* <snip> GRA2 = 0 GRSEnabled = false IsupTransparencyDisabled = 1 !--- ISUP Transparency Disabled – This permits !--- the disabling of the ISUP Transparency feature. !--- Maps to trunk group property IsupTransparencyDisabled. !--- Values are 0 (ISUP Transparency is enabled), 1 !--- (ISUP Transparency is disabled). LocationNumber = 0 <snip> MaxACL = 3 */ ; demask mml>
Note: The GTD parameter in the profile cannot be changed when linked to NAS. This is the command to remove the NAS to GTD link.
demask mml>prov-sta::srcver="active",dstver="gtdremove" MGC-01 - Media Gateway Controller 2004-05-28 10:15:28.190 MET M COMPLD "PROV-STA" ; demask mml>prov-dlt:sigsvcprop:name="signas1","gtdcaptypeprop" MGC-01 - Media Gateway Controller 2004-05-28 10:17:37.746 MET M COMPLD "sigsvcprop" ; demask mml>prov-cpy MGC-01 - Media Gateway Controller 2004-05-28 10:18:33.144 MET M COMPLD "PROV-CPY" ; demask mml> demask mml>prov-rtrv:sigsvcprop:name="signas1" MGC-01 - Media Gateway Controller 2004-05-28 10:20:25.961 MET M RTRV "session=gtdremove:sigsvcprop" /*
This informs you that the GTD session is removed.
On the IOS gateway, set the global command:
voice service voip signaling forward unconditional
Under the serial interface you can turn on/off the command isdn gtd .
Verify the GTD configuration on the gateway.
debug isdn q931 debug voice ccapi inout debug voip rawmsg debug gtd detail debug gtd error debug gts events debug gtd parser
Note: If you run into any problem, insert this information in the Service Request you open with Cisco Technical Support.
If the Ingress Cisco gateway is configured with an image which supports GTD, the Ingress gateway builds GTD information and inserts it in the raw message. It then passes to Egress. The ISDN stack at the Egress gateway receives this raw message from VoIP and sends out the FACILITY message in SETUP. If you do not want this information, turn it off with the CLI signaling forward rawmsg in the corresponding dial-peer (or turn on signaling forward rawmsg under voice service voip). The command no isdn gtd stops the ISDN stack from building GTD.
Collect a PGW 2200 MDL trace if you run into a problem.Use this procedure to collect an MDL trace via the MML command sta-sc-trc (Start Trace).
Identify the Originating SS7 SigPath Number or the Originating TrunkGroup Number on which calls are placed.
Rotate the log: run script under /opt/CiscoMGC/bin/log_rotate.sh.
Enter this command to start the MDL trace:
mml>sta-sc-trc:<ss7sigPath name | orig trunkgroup number>, CONFIRM
Perform a test (make a call).
Enter this command to stop the MDL trace:
mml>stp-sc-trc:all
Identify the Call Id (C:) of the bad call.
If this test call is made in a test environment, only one CALL_ID is displayed.
Note: These files can contain tracings from many calls that are all mixed up together if the capture is taken on a production Cisco PGW 2200. Each tracing record in the file has a specific record type and records information of a type that relates to that record. Each record has a Call ID that relates it to a specific call.
Convert the MDL trace into a readable format:
get_trc.sh <trace file name>
Type Call Id at the prompt to jump to the MDL trace of the bad call.
Choose option C to convert the trace file.
Note: .btr files are binary trace files that are produced by the Cisco PGW 2200 tracer function. The main part of the file name is given in the Cisco PGW 2200 MML command sta-sc-trc. The PGW 2200 always adds a .btr extension to these files. With the use of the C option, the file is converted into a text format and the extension has .trc files that are text trace files. They contain detailed line by line trace information from the MDO code that was run in the simulation replay that produced the file. Therefore, they contain MDL traces.
The trace file is in /opt/CiscoMGC/var/trace.
Collect the platform.log file under /opt/CiscoMGC/var/log.
In some cases the Cisco Technical Support engineer can ask for other platform.log information related to the problem this is reported during the handling of the Technical Support case.