Right now I’m trying to make the integration between GENESYS (SIP Server and GVP (MCP and RM) 8.1.5) with NICE SIP recorder. I’ve done all the steps indicated on the deployment manuals, even in one delivered by NICE, but the “Media Server” is not sending the RTP packets to the NICE recorder.
I can see in the log files that the recordingclient request are being done and the conference is made, but no request to the RM for the recordingservers is done.
Has anyone has accomplished this integration? I even tried replicating the steps for the GQM but still the same result.
Is an integration to do the recording of the agents voice calls via a 3rd-Party recorder, just like the usual NICE recording but done via SIP. It’s explained in the SIP Server deplyment guide on the “Call Recording–MSML-baed” and also in the Media Server and GVP Deplyment guides.
Ah ok, so you wanna record agents, not GVP, gotcha.
Doesn’t NICE support mirror port recording? In that way you only configure the switch to mirror all traffic from agents PCs, SIP Server and MG to the Nice server port and begin to record. Than and Nice TServer SIP integration for TLib events should be enough to record calls…
GQM implementation steps does not lead to successfully integration of NICE,because GQM is fully active recording and NICE is passive recording solution,I guess. So,for sure check if you have configured following steps:
Allow MSML (msml-support,record-msml-support) on SIP server object in CME or GA
Configure MCP for allowed vrmrecorder module and configure routeset options according to the doc
Configure RM according to the doc
Create and configure Resource Access Point for recorder server (option must point to the rec server SIP listener port)
Configure LRGs for type -
recordingclient(MCP)
recordingserver(NICE)
Create and configure default IVR profile which contain section with recdest,etc. options
Create and configure VoIP services and trunk/TG for possibility to “call” MSML services
Configure record option on object (type of SIP,RP,Ext,..) in CME or GA to “true” for instruct SIP to start recording
These steps will be lead to instruct all required components to start recording process, I hope But,I never used this deployment in practice and I am not sure if it will work and if it is supported. My experience with deployment of NICE solution was always via SPAN ports - NICE was independent on Genesys solution.
No need SPAN ports on network infrastructure,application control of used routes/way (geo-location),load-balancing on MediaServers. But as I wrote,I am not sure that this implementation is possible to use for NICE solution. In theory yes,in practice I have never seen similiar deployment of NICE.
Yes,you are right. I have confirmed from my colleague that the NICE supports active recording via GVP8.1. Prerequisities for this integration was written by genesysguru. I know only GQM implementation from practice.
As several of you has said the benefits of this integration is the ability of sending de RTP packets to the NICE Logger via a conference with the Media Server, so no port SPAM.
Following what Kubig initially said all I need to do was to re-follow the steps for GQM Integration for MCP (in Genesys Active Recording Ecosystem Guide), previously I missed the part where they told you about the “recordingclient.recdest” and “recordingclient.recmediactl” configuration parameters.
After doing this Media Server successfully started the conference with the NICE VRSP and the NICE Logger started receiving the RTP packets.
On small change though, in GQM Genesys Active Recording Ecosystem Guide manual they told you to set the “recordingclient.recdest” to “fixed,2”, in my case I had to change it to “fixed,1” so NICE Logger would only one Call Leg instead of two.
Finally with have a working testimony of this solution working, as some of you said before it was all theoretical.
Option “recordingclient.recmediactl” has two possible values (as I know yet):
fixed,1 - mono(customer’s and agent’s stream in one leg
fixed,2 - stereo(separate leg for each stream)
Option(s) “recordingclient.recdest(2)”:
Only recordingclient.recdest - RTP stream is sent to one LRG(one recorder),you can specify RM ip address or direct ip address of recorder,if you have only one recserver
recdest & recdest2 - RTP stream is replicated to two LRG, you have to specify IP address of one recorder server from each LRG
Currently,GQM can determine parameter recdest itself,may be NICE can it also.
I am not sure,if it is still active recording,when you have configured record parameter on extension object. In that configuration is recording started by SIP server or I am wrong? So,in GQM it is.
Option “recordingclient.recmediactl” has two possible values (as I know yet):
fixed,1 - single SIP session for both stream
fixed,2 - single SIP session for each stream
Option(s) “recordingclient.recdest(2)”:
Only recordingclient.recdest - RTP stream is sent to one LRG(one recorder),you can specify RM ip address or direct ip address of recorder,if you have only one recserver
recdest & recdest2 - RTP stream is replicated to two LRG, you have to specify IP address of one recorder server from each LRG
Currently,GQM can determine parameter recdest itself,may be NICE can it also.
I am not sure,if it is still active recording,when you have configured record parameter on extension object. In that configuration is recording started by SIP server or I am wrong? So,in GQM it is.
Thanks for the info Kubig, I haven’t tested the functionality without the recdest with I’ll do it as soon as I can.
About the record=true I guess it has to be with the NICE configuration because in any other way NICE will see the Logger channels in observation failure. As I said it may be something in the nice configuration.
In the GQM deployment they use this configuration to avoid the need of the TPrivateRequest from the recordingserver.
Verint will be supported in near future - it is up to Verint to modify their software to work with Media Server
record = true - works with Nice correctly and it is still active recording because RTP is duplicated in “active” way to recording device
recmediactl controls how SDP is delivered to recording server - recording is always in stereo
1 - one INVITE with two SDP inside (only for NICE)
2 - two INVITE each with one SDP (GQM and Verint)
in LRG containing VRSP You have to select “parallel forking” as monitoring method otherwise failure of VRSP won’t be handled correctly
recdest(2) parameters are used for HA only for GQM - adding recdest2 parameter into profile will cause Media Server to send same RTP to two different recording devices
8.1.6 release added support for inserting beep during recording. Beep is controlled through parameters in profile
Nice has some limitations when working with active recording - please check for most current list with Nice team
there are some additional parameters on MCP which might effect recording - for example with default parameters if NICE is not sending RTCP packets system will stop recording after 60 sek or will be restarting recording process
for proper geo-location support for active recording request You have to use proper version of RM/MCP/SIPS. Also default setting in RM for geo-location support will cause SIPS to reject recording request if there are not MCP’s with proper geo-location
on commercial side this integration requires new license called “Active recording connector”
But,I never used this deployment in practice and I am not sure if it will work and if it is supported. My experience with deployment of NICE solution was always via SPAN ports - NICE was independent on Genesys solution.