Now according to the docs, setting 3 (OCServer) overrides settings 1 and 2 and I can see that the 40secs attribute is being passed across as part of the RequestMakePredictiveCall event (AttributeTimeout 40). I’m therefore expecting to see the time between EventDialling and EventReleased for a “No Answer” to be 40seconds.
However, what is actually happening is that the time between EventDialing and EvenReleased is never longer than 30secs.
I’ve tried changing setting 2 (Tserver) to 25secs to see if that was the one controlling things but still it dials for 30secs.
Does anyone know why this could be happening or if there are any other settings which could be overriding the 3 I’ve mentioned above?
It is not recommended to set the “call_wait_connected_timeout” to value higher than 30sec, because the SIP server TimerB is 32 by default. You have two option:
Keep the timeout lower than 32 secs
Set the value for timeout to value higher than 30secs and configure the VoIP trunk between SIP and RM with option (predictive-timerb-enabled) disabling the TimerB will be applied
all depends on used architecture andtechnology (SIP, CPA, etc.)
Thanks for the response Kubig, very much appreciated.
Some of that went way over my head but with regards to technology and architecture my limited knowledge is that we use an Avaya telephony platform and Genesys version is 7.6 with 8.1 TServers.
Where would I find the SIP settings in Genesys or is this something that would be configured within the Avaya telephony?
Despite all of that my aim is to reduce the timeout to lower than 30secs anyway. If I wanted to have different settings on each TServer, is it possible to remove the call_wait_connected_timeout setting on OCServer and then Genesys would use the TServer ring-timeout setting instead?
What do you mean by term “we are only ringing for 18secs”? What is really means, try to post the log covering the interaction/call. This feature is working properly.
Uff, you are not so familiar with Genesys and troubleshooting at all. I think, you would know why is your calls dropped/released before are connected or released by the timeout. Due these fact, you should check T-Server log,where almost issues start or are easily visible/to track. EventReleased is just an impact of the root-cause, so try to check the logs before the EventReleased is generated.
PS: Strongly recommend to learn about Genesys event-model or visit any Genesys training.
That’s true - I have very little knowledge of the configuration or Event Model so I’ll look into that.
The person who configured the dialler left the business and I’m looking to improve our Outbound performance. I thought it would be a simple job to change how long Genesys dials a number for but it doesn’t appear to be the case. (3 different settings to affect how long to dial?!). That’s why I’m here, throwing myself at the forums mercy trying to work out how to get the result.
I’m still puzzled, because there’s clearly a relationship between the call_wait_connected_timeout setting and how long it dials for. It just doesn’t seem to be a 1:1 relationship
call_wait_connected_timeout=40 ==> call dials for ~30secs
call_wait_connected_timeout=25 ==> call dials for ~18secs
I think it might best if I do some testing out of office hours and then I can generate some “cleaner” log files. Trying to trace what is happening with 1 call when there are multiple other calls happening is making it difficult to “tidy” up the log files.
I’ll do some testing on Monday morning and post the resulting log files then, if that’s ok.
Thanks for all your help so far Kubig - have a good weekend.