[cisco-voip] Unicast MOH and MRG Round Robin

[Anthony Holloway]

Yes, that is correct.


On Tue, Apr 8, 2014 at 12:49 PM, Heim, Dennis <Dennis.Heim at wwt.com> wrote:

> From your case, was the recommendation that all SCCP media resources
> should be all CAPS?
>
>
>
> *Dennis Heim | Solution Architect (Collaboration)*
>
> World Wide Technology, Inc. | 314-212-1814
>
>
>
> *PS Engineering: ** Innovate & Ignite.*
>
>
>
>
>
> *From:* avholloway at gmail.com [mailto:avholloway at gmail.com] *On Behalf Of *Anthony
> Holloway
> *Sent:* Tuesday, April 08, 2014 1:45 PM
> *To:* Heim, Dennis
> *Cc:* Brian Meade (brmeade); Cisco VoIP Group
>
> *Subject:* Re: [cisco-voip] Unicast MOH and MRG Round Robin
>
>
>
> 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/57727a05/attachment.html>