Comments on AT&T proposal

HERSENT Olivier CNET/DSE/CAE olivier.hersent at CNET.FRANCETELECOM.FR
Thu Aug 20 11:53:41 EDT 1998


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 at 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 at MAILBAG.INTEL.COM
> Objet :       Re: Comments on AT&T proposal
>
>         2. We do not see how the following messages can be passed from one
> 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.]
>
>



More information about the sg16-avd mailing list