[cisco-voip] Unicast MOH and MRG Round Robin

Anthony Holloway avholloway+cisco-voip at gmail.com
Tue Apr 8 13:44:42 EDT 2014


During my troubleshooting TAC case, which resulted in identifying this as a
defect, I was told that it would affect all SCCP media resources.  Though,
I have not validated this claim.  If you have the time to validate, please
do so, and upload your trace file section so we can confirm it is in fact
happening and for the same reason.  Thanks.


On Mon, Apr 7, 2014 at 11:05 AM, Heim, Dennis <Dennis.Heim at wwt.com> wrote:

> Does this only impact MoH resources, or would MTP’s also be impacted?
>
>
>
> *Dennis Heim | Solution Architect (Collaboration)*
>
> World Wide Technology, Inc. | 314-212-1814
>
>
>
> *PS Engineering: ** Innovate & Ignite.*
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Brian Meade (brmeade)
> *Sent:* Wednesday, December 11, 2013 9:50 AM
> *To:* Anthony Holloway; Cisco VoIP Group
>
> *Subject:* Re: [cisco-voip] Unicast MOH and MRG Round Robin
>
>
>
> If anyone needs this fix on 8.x or 9.x, open a TAC case and we can get
> this put into an ES for you.
>
>
>
> Brian
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at puck.nether.net>]
> *On Behalf Of *Anthony Holloway
> *Sent:* Wednesday, December 11, 2013 12:38 AM
> *To:* Cisco VoIP Group
> *Subject:* Re: [cisco-voip] Unicast MOH and MRG Round Robin
>
>
>
> 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/20140408/13d8e906/attachment.html>


More information about the cisco-voip mailing list