what is SSC( single step conf ) and how that is used in call recording in AVAYA

[avaya137xx]

Hi All,

please help me what is SSC ?
is it Avaya CM feature or AES ?

or Verint or 3rd party feature .

how to make use of that SSC and how it is used in recording

 

[bignose21]

we use the same on Telstrat Engage for voice recording so the Telstrat interfaces via the AES TSAPI/DMCC to connect to the CM, a conference is initiated between the Telstrat server and the two parties of the call to allow recording. there is some explanation on the below link:

https://www.devconnectprogram.com/fileMedia/download/8af77c11-2f90-4339-af5d-e0b2767af678

 

[avaya137xx]

Thank you I am able to understand how it works now.
My question now is...who is offering the SSC here...is in initiated by 3rd party recording server or Avaya cm or Avaya aes

 

[kyle555]

SSC is a feature offered by AES. The 3rd party app invokes it.

So, if you wanted to build a call recorder, you'd use AES to sniff out what phones are doing to decide when you want to record them.
You'd also have your own phones registered by DMCC.
When there's a call you want to record, your app could do one of 3 things to record:

Service observe - your recording port/DMCC phone would have a COR of being allowed to be a service observer and the agent's COR would let them be observed. Your phone would dial the service observe feature code and the extension of the agent to get a copy of the audio stream.

Single Step Conference - You send a message on behalf of the agennt's phone that presses the conference button, then dials the extension of your recording port, then presses the "complete" button on the agent phone to bring your recording port into the call

Split Registration - Instead of having your recording port have its own extension, it would register a 2nd instance of the agent's phone and CM would send the audio stream to both your app's IP representing the agent extension as well as the agent's extension IP

So, single step conference is just like a normal conference but it happens in 1 motion. So, if you were to have a normal call, press conference, get dial tone, dial an extension, be on a new call with the new person, then press complete to bring them all on the line. SSC is if you could do all that programmed on a button. It's only available to AES for applications to leverage.

 

[avaya137xx]

thank you sir for the clear information.

we have an ongoing issue that , we using Verint server for call recording
on the Verint we see around 30 calls per day have no audio on the call records , like totally blank audio but we have the interaction duration captured and all other call details are captured. But we just don't have Audio on the recording when we play the records in the Verint.

I am thinking it should be something to do with DMCC license .
we recently added lot of agents into CM and Verint and added TSAPI license accordingly but we never checked about our DMCC license .

could you help me how to check if we have shortage of DMCC here.

 

[kyle555]

I wouldn't think you have a DMCC license issue. Those are only used for the media side of a phone and they are used to register the virtual phones Verint receives the audio on.

If you're maxing out on TSAPI, a report in WebLM would show how many you're using.

It does use quite a few. I believe Verint is spending a TSAPI on the call once it hits the VDN to track where it is/where it goes into which queue. Theoretically, having a bunch more trunks and a bunch more calls on hold could leave not enough TSAPIs for the calls that hit the agents.

Depending on what version of Verint you have, it might do things "the old way" that are less efficient in TSAPI usage (R12) or the new way which is more efficient (R15 - they skipped 13 and 14 - don't ask)

From an admin perspective, the best thing you can do is a cleanup and remove any old stations or agents from Verint that might not need to be there anymore.

 

[avaya137xx]

Thank you so much for the clear information.
Could you help me understand how CTI works.

We have couple of CTI links created , so how will i know through which CTI link my station/ agent Id is sending the notification/ data/ events ( I am not 100% sure what CTI links send ) to AES server.

How station and CTI link correlated.

 

[kyle555]

AES and CM have that configuration on both systems. So, in "change ip-services" you enable AES with node-name - it's kinda like DNS where a logical name in CM maps to the IP of AES and a switch password.

Then, in CM, you add cti-link 1.
On AES, you comfigure the switch password in the DMCC config - which must match what's in ip-services in CM - and you configure the CTI link number in the TSAPI config which must correlate to a CTI link you built in CM.

So, the short answer is to check how many AES's you have - in display ip-services - and then log in to those AES's and check their TSAPI configuration to see which CTI link number they correspond to.

Your station/agent isn't sending data. CM is sending it to AES. CM is sending it because AES put up a TSAPI monitor on your station, and AES did that because the app asked it to.

Here's an example:

Let's say it's a bank that always tried selling you life insurance when you call for anything. Old Verint would toss up a TSAPI for every agent/station configured in Verint. With newer Verint, you'd have a login/logout skill in CM which doesn't receive any calls, but all agents are a part of it. Verint tosses 1 TASPI monitor up on that skill and then AES will send Verint all the login/logout messages from the agents. Verint will then toss up a TSAPI monitor on all the logged in agents.

Based on your recording configuration, you might only record calls to certain VDNs, so you might monitor those too.

Now let's say that bank has 2 recorders - one for customer service to listen to the whole call and another for the compliance department because they just want the recording of the insurance terms and agreement that is configured to only record when the agent calls a VDN for that specific purpose.

The agent's call with the customer has been recorded from the start based on what I said previously. To record the verbal contract, the agent might say "i'll bring us onto a secure line" and then conference in a VDN made for that purpose. The 2nd recorder for compliance is monitoring that particular VDN by TSAPI and when it sees agent 1234 call it, that recorder might then invoke TSAPI through the same or a different AES and make a single-step-conference to that compliance recorder. That means 2 recorders can be recording the same call at the same time for potentially different purposes.

Consider how many calls are up in this case. One to the agent from the customer. 2 for the conference to the recorder. 3 for the conference to the recording VDN. 4 for the conference to the 2nd recorder.

Could you do that with service observe recording instead of SSC? Sure, since CM 5.1 you can have 2 service observers on a call. The recorders could do that. But what if the supervisor wants to use that feature too? If the supervisor wants to listen in to the agent's call while they're on with the customer, if it was before the insurance sale, then the insurance recording would fail, and if it was during the recording of the insurance contract, then the supervisor's attempt would fail.

Single Step Conference allows more flexibility for more applications to record stuff.

Now imagine this bank is also using a custom app to control the phone - like some agent desktop application. They talk on the physical phone, but they have some integration on their PC to not use One-X Agent. That's another app, another TSAPI license. You can have up to (if I recall...) 6 monitors on a station live at once.

So, there's a nice little bit of information for you. But the real question is - why do you care?

It doesn't matter which CTI link is invoking it. What problem are you trying to diagnose?

Here's an example of what might be a problem: A typical CM phone has 3 call appearances. It can have more, but the default is 3. The default is also to reserve the last one for conference/transfer. That means you can have 1 call live and 1 on hold and you're not allowed picking the last call-appearance to make a 3rd call. It's saved in case you want to transfer one of the other callers to another number - you need another line/call-appr to do that.

Now let's say you didn't restrict the last call-appr and 2 were in use and a call came in that needed to be recorded. The call from the customer would be call # 3 and you'd have no more call appearances left to invoke a conference - by single step or otherwise - and the recording would fail in that case.

So, what broke?

 

[avaya137xx]

thank you so very much sir , for the great explanation. It took me sometime to understand .

the problem we facing here , on a daily bases we have 100+ calls recording with no AUDIO. this is happening for both inbound and outbound calls .
Avaya engineer took MST trace and in the trace we can see CM sends a temporary failure once it receives the SSC request..

and I did check the Call appearance for the stations they have 3 appearances .
we get the screen recorded fine but just the audio is not captured on the Verint . and we using SSC method to record the calls.

and interestingly we have the .WAV file generated with the interaction duration for the same bad call but only the Audio is BLANK.

this is intermittent issue .

 

[Sean655]

Possibly out of media resources on your gateways? I had a similar situation once and we had to add another MedPro. You can check the resources needed with measurements commands.

 

[avaya137xx]

but Agent and customer talk path has no Audio issue , it just not recorded on the Verint.

do you think its a media resource issue ?
if you think it is please provide me the command to check that .THANK YOU !!

 

[Sean655]

list measurements ip dsp
Hit F5 to see the different options you have for checking resources. You can look at it by network region, hourly, detail, etc.

For me, agent and customer were connecting via PRI and using digital phones so the failure for recording was a symptom of not enough resources. I wouldn't be surprised if your case is the same though, the call gets established first and then the recording starts because you can't conference a call until the call actually begins.

 

[kyle555]

The temporary failure should have more information!