[cisco-voip] Unicast MOH and MRG Round Robin

[Anthony Holloway]

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