Unified Attendant Console puts callers immediately to music on hold

[foxsportsau]

Hi all,

I've got a really perplexing problem here. Since someone in our company's support department deleted the Receptionist user from Active Directory, re-establishing that user doesn't seem to have completely restored the Enterprise Console back to its normal settings.

It seems to have an outstanding problem where incoming calls (internal and external) result in the caller being placed immediately into our music on hold. The receptionist's phone does continue to ring, thankfully but it's the caller who will get confused since they're not hearing any ringtone on their end. They may well get confused and just hang up.

Both the internal and external CTI route points (14001 and 14002) are pointing to the same MOH source but while the internal callers get the MOH, the external callers do not. That's not such a big deal for us at the moment but I thought I'd mention it if it helps the investigation.

The real issue at hand here is that the incoming callers don't hear that ringtone and that's what I need to get sorted out. Our console system was (and still is) set up for blind transfers. It was never a problem before this AD user profile was killed.

Can anyone help me out with this one?

[Tim Smith · Accepted solution]

Hi mate,

Yep does sound interesting!

What versions of CUCM and CUEAC are you running?

Are you saying it's basically working normally - i.e. operator can answer and transfer calls (has CTI control from PC of the calls on the phone)

When you say the phone rings, do you mean the phone or the console app on the PC?

Was external MOH always broken or did it work before?

There is a setting in CUEAC to queue the callers immediately "Call on Arrival mode" - is this on?

Cheers,

Tim

[foxsportsau]

To answer in order:

1) CUCM = 8.6.2, CUEAC 8.6.2.11

2) Correct.

3) Apologies. Rings only from the phone. The console application doesn't seem to be making its ringing noises any longer.

4) Not sure as we've only had the system in place for a couple months and we're still building it to what we require. The MOH is the least of our worries at the moment, unless its cause is somewhat related to the bigger problem.

5) I'll have to check this setting when I'm back in the building tomorrow. I can't see why anyone would have changed any settings but stranger things have happened! I'll have a sniff around the manual and find it to see what the situation is with it.

Many thanks for the prompt reply, by the way!

[Tim Smith]

I'm actually wondering if someone has changed your queue settings for example.

So the call is answered from the phone handset or you can also answer it via phone but clicking from the console?

In terms of it ringing on phone - is the queue set to forced delivery?

Only other thing I can think is that CUEAC thinks no operator is logged in (is the operator assigned to queue?) - and maybe it is following an overflow (i.e. max waiting time in queue or no operators logged in) and forwarding to phone directly (but I wouldn't expect user to be on hold in this case)

Yeah I think I would go an double check all your settings firstly. See how you go.

Cheers,

Tim

[foxsportsau]

Certainly sounds plausible and as I said before, anything is possible here. People tend to muck around with things they shouldn't be. It doesn't help that AD accounts tied to these applications/services get wiped out without any forethought.

The call is answered successfully via the console. It is logged in to the respective operator account and reports that it is linked/connected to the receptionist's 8945 handset extension number.

The queue was set to Standard delivery as per the as built document from our vendor. I'll have to check if this is still the case.

For what it's worth, the overflow is set to our security desk's handset so that hasn't been happening. Again, the fact that it reports it's linked to the receptionist's handset/extension is good news and should rule out the overflow. Or am I not thinking this through?

I'll let you know what I find in about 9 hours from now when I'm due in.

Thanks again!

[Tim Smith]

Hey mate,

Yeah so in 9.x you can have local and AD synchronised users. It's been an annoying limitation in my mind for some time. In this case you could really ensure that only CUCM admins could then stuff things up!

When you say it is answered via console. Does the call actually appear as though it's coming through the queue in the console?

Still struggling with why it is ringing on phone direct, it shouldn't do this unless it is set to forced delivery, or for some other reason - i.e. call forward on CTI route point / overflow etc - something that points it direct to the phone. Or even maybe a shared line (which shouldn't be done anyway)

The link to handset, I guess you just mean the console can control the phone. It doesn't necessarily rule out overflow.

i.e. CUEAC config could really say a lot of things with regard to queue config, operator etc, this could be set to do anything. The CTI control over the phone is separate. It just means that CUEAC (via the Cisco TSP) has access and permissions to control the phone, and can monitor that phone / lines and control it. I.e. could really have no queues pointing to that guy, but could still login to operator console and control phone from it.

Very curious to what you discover!

Cheers,

Tim

[foxsportsau]

Hello again,

I agree about the limitation with AD synchronised users only. It would be nice to have them isolated in order to avoid this sort of situation.

There's no doubt incoming calls are getting queued as they do appear in the console's queue.

Something even more odd now is that the phone is no longer ringing directly. There's only two of us administering the system at the moment and neither one of us knowingly messed about with the delivery options. I even checked this morning and it was still on standard delivery. However, in my testing today, the phone handset is no longer ringing directly and it is the console PC that's actually producing the ring tone. It's getting weirder and weirder by the day!

I understand what you mean about the link. I had a feeling I was not totally understanding that concept. Thanks for clearing that up.

What I did discover though was that you were 100% correct about the Call Arrival Mode in the CUEAC server. It was ticked for "Hold queued calls". Unticked it and we're all OK now.

Tim, I can't thank you enough for your help with this! We'll work on the MOH source thing later.

[Tim Smith]

Hey mate,

Yeah, I think it's worth the 9.x upgrade just for this. But to be honest, I'd still let 9.1 get a few service updates under it's belt before upgrading.

It sounds like a couple of strange things going on there, but the PC ringing is how it should be operating correctly. Just to be sure, I'd maybe test this under a few scenarios and record your results - i.e. op logged off, out of hours etc, multiple calls on console in queue, wait in queue etc.

As I said before, the phone should only ring if forced delivery is on.

People do this typically in very small environments where they may have wireless headsets that they want to answer when away from desk, or maybe they want to do a call forward from phone.

No problems!

With the MOH, go back to basics and make sure this is all operating correctly with normal calls internal / external.

You also need to work out the exact failure. i.e. do you get complete silence, or do you get occasional beep (tone on hold) - it will help point you in right direction.

Cheers,

Tim.

[foxsportsau]

Will do. It's complete silence for the external callers and the generic Cisco MOH for the internal callers. They're both pointing to the same source, which is what's odd but I'll be checking that out sometime next week. I'll be sure to contact you through this forum (new thread) when that happens. Thanks again!