[cisco-voip] Unicast MOH and MRG Round Robin

[Anthony Holloway]

Hi Pete,

Yes the devices are registered and in fact, if I place them one at a time
into an MRG they each individually work. It's the round robin that's not
happening. Cheers.

On Monday, November 4, 2013, Peter Slow wrote:

> 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<javascript:_e({}, 'cvml', '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
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <javascript:_e({}, 'cvml',
>> '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/47991930/attachment.html>