Hi everyone:
Mr. Olivier HERSENT is absolutely right. The roaming has been one of the important things that has been considered to build the generalized UNIVERSAL model that AT&T proposal foresees (although the proposal does not mention specifically for implementation in roaming environment). There are many other aspects such as BW/QOS, dynamic routing schemes, inter-GK management, and topology optimization have also been considered.
I completely agree that there can be many ways how this model porposed by AT&T can be used once the basic "inter-zone" communications model that allows all H.323 signaling messages over every zone between the source-destination GK is established.
The MOST important thing is that we, in ITU-T SG16, should build the H.323 inter-GK signaling scheme as UNIVERSAL as far as practicable because one can use those power of signaling schemes in so many ways to build the SERVICES that can almost be limitless.
Thanks and regards,
Radhika R. Roy AT&T, USA Tel: + 1 732 949 8657 Email: rrroy@att.com
From: HERSENT Olivier CNET/DSE/CAE[SMTP:olivier.hersent@CNET.FRANCETELECOM.FR] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Thursday, August 20, 1998 10:53 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Comments on AT&T proposal
Hi everyone,
Some time ago, we had some brainstorming on roaming with H.323. One of the simplest ways to do it was that the roaming terminal would send the ARQ, ... to the visited network GK (discovered my broadcast/multicast). This GK would recognize from the calling party alias that the terminal si from an external administation having an agreement with the visited administration. It would then forward the xRQs to the home gatekeeper of the terminal and get the xCFs in reply.
This has many benefits :
- The home GK knows where is the roaming teminal and can forward calls.
- Any policy implemented at the home gatekeeper (restricted phone usage,
etc ...) is still enforced in any visited domain
- It is simple
So roaming might be a good reason to forward xRQs ... just my FF.02.
Best regards, Olivier HERSENT-- France Telecom CNET IP Telephony Technical Proj. Manager - TULIP
De : Roy, Radhika R, ALTEC[SMTP:rrroy@ATT.COM] Répondre à : Mailing list for parties associated with ITU-T Study Group 16 Date : Wednesday, August 19, 1998 6:09 PM A : ITU-SG16@MAILBAG.INTEL.COM Objet : Re: Comments on AT&T proposal
2. We do not see how the following messages can be passed fromone
GK to another: GRQ/GCF/GRJ, RRQ/RCF/RRJ, ARQ/ACF/ARJ, BRQ/BCF/BRJ. We do not see in the present H.323 model how or what benefit is there to gain by passing these messages. May be you can show us a scenario where this is utilized. In the current H.323 model, an endpoint only talks
RAS
with the GK it is registered with. For example: * Endpoint A which is registered to GK1, sends an ARQ to GK1 to call B * If GK1 can not resolve B's address, it shall send LRQ, and not pass on the ARQ to the next GK. [Radhika: The proposed model is so flexible that a zone boundary can be physical or logical. This distributive model does not restrict that a H.323 entity has to register to a GK which has "geographical" or "physical" proximity. That is, the model is so
flexible
that the zones can also be logical instead of maintaining a boundary constrained by the physical proximity. If we consider that the ARQ
message
is sent by a H.323 entity to the GK. The first GK that receives the ARQ message may not have the authority to respond because the H.323 entity
may
not be registered with this one. So, the ARQ message has to be passed to the next GK. (If the first receiving GK has the authority [i.e., the H.323 entity is registered with this GK] to respond, then the ARQ message need not to be passed anymore.) The GK that has the authority will respond to the ARQ message. Therefore, the GK that will respond to the ARQ message will
also
be the serving GK. Now the serving GK may be the first GK, or the serving
GK
may reside to a place where multiple transit GKs may be along the path between the calling and the serving GK. Moreover, the most important
point
is that the ARQ message needs also to confirm the "bandwidth". In a multiple GK environment, the source-destination path may cover multiple zones,
and
each zone will have its own GK. Therefore, the serving GK has to work cooperatively with all other GKs to confirm the fact that the bandwidth
in
all zones along the source-destination is good enough to accept the call before sending the ACF message (also see Section 3.5 of the proposed contribution). It shows clearly the power of the distributive GK model proposed in the contribution in solving the complex problems in the context of large-scale network. Similarly, all other messages can also be explained why these messages need to be passed from one GK to another.]