Telepresence endpoint high bandwidth when making audio only calls

[cwade23]

Hi

Our TP systems all seem to be negotiating the default 6000 Mbps BW for audio only calls instead 64k. This is occurring for inbound and outbound audio only calls.

It is not an issue with connecting or call quality however; it is messing up the reporting which designates an audio call versus a video call based on the BW.

Any suggestions on configuration changes that I need to make at the codec level to correct this?

Thanks

[Patrick Sparkman]

We need to know more about your environment and how you have everything deployed/configured.

Do you have any call control server is in use, such as CUCM/VCS, or if the endpoint is standalone?

What is the endpoint and software version, as well as other servers in your environment?

[cwade23]

Hi

Our environment consists of the following:

SX, EX, MX endpoints registered to VCSc. All endpoints are managed and monitored by TMS with integrated scheduling via TMSXE. our default call BW is set at 1920 kbps. Inbound/outbound audio calls route through CUCM  to carrier.

Understanding that the codec attempts to make a video call first however; when it cannot negotiate video, it should negotiate audio only at 64k. We see some calls at 64k and most others at 6000. We leverage vAnalytics for capacity and usage and our reports are way off because we cannot determine audio v video calls.

[Nick Halbert-Lillyman]

I had similar issues quite a while ago - it wasn't such an issue for me and I just sort of ignored it, but there are a few things to check and some possible workarounds;

Are the calls being interworked between H323 and SIP?  If so, it's usually a good idea to try and keep it as SIP the whole way (I got rid of H323 on my VCS endpoints and just let VCS interwork to H323 when required).  Interworking can screw things up sometimes.

Assuming you have no actual video endpoints on CUCM that would require anything more than 64Kbps, you can limit the available bandwidth between VCS and CUCM to 64Kbps using either the links and pipes feature on VCS, or Region + Device Pool of the SIP trunk to VCS on CUCM.  By physically limiting the maximum bandwidth, it will probably fix the reporting.

[cwade23]

Hi

Thanks for the response. We are SIP exclusively and like you, allow VCS to interwork as needed for inbound/outbound calls

We do have a few SX10's and DX80's that are of course registered to CUCM, so limiting the pipes is not really an option, although it would have been a great and simple idea.

One thing I may have mistakenly excluded about our environment, we do have Cisco Voip video phones that are registered to CUCM. (8845's & 8945's).

Thanks

[Acevirgil de Ocampo]

Hi,

We need to know how the systems are deployed on the network as well as the call control being used? For example if you are using CUCM, under Region settings you need to check the bandwidth allocated on the device pool where the system is located.

regards,

Acevirgil

[Wayne DeNardi]

By default the endpoint will try to make the call as Video, so will use whatever default call rate the endpoint is set to.

The endpoint will call the gateway at that default bandwidth, then the gateway will make the audio call outwards.

You can change the call rate on the local machine at the time of placing the call to "Audio only" to force it to 64k, or create an entry in your phonebook with a call rate of "Audio only" and use that while dialling.

The above is just a quick suggestion which may assist.  As mentioned by the other responders, if you provide us with some more detail on your systems and their configuration, we may be able to assist with an answer that is more relevant to your environment.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[cwade23]

Hi

Thanks for the response. We are SIP exclusively and like you, allow VCS to interwork as needed for inbound/outbound calls

We do have a few SX10's and DX80's that are of course registered to CUCM, so limiting the pipes is not really an option, although it would have been a great and simple idea.

One thing I may have mistakenly excluded about our environment, we do have Cisco Voip video phones that are registered to CUCM. (8845's & 8945's).

Thanks