GMS Callback - state of call isn't good for routing

[akalvi]

Hi,

I am facing the same issue of "state of call isn't good for routing." I have downloaded the DFM files from GMS admin UI and have referenced them in the ORS as well. But I am still getting the same error. Do i need to perform any more changes?. Thank you!

GMS is 8.5.114.09; Sample is Voice-Now-UserOrig


08:09:46.000_M_I_ [10:1d] PULSE over: 0 cpu 1 objects 1 trgs
08:09:48.000_M_I_ [10:1d] PULSE (calls: 3(3)=3+0-0, trgts=1, first=0,1, time=1426864188, mem=11366,98[201],14,186[3910],0,0 - 2,0,0)
08:09:48.000_M_I_ [10:1d] vqs allocation pattern: static=(13-3600 256 256) dynamic=(2 2/1024)
08:09:48.000_M_I_ [10:1d] check queue for SO <Test> type <Agent> stat <##state> (1 trgs 0 cpu)
    _M_I_0000000000000000 [10:20] try to route to ag "Test" (pl "3000", 1 ready DNs, 1 trgs): TRG 00000000012df1f0 VQ 00000000012df088 "" (1 calls), 1426864250, 0, 180aa
    _M_I_ [10:0b] ag Test, pl 3000, sw SIP_Switch dn 3000 isn't blocked absolutely(0)
    _M_I_006f02605ceb3004 [10:21] try to route to ag "Test" (pl "3000", 1 ready DNs, 1 trgs): TRG 00000000012df1f0 VQ 00000000012df088 "" (1 calls), 1, 0, 180aa
    _J_I_006f02605ceb3004 [0E:19] check call routing states (vq 00000000012d9fc8): s=4 d=0 t=0 h=(0 0 0) r=0 i=0 x=0 b=1 - false
    _M_I_006f02605ceb3004 [10:21] state of call isn't good for routing
    _M_I_006f02605ceb3004 [10:21] call vcb states 0 (62:85:0)
08:09:48.000_M_I_ [10:1d] PULSE over: 0 cpu 1 objects 1 trgs
08:09:49.000_R_I_ [19:10] routing interface request received: urs/call/006f02605ceb3004/lvq?name=&aqt=urs&filter=ewt%2Ctime%2Cwt%2Ccalls%2Cpos%2Cwpos%2Chit%2Cpriority, client=584(ORS), ref=153
08:09:49.000_R_I_ [19:11] routing interface response 'Info' sent to client 584(ORS), ref=153
Message: {}

[Kubig]

Check ORS log to find the root-cause

[akalvi]

ORS doens't show anything. Below are the only events against the call.

10:27:40.493 Int 04543 Interaction message "EventCallCreated" received from 65200 ("SIP_Svr")
10:27:40.496 Int 04543 Interaction message "EventCallPartyAdded" received from 65200 ("SIP_Svr")
10:27:40.500 Int 04543 Interaction message "EventCallPartyAdded" received from 65200 ("SIP_Svr")
10:27:40.500 Int 04543 Interaction message "EventQueued" received from 65200 ("SIP_Svr@8999")
10:27:40.501 Int 04543 Interaction message "EventRouteRequest" received from 65200 ("SIP_Svr@8999")

[cavagnaro]

You need to check URS and TServer logs
That means that agent probably was doing something when URS tried to send the interaction to it

[akalvi]

Actually it is a lab environment and there is only agent logged in and there is only 1 call being initiated to check the callback using GMS sample application. Agent is available and ready for the call, but the call is not routing to him.

Someone in another thread had mentioned about updating the DFM files locally which solved a similar problem, not sure what he means by locally.

Thanks!

[cavagnaro]

Still would check URS and TServer logs.
You are missing something then in your configuration


Enviado de meu E6633 usando Tapatalk

[terry]

Basically:
- in "check call routing states (vq 00000000012d9fc8): s=4 d=0 t=0 h=(0 0 0) r=0 i=0 x=0 b=1 - false"
b=1 here means that call cannot be routed because of outbound call with customer is not established yet (either there is no outbound call to customer done at all, or done but customer not answers yet, or whatever else).

-  "_M_I_006f02605ceb3004 [10:21] call vcb states 0 (62:85:0)" means that URS for this call already initiated notification to dial the customer  (sent some message to ORS, look for "web notification .... sent" message in URS log about 30 or 60 seconds earlier).

Probably you will need to check in ORS or GMS logs what happened with this notification (as when/if customer answer outbound call GMS expected message to URS which clear b=1 flag and make possible routing the call).



 

[gawix]

The interaction 006f02605ceb3004 is actually the virtual interaction waiting in queue. This interaction is not meant to be routed. So what you see is normal even it looks like an error message (btw, same thing happened to me). When it reaches the top of the queue, the virtual interaction should trigger an HTTP notification to GMS (which will forward it to ORS) and then procede with the rest of the callflow (send notification to customer's device?).

More details about VCB HTTP notifications in the white paper:
[url=https://docs.genesys.com/Special:Repository/VoiceCallBackWhite.pdf?id=52925528-fa1f-43ff-9351-422266e1568f]https://docs.genesys.com/Special:Repository/VoiceCallBackWhite.pdf?id=52925528-fa1f-43ff-9351-422266e1568f[/url]

Yes, 8.5 GMS callbacks are using old URS callback mechanisms.

[cavagnaro]

For sake of knowledge can you share how does it works? How does URS does the VCB internally? Never found any documentation on it with details

Enviado de meu E6633 usando Tapatalk

[terry]

Unlikely there is documentation describing it in more details then referred white paper.

And on lower details (or high) level it is pretty simple.
- All interactions (real, virtual) are the same for URS. Strategy runs for all of them, all are in queue(s), all need to be routed. Some difference is on last step (routing itself) - sometimes it is enough just send RequestRouteCall, sometimes it is more complex -  dial to customer first, wait him answers, connect outbound call with selected agent, etc).

- VCB interactions might be virtual from the very beginning (started by web request to URS, effectively scheduled VCB) or be real first and turned virtual when customer hang up after ordering VCB - URS continue strategy as if nothing happen, just call is virtual now (sort of ASAP VCB).

- When it is time route virtual call (it is selected for agent or some agent selected for it).
  a) Agent first scenario. Agent is locked after this VCB interaction. Either URS itself do all outbound stuff and when all Ok connect customer with
  the agent. Or URS just send outside (to GMS for example) web request about interaction and selected agent (sending web request is analog of
  sending RequestRouteCall). Task of URS is completed in such case and now it is GMS responsibility to connect customer ()dial to him first, etc
  and agent. Agent is locked after virtual interaction for transition_time seconds only - everything should be done within this period (or alternative
  locking like agent tagging to be used).

  b) Customer first scenario. Interaction is marked as not routable (DoNotSelectCall function). Such interaction cannot be routed (you get state
  of call isn't good for routing with b=1). Instead of router however in such case URS again will send "dialing" message (to itself, to GMS, to
  whoever will be pointed to). Message receiver supposed to dial customer, wait him answer, etc. Agent doesn't wait it (some other call will be
  routed to him). If customer answers then message receiver supposed to notify URS and make him clear DoNotSelectCall flag so virtual
  interaction can be routed now. This virtual interaction is quite ahead in queue (otherwise notification were not sent) and when NEXT agent
  becomes available it will be routed. Interaction still might be virtual (from URS perspective) and its routing might means sending a web request
  (see case a) above) just there will be no need to dial customer - it is already dialed.
  URS tries to route every time some agent becomes ready -> means rate of dialing notifications basically "proportional" to rate agents become
  ready events (minus proportion of not vcb calls - if one of not vcb calls is ahead in queue it will consume agent ready event, it will not come to
  point of attempting route vcb call and will be no dialing message).







 

[cavagnaro]

Are there any strategy samples for this scenarios??

[akalvi]

Hi All,

Thank you all for the help!

I had restarted the VM and re-configured external Cassandra and it seems to have done the trick. Still not sure what exactly helped, but was able to receive the sample callback call using VOICENOWUSERORIG.

Regards,
akalvi