alternateGk mechanism?

Paul E. Jones paulej at PACKETIZER.COM
Sat Jul 29 22:01:44 EDT 2000


Johan,

The procedures for using the Alternate Gatekeeper fields are fully defined
in the H.323v4 document and are applicable to H.323v2 systems.

You can get a copy of the most recent draft copy here:
ftp://standard.pictel.com/avc-site/0008_Por/APC-1874.zip

Best Regards,
Paul

----- Original Message -----
From: "Johan Gerhardsson (ETX)" <Johan.Gerhardsson at ETX.ERICSSON.SE>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Thursday, July 27, 2000 11:46 AM
Subject: alternateGk mechanism?


> Hello all,
>
> my name is Johan Gerhardsson and I was wondering if any one could help me
with a couple of questions regarding the of the alternateGk machanism
(h.323v2).
>
> How is it possible to make an endpoint (gw) gracefully switch over
registration and new calls to another gk without loosing existing calls on
the current GK? I.e. how can the Gk tell the gw that it should send its
SETUP messages (and keep alive RRQ) to another Gk?
>
> I see two possible ways that is almost working:
>
> 1)  ARQ/ARJ with altGkInfo:
> What if one wants to use pregranted ARQ?
> Is the registration (keep alive RRQ) also applied?
>
> 2) keep alive RRQ/RRJ with altGkInfo:
> What happens with existing calls on the GW if the registration is rejected
by GK?
>
>
> My scenario is this:
> Two GK's (Gk1 and Gk2, h323v2) is together working in a load sharing mode.
Registration data are duplicated. Calls are not duplicated. The two GK knows
that the endpoint Gw shall have Gk1 as primary GK.
>
> 1. Gw: RRQ -> Gk1
> 2. Gk1: RCF (alternateGk=[Gk2's rasaddress,<gkid>,needToRegister =
FALSE,prio=1], pregranted=yes) -> Gw
> 3. Gw sends keep alive RRQ to Gk1.
> 4. Gw sends SETUP messages to Gk1 and calls are now ongoing (gkrouted)
through Gk1.
> 5. Gk1 goes down (calls are cleared by the Gw).
> 6. Gw detects that Gk1 has gone down.
> 7. New call: Gw sends ARQ to Gk2 to get Gk2's call signaling address which
is saved for further use.
> 8. Gw routes new calls through Gk2 (no ARQ is used since pregranted is
used).
> 9. Gw sends keep alive RRQ to Gk2.
> 10. Gk2: RCF (alternateGk=[Gk2's rasaddress,<gkid>,needToRegister =
FALSE,prio=0]) -> Gw
> 11. Gk1 comes up again.
> 12. Gk2 detects that Gk1 is up again and wants to tell the Gw that it
shall go back to "normal operation" (step 3-4) as this is the wanted
scenario with this load shared network setup.
>
> Questions:
>
> 1) If pregranted was not in use, the Gk2 could use the alternateGk
mechanism with ARQ by sending ARJ with altGkInfo = altGkIsPermenent = TRUE,
alternateGk=[Gk1,<gkid>,needToRegister=FALSE,prio=0],[Gk2,<gkid>,needToRegis
ter=FALSE,prio=1], but the ARQ is only valid for new calls, not calls AND
registration (or?).
> In the case above, pregranted is wanted to reduce SETUP time, so what
shall the Gk2 do?
>
> 2) In step 9. the Gw has begun to send keep alive RRQ to Gk2. How shall
Gk2 tell the Gw to send keep alive RRQ to Gk1 when it is up and running
again? (By using RRJ and altGkInfo you might think, but how is the GW
handling the active calls that is routed through Gk2? Is it safe to make the
assumption that the Gw will not clear these calls?)
>
>
> Thanks in advance for your comments.
>
> Johan Gerhardsson
> Software developer
> Ericsson Telecom AB
> Data Backbone & Optical Networks, IP telephony
>
> Phone:  +46 (0)8 719 2396
> email: Johan.Gerhardsson at ericsson.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list