Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Marco64 on September 23, 2008, 04:13:09 PM
-
Hi,
we are trying to handle a running outbound campaign and will need some help in understanding some points.
the campaign is run in Progressive on a SCS ver 7.
there is no CPD Server thus we have set several Treatments in the calling list. This was done assuming out Switch - Avaya S8720 has the capabilities to recognize fax, Am and so on and will forward the data to Genesys.
The first issue we have is that the calls are coming to operator while still on ringing and it's up to the Agent to find what it is. What I can see/configure to handle this?
That is the main issue but still have a question:
we use a little strategy to route the Outbounds calls to GA ( VAG - skill based routing) in this it is mandatory to add a VQ? if not for statistical purposes this will be on any help?
pls feel free to make questions or ask for data .
Tks all.
-
For the first part there are settings on the PABX that you need to set in order for it to use call classification when making an outbound call, it allows you to set the actions to be undertaken when the PABX detects a particular call result. I am not an Avaya expert so I'm not sure of exactly what needs to be set up here, I just know the options exist.
In Genesys you need to set an option in the TServer "use_am_detection" - true or false, I believe this may default to false if you do not set it specifically.
As for the VQ question, a virtual queue is purely for statistics, if you do not wish to set a particular virtual queue then Genesys will assign it's own internal VQ and use that, but you wont be able to get any queue statistics. I find it is better to always use a specific virtual queue, that way you have the option to report from it or not. But if you don't have it to start with you don't have the option.
:)
-
[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
the campaign is run in Progressive on a SCS ver 7.
[/quote]
??? SCS?
[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
there is no CPD Server thus we have set several Treatments in the calling list. This was done assuming out Switch - Avaya S8720 has the capabilities to recognize fax, Am and so on and will forward the data to Genesys.
[/quote]
It does have those capabilities by using call classifiers and a bunch of fine tuning - hassle .
[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
The first issue we have is that the calls are coming to operator while still on ringing
[/quote]
What do you mean?
[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
and it's up to the Agent to find what it is. What I can see/configure to handle this?
[/quote]
It depends on what you have configured both on the switch and on the Genesys side: you can decide if to put any call through or instead filter the non-human live calls.
[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
That is the main issue but still have a question:
we use a little strategy to route the Outbounds calls to GA ( VAG - skill based routing) in this it is mandatory to add a VQ? if not for statistical purposes this will be on any help?
[/quote]
Basically as Dionysis said VQs are used for reporting purposes, but they may become useful if you have a complex blended enviroment where your agent groups are targetted by several queues inbound and outbound traffic is distributed from: to help OCS calculate properly the rate it dials calls in predictive mode, you should add to your outbound groups origination DNs any DN calls drop off.
[/quote]
Marco di dove? :P
-
[b]Dionysis:[/b]
got it on the PaBX settings. I thought that too. Will check the option on TServer.
[b]Fra:[/b]
Ciao
SCS sorry ... OCS Outbound Control Server 7.2
In regards to the Avaya PaBX you said: "It does have those capabilities by using call classifiers and a bunch of fine tuning - hassle ." -
I'm sure it has but the issue we have is that the 90% of the Outbound Calls come straight to the Agents. And this means that the Agents are receiving: Faxes, AM, Customers, simply a silence, sometimes the Agent just listen to the Ring and has to drop the call himself and so on. As you can immagine this is a big amount of wasted resources ContactCente wise as we are getting very few valid contacts.
Marco of Milano you?
-
well, but what have you set up on the switch and in Genesys? Are you using call classifiers? Did you turn it on? how did you tune the Avaya parameters? What about Genesys use_am_detection option and treatments? There is a ton of stuff to check..
Anch'io, ma lavoro a Londra ora.
-
Fra,
With respect to tuning etc, how is this done on an Avaya?
Is there any documentation you could point me towards to read up on this? Our PABX engineers have told me that it's not possible. Also, do you know of a way to benchmark the AM detection accuracy? eg. can you record the classification portion of the call so that you can go back and listen to them to check accuracy?
-
You have to work on the pause and talk durations; these are used to classify a call as human or not-human, you can find them in the "sit-treatment". You may also want to tune the DBs adjustment of the tone detection.
I'm not an Avaya engineer, but I don't think it's possible to benchmark the AM classification..
-
[quote author=Fra link=topic=3353.msg13967#msg13967 date=1222247485]
well, but what have you set up on the switch and in Genesys? Are you using call classifiers? Did you turn it on? how did you tune the Avaya parameters? What about Genesys use_am_detection option and treatments? There is a ton of stuff to check..
Anch'io, ma lavoro a Londra ora.
[/quote]
ciao
we asked to the Switch " Operator " to check the Avaya's parameters and let us know.
Meanwhile have found that on TServer the option 'use-am-detection' was set as true.
Have also found a Genesys's advice in regards the option 'call_answer_type_recognition'. We had this set to 'no_am_detection' and since, with no CDP , it's not used was set to default = 'telephony_preset'.
ADDITION
after the above we started to have something working but come accross what seems the real problem to us that is:
there are 2 -3 - even 4 seconds of communication lag between the time the call is established with the remote person and the time that the Agent starts hearing something. We have tried this several times and it works in this way:
-- the outbound call reached the remote peer ( IE: a mobile phone)
-- the remote person answers it ....
-- 2 -3 - 4 sec'
-- the Agent hears the person.
if someone has experimented this before and can advice or at least suggest where to look please do so.
-
There are 2 things that cause delays like that.
1 - The classification portion of the call. Depending on how you have it set up it could take up to 5 or 6 seconds to classify a person as a person. This is an issue that I have experienced in the past but adjusted the settings on our dialogic card to work faster.
2 - The switch is taking a long time to transfer the call once it has been classified. This seems pretty unlikely given that the Avaya doesn't actually transfer the call like Genesys / Dialogic CPD does.
My bet is that it's just taking a long time to decide that the person you have called really is a person.
-
Tks for answering. Appreciated.
We have no Dialogic in place thus no parameter. Will have the man "over" the Avaya to look again in the Switch options/parameters, even if the time the Avaya shound take to "decide" if hearing a human or not is 1,5 secs. But ... this is done before. The "voice-lag" is after the established.
Ciao
Marco
-
If there's an extra delay after the call classification, there may be some other issues not related to the outbound solution. Post the URS and TServer logs for further help.
Francesco
-
Ok,
in your T-Server logs, look at EventDialing, EventNetworkReached, EventEstablished and then look at EventRinging for the agent. What are the timestamps?
Also, just to be on a safe side and not waste too much time: PegDEF anywhere to show that the call is actually default-routed to you?
My first two guesses would be:
1. delay in classifying the call
2. default-routed call
and the optional third one being:
3. Tony is using your environment for load-testing :)
-
The lag after the established is still probably due to classification delays.
In an outbound call you should see the following events:
RequestMakePredictiveCall
EventDialling
EventNetworkReached
EventEstablished
*classification time*
RequestSingStepTransfer (classification complete at this timestamp)
EventQueued
EventDiverted
EventRinging
EventEstablished (at the agent)
Or at least something similar (I might have missed one or two), the time it takes for call classification is between the first established and the request to transfer the call. If you can use Kazimir on an outbound call you should be able to see clear time stamps and see where the delay is.
:)
-
yeah, usually it's like that, but some extra delay cause by the strategy may have occured.
And in his case, Avaya + URS and no CPD, there isn't RequestSingStepTransfer event and there is the EventRouteRequest ;)
-
tks all
the timestamps I have are:
LocalTime TimeinSecs TimeinuSecs '30090'
2008-09-25 15:56:44.9060 1222351004 906000 EventDialing
2008-09-25 15:56:49.2500 1222351009 250000 EventNetworkReached
2008-09-25 15:57:00.7650 1222351020 765000 EventEstablished
2008-09-25 16:00:18.3120 1222354818 312000 RequestReleaseCall
2008-09-25 16:00:18.3280 1222351218 328000 EventReleased
and
LocalTime TimeinSecs TimeinuSecs '30347'
2008-09-25 15:56:57.1710 1222351017 171000 EventDialing
2008-09-25 15:57:01.8280 1222351021 828000 EventNetworkReached
2008-09-25 15:57:33.7500 1222351053 750000 EventEstablished
2008-09-25 15:57:36.2960 1222354656 296000 RequestReleaseCall
2008-09-25 15:57:36.3120 1222351056 312000 EventReleased
creating the campaigns/calling lists we have associated a defaultDN as before 30090 or 30347 This is a RP where there is a simple strategy with the target block ... yet in logs (for outbound as per inbound there are ) I have no EventQueued, EventDiverted or EventRinging.
-
The problem for me is some parameter on Avaya where you must declare some timers like:
1. How long does the call must ring before declaring it as No Answer
2. Values of noise amplitude to be recognized as voice
For me you have a problem with detection, I have faced similar issues with an Alcatel (sorry again but that the only PBX i manage). You must talk to your Avaya guys to do a trace on Voice detection, I guess they should be able to do it. and see the events as you see on TServer. Check that Voice detection is not going over an IP link, I mean PRI boards must be on same hardware as the board that does the Voice detection, if it goes over IP it is a BAD idea as compression/decompression will take some time and add noise to the call (depending on the codec) and will get the voice detection to fail.
It is a clear Avaya issue.
-
tks.
about the last post I wandered all night and today pushed to have REAL logs ... that I got (the person at the other end of the line sent an incomplete set and I wasn't able in finding basic events like EventRouteUsed ::) anyhow ..
times for routing are as follows:
LocalTime TimeinSecs TimeinuSecs
2008-09-25 12:28:55.2650 1222338535 265000 EventDialing
2008-09-25 12:28:58.7340 1222338538 734000 EventQueued
2008-09-25 12:28:59.7500 1222338539 750000 EventRouteRequest
2008-09-25 12:28:59.7500 1222342139 750000 RequestUpdateUserData
2008-09-25 12:28:59.7500 1222338539 750000 EventAttachedDataChanged
2008-09-25 12:28:59.7500 1222342139 750000 RequestRouteCall
2008-09-25 12:28:59.7650 1222338539 765000 EventRouteUsed
2008-09-25 12:28:59.7650 1222338539 765000 EventDiverted
2008-09-25 12:28:59.7810 1222338539 781000 EventQueued
2008-09-25 12:28:59.7810 1222338539 781000 EventDiverted
2008-09-25 12:28:59.7810 1222338539 781000 EventRinging
2008-09-25 12:28:59.7810 1222338539 781000 EventEstablished
these aren't looking so "slow" to me - what do you think?
[b]cavagnaro: [/b]
Check that Voice detection is not going over an IP link, I mean PRI boards must be on same hardware as the board that does the Voice detection, if it goes over IP it is a BAD idea as compression/decompression will take some time and add noise to the call (depending on the codec) and will get the voice detection to fail.
It is a clear Avaya issue.
actually .. I think in this way too. The last time I have seen a issue like this was working with the IPMX. The Video conference was routed and Established in very few time. Then compressed Video-Audio packets where not so fast and the voice was not sincronized until we lowered the compression level AND used a better codec G.723.
-
Sorry to say but this log says nothing at all: there is no EventNetworkReached and only from a full TServer log on can check when a message from the switch notifing the answer was received.
The only thing that can be said from it is that the routing doesn't add delay excluding that 1 second between the EventQueued and EventRouteRequest: 10$ (no , hold on, 10€ are worth more now :P ) that is the "wait-time 1 sec" in the vector before the "adjunct" command :P
-
if the event was in the logs I was willing to post it. but there was not. Also cannot upload logs as these are prod ones (with a log of inbound in the middle ) and are 10 Mb each.
Anyhow .. I have partially handled with options mentioned before and new treatments and now the calls that come to operator while still dialing are only the 25% (before it was 100%)
what do you think I should handle to put these under control? still work on treatments? could you post some working one for the No Answered. Also in your call center the calls do ever reach the operator while dialing?
tks.
-
I run 3 different AM detection setups and not one of them will send calls through to agents while still ringing.
One of them is an Avaya using Avaya classification and I have never seen this problem before, this problem will definitely have nothing to do with your treatments as the call should never get to the agent if it is not answered. Unless you have set the "Apply to call" field in your no answer treatment to "Connect"?
-
on the Avaya the sit treatments are:
talk - 1,5 secs.
pause - 1 sec.
these are used to distinguish a human voice.
AM - drop
Wait after adjunct - 30 secs.
treatments we use for No Answer are attached.
-
They look fine, I would change the cycle to be 2 on the next in chain treatment though.
That will pass through the chain twice if the call result is always No Answer.
However, this will make no difference to the PBX transferring calls before they are answered.
-
tks for answering
-
So are you still having calls drop through to agents before they have been connected at the customer's end?
-
Marco,
if there is sensitive info in your TServer logs, you can replace it with some hash sign. And upload it as zip files. For me it's weird you don't have an EventNetworkReached, there must be, otherwise it means the TServer is not receiving the ISDN alerting message....
and yeah, can you explain which issue you are still experiencing now?
-
Another option would simply be to disable user data in the TServer log temporarily, generate a call, then upload that log for us to analyze for you. That should hide any sensitive info that may be in the logs.
-
I seem to remember that it is illegal in some countries to not have an agent available, therefore the switch doesn't wait for eventestablished to pass the call to Genesys, it passes it on an earlier event (networkreached?). There's a switch setting somewhere............
-
[quote author=daveg link=topic=3353.msg14337#msg14337 date=1223538835]
I seem to remember that it is illegal in some countries to not have an agent available
[/quote]
O_o
[quote author=daveg link=topic=3353.msg14337#msg14337 date=1223538835]
therefore the switch doesn't wait for eventestablished to pass the call to Genesys
[/quote]
you mean the Connect message
[quote author=daveg link=topic=3353.msg14337#msg14337 date=1223538835]
it passes it on an earlier event (networkreached?).
[/quote]
you mean on the Ringing. Mh, but the point is that Marco couldn't find any EventNetworkReached in the logs. For me it's non-sense..
-
Not really! The 'legal' issue in some counties is to prohibit monitoring [u]INDIVIDUAL [/u] agent status.
For group of agents, it should be fine.
OCS relies on agent readiness in Agent Group (and others statistics) to control dialing pace, not individual agent.
The specified case (CPD routes ringing state calls to destination) is quite interesting.
As pointed out by others in previous replies, it could be CPD configuration issue but harder to prove.
There was a similar case encountered in Genesys 7.2 OCS implementation.
OCS agents received calls that were in ringing state.
It was found that all outbound calls to fixed-line numbers in the region returned answer signal after 12 seconds.
Some Telco carriers configure this setting in order to charge circuit usage (or having default settings from switch manufacturer!)
Simple steps to prove:
- identify those dialed numbers having the problem
- use any Genesys soft-phone with event messages outputs
- make call to numbers in question
- observe outputted event messages AND ring-tone / voice heard