Use of Alternate Gatekeepers & Implementers Guide
Paul E. Jones
paul.jones at ties.itu.int
Wed Jul 14 19:27:48 EDT 1999
I made the editorial correction to the Implementers Guide. Thanks for
pointing that out.
Let me give a little history on that change. In H.225.0v2 in the section on
GCF and RCF, it says:
alternateGatekeeper - Sequence of prioritized alternatives for
gatekeeperIdentifer and rasAddress. The client should use these alternatives
in the future should a request to the gatekeeper not respond or return a
reject without redirect.
This issue, here, is that an endpoint could send an ARQ to its gatekeeper
and the gatekeeper could send an ARJ to indicate that the call should not be
allowed. However, according to the text shown above, an endpoint should
then use an alternative since the gatekeeper did not redirect the endpoint.
That is not desirable. If the gatekeeper issues an ARJ, the endpoint should
accept the ARJ. Therefore, we agreed to remove the text "or return a reject
without a redirect". That change does not appear in the implementers guide,
either, but has been corrected-- it will appear in the next version.
In addition, the text you show was also added to clarify how an endpoint
should behave. The full text appears as:
altGKInfo - optional information about alternative gatekeepers. If this
information is supplied, an endpoint should retransmit the request to one of
the alternate gatekeepers listed. If an alternate gatekeeper rejects the
request, the endpoint shall accept the rejection. If an alternate
gatekeeper does not respond, the endpoint may send the request to another
alternate in the list.
The intent, again, is to indicate that if a gatekeeper becomes unresponsive,
an endpoint should send the request to an alternate. If it responds or if
the alternate responds, the endpoint should observe that response--
including rejections from alternates.
The specific question you raise has to do with whether the endpoint must
first register with the gatekeeper or not. That depends on whether the
gatekeeper told the endpoint is must register with the alternate. If the
endpoint is not required to register, it simply send the request. However,
if the endpoint must register, it must send an RRQ to the gatekeeper and get
the RCF before sending the request it originally wanted to send-- including
I agree that that is an odd procedure and I made an attempt to change how
that worked at the last SG16 meeting, but I was met with some opposition.
There were good arguments for why it should work the way it does. Suppose
you use a gatekeeper that does not do call routing. If the gatekeeper stops
responding, the call can continue. Once the call is complete and the
endpoint discovers that the gatekeeper has stopped responding, it can then
register with the alternate. Being an alternate, the alternate gatekeeper
would know to query the endpoint, via an IRQ, or it may already have call
information in a common database, so that it could honor the endpoint's DRQ
I hope that clarifies things.
Paul E. Jones
----- Original Message -----
From: Jean-Francois Mule <jfmule at clarent.com>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: Wednesday, July 14, 1999 1:51 AM
Subject: Use of Alternate Gatekeepers & Implementers Guide
> The implementer's guide (revision D), section 6.2.19 states: "If this
> information is supplied, an endpoint should retransmit the request to one
> the alternate gatekeepers listed". It is also specified that this
> correction should be applied to 7.8.3 (GRJ), 7.9.3 (RRJ), 7.10.3 (URJ),
> 7.11.3 (ARJ), 7.12.3(BRJ), 7.13.3(LRJ), 7.14.3 (DRJ), and 7.15.3 (IACK).
> Editorial comments:
> 0. IACK does not include altGKInfo ==> 7.15.3 (IACK) should be replaced by
> 7.15.4 (INAK) which contains altGKInfo
> Request for comments:
> 1. The correction is understandable for GRJ, RRJ
> 2. In the case of altGKInfo received in ARJ for example, some additional
> clarification would be welcome. Indeed, the endpoint cannot retransmit
> request (ARQ) before it has registered successfully with one of the
> alternate gatekeepers. This comment is also valid for URJ, BRJ, LRJ, DRJ,
> 3. In the case of a DRJ message (endpoint is being dropped, sends DRQ,
> back DRJ with altGKInfo), should the endpoint register with one of the
> alternate gatekeepers to send a DRQ message right away?
> 4. In the case of a gateway endpoint with multiple ports, how should these
> messages be handled when calls are active?
> Thank you in advance for any comments, regards
> Jean-François Mulé
> Standards & Architecture Group
> Clarent Corporation Tel: +1 650 481-2835
> 700 Chesapeake Drive Fax: +1 650 817-3950
> Redwood City, CA 94063 jfmule at clarent.com
More information about the sg16-avd