Location audio bandwidth for ILBC is 31kbps, CUCM System Guide States 24kbps

[bwalsh]

CUCM Version - 10.5.2.13900-12

Setup an ILBC call between 9971 and 7962 (verified using ILBC by pressing "?" twice on 7965 while on active call)

This link shows CM should deduct 24 kbps per call:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_01000.html

However, when using RTMT Performance Monitor, it shows that each call is deducting 31 kbps per call.  This can also be verified if you change location BW to be less than 31 (call will get Not Enough Bandwidth).

Is this how this should work?

[Deepak Mehta]

Actual bandwidth consumption per call varies, depending on factors such as Voice payload size ( bytes or ms).

Try read through , it a good doc- http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html.

You can check TAC B/W calculator to get the exact B/W per call-https://cway.cisco.com/tools/vccalc/

[bwalsh]

Hi Deepak - I understand that part of it.  What I'm interested in though is understanding what CallManager is using for it's (E)Location-Based CAC bandwidth deduction on a per call basis.

Example, if I configure a location in CUCM that has 48 (kbps) of bandwidth, will that location allow in 1 or 2 ILBC phone calls?  Based on my testing in RTMT, it will only allow for 1 - however, based on the documentation I listed in original post, it should allow 2.

[Deepak Mehta]

Hi Bwalsh,

The values you are refferreing to has been assumed for B/W calculation simplication only and it might not be true when you test.

Therefore you are right it will allow only 1 call based on the factors responsible for B/W calculations mentioned in the thread.I have found the same in my testing .

Thank you.

[bwalsh]

Does that mean Cisco has error in their documentation?

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_01000.html

[Deepak Mehta]

The doc clearly says CUCM assumes and actual BW consumption per call may vary.

Perhaps other experts can validate ..

[Dennis Mink]

Thanks for that screen shot Deepak,I think Mr.Walsh has a point though. I myself have a TAC case open for miscalculations of location deduction, where both g711 and g729 deduct 102kbps.  anyway, stating that an audio call's bandwidth can vary, is somewhat inadequate, as with locations the very thing you want to set is a hard value on the total number of calls.  Plus what ever the value is, it should be completely irrelevant from a CUCM perspective, as it it doesnt do QoS, it just keeps track of a Location's bandwidth to potentially kick in AAR, or disallow, the n-th call.

So, bWalsh, in your case, you will need to set your location values, based on that 31kbps, so set your location to 62, and dont worry about it any further,  Where that 31kbps does come into play is your QoS policy classes, because they WILL use real bandwidth.

cheers

[Deepak Mehta]

Thank you Dennis for valuable insight.

I would like to highlight that On CUCM you can vary or set the voice payload type which will in turn affects the amount of bandwidth a call will take.Higher the payload type lower the B/W value for a call.

So to say CUCM is not completely irrelevant from a CUCM perspective is an incorrect statement .You can varify this with TAC and post the outcome on this thread.

If you want to set hard value on our Location , you need to use B/W calculator with accurate payload type/WAN overhead values and it will give you exact data.

That is the reason i was stressing on point that the doc is based on assumptions.

Voice payload size can be set from the router side as well.

[bwalsh]

Thanks Dennis, and you are right - that's exactly what I'm looking for.  I did some testing on my system and G729 is using 24 kpbs (like it should) in RTMT.  And G711 is using 80kpbs (like it should) in RTMT as well.

From other reading on this subject, perhaps the "sample size" value in Service Parameters could influence the amount of BW CUCM deducts for each call (mine are all defaults so I would expect 24 to be deducted for ILBC (unless there's a documentation bug or a CUCM/RTMT bug)).

In the end we need a way CM can count the number of calls before CM invokes AAR or just flat denies the nth call (as you stated above).

[bwalsh]

Worked with TAC and they wrote a bug ID for this behavior:

CSCuz42436

Basically, it's 24kbps is for 30 ms packets and 31kbps is for 20 ms packets.  I have yet to see CUCM decrement 24kbps since I haven't found a phone or parameter that forces the use of 30 ms packet rate.

[Deepak Mehta]

Thank you , i believe this confirms my point that voice payload size will affect the amount of B/W.

Please close the thread .

[Muhammad Al-Hussein]

Just to make sure that people do not get misguided and confused, the above discussion does not prove Deepak's point, Cisco CUCM is not Network aware and it does not know anything about the Layer 2 and compression mechanisms used in the network/WAN, Cisco states clearly that they use fixed values on the CUCM Location/CAC based on average fixed assumptions/calculations (IP header only & 30 msec) , these values do not change and if the values are different that what is in the SRND/System Guide, it is most probably a bug.

While calculating the Actual Bandwidth consumed on the WAN is a totally different story, and the only link between the two calculations (CUCM and WAN) is the number of voice channels and codec used.

Bandwidth Calculations

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_01000.html#CUCM_RF_B90D5F7F_00