[cisco-voip] Unicast MOH and MRG Round Robin

[Daniel Pagan]

>From what I recall, the 'getMohDeviceGivenMrgl' will display all MOH servers available in the MRGL regardless of registration like you mentioned, but the lookup table (createLookupTbl) that occurs slightly below these results should not display unregistered resources by name but by its PKID; sendMohAllocateRequestToDevice shouldn't be performed for an unregistered MOH resource since this occurs post lookup table.

Thx

From: Peter Slow [mailto:peter.slow at gmail.com]
Sent: Monday, November 04, 2013 11:48 AM
To: Daniel Pagan
Cc: Anthony Holloway; Cisco VoIP Group
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin

Those MOH servers are going to show up in the MRG config page and also in the traces regardless of if they're registered or not, and I'm pretty sure the same is true for RTMT in at least some places.
under ccmadmin  for your MoH servers, do they all show as being registered? .. to what server? ...and can you confirm that we're specifically discussing unicast MoH and that that's the counter that you're looking at in RTMT?
Bring me your fun Media issues,
-Pete


On Mon, Nov 4, 2013 at 10:07 AM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> 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

- Daniel

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: Friday, November 01, 2013 2:44 PM
To: Cisco VoIP Group
Subject: [cisco-voip] Unicast MOH and MRG Round Robin

All,

I have read and re-read the sections on MOH  and MRG[L]'s and I still cannot seem to figure this one out.

I have an MRG with four MOH servers. The phones are using the sampleaudio MOH. Only one MOH server in my MRG has streams active. It's currently at 140 streams according to RTMT. The remaining three show 0 active streams.

Traces show the one MOH server being selected all the time, as the first resource in the group, to be sent an allocation request, and it responds; therefore, it gets used. The remaining MOH servers go unused.

I have proven that each of the three idle MOH servers do work, by removing all but one MOH server from the MRG, and sequentially testing each one.

I'm starting to doubt my understanding of MRG resource selection as it pertains to MOH. I'm looking for confirmation or clarification on how this works.

CUCM version is 8.6(2a). Thanks for looking.

_______________________________________________
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/20131104/b124d229/attachment.html>