Summary
This Recommendation describes
simple LDAP and X.500 schemas
to represent call forwarding and
call preference information in
an H.350 directory. It is intended
to represent addresses to which
calls should be forwarded in the
case that an endpoint does not
answer a call. It can direct calls
to simple H.320, H.323 or SIP
addresses, or complex forwarding
schemes such as time of day preferences,
web pages, electronic mail or
other applications. Implementers
should review H.350 in detail
before proceeding with this Recommendation.
Keywords
LDAP, Directory Services, H.323, H.320, H.235, SIP
Table of Contents
1 Scope 5
1.1 Extending the Schema 5
2 References 5
2.1 Normative References 5
2.2 Non-Normative References 5
3 Definitions 6
4 Abbreviations 6
5 Conventions 6
6 Object Class Definitions 6
6.1 URI
6.2 Label 7
6.3 callPreferenceURIObject Object Class 7
6.4 callPreferenceURI attribute 7
7 callPreferenceURI LDIF Files 8
8 ASN.1 Representation 10
Annex A: Indexing Profile 12
A Annex A Indexing Profile 12
I Electronic Attachment 13
1 Scope
This Recommendation describes a simple LDAP and X.500 schemas to represent call
forwarding and call preference information in an H.350 directory. It is intended
to represent addresses to which calls should be forwarded in the case that an
endpoint does not answer a call. It can direct calls to simple H.320, H.323
or SIP addresses, or complex forwarding schemes such as time of day preferences,
web pages, electronic mail or other applications. Implementers should review
H.350 in detail before proceeding with this Recommendation.
The scope of this Recommendation does not include normative methods for the
use of the LDAP directory itself or the data it contains.
1.1 Extending the Schema
The callPreferences classes may be extended as necessary for specific implementations.
See the base H.350 document for a discussion on schema extension.
2 References
The following ITU-T Recommendations and other references contain provisions,
which, through reference in this text, constitute provisions of this Recommendation.
At the time of publication, the editions indicated were valid. All Recommendations
and other references are subject to revision; users of this Recommendation are
therefore encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and other references listed below. A list of
the currently valid ITU-T Recommendations is regularly published.
The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation
2.1 Normative References
2.2 Non-Normative References
3 Definitions
The following terms 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.
commObject: An LDAP object class defined in ITU-T H.350 that
represents generic multimedia conferencing endpoints.
endpoint: a logical device that provides video and/or voice
media encoding/decoding, and signalling functions. Examples include:
Note that from the perspective of most signalling protocols, gateways and MCUs are special cases of endpoints.
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.
4 Abbreviations
LDAP: Lightweight Directory Access Protocol as defined in RFC 3377.
5 Conventions
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, subclauses, annexes and appendices refer to those items
within this Recommendation unless another specification is explicitly listed.
6 Object Class Definitions
The callPreferenceURI is a URI consisting of two parts, a URI and a label. Because
it is its own unique object class, the directory can be searched for the presence
of this attribute.
6.1 URI
The URI portion is merely a pointer that points to an address at which can be
found the desired call forwarding address. In the most basic case, the URI will
be an LDAP URI that points to another H.350 entry elsewhere in the same H.350
directory. For example, if an H.323 entry is described by an h323IdentitydialedDigits
attribute, its callPreferenceURI may point to another h323IdentitydialedDigits
attribute elsewhere in the same directory. In this case, the URI is an LDAP
URI.
It is possible to represent more complex call preference behaviour if the URI
points to an object outside the H.350 directory. For example, the URI could
be a mailto: URI of the form mailto:user@host.domain, which would tell a call
server to interpret the desired call preference behaviour to initiative an electronic
mail message. Similarly, a callPreferenceURI could be a URL pointing to a web
page that contained a web form for the calling party to fill out and submit,
or even a game to play. A more advanced scenario may be supported if the URL
target represents an XML document or Call Processing Language script which describes
conditional call preferences.
Note that it is the responsibility of the implementer to ensure that the data
populating the directory is able to be interpreted by the call server that will
be accessing that data.
6.2 Label
The label portion of callPreferenceURI contains an indication of the type of
call forwarding for simple forwarding types. Types not defined here may be supported
by the implementer. The form of the label is
type:argument
where type is a string indicating the type of call forwarding and argument is a string indicating the time in milliseconds after which the call forwarding should occur. The two values are delimited by a colon.
| Type | Type Description |
| b | Forward on busy |
| n | Forward on no answer |
| u | Forward unconditionally |
| f | Forward on destination not found |
Table 6.1
For example, a label of n:4000 indicates that calls should be forwarded
to the target URI after 4 seconds if the called endpoint does not answer. Similary,
f:250 indicates that the call should be forward to the target URI after 250
milliseconds if the destination is not located.
6.3 callPreferenceURIObject Object Class
OID: 0.0.8.350.1.1.8.2.1
objectclasses: (0.0.8.350.1.1.8.2.1
NAME 'callPreferenceURIObject'
DESC 'callPreference object'
SUP top AUXILIARY
MAY ( callPreferenceURI )
)
6.4 callPreferenceURI attribute
OID: 0.0.8.350.1.1.8.1.1
attributetypes: (0.0.8.350.1.1.8.1.1
NAME 'callPreferenceURI'
DESC 'Labeled URI format to point to forwarded address and type of forwarding'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Application utility class
standard
Number of values
multi
Definition
Specifies a URI. The value of the attribute found at the URI target is the address to which calls should be forwarded.
Permissible values (if controlled)
Notes
When representing more than one call forwarding behaviours, use a separate callPreferencesURI for each. One for no answer, another for busy, etc.
Semantics
Example applications for which this attribute would be useful
A user desires that if he does not answer, calls should be forwarded to a different number. However, if the user is busy (i.e. on the phone) then the calling party should be directed to a mailto: link, which will cause an electronic mail application to open on the calling party's application.
Example (LDIF fragment)
callPreferenceURI:
ldap://directory.acme.com/dc=acme,dc=com??sub?(h323IdentitydialedDigits=1234)
b:2000 // Forward on busy after 2 seconds
7 callPreferenceURI LDIF Files
This section contains a schema configuration file for callPreferenceURI that
can be used to configure an LDAP server to support this class.
# callPreferenceURIObject Object Schema
#
# Schema for representing a callPreferenceURIObject Object in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing callPreferenceURIObject
# object in an LDAP directory [LDAPv3]. It defines schema elements
# to represent an callPreferenceURIObject object [callPreferenceURIObject].
#
# .1
= Communication related work
# .1.8
= callPreferenceURIObject
# .1.8.1
= attributes
# .1.8.2
= objectclass
# .1.8.3
= syntax
#
#
#
# Attribute Type Definitions
#
# The following attribute types are defined in this
document:
#
# callPreferenceURI
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 genericIdentity
# 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.8.1.1 NAME 'callPreferenceURI' )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.8.1.1
NAME 'callPreferenceURI'
DESC 'Labeled URI format to point to forwarded address
and type of forwarding'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
# Object Class Definitions
#
# The following object class is defined in this document:
#
# callPreferenceURIObject
#
# callPreferenceURIObject
#
#
delete: objectclasses
objectclasses: (0.0.8.350.1.1.8.2.1 NAME 'callPreferenceURIObject' )
-
add: objectclasses
objectclasses: (0.0.8.350.1.1.8.2.1
NAME 'callPreferenceURIObject'
DESC 'callPreference object'
SUP top AUXILIARY
MAY ( callPreferenceURI )
)
-
#
# end of LDIF
#
8 ASN.1 Representation
H.350.6 elements may be used in an X.500 directory architecture by using the
ASN.1 representation of the object classes defined here.
CallPreferenceURIObject
{ itu-t(0) recommendation(0) h(8)
350 1 cr(1) call(8) module(4)
}
DEFINITIONS ::=
BEGIN
-- callPreferenceURIObject Object Schema
--
Schema for representing a callPreferenceURIObject
Object in an LDAP Directory
-- Abstract
-- This document defines the schema
for representing callPreferenceURIObject
-- object in an LDAP directory
[LDAPv3]. It defines schema elements
-- to represent an callPreferenceURIObject
object [callPreferenceURIObject].
-- .1 = Communication related
work
-- .1.8 = callPreferenceURIObject
-- .1.8.1 = attributes
-- .1.8.2 = objectclass
-- .1.8.3 = syntax
IMPORTS
-- from ITU-T Rec. H.350
h350-cr
FROM CommURI { itu-t(0) recommendation(0)
h(8) 350 1 cr(1) commURI(1) module(4)
}
-- from ITU-T Rec. X.501 | ISO/IEC 9594-2
ATTRIBUTE,
OBJECT-CLASS, top
FROM InformationFramework {joint-iso-itu-t
ds(5) module(1) informationFramework(1)
4}
-- from ITU-T Rec. X.520 | ISO/IEC 9594-6
DirectoryString
{}, caseExactMatch, caseExactSubstringsMatch
FROM SelectedAttributeTypes {joint-iso-itu-t
ds(5) module(1) selectedAttributeTypes(5)
4} ;
--
Attribute Type Definitions
-- The following attribute types
are defined in this document:
-- callPreferenceURI
callPreferenceURI
ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {256}
EQUALITY MATCHING RULE caseExactMatch
SUBSTRINGS MATCHING RULE caseExactSubstringsMatch
ID { at 1 } }
--
Object Class Definitions
-- The following object class
is defined in this document:
--
-- callPreferenceURIObject
-- callPreferenceURIObject
callPreferenceURIObject
OBJECT-CLASS ::= {
SUBCLASS OF { top }
MAY CONTAIN { callPreferenceURI
}
ID { oc 1 } }
call-Id
OBJECT IDENTIFIER ::= { h350-cr
call-Id(8) }
at OBJECT IDENTIFIER ::= { call-Id
at(1) }
oc OBJECT IDENTIFIER ::= { call-Id
oc(2) }
END
-- end of ASN.1
Annex A: Indexing Profile
A 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. The
Annex A Indexing Profile describes
an indexing configuration for
callPreference attributes that
will be optimized for efficient
call server lookup. Use of this
profile is optional.
callPreference: equality
Appendix I Electronic Attachment
I Electronic Attachment
The attached file callPreferenceURI.ldif.txt
contains a text only version of
the LDIF file described in section
7.