Hi, Jaakko and All:

In fact, AT&T's contribution APC-1770 submitted in Osaka provides the framework for H.323 inter-domain mobility management using H.225.0 Annex G. So far I understand that this framework has been accepted.

The next question is: How do we extend the H.323 protocol to support mobility using H.225.0 Annex G?

We have not resolved this issue. I made several attempts what we need to do and why some of the proposals made earlier were NOT acceptable from Annex G point of view. I raised the issue that some proposals for inter-domain communications VIOLATE Annex G.

One of the fundamental objections has been Figure 7 (H.323 Annex H Functional Architecture Diagram with Reference Points) of H.323 Annex H draft that shows that "VLF of one domain can communicate with another domain."

In my opinion, this "VIOLATES" H.225.0 Annex G.

Because Annex G ONLY allows that the communications between the two domains can ONLY be permitted via Border Elements (BEs).

I am fully confident that we can solve all H.323 mobility related problems abiding by the "fundamental" principles of H.225.0 Annex G. For example, APC-1770 provides guidelines how we can do this.

Please note that this is a very "SERIOUS" issue as I explained in many of my emails because it may break the fundamental protocol architecture of H.323 in general.

One of the examples can be H.323 QOS. For inter-domain QOS, we also need to adhere to the same principles of H.225.0 Annex G. We cannot allow one QOS manager module sitting behind the GK will be communicating with another QOS manager of another domain "by-passing" the BEs.

Similarly, we can extend the models for billing, directory, and many other services. In fact, H.225.0 Annex G is addressing usage and other services that are used for billing, and Annex G has solved this problem through communicating via BEs (not by-passing them). If one by-passes the BEs (as the VLFs and HLFs of Figure 7 do), people can develop an entirely new protocol (or a new sets of protocols) that can be totally independent of H.323 protocol ( and may not have any relationship of the existing H.323 or H.225.0 Annex G protocol).

So, I am raising my serious concerns as I did in the past. I am also enclosing a copy of APC-1770.

I like to see the comments of other members as well.

Best regards, Radhika R. Roy AT&T

-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Tuesday, July 25, 2000 9:19 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H

Hi all,

As the Mobility AHG members know, the idea of using the H.225 Annex G (Communication between Administrative Domains)protocol in H.323 Annex H has been brought up many times in the discussions. So far, we haven't, however, made any decision or even exhaustive proposals for its usage. Now, the next thing I would like to see in the next draft of Annex H would be the refinement of the information flows and the messages used in the flows and at this point I would like to see what the reaction of the AHG members as well as anyone interested in the topic to the usage of H.225 Annex G protocol would be. The more I have refreshed my memory and knowledge about H.225 Annex G, the more I think that the protocol would be suitable for use in H.323 Annex H (some additions to the protocol would surely be needed). I'm planning on writing an MD contribution for the Mobility Management procedures using the actual H.225 Annex G protocol and if it seems after discussion on the contribution that people are in favor of using the protocol, I'll add this stuff in the next draft annex.

So, at this point I would just like to see your overall comments about the usage of H.225 Annex G.

------------------------------------------------ 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