[cisco-voip] Unicast MOH and MRG Round Robin

Tue Apr 8 13:49:20 EDT 2014

From your case, was the recommendation that all SCCP media resources should be all CAPS?

Dennis Heim | Solution Architect (Collaboration)
World Wide Technology, Inc. | 314-212-1814

PS Engineering:  Innovate & Ignite.

From: avholloway at gmail.com [mailto:avholloway at gmail.com] On Behalf Of Anthony Holloway
Sent: Tuesday, April 08, 2014 1:45 PM
To: Heim, Dennis
Cc: Brian Meade (brmeade); Cisco VoIP Group
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin

During my troubleshooting TAC case, which resulted in identifying this as a defect, I was told that it would affect all SCCP media resources.  Though, I have not validated this claim.  If you have the time to validate, please do so, and upload your trace file section so we can confirm it is in fact happening and for the same reason.  Thanks.

On Mon, Apr 7, 2014 at 11:05 AM, Heim, Dennis <Dennis.Heim at wwt.com<mailto:Dennis.Heim at wwt.com>> wrote:
Does this only impact MoH resources, or would MTP’s also be impacted?

Dennis Heim | Solution Architect (Collaboration)
World Wide Technology, Inc. | 314-212-1814<tel:314-212-1814>

PS Engineering:  Innovate & Ignite.

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Brian Meade (brmeade)
Sent: Wednesday, December 11, 2013 9:50 AM
To: Anthony Holloway; Cisco VoIP Group

Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin

If anyone needs this fix on 8.x or 9.x, open a TAC case and we can get this put into an ES for you.

Brian

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Anthony Holloway
Sent: Wednesday, December 11, 2013 12:38 AM
To: Cisco VoIP Group
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin

Here is the defect for this issue, and the fix is in 10.5

https://tools.cisco.com/bugsearch/bug/CSCul53246

On Mon, Nov 4, 2013 at 3:13 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> 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.

Thx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140408/0d20dcce/attachment.html>