[H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H

Roy, Radhika R, ALCOO rrroy at ATT.COM
Tue Jul 25 10:23:36 EDT 2000

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

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

-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
Sent: Tuesday, July 25, 2000 9:19 AM
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 at nokia.com *

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC-1770.zip
Type: application/octet-stream
Size: 140626 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000725/64dacc14/attachment-0006.obj>

More information about the sg16-avd mailing list