Roy, Radhika R, ALTEC
rrroy at ATT.COM
Tue Sep 8 14:52:05 EDT 1998
I guess that you have received my earlier email addressed to you via ITU-T
SG16 mailing list.
As I mentioned before, AT&T's contribution deals with RAS signaling messages
only. The proposal does separates RAS signaling in one stage, and call
signaling in another stage. (In this respect, you are confused in
understanding the AT&T's contribution. I guess that the above answer will
clarify the situation. If still you have questions, please let me know.)
Based on this clarification, you can now create the RAS or call signaling
scenarios as appropriate.
We are taking about the communications between the GKs in multiple GK
environment. So, the communication is occurring at the GK level, and is
above the so-called network level (e.g., IP, ATM, or FR) level. If a GK
decides which one is the next GK it needs to choose for sending a message,
it constitutes a kind of routing at the GK level. As I mentioned before,
H.323v2 does envision to transfer messages between the GKs, but H.323v2 does
not have the means to abstract that notion of routing at the GK level. The
communications between multiple GKs mean communications between multiple
zones (or can also be said communications between "chain of zones").
Each GK will have a complete knowledge of its own zone. Each GK will have
its address table, and the knowledge of the addresses can be obtained
through exchanges of zone/LRQ messages. Each GK will have its ability how to
route RAS message between the GKs knowing the destination addresses. So, the
notion for communicating between the zones knowing the destination address
is known (not a discovery in a random fashion as mentioned by you).
In the case of multicasting between the GKs, the assumption is that it is
again happening at the GK level. The notion is that the same message has to
be "routed" to all GKs. The notion of "routing" between the GKs is still
there although the network level multicasting can be used for implementation
to route the message to each GK (as in your case you have chosen IP network.
Please also note that a H.323 network can also be LAN, IP, ATM, FR, and/or
others - in any combination).
I hope that the above explanation will clarify the things.
> From: Chris Purvis WVdevmt-WS[SMTP:cpurvis at MADGE.COM]
> Reply To: Mailing list for parties associated with ITU-T Study Group
> Sent: Tuesday, September 08, 1998 4:50 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Annex G
> >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
> >not is left up to the implementation schemes.
> >If one does not feel the advantage of this option, then one may not use
> >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
> >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
> >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"
> >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.
> 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