Avaya AGL “Alternate Gatekeeper List”

Learn how Avaya AGL helps H.323 Endpoints obtain its registration.

In this post Avaya AGL “Alternate Gatekeeper List” see how Communication Manager uses its algorithm to push the Alternate Gatekeeper List or AGL to those H.323 endpoints requesting registration.

Learn best practices when configuring them and gotchas to look for if there is a misconfigured registration server or a network outage somewhere in the VoIP topology.

A customer reached out requesting assistance with various problems where the H.323 Endpoints were registering to DR location, others were stuck registering and the majority took too long to complete.

The Avaya Alternate Gatekeeper List or AGL helps us understand which Gatekeepers are offered to the H.323 Endpoints and how these phones end up obtaining their respective registration or Gatekeeper addresses.

Here are the 4 things you need to know:

1. Why AGL
2. HowTo AGL
3. AGL Assignment
4. Extracting the AGL Information

Why AGL

The Avaya Alternate Gatekeeper List allows IP H.323 phones to register to different registration servers based on location, helping each endpoint to fallback to a different server if the active registration server fails.

It also helps optimize network traffic by reducing the ARP requests and registration flow per network segment. This is true for local or WAN traffic.

HowTo AGL

AGL was introduced back on CM 5.1 using up to *16 Gatekeepers to provide registration with a combo of PEs and CLANs.

The AGL is sent to the phones following the IP-Network-Map and IP-Network-Region configurations.

AGL Assignment

Following the DHCP and DHCP Scope Option 242 the phone gets assigned to a IP-Network-Map which then sends it to the associated IP-Network-Region that allows the AGL to be pushed to the IP Phone requesting registration. Source Region, and Direct vs Indirect Connected IP-Network-Regions

AGL will always refer to the source region first when assigning a Gatekeeper, if that fails it will move to look for any Direct-Connected IP-Network-Regions (IPNRs) , and finally it looks to those Indirect-Connected-Regions if anything else fails.

If there are two or more Gatekeepers in the same IPNR, CM uses its algorithm to associate either a PE or CLAN acting as a gatekeeper to provider registration. The system uses load balancing techniques based on CLAN priority, and available sockets.

If the system finds that all of the 480 sockets are busied or out of service it moves to the Directly Connected Regions starting with Region 1.

All of this follows the Time to Service or TTS part of the IP Phones introduced back on SW 1.2.1 with CM 4.0. 

TTS reduces the time for IP Phones to recover after long network outages and it also improves the time for the IP Phone to come into service in case where the system has a large number of IP Endpoints trying to register which happens upon a CM reset system 2 or higher.

Extracting the AGL Information

There is a misconception that we have thinking that the DHCP Scope Option 242 is followed if the first Gatekeeper entry fails the phone will try to register to to the second configured Gatekeeper under the MCIPADD configuration.

Once the phone gets the Gatekeeper list from CM it forgets whatever it initially learned from the 242 Scope option. That being said you can extract the AGL from a packet sniff or a mib-snmp-walk.

Here is a sample of “Registration Confirm” message sent from PROCR to an Endpoint requesting registration. The AGL is sent to this phone with 3 Entries (CLANs)

* The amount of  AGL Entries supported will be different depending on the CM Version.

Other references can be found:

Administrable Alternate Gatekeeper List for IP phones