Request for Comments: 3944 U. of North Carolina
Category: Informational S. Okubo
Waseda University
S. Campos
ITU-T
December 2004
H.350 Directory Services
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The International Telecommunications Union Standardization Sector
(ITU-T) has created the H.350 series of Recommendations that specify
directory services architectures in support of multimedia
conferencing protocols. The goal of the architecture is to
’directory enable’ multimedia conferencing so that these services can
leverage existing identity management and enterprise directories. A
particular goal is to enable an enterprise or service provider to
maintain a canonical source of users and their multimedia
conferencing systems, so that multiple call servers from multiple
vendors, supporting multiple protocols, can all access the same data
store.
Because SIP is an IETF standard, the contents of H.350 and H.350.4
are made available via this document to the IETF community. This
document contains the entire normative text of ITU-T Recommendations
H.350 and H.350.4 in sections 4 and 5, respectively. The remaining
sections are included only in this document, not in the ITU-T
version.
Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions used in this document . . . . . . . . . . . . . . 4
4. H.350 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Design Goals . . . . . . . . . . . . . . . . . . 6
4.1.2. Extending the Schema . . . . . . . . . . . . . . 7
4.2. commURIObject Definition. . . . . . . . . . . . . . . . 10
4.2.1. commURIObject. . . . . . . . . . . . . . . . . . 10
4.2.2. commURI. . . . . . . . . . . . . . . . . . . . . 10
4.3. CommObject Definition . . . . . . . . . . . . . . . . . 11
4.3.1. commObject . . . . . . . . . . . . . . . . . . . 11
4.3.2. commUniqueId . . . . . . . . . . . . . . . . . . 11
4.3.3. commOwner. . . . . . . . . . . . . . . . . . . . 12
4.3.4. commPrivate. . . . . . . . . . . . . . . . . . . 13
4.4. CommObject LDIF Files . . . . . . . . . . . . . . . . . 13
4.4.1. LDIF for commURIObject . . . . . . . . . . . . . 13
4.4.2. LDIF for commObject. . . . . . . . . . . . . . . 15
4.5. H.350 Annex A Indexing Profile. . . . . . . . . . . . . 17
5. H.350.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Extending the schema . . . . . . . . . . . . . . 18
5.2. Object class definitions. . . . . . . . . . . . . . . . 18
5.2.1. SIPIdentity. . . . . . . . . . . . . . . . . . . 18
5.2.2. SIPIdentitySIPURI. . . . . . . . . . . . . . . . 19
5.2.3. SIPIdentityRegistrarAddress. . . . . . . . . . . 19
5.2.4. SIPIdentityProxyAddress. . . . . . . . . . . . . 20
5.2.5. SIPIdentityAddress . . . . . . . . . . . . . . . 21
5.2.6. SIPIdentityPassword. . . . . . . . . . . . . . . 21
5.2.7. SIPIdentityUserName. . . . . . . . . . . . . . . 22
5.2.8. SIPIdentityServiceLevel. . . . . . . . . . . . . 23
5.3. SIPIdentity LDIF Files. . . . . . . . . . . . . . . . . 23
5.4. H.350.4 Annex A Indexing profile. . . . . . . . . . . . 26
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References. . . . . . . . . . . . . . . . . . 28
8.2. Informative References. . . . . . . . . . . . . . . . . 28
9. Relationship to Other Specifications. . . . . . . . . . . . . 29
10. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 30
1. Scope
The International Telecommunications Union Standardization Sector
(ITU-T) has created the H.350 series of Recommendations that specify
directory services architectures in support of multimedia
conferencing protocols. The goal of the architecture is to
’directory enable’ multimedia conferencing so that these services can
leverage existing identity management and enterprise directories. A
particular goal is to enable an enterprise or service provider to
maintain a canonical source of users and their multimedia
conferencing systems, so that multiple call servers from multiple
vendors, supporting multiple protocols, can all access the same data
store.
H.350 architectures are not intended to change the operation of
multimedia conferencing protocols in any way. Rather, they are meant
to standardize the way the already defined protocol elements are
stored in a directory, so that they can be accessed in a standardized
manner.
In the H.350 series, Recommendation H.350 specifies the base
architecture and object classes, while subordinate Recommendations
specify elements that are specific to individual protocols.
Currently, the Recommendations include:
H.350 - Directory Services Architecture for Multimedia Conferencing
H.350.1 - Directory Services Architecture for H.323
H.350.2 - Directory Services Architecture for H.235
H.350.3 - Directory Services Architecture for H.320
H.350.4 - Directory Services Architecture for SIP
H.350.5 - Directory Services Architecture for Non-Standard Protocols
Because SIP is an IETF standard, the contents of H.350 and H.350.4
are made available via this document to the IETF community.
2. Terminology
The following terms are used throughout the document:
* call server: a protocol-specific signalling engine that routes
video or voice calls on the network. In H.323 this entity is a
gatekeeper. In SIP, this entity is a SIP Proxy Server. Note that
not all signalling protocols use a call server.
* endpoint: a logical device that provides video and/or voice media
encoding/decoding, and signalling functions. Examples include:
* a group teleconferencing appliance that is located in a
conference room
* an IP telephone.
* a software program that takes video and voice from a camera and
microphone and encodes it and applies signalling using a host
computer.
* enterprise directory: A canonical collection of information about
users in an organization. Typically this information is collected
from a variety of organizational units to create a whole. For
example, Human Resources may provide name and address,
Telecommunications may provide the telephone number, Information
Technology may provide the email address, etc. For the purposes
of this architecture, it is assumed that an enterprise directory
is accessible via LDAP.
* White Pages: An application that allows end users to look up the
address of another user. This may be web-based or use some other
user interface.
3. Conventions used in this document
Conventions in this document conform to ITU-T guidelines. In this
Recommendation, the following conventions are used:
"Shall" indicates a mandatory requirement.
"Should" indicates a suggested but optional course of action.
"May" indicates an optional course of action rather than a
recommendation that something take place.
References to clauses, sub clauses, annexes and appendices refer to
those items within this Recommendation unless another specification
is explicitly listed.
4. H.350
The normative text of H.350 is reproduced in this section.
4.1. Scope
This Recommendation describes a directory services architecture for
multimedia conferencing using LDAP. Standardized directory services
can support association of persons with endpoints, searchable white
pages, and clickable dialling. Directory services can also assist in
the configuration of endpoints, and user authentication based on
authoritative data sources. This document describes a standardized
LDAP schema to represent endpoints on the network and associate those
endpoints with users. It discusses design and implementation
considerations for the inter-relation of video and voice-specific
directories, enterprise directories, call servers and endpoints.
The use of a common, authoritative data source for call server,
endpoint, user, authentication and white pages information is an
important aspect of large scale multimedia conferencing environments.
Without a common data source, service providers must create separate
processes to manage each of these functions. By standardizing the
LDAP schema used to represent the underlying data, products from
different system vendors can be deployed together to create an
overall application environment. For example, a white pages search
engine developed by one provider could serve directory information to
IP telephones produced by a second provider, with signalling managed
by a call server produced by yet a third provider. Each of these
disparate systems can access the same underlying data source,
reducing or eliminating the need to coordinate separate management of
each system. A significant benefit to the user is that the
management of this data can be incorporated into existing customer
management tools, allowing for quick and flexible scaling up of
applications. Indeed, many technology providers have already
incorporate LDAP into their products, but have been forced to do so
without benefit of a standardized schema. This Recommendation
represents an effort to standardize those representations to improve
interoperability and performance.
While URLs are already standardized for several conferencing
protocols, their representation in a directory is not. This
Recommendation supports a standardized way for URLs to be searched
and located. This is a necessary step to support ’clickable
dialling’.
Management of endpoint configurations can be improved if the correct
settings are stored by the service provider in a location that is
accessible to both service provider and endpoint. LDAP provides a
convenient storage location that can be accessed by both call server
and endpoint; thus it is possible to use the directory to support
endpoint configuration, which is important for simplified operation
and supporting user mobility. Note that other technologies also
support endpoint configuration, notably the use of SNMP for complete
configuration and SRV records for obtaining registration server
addresses. Therefore, H.350 should be viewed not as an authoritative
endpoint configuration architecture, but rather one tool that can
assist with this task. Note that the use of H.350 has as a feature
endpoint specific configuration, where it is desirable that each
endpoint has a unique configuration.
This architecture uses a generic object class, called commObject, to
represent attributes common to any video or voice protocol. Auxiliary
classes represent specific protocols, such as H.323, H.235, or H.320,
as described in the H.350.x series of Recommendations. Multiple
H.350.x classes can be combined to represent endpoints that support
more than one protocol. For example, endpoints that support H.323,
H.235 and H.320 would include H.350, H.350.1, H.350.2, and H.350.3 in
their LDAP representations. Further, each entry should contain
commObject to serve as the entry’s structural object class.
There are two basic components in the architecture. The commURI
object is a class whose only purpose is to link a person or resource
to a commObject. By placing a commURI ’pointer’ in an individual’s
directory entry, that individual becomes associated with the
particular targeted commObject. Similarly, commObject contains a
pointer, called commOwner, which points to the individual or resource
that is associated with the commObject. In this way, people or
resources can be associated with endpoints. The only change required
in the enterprise directory is the addition of the simple object
class commURI. CommObject data may be instantiated in the same or in
entirely separate directories, thus allowing flexibility in
implementation.
4.1.1. Design Goals
Large-scale deployments of IP video and voice services have
demonstrated the need for complementary directory services
middleware. Service administrators need call servers that are aware
of enterprise directories to avoid duplication of account management
processes. Users need ’white pages’ 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
administrative processes and ensure information accuracy. The
following design criteria are established for this architecture. The
architecture will:
1) enable endpoint information to be associated with people.
Alternately it enables endpoint information to be associated
with resources such as conference rooms or classrooms;
2) enable online searchable "white pages" where dialling
information (e.g., endpoint addresses) can be found, along with
other "traditional" directory information about a user, such as
name, address, telephone, email, etc.;
3) enable all endpoint information to be stored in a canonical data
source (the Directory), rather than local to the call server, so
that endpoints can be managed through manipulations of an
enterprise directory, rather than by direct entry into the call
server;
4) support the creation of very large-scale distributed
directories. These include white pages "portals" that allow
searching for users across multiple institutional directories.
In this application, each enterprise directory registers itself
with (or is unknowingly discovered by) a directory of
directories that is capable of searching across multiple LDAP
directories;
5) be able to support multiple instances of endpoints per user or
resource;
6) represent endpoints that support more than one protocol, for
example, endpoints that are both H.320 and H.323;
7) 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, or loaded automatically
into the endpoint;
8) be extendible as necessary to allow implementation-specific
attributes to be included;
9) be non-invasive to the enterprise directory, so that support for
multimedia conferencing can be added in a modular fashion
without significant changes to the enterprise directory.
The scope of this Recommendation does not include extensions of
functionality to protocols as defined within the protocols
themselves. It is not the intent of the Recommendation to add
features, but merely to represent existing protocol attributes. The
exception to this case is when functionality is implied by the
directory itself, such as the commPrivate attribute.
4.1.2. Extending the Schema
H.350 object classes may be extended as necessary for specific
implementations. For example, a class may be extended to support
billing reference codes. Extensions to the schema are not considered
as part of the Recommendation and do not signify compliance.
In some cases it may be necessary to extend the H.350 schemas in
order to represent more information than is supported by the
Recommendations. This may be important for developers that implement
proprietary endpoint functionality that needs to be represented by
attributes in the directory. It may also be important for enterprise
applications. For example ’modelNumber’, and ’accountNumber’ are
examples of attributes that are not defined in the Recommendation but
may be useful if implemented. Adding attributes to this architecture
must be done in a way that does not break compatibility with this
Recommendation.
A full discussion of schema design and extension is beyond the scope
of this Recommendation. See IETF RFC 2252 for details. Two basic
approaches to schema extension that do not break compatibility with
this Recommendation, are extension through subclass and extension
through the use of auxiliary classes.
4.1.2.1. Extension Through Subclass
It is possible to create a subclass of an existing predefined object
class in order to add new attributes to it. To create a subclass, a
new object class must be defined, that is a subclass of the existing
one, by indicating in the definition of the new class that the
existing class is its superior. Once the subclass is created, new
attributes can be defined within it.
The following example shows how the commObject class can be
subclassed in order to add an attribute to represent a billing
account and a billing manager.
objectclass ( BillingInfo-OID
NAME ’BillingInfo’
DESC ’Billing Reference Information’
SUP commObject STRUCTURAL
MAY ( BillingAccount $ BillingManager $ )
)
Note that BillingInfo-OID must be replaced by an actual OID. Also
note that, whenever a structural class is extended, its subclass must
also be structural.
The following sample entry shows the newly created attributes. This
example also uses ITU-T Rec. H.350.1 for h323Identity.
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: h323Identity
objectclass: BillingInfo
commUniqueId: 2000
BillingAccount: 0023456
BillingManager: John Smith
Note that this example and approach demonstrate extension of the
general commObject object class, and not any individual H.350.x
classes. If it is desired to extend an H.350.x auxiliary class, then
that should be accomplished through the definition of additional
auxiliary classes that support the desired attributes, as described
in section 4.1.2.2.
4.1.2.2. Extension Through The Use Of Auxiliary Classes
It is possible to add attributes to an LDAP entry by defining an
auxiliary class containing the new attributes and applying those
attributes to instantiated values in the directory. The auxiliary
class will not be subclassed from any existing object class. Note
that it should have the special class top as its superior. The
following example creates the same billing account and billing
manager attributes as the previous example, but does so by defining
them in their own auxiliary class.
objectclass ( BillingInfo-OID
NAME ’BillingInfo’
DESC ’Billing Reference Information’
SUP top AUXILIARY
MAY ( BillingAccount $ BillingManager $ )
)
Note how the superior was changed from commObject to top and the
object class changed from being a structural to auxiliary.
It is recommended that all attributes in the auxiliary class be
optional rather than mandatory. In this way, the auxiliary object
class itself can be associated with an entry regardless of whether
any values for its attributes are present.
The following example shows a sample endpoint that utilizes the new
auxiliary class and attributes. This example also uses H.350.1 for
h323Identity.
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: BillingInfo
commUniqueId: 2000
BillingAccount: 0023456
BillingManager: John Smith
4.1.2.3. Object Identifiers
An attribute’s Object Identifier (OID) is a unique numerical
identifier usually written as a sequence of integers separated by
dots. For example, the OID for the commUniqueId is
0.0.8.350.1.1.2.1.1. All attributes must have an OID. OIDs can be
obtained from anyone who has one and is willing to delegate a portion
of it as an arc, keeping a record of the arc to avoid duplication.
Further, the Internet Assigned Numbers Authority (IANA) gives out
OIDs to any organization that asks.
4.2. commURIObject Definition
Auxiliary object class that contains the commURI attribute. This
attribute is added to a person or resource object to associate one or
more commObject instances with that object. Its values are LDAP URIs
that point to the associated commObjects, for example, to a user’s
H.323 conferencing station and SIP IP phone. Note that multiple
instances of commURI need not point to the same commObject directory.
In fact, each commURI instance could point to an endpoint managed by
a different service provider.
4.2.1. commURIObject
OID: 0.0.8.350.1.1.1.2.1
objectclasses: (0.0.8.350.1.1.1.2.1
NAME ’commURIObject’
DESC ’object that contains the URI attribute type’
SUP top AUXILIARY
MAY ( commURI )
)
4.2.2. commURI
OID: 0.0.8.350.1.1.1.1.1
attributetypes:( 0.0.8.350.1.1.1.1.1
NAME ’commURI’
DESC ’Labeled URI format to point to the distinguished name of the
commUniqueId’
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Application utility class
Standard
Number of values
multi
Definition
Labelled URI containing an LDAP URL identifying the directory
containing the referenced commObject instance. The search filter
specified by this LDAP URL shall specify an equality search of the
commUniqueId attribute of the commObject class.