Avaya Aura 6.

x Call Admission Control Best Practices

Avaya Aura Call Admission Control (CAC) and Bandwidth Management Best Practices

Page 1 of 35

CID: 151364Contents

Page 2 of 35

Avaya Aura 6.x Call Admission Control Best Practices

To achieve optimal bandwidth management in an enterprise data network, an administrator needs to understand Avaya Auras CAC functionality. This document presents relevant concepts in an ordered fashion. Readers are cautioned that many sections of the document build on preceding sections. 2. ACRONYMS The following acronyms are used: CAC Call Admission and Control BW Bandwidth SDP Session Description Protocol SIP Session Initiation Protocol SM Avaya Aura Session Manager CM Avaya Aura Communicator Manager SMGR Avaya Aura System Manager MMCS- Avaya Aura Multimedia Collaboration Server 3. REFERENCES Authors: Steve Erickson
Chris Baldwin James Free Andy Cornejo Kurt Haserodt Barb Garcia

4. INTRODUCTION Call Admission Control (CAC), or Bandwidth Management, is a service provided by Avaya Aura that prevents IP telephony from attempting to use more bandwidth than is available for a particular link in an IP network. Without this, a network could experience a volume of traffic that would result in call degradation due to dropped packets, including lost talkpath and dropped calls. Anyone whos attempted to use a cell phone at a major sporting event probably knows the experience the stadium theoretically has excellent coverage, but the sheer number of people using devices simultaneously leads to almost nonexistent service for everyone. CAC remedies this problem by preventing the establishment of new calls over a particular link if it determines that the link is at capacity. This ensures that preexisting calls continue to get quality service with no packet loss. It may result in a negative experience for the person attempting to make the new call (call denial), but it may also simply result in the call being redirected to what the enterprise network perceives as a new destination. The new destination may truly be a new destination, but it may also be a different route to the original destination. A common example sees the IP network unable to reach the destination due to CAC-determined network exhaustion, so the call is routed out a public trunk. The call reenters the IP network through another public trunk in the destinations location and terminates. The caller and callee are unaware that their call used the public network instead of the enterprise IP network. The customer does incur the cost (tolls) of using the public network, but presumably this is preferable to the call failing altogether. The ideal, of course, is that the IP network has capacity for all calls and the public network and its tolls are never used.
Page 3 of 35

The preceding scenario illustrates a key principle of CAC: that user experience when a call confronts network exhaustion (as determined by CAC) should be identical to user experience during network outage (the network is down). In either case, the network is unavailable; the reason should not matter to the user. 5. INTERACTION WITH QOS A fundamental understanding of WAN links and of Differentiated Services Architectures (Diffserv) is required to understand the role of CAC. The implementation of a Diffserv QoS is outside the scope of this document, but a brief mention is needed to lay the ground work for what CAC is intended to influence. A location is engineered with a certain amount of bandwidth on its WAN link. Voice, video, and data packets must share this bandwidth. DiffServ QoS implementation separates and prioritizes the packet traffic according to their Differentiated Services Codepoint (DSCP) tags. Properly administering priority queues end-to-end on a networks routers will increase the likelihood of the real-time packets being delivered with low packet loss and low latency. Here are some example recommendations for DSCP packet tagging: Audio : packets should be tagged EF [DSCP 46] (Expedited Forwarding : RFC-2598) Video call components : o Audio packets should be tagged AF41 [DSCP 34] (Assured Forwarding Class 4, Low Drop Precedence : RFC-2597) o Video packets should be tagged AF42 [DSCP 36] (Assured Forwarding Class 4, Medium Drop Precedence : FRC-2597) Data : packets should be tagged with AF11 [DSCP 10] (Assured Forwarding Class 1, Low Drop Precedence)

The priority tagging will determine the order in which the packets will get dropped in the event of traffic congestion on a router. In the event of congestion data packets will get dropped first, then video packets, then the audio packets of a given video call, and finally audio packets of a given audio call. The goal of CAC is to reduce the likelihood of experiencing congestion on the networks edge routers. In other words, CAC has the responsibility of controlling the flow of packets onto the router WAN links. This is primarily accomplished by blocking additional calls when a WAN link is on the verge of congestion. As an added control measure Avaya Aura can limit the amount of bandwidth requested on a per call basis. Please note that CAC can only influence the audio and video packets. If there is a burst of data packets then a properly engineered Diffserv QoS network, as described previously, should only drop the data packets as part of the data packet queues and not affect the quality of any of the audio or video calls. 6. CAC NETWORK TOPOLOGY Avaya Aura Call Admission Control assumes a hub and spoke network topology. The premise is that a given location has a generic link to the rest of the world. This is what ISPs typically provide. The link out of the Los Angeles office is the same whether the final destination is New York or Tokyo. The same bandwidth is used to traverse it. A call from Los Angeles to New York uses the Los
Page 4 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Angeles Link and the New York Link. A call from Los Angeles to Tokyo uses the Los Angeles link and the Tokyo link. SIP Signaling may have intermediate destinations, such as Avaya Aura Sequenced Applications, but media, which consumes the only significant bandwidth, is ultimately established directly from endpoint to endpoint. Because its easier to speak of links being between two things, we refer to these links as links from a location to the core, where the core represents the services available to the enterprise. The core is not a user location, though components in the core may share physical locations (datacenters) with some enterprise users. It has little substance from a CAC perspective because media is not expected to terminate in the core. Media flows from user location to user location. The following drawing illustrates the hub-and-spoke topology:

A key takeaway here is the assumption that bandwidth usage is direct from endpoint to endpoint. SIP signaling legs in the core are not expected to indicate intermediate media terminations. Also note that if both endpoints in a call are in the same location, media should never leave the location. The bandwidth between endpoints within the same location is assumed to be infinite. 7. SYMMETRIC BANDWIDTH Administration of CAC limits is performed in terms of kilobits per second (KBit/sec). Bandwidth usage is counted in these terms, with the active count being measured against the limit to determine whether a call or call route should be allowed. All bandwidth usage and limits is assumed to be bidirectional. For example, an audio call using the G.729 codec sends at a rate of 18 KBit/sec in each
Page 5 of 35

direction. CAC will count this call as 18 KBit/sec, and will deny it if the limit minus preexisting usage is less than 18 KBit/sec. Usage is assumed to be symmetric the same rate in each direction. Avaya Aura CAC does not attempt to track different levels of usage in one direction vs the other, or enforce different limits in each direction. Existing SIP devices tend not to support asymmetric media. Even video conferencing systems, in which a user sends one upstream image and receives multiple downstream images, tend to normalize downstream media to match the bitrate of upstream media, either by reducing quality of the downstream images or by sending only one at a time, cycling through far-end images as requested by the endpoint or provided by the conferencing server. Avaya will reevaluate the need for support of asymmetric media over time. 8. IMPLEMENTATION Avaya Aura Call Admission Control is primarily implemented within Avaya Aura Session Manager. As the central proxy in an Aura deployment, the SM cluster sees the majority of call establishments in the form of SIP signaling. It uses this signaling to determine the bandwidth that the call may use, as described in Session Description Protocol (SDP). It also determines the locations between which the call is being made. Bandwidth limits are associated with Locations as part of location administration within System Manager (SMGR). These limits apply to the link from the location to the core. SMGR provides status pages for viewing bandwidth usage by location both in real time and historically. SMGR also provides eventing when calls are impacted by bandwidth limits and alarms when locations persist in a high occupancy state. SM CAC processing occurs every time a SIP message related to an INVITE dialog passes through the SM cluster. The message is analyzed and SDP is parsed to determine both the locations involved and the amount of bandwidth used. If a locations limit would be exceeded by a SIP request, the request may be denied with a SIP 488 response containing at 370 Warning header indicating the reason for denial. If alternate routing possibilities are administered, the alternate routes may be tried, with CAC processing reapplied for the new routes locations. It is also possible that a request may not be denied, but rather will have its bandwidth reduced so that it fits within the locations limit. SM even has Per-Call bandwidth restrictions for locations, which can be administered to cap the bandwidth for any single SIP call, regardless of progress towards the locations overall limit. Indialog SIP requests are subject to the same processing as the initial INVITE, though they cannot be alternate routed. CAC enforcement can impact attempts to add video to an initially audio-only call. SM CAC will also recognize mid-call bandwidth changes, such as when a video call is reduced to audio-only by the user. As of SM 6.2, SM CAC will even recognize a mid-call change in the location of the source of media, in the event that media sources change over the lifetime of a call. SM 6.0, meanwhile, does not even analyze SDP. It assumes that all calls to/from a location consume an equal amount of bandwidth - a number provisioned on the location administration page. Some users of bandwidth do not signal through the SM cluster. Others do, but pass through other entities en route to their final destination, leaving SM unaware of the destinations final location. These make it difficult for SM to accurately enforce location bandwidth limits. There are several ways of accounting for these scenarios, depending on the versions of Aura products being deployed. A common example of bandwidth usage not exposed to SM is the H.323 user. A call between two H.323 users on the same CM does not generate a single SIP message. A call from a SIP user to an
Page 6 of 35

Avaya Aura 6.x Call Admission Control Best Practices

H.323 user will involve SIP, but SM will route the SIP signaling to the H.323 users CM without knowing the location of the H.323 user itself. The only way CAC can properly account for the H.323 user is if CM performs the CAC counting of the call. It can know the locations of its H.323 users. However, if an H.323 user places a call to a SIP user, we see the same problem in reverse. CM will route the call to SM without knowing where the SIP user is actually registered only SM has this knowledge. Truly effective CAC requires all uses of bandwidth to be reported to a compositor which will track the usage and enforce the limit. In the above scenario, we see that both SM and CM can record a subset of the uses of bandwidth for a location. As neither sees all uses, the two must communicate usage with each other. SMs within a cluster have always done this. CMs have their own CAC capability, but they do not communicate with other entities. The capability to receive information from other devices that wish to record bandwidth usage is being added to SM 6.2. This communication is received via a SIP PUBLISH for the Bandwidth event package, defined in CID 149836. The initial release of the Avaya Multimedia Collaboration Server (MMCS) and the 8.0 release of the CS1000 will use this PUBLISH to report location usage to the SM cluster, and to receive approval before allowing call setups. CM will adopt this capability in 2012. 9. SM/CM CAC INTERACTION CONSIDERATIONS Given the above, users of CAC before full support of Bandwidth PUBLISH exists will need to make some tradeoff choices. Before doing this, we should understand a few things about CAC processing. First, CAC enforcement must begin before the initial SIP INVITE is routed to the destination endpoint. This is true for several reasons. As stated earlier, CAC denial should behave similarly to WAN outage. In a WAN outage, the destination would not receive the INVITE. Once the INVITE reaches the endpoint, it begins to alert. We do not want to alert the user in a case where the calls media cannot be established. Also, CAC denial may lead to alternate routing. Alternate routing is performed within SM at INVITE processing time. If we terminate the INVITE, we are no longer able to alternate route. Second, a typical call may traverse a number of Avaya Aura entities. It is important that one and only one entity be responsible for counting the bandwidth for a given call against its locations limits. Ideally, this entity is the one closest to the destination endpoint, so that it knows the destinations location. Consider the diagram below. A SIP user is registered to SM1. It uses a number of Aura Sequenced Applications. Meanwhile, an H.323 user is registered to a Communication Manager, which is accessible via a link to SM2. If the SIP user calls the H.323 user, the H.323 users location is not known when SM1 or SM2 receive the initial SIP INVITE. CAC calculations are performed in CM. If the H.323 user calls the SIP user, the SIP users location is not known by CM nor SM2, but is determined by SM1 before it terminates the initial INVITE.

Page 7 of 35

The SM cluster is intelligent enough to only perform CAC calculations at the moment just before the initial SIP INVITE leaves the cluster for the final time. It does not, by default, know whether a nonSM entity, such as CM, might perform CAC calculations after the INVITE leaves the SM cluster. This must be administered. The CM is administered as a SIP Entity within SMGR. It can be designated in SMGR as an entity that supports CAC. If this designation is made, the SM cluster will assume that when routing a call to the designated entity, SMs do not need to perform CAC calculations because the entity will do so. Note that this applies only for calls TO the entity, not calls FROM the entity. Alternatively, consider the following modification of the diagram:

In this scenario, the third-party PBX does not have CAC functionality, nor will it signal useful location information to the SM cluster even in the response to the initial SIP INVITE. This PBX should be administered in SMGR as an entity that does NOT support CAC. When this is done, the SM cluster will realize that for a call from the SIP user to the DCP user, SM2 should perform CAC calculations. As it does so, it will use its best-guess knowledge of the DCP users location, which will be the administered location of the third-party PBX. In addition to the Supports CAC attribute of a SIP Entity (introduced in SM 6.2, before which all non-SM entities are assumed to not support CAC), SMGR contains settings for informing the SM cluster when an entity supports the Bandwidth PUBLISH. Ideally, all entities that support CAC also support the Bandwidth PUBLISH, so that all uses of bandwidth are counted collectively against the locations limits as maintained by the SM cluster. If entities support CAC but not the Bandwidth PUBLISH, they will be tracking usage, but doing so separately from the SM cluster, in enforcement of a separately provisioned limit. This is the scenario that we stated earlier that we wanted to avoid. The following section makes recommendations for doing so.
Page 8 of 35

Avaya Aura 6.x Call Admission Control Best Practices

10. SM/CM CAC INTERACTION RECOMMENDATIONS This section makes recommendations for dealing with scenarios where uses of bandwidth across the links to locations which are not exposed to the SM cluster during the clusters processing of an initial SIP INVITE and entities which can see these uses at call setup time do not support the Bandwidth PUBLISH. This happens most commonly in environments where H.323 endpoints exist and are registered to pre-7.0 CMs. If an enterprise consists solely of SIP users, there is no problem. All calls will traverse SM, which will route INVITEs directly to endpoints, so it knows all relevant locations when it processes initial INVITEs. If an enterprise contains only one Communication Manager (or only one CS1000), which serves all users (both SIP and non-SIP), the CAC capability of SM should be disabled (by not setting any bandwidth limits on any locations). Instead of SM CAC, the CAC capability of the CM or CS1000 should be used, since it will be aware of all uses of bandwidth for all locations in the enterprise. If an enterprise contains multiple CMs or CS1000s and non-SIP users, an effort should be made to ensure that there is no location X which contains users served by more than one CM or CS1000. If two entities serve users in the same location, we will have our undesirable condition where no single entity is aware of all uses of bandwidth for the location, making limit enforcement impossible. An example of this is diagrammed below.

CM1 serves all users in locations A, B, and C. Non-SIP users in these locations are registered directly to CM1. SIP users in these locations are registered to SM, but use CM1 as their feature server. Thus all uses of bandwidth for locations A, B, and C are signaled to CM1 in some way. CM1 can enforce limits for these locations. CM2 similarly serves locations D, E, and F. If a call is made between a user in location A and a user in location D, CM1 will see the call as flowing from A to SM, and will count bandwidth used against As limit. CM2 will see the call as flowing from SM to location D, and will count bandwidth against Ds limit.
Page 9 of 35

Enterprises which contain non-SIP users and multiple CMs (or CS1000s) in which some locations are served by more than one CM will not receive the full benefits of Avaya Aura CAC until CM support for the Bandwidth PUBLISH arrives. If CAC is highly desirable, an enterprise should attempt to avoid meeting this condition. Alternatively, several compromises can be made: 1. The enterprise could accept the CAC assumption that all non-SIP users served by a particular CM/CS1000 are in the same location. This would be administered by marking all CM/CS1000s as not supporting CAC. The SM cluster would then perform CAC calculations for calls terminated to non-SIP users by assuming that they terminate in the administered location of the CM/CS1000. 2. The enterprise could accept partial limit enforcement. Suppose a location has a link capable of sustaining bidirectional media at a rate of 10 MBit/sec. This location contains both SIP and nonSIP stations at a ratio of 3/1 (SIP to non-SIP), where the frequency of calls made is approximately equal for all stations, and all stations make audio-only calls using the G.729 codec. The administrator could enable CAC on SM and configure CM CAC to count only on behalf of the non-SIP users. On SM, the location could be given a limit of 9 MBit/sec, and on CM, a limit of 3 MBit/sec. This could potentially allow 12 MBit/sec of traffic to flow over the locations link, but could also deny calls to SIP stations when the links usage is at 9 MBit/sec (if all H.323 users are idle), or could deny calls to H.323 stations when usage is at 3 MBit/sec (if all SIP users are idle), because one component (SM or CM) would see its view of the limit being reached. This type of configuration is discouraged due to its complexity and upcoming obsolescence. 11. SESSION MANAGER LOCATION DETERMINATION Key to CAC behavior is the determination of the location of call parties. CAC will count bandwidth across the links to/from the locations of call parties if and only if the parties are not in the same location (no inter-location links are traversed by the media for an intra-location call). SM tracks up to three different flavors of location for a particular call party. Only one of these locations will be treated as the source of media for CAC purposes. The first two concepts of location called signaling location and home location. Starting with 6.2 the additional concept media location was added. The media location refers to the location from which the users media (voice, video, etc.) originates. The signaling location refers to where the users SIP signaling originates. The home location refers to the location that the user is based out of. Media location is derived solely using IP pattern match on the IP address of media origination specified in SDP. Patterns are defined in SMGRs location administration. Signaling location is derived by doing an IP pattern match on the IP address from the bottommost Via header in the request. If this does not match a known IP pattern, the provisioned location of a sending SIP Entity may also be used, if applicable. Because the home location is a mandatory field that cannot be left blank, the idea is to guarantee that there is some reasonable location for the user even in the absence of an IP pattern match.
Page 10 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Home location will only exist for SIP users and is administered as part of the user record. If it exists, the media location will be used by CAC. If no media location is determined (the SDPs IP addresses dont match any provisioned location patterns, or an SM release before 6.2 is being used), then the signaling location will be used by CAC. If no signaling location can be determined, the home location is the final fallback choice. It is only possible for a call party to have no location if the party is a non-SIP user (no home location) and there are no IP patterns matching any aspect of the call party. At this point, the user is considered to be calling from within the core. No bandwidth restriction of any kind will be applied for such a call party (restriction may still occur on behalf of the other call party). Note the importance of provisioning IP patterns for locations. If this is not done, SIP users will be considered to be calling from their home location even if they are traveling and actually calling from another location. SM features outside of CAC use the same location precedence as CAC (media, signaling, home) except that they do not consider media location. This routing location is also used for things like emergency calls and fetching location specific registration/subscription parameters. SM can still route a call even if location for the originator is undefined; it will just not match any location specific dial patterns. Calls between more than two parties receive CAC treatment based on their media paths, which can differ depending on the call setup. The possible call setups are beyond the scope of this document, but the most common setup sees all parties route media to a central server, meaning that CAC would reflect the media from various locations flowing to/from the server location. 12. MEDIA PRIORITY Avaya Aura CAC allows for two flavors of media priority. The first is presently not implemented nor fully designed: priority by user. This system allows some users to take precedence over others, including possibly reducing or terminating the calls of other users to free up bandwidth for the priority user. Avayas Multimedia Collaboration Server (MMCS) allows users to be provisioned with and granted priority when forming multimedia conferences. CM CAC also allows for some concept of priority. SM CAC, as a rule, does not impact preexisting calls in the process of finding bandwidth for new calls or call enhancements. Thus it does not have the concept of priority users, which means this concept is not available for two-party SIP calls. SM CAC also allows for priority based on media type. Media is categorized as either audio or multimedia (multimedia being defined as non-audio). Multimedia includes video, content sharing, and audio associated with video. Categorization is done based on SDP. SMGR location administration allows not only a limit on total bandwidth for the link to a location, but also a sublimit on multimedia bandwidth. This sublimit can be used to prevent a few high bandwidth video users from exhausting the locations bandwidth and starving all other users. Once the sublimit is reached, subsequent calls will be granted only audio media until the overall limit is reached. Administration of both limits is optional.

Page 11 of 35

13. SITE ENGINEERING The goal for engineering a given site is to allow as many simultaneous calls to be established while providing the best experience possible for those users. There is a balance between the call quality experience and BW usage. Higher quality experiences require more BW. This section will guide you on how to best navigate through the process of engineering a successful site. As described in previous sections, BW management is achieved by administering useful and meaningful CAC based on a sites needs. Planning can be driven from different perspectives. This section will focus on two: i) ii) Site engineering based on endpoint quantity: you are asked to calculate the bandwidth needs for a given site based on number of employees at a site, quality of experience needs, and expected maximum percentage of simultaneous calls. Site engineering based on bandwidth limits: you are given a certain amount of bandwidth and asked to determine how many employees can be supported at a site, at what quality of experience and at what maximum percentage of simultaneous calls.

Site Engineering based on Endpoint Quantity When planning a locations CAC administration based on the number of employees at a site you will first need to gather the quantity of endpoints needed, grouped by phone type.
Endpoint Count Number of SIP audio endpoints Number of Non-SIP (H.323/DCP/analog) audio endpoints Number of SIP video endpoints Number of H.323 video endpoints Quantity a b c d

1 2 3 4

Table 1: Number of Endpoints

Page 12 of 35

Avaya Aura 6.x Call Admission Control Best Practices

The endpoint quantities from Table 1 can have their call flows split into two groups, intra-location calls and inter-location calls. The focus is on inter-location calls. Inter-location calls are most likely to have BW restrictions whereas intra-location calls will most likely have plenty of LAN BW available. The inter-location call flow can be separated further into two sub-groups, audio calls and video calls. Audio call BW usage is determined by the audio codec that is selected for the call. The controlling mechanism for this is CMs ip-codec-set list and the administered/supported audio codec selection list from the endpoints themselves. For a successful point to point audio call, both endpoints and CM must agree on at least one common audio codec. Below is a sample of some commonly used audio codecs and their respective BW usage. The values are shown against 20ms frames. Overhead includes 464 bits per packet to cover headers and trailers. Approx BW (Kbps) at Approx BW (Kbps) at 20ms Frame Lengths 20ms Frame Lengths PLUS Overhead 8 24 64 80 64 80 32 51
43 72 56 48 147 115 83 75 67 51 43

# Audio Codec 1 G.729 2 G.711 3 G.722-64 4 G.722.1-32K 5 G.722.1-24K 24 6 Polycom Siren14-48 48 7 Polycom Siren14-32 32 24 8 Polycom Siren14-24 9 Polycom Siren22-128 128 10 Polycom Siren22-96 96 11 Polycom Siren22-64 64 12 Polycom Siren22-56 56 48 13 Polycom Siren22-48 32 14 Polycom Siren22-32 24 15 Polycom Siren22-24 Table 2: Audio Codec Selection

NOTE: an audio codec selection is needed for the audio portion of a video call. Video endpoint BW usage is determined by the BW agreement from both endpoints for a given video call. The Avaya Aura solution does not allow for explicitly selecting the BW usage for a given video call, but it does however provide for control mechanisms to limit the maximum amount of BW used per video call. This is done either on the SMs location form or CMs ip-codec-set form, which depends on the specific implementation. For each site you will need to determine the maximum MultiMedia BW allowed per video call:
Maximum MultiMedia BW
Page 13 of 35

(Kbps)

Table 3: Maximum MultiMedia Bandwidth NOTE: The Maximum MultiMedia BW includes the audio BW plus the video BW for a given video call. The Maximum MultiMedia BW represents the maximum BW per video call, but not the actual. Video calls may connect at lower bandwidths. This value is triggered if the endpoints request more BW than what is administered as this Maximum. The call is then downsped to this value. Next, a percentage value representing the peak simultaneous inter-location calls is needed to complete the calculations. This value is a percentage is assigned per site, per endpoint type that you gathered in Table 1. This value is based on expected call patterns and may be difficult to determine. For each location the following data is needed: Endpoint Type
1 2 Audio Video

% Simultaneous Inter-location
e f

Table 4: Percent Inter-location Simultaneous Calls You can use Table 5 as a very general guide to help you determine an appropriate value. You can fine tune this value as you monitor each site for call patterns. The ultimate goal again is to minimize BW usage while allowing for as many calls to go through at the best appropriate quality. Video endpoints are more likely to be used to make inter-location calls than audio endpoints, therefore you will most likely have a larger % Simultaneous Inter-location value for video endpoints as compared to audio endpoints. Below is a summary table of what has been gathered so far and the results of the Total BW calculations for the given site.
Quantit y a b c d Audio Codec BW (Kbps) x x y y Video BW (Kbps) n/a n/a v=z y v=z y Maximum Multimedia BW (Kbps) n/a n/a z z % Simultaneou s Calls e e f f Total BW needs (Kbps) : Sub Total BW needs (Kbps) (a*x)*(e/100) (b*x)*(e/100) (c*z)*(f/100) (d*z)*(f/100) Sum of Column

Endpoint Type SIP Audio Endpoints Non-SIP Audio Endpoints SIP Video Endpoints H.323 Video Endpoints

Table 6: Total BW needs

Page 14 of 35

Avaya Aura 6.x Call Admission Control Best Practices

NOTE: v is the value you would see if you viewed the video statistics on an endpoint when a call is established. y is based on the audio codec you chose. z must equal y+v. You now have the total amount of bandwidth needed for a given site. The table should be adjusted as needed and will most likely require your attention on a periodic basis. You may find that the bandwidth requested must be reduced to meet your IT goals, you may have site requests to improve the end user experience (increase BW usage), or have too many calls hitting the CAC BW limit you have engineered/administered and you may need to request more BW from IT. Below is a table to guide you with your adjustments:
Desired Result Target Component Maximum MultiMedia BW (z) Audio Codec (x,y) Number of Endpoints (a,b,c,d) Percent Simultaneous Calls (e, f) Maximum MultiMedia BW (z) Audio Codec (x,y) Percent Simultaneous Calls (e, f) Action reduce per call BW limit select a compressed codec deploy less endpoints decrease percentage increase per call BW limit select a better quality codec increase percentage increase the potential of blocking a call Side Effect reduced enduser experience reduced enduser experience

Decrease BW Usage

Enhance Enduser Experience (Increase BW Usage)

enhanced enduser experience enhanced enduser experience decrease the potential of blocking a call

Table 7: Site BW Adjustment Guide The call pattern for a given site should be monitored and analyzed to periodically in order to maintain a sufficient amount of BW. For monitoring CAC usage see Section 16 - SM CAC Status Reporting. For the SIP only site in Table 7, all audio endpoints are using G.729 compressed audio codec which results in 24 Kbps per call BW usage. The video endpoints are using the G.722-64 wideband audio codec, which results in 84 Kbps of audio BW per video call. Most of the BW consumption from a video call comes from the actual video. In this example, all video calls are limited to 1024 Kbps or ~1 Mbps, which includes the 84 Kbps for audio.
Audio Codec BW (Kbps) 24
(G.729)

Endpoint Type SIP Audio Endpoints Non-SIP Audio Endpoints SIP Video Endpoints
Page 15 of 35

Quantit y 1000 0 10

Video BW (Kbps) n/a n/a 940

(1024 - 84)

Maximum MultiMedia BW (Kbps) n/a n/a 1024

% Simultaneous Calls 20 0 50

Sub Total BW needs (Kbps) 4800

(1000 x 24 x .20)

0 84
(G.722-64)

0 5120
(10 x 1024 x .50)

H.323 Video Endpoints

0 Total BW needs :

0 9920

Table 8 : Example of Site Parameters Filled in SIP only site The total peak BW need for this site to provide 20% of the audio users and 50% of the video users to make simultaneous inter-location audio and video calls is 9920 Kbps or ~10 Mbps. For a mixed SIP & H.323 site, Table 8 shows the total peak BW need for this site to provide the 20% of the audio users and 50% of video users to make inter-location simultaneous audio and video calls is 19840 Kbps or ~20 Mbps.
Audio Codec BW (Kbps) 24
(G.729)

Endpoint Type SIP Audio Endpoints Non-SIP Audio Endpoints SIP Video Endpoints H.323 Video Endpoints

Quantit y 1000 1000 10 10

Video BW (Kbps) n/a n/a 940

(1024 - 84)

Maximum MultiMedia BW (Kbps) n/a n/a 1024 1024

% Simultaneous Calls 20 20 50 50 Total BW needs :

Sub Total BW needs (Kbps) 4800

(1000 x 24 x .20)

24
(G.729)

4800
(1000 x 24 x .20)

84
(G.722-64)

5120
(10 x 1024 x .50)

84
(G.722-64)

940
(1024 - 84)

5120
(10 x 1024 x .50)

19840

Table 9: Example of Site Parameters Filled in SIP & H.323 site Site Engineering based on Bandwidth Limits If you are given a BW limit and asked how many endpoints you can support and at what quality, you can derive the best configuration by working the request in the following manner. Take the BW and determine how much you want to dedicate to audio calls vs video calls. Do this by taking the sites potential population and estimate what percentage would need video endpoints. NOTE: You can setup your system to have audio endpoints use BW allocated to video endpoints. This is termed as sharing the video BW.
Total BW = r r=x+y B W

Call Type

Page 16 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Audio Video x y

Table 10: Divide Total BW amongst Audio and Video Calls You can then fill in the table below and determine the quantity of endpoints you can support. Decide which audio codec you want to use and the maximum BW usage for your video calls.
Max Available BW (Kbps) g h Audio Codec BW (Kbps) x y Maximum MultiMedia BW (Kbps) n/a z Target % Simultaneou s Calls e f Total Number of Endpoints :

Call Type Audio Video

Quantity (g*100)/ (x*e) (g*100)/(z*e) Sum of Column

Table 11: Summary Table of BW Limits Advanced Site Engineering working with video MCUs

14. SM CAC LOCATION ADMINISTRATION Once a decision has been made to make use of Session Manager Call Admission Control and desired limits for location links have been defined, SMGR can be used to provision limits and monitor CAC enforcement. The CAC parameters for a given location are provisioned on the location administration form, located at Elements Routing Locations. This form contains sections government the bandwidth constraints on the link from the location to the core, as well as per-call bandwidth restrictions, CAC alarming parameters, and a mapping of IP addresses to the location. Not all of these settings exist prior to SMGR 6.2. SM 6.0, which does not examine SDP, contains only the IP address mapping and fields for the overall bandwidth limit and the amount of bandwidth to count per call. SM 6.1 does not contain the customizable alarming fields. Form sections are explained in detail as follows:

Page 17 of 35

Total Bandwidth (number, default blank, range 0-[large number], units dropdown) The total bandwidth available for use by any calls between this location and other locations. Attempts to exceed this limit will result in call quality being reduced or calls being blocked. If blank, the limit is infinite. Multimedia Bandwidth (number, default blank, range 0-[large number], units same as Total Bandwidth, must be <= Total Bandwidth) The bandwidth available for use by multimedia calls between this location and other locations. This is a subset of the Total Bandwidth value. Attempts to exceed this limit will result in call quality being reduced or calls being blocked. If blank, the limit is not defined, and multimedia calls are subject to the Total Bandwidth limit. Audio Calls Can Take Multimedia Bandwidth (checkbox, default true) If checked, the bandwidth reserved for multimedia calls may also be used for audio calls. If unchecked, this bandwidth may only be used for multimedia calls and audio-only calls have a separate, de facto limit of Total Bandwidth Multimedia Bandwidth. This setting can be used to partition the locations bandwidth between audio and video users and prevent overlap in the partitions, if desired. *Notes About These Settings A multimedia call is defined as a call that contains non-audio media. A common example of a multimedia call is a video call. The multimedia sublimit can be used to restrict multimedia calls, which typically consume more bandwidth than pure audio calls, to a subset of the locations Total Bandwidth. Entire calls are counted as either audio or multimedia; the audio portion of a video call is considered multimedia and subjected to the multimedia sublimit, if administered. If a call establishes multimedia but is later voluntarily reduced to audio-only by the call parties, the call will continue to be categorized as multimedia by CAC throughout its lifetime.

Page 18 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Maximum Multimedia Bandwidth (Intra-Location) (number, default 1000, range 0-15360, units Kbit/sec, can be blank) The maximum bandwidth allowed for a single multimedia call within this location. Calls requesting more bandwidth than this number will be modified (downsped) to use less bandwidth. Maximum Multimedia Bandwidth (Inter-Location) (number, default 1000, range 0-15360, units Kbit/sec, can be blank) The maximum bandwidth allowed for a single multimedia call between this location and another location. Calls requesting more bandwidth than this number will be modified (downsped) to use less bandwidth. Minimum Multimedia Bandwidth (number, default 64, range 64-15360, units Kbit/sec, can be blank, must be less than either maximum number above) The minimum bandwidth per multimedia media stream that Session Manager will use when reducing (downspeeding) the bandwidth request for a call to or from this location to enforce any bandwidth restriction. If a bandwidth restriction requires Session Manager to reduce a media stream below this level, the stream will be removed from the call, possibly resulting in the entire call being blocked or the user having an audio-only call. Media requests for bandwidth beneath this minimum will not be blocked; this is solely a restriction on how Session Manager can modify requests. This value ensures a minimum level of call quality. Default Audio Bandwidth (number, default 80, range 0-15360, units Kbit/sec, cannot be blank) The audio bandwidth assumed to be used by a call originating in this location that does not explicitly specify its bandwidth needs using the Session Description Protocol (SDP). Such calls will be assumed to be audio-only. Also, if the SDP stream is not present or a SIP device provides SDP that is not recognizable or unreadable by Session Manager, then Session Manager will not block the call but allow it and designate this value for the call. SM 6.0, which does not read SDP, assumes that all calls use this value and are audio-only.

Page 19 of 35

Overall Alarm Threshold (select disabled else a value) Alarm threshold percentage. 100% means the alarm is raised when the maximum administered CAC values are sustained over the latency. Multimedia Alarm Threshold (select disabled else a value) Alarm threshold percentage. 100% means the alarm is raised when the maximum administered CAC values are sustained over the latency. Latency before Overall Alarm Trigger (0 to 30 minutes) A delay in minutes before an alarm is triggered. Latency before Multimedia Alarm trigger (0 to 30 minutes) A delay in minutes before an alarm is triggered. *Notes About These Settings When a CAC alarm is raised: Prior to SM 6.2, CAC alarm settings did not exist. SM implemented an alarm using a rough heuristic that judged when a high number of call completions left the locations link at over 80% of capacity over a period of time. In 6.2, the trigger settings are administrable. SM will take a snapshot of usage every 60 seconds, and if enough consecutive snapshots show usage above the threshold, the alarm will be raised. As depicted in the screenshot, an alarm will be raised if usage is over 80% for 6 consecutive snapshots an initial one and five additional ones. Setting the latency to 0 will result in an alarm if any snapshot shows the threshold being exceeded. What a CAC alarm means: - There is more simultaneous call traffic than anticipated at a specific Location. - The provisioned bandwidth for a specific Location is insufficient for the actual carried traffic. - The provisioned bandwidth for a specific Location is correctly set according to LAN characteristics; however traffic exceeds actual network capacity. Disabling CAC Alarms:

Page 20 of 35

Avaya Aura 6.x Call Admission Control Best Practices

All CAC alarms raised can be disabled on a global basis. If the option is selected, then it applies to all Session Managers. Elements Session Manager Session Manager Administration. Select global setting: Disable Call Admission Control Threshold Alarms. Ignore SDP for Call Admission Control Another global setting defined next to the alarm setting described above is the ability to completely disable SMs inspection of SDP to determine bandwidth values. This setting exists to allow users to forego bandwidth-based CAC in favor of an approach that effectively limits the number of calls into or out of a location. This behavior does NOT exist on Avaya Aura components other than Session Manager. It was introduced as part of the Session Manager 6.0 release. To use it, toggle the global setting and remove all Shared Bandwidth Manager SIP Entity settings. Set the Default Audio Bandwidth and Overall Managed Bandwidth values for each location such that the desired call count limit times the default equals the overall limit. Note that with this feature enabled, some fields in CDR records will not be populated (isVideo and maxBandwidth) because SM is no longer analyzing SDP.

IP Address Patterns IP Address Patterns define, using regular expressions, IP addresses that should be considered to reside within the location. Avaya strongly recommends using this field to map all possible IP addresses to locations. This will aid in location-based call routing as well as Call Admission Control. CAC cannot resolve a call partys media location without being able to map the IP address specified in SDP to a location using these patterns, nor can it resolve a call partys signaling location without mapping IP addresses in SIP signaling to locations, unless the call comes from a SIP Entity with a defined location (IP match overrides defined location, if both exist). SIP endpoints will receive the treatment of their administered home locations in the absence of a match to the IP address with which they register to SM. If a user registers from different location, perhaps because he is traveling, he will receive routing as if he is still at home, and CAC will count his call against his home location, even though he is not there!

Page 21 of 35

15. SESSION MANAGER CAC SIP ENTITY ADMINISTRATION SMGR 6.2 includes new entity administration options that allow the administrator to tell the SM cluster about non-SM entities that can participate in CAC. The SIP entity that controls the destination endpoint (or the one that controls the trunk if the call leaves the Avaya Aura network) is the one that should be performing CAC evaluation of the call. The reason for this is that CAC should be performed before the destination endpoint receives a SIP INVITE, but after the location of the destination is known. The location is best known by the last entity processing the call before termination. Previous entities may only know the location of the subsequent entity. SIP Entity Attributes Concerning CAC

Supports CAC This designation tells Session Manager it should not perform CAC on outgoing calls to the SIP Entity (because the entity will do so on its own). The entity is not to perform CAC on calls to SM, per the rule described above. Shared Bandwidth Manager This designation tells Session Manager that the entity can send Bandwidth PUBLISH message. The administrator can enable the Shared Bandwidth Manager attribute on any SIP Entity. If this option is checked, the administrator must further specify one or two SM instances that will receive the Bandwidth PUBLISH from that SIP Entity. (Two SMs are recommended for redundancy). An entity that is a Shared Bandwidth Manager must also be marked as Supports CAC. It will be expected to count and PUBLISH usage only when receiving calls from SM, not when sending calls to SM. It should also count and PUBLISH for calls not involving SM. Primary Session Manager Bandwidth Association If Shared Bandwidth Manager option above is selected, then a Session Manager SIP Entity must be selected from the drop down menu as the primary Session Manager for bandwidth communication. Backup Session Manager Bandwidth Association If Shared Bandwidth Manager option above is selected, then a Session Manager SIP Entity is recommended to be selected from the drop down menu as the backup Session Manager for bandwidth communication.

Page 22 of 35

Avaya Aura 6.x Call Admission Control Best Practices

16. SM CAC STATUS REPORTING System Manager can report on both the real-time status and the historical usage of bandwidth across location links as reported by the Session Manager cluster. Real-time status can be viewed by navigating to Elements Session Manager System Status Managed Bandwidth Usage.

The page lists locations alongside their current bandwidth usage and their limits and usage percentages. The number of calls is also listed as a reference. All usages cover only calls into or out of the location; calls that do not send media out of the location are not subject to the limits and are not counted here. An expansion of each entry breaks down the usage by the Session Manager instances that are recording it. Historical location usage can be viewed by navigating to Elements Session Manager Performance Location Performance. This page requests selection of a location and specification of a time frame, after which data can be expected to CSV or XML format or graphed on the screen. There are three available data graphs. The first displays the locations bandwidth in use. The second displays the locations bandwidth available. The third displays historical counts of call attempts for the location, with each call attempt categorized as either denied, downgraded, or completed, depending on how CAC impacted the call (if at all). All graphs use a five-minute sample interval. The first two graphs count calls and bandwidth amounts only for calls that enter or leave the location and are subjected to the locations bandwidth limit. The third graph counts all calls involving the location, even those that do not exit the location. Sample graphs are displayed below:

Page 23 of 35

Page 24 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Page 25 of 35

17. CM CAC ADMINISTRATION If the use of CM CAC without the Bandwidth PUBLISH is desired, location limits will be provisioned using CMs administration, and monitoring will also be done on CM. Using the site information you gathered from Section 13 - Site Engineering, you can now begin to administer your CM CAC. A brief recap before we get started. Partitioning total bandwidth generally starts by separating calls first by a logical location, generally geographical, second by type of call: audio-only or multimedia, and third, for H.323 endpoints, by type of user: normal or priority. Grouping endpoints by normal and priority users is only available on CM for H.323 endpoints. To partition bandwidth by geographical location, you use Network Regions. This section addresses the additional partitioning methods organized by the type endpoints used in a typical enterprise: H.323 only or a combination of H.323 and SIP. H.323 only H.323 offers the ability to separate video users as normal users and priority users. What this distinction provides is the ability to allocate separate BW for priority users and you can allow greater Maximum MultiMedia limits for the priority users. Therefore we must revisit the summary table from Section 13 to accommodate for priority users. If you do not plan on having separate priority users, skip to the Network Regions sub-section.
Quantit y d Audio Codec BW (Kbps) y Video BW (Kbps) v=zy Maximum MultiMedia BW (Kbps) Z % Simultaneous Calls f Total BW needs (Kbps) : Sub Total BW needs (Kbps) (d*z)*(f/100 ) Sum of Column

Endpoint Type H.323 Video Endpoints

Table 12: H.323 Video Portion of Summary Table Take the original BW table and focus on the H.323 video endpoints. Take the quantity of H.323 video endpoints and subtract the quantity of newly determined priority endpoints. Separate assignments can then be made.

Endpoint Type

Quantit y

Audio Codec BW (Kbps)

Video BW (Kbps)

Maximum MultiMedia BW (Kbps)

% Simultaneous Calls

Sub Total BW needs (Kbps)

Page 26 of 35

Avaya Aura 6.x Call Admission Control Best Practices

H.323 Normal Video Endpoints H.323 Priority Video Endpoints d d' y y v=zy v' = z' y Z z' f f' Total BW needs (Kbps) : (d*z)*(f/100 ) (d*z)*(f/100 ) Sum of Column

Table 13 : Separating H.323 Video Users as Priority and Normal Users The example below shows a site with 12 H.323 video endpoints, 8 have been designated as Normal users and 4 have been designated as Priority users. The Normal users have been assigned 1024 Kbps of maximum multimedia BW, while the Priority users have been assigned 1984 Kbps.
Audio Codec BW (Kbps) 24
(G.729)

Endpoint Type Non-SIP Audio Endpoints H.323 Normal Video Endpoints H.323 Priority Video Endpoints

Quantit y 400 8 4

Video BW (Kbps) n/a 940

(1024 - 84)

Maximum MultiMedia BW (Kbps) n/a 1024 1984

% Simultaneous Calls 20 50 50 Total BW needs (Kbps) :

Sub Total BW needs (Kbps) 1920

(1000 x 24 x .20)

84
(G.722-64)

4096
(10 x 1024 x .20)

84
(G.722-64)

1900
(1984 - 84)

3968
(10 x 2048 x .20)

9984

Table 14 : Example of Separating H.323 Video Users as Priority and Normal Users Network Regions: Network Region administration is done by pairing Network Regions together, assigning BW CAC to the pairing and associating an ip-codec-set with the pairing. Network Region engineering must be separated into two activities: i) Bandwidth CAC and NRs: A hub and spoke model is used to represent WAN connections per site. The hub will represent the WAN and the spokes will be the sites themselves. An NR is logically assigned the role of WAN and any NR pairings with it is where you will administer all CAC settings. An ip-codec-set is required for this pairing, but does not impact the final site to site call. That is reserved for the site to site NR pairing described in the next activity. Audio Codec Selection and NRs: Each pair of sites will need to be administered as a full mesh NR topology and assigned an appropriate ip-codec-set. This ip-codec-set will be the ip-codec-set that will determine the audio codec set list and the maximum multimedia bandwidth per call.

ii)

Page 27 of 35

Figure 1 below depicts a simple deployment example. Well use this example throughout this section. NR100 represents the WAN and NR1 and NR 2 represent two different geographical locations. Site 1 has a WAN link limit of 10 Mbps and Site 2 has a 5 Mbps limit. The NR pairing that will be used for will be NR1 NR100 and NR2 NR100 for BW CAC and NR1 NR2 for audio codec selection.

Figure 1 : Simple Two Site Deployment Example The following tables represent the calculations that went into the two site deployment example. As also shown in Figure 1, the results from the calculations below is 10 Mbps required for Site 1s WAN link and 5 Mbps required for Site 2s WAN link.
Audio Codec BW (Kbps) 24
(G.729)

Endpoint Type Non-SIP Audio Endpoints H.323 Normal Video Endpoints H.323 Priority Video Endpoints

Quantit y 400 8 4

Video BW (Kbps) n/a 940

(1024 - 84)

Maximum MultiMedia BW (Kbps) n/a 1024 1984

% Simultaneous Calls 20 50 50 Total BW needs (Kbps) :

Sub Total BW needs (Kbps) 1920

(1000 x 24 x .20)

84
(G.722-64)

4096
(10 x 1024 x .20)

84
(G.722-64)

1900
(1984 - 84)

3968
(10 x 2048 x .20)

9984

Table 15 : Site 1 BW Calculations Site 1 is engineered for 400 Audio Endpoints, 8 Normal H.323 Video Users and 4 Priority Video Users.

Page 28 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Quantit y 350 6 Audio Codec BW (Kbps) 24
(G.729)

Endpoint Type Non-SIP Audio Endpoints H.323 Video Endpoints

Video BW (Kbps) n/a 940

(1024 - 84)

Maximum MultiMedia BW (Kbps) n/a 1024

% Simultaneous Calls 20 50 Total BW needs (Kbps) :

Sub Total BW needs (Kbps) 1680

(350 x 24 x .20)

84
(G.722-64)

3072
(6 x 1024 x .50)

4752

Table 16 : Site 2 BW Calculations Site 2 is engineered for 350 H.323 Audio Endpoints and 6 H.323 Video Endpoints Bandwidth CAC and NRs CM CAC allows for the separation of H.323 video endpoints into Priority video endpoints and Normal video endpoints. Below is a brief description of each of the pools that CM CAC uses. Bandwidth pools for CM CAC: AudioThe audio pool contains bandwidth for all audio calls, including the audio component of multimedia calls. Normal videoThe normal video pool contains bandwidth for the video portion of a call made by a normal (non-priority) video user. You can set this pool to be shared. When this pool is shared, audio-only calls are allowed to borrow bandwidth from this pool. Priority videoThe priority video pool contains bandwidth that is dedicated to priority video users only. Audio calls and normal video users are not allowed to borrow bandwidth from this pool. However, if all of the priority video pool bandwidth is currently in use, priority video users can borrow bandwidth from the normal video pool, if available. For H.323, you can categorize users by audio-only, normal video, and priority video users, dividing them into three pools. Taking the bandwidth calculation tables generated for the example deployment, we can use the figures to fill in the CM specific tables below:

Site 1 - CM Specific Information Needed for BW Administration:

Total Bandwidth Audio Bandwidth Pool Priority Video Bandwidth Normal Video Bandwidth Pool Share Normal Video Bandwidth

Page 29 of 35

Pool? 10 Mbps 2 Mbps 4 Mbps 4 Mbps Yes

Site 1 has been engineered for a total BW of 10 Mbps, 2Mbps for audio, 4 Mbps for Priority Video, 4 Mbps for Normal Video, and to allow for audio endpoints to share the Normal Video BW in case they run out. Site 2 - CM Specific Information Needed for BW Administration:
Total Bandwidth 5 Mbps Audio Bandwidth Pool 2 Mbps Priority Video Bandwidth 0 Mbps Normal Video Bandwidth Pool 3 Mbps Share Normal Video Bandwidth Pool? No

Site 2 has been engineered for a total BW of 5 Mbps, 2 Mbps dedicated for audio calls, no Priority H.323 video endpoints, 3 Mbps for Normal video endpoints, and no sharing of Normal BW. Bandwidth CAC Administration: Taking the information from Figure 1 and from the CM specific information you can now administer the BW information for NR100 NR1 and NR100 NR2:
change ip-network-region 100 Source Region: 100 Page I G A R n n 4 of A G L 20 M t c e t t

Inter Network Region Connection Management Dyn CAC

dst codec direct WAN-BW-limits Video Intervening rgn set WAN Units Total Norm Prio Shr Regions 1 2 y Mbits 10 4 4 y 2 2 y Mbits 5 3 0 n

NOTE: The ip-codec-set used for this pairing is not important. It will not be used during the actual call processing. The site to site NR pairing (NR1 NR2) is the codec set that will be applied. The important information that will be used for these sets of NR pairings (NR100 NR1 and NR100 NR2) is the BW parameters. Audio Codec Selection You can assign only one ip-codec-set per NR pairing. The audio endpoints and the video endpoints will share the common list. Therefore, if you plan on having your audio endpoints use a compressed audio codec and your video endpoints use a wideband audio codec, you must administer the compressed audio codec first and then the wideband audio codec. You must then not include the compressed audio codec on the list of the actual video endpoints. The video endpoints and CM will
Page 30 of 35

Avaya Aura 6.x Call Admission Control Best Practices

utilize first matching codec, which will be the wideband audio codec. If you plan on using the same audio codec for both audio and video endpoints, then list the audio codecs as needed.
change ip-codec-set 2 IP Codec Set Codec Set: 2 Audio Codec 1: G.729 2: G.722-64K 3: G.711MU 4: 5: 6: 7: Silence Suppression n n Frames Per Pkt 2 2 2 Packet Size(ms) 20 20 20 Page 1 of 2

NOTE: If you place a compressed audio codec before a wideband audio codec, you will get a warning that the wideband audio codec should be in first position. Ignore this warning if that is your intent and re-submit the form. Page 2 of the ip-codec-set form is where you will administer the Maximum MultiMedia BW (z). The CM form refers to this setting as the Maximum Call Rate for Direct-IP Multimedia.
change ip-codec-set 2 IP Codec Set Allow Direct-IP Multimedia? y Maximum Call Rate for Direct-IP Multimedia: 1024:Kbits Maximum Call Rate for Priority Direct-IP Multimedia: 1984:Kbits FAX Modem TDD/TTY Clear-channel Mode relay off US n Redundancy 0 0 3 0 Page 2 of 2

Once the ip-codec-set list is place you want to apply the ip-codec-set list to the NR1 NR2 pairing. Below we have NR1 connected to NR2 via NR100 using ip-codec-set 2. NR 100 is the interleaving NR.
Page 31 of 35

change ip-network-region 1 Source Region: 1

Page I G A R n

4 of A G L all

20 M t c e t

Inter Network Region Connection Management Dyn CAC

dst codec direct WAN-BW-limits Video Intervening rgn set WAN Units Total Norm Prio Shr Regions 1 1 2 2 n 100: : :

Scoping Endpoints to an NR As a final step you must scope the H.323 endpoints accordingly to each of the sites. This is done by mapping the IP networks to NRs using the ip-network-map form:
change ip-network-map IP ADDRESS MAPPING Subnet Network Emergency IP Address Bits Region VLAN Location Ext --------------------------------------------- ------ ------ ---- ------------FROM: 135.5.1.1 / 1 n TO: 135.5.1.253 FROM: 135.9.2.1 / 2 n TO: 135.9.2.253 FROM: / n TO: FROM: / n TO: Page 1 of 63

Site 1s subnet that is supporting its local endpoints consists of the IP address range 135.5.1.1 through 135.5.1.253 and is assigned to NR1. Site2s subnet that is supporting its local endpoints consists of the IP address range 135.9.2.1 through 135.9.2.253 and is assigned to NR2.

H.323 and SIP Endpoints using CM CAC Add SIP endpoints is the same process as described for H.323 endpoints. The only difference is that differentiating priority users is not available. You must scope the SIP endpoints just as you did for the H.323 endpoints. Priority user tagging for SIP endpoints 18. CM CAC REPORTING If the use of CM CAC without the Bandwidth PUBLISH is desired, location limits will be provisioned using CMs administration, and monitoring will also be done on CM. The primary
Page 32 of 35

Avaya Aura 6.x Call Admission Control Best Practices

source for monitoring the BW usage is the status ip-network-region X command, where X is 100 the WAN NR from Section 17.
status ip-network-region 100 Inter Network Region Bandwidth Status Number of # Times Conn BW-limit BW-Used(bits) Connections BW-Limit IGAR Stat Tx Rx Tx Rx Hit Today Now/Today 2 4 4 2 3 0 Mbits Mbits Mbits Mbits Mbits Mbits 84K 940K 0K 84K 940K 0K 84K 940K 0K 84K 940K 0K 1 1 0 1 1 0 1 1 0 1 1 0 0 0 0 0 0 0 0/ 0

Src Dst Rgn Rgn 100

Conn Type

1 direct

pass Video: Priority: pass Video: Priority:

100

2 direct

0/

Monitoring # Times BW-Limit Hit Today is the key field to watch. This value will give you an indication if more calls are being originated than the engineering BW supports. Site engineering adjustment should be considered if an over usage pattern is found. 19. AVAYA AURA CAC and MULTIPLE MPLS NETWORKS Avaya Aura CAC was designed for hub and spoke networks; where the core is assumed to be connected with essentially unlimited bandwidth between core elements. CM can handle a multiple MPLS network by using a concept of Ghost Network Regions (aka Virtual Network Regions) to accomplish such a goal. With a multiple MPLS situation and Session Manager, one would need a way of modeling the link between multiple MPLS providers (which have a defined amount of bandwidth between one another). There in fact may not be enough bandwidth for a call to transit though MPLS networks even through there is enough bandwidth between the specific SIP entity/locations and its associated MPLS provider. Consider the following diagram of a multiple MPLS network and SDN. Two possible solutions to accomplish CAC are listed below.

Page 33 of 35

1. Connect the MPLS networks with a router (or use an existing connection). Treat the connected networks as a core and don't use the CMs to route between them, but treat those connecting CMs as their own location and let the SMs route through each other instead. o This may totally defeat your purpose, however, in wanting to more precisely control the inter-MPLS network bandwidth. 2. Associate an SM with each MPLS network. Replace the interconnecting CMs with explicit inter-SM SIP entities and entity links. Set up explicit routing between the SMs over these links. o This essentially creates four cores (see diagram). o Use location-based routing: e.g. for all locations off the AT&T SM, put in explicit routes (like CM-2) to the CMs there and back to MPLS provider A (like for CM-1) and over to MPLS provider C (like for CM-3). The problem here is the combinations. You'd need each CM in its own location for CAC, so you'd need each explicit route for each location. For the entire picture above you'd need roughly 24 x 24 dial patterns. NRP importing should make this easier to set up. These routes would choose SIP Entities representing the other SM (but not the Entities which are the actual SM instances). These somewhat "fake" SM sip entities would be in different locations and each SM would be in the "core", so you could apply CAC to the calls between the SMs. A given SM would see the call to the other SM as a call to a different location. o We normally recommend this configuration when you want to also use four different System Managers, but that shouldn't make any difference, save that it is not a well-tested situation. 3. A slight modification to #2 is to leave the inter MPLS network CMs in place (which you may have to do for the SDN--not an MPLS network--connected CMs anyway). Again, use explicit routes through the CMs (real SIP entities, not fake ones). o Here you wouldn't have to use CAC, but instead have the CM's trunk limit do the same thing. This would essentially give you the inter-CM trunk reduction within each MPLS network, but leave you with the explicit routing (and increased trunk needs) between them.

Page 34 of 35

Avaya Aura 6.x Call Admission Control Best Practices

Page 35 of 35