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 from oneGK 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.]