Hi, Everyone:
Let me repeat it again:
We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks.
Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks.
Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU.
Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks.
The same argument is true for QOS, billing, authentication, directory, etc, and others.
Let us not confuse things.
Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network.
That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU.
Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
Hi Radhika, Paul & others
Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323.
-Jaakko
-----Original Message----- From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: 17. September 2000 3:48 To: ITU-SG16@mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
Hi, Paul:
I am glad that you have asked this question.
HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others.
All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK.
(An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.)
If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life.
The same is also true for QoS, authentication, accounting, billing, and others.
More importantly, IMT-2000 is dedicated for mobility.
Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows:
Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.)
If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air."
Best regards, Radhika R. Roy AT&T
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, September 16, 2000 2:45 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
Radhika, et al,
I have to confess that I have had no time to really follow the Annex H work, but I do have a question to toss out here:
Why do you consider the VLF or HLF functions outside the scope of Q13/16? I assume that these functions are IP-based (or at least used with the same call signaling transport as the H.323 system) and integrate with the H.323 functions.
You stated below that these functions are common for all mobile systems. I will not argue that point, but will a common solution be the most appropriate for H.323 systems? I would guess that trying to introduce a generic mechanism may or may not be the best solution for H.323.
I'd like to hear counter arguments to yours. Apparently others felt that these functions were necessary for H.323 systems and should be defined within the H.323 framework.
Paul
----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Friday, September 15, 2000 10:25 AM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
Hi, Everyone:
The document MD-106 (H.323 Annex H) submitted by the editor remains basically same from the fundamentally point of view. So,
the comments
provided on the September 8 email (copy enclosed) remains
the same as stated
earlier. The comments can be summarized as follows:
The Annex should be divided into two parts:
Part 1: Within the scope of Q.13/16: Extension of H.323
(e.g., H.225.0 [RAS,
Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.
(Contributions
are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.)
Part 2: Outside the scope of Q.13/16: Back-end services related to
Mobility
(or value-added services related mobility) containing VLF and HLF.
So, it can be seen clearly that MD-106 (H.323 Annex H)
submitted by the
editor does not contain the basic part 1 which is within
the scope of
Q.13/16 (it rather contains part 2 which is outside the
scope of Q.13/16).
Best regards, Radhika R. Roy AT&T +1 732 420 1580
-----Original Message----- From: Roy, Radhika R, ALCOO Sent: Friday, September 08, 2000 10:23 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] H.323 Annex H status check
Hi, Everyone:
The draft does not contain the basic part: Extensions of
H.323 (e.g.,
H.225.0 messages). Contributions are there (e.g., D.354 of
SG16 Feb'00,
Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ
messages
need to be removed to the base spec of H.323 because there
is nothing
specific to be done with mobility. If it is used in the context of
mobility,
the issues related to mobile need to be pointed out so that
contributions
can be brought to address those issues. Contributions are
there to note the
issues.
The another suggestion is to make two parts of the Annex: 1. Basic
extension
of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end
services
related to Mobility (or value-added services related
mobility)containing VLF
and HLF.
Part 2 clearly does not have to be specific to H.323. It is
a general
service related to mobility. Every application that needs
mobility may like
to use these services. This will be addressed in the light
of the all mobile
applications of all questions of all SGs of the ITU-T. So, it is out-of-scope of Q.13/16 because Q.13/16 alone cannot makes
this decision.
Please note that Security (AuF) is also needed for the
fixed users. So, this
is a generic service that needs to be developed for both
fixed and mobile
users. So, it also belongs to the base H.323 spec. That is, any specification related to AuF should be moved to the base
H.323 spec as well
because it belong to both and the standard should be developed
accordingly.
For rapid determination, I would suggest to address part 1
only in the first
phase.
More specific technical comments will be given for each
point once the
primary objectives are clarified.
Best regards,
Radhika R. Roy AT&T
-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, September 14, 2000 7:28 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
Hi all,
I have uploaded MD-106 to URL:
ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10
6_H323AnnexHDr
aft.zip . The document is a cleaned up version of TD-42 of the Portland meeting and contains only editorial changes(as the template used in the draft document so far was, for some reason, a total mess). The only "exeption" to this is the following correction. Section 8.1 of TD-42 included the text: "Reference points A and B are out of the scope of this Annex.", which has been removed and instead section 8.3 now includes the text: "Reference points B, C and D are out of the scope of this Annex (Hinter is included but only as an option in case that utilization of reference point A is not practical).". The reason for this change is that the text in TD-42 is, as I understand from Mr. Rissanen's comments, a typo and should have mentioned reference points B and C instead of A and B.
Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist@nokia.com *
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com