Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DS1 single step conference

Status
Not open for further replies.

biglebowski

Technical User
Jan 29, 2004
3,117
0
36
GB
I need to record some extn's on a definity but cannot come off the frame. The only solution is to use DS1's and use single step conference to record the phone, this is a valid method and does work. With SSC it is initiated at the start of a call via a CTI event and therefore the rec misses the first sec of the call, my question is would it be possible to permanently conference a phone so it is always recorded even when on hook?

Thanks
 
Where did you come up with this idea????

A DS1 is a 24 channel data circuit, You are not going to just recoed off it.
 
In uk it's 30ch and connects to a digital card in a voice recorder this is a recognised method of recording in call centers and I have installed 4 (1 being 650 extns)
 
I'm intrigued by your 650 extns ! Tell me more. My recording supplier (UK based) tells me that "Avaya have a limitation on the number of simultaneous conferences thay can support while remaining stable. Extensive testing has determined 120 channels to be the maximum safe number"

On your original question, we used to have a clipping problem when we used Service Observe on our Nice system - switching to SSC overcame this.
 
The whole site was 650 extns but the call center only had 50 agents . The issue apparently is if there are a large number of extns the CTI info is slowed down,it is the cti info that activates the recording and hence the larger the switch the greater the delay. I was under the impression that SSC reduces the delay but is still about 1 sec is this true?
 
We have no noticable delay when recording 120 channels. Only the stations and skill groups that we require recording are declared to the T server.
 
If the number of recordings or monitored stations is slowing things down, it is likely from the recording solution. ASAI will handle much higher volumes and will fall apart when latency exceeds 200 ms on avg.

SSC requires call id and DS1 station to use to listen and agent station to be listened to. So, you could not camp on a station before a call as no call id would be available.

The PBX does have a limit of some 60 or so Service Observations at the same time, but this is not service observing. SSC is essentially a conference performed with a listen only path using CTI. So, any limits would be the number of simultaneous conferences and of course the number of parties on the conference.

Nice uses the alert event to determine if the call will be recorded, then starts recording on connect event. If your solution is delayed by determination of whether to record a call, perhaps delay the connect (don't use auto answer) might help? Else, the solution is just not capable of keeping up.

The SSC solution should not give a 1 second delay. Given ASAI intolerance for delays, and the relative low volume of events on your link for events on 50 stations plus some login/logout traffic from the hunts, you should expect 10-20 ms max message times on the ASAI links. There would be virtually no delay in the PBX. So, from connect event to intrusion should occur within less than 100ms unless the application is slow in making the request. 100 ms should be virtually undetectable.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top