Too much "target [...] is not valid or not current" instances in URS 7.5 logs

[Gef Buneri]

Hi all,
I'm noticing a very high amount of interactions generating this error message. An extract from URS logs of a dropped itneraction:

_I_I_009c0235ebf5f6d1 [07:2d] HERE IS DELIVER TO TARGET(1): returnk|dn:601|rdn:601|switch:GVP|target_locatio n:StatServer75URS|target_name:601_GVP|target_type: RP
_I_W_009c0235ebf5f6d1 [07:2d] target <returnk|dn:601|rdn:601|switch:GVP|target_locati on:StatServer75URS|target_name:601_GVP|target_type :RP> is not valid or not current
_C_I_009c0235ebf5f6d1 [0D:03] option use_translation= 0
_I_I_009c0235ebf5f6d1 [0E:03] NO TRANSLATION for this call
request to 65250(TServer_S8700_AES1) message RequestUpdateUserData
AttributeReferenceID 1327
AttributeUserData [31] 00 02 01 00..


Many of the interactions manage to go ahead after some trying, others simply go disconnected. The total interactions offer is near 20k calls per day, and today from 8:00am since 11:00am I've got 3758 total GVP interactions and 1487 were disconnected at the point you see in logs extract, as abandoned:

23:34:11.551_T_W_009c0235ebf5f6d1 [14:32] EventAbandoned is received for tserver IVRServer2[GVP] (this dn=601), delete call
23:34:11.552_I_I_009c0235ebf5f6d1 [07:48] suspend function
23:34:11.552_I_I_009c0235ebf5f6d1 [01:08] call deleting SVC_Abandoned
23:34:11.552_I_I_009c0235ebf5f6d1 [07:49] resume function
_I_I_009c0235ebf5f6d1 [07:42] jump to strategy *0x65*SVC_Abandoned
23:34:11.552_I_I_009c0235ebf5f6d1 [09:06] >>>>>>>>>>>>start interpretator
_I_I_009c0235ebf5f6d1 [09:04] ASSIGN: __Return(SCRIPT) <- STRING:
_I_I_009c0235ebf5f6d1 [07:46] no error mode for this call


Any tips on how to investigate reasons causing this behaviour ?


Regards,


Gef.

[Kubig]

RP 601 is a Routing Point as I understand, so what say logs for routing on this RP (T-Server and URS)?

[Gef Buneri]

Hi Kubig an thanx in advance for your interest. Can you tell me what exactly to search in logs, to help me answer correctly to your answer ? What instances to find in files ? That block is used in IRD 7.5: ( RETURN = DeliverCall['return:ok|dn:601|rdn:601|switch:GVP|target_location:StatServer75URS|target_name:601_GVP|target_type:RP',DELIVERTOAGENT] ) followed by an IF block with " GetCurrentSwitch[]='GVP' " to deliver the interaction to GVP, so I can use studio applications like "play&collect", "play&continue", etc. 'cause the only method I have (or I know) to play announcements in our system, is to play .vox files from IPCS servers. Consider is a method I eredited from the provider, so sorry if I miss some details on the whole logic process. I'll try to compensate asap

[Kubig]

I am not so familiar with GVP in version 7.x and of course do not know your routing architecture. So, could you please describe how you route the calls to the GVP - call on specific RP where you find free VTP port?

[Gef Buneri]

In a full H.323 behind the switch scenario, An avaya s8720 receives the call, establish an adjunct using VDN-RP relationship (same number for Avaya VDN and Genesys RP). On the RP i load an IRD application where the interaction is managed, then given back to Avaya for physical routing to H.323 phones linked to agents using DN(extension)-place(hostname) association through Configuration Manager. When interaction arrives on IRD application, if I have to use audio messaging, I use the functions listed in my previous post, and when I have to route the interaction, I use a 201 "Play&exit" application that generates an abandoned event, I use this event to route the call on a default RP where is loaded the terminal part of the application, where, using a SelectDN VQ/AG syntax in a function block, the call is routed to the selected target. The "weird" behaviour happens at the very beginning of the IRD application, where the DeliverCall function is used to invoke GVP resources (That 601 DN). VTPs are assigned dinamically when asked by the system, through a licensing logic. The GVP have got a redundant architecture: 2 IPCM, 4 IPCS, 1 EMS, 2 AES, 1 EMPS plus 2 management sun os servers (storm/skyline). Hope I answered.

[terry]

Unlikely "target is not valid or not current" message itself is the reason.
This message is just warning and not prevent URS from issuing RequestRouteCall.
The meaning of the message is argument-target of DeliverCall function doesn't match with LATEST selected target for this call.
Most usual use cases for this message to appear:
- target is constructed manually (not through SelectDN function or
- ClearTargets or second SelectDN was used between first SelectDN (which output is used for DeliverCall) and DeliverCall.
In other words anything that could clear/override result of first SelectDN.

Probably better is trying to track some selected failed call.
-in URS log - was requestroutecall following execution of DeliverCall function?
- in tserver logs - how this request route call was processed - was call delivered to RP on not and if not then why?
- again in URS log (assuming all is still Ok) - how URS reacts on EventRouteRequest on this destination RP?

[Gef Buneri]

Thanx Terry, I'll look in logs and will answer your questions asap.