|
|
October 12, 2001
These release notes describe the features and caveats for the Cisco Media Gateway Controller (MGC) software Release 7.4(12).
 |
Note The Cisco MGC software was formerly called the Cisco Telephony Controller software. Some documentation may reference this older name. |
The Cisco MGC software is part of several solutions that perform call processing, protocol conversion, and call switching and routing functions. It runs on a Sun Microsystems host server. The combination of software and Sun Microsystems host server that works with all supported solutions is called the Cisco MGC host. The Cisco MGC host interconnects Cisco media gateways (MGWs) to a circuit-switched time-division multiplexing (TDM) network, which offloads the signaling to an out-of-band network so that available bandwidth increases. Cisco Signaling Link Terminals (SLTs) are used to terminate Signaling System 7 (SS7) and pass signaling information to the MGC host. The combination of the Active Cisco MGC host, its paired Standby MGC host, and the associated LAN switches and Cisco SLTs are referred to as the Cisco MGC Node. This release of the software supports the following solutions:
The following optional components may be included with any of the above solutions:
The Cisco MGC is available in several continuous-service configurations, as well as simplex configurations. Supported platforms include:
|
Note The Cisco SS7 PRI Gateway Solution is supported only on the Sun Netra t 1400 or Sun Netra t 1405 platforms in production environments. |
|
Note The Sun Enterprise 450 is no longer orderable; support is provided for existing installations only. |
The following software is required to run the Cisco MGC software on the Sun Enterprise 450, Sun Netra t 112x, and Sun Netra t 140x platforms:
|
Note Network Time Protocol (NTP) software is installed with Sun Solaris. Be sure to configure your Cisco MGCs to use NTP or the equivalent time synchronization software. |
Two gigabytes of swap space is required for the Cisco MGC software. The Swap file is created during Solaris installation. Setting swap space at installation of the Sun OS is recommended; however, swap space can be changed at a later date by adding a swap file or repartitioning the swap space using the Solaris format menu (for example, reassigning how many cylinders are in each partition). The amount of swap space needed depends on the amount of traffic. As traffic increases, you should use the top command in UNIX to see how much swap space is being used and determine if more is needed.
Table 1 shows the host minimum hardware requirements for the server.
 |
Caution Before using the minimum hardware configuration, consult with your Cisco representative to determine the hardware that will give you the best results based on your network configuration, proposed traffic, and desired processing power. In particular, B-number analysis or screening, long call hold times, and service control point (SCP) queries might require additional hardware resources. |
|
Note The Cisco SS7 PRI Gateway Solution is supported only on the Sun Netra t 1400 or Sun Netra t 1405 platforms in production environments. |
| Component | Sun Netra t 100 | Sun Netra t 1120/1125 | Sun Netra t 1400/1405 | Sun E4501 |
|---|---|---|---|---|
Processor | One 440-MHz | Two 440-MHz | Two 440-MHz2 | Two 300-MHz |
Disk drive3 | Two 18-GB | One 9-GB | One 9-GB | One 9-GB |
CD-ROM drive | 1 | 1 | 1 | 1 |
DAT 3-Drive | Optional | Optional | Optional | Optional |
RAM | 1 GB | 2 GB | 1 GB4 | 1 GB5 |
Table 2 shows the signaling and Ethernet interface options.
|
Note For the Cisco SS7 PRI Gateway Solution, we recommend that you have three Ethernet interfaces: one for management and two for the control network. |
| Interface Options | Sun Netra t 1120/1125 | Sun Netra t 1400/1405 | Sun E4501 |
|---|---|---|---|
ITK E1/T1 card | Supported | Not supported | Supported |
PTI V.35 card | Supported | Not supported | Supported |
Sun Ethernet 1-port card | Required | Required | Required |
Cisco SLT | Supported | Supported | Supported |
| 1Supported for existing installations only; no longer orderable. |
|
Note We recommend that you use the Cisco SLT to terminate signaling. ITK T1/E1 and PTI V.35 cards are no longer orderable. |
Table 3 shows the ancillary hardware requirements. In addition to the items listed there, your solution might use the following:
| Component | Sun Netra t 1120/1125 | Sun Netra t 1400/1405 | Sun E4501 |
|---|---|---|---|
Dataprobe ARU | Supported Note Not recommended; you should use the built-in alarm card and software.
| Not supported | Supported; not required if alarm functions are not necessary |
Dataprobe A/B switch | Required with use of ITK T1/E1 or PTI V.35 card2 | Not supported | Required with use of ITK T1/E1 or PTI V.35 card2 |
Asynch extension | Optional for simplex configurations; required with use of Dataprobe A/B switch | Not supported | Optional for simplex configurations; required with use of Dataprobe A/B switch |
| 1Supported for existing installations only; no longer orderable. 2Call preservation upon switchover is not supported with the A/B switch. |
The Cisco SS7 PRI Gateway Solution requires the following components:
|
Note Two BSCs are required for redundancy. |
See the Cisco SS7 PRI Gateway Solution Media Gateway Guide for more information on setting up your Cisco MGX 8260.
For Cisco IOS memory requirements, see the Cisco IOS release notes listed in Table 1.
| NAS | Release Notes |
|---|---|
Cisco AS52001 | http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5200/ios52/index.htm Note Cisco AS5200 modem boards require at least 16 MB of RAM and 8 MB Flash memory per board. |
Cisco AS5300 | http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/iosrn/index.htm |
Cisco AS58002 | http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5800/58_iosrn/index.htm Note AS5800 modem boards require at least 64 MB of memory per board. The part number for the correct modem board is MEM=200/NPE-64MB=. |
|
Note The memory requirement for the NAS is 128Mb DRAM. This memory requirement refers to the AS5300 and AS5800 for all solutions. |
Table 4, Table 5, Table 6, and Table 7 show the software requirements for each solution's components. Some components are optional.
|
Note For more information about Cisco IOS software, see the Cisco IOS release notes for your platform at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/relnote/index.htm |
|
Note For more information about portware and IOS software releases, see the compatibility matrixes at the
following URL: http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/mod_info/cm/ mca12prt.htm |
| Component | Required Software Release | Required Firmware (If Applicable) |
|---|---|---|
Host |
| N/A |
Cisco SLT | Cisco IOS software Release 12.1(3)T | N/A |
Cisco MGX8260 | 1.1.4 | N/A |
Cisco MGC Node Manager (CMNM) | 15 | N/A |
Voice Service Provisioning Tool | 1.5 | N/A |
| Component | Required Software Release | Required Firmware (If Applicable) |
|---|---|---|
Host |
| N/A |
Cisco SLT | Cisco IOS software Release 12.1(3)T | N/A |
Cisco AS52001 | Cisco IOS software Release 12.1(5)T | Version 2.7.1.0 |
Cisco AS5300 | Cisco IOS software Release 12.1(5)T | Version 2.7.1.0 |
Cisco AS58002 | Cisco IOS software Release 12.1(5)T | Version 2.7.1.0 |
| Component | Required Software Release | Required Firmware (If Applicable) |
|---|---|---|
Host |
| N/A |
Cisco SLT | Cisco IOS software Release 12.1(3)T | N/A |
Cisco AS5300 | Cisco IOS software Release 12.1(3A)XI5 VCWare 7.16 | Version 6.08 |
| Component | Required Software Release | Required Firmware (If Applicable) |
|---|---|---|
Host |
| N/A |
Cisco SLT | Cisco IOS software Release 12.1(3)T | N/A |
Cisco MGX8850/VISM | 1.1.32 | N/A |
VISM | 2.0(1) | N/A |
Cisco MGC Node Manager (CMNM) | 1.0 | N/A |
Voice Service Provisioning Tool | 1.1 or 1.5 | N/A |
Cisco AS5300 | Cisco IOS software Release 12.1(3A)XI2 | Version 6.08 |
Your solution may use one or more local-area network (LAN) switches from the Cisco Catalyst Switch family with the Catalyst software, Release 12.0(3x)W5(9), to connect the Cisco MGC hosts to the MGWs or to the Cisco SLTs.
|
Note User documentation refers to the Cisco Catalyst 5500 Switch family (NEBS compliant). The Cisco Catalyst 2900 XL is another NEBS-compliant LAN switch that may be used for a small configuration, but current MGC user documentation does not address the Cisco Catalyst 2900 XL. Refer to the Cisco Catalyst 2900 XL documentation for information about this switch. |
|
Note A LAN switch is not provided with the Cisco MGC. |
Table 8 lists the features supported in Release 7.4(12) of the Cisco MGC software.
| Feature | Purpose |
|---|---|
Provides long-distance service through both indirect and direct access | Replaces the need for traditional TDM equipment. |
Supports domestic and international dialing plans | Provides scalable and flexible service. |
Supports Calling Party Number (ANI/CLI) authorization | Adds security, prevents fraudulent use of the network. |
Supports toll-free number support through the service control point (SCP) | Allows callers to use the free phone and premium services across the Tandem/Transit network. |
Supports North American Service Provider local number portability | Allows subscribers to retain their directory number between service providers. |
Provides network announcements via a PRI-based announcement server | Advises callers about network status when their calls are impacted. |
Has a centralized element manager | Provides a method to configure the network. |
ISUP PSTN interconnect with full COT support | Provides verification of the voice path. |
Supports ISDN direct-access lines | Allows direct line access to the Cisco MGC. |
Supports Extended Integrated Services Digital Network User Part (EISUP) inter-MGC signaling | Provides scalable and flexible service. |
Supports generic routing | Provides scalable and flexible service. |
Supports MGCP 0.1, SGCP 1.0 and 1.1, and SRCP | Allows the Cisco MGC to control media gateway connections. |
Has edge-to-edge security | Prevents fraudulent use of the network. |
Supports carrier-grade quality of service (QoS) | Replaces the need for traditional TDM equipment. |
Supports SS7-to-SS7, SS7-to-ISDN, and ISDN-to-ISDN call types | Provides scalable and flexible service. |
Supports voice-band telephony (G.711coding) | Provides scalable and flexible service. |
Supports ISDN data calls | Provides scalable and flexible service. |
Supports echo cancellation1 | Provides scalable and flexible service. |
Supports real-time fax relay | Provides scalable and flexible service. |
Supports Cisco media gateways | Investment in Cisco equipment protected. |
Provides software upgrade of:
| These upgrade paths provide the following:
|
Provides a reliable IP link between Cisco MGC and access servers with Reliable User Datagram Policy (RUDP) | No single point of failure in connection between media gateways and the Cisco MGC. |
Call detail records for PSTN billing | Meets carrier-grade PSTN requirements to migrate existing voice revenue streams to the packet environment and to create new voice service opportunities. Provides a CDR viewer to view billing records. |
Facility associated signaling provided by the Cisco SLTs (T1/E1 WIC, optional with SS7) |
|
Continuous-service platform | Established calls are maintained upon switchover from the Active MGC host to its paired Standby host. |
Sun Solaris 2.6 |
|
Support for:
|
|
Quasi-associated or fully associated signaling | Ready for international markets. |
Complete continuity check (two-wire and four-wire) | Meets interconnect requirements. |
Network Equipment Building Systems (NEBS) Level 3 compliant | Telco-ready. |
Supports approximately 70 ISUPs/NUPs/TUPs | Ability to interconnect with many different carriers and within the Public Switched Telephone Network (PSTN) in most parts of the world. |
| 1Echo cancellation is not yet supported on the Cisco MGX 8260 in the Cisco SS7 PRI Gateway Solution. |
Table 9 provides an overview of the management components of the Cisco MGC.
| Management Component | Description |
|---|---|
Cisco MGC Manager (CMM) | The CMM is a graphical user interface (GUI) that uses simple network management protocol (SNMP) to configure and provision your network solution. You can access the CMM remotely using X-terminals and manage all the MGC hosts in your network with a single CMM system.1 |
MML | Man-Machine Language (MML) interfaces with the Provisioning Object Manager (POM). POM requires an active provisioning session to make provisioning changes. During an active session. POM locks all the data files to prevent other users from making changes. |
PEG Counts | You can obtain a variety of usage statistics from the Cisco MGC. The data is recorded real-time and written to a file. You can specify the statistics to be collected and the time intervals for collection and writing to file. Each PEG count record includes:
|
Alarms | The Cisco MGC supports a comprehensive set of alarms in accordance with International Telecommunication Union (ITU) X.733:
You can adjust the severity of alarm and thresholds to match your carrier's severity level definitions. You can also configure the system to generate real-time alarms to local or remote terminals. All alarms are written to a log file in an uncompressed format for easy retrieval. |
| 1CMM is not supported for the Cisco SS7 PRI Gateway Solution or the Cisco Packet Tandem Solution. It is replaced by Voice Service Provisioning Tool 1.1 or 1.5. |
The Cisco IOS software installed on the media gateways provides an array of network management components (described in Table 10) that are designed to meet the needs of today's large, complex networks.
These management features provide the following benefits:
Cisco's integrated management simplifies administrative procedures and shortens the time required to diagnose and fix geographically dispersed networks. Configuration services reduce the cost of installing, upgrading, and reconfiguring network equipment.
| Management Component | Description |
|---|---|
SNMP and RMON support | Media gateways are fully manageable by means of the Simple Network Management Protocol (SNMP) and imbedded Remote Monitoring (RMON) capabilities.
By using the Alarm RMON group, you can set a threshold on any integer-valued Management Information Base (MIB) variable. When the threshold is crossed, an event, defined in the Event RMON group, is triggered. With these capabilities, the system can detect and analyze overloaded conditions and congestion in real time. |
Network management systems | The media gateways support Command Line Interface (CLI) and the CiscoView GUI for comprehensive, flexible network management. CiscoView provides dynamic status, statistics, and comprehensive configuration information for Cisco switches, routers, media gateways, Cisco SLTs, concentrators, and adapters. It displays a graphical view of Cisco devices, provides configuring and monitoring functions, and offers basic troubleshooting. |
|
Note CiscoView and RMON are not supported on the Cisco MGX 8260 or Cisco MGX 8850/VISM. |
The Cisco SLT is managed using Session Manager software. The Session Manager software also manages the communication sessions between the following elements:
The Session Manager provides the following:
The Cisco SS7 PRI Gateway Solution supports the ANSI SS7, AT&T 41459, and NI-2 protocols.
Before you install the Cisco MGC software, consult the following related documentation for information about hardware installation and system requirements:
After you install the Cisco MGC software, consult the following related documentation for information on configuring and provisioning your system:
This section contains information and procedures you can use to remove, upgrade, and install the
Cisco MGC software. It also contains information about software patches.
The Cisco MGC software is provided to customers on CD. The Cisco MGC software, including software patches, can be installed directly from the CD.
If you are installing software Release 7.4(12) for the first time, refer to the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide for instructions.
|
Note In the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide, note the following change: In the "Configuring SNMP Support Resources" sections on page 2-16 and page 2-86, be aware that SNMP Management Information Base (MIB) measurements are only valid on the Active node. They are not replicated to the Standby node. |
|
Note These documents are shipped with your software in hard copy and electronic format on CD. Always check on www.cisco.com for the latest version of the documentation. |
If you are upgrading from a previous release of 7.4(x) to Release 7.4(12), and you have a configuration with an Active and Standby host, refer to the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.
|
Caution If you are trying to maintain calls during an upgrade of a redundant system and you want to preserve your configuration, verify that in /opt/CiscoMGC/etc/XECfgParm.dat the pom.dataSync parameter is set to false. |
|
Caution No validation is performed on the IDs you enter. If you enter an invalid ID, the utilities package does not add any accounts. |
 |
Tips If you have trouble installing the utilities package, make sure that you do not still have a TransPath group in your group file (located in /etc). |
When you are attempting to migrate from Release 7.3(xx) to Release 7.4(xx), a conflict might arise in the components.dat file. To check this and rectify it if necessary, do the following after the Release 7.4(11) installation is complete:
Step 2 If the file contains a component other than LOG-01 with the compId of 00030013, change the LOG-01 component from 00030013 to 00030050.
|
Note If LOG-01 is the only component with the compId 00030013, this file does not need to be edited. |
Step 3 After changing the necessary compId, copy the components.dat file into the active link directory,
Step 4 Restart the system.
|
Note When migrating from Release 7.3(xx) to Release 7.4(xx), the upgrade will cause a disruption in service. |
If you are upgrading from Release 7.3(xx) to Release 7.4(xx), the upgrade will cause a disruption in service. Use the following procedure for patch installation:
Step 2 Remove all superseded patches.
Step 3 Install all required patches.
Step 4 Shut down N1.
Step 5 Bring up N2.
|
Note In the previous steps, N1=Active and N2=Standby. |
engine.SysGSMTimerInterval = 0 # set Group Service Message to 15000 milliseconds for Cisco SS7 Interconnect for Voice Gateways Solution. This parameter's default has been changed to zero and needs to be zero for all platforms excluding Cisco SS7 Interconnect for Voice Gateways Solution. Migration has been added also for this parameter. So, if the previous default value of 15000 is still configured on the system, then it will retain that value after migration. A one-time manual edit will need to be made to reset the value to zero. All future upgrades will then maintain that value.
The CUSTGRPTBL parameter has been removed from the ipfaspath MML command.
|
Caution If this command is not removed from any previously used batch file, the batch file will fail. |
The CRLEN and ABFLAG parameters have been added to the multipfas MML command.
Software patches for 7.4(12) are either protocol or non-protocol patches. Protocol patches are denoted by the gp indicator, for example, CSCOgp001 indicates protocol patch 001; non-protocol patches are denoted by the gs indicator, for example, CSCOgs001 indicates non-protocol patch 001.
|
Note In other releases, both protocol and non-protocol fixes may have been combined into a software patch. Going forward protocol and non-protocol patches are developed separately. |
|
Note Some CSCOgsxxx patches may include a fix that affects the CMM/Toolkit package. If this package is not installed, the system will display error messages stating that the package cannot be found. The error message can safely be ignored; the CMM/Toolkit package is not required. |
|
Note In some instances you may be required to uninstall an existing protocol patch before installing a new one. In those instances, this information will be provided. |
Because the two types of patches are separate and each has its own numbering scheme, it is possible to have two patches ending with the same number. For example, CSCOgp001 and CSCOgs001. It is important that you look at the patch's indicator (gp and gs) to distinguish the type of patch. It does not matter whether you install protocol or non-protocol patches first. However, the patches must be installed sequentially for each patch type and both both patch types (gp and gs) are required.
A brief summary of each patch is provided later in this section. Patches are listed in reverse order.
|
Note Patches included on the CD are automatically installed when the software is installed using normal installation procedures. |
Patches provide showstopper and test-stopper bug fixes to customers (devtest, solution test), customers, and so on, for a release.
|
Note To determine which patches are required, go to the last patch that you wish to install and you will see in the first bullet under Additional information the list of required patches for that patch. |
Download decode7412.pl into the same directory as the patches (var/tmp) and then run:
Patches are decoded to the required .pkg files.
|
Note decode7412.pl is only required when downloading patches from CCO. |
Step 2 Install all required patches, starting with the first required patch.
The following table gives the system level equivalency for each patch.
| Patch Number | 7.4(11) System Level Equivalency |
|---|---|
CSCOgp006 | Equivalent to 7.4(11) patch 52 |
CSCOgs008 | Equivalent to 7.4(11) patch 51 |
CSCOgp005 | Equivalent to 7.4(11) patch 52 |
CSCOgs007 | Equivalent to 7.4(11) patch 51 |
If you later receive patches that need to be added manually, use the following procedures (unless otherwise stated in the summary information for the patch):
Step 2 Stop the Cisco MGC software by entering the following command:
/etc/init.d/CiscoMGC stop
Step 3 At the UNIX prompt, change to the directory containing the software patch to be installed and enter:
pkgadd -d CSCOgpN.pkg
where N is the patch number (for example, 005).
Step 4 Follow the on-screen prompts. Answer y to each prompt that requires a response.
Step 5 Repeat Step 3 and Step 4 for each patch.
Step 6 Restart your system.
Before installing a patch (unless otherwise stated in the summary information for the patch), the user must shut down the Cisco MGC application, as the affected programs are part of the running system. In order to ensure that the MGC application has been shut down, execute the following command:
/etc/init.d/CiscoMGC stop
Once the Cisco MGC application has been shut down, the user should verify the currently installed software load to ensure that the patch being installed is both compatible and meant for the software currently installed. One way to do this is to run the following command as the root user:
pkgparam CSCOgu000
Now that the MGC application has been shut down and the software load has been verified, installation can begin.
To remove a patch (unless otherwise stated in the summary information for the patch), log in as the root user, and then type the following:
pkgrm CSCOgpN
where N is the patch number (for example, 008).
Unless it is stated otherwise in the summary information for a particular patch, patches do not have to be removed sequentially.
Patch removal will restore the data to its state prior to the upgrade. Files will be copied from the backup directories, and these backup directories will be removed.
Patch CSCOgp007 resolves the following DDTS tickets:
| Identifier | Severity | Component | Description |
|---|---|---|---|
CSCdv38159 | 2 | ioccpriip | PRIIP Q.921 link drops and does not recover. |
CSCdv18587 | 3 | engine | Getting mass engine CotRetestInProgressCmd logs after patch 57. |
CSCdv45573 | 2 | ioccc7 | C7iplinks OOS CONF when provisioning from new. |
CSCdu85580 | 6 | mdl | Make Payphone Info available for billing. |
This patch provides updates to the following:
Additional information:
|
Note It does not matter whether you install protocol or non-protocol patches first. |
After shutting down the Cisco MGC and verifying the software load you can proceed with the installation.
This patch provides updates to the following:
Additional information:
|
Note Patch CSCOgp005 is superseded by this patch. We recommend that you uninstall patch CSCOgp005 prior to installing this patch. If this is a fresh installation, only patch CSCOgp006 and the patches listed in this bullet are required. |
|
Note It does not matter whether you install protocol or non-protocol patches first. |
After shutting down the Cisco MGC and verifying the software load you can proceed with the installation.
This patch provides updates to the following:
Additional information:
|
Note Patch CSCOgp004 is superseded by this patch. We recommend that you uninstall patch CSCOgp004 prior to installing this patch. If this is a fresh installation, only patch CSCOgp005 and the patches listed in this bullet are required. |
|
Note It does not matter whether you install protocol or non-protocol patches first. |
After shutting down the Cisco MGC and verifying the software load you can proceed with the installation.
Patch CSCOgs009 resolves the following DDTS tickets:
| Identifier | Severity | Component | Description |
|---|---|---|---|
CSCdu85580 | 6 | mdl | Make Payphone Info available for billing. |
This patch provides updates to the following:
Additional information:
|
Note It does not matter whether you install protocol or non-protocol patches first. |
After shutting down the Cisco MGC and verifying the software load you can proceed with the installation.
This patch provides updates to the following:
Additional information:
|
Note Patch CSCOgs007 is superseded by the fixes in this patch. Remove CSCOgs007 before installing patch CSCOgs008. If this is a fresh installation, only patch CSCOgs008 and the patches listed in this bullet are required. |
|
Note It does not matter whether you install protocol or non-protocol patches first. |
After shutting down the Cisco MGC and verifying the software load you can proceed with the installation.
This patch provides updates to the following:
Additional information:
|
Note Patches CSCOgs001, CSCOgs002, CSCOgs003, CSCOgs005, and CSCOgs006 are superseded by the fixes in this patch. Remove the superseded patches in order from the highest to the lowest number (CSCOgs006, CSCOgs005, CSCOgs003, CSCOgs002, and CSCOgs001) before installing patch CSCOgs007. If this is a fresh installation, only patch CSCOgs007 and the patches listed in this bullet are required. |
|
Note It does not matter whether you install protocol or non-protocol patches first. |
|
Note The call screening database must be started before using this feature. For information on starting the call screening database, refer to the Software Installation and Configuration Guide: http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/swinst/2ins_74.htm#xtocid1401440 |
|
Note There are two methods that can be used to add screening data. One method uses individual mml commands and the other method uses the prov-add: files command to import a file. |
After shutting down the Cisco MGC and verifying the software load you can proceed with the installation.
Currently in the Cisco MGC Software Release 7(x) code, the user only has four gateway options (5300, 5800, VISM, & 8260). By removing this limitation the MGC software will allow the user to configure other Cisco gateways. Specifically, but not limited to, the 3660 and the 5400.
It is a common requirement in number analysis to be able to separate a dial plan into logical areas and be able to point to the different areas from within an area. The typical current analysis function supports this capability, but it cannot be provisioned. For example, E03 could be the start of an internal routing number in a dial plan, and be owned by the MGC. So when a call with CdPN starting "E03 xxx" is received, the MGC must strip the E03 routing prefix and perform the main analysis of the dialled number.
To avoid having to specify all the main dial plan analysis with each number beginning E03 it is now possible with this feature to provision a B number modification to remove the first 3 digits (E03), and then set a 'pointer' to Section 1 (main analysis). The same concept applies to indirect access calls.
With Continuity Test (COT) retry, the current channel selection uses the 'next-available' channel algorithm. With COT failures, the failure of one channel usually infers that the span is of questionable quality. The 'next-available' channel algorithm will result in a large percentage of call failures before the entire span is marked as out of service.
Optimizing channel selection on COT retry maximizes the chances that each individual call will succeed.
Group Service Messages (GSMs) forward Service Information from the SC to the NAS. The previous short-term solution was to broadcast each span at a configured interval. The GSM interim solution improves this propagation algorithm such that GSMs are forwarded to the NAS only for the spans for which a service change has occurred.
The problem has been that ISDN User Part (ISUP) variants written in Message Definition Language (MDL) make use of separate global variables for each unique ISUP message, and this creates memory overhead.
The aim of these memory reduction changes is to remove this memory overhead. To do this, an Element List is declared, which can contain any ISUP message. The Element List causes input messages to no longer be input as one of the specific global variables.
Memory utilization is significantly reduced with this change. Memory per call is reduced to 32.1K compared to 42.5K without the change. The system is very stable after bringing up 100K calls statically (all the calls are answered and call hold time is infinity). The total memory used by the 100K calls is 3.3 GB, which suggests there is still room for new calls.
For certain customers, the NI2+ signaling system that communicates between the SC2200 and the VoIP Gateway (AS5300) needed to have the enhancement of Suspend and Resume for the Cisco SS7 Interconnect for Voice Gateways Solution to allow Suspend and Resume to work end to end over the solution network.
Symmetrical Suspend and Resume involves the following messages:
and one timer: Tsusp Timer - Default 120 Secs
A line has been added to the .cshsc file in the /opt/CiscoMGC/local directory. The line is commented out (#setenv LD_PRELOAD /usr/lib/libc.so). This commented-out value means that the default is to have a system with High Call Throughput, which is for voice applications where it is important to set up and tear down calls quickly. If the user removes the comment, the system will be set to run Maximum Sustained Calls, which is for dial applications allowing the user to stay connected, for example to the internet, for a sustained length of time. The user does not need to remove the comment manually. The installation file now has a performance script, perf_config, that runs at the end of the automated installation. It allows the user to choose either High Call Throughput or Maximum Sustained Calls.
Following is a sample output of the relevant section of the installation file.
Beginning Check of System Performance Requirements
Number of CPUs in system 1
Memory size: 512 Megabytes
The sparc processor operates at 270 MHz,
WARNING Insufficient Memory to run CiscoMGC - should be at least 2048 Megabytes!!
Swap is total: 23272k bytes allocated + 38032k reserved = 61304k used, 1009752k available
Please Verify that you have over 4000000K Available swap
perf_config: setting *.numberOfThreads = 0
Configure System for (1) Maximum Sustained Calls (2) High Call Throughput
Enter 1 or 2 or q to quit
1
Optimize for Maximum Sustained Calls
perf_config: setting engine.SysMdlMemoryReduction = 1
perf_config: setting engine.CALL_MEM_BLOCK_SIZE = 0
perf_config: setting engine.CALL_MEM_CHUNK_SIZE = 0
Note that the default value is 2, High Call Throughput. If the user selects value 1, Maximum Sustained Calls, then the following parameters are set accordingly.
perf_config: setting engine.SysMdlMemoryReduction = 0
perf_config: setting engine.CALL_MEM_BLOCK_SIZE = 110000
perf_config: setting engine.CALL_MEM_CHUNK_SIZE = 110000
*.numberOfThreads will be set accordingly
In addition to the parameter setting, from this release forward, two different engine binaries are included and, based on the option you select, the right engine will be symbolically linked to engine in the /opt/CiscoMGC/bin directory.
lrwxrwxrwx 1 root sys 35 Jun 3 18:06 engine ->
/opt/CiscoMGC/bin/engine.smartalloc
-rwxr-xr-t 1 mgcusr mgcgrp 4370199 Jun 3 18:07 engine.no_smartalloc
-rwxr-xr-t 1 mgcusr mgcgrp 4381784 Jun 3 18:07 engine.smartalloc
This redesign enables the Input-Output Channel Controller (IOCC) to support 504 ISDN PRI D-channels. The XECfgParm.dat file has been modified to allow provisioning of 1500 PRI D-channels using at least three IOCCs with a maximum of 504 D-channels on each.
XECfgParm.dat Change
*.maxNumPRIL3Links = 504
This script has been modified. It now queries the user as to whether or not they intend to uninstall for the purpose of upgrading the software. The default is yes. If they choose the default, nothing will happen out of the ordinary. If the user chooses no, the system will prepare to back up the data files from the previous release once the gc001 package is completely removed.
The CLI Screening Service is executed via an intelligent network in order to authenticate a generic calling user as a customer of that network (that is, only a calling user that has already subscribed to this service can choose the intelligent network as the carrier for a particular call by selecting the particular carrier access code for that service).
The protocol between the SSP and SCP is the ETSI Core INAP CS-1 with some commissions.
By definition, the Redirecting Number parameter contains the A-number of the station that forwarded the call. Therefore, for forwarded calls, if a succeeding switch determines that the A-Number is to be screened, it shall use the number contained in the Redirecting parameter for A-number screening.
A-Number screening for forwarded calls may vary from customer to customer. For example, in the United States, Charge Number Parameter is used for forwarded calls across the local access and transport area. Therefore, an office- or switch-based parameter is required to dictate what parameter should be used for A-number screening. This feature does not impact the way in which the A-Number screening/analysis tables are provisioned, because the Redirecting Number contains the Calling Number of the station that forwarded the call.
The set-admin-state | reset command releases calls and clears any local blocking while updating the block view of its remote side. In the case of Circuit Group Reset (GRS), the Circuit Group Reset Acknowledgment (GRA) will contain the far-end blocking view. In the case of Release (RLS), the far end will acknowledge the release and send either blocks or unblocks indicating the far-end blocking view of bearer channel. The set-admin-state | reset command is only applicable for Integrated Services Digital Network User Part (ISUP) . The Switch Port Analyzer (SPAN) and bearer channel targets are not applicable.
MML command format:
set-admin-state:target: lock | unlock | reset
Target is identical to the target option for stp-call. The other parameters are:
Example commands :
set-admin-state:VSC-44:reset
set-admin-state:gw1-5300:reset
set-admin-state:opc:reset
set-admin-state:opc:cic=5,rng=255,reset
set-admin-state:tg-4000:reset
This feature has been implemented to allow a Service Controller (SC) to support an even greater number of sustained calls. The user can now configure the system to capture information for all events or only the last event associated with a call. This captured information will be displayed when either prt-call or sta-abn is invoked and the selection criteria is met. This information is used to help identify operational problems. In order to achieve the greater number of sustained calls, the user must select the option to capture information regarding only the last event for the call.
Defining the behavior of call event capture will be only settable at a system level and cannot be dynamically changed in 7.4(12). A new parameter has been added to XECfgParm.dat to indicate the default behavior of the system: *.detailedCallEventCapture = [0|1]
The possible settings are:
Values other than 0 or 1 will invoke the same behavior as the default setting. The default setting is 1.
This functionality will have a single tariff rate depending on the Called Party Number. This may be achieved by configuring a tariff in the dialplan. Thus, CdPN analysis may be provisioned to return a charging value and trigger a CRGT. The tariff rate will be fixed, not varying with time of day or day of week. Hence, the current tariff will equal the next tariff, and switchover time will be the maximum value for every message (that is, 24 hours). It appears using the Tariff Duration type = 0 allows for time-independent tariffs (unlimited duration); next tariff and switchover time do not have to be sent in this case.
New added parameters and their default values in the properties.dat file are as follows:
The following parameters are added for IP links and for C7 IP links.
Parameter's MMI Name | Parameter's SNMP MIB Name | Parameter's Description | Parameter's Values (Default) |
NEXTHOP | tppC7IPLinkNextHop | IP address of next hop | IP address; (0.0.0.0). IP address of router used to get to remote subnet. All IPLNKs and C7IPLNKs with the PEERADDR on the same subnet and that have a NEXTHOP other than 0.0.0.0 must have the same NEXTHOP value. Each IPLNK that has a NEXTHOP other than 0.0.0.0 is validated to be certain that the configured NEXTHOP is being used when packets are transmitted to the PEERADDR. All IPLNKs with a NEXTHOP other than 0.0.0.0 are validated to ensure that the NEXTHOP address is on the same subnet as the IPADDR parameter. To use proxy ARP and host routes, set the NEXTHOP parameter to the local address by using one of the following special strings: "IP_Addr1"
"IP_Addr2"
"IP_Addr3"
"IP_Addr4"
This will get translated into an actually local address in the same way the IPADDR parameter does. |
NETMASK | Net mask | 255.255.255. | IP address; (255.255.255.255). Set to subnet mask of PEERADDR. Set to "255.255.255.255" to produce a host route instead of a subnet route. NETMASKS of 0.0.0.0 and values that have a 1 bit less significant than the most significant 0 bit are rejected. |
The following is an example using an MML command.
The IP link is an IP connection between an MGC Ethernet interface and an MGW. Its MML name is IPLNK. When the IP link is to another subnet, the optional NEXTHOP and NETMASK parameters are recommended.
| Command | Purpose |
|---|---|
MML>prov-add:iplnk:name="
Iplink1",if="en-1lif1",ipaddr="IP_Addr1",port
=3001,
peeraddr="192.12.214.10",peerport=3001,svc="i
pfassvc1",sigslot=1,sigport=1,desc="IP link
for IPFAS service to
NAS1",nexthop="172.24.235.1",netmask="255.255
.255.0"
| Uses the PROV-ADD command to add the component and required parameters: Component: iplnk Name: Iplink1 IF: en-1lif1 PORT: 3001 PRI: 1 (default) PEERADDR: 192.12.214.10 PEERPORT: 3001 IPADDR: IP_Addr1 SIGSLOT: 1 SIGPORT: 1 SVC: pfassvc1 Description: IP link for IPFAS service to NAS1 NEXTHOP: 172.24.235.1 NETMASK: 255.255.255.0 |
Use the prov-rtrv command to verify.
|
Tips When configuring two IP links to the same NAS, you need to configure two different Ethernet IP addresses on both the MGC and the NAS. All IP links and C7 IP links with a PEERADDR on the same network must have the same NEXTHOP. For each IP link and C7 IP link, the NEXTHOP must be on the same network address as the IPADDR. When NEXTHOP is set to 0.0.0.0, the IP routing feature is disabled. A value of 0.0.0.0 for the NETMASK is not allowed. As a binary number, the NETMASK cannot have any 1 bits less significant than the most significant 0 bits. For example, a NETMASK of 0.0.255.255 is invalid. |
Some customers have located Media Gateways on subnets other than the subnets local to the Media Gateway controller. This enhancement involves defining an entry in the Solaris routing table whenever a Media Gateway is added to the system. This will alleviate single point of failure due to loss of a single interconnect. With the addition of a Media Gateway whose interfaces are located in two new subnets that do not have corresponding routes in the routing table, the following must occur on deployment of the configuration:
This is a specifically requested functionality due to an issue with a customer's Ericsson AXE10 Local exchange switch. The switch software currently prevents it from acting upon the access control list (ACL) parameter in an ISUP Release message. This specific functionality, along with the standard ACC mechanism, allows the customer to effectively manage and limit congestion events across the Cisco-deployed dial access platforms for all possible originating switch types.
It is possible to command the last available signaling link in a link set to OOS, without any warning or prompt to confirm the action. The forced out of service (FOOS) is intended for use on the last link in a link set. The OOS command should be refused under these circumstances, and if the user wants to proceed, they have to use FOOS. Most of the other devices will at least prompt the user to confirm the action, or will deny the action unless a specific command or parameter is entered. The MGC MML will be modified to reflect the above condition, to prevent the user from deleting the whole linkset by mistake.
The T_LinkAlignTime parameter controls whether or not RSC messages are sent when links/dpc(s) are restored. If the time specified in the T_LinkAlignTime parameter expires before the links are restored, then the SC tries to reset the CICs associated with those links when the links are recovered. If the links are restored before the time specified in the T_LinkAlignTime parameter expires, then the SC continues the call. In previous versions, T_LinkAlignTime was hardcoded to 2 minutes. T_LinkAlignTime is now configurable (through properties.dat). It is set per sigPath and is specified in milliseconds. Valid values are 0 to n.
In this version the functionality for DPP is accessed via MML or the MGC Node Manager. Finally, screening functionality has been added to this release.
MGCP supports codec negotiation via the transfer of preferred codecs in the Session Description Protocol (SDP) messages exchanged between the ingress and egress gateways. The call agent (MGC) is not a required participant in this negotiation other than to deliver the messages via MGCP. However, MGCP also supports the ability for the call agent to influence the negotiation by providing a local connection option (LCO) that can limit the codecs proposed by the gateways. The LCO can be part of the ingress create connection (CRCX) or the egress CRCX. Since the supplying of the LCO is an option, the Cisco gateways can function when the call agent does not supply a list. The Cisco 5300 has the concept of a preferred codec that it will select as long as the call agent also includes that codec in the LCO (or the call agent fails to specify an LCO). The Mixed Codex featurette takes advantage of this feature.
Although not truly a compression algorithm, some Cisco gateways support clear channel data indication via the "a" subparameter of the LCO. However, not all versions of all gateways use the same string to indicate this feature, and not all gateways support clear channel. Therefore the MGC will implement a value called the GWClearChannelAlgorithm that can be provisioned on a MGC in the XEfgParms.dat, as follows:
*.GWClearChannelAlgorithm = null # clear channel algorithm.
This section contains information about known issues and the corresponding workarounds in the
Cisco MGC software release 7.4(12).
|
Note For more information about Cisco IOS issues and workarounds, see the Cisco IOS release notes for your platform. |
On very large configurations, prov-sync may result in a spurious switchover. The current heartbeat configuration does not allow enough time for prov-sync to complete and may timeout other processes.
The following XECfgParm.dat configuration change is required:
This change is not patchable; it must be manually executed.
During a failover on the master SC where both ethernet connections are lost, the failover correctly switches to the slave SC. However, once the ethernet connections are restored on the master, the SC does not return to Standby mode.
Workaround:
With the slave in Active mode, execute (as root) on the the Master:
After the SC software has stopped, restart it using the following command:
To verify that the SC has entered the Standby state, return to mml and execute the following command:
|
Note The ifconfig UNIX commands should not be used to administratively down the ethernet interfaces while the MGC software is running. |
ReleaseMode is a SigPath property used to define the type of releasing used for a solution. Valid values for ReleaseMode are sync and async. Switched solutions use asynchronous releasing (async). Nailed solutions use synchronized releasing (sync). Synchronous releasing ensures that circuits are released simultaneously.
|
Note For nailed solutions, the ReleaseMode property should be set to sync on both the SS7 and IP sides. |
The ReleaseMode property can be modified using MML:
CSCdt15122 provides a fix that updates the properties.dat ReleaseMode parameter from Async to Sync for a new configuration. However, existing configurations must be modified using the following MML command:
|
Note This command must be entered for each link. |
There is a mismatch between the SLT timer and the failover daemon timer. This mismatch leads to SS7 links bouncing when the standby SC2200 must "discover" that the active box has become inactive.
A change to the failover daemon timers corrects the problem. In XECfgParm.dat:
When migrating from 7.3 (x) to 7.4(10) or later, the script migrate_7.1003_7.1004 (contains the code for filling in empty extNodes.dat) is skipped. If extNodes.dat is empty, you must modify the migration script to fill in extNodes.dat from components.dat. Different migration scripts are modified in different baselines.
For the Cisco SS7 Interconnect for Access Servers Solution Release 2.2, the Active and Standby system platforms must use matching hardware. For example, a Sun Netra 1120 cannot be used as a peer to a Sun t100. A Sun Netra 1120 can be used as a peer only to a Sun Netra 1120. A Sun t100 can be used only as a peer to a Sun t100.
Due to timing issues, if both Master and Standby MGCs are started almost simultaneously, the intended Slave (as defined in XECfgParm.dat: *.desiredPlatformState) may become Active, while the intended Master machine goes to Standby mode. When this occurs, there may be a minimal time delay on initial system startup.
The format of call detail record (CDR) files has changed in Release 7. CDR files are now generated in a binary format and consist of call detail blocks (CDBs). CDBs are statistics taken at various points in a call. CDR files are generated at regular intervals based on file size, call records, or a specified number of minutes.
|
Note You can configure the Cisco MGC software to generate CDRs in an ASCII format, if necessary. For more information, see the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide. |
It is possible to change the following settings:
For information about CDBs and the fields in CDR files, see the Cisco Media Gateway Controller Software Release 7 Reference Guide and the Cisco Media Gateway Controller Software Release 7 Operations, Maintenance, and Troubleshooting Guide.
The following table shows the mapping from Software Release 4.2(x) format data to Release 7 format data.
| Release 4 Field | Release 7 Field or Derivation | ||||||
|---|---|---|---|---|---|---|---|
Name | Type | Size | Comment | Name | Type | Size | Default Value |
Revision Level | Int | 3 | Not updated in Release 7 | Tag 4000 |
|
| 0 |
Pretranslated Calling Number Indicator | Int | 1 | Not valid in Release 4 or Release 7 |
|
|
| Always 0 |
Calling Number | String | 32 |
| Tag 4010 | IA5 | 1 to 96 |
|
Pretranslated Dialed Number Indicator | Int | 1 | Not valid in Release 4 or Release 7 |
|
|
| Always 0 |
Name | Type | Size | Comment | Name | Type | Size | Default Value |
Dialed Number | String | 32 |
| Tag 4012 | IA5 | 1 to 96 |
|
Posttranslated Calling Number Indicator | Int | 1 | Not valid in Release 4 or Release 7 |
|
|
| Always 0 |
Translated Calling Number | String | 32 |
| Tag 4011 | IA5 | 1 to 96 |
|
Posttranslated Dialed Number Indicator | Int | 1 | Not valid in Release 4 or Release 7 |
|
|
| Always 0 |
Translated Dialed Number | String | 32 |
| Tag 4014 | IA5 | 1 to 96 |
|
Setup Time | UNIX Time Format | 10 | Number of Seconds since Jan 1, 1970 | Tag 4003 | BE | 4 |
|
Seizure Time | UNIX Time Format | 10 | Number of Seconds since Jan 1, 1970 | Tag 4004 | BE | 4 |
|
Answer Supervision Time | UNIX Time Format | 10 | Receipt of Answer Message | Tag 4005 | BE | 4 |
|
Disconnect Time | UNIX Time Format | 10 | Receipt of Release Message | Tag 4006 | BE | 4 |
|
Disconnect Side | 0 = orig, 1 = term, 2 = MGC | 1 |
| Tag 4028 | char | 1 |
|
Release Code | Hex | 4 |
| Tag 2008 or 3008 | BE | 2 |
|
In SigpathId | Hex | 8 |
| Tag 4066 | BE | 4 |
|
In Channel Id | Hex | 6 |
| Tag 4068 | BE | 4 |
|
In Protocol Id | Int | 2 |
| Tag 4069 | char | 1 |
|
Out Sigpath Id | Hex | 8 |
| Tag 4070 | BE | 4 |
|
Out Channel Id | Hex | 6 |
| Tag 4072 | BE | 4 |
|
Out Protocol Id | Int | 2 |
| Tag 4073 | char | 1 |
|
Bearer Capability | Hex | 4 | Not Used | Tag 2001 or 3001 | char | 2 to 13 |
|
Customer Id | Int | 5 | Not Used |
|
|
|
|
Charge Number | String | 32 |
| Tag 4011 | IA5 | 1 to 96 |
|
CPC Call Type | Int | 1 |
| Tag 2000 or 3000 | char | 1 |
|
CPC User | Int | 1 |
| Tag 2000 or 3000 | char | 1 |
|
CPC Language | Int | 1 |
| Tag 2000 or 3000 | char | 1 |
|
Reserved | Int | 1 |
| n/a |
|
|
|
Name | Type | Size | Comment | Name | Type | Size | Default Value |
Reserved | Int | 1 |
| N/A |
|
|
|
Call Type Flag | Int | 1 |
| N/A |
|
|
|
Call Feature Flag | Int | 1 |
| N/A |
|
|
|
NOA Pretranslated Calling Number | Int | 2 |
| Tag 2003 or 3003 | char | 1 |
|
NOA Pretranslated Dialed Number | Int | 2 |
| Tag 2005 or 3005 | char | 1 |
|
NOA Posttranslated Calling Number | Int | 2 |
| Tag 2004 or 3004 | char | 1 |
|
NOA Posttranslated dialed Number | Int | 2 |
| Tag 2007 or 3007 | char | 1 |
|
Total Meter Pulses | Int | 4 |
| Tag 4030 | BE | 2 |
|
When setting administrative state or blocking a circuit while the circuit is in use, be aware that the circuit remains in the camped-on state until the call is dropped.
If you use the Sun Enterprise Volume Manager software to mirror your system and you set the system to a future date, you must reinstall the Sun Solaris operating system to reset the current date. If you change the setting from a future date back to the present date without reinstalling Sun Solaris, your system will not operate.
To change the value of the CIC on a switch trunk with the MML command prov-ed, block the CIC using the blk-cic MML command before issuing a prov-cpy command.
Circuit group operations on Non-Facility Associated Signaling (NFAS) spans are functional, but note the following behavior in a configuration where CICs 1 through 23 map to channels 1 through 23 on NAS span 0, and CIC 24 maps to channel 1 on NAS span 1.
When two NAS spans are disconnected, the Cisco MGC receives two group service messages from the NAS:
When two NAS spans are reconnected simultaneously, two identical group service messages are received. These messages indicate that the channels on span 0 and span 1 are in service. The Cisco MGC sends out the circuit group unblocked (CGU) message, starting from CIC 1 with a range of 23. This includes CIC 24, since the group service message indicates that channel 1 on span 1 is In-Service. The Cisco MGC sends a second CGU starting from CIC 25, since CIC 24 is noted in the first CGU.
If your configuration uses an 8-port connector as a serial connection for switchover, you must enable the read-write permissions for the connection. The permissions file is located at /devices/pci@1f,2000. With root access, use the chmod command to change the setting from crw---------- to crw-rw-rw-.
Congestion control for Calls Per Second (CPS), which are driven by available CPU for processing, is implemented in this release. This means that if the traffic pattern exceeds the capacity of the platform, calls will be throttled per the defined criteria. However, congestion control for the number of sustaining calls, which are driven by available memory, is not implemented until a future release. Should a situation arise where the number of sustaining calls exceeds the capacity number of the platform, that is to say if there is not enough available memory, the application will core. This can be avoided by carefully planning your network to ensure proper provisioning of DS0 per each node. Please consult with your account team for safe thresholds.
The following changes are in Release 7.4(x):
Guidelines for using CMM must be followed carefully or access problems may arise regarding the provisioning files. In particular, make certain to use a valid user ID that has been defined to belong in the valid group (mgcgrp). If the root account is used to create provisioning data, a non-root user will not be able to modify that data on a subsequent provisioning session.
The expected throughput data rate on an SS7 link configured to run at 64 kbps is approximately 53 kbps, allowing for link overhead for flags, bit stuffing, and sequence numbering. However, when using a 64-kpbs link on the IT Telekommunikations AG (ITK, now Digi International AG) cards, the uplink data rate is approximately 40 kbps, and the downlink data rate is approximately 52 kbps.
|
Note You need three network interface cards (NICs) per Cisco MGC: two for MGCP, and one for network management traffic. |
The *.logFileNamePrefix parameter replaces the *.logDest parameter to determine log file names. However, the *.logDest parameter remains in the XECfgParm.dat file because some processes rely on it to start correctly.
For sustainable runs, Cisco recommends that all log priority processes be set to Error.
Do not store more than 64 configurations on your host machine. Your configurations are automatically saved to the /opt/CiscoMGC/etc/CONFIG_LIB directory. If you have a continuous-service configuration, during the prov-sync command, all the configurations in this directory on the Active host are synchronized on the Standby host. If you have too many configurations stored in this directory, the command fails and the Standby is left in an Out-of-Service state.
MICAtm Technologies modems do not include a near-end echo canceller, so they do not function correctly on circuits with excessive near-end echo (greater than -60dBm, for example -33dBm). Typical observed results are poor or no V.34 or PCM connects on long distance calls. With a short round trip delay, the near end and far end echoes might overlap and the modem's far-end echo canceller might cancel both.
Workaround: Reengineer the line to the MICA modem to eliminate any near-end echo (for example, remove any near-end A/D conversion), or replace the MICA modem with a Microcom modem. Microcom modems (3.1.30 fw) function correctly and establish solid, if not exceptionally fast, V.34 connections (19.2 to 24 Kbps range). Also, setting a modem cap with s29 = 4 (for example, V.22bis and below) causes incoming calls to succeed.
When you reboot a media gateway (MGW), you might see several version messages exchanged between the Cisco MGC and MGW during synchronization. This behavior does not affect system performance or PRI initialization.
The PEERPORT field is no longer used in the C7IPLNK component and has been removed from the CMM C7IPLINK panel and from the MML command. Since the PEERPORT value is now determined using the XECfgParm.dat file, rather than the sigChanDevIp.dat file, all your links will have the same PEERPORT. All Cisco SLTs must have the same PEERPORT.
In the XECfgParm.dat file, you must enter the PEERPORT number in the *.stPort parameter.
When the RLM heartbeat timer is increased on the NAS, the RLM.timerLinkDownMin property must be changed to heartbeat + 5 seconds.
After starting the Cisco MGC from an Out-of-Service condition, wait at least ten seconds before starting an MML session. The log server may not run. If this occurs, you must stop and start the Cisco MGC manually (CSCdr13849).
The current version of Release 7.4 does not support software upgrades from 7.3 to 7.4 without the loss of calls.
Symptom/Condition: prov-dply command produces the following error:
Wed Nov 22 19:35:55:223 2000 | ProvObjectManager (PID 15865) <Error>
XEFileService::countFilesInDir(): error opening directory
/opt/CiscoMGC/etc/CONFIG_LIB/CFG_after_deploy
The above error is written in the platform.log file, but this does not mean that prov-dply failed. To determine if the command worked, use the following workaround.
After the prov-dply command is issued, check to see if the Active link on the Standby side is the same as the active link on the Active side by following these steps:
cd /opt/CiscoMGC/etc
Step 2 Issue the ls -l active_link command:
ls -l active_link
Perform the above two steps on the Standby as well as the Active side and compare the active links. If they are the same, prov-dply worked.
You can also follow the prov-dply command with the prov-sync command to make sure that the provisioning data on the Active side is copied to the Standby side.
This section describes issues and caveats for Cisco MGC software Release 7.4(12).
Table 12 lists resolved caveats sorted by severity, then identifier, then component.
| Identifier | Severity | Component | Description |
|---|---|---|---|
CSCdt21217 | 2 | mdl-pri | sc/vsc: COT calls terminating on sc/vsc not working |
CSCdt95831 | 2 | engine | TV13: SC2200 does not set CIC oos/send GSM for COT failure |
CSCdu09666 | 2 | protocol | SS7 REL with cause translates to DISC with PI=8 |
CSCdu59886 | 2 | engine | SC2200 displays incorrect trunk information on switch over |
CSCdv05388 | 2 | engine | TV13: SC2200 not responding to ISUP messages on a CIC, CIC is idle |
CSCds51747 | 3 | iocm | MGC IP Routing: Dest went INB after modifying nexthop/netmask |
CSCdt51753 | 3 | mdl-q721 | SC2200 sends suspend to NAS rather than disconnect |
CSCdt59590 | 3 | provision | prov-exp never completes after migrating from 7.3(17D) to 7.4(12) |
CSCdt63952 | 3 | iocm | Rtrv-lnk-ctr has nothing in it |
CSCdt81365 | 3 | engine | TV: set-admin-state:<NASPATH>:lock does not work |
CSCdt83725 | 3 | mml | prov-exp:numan exporting incorrect bdigtree digitstrings |
CSCdu31435 | 3 | ioccxgcp | Please change mgcp log invalid format from debug to error |
CSCdu32192 | 3 | mdl-pri | Wrong release cause sent when timer expires on ansi |
CSCdu36842 | 3 | engine | TV13: SC2200 continues sending CGB/CGU messages for 24 cics |
CSCdu47106 | 3 | ioccc7 | No response to SLTM with single c7iplnk in linkset |
CSCuk24866 | 3 | install | Install script hangs following patch installation |
Contact your Cisco representative to obtain status on software problem reports (SPRs). For more information on IOS caveats, see the IOS release notes for your platform. Table 2 is sorted by severity, then identifier, then component.
|
Note For sustainable runs, we recommend that all log priority processes be set to Error. |
| Identifier | Severity | Component | Description | Explanation/Workaround |
|---|---|---|---|---|
CSCdr50472 | 2 | provision | BD: prov-sync fails if one enet link is disconnected on slave | Due to the large amount of configuration data, the time necessary for provisioning the boxes exceeds default timeout value for MML response (1.7 MB on raemon and 1.1 MB on purvis). Workaround: Increase the value for prov-sync command in XECfgParm.dat file - add MML.prov-sync = 30000 to the MML section of XECfgParm.dat file. |
CSCdt79888 | 2 | engine | Unackknowledged CGB/CGU over an extended period (8hrs) causes core | After migrating from 7.4.9C to 7.4.12, unacknowledged CGB/CGU over an extended period of time(8hrs)causes engine to core. |
CSCdt86541 | 2 | flovr | TV: sw-over from ACTIVE 7.4(11) SC to STANDBY 7.4(12) SC prohibited | On the Cisco MGC, manual switch over via the sw-over command may be prohibited if the Standby MGC is running 7.4(12) and the Active MGC is running 7.4(11). |
CSCdt89116 | 2 | engine | COT failure alarm does not identify circuit that failed | A COT failure generates an alarm but does not identify the CIC that the failure occurrred on. |
CSCdu40226 | 2 | engine | SC2200 shouldnt ignore GSM ACK contents, should data fill correctly | TV: After adding a new span of circuits on the SC2200 whose associated span of circuits on the NAS is shut but configured, the SC2200 sends a Group Service Message for that span indicating it is in-service. The NAS does not initiate its own GSM back to the SC2200 to indicate that those channels are not in-service. This creates a situation where we have a channel state mismatch scenario and the SC2200 thinks those channels are available for calls. |
CSCdv06452 | 2 | mdl-ansi-ss7 | TV13: SC2200 continues sending RSC messages, reporting T17 alarms | TV13: SC2200 continues sendig ISUP RSC messages and reporting T17 timer expired alarms even though the RSC messages are acknowledged with RLC messages. |
CSCdv21898 | 2 | doc | Dynamic Reconfig: Added,deleted, and re-added CIC, comes up blk=gateway | Workaround: Bounce the VSC software. |
CSCdv24190 | 2 | engine | SC sends SS7 RSC upon receiving nas disconnect | Workaround: None |
CSCdv25510 | 2 | provision | MML session hangs up on prov-cpy | Workaround: None |
CSCdt20284 | 3 | mdl-pri | Up/down calls on NAS and SC2200 not release CIC | This problem is seen with SC versions 7.4.10 and 7.4.11 and above when working with AS5800 (UUT) and AS5300 (Client call) back to back environment. If user terminates a large amount of calls simulataneously (e.g.: clear modem on UUT or client), sometimes the SC will not put the CICs back in the proper state on the client side or the UUT side. As a result, new client calls are rejected with "Temporary failure" in the debug isdn q931 on the NASes. Main problem is that inconsistant reporting is showing on SC where "rtrv-tc:all" first displays that all CICs are in IS and Idle state. If you scroll down where "rtrv-tc:all" displays the individual TC information, lots of TCs are in the IN state. Calls are not being cleared properly. Workaround: Stop and start the SC. |
CSCdu33449 | 3 | xe | TV13: Default value in XECfgParm.dat for SysScreeningCheck is false | SysScreeningCheck has a default value in XECfgParm.dat of false; should default to true. If left false and a customer configures screening on the SC2200, all calls will be rejected by the SC2200. Changing this in XECfgParm.dat will require a switchover or restart before taking affect. |
CSCdu35454 | 3 | engine | different service states for 2 sides of nailed trunk is confusing | In a configuration where there are nailed trunks provisioned, we frequently see occasions where, in mml, the service state (PST= )of the SS7 side of a nailed trunk is OOS, but the service state of the ISDN side of that same trunk is IS. This is inherently confusing because since these trunks are nailed, when the SS7 side is OOS, the ISDN is OOS as well. MML should reflect this to avoid confusing the user. |
CSCdu44719 | 3 | procm | MGC software does not gracefully shutdown after P39-40 | In standalone configuration, after installation of patches 39 and 40 in 7.4.11, the command /etc/init.d/CiscoMGC stop does not gracefully shutdown software processes. Workaround: None (after three timeouts processes are killed) |
CSCdu51917 | 3 | engine | TV13: SC sends incompatible VERSION message after RLM reinitializes | Testing TV w/ 7.4(12). After RLM reinitializes between the SC and the NAS (either by reload, shut/no shut on the RLM, etc.) the NAS and SC should exchange VERSION messages, GSMs, and RESYNCs. When the NAS initiates the VERSION message up to the SC, the SC responds with a message which the NAS cannot understand (the NAS defines as BAD PACKET in ISDN q931 debugs and "releases" as a temporary failure). I'm assuming this is a VERSION message, but in an incompatible format which the NAS does not understand. The SC then follows up by initiating its own VERSION message, which the NAS accepts without a problem. |
CSCdu62917 | 3 | mdl-ansi-ss7 | TV13: SC2200 reports T17 ISUP alarms but does not send RSC message | On the Cisco SS7 Interconnect for Voice Gateways Solution, the SC2200 may incorrectly report T17 ISUP timer alarms. Workaround: Manually switch to the standby SC2200 by executing the mml command "sw-over::confirm". |
CSCdu89179 | 3 | engine | Call negotiated by NAS to wrong DPC, is not invalidated by SC2200. | Calls intended for DPC1 from DPC2, were inappropriately terminated back to DPC1 by NAS and were 'not' invalidated by SC2200. NAS is allowed to negotiate calls to any available CIC; but if the terminating CIC is on a DPC not intended per call definition, than SC2200 should proactively invalidate the call. |
CSCdv01684 | 3 | provision | After prov-cpy fails, same data cannot be provisioned again. | When prov-cpy fails, running the provisioning script again does not provision the same data that the script previously failed. |
CSCdv15041 | 3 | mml | mml session reports ACE_SV_Semaphore_Complex | mml sessions encountered the following error message: fairfield:/opt/CiscoMGC/local> mml -s2 ACE_SV_Semaphore_Complex: No space left on device ACE_SV_Semaphore_Complex: No space left on device After restarting the CiscoMGC the problem goes away for a while and then returns. |
CSCdv20239 | 3 | procm | STP-SOFTW:all:kill,confirm make SC2200 display ambigious Platform St | If you use the stp-softw:all:kill,confirm mml command to stop the SC2200, all the processes are stopped except rtrv-ne, which shows the SC2200 to be in Standby state instead of OOS State. |
CSCdv20615 | 3 | mml | diaglog put files in the wrong place | According to mml and CiscoMGC release 7 document, diaglog should put files in $BASEDIR/var, but it actually puts them into $BASEDIR/var/log. |
|
Note Cisco Management Information Base (MIB) User Quick Reference is no longer published. For the latest list of MIBs supported by Cisco, see Cisco Network Management Toolkit on Cisco Connection Online. From Cisco.com, click on the following path: Service & Support: Software Center: Network Mgmt Products: Cisco Network management Toolkit: Cisco MIB. |
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at http://www.cisco.com. Translated documentation can be accessed at http://www.cisco.com/public/countries_languages.shtml.
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Cisco documentation is available in the following ways:
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response card behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc.
Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
P3 and P4 level problems are defined as follows:
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
http://www.cisco.com/register/
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
http://www.cisco.com/tac/caseopen
If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
P1 and P2 level problems are defined as follows:
Posted: Fri Oct 12 12:48:19 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.