[cisco-voip] UCCX Support for Direct Dial to an agent whether logged in or not

Fri Nov 15 11:56:43 EST 2013

Totally agree with you, in addition to that they lose their reporting capability.

:-:gm

Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342
grace.maximuangu at blackbox.com<mailto:grace.maximuangu at blackbox.com>
www.blackbox.com<http://www.blackbox.com/>

[cid:image001.jpg at 01CEE1E0.9B631950]

From: Tanner Ezell [mailto:tanner.ezell at gmail.com]
Sent: Thursday, November 14, 2013 5:02 PM
To: Grace Maximuangu
Cc: Anthony Holloway; Cisco VoIP Group
Subject: Re: [cisco-voip] UCCX Support for Direct Dial to an agent whether logged in or not

There are some very fundamental design problems at the root of your request, starting with entertaining the idea of ACD line voicemail.

Technically possible. Would not recommend.

On Thu, Nov 14, 2013 at 3:57 PM, Grace Maximuangu <Grace.Maximuangu at blackbox.com<mailto:Grace.Maximuangu at blackbox.com>> wrote:

What we are looking for is a way that, whether agents are currently logged in or not logged in, that  agent must be able to receive direct dial calls on their agent line, for instance if agent 1234 is logged in as level 1, and I dial "1234", their phone should rings, and if they don't answer, it goes to their voicemail.

Is this possible and what are the implications of doing this?

:-:gm

Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342<tel:213.268.6342>
grace.maximuangu at blackbox.com<mailto:grace.maximuangu at blackbox.com>
www.blackbox.com<http://www.blackbox.com/>

[cid:image001.jpg at 01CEE1E0.9B631950]

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Anthony Holloway
Sent: Monday, November 04, 2013 1:18 PM
To: Anthony Holloway
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin

This is also affecting my 9.1.2.10000-1 cluster as well.

On Monday, November 4, 2013, Anthony Holloway wrote:
It was case sensitivity on the MOH server name.

If you rename your MOH from MOH_2 to Sub2_MOH you will see it happen as well.

I played with all capitals and it started working.

I will report this via TAC and get an update out to the list.

Thanks Daniel.

On Monday, November 4, 2013, Anthony Holloway wrote:
That was helpful, thank you.

It looks like the issue is the counter not being incremented.

RTMT is showing 150 active streams and the SDI trace shows a counter of 0 for all four MOH.

In the SDI trace I see the line:
14:44:32.746 |MRM::updateMohCounter devName=SUB02B_MOH, countChange=1...

My actual MOH server is named Sub02b_MOH. note the case difference. I'm wonder if you have a case discrepancy as well?

I too am running 8.6(2a). Specifically 8.6.2.22029-1.

Thanks again.

On Monday, November 4, 2013, Daniel Pagan wrote:

This is also my understanding of how CUCM allocates the same media resource type within the same MRG. My lab is currently on 8.6(2)a and I'm unable to recreate the problem - I've placed two calls, back to back, and put both on hold while having two MOH servers (MOH_2 and MOH_3) in the same MRG assigned to the called device MRGL. CUCM allocated MOH_3 for the first call and MOH_2 for the second call.

Going to CCM SDI traces, do you see CUCM immediately allocating the same MOH server? In other words, is there a chance you might have missed previous MOH allocation failures for your other MOH resources in the trace file? Do you see a sendMohAllocateRequestToDevice event for other MOH resources prior to the allocation of the overused MOH server?

Also, some trace entries that might be of interest:

MediaResourceCdpc(8)::createLookupTbl Name=MOH_2 Cepn=cfb5e1cd-fa16-495f-a380-7b7e75b1887c Weight=0 Group=0 Counter=0

MediaResourceCdpc(8)::createLookupTbl Name=MOH_3 Cepn=cf2d51e6-ece4-403b-b096-ed188521ab40 Weight=0 Group=0 Counter=1

(counter = number of simultaneous allocations)

(group = the MRG priority within the MRGL)

In the slight chance you do see other (failed) MOH allocation requests prior to the allocation of your overused MOH server, I would also look at and compare the capabilities for the MOH and held party to make sure there's a match:

logCapabilitiesinTrace -- MOH Caps = 4

logCapabilitiesinTrace -- Held Party Caps = 4 2 10

(4 = g711ulaw... 2= alaw)

Hopefully some of this helps.

________________________________
This email and any files transmitted with it are confidential and are intended for the sole use of the individual to whom they are addressed. Black Box Corporation reserves the right to scan all e-mail traffic for restricted content and to monitor all e-mail in general. If you are not the intended recipient or you have received this email in error, any use, dissemination or forwarding of this email is strictly prohibited. If you have received this email in error, please notify the sender by replying to this email.

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131115/279e6f17/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2975 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131115/279e6f17/attachment.jpg>