CUC (6) CUCM (28) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (3)

Tuesday, 12 May 2015

Regions and Locations in CUCM, and in particular in conjunction with video

Regions and locations on CUCM, this should be bread and butter stuff for any voice engineer. Part of CCVP, CCNP voice or whatever the hell they call it nowadays and there is a reasonable amount of documentation on the topic available as well.

The thing that sparked up the need for me to put up a post on this topic was when I was troubleshooting an issue; video capabilities not being enabled when dialing in a certain direction between two phones on separate clusters, tied together by a SIP trunk.

After collecting a test call's trace, I found that the call from one end was not including video capabilities in its SIP SDP's.  Drilling more into the trace files and eventually pulling the Location Bandwidth Manager's logs for the test call, I found the following error:

35808704.006 |08:41:55.347 |AppInfo  |LBM: RES_REC NOT Enough for 16500 on Edge Hub_None->USA_CUCM. Left=9000, Calls=0. FAIL. (ProcessLocationHelper.cpp:163)
35808704.007 |08:41:55.347 |AppInfo  |GenAlarm: AlarmName = LocationOutOfResource, subFac = Location Bandwidth ManagerKeyParam = , severity = 4, AlarmMsg = Name : Hub_None->USA_CUCM

After this, the solution was simple; add more bandwidth to Hub_None > USA_CUCM relationship. Which did indeed fix video.  The symptom of having insufficient bandwidth was that one end was was not including video as one of its capabilities, resulting in a audio only call. This makes sense if you think about it.  For example, a video capable phone in Location A calls a video capable phone in  Location B. Suppose Location B has insufficient bandwidth to allow video back to Location A. This will result in Location B not including video capabilities in its signalling back to Location A.  This means that on a signalling level (irrespective of whatever protocol is used), there can be no agreement of what protocol is being used. As a result of this, there will be no video at all.

Actually, the caller in location A, will see a message on his screen like "no video capabilities, remote party has video off" (on for instance Cisco 8941 phones). Strictly speaking this message is true from a signalling perspective, but the phone in location B, is video capable, but disallowed Video because of bandwidth insufficiency.  Enough about that. 

Regions and Locations are tied together in what Cisco calls Call Admission Control architecture. Simply put, regions define what codecs are used for calls between these regions, and locations define how much bandwidth is allowed for these calls once the codec has been decided on.  Essentially it is a way to prevent your location's WAN link from being swamped with audio/video traffic, because Call Manager's Location Bandwidth Manager's (LBM) will simply not allow the call if there is insufficient bandwidth (or it i will degrade it to audio only, as long as Retry video as audio call, is set on the phone,  like I indicated in my initial example). Locations in CUCM are a representation of a physical site and endpoints are normally associated to them, through their device pool.

Part of the setup of a call across 2 location pairs, is that LBM deducts the following values off the total bandwidth, to calculate the remaining bandwidth for the next call(s)

Call Speed                                Static Location and Link Bandwidth Value
G.711 audio call (64 kbps)          80 kbps
G.729 audio call (8 kbps)            24 kbps
128 kbps video call                    128 kbps
384 kbps video call                    384 kbps
512 kbps video call                    512 kbps
768 kbps video call                    768 kbps

Whatever 'call speed' is being used, really depends on the region's codec choice in relation to the region the call is going to, in this case the region to which the SIP trunk belongs

For example a video call between locations 1 (L1) and 2 (L2). L1  is on a separate cluster from L2, tied together by  a SIP Trunk. This is represented in the picture below:

As with most Voice stuff, figuring out a call flow, is very much like following the bouncing ball (some CCIE voice, with a lot of experience once told me this), in terms of locations. In my example a Location 1 initiated video call to L2, will traverse the following locations:  L1>Hub_none on cluster 1>L2 (which is the SIP trunk) > Hub_none on cluster 2>Location 2

This means that a total of 4 locations (relationships) are relevant:

on Cluster 1:

  • Location 1 > Hub_none
  • Hub_none > SIP trunk Location 2
on Cluster 2:

  • SIP trunk location 2 > Hub none
  • Hub_none > Location 2
Please note that the opposite direction will need to be considered as well to verify if locations bandwidth settings are correct, because remember insufficient bandwidth in only one direction can cause a video enabled call to be degraded to audio only!

As can be seen in the picture above, all locations that are part of the call path, have 1 Mbps deducted from their available bandwidth (or total bandwidth if no other calls were already active at the time). This because the video is set up with a 1 Mbps media rate.

Also Note that I use Hub_none. Hub_none is pretty much used to emulate a Hub-Spoke network. This implies that all locations connect to the Hub_none location and vice versa. Which is the more conventional way of implementing Call admission control.

Another thing I would like to point out, regarding Call admission control is that implementing it, is like a fail safe for swamping you WAN link with delay sensitive traffic. Nowadays, most WAN provider's implement some form of QoS on their links. Don't think for one moment that that is a self fulfilling prophecy, and that as soon as you hand traffic off to whoever your provider is, everything is fine.  Some providers give absolute priority to delay sensitive traffic such as video and voice, which means that, if they do not cap it, no one will. This could well mean that a 10Mbps is fully utilised by video/voice leaving no room for business critical application data. The way to make sure this does not happen, you guessed it; Implement Call Admission Control.

Sleep well

1 comment:

  1. Nice crisp way to explain Regions, Locations, CAC. Thank you.