The information within this document defines the IPCC Enterprise state
that is held within the memory of the IPCC Call Router, which includes the type
of information it contains, the items that can account for its size, and the
affect that the size of the state can have on the call-routing
Technical Tips Conventions for more information on document
What is the ICM state size and what components contribute to its growth /
A. The state is held within the memory of the ICM Call Router and is
somewhat related to the size of the overall ICM configuration, but what is
contained within the state is more than configuration. The Call Router loads
the ICM configuration from the Logger database and holds that configuration
within memory. If the environment were not active or able to route calls and no
further activity occurred, the state size on the ICM Call Router remains fairly
small and constant.
As calls and tasks begin to be processed within the environment, the
ICM Call Router maintains certain pieces of knowledge about each item within
the configuration and uses that knowledge to make routing decisions and
populate real-time reports. These added pieces of information are also
maintained within the memory of the Call Router and added to the size of the
state. The state size is equal to the amount of memory that the Call Router
requires to allocate and hold all the information that it 'learns' about each
item within the configuration.
For example, for each service that the ICM Call Router has within the
configuration that it received from the Logger, this abbreviated list mentions
pieces of data that are maintained within the state (basically all real-time
When you consider state size, you also need to take into consideration
that this is true for every object within the configuration: Skill Groups,
Services, Trunk Groups, Scripts, Agents, LAA or MED values, etc. All these
items held within the configuration also have real-time data that the router
learns and holds within its memory. The state is updated constantly based on
information that comes into the router from PGs and NICs. Most of this
real-time data is passed out through the real-time feed, populated in the
real-time tables on the administrative workstations, and used for real-time
reporting. The more items in the configuration, and the more real-time data
there is about them, the bigger the state size grows.
Is it normal to see the state size fluctuate? At times it seems to grow,
but at other times it is back down to a smaller size,
A. Yes, this is normal behavior to see the state size grow as the memory
allocated to the state as required by the amount of real-time detail grows. The
amount of data that the ICM Call Router receives at the configuration from the
Logger database is only one part of what makes up the full state size. Many
other factors add to the size of the state because many other pieces of
information are held within the memory of the Call Router in order to complete
the tasks associated with intelligent call routing and real-time reporting. As
activity within the environment changes and tasks are processed, so does the
state size change.
For example, when the initial load of configuration and state is sent
to the Call Router, information about configured agents is included.
Information about those agents is updated by each peripheral as to which skills
the agents are logged into. This data is held in the real-time data for
SkillGroupMembers. If those agents are then reskilled to another skill group,
the original data for that agent skill assignment still exists within the state
of the Call Router, and the new skill assignment is also added. The information
for the original skill assignment of the agent is kept within the Call Routers
state in order to complete real-time reporting for that agent. Since
information about the skill assignments of this agent is now increased, the
memory required for the Call Router to hold that data is also increased, and
the state size grows larger.
Note: This is only one example of how the state can require the memory
allocation for real-time state data to also increase; other types of data can
also cause the state to grow in this manner.
Is there a maximum supported limit for state
A. State size is affected by configuration size and changes, as well as
call volume and activity, such as agent reskilling. Because of this fact, it is
impossible to predict the size of the state based on the size of the
configuration within the Logger database, and it can grow larger in some
environments more so than others. Cisco does not dictate any specific limits to
the upper bounds of the state size for any one customer environment, but at
1500MB a customer is faced with these considerations:
The 32-bit Microsoft Windows machines limit the memory per-process to
2000MB. If the state size exceeds 1500MB, it can exceed the Microsoft Windows
Longer time is taken to complete state transfer across the private
Increased memory usage and CPU utilization on the call routers and
administrative workstations: there must be enough physical memory to support
the state size. On modern hardware, with 2-4GB of memory, this is seldom an
There is the necessity to provide more bandwidth and speed over the
private network to facilitate the state transfer, as well as over the public
network to facilitate data transfer to and from peripheral gateways and
administrative workstations (*see note below).
Increased buffer utilization is needed for processes, such as the
RTServer, RTDistributor, and RTClient on the Administrative
Increased buffer utilization for is needed for processes, such as
PGAG and CCAG between the peripheral gateways and Call Routers.
Increased size of the AWDB database can be necessary to accommodate
an increased amount of real-time data.
*The private network between sides must be able to transfer the state
in a reasonable amount of time. A brief outage can be expected within a state
transfer as the state is prepared to be sent. This is typically several seconds
on a large state size. Within this window, calls can be default routed.
How is call processing performance affected by a large state size on my
ICM Call Router?
A. State size does not generally affect router performance in terms of
call-per-second or response time in handling a call. The only performance that
affects a scenario, given a large state size, is related to the network speed
and resources required to perform a state transfer or to pass the real-time
information back down to devices within the environment (peripheral gateways
and administrative workstations) or in situations where the memory required by
the process exceeds the Microsoft Windows 32-bit limit of 2000MB.
The ability of the ICM Call Router to respond to inbound route requests
and provide labels / intelligent routing decisions is not affected by state
size. Currently most IPCC Enterprise customers operate successfully with state
sizes in the 300-500MB range.
Do I need to evaluate higher specs for my hardware given a particular
A. Recommendations for server sizing and capacity are outlined within the
and System Software Specification for Cisco Unified ICM / Unified CC Enterprise
& Hosted Editions, formerly know as The ICM Bill of
Materials. Within this guide are the sizing requirements for low and
high-end deployments. As long as the state size is well below the Microsoft
Windows 32-bit limitation, there is no need to increase capacity or
specifications for hardware above those outlined within this document.
I see a warning message that states, "The router's state size of 31 MB
has grown beyond the alarm limit of 30 MB." What does this event mean, and do I
need to take action when I see this message?
A. This message is informational. The number that is reported comes
directly from this registry value and does not affect performance.
Registry Value Location = /Router/CurrentVersion/StateTransfer/StateSizeThresholdMB.
Refer to the
Does the ICM Event "The router state size of 31 MB has grown beyond the alarm
limit of 30 MB" Mean? tech tip for further explanation of this