[H.323 Mobility:] H.323 Annex H status check

[Roy, Radhika R, ALCOO]

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 at NOKIA.COM]
Sent: Friday, September 08, 2000 7:54 AM
To: ITU-SG16 at 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 at nokia.com *
------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com