ANI on POST ROUTE ICM 4.6.2

[umassjsp]

When a call comes in from an AT&T toll free number and goes into the IVR is the ANI lost on post route? When I run a query on Route Call Detail for Post Routed calls the ANI is always the DNIS/VDN that entered the IVR. Thanks for any thoughts....Scott

[erestes]

If I understand your call its like this : Caller dials 800 number to att(a Route Request) occurs and the call is directed to an IVR. Is there another ROute Request by the IVR (that your calling Post Route) . Sounds like your IVR application might be doing somethign with the ANI as the call arrives there. Normally the ANI of the caller should show up for every RouteRequest handled by ICM and hence should be in RCD ANI column. PG Logs for the IVR could prove how the Call arrives and the ANI and how the Call Leaves the IVR and what happens to the ANI and other things variables... eestes

[umassjsp]

Thanks for the response. The call comes into the IVR and the IVR uses the DNIS/VDN to trigger the proper IVR application for the caller to hear. When the caller wants to opt out of the IVR the IVR does a post route request to the script and a label is sent back to the IVR so it can direct the call. The ANI in Route Call detail is not showing the number the call came from but is showing the DNIS/VDN of the toll free number dialed. On another client that we Pre-Route the ANI is the number of the phone the caller is using. So it looks like the ANI is lost in the post route scenario.

[erestes]

Ok so you have told me something else.. indirectly.. VDN of course tells me your IVR is behind an Avaya ACD. So I bet you might have VDN Override enabled for the VDN's that send traffic thru to the IVR.. This could be over writing the orig ANI with the respective VDN number when the call goes to the VRU. So really it has nothing to do with the Route Request its just you see it then when it was really changed before the Route Request.. Check that Avaya Setting..

[umassjsp]

Hey Eric-

All of our Avaya vdns going into IVR (conversing to IVR from Avaya) have override set to YES. This is because we want the CSR to see the vdn that the call opts out to (has the correct whisper and display). What I am going to propose to the user on this is to route the ANI's needing special treatment into the IVR on a new DNIS. I can separate out those ANI's using AT&T Route It. The new entry point into the IVR will have its own script in ICM and this will accomplish what they need. I am going to do some more testing with scripts to see if I can discern ANI when IVR makes post route request. Thanks.