[cisco-voip] Unicast MOH and MRG Round Robin

[Anthony Holloway]

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
>
>
>
> - Daniel
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<javascript:_e({}, 'cvml', '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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131104/918b87ab/attachment.html>