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@madge.com
participants (1)
-
Chris Purvis WVdevmt-WS