In information critical systems such as a customer complaints center or a 911 center, incoming calls are monitored and recorded and saved for future use using a Call Monitoring and Recording Application. This paper investigates how CUAE can provide the ability to build such an application.

Use case#

An enterprise a.com has a customer complaints center which has 10 customer service representatives. The center has a toll free number and customers call in to the center using this number. The Communications server delivers the calls to the free agent. Based on few business logics, a decision is made to monitor/record an incoming call to a file. Occasionally, the conversation is mirrored to a 3rdparty mirroring/recording application to listen in real time and to store it in a different format.

Requirement Analysis#

Based on this use case, the requirements can be summarized as

1. Require the ability to monitor calls

2. Require the flexibility of deciding which calls must be recorded

3. Require the ability to store the RTP stream in multiple formats

4. Require the ability to start monitoring mid way in a call

5. Require the ability to use a variety of recording systems to record that use variety of protocols

High Level Design#

Based on these requirements, CUAE appears to a perfect fit to build such an application that will provide the required functionality.

The High Level Life cycle#

The high level life cycle of such a call would involved the following steps

1. Receive the incoming call and extend it to the application through CUAE

2. Making the decision in the application if we are interested in monitoring the call

3. Monitoring the call voice stream

4. Recording/Mirroring the voice stream

CUAE provides multiple options to build such a solution. It provides actions such as record using its own internal components in addition to the flexibility to integrate with external functionality.

The Application Flow#

The application flow will include the following steps

1. An external user makes a call and the Incoming Call arrives at the CUCM.

2. The CUCM matches the route pattern and forwards the call to the CUCM using either SIP trunk, H323 gateway or CTI route point

3. An Incoming Call event triggers the application in CUAE and the Monitoring and Recording App gets started

4. The application makes the decision to monitor the call based on its business logic

5. If the application decides to monitor the call, the application creates a Media Engine connection and uses a CTI port to make a call to the built in bridge on the Agents phone

6. At this point, the RTP traffic between the two phones also starts to flow from the BIB on the agents phone to the ME connection.

7. The application invokes the Record action to record the RTP stream to a file

Mirroring RTP Traffic#

If the application is interested in mirroring the RTP stream in addition to recording to a file, follow all the steps above and add the following steps in your application

1. The application requests the 3rdparty mirroring/recording device/application to open a RTP port where the RTP stream must be sent.

2. The application creates a conference on the Media Engine and adds the two connections: the connection from the BIB to the media engine and the connection from the 3rparty mirroring/recording device.

High Level System Architecture#

CUAE provides multiple options to use in terms of protocols and configurations. The diagram indicates the high Level System Architecture of such a solution.

Implementation Notes#

CUAE provides multiple options to build such a solution. We will consider few of these cases.

Extending the incoming call to CUAE#

The incoming call can be extended to the CUAE using first party or 3rdparty call control. CUAE provides the choice of SIP, H323 or CTI for the first party call control and JTAPI for third party call control.

The choice can be made to use active involvement of CUAE in the call or passive involvement of CUAE in the call. There are advantages and disadvantages of either option.

Active Vs Passive Involvement of CUAE#

Passive Involvement of CUAE//#

When a call comes in to the system to an agent's phone, the JTAPI 3rdparty events are used to extend the call to the CUAE. This uses 3rdparty APIs

Advantage://

If CUAE is down, this setup will not affect the original call.

Disadvantage://

The devices must be CTI monitored. (Registered with a monitored device pool)

Active Involvement of CUAE//#

When a call comes in to the system, the call is routed to the CUAE as a first party call. A protocol such as SIP, H323 or JTAPI can be used. CUAE is involved in the call and the routing is based on the pattern.

Advantage://

The devices do not have to be monitored for this phase. This is better in terms of scale.

Disadvantage://

If CUAE is down, this setup will affect the original call

Protocol Choices#

Using SIP trunks//#

SIP trunks can be configured from the CUCM to the CUAE to extend the calls that match a particular route pattern. An incoming call will generate a Metreos.Providers.CallControl.- IncomingCall event.

Using H323 Gateway//#

H323 Gateway can be configured between the CUCM and the CUAE to extend the calls that match a particular route pattern. An incoming call will generate a Metreos.Providers.- CallControl.IncomingCall event.

Using CTI Route point//#

CTI Routepoints are virtual devices that can be configured between the CUCM and the CUAE to extend the calls that match a particular route pattern. CTI Routepoints use first party JTAPI call control. An incoming call will generate a Metreos.Providers.CallControl.- IncomingCall event.

Using JTAPI monitoring of phones//#

The agent phones can be monitored using JTAPI 3rparty APIs. An incoming call to a phone will generate a Metreos.CallControl.JTapiIncomingCall event.

Triggering the CUAE Application#

CUAE can have multiple applications registered with it. The intended application can be triggered using the appropriate triggering event. In this scenario, the obvious choices would be

1. JTapiIncomingCall

2. IncomingCall

In addition other events can be considered depending on the need of the application. For ex. If the application needs to be triggered to monitor a call mid way, it could be triggered using a HttpGotRequest.

Making the decision if we are interested in monitoring the call#

Once a call arrives at CUAE, the appropriate application must be triggered which will make the decision if we are interested in monitoring the call.

Monitoring all calls Vs Selective calls#

CUAE provides the flexibility to choose if all calls must be monitored or a selective set of calls must be monitored.

The choice of deciding if we want to do selective monitoring can be accomplished in two ways:

1. Filtering at the CUAE level: Applications can add triggering parameters that would dictate when the application is triggered.

2. Filtering at the Application level: Once the application is triggered, the application can use its own business logic to decide if it is interested in monitoring the call.

Example:// The application can use the 'from' number to lookup an interested set of numbers to start monitoring the call.

Triggering Events#

CUAE can have multiple applications registered with it. The intended application can be triggered using the appropriate triggering event. In this scenario, the obvious choices would be

3. JTapiIncomingCall

4. IncomingCall

In addition other events can be considered depending on the need of the application. For ex. If the application needs to be triggered to monitor a call mid way, it could be triggered using a HttpGotRequest.

Adding Trigger Params//#

Trigger Params can be used to trigger specific application. For example, if calls coming to a specific device needs to be monitored, the trigger param DeviceName can be used.

Monitoring the call voice stream#

Once the decision has been made to monitor the call, the applications invoke StartMonitoring JTAPI 3rdparty API to monitor the calls.

There are few configurations that are required for this functionality on the CUCM and the CUAE. There are terminal restrictions for this feature.

On the CUAE side, the device must be added in the monitoring device pool. This can be done in multiple ways and is documented in the configuration section.

Recording/Mirroring the voice stream#

CUAE provides the ability to record and mirror the RTP streams. It provides actions such as Record using its own internal components. In addition, it provides the flexibility to integrate with external applications using multiple protocols.

Recording Options#

Using CUAE Media Engine Record action//#

The Media Engine component of the CUAE provides a Record option to record the RTP stream to a file.

Using 3rdparty Recording Solution//#

CUAE provides the flexibility to use a 3rdparty recording application that supports either an API or a standard protocol such as SIP.

Mirroring to another RTP port on a different application#

CUAE provides the flexibility to create conferences and mirror the RTP traffic to another application that is interested in the RTP stream at the same time when the traffic is being recorded to a file.

Example:// A real time RTP traffic analyzer

Configuration#

Adding Agent phones for monitoring#

Application can add agent phone for monitoring using multiple options provided by CUAE. These include:

1. Adding the phones to a monitored device pool manually through the cuaeadmin

2. Adding the phones from the application using JTapiNonTroggeringSubscribe

3. Adding the phones from the application using the management service API

CUCM/Terminal Prerequisites#

The Silent monitoring feature requires few prerequisites

1. The CUCM version must be 6.0 and above

2. The Agent Phones must have a Built In Bridge

3. The BIB must be turned on for the device

4. The Monitoring calling search space must match for the Initiator (CTI port) and the agent phone

Contact Information#

For questions, please send an email to cuae-developers@developer.cisco.com

The discussion archives can be found at http://developer.cisco.com/web/cuae/forums

Sample reference application#

Coming Soon...