Location audio bandwidth for G729 was 24kbps before migration, and now is 13kbps

[Nadav]

Hello everyone,

Before migrating to CUCM 11.x, I had an 8.6.2 cluster. CAC was used between two locations which allowed 10 calls between the two locations (a total of 240kbps for audio). For 8.6.2 each G729 call took 24kbps (this in both in SRND 8.x and in the help page for CAC in CUCM 8.6.2).

Now that I've migrated to CUCM 11.x, even though the total bandwidth configuration is maintained during migration, it seems that each call takes only 13kbps. This is confirmed by RTMT 11 and Prime Collaboration Assurance 11.1. I should point out that the weight between the two locations is 50 (default), since there was no use of Enhanced Locations in 8.6.2.

Is there any documentation for this change? Is it a possible bug? I checked the SRND 11.x and it states in Table 13-9 that G729 calls still take 24kbps. 

I'd appreciate your thoughts.

Edit:

I've checked whether this is a monitoring issue or a bandwidth enforcement issue. It appears that the 24kbps sizing is being enforced since if I drop the CAC audio bandwidth limit, I can't issue the last of the ten calls. However, RTMT and PCA still indicate that each call takes 13kbps.

[Dennis Mink]

Could be a bug,

make sure you double check your locations settings. I have seen issues with this in version 10.  go into your location bandwidth settings for either video or voice and tweak it down to a low point to see at what minimum bandwidth audio/video stops being established. This way you can work out what your total bandwidth your location should be to allow the number of calls across that location.

Cisco tends to add overhead to the codec sample rate, for instance I found that for 384 video, the Location video bandwidth needs to be set to 500, to allow a single call.  

regards

[Nadav]

Hi Dennis,

If it were just a matter of Cisco changing the way CAC estimates G729 bandwidth, there could be a workaround. But as I've tested, the bandwidth calculation seems to be as before (24kbps per call,  more or less) but the monitoring based on RTMT/PCA says 13kbps per call. Whenever I drop a call, the unused bandwidth rises by another 13kbps according to RTMT performance counters.

I'd imagine that if this is an issue with CUCM that it would be an open bug as of version 10 (which you stated had similar problems). Are you familiar with an open case?

This issue means that even if CAC is enforced correctly, I could never get an alert for location resources being used up. For example in my testing I've used all possible call bandwidth between two locations and PCA/RTMT indicate that roughly 54% of the CAC limit was used. 

[Chris Deren]

Are you sure the established call is G729?

Remember Region relationship does not hard code a specific codec, but instead caps the bandwidth to a certain codec, for example if set to G711 it can negotiate any call with lower bandwidth codec up to G711 (64 kbps).

I would check what codec is being negotiated, perhaps you are using GSM or iLBC or something else.

CUCM 11.0 still uses 24 kbps for G729 call (table 13-9):

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/cac.html

If it is in fact G729 then it must be a bug.

[Nadav]

Audio codec set to G729 between the regions. I confirmed the codec used via wireshark.

I should have mentioned that these are 7931 phones. They support G.711a, G.711u, G.729a, G.729b, and G.729ab. 

The incongruity between the monitoring data and the CAC enforcement is what makes me question whether this is a different codec being calculated. If CUCM thinks I'm using GSM that's one thing, but then it should have allowed more calls than my original limit between the locations. 

[Dennis Mink]

I currently have a TAC case open because of Location bandwidth settings, but that is for version 10.5.2. I might go and post the outcome as part of this post.

One other thing, to find out the codec being used, set up a call and browse to the phone;s IP address and check Stream1, this should tell you the codec being used.

[Chris Deren]

For what it's worth, I just tested it on my 10.5.2SU3 environment, and G729 call deducted expected 24 kbps.

[Nadav]

Any chance there are service/enterprise parameters which may be affecting this?

[Chris Deren]

Nope.

[Nadav]

I'm calling between a custom location and Hub_None with audio bandwidth hard limited to a multiple of 24kbps and without bandwidth for video and immersive, are you doing the same?

[Chris Deren]

In nutshell, my video is set to default, and so is my voice codec, thus it drives the default value from inter region service parameter which is set to g729 (24 Kbps).

[Nadav]

Same here, default is g729 and the region matrix shows explicitly that the maximum audio codec is 8kbps (G729). I've even changed the audio codec preference list to put G729 at the top. Each phone in the location shows that the input and output codec being used is G729.

Still no luck.

Can anyone reading this and running CUCM 11 SU1 perform a quick check? This issue can be replicated by performing a call between two locations with G729, limiting the calls by CAC for one of the locations, and seeing in RTMT how much bandwidth is deducted for the location. 

[Jonathan Unger]

Hi there,

I just tested on CUCM 11.0.1.21900-11 (11.0(1a)SU1).

As seen in the screenshot below, a G729 call between locTEST-A and locTEST-B is only consuming 24Kbps (as expected).



I also pulled a LBM trace to confirm, as you can see in the log entry, only 24Kb was reserved.

|LBM: RES_REC OP=UPDATE tid=2092651703202483731 A=24 O Entering IP=XXX.XXX.XXX.XXX st=answered FK=StandAloneCluster:43470XXX+StandAloneCluster:43470XXX:locTEST-A->locTEST-B

If you are confident that the codec being negotiated is G.729, and the bandwidth is not being deducted correctly you could try restarting the location bandwidth manager service.

If after an LBM restart things are still showing up incorrectly, I would recommend pulling the CM and LBM traces, then opening a TAC case.

Please let us know if this helps.

[Nadav]

Thanks Jonathan,

It's a big help knowing that this is likely not a version specific issue. I'll investigate further. 

[Nadav]

I've checked this issue further,

Each call was taking 13kbps due to the milliseconds packet size configuration under Service Parameters (was configured at 60ms as opposed to the default 20ms). However, the fact that RTMT/Assurance takes this into account but CAC didn't is definitely an issue.

Feel free to confirm this issue if you have a few minutes.

I got around this using call counting under Service Parameters. This solution won't work for everyone (probably not even most customers), but it's fine for my purposes.