This document describes Network Based Recording’s (NBR) different scenarios and it's troubleshoot.
Cisco recommends that you have knowledge of these topics:
Cisco Unified Communications Manager (CUCM) version 10.0(1) or later
Phone-based recording architecture
Network based recording architecture
The information in this document is based on these software and hardware versions:
Cisco Call Manager version 10.5
Customer Voice Portal ( CVP ) version 10.5
Cisco Unified Contact Center Express (UCCE ) 10.5(2)
Gateway 3925E 15.3(3)M
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.
Network based recording is available as of CUCM, Release 10.0(1) and allows you to use the gateway to record calls.
The feature allows to record calls regardless of device, location, or geography such as calls extended off-network to mobile and home office phones. It automatically selects the right media source based on call flow and call participants.
It is important to understand that:
SIP signalization is from CUCM to CUBE and from CUCM to the recording server.
There is no direct SIP signaling between the recording server and CUBE.
CUBE is responsible for forking the RTP stream to the recording server.
The recorded endpoint on CUCM does not need to support Built in Bridge (BiB).
CUCM uses HTTP to initiate the call recording request to the Cisco Unified Communications (UC) Services API on CUBE. The Cisco Unified Communications (UC) Services API provides a unified web service interface for the different services in IOS gateway. One of those services is the Extended Media Forking (XMF) provider that allows applications to monitor calls and trigger media forking on Real-time Transport Protocol (RTP) and Secure RTP calls.
How Mobile Agents Work
Caller A on Communication manager express (CME) dials B, which points to Gateway (GW). GW dial peer points to Customer Voice Portal (CVP).
CVP sends a route request to Intelligent Contact Manager (ICM), and ICM returns the Mobile Agent label, which is Local CTI port (LCP port ) Dialed Number (DN).
CVP sends invite to CUCM. While the LCP port rings, the JTAPI Gateway (JGW) instructs CUCM to call agent phone from Remote CTI port (RCP ) DN .
Once the agent answers, the agent leg is connected to Music-on-Hold (MoH).
JGW instructs CUCM to answer the inbound call that rings on the LCP port.
Once the LCP leg is connected, JGW instructs CUCM to retrieve the agent leg.
JGW passes on the Real-Time Transport Protocol (RTP) IP address/port details from the customer leg to the agent leg and vice versa.
CUCM bridges the two legs and establishes the RTP path between the agent and the customer.
How Recording Works in Case of Mobile Agent
In case of Mobile Agents, recording can be enabled either on LCP Port or RCP port.
Once call is connected on LCP or RCP and recording is enabled , CUCM sends 2 Invite to recording Server for near end and far end device.
Once signaling is completed for the near end device and the far end Device SDL HTTP request is sent to the gateway to instruct it to Start recording.
Note: There can be scenarios where CUCM does not have a direct SIP trunk with Gateway or with CVP
Note: For instance, CUCM can have a SIP Trunk with a Proxy server ( CUSP ) controlling all the traffic flow
Note: If recording is enabled on CTI port and call is landing on that port, Recording will work.
Note: In case of mobile agents, CTI ports do facilitate signaling and then are out of the RTP flow. It is the end points between which RTP will flow. But LCP and RCP port never go out of the signaling. Their Ci ‘s are never destroyed till the end of the call. This is the reason recording is successful on LCP or RCP port even if the RTP does not flow through them
UCCE Deployment With CUSP ( Proxy Server )
With UCCE deployed with CVP and CUSP with the so-called comprehensive model, there are no SIP trunks between CUCM and the CUBE(s). All communication between CUBE and CUCM goes via a single SIP trunk to CUSP.
CUCM needs a way to know from which CUBE the call is coming, so that it knows where to send the recording requests. This is achieved by sending the request back to the destination IP of the incoming SIP trunk that was used for the call. However, if CUCM sends the API request back to CUSP nothing will happen. To work around this limitation in environments with CUSP, the following CUCM configuration needs to be implemented:
Create dummy SIP trunks to each CUBE. This trunks will not be used to route any calls!
Re-classify the incoming calls on the CUSP SIP trunk to the correct dummy CUBE trunk using the Call-Info header.
Note: This setting does not affect any call processing decisions - all call processing and call class of service decisions will be done as if the call is still on the CUSP SIP trunk and no SIP messages will be sent to the destination of the newly matched trunk.
Note: The x-cisco-origIP value in the incoming INVITE must match the destination IP address a dummy trunk.
Note: To have a correct value for the x-cisco-origIP header, it must be correctly set on the originating CUBE. Setting the value can be achieved by adding the header on the CUBE, but also by adding it on CVP. The UCCE Direct agent script already uses on the Call-Info header. Therefore, a second Call-Info header with the required x-cisco-origIP will be added after the Call-Info header for the Direct agent script. Tests showed that CUCM will still do the required re-classification when the x-cisco-origIP is contained in the second Call-Info header of the SIP INVITE.
Key Configuration Points for UCCE deployment with CUSP :
Create a SIP Trunk Device for a Recorder
To provision a recorder as a SIP trunk device, a Unified CM administrator creates a SIP trunk device from the device page, and enters the device name and the IP address of the recorder in the Destination Address field.
Create Call Recording Profiles
To provision line appearances of agents for call recording, one or more call recording profiles should be created. A recording profile is then be selected for a line appearance. To create a recording profile, a Unified CM administrator opens Device Setting page and select Call Recording Profile. In the Recording Destination Address field, the administrator enters the DN or the URL of the recorder. In the Recording Calling Search Space field, the administrator enters the partition of the SIP trunk configured for the recorder.
Provision a Dummy SIP Trunks to each CUBE
For each gateway that needs to fork calls to the recording server a dedicated dummy trunk on CUCM must be configured. Remember that this trunk is not used for any real SIP signaling and does not influence any call decisions. The important things to configure are :
This trunk connects to a recording-enabled gateway.
The destination IP must be the same on which the CUBE is configured to listen in its XMF configuration
Provision Route Pattern for the Recorder
To provision the route pattern for the recorder, the administrator opens the route pattern configuration page and enters a route pattern based on the recorder DN. The administrator selects the SIP Trunk device for the recorder, and then saves the route pattern. If the recorder address is given as a SIP URL and the RHS of the URL does not belong to Unified CM cluster, a SIP route pattern should be configured. The pattern field should be the domain or ip address of the recorder (the RHS part of the recorder URL) and the SIP Trunk field should be the SIP trunk for the recorder.
Provision Recording Calling Notification Tone Option
To provision the cluster wide service parameter for Recording Notification Tone, the administrator opens the Unified CM Administration’s Service Parameter page and locates the entry for Play Recording Notification Tone to Observed Target. The administrator enters Yes or No. The administrator then locates the entry for Play Recording Notification Tone to Observed Connected Target. The administrator enters Yes or No.
Provision the CUBE XMF Provider
These configuration enables the HTTP communication and the XMF provider configuration :
Provision the CUBE SIP Profiles for Call-Info Header
In order to have a correct value for the x-cisco-origIP header care must be taken to set it correctly on the originating CUBE. Setting the value can be achieved in multiple ways and also it is not necessary to be done on the CUBE, for example, it can also be set on CVP. This is an example SIP profile that statically sets the x-cisco-origIP value in the outgoing INVITE from CUBE to CUSP.
If the UCCE system already relies on the Call-Info header, then a second Call-Info header with the required xcisco- origIP. Tests showed that CUCM will still do the required re classification when the x-cisco-origIP is contained in the second Call-Info header of the SIP INVITE. The same tests showed that the other systems however stop working if the new Call-Info header is put first. That profile needs to be applied to the outbound dial-peers that point to CUSP.