Cisco PGW 2200 Softswitch

Interaction Between the SysMdlMemoryReduction Parameter, Failover, and CDRs

Document ID: 44280

Updated: Feb 02, 2006



This document describes the interaction between the SysMdlMemoryReduction parameter, failover, and Call Detail Records (CDRs). There are two ways to generate CDRs in the PGW, and each method uses its own technique to populate tags in CDRs for the Cisco PGW 2200.



Readers of this document should have knowledge of Call Detail Block (CDB) descriptions. Refer to Cisco Media Gateway Controller Software Release 9 Documentation for further PGW information.

Components Used

The information in this document is based on the Cisco PGW 2200.

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.


These lines are in the /opt/CiscoMGC/etc/XECfgParm.dat file:

engine.SysMdlMemoryReduction = 1
*.LongCallTime = 21600000
engine.CDRmessageTypes = "1010,1020,1030,1040,1050,1060,1070"

For default settings, refer to the XECfgParm.dat File Parameters document.

End of Call CDR Generation

In this method, the tags are written in CDB 1110 only at the end of the call. Therefore, all CDR information is preserved until the end of the call, and all CDR information is also checkpointed to the standby. In this method, the information is available when CDB 1060 is written. Therefore, all tags are correctly populated in CDB 1060 before and after failover.

Event-Based CDR Generation

In this method, a customer receives CDR information at various stages of a call. The PGW pre-defines several stages (Answered, Long Duration, Released, and so forth) that can trigger a generation of CDBs. Various CDBs that can be configured are 1010, 1020, 1030, 1040, 1050, 1060, 1070, and 1080. Once a tag is written into a CDB, it is considered to be non-essential information; PGW does not checkpoint non-essential information to standby. The tags in CDB 1060 are non-essential information because they were already written into CDB 1010. Once failover occurs, the newly active system has no knowledge of non-essential information, as they were not checkpointed. Therefore, it creates CDB 1060 with empty tags.

If you set the engine.SysMdlMemeoryReduction parameter in the XECfgParm.dat file to 1, then the non-essential information is deleted in the active PGW after the tags are written into a CDB. The 1 value for that parameter is recommended for optimum usage of memory per call.

If the above parameter was set to 0, the tags in CDB 1060 would be empty only in the standby system.

1060 CDBs are Sometimes Lost

Once a call is answered, the Long Duration timer is started in both the active and standby system. Whenever the timer expires in the active system, the PGW writes the CDB 1060 and restarts the timer. The standby PGW only keeps track of the timer and does not write a CDR. After failover, the newly active PGW writes a CDR record.

This is an example of that sequence:

  1. The call is answered at 8:33.

  2. The Long Duration Timer for 30 minutes is started in both the active and the standby PGW at 8:33.

  3. Failover occurs at 9:02. It takes couple of seconds for the standby PGW to become active.

  4. The active PGW stops at almost the same time that the Long Duration Timer expires. Therefore, it can not write the 1060 CDB at 9:03. Furthermore, at 9:03, the standby PGW is transitioning to active PGW and is not fully active. Since only an active PGW creates a 1060 CDB, this CDR is lost.

  5. At 9:33, the Long Duration time expires again and the1060 CDB is created by the newly active PGW.

It is possible that the CDB 1060 can become lost during failover due to a race condition between the Long Duration timer expiry and the failover process.

Note:  If failover happens at any other time (for example, at 9:05), then there is no race condition and the CDB is not lost.

Related Information

Updated: Feb 02, 2006
Document ID: 44280