Requirements for H.ldap

OKUBO Sakae okubo at MXZ.MESH.NE.JP
Sat Jan 11 10:16:58 EST 2003

Dear Mr. Johnson and other experts who are interested in H.ldap,

One of the action points from the previous SG16 meeting in October
2002 is to make a requirement capture as recorded in the meeting
report COM16-R25:

"At the WP2 review session, it was suggested to formulate a
requirements capture that would serve a check at the final stage of
standardization. We can find a good precedent in D.281 for H.248.MCU."

I have tried a draft as attached based on the following materials:

   - AVD-2199 Directory Services Architecture for Multimedia
Conferencing (RADVISION, ViDe, Internet2), June 2002, Bruges
   - D271 Directory Services Architecture for Multimedia Conferencing
(Cisco Systems, Inc.)
   - COM16-R25 Report of WP2/16, October 2002
   - TD-61/WP2 Directory Services Work Plan (Q4/16 Rapporteur), October 2002

Your additions, deletions, reorganization, improved wordings etc are
very much welcome.

Best regards,

e-mail: okubo at
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
   YRP Ichibankan 312                           Tel: +81 46 847 5406
   3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken  Fax: +81 46 847 5413
   239-0847 Japan

GITI Headquarter
   29-7 Waseda University Bldg.                 Tel: +81 3 5286 3831
   1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo      Fax: +81 3 5286 3832
   169-0051 Japan

Draft AVD-2279
Source:  TBD
Title:   Requirements for H.ldap "Directory Services Architecture for
Multimedia Conferencing"
Date:    11 January 2003
Purpose: Proposal

H.ldap will be able to support the following requirements as seen
from the human user, gatekeeper and terminal configuration. The list
will also serve as a checklist to verify that the proposed
specification will support listed items. Some of the features are
marked as advanced features and will be part of the future extension.

1.      General

1/      Service administrators need call servers that are aware of
enterprise directories, to avoid duplication of account management
processes. Users need directories to locate other users with whom
they wish to communicate. All of these processes should pull their
information from canonical data sources in order to reduce redundant
processes and ensure information accuracy. [AVD-2199]

2/      H.ldap should accommodate H.320, H.324, SIP or other call
signaling protocols concurrently with or subsequently to H.323,
subject to decision of the group. [COM16-R25]

3/      The fact that recent videoconferencing products are mostly of
H.323/H.320 hybrid should be taken into account. [COM16-R25]

4/      Standards should include information to facilitate
implementation in addition to normative specifications. [COM16-R25]

5/      It should be possible to create very large-scale distributed
directories. These could include white pages "portals" that allow
searching for users across multiple institutions. In this
application, each enterprise directory would register itself with (or
be unknowingly discovered by) a directory of directories that is
capable of searching across multiple LDAP directories. [AVD-2199]

2.      Object Classes

1/      Enable endpoint information to be associated with people (or
resources such as conference rooms). [AVD-2199]

2/      Enable online searchable "white pages" where dialing
information (e.g. H.323 URL) can be found, along with other
"traditional" directory information about a user, such as name,
address, telephone, email, etc. [AVD-2199]

3/      Enable all endpoint information to be stored in a canonical
data source (the Directory), rather than local to the gatekeeper, so
that endpoints can be managed through manipulations of an enterprise
directory, rather than by direct entry into the gatekeeper. [AVD-2199]

4/      Store enough information about endpoint configuration so that
correct configuration settings can be documented to end users on a
per-endpoint basis, as a support tool. [AVD-2199]

5/      Include H.323 zone information - such as the zone
administrators, network identity of the gatekeeper and resources
associated with the zone. [AVD-2199]

6/      Be able to support multiple instances of endpoints per user. [AVD-2199]

7/      Enable a "whois" functionality for H.323 zones, so that one
may query the network and find contact information for a particular
H.323 zone, and published resources associated with the zone.

8/      Be extendable as necessary. [AVD-2199]  Defining a minimum in
the standard with provision of an extension mechanism has been a good
practice. [COM16-R25]  Careful consideration is needed for what
should be in the standard and what should be left for extension.

9/      Be able to encompass H.32x, SIP or other related conferencing
protocols in the future. [D271]

3.      Security, authentication and authorization

1/      It is important that the H.323 LDAP infrastructure support
not only H.235 Annex D (hop-by-hop authentication) and Annex E
(end-to-end authentication) modes, but that an organization could
shift from one mode to the other without reconstructing the schema.

2/      Associate authentication information with a user and enable
both endpoint and gatekeeper access to that information, in order to
support H.235 Annexes D and E. [AVD-2199]

3/      It should allow both endpoint-centric and user-centric
authentication. [AVD-2199] Authentication credentials, such as
certificate or user ID / password for station and that for user can
be separate. This separation allows for flexibility in the
implementation of security architectures. [COM16-R25]

4/      It should be possible to use the directory to manage the
services that are authorized for each endpoint or user once
authentication is achieved. [D271]


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

More information about the sg16-avd mailing list