Administrative Workstation subprocess in UCCE

The administrative workstation (AW) provides the systems administrator with an array of
configuration tools to manage and maintain the UCCE platform
The most popular AW deployment is the AW-HDS-DDS.

The logger holds the database used by the central controllers, but rather than this database
being modified by the client applications, the configuration tools actually modify a
copy of the configuration data stored in the local database on the AW. When changes are
made in this database, the AW processes communicate with the loggers to instruct them
of the change.As well as containing a copy of the configuration data, the AW database also contains
data used for real-time reporting. Although this data is described as real-time, in practice
it should actually be termed “near real-time” as the data is updated approximately every
10–12 seconds.


Below are the database that are present in the mentioned deployment:

<instance name>_awdb: Used for storing UCCE configuration and real-time data
<instance name>_hds: Used by the HDS processes for long-term historical data storage
<instance name>_wv: Used by WebView for storing WebView-specific configuration

Where the instance-name is the customer instance name

The AW consists of many software processes:

 configlogger: The Configuration Logger process stores configuration data in the AW
database.

 replication: The Replication process receives historical data from the logger and
inserts this data into the HDS database on the AW.

 rtdist: The Real-Time Distributor receives real-time data from the router and distributes
this data to all the real-time clients that are connected to it. These clients can be
other AWs, typically a client AW.

 rtclient: The Real-Time Client on the AW is responsible for updating the local AW
database. The rtclient gets its data from the rtdist process.

 updateaw: The UpdateAW process ensures that the local AW configuration database
remains current with configuration data from the central controller.

Different subprocess in Peripheral Gateway

The PG provides an abstraction layer between the peripheral (usually an ACD or IVR)
and the UCCE central controller. With UICM and UCCH, the supported peripherals can
be from many vendors, but with UCCE, the peripheral that provides call control for the
agent devices is the Unified CM, with Cisco Unified IP IVR or Cisco Customer Voice
Portal (CVP) providing IVR and call queuing.
Similar to the router and logger nodes, the PGs are deployed in a duplex manner, but
their physical location varies depending on the deployment architecture used. Typically,
the duplex PG pair will be deployed at the same location as the ACD. For example, in a
distributed call processing model using two or more independent Unified CM clusters, a
duplex PG pair would be deployed at each of the sites coresident with the Unified CM
cluster. This rule is true for all deployment models with the exception of the Clustering
Over the WAN model. With this deployment model, the Unified CM cluster is typically
split over two sites. Each site contains one side of the UCCE central controller, including
a PG.A single PG pair can service more than one peripheral. In typical UCCE deployments, the
PGs usually service both the Unified CM cluster and the IVRs, but for larger deployments,
dedicated PGs can be used.ACD PGs, including Unified CM PGs, also have the CTI Server process and, if required,the CTI OS Server.
The type of ACD being deployed reflects directly on the different PIM process installed.
UCCE uses the Enterprise Agent PIM (eagtpim) process, which is named after a remote
agent component used in early versions of UCCE that allowed agents to work using analog
cards installed in their PC rather than being connected to an ACD. This feature was
withdrawn from UCCE a long time ago.
The PG node processes are as follows:

mdsproc: The Message Delivery Service : The Message Delivery Service (MDS) process manages message delivery between the processes running on the PG.

opc-cce: The Open Peripheral Controller is the heart of the PG. The OPC is responsible
for synchronization with the other PG as part of the PG pair and prepares the call records for the UCCE database.

pgagent: The Peripheral Gateway Agent (PGAgent) manages the session layer communication between the PG and the ccagent process running on the router. When
deployed as a duplex pair, the pgagent process window displays with which side of
the central controller router it maintains an active connection. If the process windowdisplays InSvc A:Active B:Idle, you could determine that pgagent has an active connectionwith ccagent on Router A; therefore, only heartbeat traffic is being sent to Router B. Router-side preference is configured during PG setup. The PG can be configured to have preference as Side A, Side B, or no preference. This preference is typically used to engineer traffic routing when the PGs are deployed remotely from the central controller but is also used during failure scenarios. Should the preferred side go offline, the nonpreferred side will take over. When the preferred side comes back online, the active side will switch back again. This switchback does not occur if the PGs are configured with no preferred sides.

testsync: The Testsync process provides an application interface for the various test and debugging tools to connect to.

jtapigw: Many third-party applications communicate with a Unified CM cluster using
a Cisco-proprietary JTAPI. For the Jtapigw process to function, the Cisco JTAPI
driver needs to be installed on the PG. Cisco JTAPI is available from the Plugins page
on the Unified CM servers. You should ensure that the version of JTAPI installed on
the PG is the same version of JTAPI available from the Unified CM server.

eagtpim: This is the Enterprise Agent PIM process that connects to the jtapigw
process required for connection to a Unified CM cluster.

ctisvr: The Computer Telephony Integration (CTI) server process is installed on PGs,
where the peripheral communicates real-time agent data to the PG and the agents use
a CTI-enabled desktop application to inform the PG of agent state changes and information including CTI data (wrap-up codes, reason codes, and call data updates). The ctisvr process communicates with the OPC process running on the PG. Throughout
early versions of UICM, the CTI Server provided the native connection to all agent
desktop applications and third-party applications that required real-time data such as wallboards and call recording, where data tagging is used. To support developers and make the solution more scalable, Cisco developed the CTI Object Server (CTI OS) and requested that all CTI applications developed now be against CTI OS rather than the CTI Server.

ctios server: The CTI OS Server process establishes a connection to the CTI Server
process and provides an interface for desktop and third-party applications to develop nagainst using the CTI OS Toolkit. The ctios server also establishes a connection to its duplex pair to provide resiliency. The title bar of the CTI OS process window displays the IP address and port of the active CTI Server it is connected to. It also displays the IP port that the process is listening on. An example of this display is [ACTIVE, CG 192.168.15.30, CGPort 42027, Listen Port: 42028].

vrupim: The Vrupim process is the PIM for IVRs connected through the GED125
specification. It is common for deployments with multiple IP IVRs to have several
Vrupim processes running on the same PG.

Different subprocess in Cisco ICM Router

Router is the main brain of the UCCE system. The configuration data get stored in router memory and also it has knowledge of the real time data .It get data from PG.As this is the brain of the UCCE system it take the routing decision based in the data it has got from PG, its stored configuration ,routing scripts .

The Router has below process:

router: This process is used by the UCCE to provide the route response and manage the route request.This process also collect all the real time data and maintain a holistic view of the contact center.

ccagent:  This process is used to communicate with the PG and the status bar of the sevice can show you how many PG it is connected to

dbagent: This process  is used to check communication between the router and the logger by validating access to central controller database

mdsproc:  This process  is used to manage reliable message delivery between different  UCCE process

testsync : The testsync process provide application interface for connection to various test and debugging tool to connect to

Logger Process in ICM

Logger component of ICM is the component that  store the configuration of the UCCE in its database.
Along with the configuration it store the Historical data  for 30 Days .It also store the the real time data, call variable, routing scripts etc.

The logger process can work in a duplex  environment.

there are various subprocess under the logger .

Let discuss the process one  by one

configlogger process: The configlogger process is used to store the configuration data in the central controller database 

csfc process: Cusromer suppport forwarding service(csfs) process is  use to monitor the connection between the logger and router using regular heartbeat

histlogger Process: This process is used to store historical data in the central database

recovery process: This process is used to synchronize the historical data  from the most recent logger database in case there is a fallback scenario comes in .The recovery process the happen with a process called state transfer

replication process:  This  process syncronize the historical data from the central controller database to historical database

No Dial Tone and the "High Traffic Try Again Later" Error Message Appears

If you get a message on your phone LCD screen  "High Traffic Try Again Later"  with no dial tone you can try  the below solution:

Solution:

The High Traffic Try Again Later error message that appears on the IP Phones indicates this issue:

Whenever the LowPriorityQueueThrottlingFlag Cisco CallManager service parameter is set to TRUE and the Low Priority queue is over the limit specified by the LowPriorityQueueThrottlingMaxCount Cisco CallManager service parameter, the High Traffic Try Again Later error message appears on the LCD display of any IP Phone that is registered to this Cisco CallManager server and that attempts to go off-hook and make a new call. By default, this message appears on the phone if the Low Priority queue gets deeper than 20 signals.

Generally, the Cisco CallManager works fine as long as the Low Priority queue does not get higher than 100. Therefore, if you never see the Low Priority queue go higher than 75, you can configure the LowPriorityQueueThrottlingMaxCount = 100 Cisco CallManager service parameter in order to overcome this issue.

Monitoring UC device using Cisco prime unified operation Manager

Monitoring a UC component is very much essential as this provide the core communication infrastructure in the Enterprise.

Cisco has CUOM to monitor and send notification if any alert happen to the services.

To configure you need to have the device in CUOM device summary under monitored device
if it is not discovered automatically or you can manually the device .(You need to have SNMP string you defined in  UC Server like CUCM and use the same here while adding )

Once the device is in monitired state you can configure to send an alert via email notification.

First step is to do the SMTP configuration in the CUOM Portal to acheive this Go to System >Miscellaneous >Preferences  and mention the SMTP server adddress.

Now move to Administration > Notification >Eventset

Mention the alert which trigger the Event ,There are pre defined event that you need to group to configure an Event set

Now move to Administration > Notification > Notification Criteria

Define the Criteria and mention all the parameter and also follow the wizard to mention the alert notification recepeint IP address (This option will display when you select the email option for notification)

done...

You need to check CUOM is able to connect to SMTP using port 25 .

Basics of Cisco Unified Border Element

Now a days SIP service are growing and the  service provider are providing SIP as  a service.These services can be terminated for a enterprise on a SBC/CUBE .
The CUBE has many benefit over traditional TDM circuit etc.

The benefit are

Interoperability : SIP is a protocol supported by many vendor  hence these can be deployed with different SIP solution

Demarcation Point : CUBE can be used as a demarcation point between PSTN and enterprise network

Encryption and security is also a part of  CUBE,you can use CUBE to hide the IP address of the CUCM 

To achieve the redundancy the SIP has more flexibility compared to Traditional Telephony.

CUBE can be deployed in two mode:

Media flow around : in case of media flow around  the CUBE doesn't comes into media path

Media flow through  : In case of media flow through the CUBE comes into media path

The command can be configured under dial-peer config using the command :

media flow-through|flow-around

CUBE can be used for media codec negotiation as well when the service provider link is terminated on the cube.
You can configure the media negotiation mode by configuring the below command under dial-peer
codec transparent

The above command define that the CUBE will not be part of any codec negotiation . if this command is not there then CUBE take part in codec negotiation

apart from then you need to configure allow-connection under voice service voip command

You can verify SIP calls in the CUBE using the command

show sip calls
show voice call status
show voip rtp connection
show call active voice

debug command used to debug dial peer

debug dialper voice inout

Call disconnect issue on MGCP on muted phone

Just want to share one incident with a customer and from that i came to know about this feature of MGCP gateway.
The problem we are facing is when the phone kept in mute stage for a long time it gets disconnected .

to resolve this feature put the below command in mgcp gateway and it resolved the issue .

no mgcp timer receive-rtcp

This command basically define how (method)  to detect a RTCP stream  for a MGCP call

CME configured as SRST fallback in MGCP mode

Cisco CME can be configured in SRST mode and is better option than normal SRST.CME in SRST support more feature compare to normal SRST and support less phone compared to CME as SRST

The configuration is pretty simple ..

For MGCP fallback you need to configure

ccm-manager fallback-mgcp

Then configure the below command to fallback to H323 in case of failover:

global
  service alternate DEFAULT

Then configure the SRST fallback in CME

telephony-service
srst mode auto-provision none

 srst ephone template 3  // Define the default template to be used for phone if the phone is not previously added in the configuration

srst dn template 2  // Define the dn template to be used for the phone if the phone is not previously added in the configuration

Define the dn line mode

srst dn line-mode dual

max-ephones 58
 max-dn 100
 ip source-address <CME port ip > port 2000 // Ip will be the one that phone will communicate for sccp


Verification command:

show telephony-service
show ccm-manager fallback-mgcp
debug ephone details
show telephony-service
show telephony-service ephone
ip tcp adjust-mss
session transport tcp

Blocking calls based on time and pattern

In CME we can provision it do the call routing based on time and the pattern.
These kind of scenario came when you want to block some special pattern on out of office hour or permanently.

First you need to define out of office hour schedule and then need to define the out of office hour pattern and apply those pattern to either ephone-dn,globally in telephony-service.

The limit is 100 block pattern .

The command to configure this is "after-hours block pattern pattern-tag pattern".
This command is used to configure the pattern 1800XXXX for after hour blocking "after-hours block pattern 3 1800.... "

You can define the after hour time under the telephony-service command using the command .

"after-hours day day start-time stop-time "

"after-hours date month date start-time stop-time "

You can also define few ephone or ephone-dn an override from the after hour period so that they can dial pattern during after hour

The config would look like this  :

telephony-service
 after-hours block pattern 1 91
 after-hours block pattern 2 9011

 after-hours block pattern 3 91900 7-24
 after-hours day mon 19:00 07:00
 after-hours day tue 19:00 07:00
 after-hours day wed 19:00 07:00
 after-hours day thu 19:00 07:00
 after-hours day fri 19:00 07:00
 after-hours day sat 13:00 12:00
 after-hours day sun 12:00 07:00
!
ephone 23
 mac 00e0.8646.9242
 button 1:33
 after-hour exempt  // This will exempt  the ephone from the after-hour  config so that they can  dial during the after hour 
!
ephone 24
 mac 2234.1543.6352
 button 1:34

Survivable Remote Site Telephony ( SRST )

Survivable Remote Site Telephony (SRST) is a feature used in cisco IPT deployment to provide fallback in case the Remote site looses connectivity with the  CUCM cluster .

                     

The local voice gateway based on cisco IOS has the feature of providing local call agent functionality  once the gateway/remote site phones looses connectivity with the CUCM .


We can deploy SRST based on different protocol (MGCP,h323 and SIP).

The MGCP fallback uses h323 configuration as a default protocol
Also there are various mode of deployment of srst  like with CME as SRST or normal SRST .

Here are the various options for deployment of SRST .

1. Call-Manager-Fallback : This option is used basic deployment of SRST and have very limited feature to use. Also the use is very limited.The config of the phone are fetched using SNAP from the Phone itself

2.  Telephony-service with auto provision none : This option uses the CME router as SRST and if we used the telephony-service option with auto provision as none in that case the snap discovered the phone config and store the phone config in the ios running config .However the ephone-dn and ephone config is not visible in the router running config and hence customization cann't be done .

3. Telephony-service with auto provison dn : This is same as "Telephony-service with auto provision none " only difference is  that in this case the ephone-dn is visible in the route running config .

4.  telephony-service with auto provision all  : This is same as point number 2  and only difference is in this deployment both the ephone and ephone-dn is visible in the route ios running config .This method has more flexibility as the ephone and ephone-dn can be modified and also support maximum feature


Note : if you are using extension mobility with SRST then EM login will not work ,hence any new EM login will not be successful however existing login phone will continue to work

Paging configuration in Call Manager Express

Just came across a requirement from a customer for implementing paging in Cisco Call Manager Express       ( CME )

The config is pretty much simple .

First  you need to define a ephone-dn for the paging and need to define a multicast ip address for paging.
The config will look like this  :

ephone-dn  5
 description Paging
 number 1001
 paging ip 239.0.1.20 port 2000

one u have configured the ephone-dn.
Apply the ephone-dn to the ephone you have configured in CME .

ephone  1
  paging-dn 5
!  
!
ephone  2
  paging-dn 5

Once the user dial 1001 from any phone .It will establish a one side audio to all the phone for paging.