7.6 Enhanced Location CAC Considerations

This topic describes the issues that must be considered when implementing Enhanced Location CAC.

One cluster (typically Cisco Unified CM SME) can be used as a central location and link management cluster:

  • Configuration of the locations and link management cluster (SME):
    1. All locations of the entire intercluster topology
    2. All links that exist in the entire intercluster topology
    3. Each link must be configured with weight and bandwidth limits.
    4. One or more LBM hubs must be configured as a PoC.
  • Configuration of all other clusters (SME leaf clusters):
    1. Each leaf cluster includes only the locations that are required for local device associations.
    2. No links (and no weights and bandwidth limits) are configured at leaf clusters.
    3. Each leaf cluster requires one or more LBM hubs that refer to the Cisco CM SME LBM hubs as PoCs.
  • Each cluster will be able to build complete intercluster topology by merging local configuration and information received from SME

Enhanced Location CAC supports a configuration in which Cisco Unified Communications Manager Session Management Edition (Cisco Unified CM SME) can be used as a centralized location and link management cluster.

The main advantages of using a location and link management cluster are centralized configuration, centralized call control, and centralized CAC.

When using Cisco Unified Communications Manager Session Management Edition as a location and link management cluster, the network model configuration is performed as follows:

  • Cisco Unified Communications Manager Session Management Edition cluster configuration: All locations of all clusters and all links between these locations must be configured at the Cisco Unified Communications Manager Session Management Edition cluster. The weight and bandwidth limits must be configured for each link at the Cisco Unified Communications Manager Session Management Edition cluster. One or more LBMs of the Cisco Unified Communications Manager Session Management Edition cluster are configured as PoCs in an LBM intercluster replication group. The LBM intercluster replication group is applied to all of the LBMs that are listed as PoCs and optionally to additional LBMs of the Cisco Unified Communications Manager Session Management Edition cluster.
    Note

    Based on the previous Cisco Unified Communications Manager Session Management Edition cluster configuration, the Cisco Unified Communications Manager Session Management Edition cluster knows the network model of the entire deployment. It has one or more LBM hubs, and at least one of these LBM hubs is configured as a PoC.

  • Configuration of all other clusters (Cisco Unified Communications Manager Session Management Edition leaf clusters): Each leaf cluster is configured only with those local locations that are required for local device associations. Locations that do not include any devices of the leaf cluster are not configured at the leaf cluster. No links (and consequently no link weights and bandwidth limits) are configured at the leaf clusters. Each leaf cluster requires at least one LBM hub, and the LBM intercluster replication group that is used to designate a server as an LBM hub is identical to the one that was configured at the Cisco Unified Communications Manager Session Management Edition cluster. It includes up to three PoCs that refer to LBM hubs of the Cisco Unified Communications Manager Session Management Edition cluster.

This configuration allows each Cisco Unified Communications Manager Session Management Edition leaf cluster to associate local devices with locations. The remaining information that is required for a network model of the leaf cluster is not configured at the individual leaf clusters but in a centralized way at the Cisco Unified Communications Manager Session Management Edition cluster only. Based on the configured replication network, each leaf cluster will learn the entire network model from the Cisco Unified Communications Manager Session Management Edition cluster and overlay its local locations with the entire received network model. All transit locations, all remote locations, and all links and link settings are learned from the Cisco Unified Communications Manager Session Management Edition cluster and are not required to be configured locally at the leaf clusters. Transit locations are local locations that do not include any devices. Remote locations exist only in other clusters.

SME Used as Location and Link Management Cluster Example

This section shows an example of Cisco Unified Communications Manager Session Management Edition being used as a location and link management cluster.

  • Only Cisco CM SME is configured with all locations.
  • MPLS locations do not include devices and represent two separate MPLS IP WAN networks.
  • Leaf clusters are only configured with locations that include local devices.
  • Links are only configured in Cisco CM SME.
  • After replication, all clusters have full view (as shown in SME topology).
  • SME LBM hubs are configured as PoCs at all clusters.

The figure shows a Cisco Unified Communications Manager Session Management Edition cluster that is configured with the entire network model, which consists of three clusters and six physical locations.

One cluster is at the centralized headquarters site (HQ). This site has access to two separate MPLS IP WANs.

Another cluster, cluster A, serves three physical sites. Two sites (A-1 and A-2) are attached to one of the MPLS networks (MPLS-1). The third site (A-3) is connected to one of the other two sites (A-1), but this connection is not provided by the MPLS network. The connection is provided by any other type of WAN.

The third cluster, cluster B, serves two physical sites (B-1 and B-2). Both of these sites are attached to the other MPLS network (MPLS-2).

The correct way to represent this physical topology in a network model is by using one location per physical site and two transit locations that do not contain any endpoints. Each of the two transit locations represents one of the MPLS networks. The Cisco Unified Communications Manager Session Management Edition cluster does not contain any endpoints and therefore does not require a location in the network model.

As described earlier, when using a centralized location and link management cluster, each Cisco Unified Communications Manager Session Management Edition leaf cluster is only configured with the local locations that contain endpoints. See the three Cisco Unified Communications Manager Session Management Edition leaf cluster topologies in the figure.

The Cisco Unified Communications Manager Session Management Edition cluster is configured with the entire network model including all locations (including the MPLS transit locations), links, and link settings. A replication network is configured where each cluster has at least one LBM hub that refers to one or more PoCs located in the Cisco Unified Communications Manager Session Management Edition cluster.

After successful replication, each cluster will have knowledge about the entire network model (shown as the Cisco Unified Communications Manager Session Management Edition topology in the figure).

Considerations for Media Resources

This section describes what needs to be considered when using media resources and Enhanced Location CAC.using MTPs that have different audio bit rates on their media legs.

When using MTPs, the two RTP legs may have different audio bit rates.

  • The service parameter Locations Media Resource Audio Bit Rate Policy has two options:
    1. Lowest Bit Rate: The lower bit rate is used for the bandwidth deduction at all links along the effective path.
    2. Highest Bit Rate: The higher bit rate is used for the bandwidth deduction at all links along the effective path.

When using MOH, the following applies:

  • Enhanced Location CAC does not manage bandwidth independently per direction
  • Unicast MOH streams consume full bandwidth for the MOH stream (although only one way)
  • Multicast MOH is not subject to CAC

When a call utilizes any kind of MTP, such as a transcoder, the two media legs may have different audio bit rates. These calls are treated based on the configuration of the clusterwide Cisco CallManager service parameter called Locations Media Resource Audio Bit Rate Policy. Possible values are Lowest Bit Rate and Highest Bit Rate. The default value is Lowest Bit Rate.

This parameter determines the bit rate value to deduct from the audio bandwidth pools within and between the locations of the parties for an audio-only call when a media resource such as a transcoder is inserted into the media path. When an audio call is transcoded, there is typically a difference in bit rate between the two endpoints that are connected by the transcoder. For example, in a transcoded audio call from G.729 to G.711, the G.729 media leg has a 24-kbps bit rate while the G.711 media leg has an 80-kbps bit rate.

Similarly, when interworking IPv4 and IPv6, the bit rate that is used on the IPv4 media leg will be less than that of the IPv6 media leg for the same audio codec. When set to Lowest Bit Rate, the lowest bit rate of the media legs is used as the value to deduct from the audio bandwidth pools that track the bandwidth usage within and between locations. In a simple example, a transcoded audio call from G.729 to G.711 would use the lower G.729 bit rate value of 24 kbps because this bit rate is the lowest bit rate for the entire media path end-to-end. When set to Highest Bit Rate, the highest bit rate of the audio media legs is used as the value to deduct from the bandwidth pools for audio. In a simple example, a transcoded audio call from G.729 to G.711 would use the higher G.711 bit rate value of 80 kbps because this bit rate is the highest bit rate for the entire media path end-to-end.

When MOH or Multicast MOH is used, you have to consider the following:

  • In case of unicast MOH, a call that is on hold consumes the bandwidth that is used by the MOH stream. This bandwidth depends on the codec that is used for the MOH stream. The codec that is selected for a MOH audio stream depends on the enabled audio codecs of the MOH server and on the region or regions of the MOH server and the held party.
  • In case of multicast MOH, the multicast MOH stream is not considered by Enhanced Location CAC. From a CAC perspective, endpoints that are put on hold do not consume any bandwidth if they receive multicast MOH.
  • Enhanced Location CAC does not manage the bandwidth independently per direction even if there is only a one-way audio stream like in the case of MOH.

Limitations and Caveats of Enhanced Location CAC

This section describes limitations and caveats of Enhanced Location CAC.

  • Enhanced Location CAC is not topology-aware. Available bandwidth and media path may be incorrectly modeled during network failures.
  • Intercluster CAC is not supported over H.323 ICT.
    1. SIP ICT required; must be in shadow location
    2. If H.323 ICT is put into shadow location, it will be treated as if it were in Hub_None
  • Make sure that location names are unique (case-sensitive).
    1. Identical locations are considered as common locations.
    2. Rename Hub_None location, if it is not used as a common location.
    3. Shadow and phantom locations are excluded from replication.
  • Enterprise parameter Cluster ID should be set to unique values.
  • Intercluster replication may take up to 70 seconds.

Enhanced Location CAC is not topology-aware. Available bandwidth and media paths may be incorrectly modeled during network failures.

Intercluster Enhanced Location CAC is not supported over an H.323 ICT. Only a SIP ICT is supported, and the SIP ICT must be put into the shadow location. If any other device, such as an H.323 ICT, is put into the shadow location, it will be treated as if it were in the location Hub_None.

Location names must be unique when using intercluster Enhanced Location CAC, unless the location should be a common location that is shared by multiple clusters. When configuring common locations, make sure that the name is identical and remember that location names are case-sensitive. Pay special attention to the location Hub_None, which exists in all clusters by default. Rename this location with a unique name if the location should not be a common location that is shared with other clusters. The other two locations that exist by default, the shadow and phantom locations, do not have to be renamed (in fact, they cannot be renamed) because they are excluded from Enhanced Location CAC replication and are not sent over a SIP ICT.

It is recommended that you use a unique cluster ID at each cluster. The cluster ID helps identify a cluster (for example, in serviceability reports).

It may take up to 70 seconds to replicate a locally changed location configuration to other remote clusters.

Advertisements