No Answer ring time setting(s)

[MancMonkey]

I'm trying to work out which setting is actually in control of how long a call is dailled before it is classed as a No Answer.

I've looked through several Genesys documents and found 3 settings that I think could control this

1 - TServer - num-ring-no-answer=6
2 - TServer - ring-timeout=30
3 - OCServer - call_wait_connected_timeout=40

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?

Thanks in advance for any help you can give me.

[Kubig]

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:

1) Keep the timeout lower than 32 secs
2) 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.)

[MancMonkey]

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?

[MancMonkey]

Quick update on this - I  changed the call_wait_connected_timeout setting to 25 in OCServer

However now I'm seeing that we're only ringing for 18secs?! 

Any ideas as to why the setting of 40 would equate to 30secs and a setting of 25 would equate to 18secs?

[Kubig]

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.

[MancMonkey]

Thanks for the help Kubig

From the log files for the RequestMakePredictiveCall event I can see the AttributeTimeout value of 25 being passed through

request to 65200(New*****_Tserver_Avaya) message RequestMakePredictiveCall
AttributeReferenceID 15825
AttributeExtensions [2] 00 00..
AttributeUserData [1037] 00 26 01 00..
'GSW_TZ_OFFSET' 0
'GSW_CHAIN_N' 0
'GSW_PHONE' '*****'
'SPA:Title' '*****'
'SPA:Address 1' '*****'
'SPA:Address 2' '*****'
'SPA:Address 3' ''
'SPA:Address 4' ''
'SPA:Postcode' '*****'
'SPA:Date of Birth' ''
'Daytime phone number' '*****'
'Evening phone number' ''
'Other phone number' ''
'SPA:Notes' ''
'SPA:Lead Source' '*****'
'SPA:Surname' '*****'
'SPA:Max Reschedule Date' '*****'
'SPA:INITIALS' '*****'
'GSW_CALLING_LIST' '*****'
'GSW_CAMPAIGN_NAME' '*****'
'InteractionType' 'Outbound'
'InteractionSubtype' 'OutboundNew'
'GSW_RECORD_HANDLE' 138216
'GSW_APPLICATION_ID' 170
'GSW_CAMPAIGN_GROUP_DBID' 211
'GSW_CALLING_LIST_DBID' 368
'GSW_SWITCH_DBID' 108
'GSW_CAMPAIGN_GROUP_NAME' '*****'
'GSW_CAMPAIGN_GROUP_DESCRIPTION' ''
'GSW_CHAIN_ID' 147023005
'GSW_ATTEMPTS' 20
'GSW_AGENT_ID' ''
'GSW_CALL_RESULT' 0
'GSW_TZ_NAME' 'GMT'
'GSW_CONTACT_MEDIA_TYPE' 'voice'
'GSW_CALL_ATTEMPT_GUID' '9A4BGE345D0LL8JQC2JRO6QKT40038SB'
AttributeTimeout 25
AttributeOtherDN '*****'
AttributeThisDN '834907'



And then log file from the EventReleased I can see the time between events and the CallDialled value are ~18secs


received from 65200(New*****_Tserver_Avaya)*****(fd=260) message EventReleased
AttributeCallState 7
AttributeThisQueue '834907'
AttributeNetworkCallID 1452849798
AttributeCallType 3
attr_#152 3
AttributeCallID 64257
AttributeConnID 00ca0274723d25df
AttributeCallUUID 'F7NRON4TSL4S553EL2P9MJISOC079A0G'
AttributeUserData [1037] 00 26 01 00..
'GSW_TZ_OFFSET' 0
'GSW_CHAIN_N' 0
'GSW_PHONE' '*****'
'SPA:Title' '*****'
'SPA:Address 1' '*****'
'SPA:Address 2' '*****'
'SPA:Address 3' ''
'SPA:Address 4' ''
'SPA:Postcode' '*****'
'SPA:Date of Birth' ''
'Daytime phone number' '*****'
'Evening phone number' ''
'Other phone number' ''
'SPA:Notes' ''
'SPA:Lead Source' '*****'
'SPA:Surname' '*****'
'SPA:Max Reschedule Date' '*****'
'SPA:INITIALS' '*****'
'SPA:Cti Id' 25105763
'GSW_CALLING_LIST' '*****'
'GSW_CAMPAIGN_NAME' '*****'
'InteractionType' 'Outbound'
'InteractionSubtype' 'OutboundNew'
'GSW_RECORD_HANDLE' 138216
'GSW_APPLICATION_ID' 170
'GSW_CAMPAIGN_GROUP_DBID' 211
'GSW_CALLING_LIST_DBID' 368
'GSW_SWITCH_DBID' 108
'GSW_CAMPAIGN_GROUP_NAME' '*****'
'GSW_CAMPAIGN_GROUP_DESCRIPTION' ''
'GSW_CHAIN_ID' 147023005
'GSW_ATTEMPTS' 20
'GSW_AGENT_ID' ''
'GSW_CALL_RESULT' 0
'GSW_TZ_NAME' 'GMT'
'GSW_CONTACT_MEDIA_TYPE' 'voice'
'GSW_CALL_ATTEMPT_GUID' '9A4BGE345D0LL8JQC2JRO6QKT40038SB'
AttributeDNIS '*****'
AttributeANI '834907'
AttributeThisDN '834907'
AttributeThisDNRole 1
AttributeOtherDNRole 2
AttributeOtherDN '*****'
AttributeExtensions [37] 00 02 01 00..
'CauseCode' 10
'UCID' bin: 86 BA 98 56.. (len=8)
AttributeTimeinSecs 1452849816 (09:23:36)
AttributeTimeinuSecs 890000
AttributeEventSequenceNumber 0000000002549e87
09:23:37.200 Trc 50002 TEvent: EventReleased
09:23:37.200 OCSEvent[3146594]::EventReleased(No Answer,CallTypeOutbound)
TServer[202`New*****_Tserver_Avaya]
DN[3754`834907]RoutingPoint
{
CallTMake[202:15825]::EventReleased {
CallProgressor[138216:T40038SB]::EventReleased{
FTCcall[202:15825]::EventReleased
Application[170`OCServer_PRI].log_call_stats = true
FTCcall[202:15825]::reporting
phone                  '*****'
pCallRes                'No Answer'
timeDialing            '09:23:18.763'
timeClientRinging      '09:23:24.659'
timeBadCallReleased    '09:23:36.890'
deltaOCS_CPD            0
09:23:37.200 PAEventInfo (ContactInfo):
OwnerSessionDBID: 211; OriginSessionDBID: 211;
CallType:  PA_CallOutbound; StatType: PA_StatCallNoContact;
RecHandle: 138216; CallID: 64257;
PlaceDBID: 0; CallResult: 7;
09:23:37.200 PA Outbound Call Info:
OwnerDBID: 211; OriginDBID: 211; RecHandle: 138216; CallID: 0; PlaceDBID: 0;
CurrentStatType: CallNoContact; State: OutCallNoContact; CPDCompletedFlag: 1; CompletedFlag: 1; CallResult: 7;
StatType Durations:
      CallDialed   18.28
      CallNoContact   0.00


Let me know if you need any more information

[Kubig]

You have to check T-Server log to find out the root-cause for release the call.

[MancMonkey]

Info below from the TServer log for the EventReleased - what am I looking for here?


@09:23:36.8900 [0] 8.1.001.14 distribute_event: message EventReleased
AttributeEventSequenceNumber 0000000002549e87
AttributeTimeinuSecs 890000
AttributeTimeinSecs 1452849816 (09:23:36)
AttributeExtensions [37] 00 02 01 00..
'CauseCode' 10
'UCID' bin: 86 ba 98 56.. (len=8)
AttributeOtherDN '*****'
AttributeOtherDNRole 2
AttributeThisDNRole 1
AttributeThisDN '834907'
AttributeANI '834907'
AttributeDNIS '*****'
AttributeUserData [1037] 00 26 01 00..
'GSW_TZ_OFFSET' 0
'GSW_CHAIN_N' 0
'GSW_PHONE' '*****'
'SPA:Title' '*****'
'SPA:Address 1' '*****'
'SPA:Address 2' '*****'
'SPA:Address 3' ''
'SPA:Address 4' ''
'SPA:Postcode' '*****'
'SPA:Date of Birth' ''
'Daytime phone number' '*****'
'Evening phone number' ''
'Other phone number' ''
'SPA:Notes' ''
'SPA:Lead Source' '*****'
'SPA:Surname' '*****'
'SPA:Max Reschedule Date' '*****'
'SPA:INITIALS' '*****'
'GSW_CALLING_LIST' '*****'
'GSW_CAMPAIGN_NAME' '*****'
'InteractionType' 'Outbound'
'InteractionSubtype' 'OutboundNew'
'GSW_RECORD_HANDLE' 138216
'GSW_APPLICATION_ID' 170
'GSW_CAMPAIGN_GROUP_DBID' 211
'GSW_CALLING_LIST_DBID' 368
'GSW_SWITCH_DBID' 108
'GSW_CAMPAIGN_GROUP_NAME' '*****'
'GSW_CAMPAIGN_GROUP_DESCRIPTION' ''
'GSW_CHAIN_ID' 147023005
'GSW_ATTEMPTS' 20
'GSW_AGENT_ID' ''
'GSW_CALL_RESULT' 0
'GSW_TZ_NAME' 'GMT'
'GSW_CONTACT_MEDIA_TYPE' 'voice'
'GSW_CALL_ATTEMPT_GUID' '9A4BGE345D0LL8JQC2JRO6QKT40038SB'
AttributeCallUUID 'F7NRON4TSL4S553EL2P9MJISOC079A0G'
AttributeConnID 00ca0274723d25df
AttributeCallID 64257
AttributePropagatedCallType 3
AttributeCallType 3
AttributeNetworkCallID 1452849798
AttributeThisQueue '834907'
AttributeCallState 7

[Kubig]

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.

[MancMonkey]

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

like it's only dialling it for 75% of the setting

I really appreciate any help you can give me.

[Kubig]

Post entire log of T-Server covering your issue, I will look at that and provide you with some hints

[MancMonkey]

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.