H.225.0 Annex G conference call
Roy, Radhika R, ALTEC
rrroy at ATT.COM
Wed Aug 5 13:35:12 EDT 1998
We are in receipt of the revised Annex-G sent by Glenn Freundlich via email.
It appears that the present Annex G write-up and email are yet to reflect
the true essence that had been discussed in the conference calls as well as
communicated via emails (copies of the emails including Santo Wiryamen's are
also enclosed). The specific points are mentioned below:
1. The modified title of Annex G is very restrictive, and is NOT
acceptable. The title of the Annex G should remain as it was before -
"Gatekeeper-to-Gatekeeper Communications". (The communication between
administrative domain will only be one of the customized scenarios for
communications between the gatekeepers. It is a complete surprise to see
such a major change has been made all on a sudden).
2. Section 1.1 (Scope). The scope of Annex G should be
"Inter-gatekeeper communications that will include inter-gatekeeper
communications within a given domain as well as communications between the
(administrative) domains". (So, the present objective that restricts for
dealing communications between the administrative domains only is NOT
3. Section 1.1 (Scope). It has been mentioned that "It should also be
understood that Annex G does not mandate a specific system architecture
within an administrative domain". This should NOT be a mandatory in the
standard. Rather, we can keep this as an option depending on the choice of
the implementation schemes. That is, the standard MUST provide all the
options to reveal about the protocols, organization or architecture within a
given administrative domain leaving no room for proprietary implementations
In view of the above limitations of the present Annex G write-up (Title and
Section 1.1), the following have been proposed:
1. The title of Annex G should remain as it was before: "Annex G -
2. Scope of Annex G should be divided into two parts: A.
Inter-Gatekeeper Communications Within a Domain, and B. Inter-Gatekeeper
Communications Between Domains.
3. A domain has to be defined further. For example, a domain may
consist of multiple zones.
4. Inter-gatekeeper communications between the multiple zones of a
given domain has to be standardized as it has been outlined in Santo
Wiryamen's email and APC-1385 (more contributions from AT&T [to be released
after internal review in the Spetember'98 ITU-T SG 16 meeting] for
inter-gatekeeper communications in a given domain that will use
non-hierarchical model will be submitted. All other companies are also
encouraged to submit contributions in this area. Annex G will be expanded as
soon as those contributions are received).
5. A single administrator will also be able to create multiple domains
for its own internal communications for scalability or other purposes for
the large H.323 network. Then, this communication between such domains is
known as "Inter-Gatekeeper Communications Between Domains".
6. If a domain belongs to a single administrator, and communications
between such administrative domains need to happen, then the communication
between such administrative domains is termed as "Inter-Gatekeeper
Communications Between Administrative Domains".
7. The inter-gatekeeper communications between (administrative) domains
can also be non-hierarchical, hierarchical, and hybrid (non-hierarchical +
hierarchical). However, present contributions have been provided only for
hierarchical models, and non-hierarchical and hybrid models will be
addressed as soon as contributions will be received in these areas.
Specific comments related to Section 1.2:
1. Definitions for "H.323 network", "zone" and "domain" should also be
included (in addition to "Administrative Domain" and "Border Element").
Specific comments related to Section 1.3:
1. The title of this section should be changed to "Hierarchical
Inter-Gatekeeper Communications Between Administrative Domains". The
write-up should be modified to take into account all the comments given
Specific comments related to Sections 1.5, 1.5.1, 1.5.2, 18.104.22.168-22.214.171.124:
1. These sections are general enough to be used in the context of a
zone. In fact, it is a very good one. These items are very useful for
communications between the zones within a given domain. AT&T contribution
that is expected be submitted (yet to obtain clearance) may also propose to
use these message sets for inter-zone communications in a given domain.
In view of the above comments, it is proposed that the outline of Annex G
should be modified as follows:
1. Annex G - Gatekeeper-to-Gatekeeper Communications
1.3 Inter-Gatekeeper Communications Within a Given Domains
1.3.1 Non-Hierarchical (Distributive)
1.3.2 Hierarchical (Centralized)
1.3.3 Hybrid (Non-Hierarchical + Hierarchical)
1.4 Inter-Gatekeeper Communications Between (Administrative) Domains
1.4.3 Hybrid (Non-Hierarchical + Hierarchical)
(* The present write-up addresses this model only. The other models will be
addressed as soon as contributions will be brought in those areas).
If anyone has any questions, please let me know.
Radhika R. Roy
Holmdel, NJ 07733, USA
Tel: (732) 949 8657
Fax: (732) 949 8569
Rrroy at att.com
From: Santo Wiryaman[SMTP:swiryaman at VIDEOSERVER.COM]
Reply To: Mailing list for parties associated with ITU-T Study
Sent: Thursday, July 23, 1998 10:37 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: H.225 Annex G hierarchies
I completely agree with Mr. Roy that we should include a discussion
Annex G on how zones within an Administrative domain can be arranged
is described in APC-1385.
However, my version of APC-1375 titles Annex G as "Communication
Administrative Domains". As currently defined in Annex G, an
Administrative Domains includes a "Border Element" and there is an
implied hierarchy structure between a border element and regular
gatekeepers (granted that this could be a degenerate form of
The proposal we brought to the table is how we could arrange these
Administrative Domains in a manner that would be scalable consistent
Goal #2 as stated in Annex G.
swiryaman at videoserver.com
From: Mailing list for parties associated with ITU-T Study Group 16
[SMTP:ITU-SG16 at mailbag.jf.INTEL.COM]
Sent: Thursday, July 23, 1998 8:50 AM
Subject: Re: H.225 Annex G topics
This proposal of Videoserver suggests a specific implementation
is known as "hierarchical (or centralized)" model. A hierarchical
both advantages and disadvantages (we had many discussions on this
However, Annex G does not impose any restriction how the system
will look like. Consequently, the system organization can be
"non-hierarchical (or distributive)", "hierarchical (or
"hybrid (distributive + centralized)" as proposed in APC 1385, and
chosen depending what is best from an implementation point of view.
The important point is that a "zone" having a single gatekeeper (GK)
the basic building block. A domain may consist of multiple zones.
possible logical organizational relationship for communications
multiple zones can be "distributive", "centralized", or "hybrid" as
in APC 1385. The fundamental questions are as follows:
* Can we define the inter-GK communications protocol (IGCP)
satisfies the requirements in "distributive", "centralized", and
system organizational environment?
* Can we use the same RAS protocol that will provide the
solution for both connection oriented and connectionless networking
environment considering the large-scale H.323 network? Or do we need
extension of this RAS protocol?
Therefore, it is strongly suggested that the above points that are
suggested in APC 1385 should also be included in the work scope of
Thanks and regards,
Radhika R. Roy
Tel: (732) 949 8657
Fax: (732) 949 8569
Email: rrroy at att.com
> From: Glen Freundlich[SMTP:ggf at lucent.com]
> Reply To: ggf at lucent.com
> Sent: Tuesday, August 04, 1998 1:53 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: H.225.0 Annex G conference call
> <<File: annexg.zip>>
> There will be another conference call to discuss H.225.0 Annex G:
> date: 6 August (Thursday)
> time: 9:00am Mountain Time (8:00 Pacific, 11:00 Eastern, etc)
> bridge number: +1 630-713-3333
> code: 840059
> duration: 1 hour
> Tentative agenda:
> - next call on 19 August (Wednesday)?
> - readout on issues from last call:
> - security issues (Senthil Sengodan) - see email
> - Diameter update (Nancy Greene)
> - telephone network addressing hierarchy (Hal Purdy)
> - review of current Annex G text (see attached document)
> - review requirements coverage
> Notes from last call:
> There was more discussion about architecture, with reference to APC-1385
> and an email submission from Santo Wiryamen. Annex G should not impose
> any architectural model, and should allow any model (hierarchical,
> distributed, hybrid) to exist. Nothing currently proposed seems to
> require, or favor, one model over any other, but text and figures should
> give equal time to other models. Also, both currently defined call
> models (gatekeeper routed and direct endpoint) should be allowed, and
> the protocols are probably not different depending on call model.
> There could be some value in looking at numbering and architecture in
> the telephone network, although numbering and architecture are probably
> orthogonal issues. Hal Purdy will investigate the telephone network's
> implementation and report back.
> Nancy Greene gave a quick readout on Diameter. There is a framework that
> can carry various extensions, where the Annex G work could fit into one
> (or more) extensions. The framework and some extensions are current IETF
> drafts. Nancy will provide more details.
> There are security concerns that will need to be addressed. Senthil
> Sengodan will begin to look at this and report back.
> For those who were on the last call, please correct me if I've missed
> Glen Freundlich ggf at lucent.com
> Lucent Technologies office: +1 303 538 2899
> 11900 N. Pecos fax: +1 303 538 3907
> Westminster, Colorado 80234 USA
More information about the sg16-avd