The forward no answer setting has been a topic of discussion for some time and I understand that Cisco is working to correct the inflexibility in the future however I am in search of a workaround if anyone has any ideas.
We have setup unity 3.1(4) with CM 3.2 and are integrating with a Toshiba 424 phone system with Toshiba Stratagy ES voicemail server. The legacy system has individual settings per port for the timeout to forward to voicemail. The ports vary from 12 seconds to what seems like 20. We have the PSTN lines terminating on a 6608 with Unity answering as an AA. Each user has an account setup within Unity and is set to forward to the extension when called. That is where it gets tricky.
If we do a 'release to switch' transfer, when callers press an extension to route to a user still on the legacy system (which is the majority) the call will forward properly using the DNIS routes we setup across the intra-system trunks however on phones with a longer foward no answer timer than what the CM system setting is, the call gets bounced back to unity. If the users timer is less than CM all is good and the legacy voicemail answers the call and the new system is seamless to the user.
If we do a 'supervised transfer' with the rings jacked up to 10 to allow for even the longest timer on the legacy side everything seems to run smoothly. Users get their calls, calls go to the legacy system and our IP users have a normal forward timer of 12 seconds. The problem is there is no MOH so if a caller is transferring to someone who is not at their desk they hear 12-16 seconds of silence which of course creates the concern of "did I get disconnected?"
So now we are setting back to a long timeout on CM (like 30 seconds) with 'release to switch' to appease the masses but this leaves the IP users with an unacceptably long timeout for their calls to go to voicemail.