[cisco-voip] Unicast MOH and MRG Round Robin

[Anthony Holloway]

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> 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/20131210/81b5379b/attachment.html>