[H.323 Mobility:] On home concepts, etc.
Roy, Radhika R, ALARC
rrroy at ATT.COM
Mon May 8 15:58:56 EDT 2000
Hi, Steve:
I am really curious to se the detail of Ericsson's contribution.
What I am worried about that the basic problems still remain the same
whether we go via GKs (or HLFs). Now GKs and BEs have mechanisms in place if
any information is not available to a GK (or BE) how to communicate with
another one to resolve it.
In view of many HLFs, I am afraid that we may to do the same with the HLFs
all over again. Then the basic question comes: Why do we want to re-invent
the wheel (assuming that a GK or BE will be able to do the job if we go via
them because HLFs are sitting behind them).
We will discuss when we see your contributions.
Best regards,
Radhika R. Roy
> -----Original Message-----
> From: Stephen Terrill [SMTP:stephen.terrill at ericsson.com]
> Sent: Monday, May 08, 2000 3:10 PM
> To: Roy, Radhika R, ALARC
> Cc: tsg16q13 at itu.int
> Subject: Re: [H.323 Mobility:] On home concepts, etc.
>
> Hello Roy,
>
> Thanks for resending, our mail system is strained here due to the recent
> virus which is going around.
>
> I am in the process of submitting a contribution to the next meeting
> (again slowed by the email system).
>
> I haven´t read the indicated contributions, however I can guess the
> contents based your description below. What I am trying to say is that
> with the ericsson contribution, Annex G applies between "home" operators,
> and the visited network is not considered to be another service domain,
> but a means for IP connectivity and maybe some resource support (such
> things are really for further study) (there maybe a gatekeeper proxy in
> the visited network to proxy the messages to the home gatekeeper in our
> view). As such, I don´t view that this breaks the H.323 model in any
> means.
>
> Regards,
>
> ..//steve
>
> "Roy, Radhika R, ALARC" wrote:
>
> > Steve:
> >
> > I do not know whether you received this or not because I have not seen a
> > copy of it from the reflector. So, I am enclosing it again.
> >
> > Thanks,
> > Radhika R. Roy
> >
> > > -----Original Message-----
> > > From: Roy, Radhika R, ALARC
> > > Sent: Friday, May 05, 2000 9:02 AM
> > > To: 'Stephen Terrill'
> > > Cc: tsg16q13 at itu.int
> > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > >
> > > Hi, Steve:
> > >
> > > I do not know what your reference is up to.
> > >
> > > Please see the contributions from Alcatel that also shows in one
> example
> > > as inter-domain communications.
> > >
> > > You can also see Ericsson's contribution where inter-domain
> communications
> > > are shown.
> > >
> > > If you compare the two, you can see a difference. Alcatel's
> contribution
> > > is following the framework of H.323 (H.225.0 Annex G) although there
> are
> > > other items that are required to be there (AT&T's upcoming
> contributions
> > > will explain this as well).
> > >
> > > I guess that Ericsson's contribution is NOT along the framework of
> H.323
> > > (H.225.0 Annex G) for inter-domain communications. It is not an
> assumption
> > > per se. AT&T's upcoming contribution will explain why it is NOT within
> the
> > > framework of H.225.0 Annex G.
> > >
> > > In this context, AT&T is also bringing contributions and we can have a
> > > detail discussion in Osaka or in the cof call on May 9.
> > >
> > > Best regards,
> > > Radhika R. Roy
> > > AT&T
> > >
> > > -----Original Message-----
> > > From: Stephen Terrill [SMTP:stephen.terrill at ericsson.com]
> > > Sent: Thursday, May 04, 2000 9:13 AM
> > > To: Roy, Radhika R, ALARC
> > > Cc: tsg16q13 at itu.int
> > > Subject: Re: [H.323 Mobility:] On home concepts, etc.
> > >
> > > Hi Roy,
> > >
> > > I am not clear on what suggestions are "breaking" h.323. I
> sence
> > > that there are assumptions being made which are not necessarily valid.
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > > "Roy, Radhika R, ALARC" wrote:
> > >
> > > > Hi, Gösta:
> > > >
> > > > Let us discuss this what it means. Let me provide an example.
> > > H.323 uses
> > > > Q.931/932-like protocol that has been the part the
> > > circuit-switching
> > > > network. However, H.225.0's Q.931/932 has become a part of the
> > > > packet-switched H.323 protocol. Now, H.225.0 (RAS, Q.931/932,
> > > Annex G
> > > > protocol), H.245, and H.235 have become the part of H.323.
> > > >
> > > > These protocols have created a new framework of H.323 (H.225.0
> and
> > > H.245 are
> > > > no longer valid from the circuit-switched PSTN/ISDN network
> point
> > > of view).
> > > > We have got a new set of rules based on the existing H.323
> > > standard.
> > > >
> > > > In the same token, we can look into any protocols that we
> might
> > > think of,
> > > > but we have to use it within the framework of the existing
> H.323
> > > standard
> > > > without "breaking" it.
> > > >
> > > > Our main goal is to extend H.323 protocol to support mobility.
> > > >
> > > > Hope it will clarify points further.
> > > >
> > > > Best regards,
> > > > Radhika R. Roy
> > > >
> > > > > -----Original Message-----
> > > > > From: Gösta Linder (LME) [SMTP:Gosta.Linder at lme.ericsson.se]
> > > > > Sent: Wednesday, May 03, 2000 6:17 PM
> > > > > To: Roy, Radhika R, ALARC
> > > > > Cc: 'jaakko.sundquist at nokia.com'; tsg16q13 at itu.int
> > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > > > >
> > > > > Hi Roy,
> > > > > according to ToR for H323 AnnexH, the following outputs are
> > > expexted by
> > > > > our work:
> > > > > "A complete H.323 Annex H specification document will be
> > > produced. The
> > > > > framework, architecture, any changes to existing H.323
> messages
> > > or
> > > > > protocols as well as any requirements on the non-H.323
> protocols
> > > to be
> > > > > utilized as part of the solution will be included in the
> > > specification."
> > > > >
> > > > > This means that we are not restricted to look at HLF/VLF as
> BEs
> > > under the
> > > > > GK. Thus the input by Steve prior to the last teleconf is
> not
> > > assuming
> > > > > HLF/VLF as Bach End functions to GK.
> > > > >
> > > > > So let us be open in our definitions of a mobility solution
> > > supporting
> > > > > H323 systems and find a suitable solution.
> > > > > Best Regards/Gösta Linder
> > > > >
> > > > > -----Original Message-----
> > > > > From: Roy, Radhika R, ALARC [mailto:rrroy at att.com]
> > > > > Sent: den 3 maj 2000 16:26
> > > > > To: Gösta Linder (LME); Gösta Linder (LME);
> > > > > 'jaakko.sundquist at nokia.com'; tsg16q13 at itu.int
> > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > > > >
> > > > >
> > > > > Hi, Gösta:
> > > > >
> > > > > The basic point is that we are extending H.323 to support
> > > mobility. So,
> > > > > there are some fundamental basis how H.323 protocol works.
> So,
> > > we are
> > > > > committed to be consistent with the H.323 standard that
> already
> > > exists.
> > > > >
> > > > > In H.323, the logical entities are terminals, GWs, GKs, BEs,
> > > MCUs, MCs,
> > > > > and
> > > > > others.
> > > > >
> > > > > HLFs, VLFs, and AuFs are the servers that provide the
> backend
> > > services
> > > > > (BES).
> > > > >
> > > > > The BES servers are connected behind the GKs and BEs.
> > > > >
> > > > > Similarly, the directory servers, billing servers, route
> > > servers, and
> > > > > other
> > > > > servers are also considered as the BES servers in H.323. In
> the
> > > same
> > > > > token,
> > > > > they also reside behind the GKs and BEs.
> > > > >
> > > > > So, H.323 protocol is very clear about the relationship
> between
> > > the
> > > > > GKs/BEs
> > > > > and the BES servers. The protocol itself says what the
> logical
> > > relation is
> > > > > or should be. More specifically, H.225.0 Annex G shows how
> the
> > > > > inter-domain
> > > > > communications are performed.
> > > > >
> > > > > In this respect, AT&T is also bring two more contributions
> in
> > > the upcoming
> > > > > SG16 Q.13 Osaka meeting in addition to the contributions
> that
> > > have been
> > > > > submitted to the Ad Hoc Mobility group.
> > > > >
> > > > > I would appreciate to explain your points more clearly with
> > > reference to
> > > > > AT&T MD-018 and MD-017. In this way, I could reply you
> questions
> > > more
> > > > > clearly.
> > > > >
> > > > > Finally, I am confident that we can satisfy all requirements
> > > including the
> > > > > items that you are up to consistent with the existing H.323
> > > standard.
> > > > >
> > > > > Thank you very much for continued discussion that helps all
> of
> > > us to
> > > > > understand better.
> > > > >
> > > > > Best regards,
> > > > > Radhika R. Roy
> > > > > AT&T
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gösta Linder (LME)
> > > [SMTP:Gosta.Linder at lme.ericsson.se]
> > > > > > Sent: Tuesday, May 02, 2000 5:17 PM
> > > > > > To: Roy, Radhika R, ALARC; Gösta Linder (LME);
> > > > > > 'jaakko.sundquist at nokia.com'; tsg16q13 at itu.int
> > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > > > > >
> > > > > > Roy, regards your statement; "To be consistent with the
> H.323
> > > system
> > > > > > architecture in view of multiple HLFs...." seems to be
> > > premature. A
> > > > > H.323
> > > > > > system architectecture is not as yet defined regards
> mobility,
> > > that is
> > > > > > what we are trying to do. When we identified the HLF, VLF
> in
> > > Red Banks,
> > > > > we
> > > > > > did not state them relates role of the GK and if
> registration
> > > should go
> > > > > > via GK or directly to the HLF function. In fact, I do not
> see
> > > any
> > > > > purpose
> > > > > > of going via the GK to register or make a location
> request.
> > > Really,
> > > > > > according to the subscription data might give the info
> needed
> > > to do the
> > > > > > right GK selection. I.e. we then better do the GK
> selection
> > > based upon a
> > > > > > HLF selection rather than other way around.
> > > > > > Best Regards /Gösta Linder
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Roy, Radhika R, ALARC [mailto:rrroy at ATT.COM]
> > > > > > Sent: den 28 april 2000 17:37
> > > > > > To: Gösta Linder (LME); 'jaakko.sundquist at nokia.com';
> > > tsg16q13 at itu.int
> > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > > > > >
> > > > > >
> > > > > > Hi, Gösta:
> > > > > >
> > > > > > If the concept of the home domain needs to be added as
> well as
> > > home
> > > > > > GK/zone
> > > > > > (+ home network address) etc., I also see that there is a
> need
> > > for
> > > > > further
> > > > > > inclusion in Annex H.
> > > > > >
> > > > > > However, one side comment in response to Jaakko's
> comments,
> > > "..If we are
> > > > > > talking just about contacting the User's HLF from a
> Visited
> > > > > > Administrative Domain, my opinion is that no GK in the
> Home
> > > > > Administrative
> > > > > > Domain needs to be involved in this. ..."
> > > > > >
> > > > > > We do not think that this would "always" be true because
> let
> > > us NOT
> > > > > assume
> > > > > > that the there is only ONE HLF (or one logically clustered
> > > HLF) with
> > > > > > centralized architecture in a domain. To be consistent
> with
> > > the H.323
> > > > > > system
> > > > > > architecture in view of multiple HLFs (centralized or
> > > distributed),
> > > > > > associations through signaling messages of the backend
> > > services (e.g.,
> > > > > > HLFs/VLFs, security servers [AuFs], billing servers,
> directory
> > > servers,
> > > > > > etc)
> > > > > > are made via the GKs and BEs.
> > > > > >
> > > > > > Best regards,
> > > > > > Radhika R. Roy
> > > > > > AT&T
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Gösta Linder (LME)
> > > [SMTP:Gosta.Linder at LME.ERICSSON.SE]
> > > > > > > Sent: Friday, April 28, 2000 11:15 AM
> > > > > > > To: 'jaakko.sundquist at nokia.com'; tsg16q13 at itu.int
> > > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > > > > > >
> > > > > > > Jakko,
> > > > > > > sorry for not beeing able to answere until now;
> > > > > > > The comments you made clarifies what you were aiming
> for.
> > > With that I
> > > > > > have
> > > > > > > no concerns with your statements proposed for further
> > > inclusion in
> > > > > Annex
> > > > > > > H.
> > > > > > > Regards / Gösta
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: jaakko.sundquist at nokia.com
> > > [mailto:jaakko.sundquist at nokia.com]
> > > > > > > Sent: den 20 april 2000 13:59
> > > > > > > To: Gosta.Linder at lme.ericsson.se; tsg16q13 at itu.int
> > > > > > > Subject: RE: [H.323 Mobility:] On home concepts, etc.
> > > > > > >
> > > > > > >
> > > > > > > Hi Gösta,
> > > > > > >
> > > > > > > Comments embedded...
> > > > > > >
> > > > > > > > Jakko,
> > > > > > > > regards Home GK;
> > > > > > > >
> > > > > > > > I am not sure I understand what subject you are
> addressing
> > > > > > > > with "a home GK, and more precicely in such a way that
> > > > > > > > there is only one home GK for a User"
> > > > > > > >
> > > > > > > > As we agreed in the mailing prior to the Tel Conf;
> there
> > > > > > > > might be more than one GK in Home admin domain, even
> > > though
> > > > > > > > just one is seen from Visited Admin Domains.
> > > > > > >
> > > > > > > I do not remember agreeing to anything like this. What
> > > exactly do you
> > > > > > mean
> > > > > > > with "just one is seen from Visited Admin Domains"? Of
> > > course there
> > > > > can
> > > > > > be
> > > > > > > multiple GKs per domain and my opinion is that the
> Visited
> > > > > > Administrative
> > > > > > > Domain should not even be aware of the amount or
> topology of
> > > GKs in
> > > > > the
> > > > > > > Home
> > > > > > > Administrative Domain.
> > > > > > >
> > > > > > > If we are talking just about contacting the User's HLF
> from
> > > a Visited
> > > > > > > Administrative Domain, my opinion is that no GK in the
> Home
> > > > > > Administrative
> > > > > > > Domain needs to be involved in this.
> > > > > > >
> > > > > > > >
> > > > > > > > Or are you are addressing the the issue of which is
> the GK
> > > > > > > > that serves a user that is attached to a Visited Admin
> > > > > > > > Domain? Perhaps you remember from WP2 plenary in
> Geneva,
> > > we
> > > > > > > > agreed on having two alternatives; either a GK of Home
> > > Admin
> > > > > > > > Domain OR the GK of Visited Admin Domain service
> control.
> > > The
> > > > > > > > overall objective for the Home Admin GK control is the
> one
> > > > > > > > pointed out by Radhika in a just recent mail pointing
> at
> > > > > > > > having a mobility concept that allows for freedom in
> > > service
> > > > > > > > provisioning; i.e, the freedom of the service provider
> to
> > > > > > > > offer the service he wants without waiting for the
> > > > > > > > Administrator of the Visited Domain to introduce the
> > > service
> > > > > > > > needed by the Home Administrator customer(=user). This
> > > would
> > > > > > > > then in turn spoil the concept of providing a
> homogeneous
> > > > > > > > service for the user roaming between admin domain
> until
> > > each
> > > > > > > > new service is standardised and implemented
> accordingly
> > > > > > > > between the Administartors of all domains within a
> > > > > > > > "homogeneous service alliance group".
> > > > > > > >
> > > > > > >
> > > > > > > I do remember the discussions in Geneva. This is
> actually a
> > > big part
> > > > > of
> > > > > > > what
> > > > > > > we have been discussing with Steve and I think we should
> try
> > > to
> > > > > describe
> > > > > > > these two alternative service provisioning schemes in
> the
> > > Annex H (we
> > > > > > > already have reserved headings for the explanations for
> them
> > > in the
> > > > > > > annex).
> > > > > > > I tried to say in many of my mails about the Home GK
> idea
> > > that I do
> > > > > > > understand that it is probably needed in the Home
> executed
> > > services
> > > > > > > scheme,
> > > > > > > but in my opinion not in the Visited Domain executed
> > > services scheme.
> > > > > > >
> > > > > > > - Jaakko
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd
mailing list