Should we Break H.323 Model for Mobility?

[Stephen Terrill]

Hi Rardhika,

I agree that we need to register with the gatekeeper, however I extend that to say, the gatekeeper could be at home.

I think that we need to clarify the roles of the HLF, VLF, GKs etc before we can move further forward.

Regards,

..//steve

"Roy, Radhika R, ALARC" wrote:

> Hi, Steve:
>
> Your statement appears that you are agreeing with the registration with the
> GK that is the basic foundation of H.323. (However, your contribution does
> NOT clearly indicate this.) It is a very good news.
>
> Contributions are there what roles to be performed by the VLF, HLF, and
> home/visiting/visited/target GK/zone/domain. We like to see where you differ
> and why, and your suggestions.
>
> Please also see my subsequent emails what we need to be done to extend our
> model to be consistent with H.323 as well as how we can reconcile all
> contributions: AT&T, Alcatel, and Ericsson.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill at ericsson.com]
> Sent: Sunday, April 16, 2000 5:00 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Should we Break H.323 Model for Mobility?
>
> Hi Roy,
>
> I feel that this email places more assumptions into the role of the VLF,
> HLF, visited GK, and home GK than we have agreed upon.  Certainly the model
> that we have proposed hasn´t  stopped registration with the gatekeeper.
>
> I think that we need to agree upon the roles of the particular entities
> befor embarking upon concluding that something breaks the H.323 model.
>
> Regards,
>
> ..//steve
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Hi, Everyone:
> >
> > H.323 has some definite architectural notion such as terminal, GK, GW, MCU
> > and(MC, MP). One of the fundamental corner stones is the GK. The H.323
> > entities (e.g., terminals, GWs) register with the GK. A GK manages a zone
> > with the information of all registered users along with other functions
> > (e.g., bandwidth, resource management, etc).
> >
> > The "registration" with the GK is the fundamental corner stone of H.323
> > where an association is made by each user. That is, a GK becomes the basic
> > source to have the information related to each user.
> >
> > H.323 mobility protocol MUST also follow the same H.323 architectural
> > concept. If this basic notion is not maintained, it breaks the basic
> > foundation of H.323.
> >
> > It appears that H.323 mobility likes to define additional databases like
> > VLFs and HLFs that will store the information related to the mobile users.
> > These databases are supposed to help the function of a GK in order to
> manage
> > the mobility related information.
> >
> > If people think that an H.323 will be able to register with a VLF
> directly,
> > does it not mean we are by-passing the basic foundation of H.323 model?
> Does
> > it not opening the entirely a new set of problems in H.323? It will create
> a
> > parallel architecture like GK in H.323 what is not needed at all because
> > solutions have provided that are consistent with H.323 model and there is
> no
> > need to do this. We probably have to do all over again what we have done
> for
> > the GKs and BEs. We inviting unnecessary problems that are yet to imagine
> > where we may end up with. Why do we need to do that if one can do this
> using
> > the consistent H.323 model of GK?
> >
> > In another situation, we have to go step-by-step. First intra-zone, then
> > inter-zone, and last of all inter-domain. Contributions are there to
> address
> > those problems.
> >
> > The mobile users that move between cells, those cells are expected
> primarily
> > remain the control of a given GK (in some cases it may be two GKs). These
> > scenarios mostly seem to be intra-zone and inter-zone and may involve a
> > single service provider. Of course, there will also be the calls between
> the
> > two adm domains of two service providers.
> >
> > More importantly, solutions are inter-dependent. That is, we cannot
> address
> > the problems of inter-zone without knowing the intra-zone. In the same
> > token, we cannot address the inter-domain problems without knowing the
> > inter-zone problem. Contributions are there. Let us proceed accordingly.
> >
> > Last of all, I am reminding the mess that we have made in Annex G. Now
> > people are hungry to use the more powerful and efficient Annex G messages
> > between the GKs. Contributions were brought to do this, but the proposals
> > had been rejected by a very few. Who is suffering?
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T