Yes, that is correct.
On Tue, Apr 8, 2014 at 12:49 PM, Heim, Dennis <[email protected]> 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:* [email protected] [mailto:[email protected]] *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 <[email protected]> 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:[email protected]] *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:[email protected]<[email protected]>] > *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 < > [email protected]> 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 > > > > > > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
