So a call is going down the failure path of your Queue to Skill Group node because the call is triggering one of seven requery status variables.
| Requery Status Variable | Description |
| REQUERY_ANSWER (0 | Script ends. The call was successfully sent to the chosen target.
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node. |
| REQUERY_ROUTE_SELECT_FAILURE (1) | Routing client generated an error code from ReRouteReq msg indicating a Route Select failure. |
| REQUERY_CALLED_PARTY_BUSY (2) | Routing client generated error code from ReRouteReq msg indicating the called party is busy. |
| REQUERY_NO_ANSWER (3) | Routing client generated an error code from ReRouteReq msg indicating no answer. |
| REQUERY_ERROR (4) | CallRouter generated an error code. The attempt to send the call to target failed because the target was not reachable (i.e., busy, ring no answer). |
| REQUERY_TIMED_OUT (5) | The attempt to send the call to a target failed because the Routing Client did not respond within the DivertOnBusyCallTimeout period. The script ends
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node. |
| REQUERY_ABORTED (6) | The attempt to send the call to a target failed because the caller hung up or the call was lost. In the case of ABANDON and DISCONNECT, the CallRouter assumes the call has ended and ends the script. The RequeryStatus value is set to 6, indicating REQUERY_ABORTED.
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node. |
When it comes to requery status, it's almost always a RONA (3). But to know for sure, you can edit your script with seven IF nodes checking to see if Call.RequeryStatus==0, Call.RequeryStatus==1, Call.RequeryStatus==2... all the way to 6. One of those IF nodes will get the call and go out the success branch... let us know which one it is.
