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: Friday, September 08, 2000 7:54 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: [H.323 Mobility:] H.323 Annex H status check
Hi all,
I'll try to gather my thoughts of the situation of the H.323 Annex H work after the Portland meeting in this mail. This mail will not handle the issues about the "mandate" of the annex raised by Mr. Roy, but I will take part in that discussion in separate postings.
The draft annex produced as the result of the discussions you had in Portland is TD-42 (not TD-42a as I may have stated earlier). I will produce a cleaned up version of that draft early next week (this new version will only have editorial changes compared to TD-42).
In the following I list issues that need to be addressed in the future work and discussions. The list is based on the ad hoc group meeting minutes that I received from Mr. Rissanen (I assume that these are made by Mr. Korpi) and on the discussions I have had with Mr. Rissanen. The list is not in any particular order.
- Chapter 2, especially concerning Figure 1, should be clarified. I understand that Mr. Aronson will contribute a clarified version of the figure and accompanying text. - Terms, abbreviations and definitions should be re-examined. This work shall be done by the editor with the help of other representatives. Especially the following issues should be kept in mind: - Definition of the H.323 Mobile User should be expanded. - Definition of the Service Provider should be rewritten. - Some representatives were not happy about the current definitions for the Administrative Domains (Home, Visited, etc.). - The terminology of the annex should be aligned with the terminology used in 3G. - Chapter 7 -> Normative text should be produced out of the current text. Editor's note: Currently this chapter is meant to handle the functional REQUIREMENTS for the annex, not normative specifications. Normative text will be produced when these issues are discussed and worked on. Furthermore, I think this chapter could evolve as being the normative text defining e.g. the formats of the identifiers. - New sub-section 7.1.2: "Procedures Required for Provisioning Mobile H.323 Service". If this section is to be added, contributions from the representatives are required (quite fast), otherwise I'm on the opinion that this sub-section should be dropped from the document intended for determination in November. Also, the editor does not have a very clear picture of what issues this sub-section is going to handle, so some clarifications would be nice. - Current draft assumes the GK-routed call model -> Contributions for direct call model are invited. - BEs will be utilized with information flows between different administrative domains. - Some of the information flows in some interfaces should be marked as optional. Also related to this, I think it would be important to decide on which interfaces do we concentrate in the first version of the annex. E.g. reference points K, L and J do not seem to be of the greatest importance, but we could assume that the AuF is always co-located with some other entity and thus leave the interfaces unspecified. I will make a proposal about the this issue in the following week. - The security issues of this annex will be handled in H.235 Annex G. The contents of APC-1930 will be the first "draft" of this annex. The work on H.235 Annex G will, of course, require the help of the mobility group in the form of contributions. I.e., you should still consider the security issues, when making a contribution for the H.323 Annex H, these issues will then be reflected in H.235 Annex G. The editor of H.235 (Mr. Euchner) has kindly offered his help on the security issues. - The cases of a non-mobile User/Terminal calling a mobile User/Terminal (or vice versa) should be addressed in the annex (some of the needed changes are incorporated already in TD-42). - The work on the information flows should continue as fast as possible. Also other protocols than the H.225 Annex G should be examined (e.g. IETF's Mobile IP, etc.). Contributions are invited.
As I said this mail tries to capture my understanding of the H.323 Annex H situation after the Portland meeting. If you think I have missed something important or am deadly wrong about something or you have some other comments/questions, please send a response to this mail to the list.
Have a nice, relaxing weekend, everyone!
------------------------------------------------ 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.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com