SM CAC Best Practices

8/2/2019 SM CAC Best Practices

1/35

Avaya Aura 6.x Call Admission ControlBest Practices

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

Page 1 of35


2/35

CID: 151364Contents

Page 2 of35


3/35


To achieve optimal bandwidth management in an enterprise data network, an administrator needs tounderstand Avaya Auras CAC functionality. This document presents relevant concepts in an orderedfashion. Readers are cautioned that many sections of the document build on preceding sections.

2. ACRONYMSThe following acronyms are used:

CAC Call Admission and ControlBW Bandwidth

SDP Session Description ProtocolSIP Session Initiation ProtocolSM Avaya Aura Session ManagerCM Avaya Aura Communicator ManagerSMGR Avaya Aura System ManagerMMCS- Avaya Aura Multimedia Collaboration Server

3. REFERENCESAuthors:Steve EricksonChris Baldwin

James Free

Andy Cornejo

Kurt Haserodt

Barb Garcia

4. INTRODUCTION

Call Admission Control (CAC), or Bandwidth Management, is a service provided by Avaya Aurathat prevents IP telephony from attempting to use more bandwidth than is available for a particularlink in an IP network. Without this, a network could experience a volume of traffic that would resultin call degradation due to dropped packets, including lost talkpath and dropped calls. Anyone whosattempted to use a cell phone at a major sporting event probably knows the experience the stadiumtheoretically has excellent coverage, but the sheer number of people using devices simultaneouslyleads to almost nonexistent service for everyone.

CAC remedies this problem by preventing the establishment of new calls over a particular link if itdetermines that the link is at capacity. This ensures that preexisting calls continue to get qualityservice with no packet loss. It may result in a negative experience for the person attempting to makethe new call (call denial), but it may also simply result in the call being redirected to what theenterprise network perceives as a new destination. The new destination may truly be a newdestination, but it may also be a different route to the original destination. A common example seesthe IP network unable to reach the destination due to CAC-determined network exhaustion, so thecall is routed out a public trunk. The call reenters the IP network through another public trunk in thedestinations location and terminates. The caller and callee are unaware that their call used the publicnetwork instead of the enterprise IP network. The customer does incur the cost (tolls) of using thepublic network, but presumably this is preferable to the call failing altogether. The ideal, of course, isthat the IP network has capacity for all calls and the public network and its tolls are never used.

Page 3 of35


4/35

The preceding scenario illustrates a key principle of CAC: that user experience when a call confrontsnetwork exhaustion (as determined by CAC) should be identical to user experience during networkoutage (the network is down). In either case, the network is unavailable; the reason should not matterto 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 thescope of this document, but a brief mention is needed to lay the ground work for what CAC isintended to influence.

A location is engineered with a certain amount of bandwidth on its WAN link. Voice, video, and datapackets must share this bandwidth. DiffServ QoS implementation separates and prioritizes the packettraffic according to their Differentiated Services Codepoint (DSCP) tags. Properly administeringpriority 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 examplerecommendations 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, LowDrop Precedence)

The priority tagging will determine the order in which the packets will get dropped in the event oftraffic congestion on a router. In the event of congestion data packets will get dropped first, thenvideo packets, then the audio packets of a given video call, and finally audio packets of a givenaudio call. The goal of CAC is to reduce the likelihood of experiencing congestion on the networksedge routers. In other words, CAC has the responsibility of controlling the flow of packets onto therouter WAN links. This is primarily accomplished by blocking additional calls when a WAN link ison the verge of congestion. As an added control measure Avaya Aura can limit the amount ofbandwidth requested on a per call basis. Please note that CAC can only influence the audio andvideo packets. If there is a burst of data packets then a properly engineered Diffserv QoS network, asdescribed 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 isthat 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 orTokyo. The same bandwidth is used to traverse it. A call from Los Angeles to New York uses the Los

Page 4 of35


5/35


Angeles Link and the New York Link. A call from Los Angeles to Tokyo uses the Los Angeles linkand the Tokyo link. SIP Signaling may have intermediate destinations, such as Avaya AuraSequenced Applications, but media, which consumes the only significant bandwidth, is ultimatelyestablished directly from endpoint to endpoint.

Because its easier to speak of links being between two things, we refer to these links as links from alocation to the core, where the core represents the services available to the enterprise. The core isnot a user location, though components in the core may share physical locations (datacenters) withsome enterprise users. It has little substance from a CAC perspective because media is not expectedto terminate in the core. Media flows from user location to user location. The following drawingillustrates the hub-and-spoke topology:

A key takeaway here is the assumption that bandwidth usage is direct from endpoint to endpoint. SIPsignaling legs in the core are not expected to indicate intermediate media terminations. Also note thatif both endpoints in a call are in the same location, media should never leave the location. Thebandwidth 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). Bandwidthusage is counted in these terms, with the active count being measured against the limit to determinewhether a call or call route should be allowed. All bandwidth usage and limits is assumed to bebidirectional. For example, an audio call using the G.729 codec sends at a rate of 18 KBit/sec in each

Page 5 of35


6/35

direction. CAC will count this call as 18 KBit/sec, and will deny it if the limit minus preexistingusage 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, orenforce 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, cyclingthrough far-end images as requested by the endpoint or provided by the conferencing server. Avayawill 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 establishmentsin 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 locationadministration within System Manager (SMGR). These limits apply to the link from the location tothe core. SMGR provides status pages for viewing bandwidth usage by location both in real time andhistorically. SMGR also provides eventing when calls are impacted by bandwidth limits and alarmswhen locations persist in a high occupancy state.

SM CAC processing occurs every time a SIP message related to an INVITE dialog passes throughthe SM cluster. The message is analyzed and SDP is parsed to determine both the locations involvedand the amount of bandwidth used. If a locations limit would be exceeded by a SIP request, therequest may be denied with a SIP 488 response containing at 370 Warning header indicating thereason 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 maynot be denied, but rather will have its bandwidth reduced so that it fits within the locations limit. SMeven has Per-Call bandwidth restrictions for locations, which can be administered to cap thebandwidth for any single SIP call, regardless of progress towards the locations overall limit. In-dialog SIP requests are subject to the same processing as the initial INVITE, though they cannot bealternate 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 toaudio-only by the user. As of SM 6.2, SM CAC will even recognize a mid-call change in the locationof 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 equalamount 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 otherentities 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 severalways 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 twoH.323 users on the same CM does not generate a single SIP message. A call from a SIP user to an

Page 6 of35


7/35


H.323 user will involve SIP, but SM will route the SIP signaling to the H.323 users CM withoutknowing the location of the H.323 user itself. The only way CAC can properly account for the H.323user 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 willroute 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 trackthe usage and enforce the limit. In the above scenario, we see that both SM and CM can record asubset of the uses of bandwidth for a location. As neither sees all uses, the two must communicateusage with each other. SMs within a cluster have always done this. CMs have their own CACcapability, but they do not communicate with other entities. The capability to receive informationfrom other devices that wish to record bandwidth usage is being added to SM 6.2. Thiscommunication is received via a SIP PUBLISH for the Bandwidth event package, defined in CID149836. The initial release of the Avaya Multimedia Collaboration Server (MMCS) and the 8.0release 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 makesome 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 destinationendpoint. This is true for several reasons. As stated earlier, CAC denial should behave similarly toWAN outage. In a WAN outage, the destination would not receive the INVITE. Once the INVITEreaches the endpoint, it begins to alert. We do not want to alert the user in a case where the callsmedia cannot be established. Also, CAC denial may lead to alternate routing. Alternate routing isperformed 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 onlyone 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 destinationslocation. Consider the diagram below. A SIP user is registered to SM1. It uses a number of AuraSequenced 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 locationis not known when SM1 or SM2 receive the initial SIP INVITE. CAC calculations are performed inCM. If the H.323 user calls the SIP user, the SIP users location is not known by CM nor SM2, but isdetermined by SM1 before it terminates the initial INVITE.

Page 7 of35


8/35

The SM cluster is intelligent enough to only perform CAC calculations at the moment just before theinitial SIP INVITE leaves the cluster for the final time. It does not, by default, know whether a non-SM 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 bedesignated 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 CACcalculations because the entity will do so. Note that this applies only for calls TO the entity, not callsFROM 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 usefullocation information to the SM cluster even in the response to the initial SIP INVITE. This PBXshould be administered in SMGR as an entity that does NOT support CAC. When this is done, theSM cluster will realize that for a call from the SIP user to the DCP user, SM2 should perform CACcalculations. As it does so, it will use its best-guess knowledge of the DCP users location, whichwill 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 allnon-SM entities are assumed to not support CAC), SMGR contains settings for informing the SMcluster when an entity supports the Bandwidth PUBLISH. Ideally, all entities that support CAC alsosupport the Bandwidth PUBLISH, so that all uses of bandwidth are counted collectively against thelocations limits as maintained by the SM cluster. If entities support CAC but not the BandwidthPUBLISH, they will be tracking usage, but doing so separately from the SM cluster, in enforcementof 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 of35


9/35


10. SM/CM CAC INTERACTION RECOMMENDATIONS

This section makes recommendations for dealing with scenarios where uses of bandwidth across thelinks 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 BandwidthPUBLISH. This happens most commonly in environments where H.323 endpoints exist and areregistered to pre-7.0 CMs.

If an enterprise consists solely of SIP users, there is no problem. All calls will traverse SM, whichwill route INVITEs directly to endpoints, so it knows all relevant locations when it processes initialINVITEs.

If an enterprise contains only one Communication Manager (or only one CS1000), which serves allusers (both SIP and non-SIP), the CAC capability of SM should be disabled (by not setting anybandwidth 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 toensure that there is no location X which contains users served by more than one CM or CS1000. Iftwo entities serve users in the same location, we will have our undesirable condition where no singleentity is aware of all uses of bandwidth for the location, making limit enforcement impossible. Anexample of this is diagrammed below.

CM1 serves all users in locations A, B, and C. Non-SIP users in these locations are registereddirectly to CM1. SIP users in these locations are registered to SM, but use CM1 as their featureserver. Thus all uses of bandwidth for locations A, B, and C are signaled to CM1 in some way. CM1can enforce limits for these locations. CM2 similarly serves locations D, E, and F. If a call is madebetween a user in location A and a user in location D, CM1 will see the call as flowing from A toSM, and will count bandwidth used against As limit. CM2 will see the call as flowing from SM tolocation D, and will count bandwidth against Ds limit.

Page 9 of35


10/35

Enterprises which contain non-SIP users and multiple CMs (or CS1000s) in which some locationsare served by more than one CM will not receive the full benefits of Avaya Aura CAC until CMsupport for the Bandwidth PUBLISH arrives. If CAC is highly desirable, an enterprise shouldattempt 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 particularCM/CS1000 are in the same location. This would be administered by marking all CM/CS1000sas not supporting CAC. The SM cluster would then perform CAC calculations for callsterminated to non-SIP users by assuming that they terminate in the administered location of theCM/CS1000.

2. The enterprise could accept partial limit enforcement. Suppose a location has a link capable ofsustaining bidirectional media at a rate of 10 MBit/sec. This location contains both SIP and non-SIP stations at a ratio of 3/1 (SIP to non-SIP), where the frequency of calls made isapproximately 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 onbehalf of the non-SIP users. On SM, the location could be given a limit of 9 MBit/sec, and onCM, a limit of 3 MBit/sec. This could potentially allow 12 MBit/sec of traffic to flow over thelocations link, but could also deny calls to SIP stations when the links usage is at 9 MBit/sec (ifall H.323 users are idle), or could deny calls to H.323 stations when usage is at 3 MBit/sec (if allSIP users are idle), because one component (SM or CM) would see its view of the limit beingreached. This type of configuration is discouraged due to its complexity and upcomingobsolescence.

11. SESSION MANAGER LOCATION DETERMINATION

Key to CAC behavior is the determination of the location of call parties. CAC will count bandwidthacross the links to/from the locations of call parties if and only if the parties are not in the samelocation (no inter-location links are traversed by the media for an intra-location call). SM tracks upto three different flavors of location for a particular call party. Only one of these locations will betreated as the source of media for CAC purposes. The first two concepts of location called signalinglocation 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 refersto the location that the user is based out of.

Media location is derived solely using IP pattern match on the IP address of media originationspecified 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 bottommostVia header in the request. If this does not match a known IP pattern, the provisioned location of asending SIP Entity may also be used, if applicable. Because the home location is a mandatory fieldthat cannot be left blank, the idea is to guarantee that there is some reasonable location for the usereven in the absence of an IP pattern match.

Page 10 of35


11/35


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 IPaddresses 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, thehome location is the final fallback choice. It is only possible for a call party to have no location if theparty is a non-SIP user (no home location) and there are no IP patterns matching any aspect of thecall party. At this point, the user is considered to be calling from within the core. No bandwidthrestriction of any kind will be applied for such a call party (restriction may still occur on behalf ofthe other call party).

Note the importance of provisioning IP patterns for locations. If this is not done, SIP users will beconsidered to be calling from their home location even if they are traveling and actually calling fromanother 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 likeemergency calls and fetching location specific registration/subscription parameters. SM can stillroute a call even if location for the originator is undefined; it will just not match any location specificdial patterns.

Calls between more than two parties receive CAC treatment based on their media paths, which candiffer 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 wouldreflect 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 norfully 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 thepriority user. Avayas Multimedia Collaboration Server (MMCS) allows users to be provisioned withand granted priority when forming multimedia conferences. CM CAC also allows for some conceptof priority. SM CAC, as a rule, does not impact preexisting calls in the process of finding bandwidthfor new calls or call enhancements. Thus it does not have the concept of priority users, which meansthis 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 locationadministration allows not only a limit on total bandwidth for the link to a location, but also asublimit on multimedia bandwidth. This sublimit can be used to prevent a few high bandwidth videousers from exhausting the locations bandwidth and starving all other users. Once the sublimit isreached, subsequent calls will be granted only audio media until the overall limit is reached.Administration of both limits is optional.

Page 11 of35


12/35

13. SITE ENGINEERING

The goal for engineering a given site is to allow as many simultaneous calls to be established whileproviding the best experience possible for those users. There is a balance between the call qualityexperience and BW usage. Higher quality experiences require more BW. This section will guide youon how to best navigate through the process of engineering a successful site.

As described in previous sections, BW management is achieved by administering useful andmeaningful CAC based on a sites needs. Planning can be driven from different perspectives. Thissection will focus on two:

i) Site engineering based on endpoint quantity: you are asked to calculate the bandwidthneeds for a given site based on number of employees at a site, quality of experience

needs, and expected maximum percentage of simultaneous calls.ii) 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, atwhat 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 youwill first need to gather the quantity of endpoints needed, grouped by phone type.

Endpoint Count Quantity

1 Number of SIP audio endpoints a

2 Number of Non-SIP (H.323/DCP/analog) audio endpoints b

3 Number of SIP video endpoints c

4 Number of H.323 video endpoints d

Table 1: Number of Endpoints

Page 12 of35


13/35


The endpoint quantities from Table 1 can have their call flows split into two groups, intra-locationcalls and inter-location calls. The focus is on inter-location calls. Inter-location calls are most likelyto have BW restrictions whereas intra-location calls will most likely have plenty of LAN BWavailable.

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 controllingmechanism for this is CMs ip-codec-set list and the administered/supported audio codec selectionlist from the endpoints themselves. For a successful point to point audio call, both endpoints and CMmust agree on at least one common audio codec. Below is a sample of some commonly used audiocodecs and their respective BW usage. The values are shown against 20ms frames. Overheadincludes 464 bits per packet to cover headers and trailers.

# Audio Codec

Approx BW (Kbps) at

20ms Frame Lengths

Approx BW (Kbps) at20ms Frame Lengths

PLUS Overhead1 G.729 8 24

2 G.711 64 80

3 G.722-64 64 80

4 G.722.1-32K 32 51

5 G.722.1-24K 24 43

6 Polycom Siren14-48 48 72



9Polycom Siren22-128 128 147

10 Polycom Siren22-96 96 11511 Polycom Siren22-64 64 83





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 givenvideo call. The Avaya Aura solution does not allow for explicitly selecting the BW usage for a givenvideo call, but it does however provide for control mechanisms to limit the maximum amount of BWused per video call. This is done either on the SMs location form or CMs ip-codec-set form, whichdepends on the specific implementation. For each site you will need to determine the maximumMultiMedia BW allowed per video call:

Maximum MultiMedia BW z (Kbps)

Page 13 of35


14/35

Table 3: Maximum MultiMedia Bandwidth

NOTE: The Maximum MultiMedia BW includes the audio BW plus the video BW for a given videocall. 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 tocomplete the calculations. This value is a percentage is assigned per site, per endpoint type that yougathered 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:

EndpointType

% SimultaneousInter-location

1 Audio e

2 Video 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 finetune this value as you monitor each site for call patterns. The ultimate goal again is to minimize BWusage 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 endpointsas 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.

Endpoint TypeQuantit

y

AudioCodecBW

(Kbps)

VideoBW

(Kbps)

MaximumMultimedia BW

(Kbps)

%Simultaneou

s Calls

Sub TotalBW needs

(Kbps)

SIP AudioEndpoints a x n/a n/a e (a*x)*(e/100)

Non-SIP AudioEndpoints b x n/a n/a e (b*x)*(e/100)

SIP VideoEndpoints c y

v = z y z f (c*z)*(f/100)

H.323 VideoEndpoints d y

v = z y z f (d*z)*(f/100)

Total BWneeds (Kbps)

:Sum ofColumn

Table 6: Total BW needs

Page 14 of35


15/35


NOTE: v is the value you would see if you viewed the video statistics on an endpoint when a callis 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 asneeded 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 improvethe end user experience (increase BW usage), or have too many calls hitting the CAC BW limit youhave engineered/administered and you may need to request more BW from IT. Below is a table toguide you with your adjustments:

Desired Result Target Component Action Side Effect

Decrease BW Usage

Maximum MultiMediaBW (z)

reduce per call BWlimit reduced enduser experience

Audio Codec (x,y)select a compressedcodec reduced enduser experience

Number of Endpoints(a,b,c,d) deploy less endpoints

Percent SimultaneousCalls (e, f) decrease percentage

increase the potential ofblocking a call

Enhance Enduser

Experience(Increase BW Usage)

Maximum MultiMediaBW (z)

increase per call BWlimit enhanced enduser experience

Audio Codec (x,y)select a better qualitycodec enhanced enduser experience

Percent SimultaneousCalls (e, f) increase percentage

decrease the potential ofblocking a call

Table 7: Site BW Adjustment Guide

The call pattern for a given site should be monitored and analyzed to periodically in order tomaintain a sufficient amount of BW. For monitoring CAC usage see Section 16 - SM CAC StatusReporting.

For the SIP only site in Table 7, all audio endpoints are using G.729 compressed audio codec whichresults in 24 Kbps per call BW usage. The video endpoints are using the G.722-64 wideband audiocodec, which results in 84 Kbps of audio BW per video call. Most of the BW consumption from avideo 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.

Endpoint Type

Quantit

y

Audio

CodecBW

(Kbps)

VideoBW

(Kbps)

MaximumMultiMedia BW

(Kbps)

%Simultaneous

Calls

Sub TotalBW needs

(Kbps)

SIP Audio

Endpoints 100024

(G.729) n/a n/a 204800

(1000 x 24 x .20)

Non-SIP Audio

Endpoints 0 0 n/a n/a 0 0

SIP Video

Endpoints 1084

(G.722-64)

940(1024 - 84) 1024 50

5120(10 x 1024 x .50)

Page 15 of35


16/35

H.323 VideoEndpoints 0 0 0 0 0 0

Total BWneeds : 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 tomake 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 callsis 19840 Kbps or ~20 Mbps.

Endpoint Type

Quantit

y

AudioCodec

BW

(Kbps)

VideoBW

(Kbps)


(Kbps)

%Simultaneous

Calls

Sub TotalBW needs

(Kbps)SIP AudioEndpoints 1000

24(G.729) n/a n/a 20

4800(1000 x 24 x .20)

Non-SIP AudioEndpoints 1000

24(G.729) n/a n/a 20

4800(1000 x 24 x .20)

SIP VideoEndpoints 10

84(G.722-64)

940(1024 - 84) 1024 50

5120(10 x 1024 x .50)

H.323 VideoEndpoints 10

84(G.722-64)

940(1024 - 84) 1024 50

5120(10 x 1024 x .50)

Total BWneeds : 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, youcan derive the best configuration by working the request in the following manner. Take the BW anddetermine how much you want to dedicate to audio calls vs video calls. Do this by taking the sitespotential 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

Call TypeBW

Page 16 of35


17/35


Audio x

Video 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.

Call

Type

MaxAvailable

BW (Kbps)

Audio

CodecBW

(Kbps)

MaximumMultiMedia

BW (Kbps)

Target %Simultaneou

s Calls Quantity

Audio g x n/a e

(g*100)/

(x*e)

Video h y z f (g*100)/(z*e)

Total

Number ofEndpoints :

Sum ofColumn

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 desiredlimits for location links have been defined, SMGR can be used to provision limits and monitor CACenforcement. 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 tothe core, as well as per-call bandwidth restrictions, CAC alarming parameters, and a mapping of IPaddresses to the location. Not all of these settings exist prior to SMGR 6.2. SM 6.0, which does notexamine SDP, contains only the IP address mapping and fields for the overall bandwidth limit andthe 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 of35


18/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 otherlocations. Attempts to exceed this limit will result in call quality being reduced or callsbeing blocked. If blank, the limit is infinite.

Multimedia Bandwidth

(number, default blank, range 0-[large number], units same as Total Bandwidth, must be


19/35


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. Callsrequesting more bandwidth than this number will be modified (downsped) to use lessbandwidth.

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 andanother 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 eithermaximum number above)

The minimum bandwidth per multimedia media stream that Session Manager will use whenreducing (downspeeding) the bandwidth request for a call to or from this location to enforceany bandwidth restriction. If a bandwidth restriction requires Session Manager to reduce amedia 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 forbandwidth beneath this minimum will not be blocked; this is solely a restriction on howSession 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 doesnot 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 aSIP device provides SDP that is not recognizable or unreadable by Session Manager, thenSession 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 of35


20/35

Overall Alarm Threshold (select disabled else a value)Alarm threshold percentage. 100% means the alarm is raised when the maximumadministered 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 maximumadministered 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 arough heuristic that judged when a high number of call completions left the locationslink 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 enoughconsecutive snapshots show usage above the threshold, the alarm will be raised. Asdepicted in the screenshot, an alarm will be raised if usage is over 80% for 6 consecutivesnapshots an initial one and five additional ones. Setting the latency to 0 will result inan 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 actualcarried 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 of35


21/35


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 ManagerAdministration. 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 tocompletely disable SMs inspection of SDP to determine bandwidth values. This settingexists to allow users to forego bandwidth-based CAC in favor of an approach thateffectively limits the number of calls into or out of a location. This behavior does NOTexist on Avaya Aura components other than Session Manager. It was introduced as part ofthe Session Manager 6.0 release. To use it, toggle the global setting and remove allShared Bandwidth Manager SIP Entity settings. Set the Default Audio Bandwidthand Overall Managed Bandwidth values for each location such that the desired callcount 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) becauseSM is no longer analyzing SDP.

IP Address PatternsIP Address Patterns define, using regular expressions, IP addresses that should beconsidered to reside within the location. Avaya strongly recommends using this field tomap all possible IP addresses to locations. This will aid in location-based call routing aswell as Call Admission Control. CAC cannot resolve a call partys media location withoutbeing able to map the IP address specified in SDP to a location using these patterns, norcan it resolve a call partys signaling location without mapping IP addresses in SIPsignaling to locations, unless the call comes from a SIP Entity with a defined location (IPmatch 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 withwhich they register to SM. If a user registers from different location, perhaps because heis traveling, he will receive routing as if he is still at home, and CAC will count his callagainst his home location, even though he is not there!

Page 21 of35


22/35

15. SESSION MANAGER CAC SIP ENTITY ADMINISTRATION

SMGR 6.2 includes new entity administration options that allow the administrator to tell the SMcluster 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 SIPINVITE, but after the location of the destination is known. The location is best known by the lastentity processing the call before termination. Previous entities may only know the location of thesubsequent entity.

SIP Entity Attributes Concerning CAC

Supports CAC

This designation tells Session Manager it should not perform CAC on outgoing calls tothe SIP Entity (because the entity will do so on its own). The entity is not to performCAC on calls to SM, per the rule described above.

Shared Bandwidth ManagerThis designation tells Session Manager that the entity can send Bandwidth PUBLISHmessage. The administrator can enable the Shared Bandwidth Manager attribute on anySIP Entity. If this option is checked, the administrator must further specify one or two SMinstances that will receive the Bandwidth PUBLISH from that SIP Entity. (Two SMs arerecommended for redundancy). An entity that is a Shared Bandwidth Manager must alsobe marked as Supports CAC. It will be expected to count and PUBLISH usage onlywhen receiving calls from SM, not when sending calls to SM. It should also count andPUBLISH for calls not involving SM.

Primary Session Manager Bandwidth Association

If Shared Bandwidth Manager option above is selected, then a Session Manager SIPEntity must be selected from the drop down menu as the primary Session Manager forbandwidth communication.

Backup Session Manager Bandwidth AssociationIf Shared Bandwidth Manager option above is selected, then a Session Manager SIPEntity is recommended to be selected from the drop down menu as the backup SessionManager for bandwidth communication.

Page 22 of35


23/35


16. SM CAC STATUS REPORTING

System Manager can report on both the real-time status and the historical usage of bandwidth acrosslocation 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 usagepercentages. The number of calls is also listed as a reference. All usages cover only calls into or outof the location; calls that do not send media out of the location are not subject to the limits and arenot counted here. An expansion of each entry breaks down the usage by the Session Managerinstances 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 seconddisplays the locations bandwidth available. The third displays historical counts of call attempts forthe 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 locationand are subjected to the locations bandwidth limit. The third graph counts all calls involving thelocation, even those that do not exit the location. Sample graphs are displayed below:

Page 23 of35


24/35

Page 24 of35


25/35


Page 25 of35


26/35

17. CM CAC ADMINISTRATION

If the use of CM CAC without the Bandwidth PUBLISH is desired, location limits will beprovisioned using CMs administration, and monitoring will also be done on CM. Using the siteinformation you gathered from Section 13 - Site Engineering, you can now begin to administer yourCM 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-onlyor multimedia, and third, for H.323 endpoints, by type of user: normal or priority. Groupingendpoints by normal and priority users is only available on CM for H.323 endpoints. To partitionbandwidth by geographical location, you use Network Regions. This section addresses the additionalpartitioning methods organized by the type endpoints used in a typical enterprise: H.323 only or acombination of H.323 and SIP.

H.323 only

H.323 offers the ability to separate video users as normal users and priority users. What thisdistinction 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 tablefrom Section 13 to accommodate for priority users. If you do not plan on having separate priorityusers, skip to the Network Regions sub-section.


y

AudioCodec BW

(Kbps)

VideoBW

(Kbps)

MaximumMultiMediaBW (Kbps)

%Simultaneous

Calls

Sub TotalBW needs

(Kbps)

H.323 VideoEndpoints d y

v = z -y Z f

(d*z)*(f/100)

Total BWneeds (Kbps)

:

Sum of

ColumnTable 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.323video endpoints and subtract the quantity of newly determined priority endpoints. Separateassignments can then be made.


y

AudioCodec

BW(Kbps)

Video

BW(Kbps)

Maximum

MultiMedia BW(Kbps)

%

SimultaneousCalls

Sub Total

BW needs(Kbps)

Page 26 of35


27/35


H.323 NormalVideo Endpoints d y

v = z -y Z f

(d*z)*(f/100)

H.323 PriorityVideo Endpoints d' y

v' = z' -y z' f'

(d*z)*(f/100)

Total BW

needs(Kbps) :

Sum ofColumn

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 Normalusers and 4 have been designated as Priority users. The Normal users have been assigned 1024 Kbpsof maximum multimedia BW, while the Priority users have been assigned 1984 Kbps.


y

AudioCodec

BW(Kbps)

Video

BW(Kbps)

Maximum

MultiMedia BW(Kbps)

%

SimultaneousCalls

Sub Total

BW needs(Kbps)


24(G.729) n/a n/a 20

1920(1000 x 24 x .20)

H.323 NormalVideo Endpoints 8

84(G.722-64)

940(1024 - 84) 1024 50

4096(10 x 1024 x .20)

H.323 PriorityVideo Endpoints 4

84(G.722-64)

1900(1984 - 84) 1984 50

3968(10 x 2048 x .20)

Total BWneeds

(Kbps) : 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 tothe pairing and associating an ip-codec-set with the pairing. Network Region engineering must beseparated into two activities:

i) Bandwidth CAC and NRs: A hub and spoke model is used to represent WANconnections per site. The hub will represent the WAN and the spokes will be the sitesthemselves. An NR is logically assigned the role of WAN and any NR pairings with it iswhere 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 NRpairing described in the next activity.

ii) Audio Codec Selection and NRs: Each pair of sites will need to be administered as afull mesh NR topology and assigned an appropriate ip-codec-set. This ip-codec-set willbe the ip-codec-set that will determine the audio codec set list and the maximummultimedia bandwidth per call.

Page 27 of35


28/35

Figure 1 below depicts a simple deployment example. Well use this example throughout thissection. NR100 represents the WAN and NR1 and NR 2 represent two different geographicallocations. 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 NR1NR2 for audiocodec selection.

Figure 1 : Simple Two Site Deployment Example

The following tables represent the calculations that went into the two site deployment example. Asalso shown in Figure 1, the results from the calculations below is 10 Mbps required for Site 1sWAN link and 5 Mbps required for Site 2s WAN link.


y

Audio

CodecBW

(Kbps)

VideoBW

(Kbps)


(Kbps)

%Simultaneous

Calls

Sub TotalBW needs

(Kbps)


24(G.729) n/a n/a 20

1920(1000 x 24 x .20)

H.323 Normal

Video Endpoints 884

(G.722-64)

940(1024 - 84) 1024 50

4096(10 x 1024 x .20)

H.323 PriorityVideo Endpoints 4

84(G.722-64)

1900(1984 - 84) 1984 50

3968(10 x 2048 x .20)

Total BWneeds

(Kbps) : 9984

Table 15 : Site 1 BW Calculations

Site 1 is engineered for 400 Audio Endpoints, 8 Normal H.323 Video Users and 4 Priority VideoUsers.

Page 28 of35


29/35



y

AudioCodec

BW(Kbps)

VideoBW

(Kbps)


(Kbps)

%Simultaneous

Calls

Sub TotalBW needs

(Kbps)

Non-SIP Audio

Endpoints 350

24

(G.729) n/a n/a 20

1680

(350 x 24 x .20)

H.323 VideoEndpoints 6

84(G.722-64)

940(1024 - 84) 1024 50

3072(6 x 1024 x .50)

Total BWneeds

(Kbps) : 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 andNormal 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 thispool 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 bandwidthfrom 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. ForH.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 thefigures to fill in the CM specific tables below:

Site 1 - CM Specific Information Needed for BW Administration:

TotalBandwidth

AudioBandwidthPool

Priority VideoBandwidth

Normal VideoBandwidthPool

Share NormalVideoBandwidth

Page 29 of35


30/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 casethey run out.Site 2 - CM Specific Information Needed for BW Administration:

TotalBandwidth

AudioBandwidthPool

Priority VideoBandwidth

Normal VideoBandwidthPool

Share NormalVideoBandwidthPool?

5 Mbps 2 Mbps 0 Mbps 3 Mbps No

Site 2 has been engineered for a total BW of 5 Mbps, 2 Mbps dedicated for audio calls, no PriorityH.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 Page 4 of 20

Source Region: 100 Inter Network Region Connection Management I MG A t

dst codec direct WAN-BW-limits Video Intervening Dyn A G crgn set WAN Units Total Norm Prio Shr Regions CAC R L e1 2 y Mbits 10 4 4 y n t2 2 y Mbits 5 3 0 n n t

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 endpointswill share the common list. Therefore, if you plan on having your audio endpoints use a compressedaudio codec and your video endpoints use a wideband audio codec, you must administer thecompressed audio codec first and then the wideband audio codec. You must then not include thecompressed audio codec on the list of the actual video endpoints. The video endpoints and CM will

Page 30 of35


31/35


utilize first matching codec, which will be the wideband audio codec. If you plan on using the sameaudio codec for both audio and video endpoints, then list the audio codecs as needed.

change ip-codec-set 2 Page 1 of 2

IP Codec Set

Codec Set: 2

Audio Silence Frames PacketCodec Suppression Per Pkt Size(ms)

1: G.729 n 2 202: G.722-64K 2 203: G.711MU n 2 204:5:6:7:

NOTE: If you place a compressed audio codec before a wideband audio codec, you will get awarning that the wideband audio codec should be in first position. Ignore this warning if that is yourintent and re-submit the form.

Page 2 of the ip-codec-set form is where you will administer the Maximum MultiMedia BW (z). TheCM form refers to this setting as the Maximum Call Rate for Direct-IP Multimedia.

change ip-codec-set 2 Page 2 of 2

IP Codec Set

Allow Direct-IP Multimedia? y

Maximum Call Rate for Direct-IP Multimedia: 1024:KbitsMaximum Call Rate for Priority Direct-IP Multimedia: 1984:Kbits

Mode RedundancyFAX relay 0Modem off 0TDD/TTY US 3Clear-channel n 0

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 interleavingNR.

Page 31 of35


32/35

change ip-network-region 1 Page 4 of 20

Source Region: 1 Inter Network Region Connection Management I MG A t

dst codec direct WAN-BW-limits Video Intervening Dyn A G crgn set WAN Units Total Norm Prio Shr Regions CAC R L e

1 1 all2 2 n 100: : : n t

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 bymapping the IP networks to NRs using the ip-network-map form:

change ip-network-map Page 1 of 63IP ADDRESS MAPPING

Subnet Network EmergencyIP Address Bits Region VLAN Location Ext--------------------------------------------- ------ ------ ---- -------------FROM: 135.5.1.1 / 1 nTO: 135.5.1.253

FROM: 135.9.2.1 / 2 nTO: 135.9.2.253

FROM: / nTO:

FROM: / nTO:

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 endpointsconsists 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 thatdifferentiating 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 beprovisioned using CMs administration, and monitoring will also be done on CM. The primary

Page 32 of35


33/35


source for monitoring the BW usage is the status ip-network-region X command, where X is 100the WAN NR from Section 17.

status ip-network-region 100

Inter Network Region Bandwidth StatusNumber of # Times

Src Dst Conn Conn BW-limit BW-Used(bits) Connections BW-Limit IGARRgn Rgn Type Stat Tx Rx Tx Rx Hit Today Now/Today100 1 direct pass 2 Mbits 84K 84K 1 1 0 0/ 0

Video: 4 Mbits 940K 940K 1 1 0Priority: 4 Mbits 0K 0K 0 0 0

100 2 direct pass 2 Mbits 84K 84K 1 1 0 0/ 0Video: 3 Mbits 940K 940K 1 1 0

Priority: 0 Mbits 0K 0K 0 0 0

Monitoring # Times BW-Limit Hit Today is the key field to watch. This value will give you anindication if more calls are being originated than the engineering BW supports. Site engineeringadjustment 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 beconnected with essentially unlimited bandwidth between core elements. CM can handle a multipleMPLS network by using a concept of Ghost Network Regions (aka Virtual Network Regions) toaccomplish such a goal.

With a multiple MPLS situation and Session Manager, one would need a way of modeling the linkbetween multiple MPLS providers (which have a defined amount of bandwidth between oneanother). There in fact may not be enough bandwidth for a call to transit though MPLS networkseven through there is enough bandwidth between the specific SIP entity/locations and its associatedMPLS provider.

Consider the following diagram of a multiple MPLS network and SDN. Two possible solutions toaccomplish CAC are listed below.

Page 33 of35


34/35

1. Connect the MPLS networks with a router (or use an existing connection). Treatthe 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 otherinstead.

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 CMswith explicit inter-SM SIP entities and entity links. Set up explicit routing between theSMs 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 (likeCM-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 eachCM in its own location for CAC, so you'd need each explicit routefor each location. For the entire picture above you'd need roughly24 x 24 dial patterns. NRP importing should make this easier toset 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 differentlocations 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 SMas 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 thatit 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 CMsanyway). 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 leaveyou with the explicit routing (and increased trunk needs) between them.

Page 34 of35


35/35


Documents

SM CAC Best Practices