[cisco-voip] On-Call Solution/Best Practices for CUCM/Unity Environment

[Kim, Hyoun]

I thought the UCCX "Premium" tag only applied to older versions.  We have UCCX 8.0.2.  UCCX is actually used for our Service Desk and we don't use it for anything else, but if an On-Call scenario could be built that's better than how it's handled now, then that's a viable option.

But before I go any further, maybe I need to elaborate how our setup is made and what we don't like about it.  Again, I didn't set it up, it was just inherited by me and my team from the past engineers.  For simplicity's sake, we're going to use my department's (Networking) On-Call setup.

There is a CTI Route Point set up on CUCM for our On-Call setup.  This CTI RP is pointed to a DN which also has a DID attached to it as a translation pattern.  For that DN, we use "Forward All" which we change to our own cell phones during the start of each person's rotations.  Simple enough.  You dial the DID (which we publish), you get whoever is on-call.

On Unity, we have a voicemailbox that is attached to an Exchange mailbox.  This VM is attached to a dummy-non-used extension so  you can't actually leave any voicemail messages on that mailbox.  In the Message Notification options for that VM, we have it monitor the exchange mailbox for any unread messages and use the DN extension that was defined under the CTI Route Point in CUCM.  Whenever that Exchange mailbox receives a new message, the Unity VM's notification setup will call the extension, who then calls the On-Call number being forwarded.   When you answer, you just hear the normal prompt of "This is the Cisco Unity Messaging system notifying you that there are unread messages in your mailbox."

So that is how the on-call is set up for my team and other teams.  This setup was created because there were times (in the middle of the night) where something went wrong/failed and someone had to be notified in some manner.  A simple email to someone's mailbox is usually not enough to wake them up and not everyone has each other's cell phone number.  By doing it in the way that it is described, it makes it a lot easier to wake that person up.  The problem is that to make it stop calling you, you have to go to that mailbox and mark the message as read.  If you happen to not have Internet access at the time, then you will receive calls repeatedly.

Anyway, this is how our On-Call system is set up.  I'm just wondering if there is a "better" way to do this given the CUCM & Unity servers.  I know there has to be other ways to implement an on-call system but I'm just not sure how.

Hyoun Kim
Network Engineer
Network Infrastructure
OHL

This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies.

From: Scott Voll [mailto:svoll.voip at gmail.com]
Sent: Monday, February 13, 2012 3:32 PM
To: Kim, Hyoun
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] On-Call Solution/Best Practices for CUCM/Unity Environment

Do you have UCCx premium?

Could you do a DB dip for the on call person and call transfer to them?

Scott
On Mon, Feb 13, 2012 at 10:15 AM, Kim, Hyoun <hkim at ohl.com<mailto:hkim at ohl.com>> wrote:
Hi all,

It's been awhile since I posted. I was originally posting from Charter Communications but moved to another job that has a fully fledged CUCM/CCX/Unity environment.

Does anyone have a solution for departments using an "On-Call" rotation?  I kind of inherited the existing infrastructure at my new company and the prior voice engineers both left.

Right now the way the previous engineers set it up is via Unity, which is monitoring an Exchange mailbox for any unread messages.  We have other hardware management software that will shoot alerts to this mailbox.  Then Unity is using its notification options to call specific numbers to notify them that they have unread messages in this mailbox.  This is how various departments who have 24/7 on-call rotations are being notified that there are issues that need to be investigated.

While it does work, it requires the person on-call to have Internet access to mark those emails as "read" to force Unity to stop calling.  To me that seems to be a backwards way of using the current environment for departments using a 24/7 on-call rotation, but given my past experiences, I don't know of a "better" way to do this with existing hardware.

Thanks in advance.

Hyoun Kim
Network Engineer
Network Infrastructure
OHL


______________________________________________________

This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


______________________________________________________

This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120213/f9eb0718/attachment.html>