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@ericsson.com] Sent: Monday, May 08, 2000 3:10 PM To: Roy, Radhika R, ALARC Cc: tsg16q13@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@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@ericsson.com] Sent: Thursday, May 04, 2000 9:13 AM To: Roy, Radhika R, ALARC Cc: tsg16q13@itu.int Subject: Re: [H.323 Mobility:] On home concepts, etc. Hi Roy, I am not clear on what suggestions are "breaking" h.323. Isence
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@lme.ericsson.se] > > Sent: Wednesday, May 03, 2000 6:17 PM > > To: Roy, Radhika R, ALARC > > Cc: 'jaakko.sundquist@nokia.com'; tsg16q13@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@att.com] > > Sent: den 3 maj 2000 16:26 > > To: Gösta Linder (LME); Gösta Linder (LME); > > 'jaakko.sundquist@nokia.com'; tsg16q13@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 contributionsin
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@lme.ericsson.se] > > > Sent: Tuesday, May 02, 2000 5:17 PM > > > To: Roy, Radhika R, ALARC; Gösta Linder (LME); > > > 'jaakko.sundquist@nokia.com'; tsg16q13@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@ATT.COM] > > > Sent: den 28 april 2000 17:37 > > > To: Gösta Linder (LME); 'jaakko.sundquist@nokia.com'; tsg16q13@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 theHome
> > Administrative > > > Domain needs to be involved in this. ..." > > > > > > We do not think that this would "always" be true becauselet
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@LME.ERICSSON.SE] > > > > Sent: Friday, April 28, 2000 11:15 AM > > > > To: 'jaakko.sundquist@nokia.com'; tsg16q13@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@nokia.com [mailto:jaakko.sundquist@nokia.com] > > > > Sent: den 20 april 2000 13:59 > > > > To: Gosta.Linder@lme.ericsson.se; tsg16q13@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, eventhough > > > > > 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 ortopology 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 isthe GK
> > > > > that serves a user that is attached to a Visited Admin > > > > > Domain? Perhaps you remember from WP2 plenary inGeneva,
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 pointingat
> > > > > having a mobility concept that allows for freedom inservice > > > > > 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 theservice > > > > > 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 domainuntil
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 isactually 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@mailbag.intel.com