Outbound campaing - the call comes to Agent while still ringing

[cavagnaro]

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.

[Marco64]

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.

[Fra]

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 ) that is the "wait-time 1 sec" in the vector before the "adjunct" command

[Marco64]

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.

[Dionysis]

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"?

[Marco64]

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.

[Dionysis]

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.

[Marco64]

tks for answering

[Dionysis]

So are you still having calls drop through to agents before they have been connected at the customer's end?

[Fra]

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?

[Dionysis]

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.

[daveg]

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............

[Fra]

[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..

[bcyk]

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