We have recently deployed an IP-IVR running CRS 4.0(5) working with a CallManager 4.1(3) cluster. The purpose is to play an "upfront" announcement ('This call may be recorded...') before sending the call to the user's phone. Most devices use the Unlimited-CSS Calling Search Space, which is allowed to access the Internal-Part partition. Upfront phones are placed in the UFA-Part partition, which the Unlimited-CSS is not allowed to dial directly. Instead a phone or gateway with Unlimited-CSS matches a wildcard CTI Route Point/JTAPI Trigger that sends the call to the IP-IVR. The IP-IVR captures the original dialed number, plays the announcement, then redirects the call to the original dialed number.
For example, a call comes in for 315-5111. 315-5111 is in the UFA-Part partition. Since the PSTN gateway (with Unlimited-CSS) can not dial the UFA-Part, it matches the 315XXXX CTI Route Point. This passes the call to the IP-IVR, which stores the original dialed number (3155111) in a variable, plays the announcement and redirects the call back to 3155111. The IP-IVR (and its CTI ports) are allowed to dial the UFA-Part partition, so after the announcement the call is delivered to the UFA phone.
That works great...the issue comes in when a non-UFA (normal) phone - let's say 315-5222 - receives a call. The 315-5222 line is configured for Call Forward No Answer (CFNA) to a UFA phone (such as to 315-5111). If I use a CSS on the CFNA config that allows the call to be sent to 315-5111 in the UFA-Part then the CFNA forward completes fine, but the IP-IVR is bypassed and the announcement is never played (bad). If I use a CSS that blocks the UFA-Part, then the CFNA forward call matches 315XXXX and the call is sent to the IP-IVR. The problem is the original dialed number is still 315-5222, so that is where the IP-IVR will send the call after playing the announcement - rather than the 315-5111 CFNA destination. The script can capture the redirect number, but since it matches the CTI wildcard Route Point, when the call arrives at the IP-IVR the redirect number is 315XXXX. I do not believe 315-5111 is sent to the IP-IVR at all.
The IP-IVR can capture "arrival type." Normally this is "Direct," but gets set to either "Redirect" or "Call Forward No Answer" in the case described above. My question is can anyone see a way around this and/or if the script detects the arrival type as Redirect, can the IP-IVR script reach into CallManager to see what the CFNA destination is??
Any other ideas welcome!
Thanks - Rob.