Permissible values (if controlled)
Notes
Used to find the endpoint of the user in question. The label
field may be used to represent the function of the endpoint, such as
’home IP phone’ or ’desktop video’ for user interface display
purposes.
Note that the label portion of the field may contain spaces as
in the example below showing ’desktop video’.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
commURI:
ldap://directory.acme.com/dc=acme,dc=com??sub?(commUniqueId=bob)
desktop video
4.3. CommObject Definition
Abstraction of video or voice over IP device. The commObject class
permits an endpoint (H.323 endpoint or SIP user agent or other
protocol endpoint) and all their aliases to be represented by a
single entry in a directory. Note that every directory entry should
contain commObject as the entry’s structural object class. That
entry may also contain H.350.x auxiliary classes.
4.3.1. commObject
OID: 0.0.8.350.1.1.2.2.1
objectclasses: (0.0.8.350.1.1.2.2.1
NAME ’commObject’
DESC ’object that contains the Communication attributes’
SUP top STRUCTURAL
MUST commUniqueId
MAY ( commOwner $ commPrivate )
)
4.3.2. commUniqueId
OID: 0.0.8.350.1.1.2.1.1
attributetypes: (0.0.8.350.1.1.2.1.1
NAME ’commUniqueId’
DESC ’To hold the endpoints unique Id’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Application utility class
standard
Number of values
multi
Definition
The endpoint’s unique ID.
Permissible values (if controlled)
Notes
This is the RDN of this object. In practice, there will always
be one and only one commUniqueId for every endpoint. This attribute
uniquely identifies an endpoint in the commObject directory. It must
be unique within that directory, but need not be unique globally.
This attribute has no relationship to the enterprise directory.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
commUniqueId: bob
4.3.3. commOwner
OID: 0.0.8.350.1.1.2.1.2
attributetypes: 0.0.8.350.1.1.2.1.2
NAME ’commOwner’
DESC ’Labeled URI to point back to the original owner’
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 format to point back to the person or resource
object associated with this entry.
Permissible values (if controlled)
Notes
Used as a reverse entry finder of the owner(s). This attribute
may point to groups. Note that this URI can point to a cn, but in
applications where it is desired to bind authentication information
across both the commObject and enterprise directories, it may be
desirable that commOwner points to a dn rather than a cn, thus
uniquely identifying the owner of the commObject.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
commOwner:
ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith)
commOwner: uid=bob,ou=people,dc=acme,dc=com
4.3.4. commPrivate
OID: 0.0.8.350.1.1.2.1.3
attributetypes: (0.0.8.350.1.1.2.1.3
NAME ’commPrivate’
DESC ’To decide whether the entry is visible to world or not’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Application utility class
Standard
Number of values
multi
Definition
To be used by the user and indicate privacy options for an
endpoint, i.e., unlisted number.
Permissible values (if controlled)
Notes
This attribute is defined as Boolean. Future version of this
Recommendation may develop a controlled vocabulary for this
attribute to accommodate multiple types of privacy.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
commPrivate: true
4.4. CommObject LDIF Files
This section contains a schema configuration file for commURIObject
and commObject that can be used to configure an LDAP server to
support these classes.
4.4.1. LDIF for commURIObject
# Communication Object Schema
#
# Schema for Representing Communication Objects in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing Communication
# objects in an LDAP directory [LDAPv3]. It defines schema elements
# to represent a communication object URI [commURIObject].
#
#
#
# .1 = Communication related work
# .1.1 = commURIObject
# .1.1.1 = attributes
# .1.1.2 = objectclass
# .1.1.3 = syntax
#
# Attribute Type Definitions
#
# The following attribute types are defined in this document:
#
# commURI
dn: cn=schema
changetype: modify
#
# if you need to change the definition of an attribute,
# then first delete and re-add in one step
#
# if this is the first time you are adding the commObject
# objectclass using this LDIF file, then you should comment
# out the delete attributetypes modification since this will
# fail. Alternatively, if your ldapmodify has a switch to continue
# on errors, then just use that switch -- if you’re careful
#
delete: attributetypes
attributetypes: (0.0.8.350.1.1.1.1.1 NAME ’commURI’ )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
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 )
-
# Object Class Definitions
#
# The following object classes are defined in this document:
#
# commURIObject
#
# commURIObject
#
# This auxiliary object class represents a URI attribute type
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.1.2.1 NAME ’commURIObject’ )
-
add: objectclasses
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 )
)
-
#
# end of LDIF
#
4.4.2. LDIF for commObject
# Communication Object Schema
#
# Schema for Representing Communication Objects in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing Communication
# objects in an LDAP directory [LDAPv3]. It defines schema elements
# to represent a communication object [commObject].
#
#
# .1 = Communication related work
# .1.2 = commObject
# .1.2.1 = attributes
# .1.2.2 = objectclass
# .1.2.3 = syntax
#
#
# Attribute Type Definitions
#
# The following attribute types are defined in this document:
#
# commUniqueId
# commOwner
# commPrivate
dn: cn=schema
changetype: modify
#
# if you need to change the definition of an attribute,
# then first delete and re-add in one step
#
# if this is the first time you are adding the commObject
# objectclass using this LDIF file, then you should comment
# out the delete attributetypes modification since this will
# fail. Alternatively, if your ldapmodify has a switch to continue
# on errors, then just use that switch -- if you’re careful
#
delete: attributetypes
attributetypes: (0.0.8.350.1.1.2.1.1 NAME ’commUniqueId’ )
attributetypes: (0.0.8.350.1.1.2.1.2 NAME ’commOwner’ )
attributetypes: (0.0.8.350.1.1.2.1.3 NAME ’commPrivate’ )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.2.1.1
NAME ’commUniqueId’
DESC ’To hold the endpoints unique Id’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.2.1.2
NAME ’commOwner’
DESC ’Labeled URI to point back to the original owner’
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.2.1.3
NAME ’commPrivate’
DESC ’To decide whether the entry is visible to world or not’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
# Object Class Definitions
#
# The following object classes are defined in this document:
#
# commObject
#
# commObject
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.2.2.1 NAME ’commObject’ )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.2.2.1
NAME ’commObject’
DESC ’object that contains the Communication attributes’
SUP top STRUCTURAL
MUST commUniqueId
MAY ( commOwner $ commPrivate )
)
-
#
# end of LDIF
#
4.5. H.350 Annex A Indexing Profile
Indexing of attributes is an implementation-specific activity and
depends upon the desired application. Non-indexed attributes can
result in search times sufficiently long to render some applications
unusable. Notably, user and alias lookup should be fast. The Annex
A Indexing Profile describes an indexing configuration for commObject
directories that will be optimized for use in directory of
directories applications. Use of this profile is optional.
commURI: no recommendation
commUniqueId: equality
commOwner: presence
commPrivate: presence
5. H.350.4
The normative text of H.350 is reproduced in this section.
5.1. Scope
This Recommendation describes an LDAP directory services architecture
for multimedia conferencing using SIP. In particular, it defines an
LDAP schema to represent SIP User Agents (UAs) on the network and
associate those endpoints with users.
This Recommendation is intended to supplement the CommObject
directory architecture as discussed in ITU-T Rec. H.350, and not
intended to be used as a stand-alone architecture. The
implementation of this LDAP schema, together with the use of the
H.350 CommObject architecture, facilitates the integration of SIP
User Agents and conferencing devices into existing Enterprise
Directories, thus allowing the user to perform white page lookups and
access clickable dialling supported by SIP devices. The primary
reasons for implementing this schema include those listed in ITU-T
Rec. H.350 (the CommObject class definition) as they apply
specifically to the use of SIP UAs, and to facilitate vendors making
SIP services more readily available to their users.
The scope of this Recommendation includes recommendations for the
architecture to integrate endpoint information for endpoints using
SIP into existing enterprise directories and white pages.
The scope of this Recommendation does not include normative methods
for the use of the LDAP directory itself or the data it contains. The
purpose of the schema is not to represent all possible data elements
in the SIP protocol, but rather to represent the minimal set required
to accomplish the design goals enumerated in ITU-T Rec. H.350.
Note that SIP provides well-defined methods for discovering registrar
addresses and locating users on the network. Some of the attributes
defined here are intended for more trivial or manual implementations
and may not be needed for all applications. For example,
SIPIdentityRegistrarAddress and SIPIdentityAddress may not be needed
for many applications, but are included here for completeness. Thus,
SIPIdentitySIPURI is the primary attribute of interest that will be
served out, especially for white page directory applications.
5.1.1. Extending the schema
The SIPIdentity classes may be extended as necessary for specific
implementations. See the base of ITU-T Rec. H.350 for a discussion
on schema extension.
5.2. Object class definitions
The SIPIdentity object class represents SIP User Agents (UAs). It is
an auxiliary class and is derived from the commObject class, which is
defined in the ITU-T Rec. H.350.
5.2.1. SIPIdentity
OID: 0.0.8.350.1.1.6.2.1
objectclasses: (0.0.8.350.1.1.6.2.1
NAME ’SIPIdentity’
DESC ’SIPIdentity object’
SUP top AUXILIARY
MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $
SIPIdentityProxyAddress $ SIPIdentityUserName $
SIPIdentityPassword $ SIPIdentityServiceLevel $
userSMIMECertificate )
)
5.2.2. SIPIdentitySIPURI
OID: 0.0.8.350.1.1.6.1.1
attributetypes: (0.0.8.350.1.1.6.1.1
NAME ’SIPIdentitySIPURI’
DESC ’Universal Resource Indicator of the SIP UA’
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Application utility class
standard
Number of values
multi
Definition
Uniform Resource Identifier that identifies a communication
resource in SIP. Usually contains a user name and a host name and is
often similar in format to an email address.
Permissible values (if controlled)
Notes
This URI may institute SIP or SIPS (secure). In the event that
SIPS is instituted, the URI must reflect that it is using SIPS as
opposed to SIP. See Examples below.
Semantics
Example applications for which this attribute would be useful
Online representation of most current listing of a user’s
SIP(S) UA.
Example
SIPIdentitySIPURI: sip:alice@foo.com // SIP example
SIPIdentitySIPURI: sip:alice@152.2.158.212 // SIP example
SIPIdentitySIPURI: sips:bob@birmingham.edu // SIPS example
5.2.3. SIPIdentityRegistrarAddress
OID: 0.0.8.350.1.1.6.1.2
attributetypes: (0.0.8.350.1.1.6.1.2
NAME ’SIPIdentityRegistrarAddress’
DESC ’specifies the location of the registrar’
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Application utility class
Standard
Number of values
multi
Definition
Address for the domain to which the server that handles
REGISTER requests and forwarding to the location server for a
particular domain belongs.
Permissible values (if controlled)
Notes
Note that RFC 3261 states that user agents can discover their
registrar address by configuration, using the address-of-record, or
by multicast. The first scenario, by configuration, is noted as out
of scope for RFC 3261. This attribute may be used for the first
scenario. It can be accomplished manually, (e.g., a web page that
displays a user’s correct registrar address) or automatically with
an H.350.4 aware user agent.
Semantics
Example applications for which this attribute would be useful
white pages, a web page that displays a user’s correct
configuration information.
Example (LDIF fragment)
SIPIdentityRegistrarAddress: 152.2.15.22 //IP address example
SIPIdentityRegistrarAddress: sipregistrar.unc.edu //FQDN example
5.2.4. SIPIdentityProxyAddress
OID: 0.0.8.350.1.1.6.1.3
attributetypes: (0.0.8.350.1.1.6.1.3
NAME ’SIPIdentityProxyAddress’
DESC ’Specifies the location of the SIP Proxy’
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Application utility class
Standard
Number of values
multi
Definition
Address which specifies the domain location of SIP proxy within
a domain. RFC 3261 defines the role of the SIP proxy.
Permissible values (if controlled)
Notes
SIP User Agents are not REQUIRED to use a proxy, but will in
many cases.
Semantics
Example applications for which this attribute would be useful
white pages, a web page that displays a user’s correct
configuration information.
Example (LDIF fragment)
SIPIdentityProxyAddress: 172.2.13.234 //IP address example
SIPIdentityProxyAddress: sipproxy.unc.edu //FQDN example
5.2.5. SIPIdentityAddress
OID: 0.0.8.350.1.1.6.1.4
attributetypes: (0.0.8.350.1.1.6.1.4
NAME ’SIPIdentityAddress’
DESC ’IP address or FQDN of the UA’
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Application utility class
standard
Number of values
multi
Definition
Specifies the IP address or fully qualified domain name of the
UA.
Permissible values (if controlled)
Notes
This attribute may be useful for applications in which UA to UA
communication is direct, not involving a proxy or registrar.
Example applications for which this attribute would be useful
A web page that displays a user’s proper user agent
configuration information.
Example (LDIF fragment)
SIPIdentityAddress: 152.2.121.36 // IP address example
SIPIdentityAddress: ipPhone.foo.org // FQDN example
5.2.6. SIPIdentityPassword
OID: 0.0.8.350.1.1.6.1.5
attributetypes: (0.0.8.350.1.1.6.1.5
NAME ’SIPIdentityPassword’
DESC ’The user agent SIP password ’
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Application utility class
Standard
Number of values
multi
Definition
The SIP user agent’s password, used for the HTTP digest
authentication scheme as defined in RFC 2617.
Permissible values (if controlled)
Notes
Because RFC 2069, which was made obsolete by RFC 2617, was used
as the basis for HTTP Digest in RFC 2543, any SIP servers supporting
RFC 2617 must ensure backward compatibility with RFC 2069.
This SIPIdentityUserName, together with SIPIdentityPassword,
are reserved for the purpose of use with Digest Access
Authentication, and not intended for use with Basic Authentication
methods.
LDAP provides one method to store user passwords for reference.
If passwords are stored in LDAP it makes the LDAP server a
particularly valuable target for attack. Implementors are encouraged
to exercise caution and implement appropriate security procedures
such as encryption, access control, and transport layer security for
access to this attribute.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
SIPIdentityPassword: 36zxJmCIB18dM0FVAj
5.2.7. SIPIdentityUserName
OID: 0.0.8.350.1.1.6.1.6
attributetypes: (0.0.8.350.1.1.6.1.6
NAME ’SIPIdentityUserName’
DESC ’The user agent user name.’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Application utility class
Standard
Number of values
multi
Definition
The SIP user agent’s user name, used for the HTTP digest
authentication scheme as defined in RFC 2617.
Permissible values (if controlled)
Notes
Because RFC 2069, which was made obsolete by RFC 2617, was used
as the basis for HTTP Digest Authentication in RFC 2543, any SIP
servers supporting HTTP Digest Authentication as defined in RFC 2617
must ensure backward compatibility with RFC 2069.
This SIPIdentityUserName, together with SIPIdentityPassword,
are reserved for the purpose of use with Digest Access
Authentication, and not intended for use with Basic Authentication
methods.
Note that in many cases the user name will be parsed from the
user@proxy.domain portion of the SIP URI. In that case it may not be
necessary to populate this attribute.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
SIPIdentityUserName: nelkhour
5.2.8. SIPIdentityServiceLevel
OID: 0.0.8.350.1.1.6.1.7
attributetypes: (0.0.8.350.1.1.6.1.7
NAME ’SIPIdentityServiceLevel’
DESC ’To define services that a user can belong to.’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Application utility class
Standard
Number of values
multi
Definition
This describes the level of services a user can belong to.
Permissible values (if controlled)
Notes
This attribute does not represent a data element found in SIP.
SIP itself does not support distinctions in service levels. Instead,
this attribute provides a mechanism for the storage of service level
information directly in LDAP. This mapping allows service providers
to adapt to an existing LDAP directory without changing the values
of the SIPIdentityServiceLevel instances in the directory.
Semantics
Example applications for which this attribute would be useful
Example (LDIF fragment)
SIPIdentityServiceLevel: premium
5.3. SIPIdentity LDIF Files
This clause contains a schema configuration file for SIPIdentity
that can be used to configure an LDAP server to support this class.
# SIPIdentity Object Schema
#
# Schema for representing SIPIdentity Object in an LDAP Directory
#
# Abstract
#
# This Recommendation defines the schema for representing
SIPIdentity
# object in an LDAP directory [LDAPv3]. It defines schema elements
# to represent an SIPIdentity object [SIPIdentity].
#
# .1 = Communication related work
# .1.6 = SIPIdentity
# .1.6.1 = attributes
# .1.6.2 = objectclass
# .1.6.3 = syntax
#
#
#
# Attribute Type Definitions
#
# The following attribute types are defined in this
Recommendation:
#
# SIPIdentitySIPURI
# SIPIdentityRegistrarAddress
# SIPIdentityProxyAddress
# SIPIdentityAddress
# SIPIdentityPassword
# SIPIdentityUserName
# SIPIdentityServiceLevel
dn: cn=schema
changetype: modify
#
# if you need to change the definition of an attribute,
# then first delete and re-add in one step
#
# if this is the first time you are adding the SIPIdentity
# objectclass using this LDIF file, then you should comment
# out the delete attributetypes modification since this will
# fail. Alternatively, if your ldapmodify has a switch to continue
# on errors, then just use that switch -- if you are careful
#
delete: attributetypes
attributetypes: (0.0.8.350.1.1.6.1.1 NAME ’SIPIdentitySIPURI’ )
attributetypes: (0.0.8.350.1.1.6.1.2 NAME ’SIPIdentityRegistrarAddress’)
attributetypes: (0.0.8.350.1.1.6.1.3 NAME ’SIPIdentityProxyAddress’)
attributetypes: (0.0.8.350.1.1.6.1.4 NAME ’SIPIdentityAddress’ )
attributetypes: (0.0.8.350.1.1.6.1.5 NAME ’SIPIdentityPassword’ )
attributetypes: (0.0.8.350.1.1.6.1.6 NAME ’SIPIdentityUserName’ )
attributetypes: (0.0.8.350.1.1.6.1.7 NAME ’SIPIdentityServiceLevel’)
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.6.1.1
NAME ’SIPIdentitySIPURI’
DESC ’Universal Resource Indicator of the SIP UA’
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.6.1.2
NAME ’SIPIdentityRegistrarAddress’
DESC ’specifies the location of the registrar’
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.6.1.3
NAME ’SIPIdentityProxyAddress’
DESC ’Specifies the location of the SIP Proxy’
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.6.1.4
NAME ’SIPIdentityAddress’
DESC ’IP address of the UA’
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes: (0.0.8.350.1.1.6.1.5
NAME ’SIPIdentityPassword’
DESC ’The user agent SIP password ’
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetypes: (0.0.8.350.1.1.6.1.6
NAME ’SIPIdentityUserName’
DESC ’The user agent user name.’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.6.1.7
NAME ’SIPIdentityServiceLevel’
DESC ’To define services that a user can belong to.’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
# Object Class Definitions
#
# The following object class is defined in this Recommendation:
#
# SIPIdentity
#
# SIPIdentity
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.6.2.1 NAME ’SIPIdentity’ )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.6.2.1
NAME ’SIPIdentity’
DESC ’SIPIdentity object’
SUP top AUXILIARY
MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $
SIPIdentityProxyAddress $ SIPIdentityAddress $
SIPIdentityPassword $ SIPIdentityUserName $
SIPIdentityServiceLevel $ userSMIMECertificate )
)
-
#
# end of LDIF
#
5.4. H.350.4 Annex A Indexing profile
Indexing of attributes is an implementation-specific activity and
depends upon the desired application. Non-indexed attributes can