[H.323 Mobility:] A new editor's draft H.323 Annex H

Roy, Radhika R, ALARC rrroy at ATT.COM
Mon May 8 16:29:53 EDT 2000

Hi, Jaakko:

I hope that you have been enjoying the ice-hockey....

I understand that the editor's draft is just a contribution for the upcoming
tomorrow's conf call, not a draft for the Osaka meeting.

I do not know which parts of your draft have been taken from the
contributions that had been discussed and agreed. I have seen no reference
to it. Or, have you made some educative guess from your side?

Let me explain.

You have two roles to play: First as an editor to reflect what has been
agreed upon by the members based on contributions. Second, an individual
from Nokia to agree or disagree.

An editor must provide the draft that will reflect what has been agreed by
the members based on contributions. However, as an individual from a company
an editor may have differences. These differences can be reflected in the
draft in two ways: 1. As an editor's note and 2. Even as an individual from
Nokia (assuming that subsequent contributions will clarify this).

I do not have enough time to provide all comments in writing. In brief, I
have the following comments:

Section 4:

I guess that you have one contribution showing these figures 2 through 7
(there is no reference - I see a similarity- am I correct?). We never
discussed this contribution in any conference call. How come that you have
included all figures from your contribution that has not been discussed and

In fact, we discussed about your earlier contribution where we have agreed
that we will start from all H.323 scenarios: First, intra-zone, inter-zone,
and inter-domain scenarios.

For inter-working between H.323 and non-mobile scenarios, there are many
possible scenarios and we may not address in this document for now for the
sake of time. So far I re-collect, this has been the decision. Section 4
does NOT reflect this.

Section 7:

I like to see that there should be an editor's note that "Figure 8 will be
revisited based on the extensions that will be made in H.323 to support
mobility. This is just a place holder to provide references for the on-going

Section 8:

Which contributions your are referring here that we have agreed? I would
request that people MUST bring contributions to define virtual home and
service execution environment before an editor put any texts in it.

Did you submit an outline of your draft to be approved?

Section 9:

Which contributions you are referring to?

Did you have any outlines for this section that need to be approved?

My understanding has been that we agreed that the mobility management will
include: A. Intra-Zone, B. Inter-Zone, and C. Inter-Domain.

In each case it will have the following:

1.      GK discovery
2.      Registration
3.      Location update
4.      Call establishment

AT&T and Alctel contributions are there and these contributions were
discussed. The outlines should follow these procedures to follow the text

Now  I am providing comments per sections that you have arranged although I
do not agree with the outlines.

Section 9.1.1:

Like home domain, AT&T contribution has provided the detail description of
home GK/zone from a user point. Accordingly, home network address (network
point attachment) has been explained. In a given zone, a mobile may move
from one NpoA to another. Like foreign (or visited/visiting/target) domain,
AT&T contribution has also explained the foreign (or
visited/visiting/target) network address (or NpoA). The subsequent emails
have also been sent explaining the things.

I would expect, like visiting/visited domain, the concept of
visiting/visited/target network address should be taken as a part of it.
Without this, the mobility management will almost be MEANINGLESS because the
trivial mobility management keeping some addresses in a database like
VLFs/HLFs do not help the service providers and the mobility management
through re-registration is already there in H.323, and no new standard work
is needed for extending the so called VLFs and HLFs databases.

Figure 11 shows that the inter-zone mobility management is maintained using
the single HLF. Which contributions you are referring to? Did we agree on
this concept? AT&T contribution shows that it is an unacceptable proposition
if we consider that there is a single HLF (as the protocol is "hard-wired"
for a centralized HLF configuration)?

Figure 12 shows that a single VLF is communicating with multiple HLFs. Which
contributions do you refer to?

Figure 13 shows that HLFs are communicating between the domains? Did you not
see that we are NOT in sink with this approach because the questions have
been raised that this approach might be "breaking" the H.323 standard? AT&T
has also provided contributions regarding this (I guess that Alcatel's
contribution also agrees with AT&T's contribution in this regard).

Are you "pushing" for some something (or am I missing something)? If it is
so, please bring contributions, we will be pleased to discuss.

Section 9.2:

Use of GRQ messages for the GK discovery is NOT new in H.323. It is already
a standard. A reference to the existing H.323 standard is enough.

However, the fundamental question has been that GRQ messages are NOT
efficient for the GK discovery in the cellular environment. AT&T
contributions have provided an alternative solution using the MGA message
for the GK discovery.

So, the use of GRQ messages are INEFFICIENT for the GK discovery. So, it is
NOT acceptable in the highly mobile environment.

Section 9.5:

Again, I like to know which contributions you are referring to?

Figures 15, 16, 17, 18, and 19 show that, as if, the protocol is
"hard-wired" for the centralized HLF configuration. AT&T contributions do
not assume this. We have NOT accepted this notion.

So, the basic question: Why do you want to include the material where there
are no contributions and no agreement?

There are fundamental flows the way you have shown all information flows.
Let me cite few examples:

You have shown that LRQ messages are sent from the GK to the VLF and/or HLF.
Why do you think so? Did you not see that we have NOT even agreed with this
in the last conference call and via emails? AT&T contributions have used NEW
mobility management messages.

We have serious problems if we use LRQ messages like this. That is why, AT&T
has provided a contribution APC-1769.

Considering the comments provided above, all texts provided in your
contribution need a COMPLETE re-writing of the document.

I understand the difficulty with the job as an editor. I appreciate your
efforts. However, there are some norms that an editor has to follow:
Contributions and Agreement made. If editors have their opinions, they can
bring separate company contributions (NOT as Rapporteur contributions).

Hope to discuss the same in tomorrow's conf call.

I am also curious to know which the team won the ice-hockey.....

Best regards,

Radhika R. Roy
+1 732 420 1580
rrroy at att.com

> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist at NOKIA.COM]
> Sent: Monday, May 08, 2000 8:27 AM
> Subject:      [H.323 Mobility:] A new editor's draft H.323 Annex H
> Hi all,
> I have uploaded the new editor's draft H.323 Annex H to the URL:
> ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/
> I suggest that we go through the changes I have made in tomorrow's
> teleconference.
> I'm sorry that I haven't responded to any messages recently, but working
> with the draft took a bit more of my time than I expected, so I simply
> haven't had the time. I will try to read all the messages through tomorrow
> and hopefully answer to some.
> And now I'm off to watch Finland demolish the poor Norwegians in the
> ice-hockey world championships...
> ------------------------------------------------
> 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

More information about the sg16-avd mailing list