Annex G

Chris Purvis WVdevmt-WS cpurvis at MADGE.COM
Tue Sep 8 04:50:59 EDT 1998


Radhika,

>The "abstraction of routing" between the GKs is an option. Whether the
>"abstraction of this routing option" to be used through a chain of zones
or
>not is left up to the implementation schemes.

>If one does not feel the advantage of this option, then one may not use
it.

>I hope that this will clarify the things.

In that case I for one don't understand your proposal (nh_gkx2.doc).  As
I understood it, it works like this:
A source endpoint sends an ARQ to its gatekeeper (GKA) to try to make a
call.  GKA sends LRQs to various "friends" (GKB1, GKB2, GKB3, say), which
do the same in turn until they find the destination alias (which is for
instance known by GKD111, discovered via GKB1 and GKC11).  Now GKA needs
to send an ARQ somewhere (if I understand your scheme correctly).  The
only place it knows that it can send an ARQ to is GKB1, as the address
returned in the LCF is a call signalling address rather than a RAS
address, and may refer to the destination endpoint itself.  Hence the ARQ
must, as I understand your scheme, be routed via GKB1, GKC11 and GKD111
and not direct from GKA to GKD111.  Yet you say the "chain of zones" is
an option.  Therefore I misunderstand your proposal.

>PS When we see references in H.323 that a message is to be sent from one
GK
>to another GK, it implies that the message has to be "routed" from one
GK to
>another. (In another scenario, when in H.323 it is assumed that messages
are
>to be sent between the GKs via "multicasting", it is also a kind of
>"routing" through a tree architecture that has a "chain of branches"
where
>GKs are located.)
You appear to confuse IP (or equivalent) routing with routing messages
via a number of H.323 entities.  In order to route messages via a number
of H.323 entities (as you suggest) the IP routing phase needs to be done
multiple times.  Worse, the message needs to be processed multiple times
on its travels, whereas if we leave IP to do a job it is good at the
message only needs to be processed at relevant places.

Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
Phone:+44 1753 661359  email: cpurvis at madge.com



More information about the sg16-avd mailing list