Hi Randy
Trying to achieve best practice behavior.. (when you know your inboundcall has disconnected -you want to skip all future behavior such as calling DB's/WS etc.. )
Seems to me -no one really have reasonable solution for that..(i think its a threading issue)
I'm basically very familiar with handlers and i can tell you we're using "Get-attribute" to check eic_state after "extended-get-key"' fails with error.
We expect the system to have the correct state ("E") - but it doesn't
Do you have some other way you can think of in a synchronous way? (i know about the "wait for disconnect" tool but it should be placed asynchronous and i'm tring to keep it simple.Moreover,if the "eic_state" is being delayed -i think the "wait for disconnect" will too)
Thanks 4 your help
------------------------------
Avi Rozen
Harel
------------------------------
Original Message:
Sent: 07-15-2019 19:33
From: Randy Drielinger
Subject: Best condition for RT client disconnected within IVR
What are you trying to achieve, after detecting a client side disconnect?
It is possible with handlers, but I'm trying to figure out the use case here.
------------------------------
At 3Fiftynine impossible is just a challenge
We provide kick-ass products on top of Genesys platforms
Original Message:
Sent: 03-13-2019 08:58
From: Avraham (Avi) Rozen
Subject: Best condition for RT client disconnected within IVR
Hello community
Recentely we've noticed that eic_state="E" for analyzing disconnects (client side) within the system IVR is NOT good enough (Stays "S")
Then we moved into eic_CallStateString="%12307%" which covers 80% of the cases...
Still no 100% ..Sometimes the eic_CallStateString inticates of "System" or "ACD-Wait agent" although it should become "Disconnected"
I'm sure there is a reliable system attribute which can be checked right after "ExGetKey" tool fails to play audio-
Have someone handled this kind of thing ?
TNX
Avi
#Handlers
------------------------------
Avraham (Avi) Rozen
Harel
------------------------------