Develop Call Recording solution using 8.1 SDK

dmodi · February 9, 2015, 8:32am

My question may sound naive. Please pardon my ignorance. I am a newbie to Genesys.

I am trying to implement call recording in two ways on a Genesys Sip Server using SDK 8.1

I am getting a span (mirror) for all call centre agents traffic. I would like to get all call metadata through the T-Server SDK while I get all media for recording from the span.

What request should I use to get call events for the monitored extensions ?

The SDK documentation mentions of two methods that I can think of -

a. Register a DN using RequestRegisterAddress with registermode as ModeMonitor. Does this register the DN to my application as a third party just to receive the call events on this extension ?
b. RequestStartCallMonitoring - I see that the events on this are relatively fewer than the earlier namespace request.

We will be using a single step conferencing type of method to record work from home agents. We will not be getting WFH agent traffic in the span. We would therefore need to get a copy of the media. We are thinking of registering a phone using sip endpoint sdk and based on call events for the WFH agents, put our phone in conference on the call thereby receiving a copy of the media to our recorder. Is this the correct method ? Can we get any sample code that implements this ?

Kubig · February 9, 2015, 10:04am

The topic is so general and it is not possible to answer with few words. So, in general, in case when you have passive recording (span ports), you have to just register as an T-Server client and observe specified DNs. Then you can receive all attached data. You do not need use “RequestStartCallMonitoring” or any type of conference.

From my point of view, that SPAN ports are not necessary at all and you can use “active” recording mode, where the Genesys Media Server provide the media/stream replication to specified recording servers. The CTI integration is still same as is mentioned above.

If you want, send me PS and I will try to give you some hints.

dmodi · February 25, 2015, 8:24am

Thanks Kubig for your help.

Passive recording -

I have successfully registered the DN’s that I am interested in receiving unsolicited call events. Except for the EventRegistered in response to my request I do not receive any unsolicited call events. I have tried RegisterMode.ModeMonitor as well as RegisterMode.ModeShare.

How do I request unsolicited call events as a third party application for the DN’s I have registered ?

Thanks in advance.

dmodi · March 3, 2015, 8:49am

Update -

We have been able to get the required call and agent events. We should be OK as far as passive call recording is concerned.

For active recording, when we get the required call event that we wish to record actively, we send a private service request as follows -

                KeyValueCollection reasons = new KeyValueCollection();
                KeyValueCollection extensions = new KeyValueCollection();
                extensions.Add("record", "source");
                extensions.Add("id", ev.CallUuid);
                extensions.Add("dest", "sip:" + sipSocketListenerIP + ":" + sipSocketListenerPort);
                RequestPrivateService requestPrivateService = RequestPrivateService.Create(3013, ev.thisDN, ev.connID, ev.userData, reasons, extensions);
                tServerProtocol.Send(requestPrivateService);

As per Genesys active recording documentation, we should get a sip invite on the listener socket.

We get an ‘EventACK’ to our request followed by an ‘EventAttachedDataChanged’. This event contains the following attributes -

	'GSIP_REC_FN' [str] = "CE937U6TP90HF509O6NAINAN3O004O6H"
	'GSIP_RECORD' [str] = "ON"

We do not receive an invite on our listener socket. The above attributes indicates that the media server is creating a recording file and not duplicating and sending us the RTP packets.

How do we make the media server forward the packets to us ? Is that a change in the Genesys configuration ? Will the RTP packets be received on the same port as the invite ?

Thanks for your help.

Kubig · March 3, 2015, 8:58am

You have mixed T-Lib protocol with SIP and RTP protocols - that are totally different levels. When you start the active recording session, the SIP server contact RM, which should select MCP for required service basis on configured rules. Then MCP will invite the recorder server IP:PORT (by default IP:5060) , both endpoint send own SDP and within signalization will be one of them select and used. Afterthat the RTP from MCP should be replicated to the recording server. For properly working you have to of course deploy all necessary components and configure all objects like VoIP service, LRGs, etc. Did you configure LRG for recording client and recording server? Is the integration between SIP server and RM working? What says logs?

PS: If you want to help with configuration Genesys env, feel free to post me a PM.

dmodi · March 11, 2015, 8:17am

What is the correct way to sending AttributeExtensions ? What is wrong with the following code -

KeyValueCollection extensions = new KeyValueCollection();
extensions.Add(“RTP-PASSWORD”,“7364533”);
RequestPrivateService rps = RequestPrivateService.Create(2,DN,null,null,null,extensions);
tserverprotocol.Send(rps);

We receive an invalid attribute error -

EventError’ (‘52’)
message attributes:
AttributeErrorMessage [str] = “Invalid attribute”
AttributeErrorCode [int] = 53
AttributePrivateMsgID [int] = 2
AttributeEventSequenceNumber [long] = 4694558
AttributeExtensions [bstr] = KVList:
‘RTP-PASSWORD’ [str] = “7364533”

The Genesys support team says I am sending the attribute extensions in the wrong format.

What is the correct way ?

Thanks in advance.

Dave

Kubig · March 11, 2015, 8:59am

According to the error message, it seems like the password value does not match the configured value on SIP server application object level. Try to attach or check logs records before the EventError is generated. There should be the root-cause visible.

dmodi · March 11, 2015, 9:49am

Thanks Kubig.

Genesys support mentions that the attribute is not being sent in the correct format.

They say the attributeextensions should appear as follows -

message RequestPrivateService
AttributePrivateMsgID 2
AttributeThisDN ‘7103’
AttributeExtensions [23] 00 01 00 00..
‘RTP-PASSWORD’ ‘7364533’
AttributeReferenceID 5

whereas in the error message it appears as -

AttributeExtensions [bstr] = KVList:
‘RTP-PASSWORD’ [str] = “7364533”

Is it something to do with encoding or serialization ?

Thanks

Fra · March 11, 2015, 9:50am

dmodi post:6:

What is the correct way to sending AttributeExtensions ? What is wrong with the following code -

KeyValueCollection extensions = new KeyValueCollection();
extensions.Add(“RTP-PASSWORD”,“7364533”);
RequestPrivateService rps = RequestPrivateService.Create(2,DN,null,null,null,extensions);
tserverprotocol.Send(rps);

We receive an invalid attribute error -

EventError’ (‘52’)
message attributes:
AttributeErrorMessage [str] = “Invalid attribute”
AttributeErrorCode [int] = 53
AttributePrivateMsgID [int] = 2
AttributeEventSequenceNumber [long] = 4694558
AttributeExtensions [bstr] = KVList:
‘RTP-PASSWORD’ [str] = “7364533”

The Genesys support team says I am sending the attribute extensions in the wrong format.

What is the correct way ?

Thanks in advance.

Dave

Check Knova Id: 31395 article out on the Genesys KB. Looks very similar to the issue you’ve come across.

Fra

dmodi · March 11, 2015, 10:01am

Can you provide a link ?

Thanks

Kubig · March 11, 2015, 10:05am

It is not seems like the root-cause. Mentioned bug was related to RequestPrivateService with ID 3013 and not to ID 2. But, install the latest release of SIP server would be the best

Fra · March 11, 2015, 10:06am

https://genesyspartner.force.com/customercare/pkb_Home?id=kA4U00000008bG2&q=Knova+Id%3A+31395&l=en_US&fs=Search&pn=1

Fra · March 11, 2015, 10:08am

Maybe. But it’s worth checking whether he’s running the same SIP Server version mentioned there in the article.

dmodi · March 11, 2015, 10:12am

The attribute is correctly listed in that article

AttributeExtensions [2] 00 00..

Whereas in my case the attribute in the log is as follows -

AttributeExtensions [bstr] = KVList:
‘RTP-PASSWORD’ [str] = “7364533”

It should list as following -

AttributeExtensions [23] 00 01 00 00..
‘RTP-PASSWORD’ ‘7364533’

It appears it is not able to proper read the values I am sending. Isn’t this a serialization issue ?

Thanks

Fra · March 11, 2015, 10:33am

[ol]- what version of SIP Server are you running? Is it the same affected by the bug described in that article?

is rtp-info-password option configured correctly in SIP Server? Which section did you configure it in?
Are you issuing the RequestPrivateService against a specific DN? I can’t see the AttributeThisDn
Can you please post the SIP Server log snippet covering from the RequestPrivateService until after the relevant EventError?
I guess you grabbed the log from your end rather than from SIP Server, hence the quotation marks may appear different: you got double quotes on both the AttributeErrorMessage and the RTP-PASSWORD:

EventError’ (‘52’)
message attributes:
AttributeErrorMessage [str] = “Invalid attribute”
AttributeErrorCode [int] = 53
AttributePrivateMsgID [int] = 2
AttributeEventSequenceNumber [long] = 4694558
AttributeExtensions [bstr] = KVList:
‘RTP-PASSWORD’ [str] = “7364533”[/ol]

dmodi · March 11, 2015, 10:51am

Thanks Fra.

Yes, this is the log on our end.
Yes, both the key and the value is in double quotes.

I am requesting my client for the sip server version and the logs. Will post once I receive them.

Thanks

cavagnaro · March 11, 2015, 11:34am

Why a List and not a Pair only?

dmodi · March 16, 2015, 10:10am

Thanks Everyone for your help.

We were successfully able to record both passively as well as actively.

For Passive recording, our code for passing AttributeExtension was correct. The password Genesys support had provided was wrong. On getting the correct password, we were able to get the UserEvent with the RTP info.

For active recording, we developed a sip stack which would receive the sip commands and provided appropriate responses. On sending a proper “200 OK”, we were able to receive the RTP.

Thanks Kubig.

Fra · March 16, 2015, 1:32pm

Excellent news, well done