Context: The implementer's guide (revision D), section 6.2.19 states: "If this information is supplied, an endpoint should retransmit the request to one of 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

Jean-François, 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 a DRQ. 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 message. I hope that clarifies things. Best Regards, Paul E. Jones ----- Original Message ----- From: Jean-Francois Mule <jfmule@clarent.com> To: <ITU-SG16@MAILBAG.INTEL.COM> Sent: Wednesday, July 14, 1999 1:51 AM Subject: Use of Alternate Gatekeepers & Implementers Guide the

request (ARQ) before it has registered successfully with one of the alternate gatekeepers. This comment is also valid for URJ, BRJ, LRJ, DRJ, INAK 3. In the case of a DRJ message (endpoint is being dropped, sends DRQ, gets 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 -------------------------------------------------------- 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@clarent.com http://www.clarent.com