Hi there everyone. Here's a question you experts will laught at me for...<br><br>The owner of our company needs to have all of his calls picked up during business hours (so line 1 goes to line 2 goes to an operator). However, while the office is closed, I'd like to setup a VM for him (so line 1 to line 2 to VM). This all needs to be done without him having to call forward everything to VM (i.e. this schedule should be transparent to him)<br><br>Our setup here is Cisco Call Manager 3.0(9) and Unity 2.4.<br><br>Any help would be greatly appreciated.<br>Thanks!<br>Alex<br><br>IS/IT Administrator<br>Maguire Partners<br>555 W. 5th St. Ste. 5000<br>Los Angeles CA 90013
Not gonna laugh at this one, since there's probably half a dozen ways to do this if you count routing rules & phone system programming, but here's a method that uses just his mailbox & a call handler for the second line. As usual, the tricky part is how the phone system will present call forwarding information to the Unity.
First, let me make sure I understand the scenario. There are two line appearances on his phone. His calls MUST be answered by a live person during business hours. His calls must still ring his phone after hours, but forward to a message box if not answered. Is that it? OK, let's get to work.
For the sake of this example, let's just say that his primary extension number is 100 (configured as a subscriber), and the secondary appearance is 200 (configured as a call handler). The operator will be at 0, using the Operator Handler. Let's also assume (since it gets installed by default) that there is already a schedule defined called Weekdays, which represents business hours.
Set up his subscriber account as extension 100. Set call transfer to 'Yes, ring subscriber's extension'. Use release to switch transfer. This should ring line 1 when a caller dials x100. Cake so far, right?
Here's where it gets tricky because of the switch. Does line 1 forward back to Unity, or does it forward to line 2? We can do it either way, so bear with me if this gets a bit confusing -- but the Unity programming will pretty much be the same regardless.
If line 1 forwards back to Unity, fine. Set up his mailbox (100) to use the Alternate Greeting. Record it to say something like, "Now attempting line 2", or whatever seems appropriate. Set the action after greeting to 'Send Caller to Call Handler', and select the x200 handler. Make sure to choose 'Attempt transfer for' instead of 'Send to greeting for' in the Call Handler selection screen.
So now, when a caller dials x100, it should ring his primary line, forward back to Unity, and then attempt transfer for x200. Groovy.
OK, let's check out the handler for x200. See, the cool thing about call handlers (as opposed to subscribers) is that you can apply a schedule to the transfer settings. So, on the Profile page, make sure the extension is entered, and the Weekdays schedule is active. Still with me?
On the Call Transfer page for the x200 handler, make sure Alternate is disabled, and Closed is enabled. For Standard transfer: Yes, ring a subscriber at x200. Release to switch. For Closed transfer: Also set this to ring x200. Release. For Standard Greeting: Record something like, "You will now ring the receptionist", and set the action after greeting to send caller to the Operator Handler (remember to pick 'attempt transfer' instead of 'send to greeting'). For the Closed Greeting: Here's where you record his actual "Please leave me a message" greeting. Set the action to Take a message. Make sure this dude is selected as the message recipient on the Messages page so that he actually gets them.
Great. Now whenever the autoattendant gets a call for x200 during business hours, it will ring x200. But here's where the phone system can make a difference. Regardless of whether it forwards from x100->x200->Unity or x100->Unity->x200->Unity, it's very important that Unity sees the forwarded call from x200 as exactly that. Sometimes, secondary line appearances are masked to show up as the primary, and in this case it would break the application. Similarly, if it bounces from 100 to 200 and then to voicemail, but it shows up as as the original forwarding station (100), we're in trouble. So this may affect how you program the phone system... hitting Unity twice is less efficient, but we need the forward from 200 to show up that way.
Now, when the call goes back to Unity as a forward from x200, the schedule comes in to play. If it's daytime, we attempt transfer for the operator, or whoever it is that writes his messages down on a pink slip of paper. If it's after hours, Unity does a paperless version of that job by recording a message & lighting the lamp (if enabled) for x100.
The caveat is that he really shouldn't ever change his transfer or greeting options for x100, as that could ruin the whole deal. This shouldn't be an issue since it's really just a fancy night message box, but keep that in mind.
Hopefully that will do the trick for you, let me know if anything needs clarification.
Scott Morgan Cisco Systems TAC
"Hey, you're not related to that other monkey, are you? He still owes me twenty bucks!"
One more thing I forgot to mention... notice that I refer to call handlers as "cool" because they can have different transfer schedules, but in my example I have both Standard & Closed transfer for x200 doing the same thing?
Well, let's say that in this case, the phone system CAN'T present a forwarded call from x200 as anything other than x100. Either it's masking the secondary with the primary all the time, or it's retaining the original forwarding station ID -- such that any forwarded call from x200 will still appear to Unity as x100. If that's how it works, you're going to want to have forwarding in the phone system set up like this: 100->200->Unity ... this way it will ring both lines, forward back as if from x100, and then get sent to handler 200 after the greeting.
Well, in that case your programming for x100, the subscriber box, would still be correct...though you might want to blank out the alternate greeting so it doesn't say, "Trying line 2". What you would need to change is the transfer programming for the call handler at x200. Standard Transfer: Attempt transfer for Operator rather than x200 -- ring console during the day. Closed Transfer: Do not transfer -- go directly to voicemail to take a message.
Thank you for your posts, they were very helpful. However, the solution I ended up with was rather different to the one you posted (or, and this is more than likely the case, I just didnt understand it all and stumbled my way through and got lucky!)
So this is what I did:
1. I created a new schedule (to more accurately reflect his times in the office) 2. I created a new call handler (based on the Operator handler with no extension associated) 2b. Standard greeting to x300 (Operator) 2c. Closed greeting to handler greeting 3. Then for the subscriber I did the following: 3b. Standard greeting set to transfer to call handler 3c. Busy greeting set to transfer to call handler 3d. Closed greeting set to take message.
I just tested this during business hours and get transferred properly. I also adjusted the schedule in use by the subscriber to make all of today closed and was greeted by his voice mail.
So, looks like my issue was resolved.
Again, thanks for your input, its greatly appreciated. Alex
IS/IT Administrator Maguire Partners 555 W. 5th St. Ste. 5000 Los Angeles CA 90013
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...