I currently have this open with TAC via SR 687172665, but they have been unable to dedicate time to this issue over the last few days.
I may requeue it this weekend, but have tried to be patient to get the best answers.
We are currently using SPAN recording for our Mobile Agents' nailed connections. It is capturing each individual customer call as intended.
We are migrating from TDM DS-3 connections over to SIP Trunks from our Carrier. As part of this migration, we must change SPAN recording to a recording model that works with CUBE and with Mobile Agents (LCP and RCP). We had originally planned to use SIPREC after discussions with our VAR and Calabrio. However, once configured we found that SIPREC would only record the RCP (The entire nailed connection) instead of the LCP (individual customer calls going over nailed connection) calls.
After some further research I found these documents to follow to configure Extended Media Forking (XMF) at the CUBE, controlled by CUCM.
We have two CUBEs for the SIP Trunking, in separate Data Centers, but are not configured for CUBE HA. These are used for redundancy, but not setup with CUBE HA. I am configuring our Site A CUBE first, and once it is working, will implement the same config on Site B CUBE. We will ensure RCP and LCP ports are registered to CUCM subscribers local to the CUBE which is primary in their dial plan.
The trouble we are running into is that the CUBE doesn’t seem to be receiving instruction from the CUCM to fork the call. My VAR, as well as Cisco TAC has confirmed my configuration. Cisco TAC did advise us to route the calls to be recorded over the referenced “Dummy Trunk” to the CUBE. Making this change has provided no change in results.
I have attached CUCM logs and CUBE Debugs for my most recent test call. No configuration changes have been made since.
Call Time 4:31pm
Calling Party – 4234997762
Called Party - 4236676877
Thanks in advance for any assistance on this important issue.
Set it up to record the LCP port and place a call.
Look on the Calabrio server in log directry at the ctiservice.dbg file
Search for the directory number of the LCP port and see if Calabrio is receving the SIP Invite
Normally Calabrio will look at the calling and called number to see if either number belongs to a licensed user.
Calabrio will then ACK the Invite and include its recorder IP address and UDP port numbers for the audio streams. It will also send "a=recvonly"
I have a feeing in some cases Calabrio can send "a=inactive" in which case UCM will never try to setup the audio streams.
You may need to run a Wireshark on the Calabrio server to capture the SIP traffic.
OK, I see what you are doing. This is nothing to do with Calabrio.
If you use the UCM Call Data Records and look at a normal inbound call it will list the end points, they will be the phone SEP address and the SIP Trunk to the CUBE/PSTN. If you have the "This trunk connects to a recording-enabled gateway" button selected on the SIP Trunk UCM can identify the CUBE and send the XMF command to fork the audio.
If you use the CDR to look at a directory number for the RCP connection then the end points will be the LCP and the SIP Trunk to the CUBE/PSTN as this is the outbound leg, Again UCM can identify the SIP trunk and send the XMF command to the correct CUBE.
If you look at the CDR record for the LCP port the end points will be the RCP and the SIP trunk to the CVP server. As UCM can't identify the CUBE it will never send the XMF command.
What can you do about it.
There was some discussion at a Cisco CC partner event a few years ago about having CVP relay the XMF commands to the correct CUBE. In that case you would select the "This trunk connects to other clusters with recording-enabled gateways" button on the CVP SIP trunk and you would add the CVP IP addresses in the CUBE to the remote URL.
I don't know if this was ever implemented and I fear it stayed in the good idea list.
The other thing you can try is to get that inbound call leg to CVP on UCM. You would need have the inbound PSTN leg send the call to UCM and them have UCM route the call onto the CVP SIP trunk. Normally CVP will stay in the call control path but you can use the SIP Refer in your ICM script to try and make CVP step out of the call control. In that case when CVP transfers to the LCP port it should take itself out of the loop and UCM will then see the end points as the RCP port and the SIP trunk from the CUBE/PSTN. In which case it will be able to send the XMF command as it will be able to identify the correct CUBE.
If neither of those two work then I think your only other option will be to put a CUBE in the SIP trunk between UCM and CVP. That is obviously a major change in the call routing for an in production UCCE system.
Currently, I'm testing with a softphone trying to get this working and then will bring in the LCP/RCP Port variable.
The reason I asked about the Calabrio server is because I am connecting to my CUBE SIP CTI Service, which has cubeservice debug files, rather than ctiservice debugs. I imagine then, that I need to configure my SIP Trunk to Calabrio to point to a standard CTI Service? I do not see any A=recvonly or a=inactive in the cubeservice debugs.
In the sip messages in the Calabrio SIP CTI server, I do see the invite from Call Manager, I see the OK back to CUCM, and then an ACK and an immediate BYE from CUCM to Calabrio.