These are just some thoughts for consideration. Please validate with your Cisco SE rep regarding final design as I am providing some insight without really knowing your phone/user environment.
1. I can speak to CallManager as that is our environment. The default phone line configuration is 4 calls and busy trigger 2. The Busy Trigger setting, which works in conjunction with Maximum Number of Calls and Call Forward Busy, determines the maximum number of calls to be presented at the line. If maximum number of calls is set for 4 and the busy trigger is set to 2, then incoming call 3 gets rejected with a busy cause (and will get forwarded if Call Forward Busy is set). You may need to consider this number if you want CallManager to forward the call to Unity so that the Busy greeting is presented. If a subscriber does not have a Busy greeting recorded, the Standard greeting is used. So you may need to consider recording a common recording for all subscribers, which sounds like more work to do. An alternate way to do this "might" be:
- Create a CTI route point in CallManager and assign a directory number. This could be a non-DID in your dialing plan. Forward all calls on this directory number to Unity.
- Create a Unity call handler and assign it the same directory number. Create a recording for the call handler that tells callers what menu options they have.
- Create Caller Input keys. Note: Traditional auto attendant applications use 0 as the standard Operator, which you may want to consider. I recommend not using the default Unity Operator call handler. I would use one of your Unity subscribers as the 0-out and code "Attempt transfer for" so that the operator's phone is rung (meaning don't route the caller to another greeting here, but the caller usually wants to reach a live person by pressing 0).
- In each subscriber's phone line configuration setting, uncheck the forward to voicemail if Busy and put in the directory number into the Coverage/Destination field.
- Now when the user's phone is Busy, CallManager will call the CTI route point DN and the Unity call handler will begin execution.
2. Unity is not meant to be an IVR/queuing application. You would use IP Contact Center for that. Unity does have the ability to put the caller on hold. This action only occurs when Supervised Transfer is in affect (calls that came to the subscriber by way of the Unity conversation, call handler or Unity directory handler). The settings for holding options are in the Call Transfer settings for each subscriber. What that means is, if a caller calls a subscriber's phone direct and rolls to voicemail because it was busy or not answered, no option to hold. So I don't think you are going to get the Press 1 to hold functionality you want. Instead, you could have one of the call handler input keys go to a directory handler that contained all of your subscribers as members. Callers could then spell by name and transfer to the subscriber's phone. This would enable Supervised Transfer, providing you have it coded as such on each subscriber's Unity record. Go to Call Transfer and configure Supervised Transfer instead of Release to switch. Include the number of rings to wait, we use 4 for a 20-second ring cycle and also specify either Always Hold or Ask Caller. Unity will place the caller on hold and later requeue the caller to continue waiting or leave a voice message. Check out the Bulk Edit utility which will allow you to update multiple subscribers at once. Or you can create a common subscriber template and apply that to your subscribers as they are created.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...