Mobile agent Recording - UCCE

[Okechi Awujo]

I configured mobile agent on UCCE/Finesse, agents can log in ok and take calls. However i can not get the calls to be recorded. i configured call recording on the DN of the LCP  ( see attached) any help will be appreciated 

[Chris Deren]

What solution do you use for recording?

Your title mentions this is mobile agent, does agent login onto a VPN Cisco phone or using mobile agent and logs onto their home phone, mobile, etc?

[Okechi Awujo]

Mobile Agent.. so they log into finesse select the mobile agent button enter their mobile phone number.. we use verient for call recording. Calls record ok for non mobile agents ..

[Chris Deren]

Call recording of mobile agents has specific requirements, it requires SPAN recording where the ingress and egress voice gateways need to be separate. This is documented in the UCCE and/or CVP SRND documents.

[jc12]

Replying to an old post but it's related......

Looking to try to implement this in our environment.  I have looked at the Design document for 10.5 and I don't see anything related to separate gateways being needed.

Under the recording section this is what I find....

"

Cisco Packaged CCE supports MediaSense for audio recording. However video recording and playback is not supported.

Packaged CCE supports both of the following:

          Unified Communications Manager-based (Built In Bridge)—preferred. This requires a third-party Recording Server.                      SPAN (Silent Monitoring Server) for Mobile Agent.

"

For my setup currently I have calls coming into my CUBE to CVP.

CUCM I have LCP and RCP setup and recording enabled on both of them.

Well my current setup is not recording.... I don't care about silent monitoring.  I don't have a sip proxy in my environment.

Can someone please provide the document that states to use two gateways for mobile agent recording.  Maybe I'm overlooking it.

thanks.

[bill.king1]

I know you said you don't care about silent monitoring, but to my mind, if you're trying to silent monitor and/or record from UCM, you would run into the same restrictions? The 10.5 guide says UCM silent monitoring is not supported:

Silent Monitoring

Unified Mobile Agent provides the following silent monitoring support:

• Mobile Agent supports CTI OS server-based silent monitoring only. Unified CM-based silent monitoring is not supported

This is changed in version 11 as Chris mentioned earlier:

Silent Monitoring

Unified Mobile Agent provides the following silent monitoring support:

• Unified Mobile Agent requires that caller and agent voice gateways be on separate devices if silent monitoring is to be used.

[Anoop Krishnan]

Hi Okechi, 

Please follow this document for enabling Call Recording for Mobile Agents 

Call Recording for Mobile Agents

Regards, 

Anoop

[KT4RJN]

I have followed the documentation for setting Extended Media Forking up on CUCM and CUBE. I have been unable to get a forking call setup. I show the registration for all five CUCM servers in the XMF config. The LCP port is configured for the new XMF Recording profile, and Gateway Preffered. I see no evidence of the CUBE receiving instruction from CUCM to Fork the call with the Recording server.

Thanks in advance for any assistance.

[ahmed.zakaria]

Configuration

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.

[Konstantin Vaksin]

Hello.

Please watch out with call recording in case of call transfer. You might need to consider to record LCP port instead of RCP

Kostia

[ahmed.zakaria]

Provision the CUBE XMF Provider

These configuration enables the HTTP communication and the XMF provider configuration :

CUBE001 :

ip http server
no ip http secure-server
ip http max-connections 1000
ip http timeout-policy idle 600 life 86400 requests 86400
ip http client source-interface Port-channel20.307
uc wsapi
message-exchange max-failures 2
source-address 10.106.230.20
probing interval keepalive 5
probing max-failures 5
!
provider xmf
remote-url 1 http://10.106.97.140:8090/ucm_xmf
remote-url 2 http://10.106.97.141:8090/ucm_xmf
remote-url 3 http://10.106.97.143:8090/ucm_xmf
remote-url 4 http://10.106.97.144:8090/ucm_xmf

CUBE002:

ip http server
no ip http secure-server
ip http max-connections 1000
ip http timeout-policy idle 600 life 86400 requests 86400
ip http client source-interface Port-channel20.307
uc wsapi
message-exchange max-failures 2
source-address 10.106.230.20
probing interval keepalive 5
probing max-failures 5
!
provider xmf
remote-url 1 http://10.106.97.140:8090/ucm_xmf
remote-url 2 http://10.106.97.141:8090/ucm_xmf
remote-url 3 http://10.106.97.143:8090/ucm_xmf
remote-url 4 http://10.106.97.144:8090/ucm_xmf

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.

---
voice class sip-profiles 666
request INVITE sip-header Call-Info add "Call-Info: <sip:10.106.242.27>;PURPOSE=x-cisco-origIP"
---

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.