VCS call rate reporting

[Bob Fitzgerald]

Hello!

A customer was concerned that calls to a Jabber client at a remote office were at a higher call rate than what that office's network could handle.  I advised them that the Maximum In/Out Bandwidth could be Provisioned for the Jabber client (in this case, 768k) so that the call rate would be within the network's capability.  I got an email back telling me that calls to the Jabber client were connecting at 1472k.  As evidence, they included a screen shot of their CCC which indicated the connection to the Jabber client at 1474k.

So, I tried this out myself.  In my tests I had the following combinations of devices;

TMS14.1.1, VCS-C X7.2.1, C90 TC6.0.1, Jabber 4.6 provisioned for 768k Max In/Out

TMS13.2, VCS-C X7.2, 6000MXP F9.1, Jabber 4.6 provisioned for 768k Max In/Out

I made calls from the C90 and 6000MXP at 1472k and looked at the call in CCC.  Sure enough the connection to the Jabber client said 1472k.

So I looked at the VCS-C to see what the call rate was being reported as.  As seen below, the VCS could identify the rate at which the call was initially made and the rate at which the endpoints agreed to.

Looking at the Jabber client, we see that the Signaled bitrate is what the endpoints initially called at, but the Configured bitrate is what was Provisioned... sort of.  I've noticed that what's reported in the Jabber's call status doesn't make sense sometimes.

As we know, TMS gets most of its CDR information from the VCS.  It appears to me that the call rate information in the CCC is the "Requested" bandwidth reported in the VCS. 

So my questions are;

- Is this indeed the case, or am I missing a piece of the puzzle?

- Is this "Working as designed" or is it a bug?

It seems to me that it would be more useful to have the "Allocated" bandwidth represented in the CCC.  In our customer's example, a quick look at CCC would be a good first step if the end user reported video quality issues.

Thanks!

[Eunkyung Lee · Accepted solution]

When we used SIP call, the call rate in TMS Conference Control Center(CCC) matched with the max allowed bitrate In the Jabber's call status, but when we used H323 call it showed similar to what you posted in the support forums.


Our conclusion is the following.

During SIP call(non traversal calls), VCS does not handle the call so the end points negotiate the call with max bit rate of 768kb/s.

C90     <--------  Max 768kb/s --------->  Jabber 4.6
CCC: 768kb/s


However, when using H323(traversal calls), VCS handles the call to down speed.

C90     <--------  Max 1472kb/s --------->   VCS     <--------  Max 768kb/s --------->  Jabber 4.6
CCC: 1472 kb/s



In TMS it showed the maximum bandwidth that is used for the call, if some part of the call was transmitted with higher bit rate then others.

Once you understand this call flow, it is easier to make sense out of the three different call rate reporting.

I hope this help.

Also, if your customer wants to limit the bandwidth usage more, they can limit the call rate from VCS.

You can check the Bandwidth control portion of the Cisco VCS Admin Guide (X7.2)
http://www.cisco.com/en/US/partner/products/ps11337/prod_maintenance_guides_list.html

[asafayan]

Excellent summary EunKyung Lee.  I am sitting in my first TP class and this kind of forum post is very, very helpful.  Thank you sir!

Amir

[ahmashar]

you can also limit the bandwidth using PIPE as well as subzone bandwidth limitation where the endpoints are registered. you have all these tools to set a threshold for your jabber client, the configuration just need a fine tuning otherwise I have tested similar scenarios in the lab and they work like a charm.

[Bob Fitzgerald]

Hi guys!

Thanks for the responses.  I had already discussed ways to ensure call rate compliance to the remote site with the customer, but the important element to them was how it appeared in CCC.  They are satisfied with Provisioning the Jabber client to the desired call rate limitation.

Thanks again!