URS report_targets / infomart

[PFCCWA]

hello
i am working on a report to show ISCC multi site transfer calls which are not completed (or fail - eventremoteconnectionfailed). in this scenario the call fails on the XRP (external routing point) due to the target place being busy (Event destination busy).
i have found and extracted the calls but we want to know which agent was the target before it failed.
But i cannot locate the target agent.  on reading the icon/infomart guides i think i need to enable URS option 'report_targets' to true?
presuming this will add resource load but sounds like we have no other choice as the reporting is not possible without it.  we use load balancing across multiple URS' but logging is standard unless we have a fault.
also can we report on the reason for the multisite failure? i.e. it was cased by the destination busy?

thanks

[cavagnaro]

  Why don't just increase the XRP DNs? Would fix your problem.
URS is targeting just agents via ISCC? If so then you just follow the call in URS and when it does the target selection you will see Agent chosen, nothing special or different? ISCC then is performed by your TServer by acknowleding that the target is masked as an Access Code or Trunk





But i cannot locate the target agent.  on reading the icon/infomart guides i think i need to enable URS option 'report_targets' to true?
Yes, in this way URS adds new UData/KVPs printing that information, otherwise, won't be available

[PFCCWA]

We have a t-server /switch set up (no SIP).
Once the call has routed i dont think we have any control of the call (it fails on the XRP with user busy messages on the site tserver).  The agent may be having issues or making themselves busy after genesys has registered ready state.
we can follow the call in the logs but have a large number to shift through.  There might be an app we can use to extract this but the number of logs is large so prefer to do this through reporting -if possible.

thanks,

[hsujdik]

report_targets is recomended for info mart, and shouldn't increase your load in a way it would matter

[cavagnaro]

For what you describe I think your XRP is busy when the ISCC transaction starts, that can happen if you have a lack of XRP on the remote side or on how remote TServer monitors XRP.
Which PBX is this? Another possibility is that if you are not using SIP links, maybe your ISDN/E1 links are being saturated?


Agent being busy should be treatable by RONA on TServer or URS on_route error options as any other agent. That is what makes me think you are having a XRP problem rather than agent being busy when URS selects him.