Gatekeeper shutdown

Sebastien,

Vivek is correct that calls already setup will continue if the gatekeeper comes down. In its strictest sense this applies to gatekeepers which allow either direct call signalling (everything but the RAS signalling goes directly between the 2 clients)
and gatekeeper routed signalling (where everything goes via the gatekeeper).

The reason for this is that once the call is setup between 2 IP phones the H.225.0 signalling channel is not required (supplementary services aside).

However there are some configurations in which a gatekeeper failure will cause calls in progress to fail. The ones that I can think of are below. Please also remember that the scenarios I give below may or may not cause calls in progress to fail it will usually depend upon the way that the gatekeeper or client or gateway has been programmed to act in this situation. Some of the gatekeepers that I have worked on will clear a call in progress in 1 or more of the scenarios below while others will allow the call to continue:

1)calls between a PSTN to H.323 gateway and an H.323 IP phone when gatekeeper routed signalling is being used. The H.323/H.225.0 recommendations say that when a gateway is involved the H.225.0 call signalling/Q.931 channel must remain open (when the call is only between H.323 IP phones it can be left open or closed it is an implementation decision). Some implemenations when detecting that the H.225.0 channel is down and that a gateway is involved will clear the call.

2) some gatekeepers which allow/force gatekeeper routed call signalling also allow for the routing of the H.245 logical channel 0 to be gatekeeper routed.
A gatekeeper failure in this scenario may very well cause a call in progress to fail.

Also whether the gatekeeper allows/forces direct signalling or gatekeeper routed signalling the
endpoints will usually have to re-register after a certain period of time specified by the TTL in the original exchange of registration messages. If the TTL expires and
a client cannot get a response from the gatekeeper to re-register then they will not be able to make any more calls. Even if pre-registered ARQ was in use most H.323 clients use the gatekeeper for directory services i.e. phone number to IP address lookup.

There are ways to use a secondary gatekeeper if the first gatekeeper
failed. This can be done by having the client configured with the secondary gatekeeper IP address or
by the gatekeeper specifying an alternate gatekeeper IP address to use if required in the registration and/or admission messages.

regards

Tony

Hi Chris,

I’m not involved with the OpenH323 project. My knowledge of the OpenH323 project is only with the use of the OpenPhone H.323 client. Which I’ve used to evaluate and test gatekeepers from several different manufacturers. I found that it provides far greater flexibility in terms of configuration than Netmeeting.

With regards to your question about does having a gatekeeper manage H.323 messages better than allowing clients to talk directly its not really that a gatekeeper manages H.323 messages better its more to do with services and phone number to IP address lookup.

One of the primary purposes of a gatekeeper is to provide the IP address of the party to be called so that the calling party knows where to send the call signalling (if gatekeeper routed signalling is being used the gatekeeper will return its own address as the destination). If we take a simple example of 1 gatekeeper and 2 phones:

phone 1 has an IP address of 205.5.5.5 and registers with an E.164 alias (telephone number) of 2000.

phone 2 has an IP address of 205.5.5.6 and registers with an E.164 alias of 2001.

When phone 1 wants to call phone 2 its asks the gatekeeper where it can find phone 2. The gatekeeper tells it to send the signalling to IP address 205.5.5.6. Now for only 2 phones it would be easier (and cheaper) to simply use an IP address. However this becomes much more difficult if there are 50 or 100 phones or if DHCP is used and the IP address of clients changes regularly. Hence a gatekeeper.

Also if the gatekeeper can stay in the middle of the call signalling (known as gatekeeper routed call signalling GKRCS) rather than just returning the IP address related to a telephone number (known as direct call signalling were clients signal between themselves once the IP address of the destination is known) then it can be configured to examine certain parameters and fields and provide features and services to clients (and/or gateways in the case of PSTN interworking).

It is possible to implement many of these features (such as call forwarding) using the H.450.x recomendations and does not require that the gatekeeper stay in line with the signalling. However this requires that the clients support the H.450.x recommendation (s). Also many features/services which may be required are not specified in an H.450 recommendation.

Please bear in mind that due to the extra processing required to handle gatekeeper routed call signalling (GKRCS) a gatekeeper performing GKRCS will not scale to handle the same number of clients as a gatekeeper doing direct call signalling.

regards

Tony

Hi Chris,

with regards to whether GKRCS is used or direct signalling it could be either. I’ve never configured
the OpenGK before but other gatekeepers will often have the ability to be configured for either. If required a gatekeeper manufacturer could program their gatekeeper to be configured to allow GKRCS for some type of call and direct signalling for others.
This could be decided based upon a number of criteria such as called number, calling number, etc.

If you have a LAN sniffer capable of decoding H.323 then you will be able to see if the gatekeeper is
doing GKRCS or direct.

With regards to the Avirt GK which you are using and routed call support for the OpenGK I’d take a
guess that both are refering/using
the LRQ (location request) method.

Lets say that you have an H.323 PABX which handles all numbers in the 2xxx range. The next site has an H.323 PABX which handles numbers in the 3xxx range. If a user on the 2xxx PABX dials 3333 then its own H.323 PABX will send an LRQ message to the 3xxx H.323 PABX requesting the IP address of user with alias 3333. Hopefully the
3xxx H.323 PABX will then return the IP address of 3333 to the user on 2xxx wishing to call 3333. The IP address should be returned in a
LCF (location confirm message).

Each H.323 PABX/gatekeeper needs to be configured with the IP address of every other GK covering
a number range that it may want to reach.

The same principal applies to GK’s on the internet or which are on a LAN and can be configured to reach GK’s on the internet.

Some gatekeeper manufacturers use other methods such as having their
gatekeepers which all cover different zones talk to a central database using either a proprietary method or something like LDAP. However if these gatekeepers want to communicate to other GK’s from different manufacturers they will have to use the LRQ method.

I’m not aware of any other Opensource GK’s for WIN32.

regards

Tony

Hi hi tech,
It looks like some have great experince in this feild.
I am looking to implement a VoIP, GK solution based on a 2610 CISCO IOS/H323 gatekeeper and other Radius. Anyone had such experience?
Should that be a reliable solution?
Thanks

Hi Sajjad,

have you tried to make calls to your gateway yet using an IP phone
or PC softphone such as Netmeeting or OpenPhone? If so and the calls
are failing do you have any call
traces or did you receive any clear
codes?

What is your current setup? ie is
the gateway connected to a hub or
switch or do you have it connected
to the internet/a private IP network?

I’ll assume for now that the gateway is connected via Ethernet to a hub/switch. Using an IP phone
or PC using a softphone such as Netmeeting connect the IP phone
or PC to the hub. Give the PC or
IP phone an IP address in the same range as the gateway and give it the same subnet mask.

e.g if the gateway has an IP address of 10.5.5.5 give the PC/IP
phone an IP address of 10.5.5.6

Next have the IP phone or PC call
the gateway using the gateways IP
address as the destination.

If the gateway is set up to accept
calls without a gatekeeper and other gateway call setup paramaters
are correct then this should work.

As with most thing “should work”
does not mean it will. Try the above and lets see what happens.

regards

Tony

Wilson Boyrie:

No its not.

Sajjad,

this could be a number of things ranging from an incompatability problem between Netmeeting and the gateway to firewall problems to gateway configuration problems.

Some questions:

1) Who is the manufacturer of the gateway?

2) Are you sure that the gateway is configured correctly? For example is the gateway setup to route the number that you are calling?

3) In advanced calling on Netmeeting did you enter the gateway IP address in the gatekeeper section at the top or in the gateway section at the bottom?

4) Do you have a network sniffer capable of decoding H.323?

5) You say that the gateway is on the internet with a fixed IP address. Is it possible for the purpose of tests to connect the gateway to a hub with the PC running Netmeeting also connected to the same hub?

regards

Tony