igar

Author: CDB Systems Engineering - Basking Ridge White Paper page 1 of 12

Reviewed: various ©2010 Avaya Inc. All Rights Reserved IGAR.mkr

Date: 16 Apr 2010 COMPAS 137297

Inter-Gateway Alternate Routing

Avaya Communication Manager 5.2.1 - Issue 1.0

Abstract

This paper describes the Inter-Gateway Alternate Routing (IGAR) and related features, with

the goal of advising sales teams and customers on when IGAR works well, and when caution

should be exercised before deploying IGAR in a customer network. This paper does not pro-

vide step-by-step instructions for configuring IGAR -- for that, the reader should consult stan-

dard customer documentation.




1. Introduction

Avaya Communication Manager (CM) software offers a number of features that let customers reroute their

calls via the PSTN during outages in their corporate LAN or WAN. These include the following:

• Inter-Gateway Alternate Routing (IGAR)

• Dial Plan Transparency in Survivable Mode (DPT)

• Coverage to Remote Voice Mail

This White Paper describes the configurations in which IGAR can be safely used, as well as those

configurations in which customers may experience trouble.1 The intended audience includes

Avaya Tier III and Tier IV technical support and design personnel, as well as customers develop-

ing a plan for routing high-quality voice calls through their corporate network.

These notes are meant to be brief enough that the reader can find what he/she needs quickly, and contain

just enough detail to explain things clearly without overwhelming the reader with non-essential informa-

tion. In particular, it is not the intent of these notes to explain feature administration and operation, except

for aspects that may be overlooked or misunderstood. More general information such as this can be found

in customer documentation (see http://support.avaya.com).

2. Key Message

IGAR is well suited for many, but not all, customer networks. Customers must understand how IGAR

impacts call flow and system performance before implementing IGAR in their corporate telecommunica-

tion network.

3. Definition of Terms

Because CM servers offer several features similar to IGAR, we start by laying out when each of these fea-

tures apply to a customer network. The following table includes a related fourth feature as well: Separation

of Bearer and Signaling. Note that other than being presented as a contrast to IGAR, the three other fea-

tures listed below are outside the scope of this White Paper.

1. In the future this White Paper may be expanded to cover Dial Plan Transparency and Coverage to Remote Voice

Mail, but they remain out of scope for now, other than the feature comparison in Section 3.

FeatureServer

Configuration

Network

StatusPurpose

Additional

Notes

Separation of

Bearer and

Signaling (SBS)

Multiple servers

interconnected by

H.323 and non-IP

trunks

Network is intact

Provides QSIG fea-

ture transparency

through non-QSIG

(e.g., public)

network

Similar in

concept to

DCS+

Inter-Gateway

Alternate

Routing (IGAR)

Single server with

multiple PNs / MGs

Network is intact

but has limited

bandwidth

Provides voice

connectivity via

public trunks when

data network can-

not handle addi-

tional traffic

Table 1: Feature Summary and Comparison




4. IGAR Feature Overview

4.1 Control Flow - Station-to-Station Call

Avaya personnel and customers often want to know the control flow of an IGAR call.

1. User A in Network Region X calls User B in Network Region Y.

2. CM server determines that IGAR must be used to set up the bearer connection from A to B.2

3. User A hears ringback, but User B does *not* begin to ring.

4. CM server determines the direction of the trunk call. This is not under the control of the customer, but

in general, the IGAR trunk call is set up in the same direction, regardless of the direction of the original

station-to-station call.

5. CM server originates a trunk call between the two Network Regions using the administered IGAR

Listed Directory Numbers and standard Automatic Route Selection (ARS), with the following special

cases:

a. The outgoing trunk must be in the same Network Region as the side originating the call (this may

be NR X or NR Y).

b. Likewise, the incoming trunk must be in the same Network Region as the other side.

c. The FRL and Bearer Capability (voice/data) of the endpoint on the side originating the trunk call

(this may be User A or User B) is considered when selecting the preference in the route pattern.

6. The IGAR trunk call is answered immediately; special DTMF signaling (carried in-band over the

trunk) lets the CM server associate the incoming trunk call with the outgoing trunk call and the original

station-to-station call.

7. When the association is complete, CM begins to ring User B.

8. The IGAR trunk stays active as long as the call stays up. The IGAR trunk drops when the call drops.

9. Special Case: If the call is transferred from User B to a user in NR X, so that it is now fully within NR

X, the IGAR trunk is dropped.

Dial Plan

Transparency

(DPT)

Same as IGAR

Network outage has

caused some PNs /

MGs to disconnect

from main CM

server

Lets users keep

dialing between

PNs / MGs without

being aware of

outage

Most sta-

tion fea-

tures are

not avail-

able. Users

are warned

by “SV”

reason code

Coverage to

Remote Voice

Mail

Same as IGAR Same as DPT

Provides coverage

to central voice

mail server

Can be used

together

with DPT

2. See Section 4.5 for events that trigger IGAR.

FeatureServer

Configuration

Network

StatusPurpose

Additional

Notes

Table 1: Feature Summary and Comparison




Figure 1: Possible Flow of an IGAR call

Figure 2: Possible Flow of an IGAR call

4.2 Control Flow: Station-to-Trunk Call

IGAR may be needed on a call from a station to a trunk -- for example, when User A in NR X places an

outgoing call over a trunk in NR Y, and IGAR is required for calls between those two Network Regions. In

Net Rgn X Net Rgn Y

Hartford

Net Rgn Y

New Haven

CM Server

Public Network

Trunk GroupTrunk Group

User A User BDirection of call

Hartford New Haven

A calls B;

A hears ringback

Call appearance on B

reserved; B does not ring

CM server originates

ISDN call from New

HavenTrunk call answered;

DTMF signaling starts

DTMF signaling

succeeds; B rings;

B answers call

ISDN call setup signaling

A hangs upISDN call clearing

Call drops at B




most such cases, the IGAR trunk call from NR X to NR Y is set up in parallel with the trunk call leaving

NR Y. In most cases, this “parallel processing” reduces the user-visible delay on outgoing trunk calls.3

4.3 A Special Case - QSIG / SIP Voice Mail

Calls via a QSIG or SIP trunk to a Voice Mail server are an exception. If User A in NR X calls a Voice Mail

server using a hunt group extension, and the QSIG / SIP trunk dedicated to that server is in NR Y, CM soft-

ware delays originating the QSIG / SIP trunk call to the Voice Mail server until the IGAR trunk between

the Network Regions is active. This is necessary, because the QSIG/ SIP Voice Mail call generally sets up

very quickly. If the two trunk calls were to be set up in parallel, then the caller would often miss the first

few words of the Voice Mail greeting.

4.4 Measurements and Status

Two forms can be used to verify the connection of an active call that uses IGAR for its bearer connection:

1) status trunk shows that the trunk is being used for an IGAR connection.

--------------------------------------------------------------------------------

status trunk 1

TRUNK GROUP STATUS

Member Port Service State Mtce Connected Ports

Busy

0001/001 01A0801 out-of-service-NE no

0001/002 01A0802 out-of-service-NE no

0001/009 01A1101 in-service/active no IGAR 02A1101 S00013 S00002

0001/010 01A1102 in-service/idle no

--------------------------------------------------------------------------------

status trunk 1/9 Page 1 of 5

TRUNK STATUS

Trunk Group/Member: 0001/009 Service State: in-service/active

Port: 01A1101 Maintenance Busy? no

Signaling Group ID: 1 CA-TSC state: not allowed

IGAR Connection? yes

Connected Ports: IGAR 02A1101

S00013 S00002

-------------------------------------------------------------------------------

3. Because this parallel processing can cause a brief loss of talk path at the start of the call in some cases, CM6.0 soft-

ware will let customers force sequential processing. If sequential processing is selected, the CM server will not ini-

tiate the outgoing trunk call until the IGAR trunk connection is active.




2) status station on either station shows that IGAR has been used to set up the bearer connection.

--------------------------------------------------------------------------------

status station 8864000 Page 8 of 9

SRC PORT TO DEST PORT TALKPATH

src port: S00002

S00002:TX:135.105.213.191:3054/g729a/20ms

02A0201:RX:135.11.209.58:2924/g729a/20ms:TX:tdm:a64

02A1101:RX:tdm:a64 TX:IGAR-Trunk

01A1101:RX:IGAR-Trunk TX:tdm:a121

01A0201:RX:tdm:a121:TX:135.11.209.55:2876/g729a/20ms

S00029:RX:135.105.6.166:2048/g729a/20ms

dst port: S00029

--------------------------------------------------------------------------------

The list trace station and list trace trunk commands show whether IGAR has been invoked on a call in

progress:

--------------------------------------------------------------------------------

LIST TRACE

time data

15:34:36 active station 8864000 cid 0xb9

15:34:36 G711MU ss:off ps:20 rn:2/2 135.11.185.143:2798 135.11.209.58:2668

15:34:37 dial 17324314875

15:34:37 ring station 17324314875 cid 0xb9

15:34:37 IGAR starting call app A station 17324314875 cid 0xb9

15:34:37 G711MU ss:off ps:20 rn:1/1 135.11.185.39:3250 135.11.209.55:2808

15:34:37 dial 011498954752121153599999# route:ARS

15:34:37 term trunk-group 1 cid 0xba

15:34:37 dial 011498954752121153599999# route:ARS

15:34:37 route-pattern 12 preference 1 cid 0xba

15:34:37 seize trunk-group 1 member 10 cid 0xba

15:34:37 Calling Number & Name 9089539999 EXT 190895399

15:34:37 dial 011498954752121153599999# route:ARS

15:34:37 route-pattern 12 preference 1 cid 0xba

15:34:37 seize trunk-group 1 member 10 cid 0xba

15:34:37 Proceed trunk-group 1 member 10 cid 0xba

15:34:37 tone-receiver 01A0506 cid 0xba

15:34:37 Alert trunk-group 1 member 10 cid 0xba

15:34:37 active trunk-group 1 member 10 cid 0xba

15:34:37 IGAR active call app A trunks 1/10 & 2/10 cids 0xba & 0xbb

15:35:17 idle station 8864000 cid 0xb9

15:35:17 idle cid 0xba

--------------------------------------------------------------------------------




To get an overall view of how IGAR is being used on a daily basis, IGAR measurements can be viewed in

the rightmost column of the status ip-network-region form:

--------------------------------------------------------------------------------

Inter Network Region Bandwidth Status

Number of # Times

Src Dst Conn Conn BW-limit BW-Used(Kbits) Connections BW-Limit IGAR

Rgn Rgn Type Stat Tx Rx Tx Rx Hit Today Now/Today

2 1 direct pass 2 Calls 0 0 0 0 0 0/ 2

Video: 0 Calls 0 0 0 0 0

Priority: 0 Calls 0 0 0 0 0

--------------------------------------------------------------------------------

All the network regions with IGAR or DPT enabled can be viewed using the list ip-network-region igar-

dpt report:

--------------------------------------------------------------------------------

IP NETWORK REGIONS - IGAR/DPT

LDN Max

Region Name Extension Trks DPT? Location

1 New Jersey (PN 1) 1908-953-9999 10 n 1

2 EMEA (PN 2) 2115-359-9999 10 n 2

--------------------------------------------------------------------------------

4.5 IGAR Triggers

A number of events can trigger a CM server to invoke IGAR.

1. Static CAC: The most commonly used trigger is a new call that exceeds Call Admission Control

(CAC) limits. These limits appear on the IP Network Region form, and are a static representation of

how much traffic the customer expects their data network can carry with reasonable voice quality.

2. Dynamic CAC: The administered CAC value can be changed dynamically by all Avaya H.248 gate-

ways except the G700. This typically happens when the gateway becomes disconnected from the main

CM server. When that occurs, the gateway re-registers with the CM server using a dial-up connection,

and changes the CAC limit to zero, forcing all new calls to use IGAR.

3. Network Measurements: If a customer enables Special Application SA9020, CM uses test packets to

measure the quality of the customer data network. If the thresholds administered on page 1 of the IP

Options form are exceeded, IGAR is triggered. When network quality is restored, IGAR stops being

used for new calls.

4. Forced IGAR: If a customer knows their data network does not have the bandwidth to carry voice calls

between two Network Regions, they can force IGAR to be used on all calls between those NRs. In this

case, there is no “trigger” -- IGAR is used on every call between the two NRs.4

4.6 Delayed Ringing

On a typical inter-region call, the calling and called parties are not aware that IGAR has been triggered.

The calling party hears ringback, and the called party does not ring until the IGAR trunk is active and the

talk path is open and connected. The main impact on users is that a time gap is introduced between Step 3

and Step 7 in Section 4.1 -- that is, from the time the destination call appearance is selected until the time

4. Customers can also use forced IGAR temporarily to verify they have set up IGAR call routing correctly, even if they

plan to use one of the other IGAR triggers just described.




that call appearance begins to ring. During this delay, normal call timers are running -- for example, the

“don’t answer” interval for features such as coverage and call forwarding. This lets the call cover normally

in case the IGAR trunk call cannot be set up for some reason.

It is strongly recommended that customers design their networks to keep this time gap as short as possible.

This can be done in a few ways:

• Use “fast” trunk groups whenever possible. ISDN trunks (PRI or BRI) are good choices. These have

two advantages: The call setup time itself is fast, and the default End-to-End Signaling timers are

short: Tone = 80 msec, Pause = 60 msec.

• If a “slow” (e.g, non-ISDN) trunk group must be used, speed up the DTMF signaling exchange (Step 6

in Section 4.1) by reducing the End-to-End Signaling timers on that trunk group. Note that these

default to much higher values: Tone = 350 msec., Pause = 150 msec.

It is advisable to do this in steps -- reduce the timers a little bit and make test calls. If they work, reduce

the timers again. Repeat until the call setup time is acceptable. If the test calls stop working, increase

the timers until the test calls start working again. The degree to which the timers can be reduced

depends on the Service Provider Network the customer uses to interconnect the Network Regions. It

may not be possible to reduce them down to the 80 / 60 settings that ISDN trunks use by default.

4.7 Impact on System Performance and Capacities

IGAR has a non-trivial impact on system performance and overall Busy Hour Call Capacity, because every

call that triggers IGAR spawns two others, for a total of three calls managed by the controlling CM server:

• The original inter-network-region call

• An outgoing trunk call

• An incoming trunk call

Naturally, the two trunk calls also reduce the number of trunks available for “real” incoming and outgoing

calls. If users in a given Network Region expect to use IGAR frequently, the customer may need to order

more trunks for the gateways in that Network Region from their Public Network Service Provider.

Frequent IGAR invocation must also be factored into the amount of traffic a CM server can handle. In

other words, when determining proper CPU occupancy, the number of calls that are expected to trigger

IGAR should be tripled to account for the outgoing and incoming trunk calls.

4.8 Impact of Call Setup Delay on Station Features

Feature-transparency protocols like QSIG, DCS and even SIP, limit the features a user can invoke to the

very few most popular ones. For example, QSIG, DCS, and SIP all support Automatic Callback between

CM servers, but none of them supports Whisper Page.

By contrast, IGAR offers users the entire set of station features, using trunks “behind the scenes” to set up

a high-quality talk path. However, the delayed ringing described earlier can lead to some undesirable fea-

ture interactions, meaning that some features should be used with care -- or not at all -- on a call that trig-

gers IGAR.

Call Coverage

For example, let’s look at call coverage. By default, a call covers to the first coverage point after 2 rings.

However, if IGAR trunk setup delays are long, the call may go to coverage even before the called party has

a chance to answer the call. The problem in this case can be alleviated by reducing the End-to-End Signal-

ing timers (see Section 4.6), or by increasing the coverage ringing interval5.




Bridging

System designers must also evaluate carefully cases when IGAR is triggered without any “advance warn-

ing” to the CM server. For example, if Joanne in Jacksonville has a bridged appearance of Pierre in Paris,

CM software cannot start to build the IGAR trunk connection until after Pierre bridges onto Joanne’s call.

Thus, a talk path delay in this case cannot be avoided. If this scenario is important for a customer, users

must be trained to expect a delay before they can talk or listen. This caution applies equally to similar fea-

tures such as No Hold Conferencing.

Announcements

A third example is recording an announcement. Within a Network Region, a system administrator can dial

the Announcement Feature Access Code, followed by the appropriate digits, and immediately start to

record an announcement. But if the announcement is stored in a distant Network Region that requires

IGAR, the first few words spoken will be lost because the talk path is not yet ready. Because there is no

signal to the administrator that talk path is now active, it is best to avoid IGAR for features like this.

5. IGAR Configuration Recommendations

5.1 Safe Configurations for IGAR

IGAR is well suited for configurations in which calls between Network Regions are either basic voice

calls, or they involve no features that are adversely affected by delayed ringing or delayed talk path.

5.2 Call Center Configurations -- Caution!

Customers should take great care before implementing IGAR in a Call Center environment. Product Sup-

port Notice PSN002190r2 was issued in late 2008 to describe the risks in doing so. The following text

taken from that PSN summarizes the reasons for this restriction:

...because call centers are by nature high-traffic configurations with fast response time requirements,

they cannot use IGAR as an ... alternative to IP routing of bearer channels, because of delays in setting

up connections and higher risk of calls not being connected. This is a particular concern for routing

ACD calls to auto-answer agents where calls can be lost under the assumption the call has been deliv-

ered.

Specific Call Center features susceptible to failure with IGAR include Service Observing, Announcement

Playback, VDN of Origin Announcements, and Redirect on No Answer (RONA). In addition, agents con-

nected via IGAR will be alerted more slowly than other agents, which means the IGAR-connected agents

may not be able to perform at the same level with their colleagues who do not need an IGAR connection.

This White Paper gives the reader the background to understand the reasons behind this restriction. Avaya

is aware of a few Call Center implementations that use IGAR in countries such as Germany, where ISDN

trunks are reliable, relatively inexpensive, and set up calls quickly. This keeps the delays introduced by

IGAR small enough that these Call Centers can still function at the performance level expected by the cus-

tomer. Such Call Centers are taking advantage of an especially good service-provider network, so the

reader should not infer that IGAR is equally suitable for use by a Call Center in countries or regions where

the network performance may be less robust.

5. This can be done system-wide by increasing the number of rings for the Subsequent Redirection Intervals (Call Cov-

erage/Call Forwarding System Parameters), or for individual coverage points (Coverage Path).




6. Feature Interactions and Limitations

6.1 Feedback to Calling / Called Party

As explained in Section 4.1 on page 3, the calling party is normally unaware that IGAR has been triggered.

Not only that, but he/she is also generally not notified if the CM server is unable to set up the IGAR trunk

call. This is because we want the call to follow the normal steps for the case the called party is not avail-

able, most likely routing to the called party’s first coverage point. If all the coverage points also cannot be

reached, the caller simply continues to hear ringback until he/she hangs up.

One exception is the case where IGAR is required to connect a calling party in one Network Region (NR)

to an outgoing trunk in another NR. In this case, the caller hears reorder tone if the IGAR trunk call fails.

Denial Events are logged if an IGAR trunk call cannot be set up. Therefore, it is a good idea to check the

Denial Event log or run “list trace” on a failing IGAR call to determine the reason for the failure. Incorrect

call routing is a common cause of failure. Alternatively, the system may have reached the maximum num-

ber of IGAR trunks assigned to one of the Network Regions involved in the call.

6.2 IGAR Trunk Call Routing

IGAR calls have the following routing limitations:

• DTMF Tones: Because the IGAR trunk call requires an exchange of DTMF tones, customers must be

sure that the trunks the plan to use for IGAR can transmit these tones reliably and clearly. This is a crit-

ical prerequisite for successful deployment of IGAR. Adjusting the end-to-end signaling parameters on

the appropriate trunks may be necessary -- see Section 4.6 on page 7 for details.

• Direction: The direction of the IGAR trunk call cannot be controlled by the customer. For instances,

on calls between Joanne in Jacksonville and Pierre in Paris, the trunk call may generally be set up

always from Paris to Jacksonville, no matter whether Joanne calls Pierre or vice versa.6

• ARS Only: As noted in Step 5 in Section 4.1, ARS is always used to route the IGAR call. The cus-

tomer cannot use Automatic Alternate Routing (AAR) or Uniform Dial Plan (UDP)7, or skip ARS pro-

cessing and designate a particular trunk group (e.g., using a Trunk Access Code).

• Multiple Locations: ARS Routing must be set up so that calls to the same IGAR Listed Directory

Number (LDN) use different trunk groups, depending on the Network Region from which they origi-

nate. For example, if a CM server has a gateway in New York, Chicago, and Los Angeles, an IGAR

trunk call to Chicago must select a New York trunk if the call comes from New York. One way to do

this is to use the Multiple Locations feature. Details are available in customer documentation.

• Facility Restriction Level (FRL): The FRL of the calling party is taken into account when selecting

the outgoing route pattern preference. This lets the customer partition users into those that can use

IGAR and those that cannot. This can lead to a scenario where a low-privilege user can call a user in

another Network Region most of the time, but if IGAR is triggered, the call does not go through.8

• IP Trunks: IP trunks are skipped when selecting an outgoing trunk. This means IGAR calls cannot be

routed via the public network over a SIP, H.323, or SBS trunk group.9

6. CM generally selects the lower-numbered trunk group for IGAR. Therefore, if a customer strongly prefers that IGAR

trunk calls be set up in a particular direction, the customer can assign the desired public-network trunk group a lower

number than the trunk group belonging to the other Network Region.

7. The customer can use ARS Digit Conversion to “hop” from ARS to AAR or UDP.

8. The Dial Plan Transparency feature, which shares many administration fields with IGAR, lets customers ignore the

FRL and let the calls go through.

9. CM6.0 introduces a new system parameter that lets IP trunks be selected for use by IGAR. Details on this capability

will be added to this paper after the feature is generally available.




6.3 Call Charges and Call Detail Recording (CDR)

A trunk call used for IGAR is always answered, even if the called party is not available and does not

answer the call. This must be considered when setting up IGAR in regions where outgoing calls, particu-

larly international calls, are expensive.

The CDR record for an IGAR trunk call does not report the extension of the two endpoints involved in the

call that triggered IGAR. Instead, the IGAR Listed Directory Numbers (LDNs) associated with the calling

and called Network Region appear as the calling and called parties.

6.4 Call Transfer

If a call involving IGAR trunks is transferred among different Network Regions, CM software optimizes

the connections among the parties on the call to reduce the number of IGAR trunks required.

6.5 Limit on Trunk Call Setup Time

Once the IGAR trunk call is routed and launched, the far end must answer and begin DTMF signaling

(Step 6 in Section 4.1) within 10 seconds. If not, the called party is never rung. This can happen if the cus-

tomer routes some calls over very slow public-network connections.

6.6 Usage of Non-DID Trunks for IGAR

Customers with very small branches may have just a few non-DID Central Office (CO) trunks at those

branches. Non-DID trunks must be programmed with a destination extension at which all incoming calls

will ring. Normally that extension belongs to an attendant, auto-attendant, or a designated station.

IGAR works well with these trunks for outgoing calls from the small branch (see Section 4.6 on page 7 on

how to reduce delays). However, for IGAR to work on incoming calls into these branches the customer

probably must purchase additional trunks.

These extra trunks are required because incoming IGAR calls must be routed to the IGAR LDN for the

local Network Region, in order for the IGAR processing described in Section 4.1 on page 3 to take place.

Therefore, the customer must have two loop-start CO trunk groups:

• The existing CO trunk group can continue to handle normal incoming and outgoing calls, as well as

outgoing IGAR calls. Incoming calls on this trunk group ring the designated attendant, auto-attendant,

or station.

• A new CO trunk group must be created to handle incoming IGAR calls and must route these calls to

the IGAR LDN for the appropriate Network Region. This trunk group can be used for non-IGAR out-

going calls, but cannot handle normal incoming calls to the branch. A normal voice call arriving on

this trunk group will be treated as an IGAR call, DTMF signaling will fail, and the call will drop.

6.7 Encryption

A call that is encrypted when traveling through the customer’s LAN or WAN may be routed over a non-

encrypted public-network trunk if IGAR is triggered. Customers concerned about encryption should prob-

ably assign high-security users to a special network region that never triggers IGAR, or that routes IGAR

calls over secure private trunks.




©2010 Avaya Inc. All Rights Reserved

Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by ® and ™ are

registered trademarks or trademarks, respectively, of Avaya, Inc. All other trademarks are the property of

their respective owners. The information provided in this White Paper is subject to change without notice.

The technical data provided in this White Paper are believed to be accurate and dependable, but are

presented without express or implied warranty. Users are responsible for their application of any products

specified in this White Paper.

Date post:	02-Oct-2014
Category:	Documents
Upload:	kool2k9
View:	60 times
Download:	0 times

igar

Documents