draft-ietf-iptel-cpl-09.txt   rfc3880.txt 
Internet Engineering Task Force IPTEL WG Network Working Group J. Lennox
Internet Draft Lennox/Wu/Schulzrinne Request for Comments: 3880 X. Wu
Category: Standards Track H. Schulzrinne
Columbia University Columbia University
draft-ietf-iptel-cpl-09.txt October 2004
April XX, 2004
Expires: October, 2004
CPL: A Language for User Control of Internet Telephony Services
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with Call Processing Language (CPL):
all provisions of Section 10 of RFC2026. A Language for User Control of Internet Telephony Services
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress". Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see Copyright (C) The Internet Society (2004).
http://www.ietf.org/shadow.html.
Abstract Abstract
The Call Processing Language (CPL) is a language that can be used to This document defines the Call Processing Language (CPL), a language
describe and control Internet telephony services. It is designed to to describe and control Internet telephony services. It is designed
be implementable on either network servers or user agent servers. It to be implementable on either network servers or user agents. It is
is meant to be simple, extensible, easily edited by graphical meant to be simple, extensible, easily edited by graphical clients,
clients, and independent of operating system or signalling protocol. and independent of operating system or signalling protocol. It is
It is suitable for running on a server where users may not be allowed suitable for running on a server where users may not be allowed to
to execute arbitrary programs, as it has no variables, loops, or execute arbitrary programs, as it has no variables, loops, or ability
ability to run external programs. to run external programs.
This document is a product of the IP Telephony (IPTEL) working group
of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at
iptel@ietf.org and/or the authors.
Table of Contents Table of Contents
1 Introduction ........................................ 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions of This Document ........................ 4 1.1. Conventions of This Document. . . . . . . . . . . . . . 4
2 Structure of CPL Scripts ............................ 5 2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4
2.1 High-level Structure ................................ 5 2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4
2.2 Abstract Structure of a Call Processing Action ...... 5 2.2. Abstract Structure of a Call Processing Action. . . . . 5
2.3 Location Model ...................................... 6 2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6
2.4 XML Structure ....................................... 6 2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6
3 Script Structure: Overview .......................... 7 3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7
4 Switches ............................................ 9 4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Address Switches .................................... 9 4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9
4.1.1 Usage of "address-switch" with SIP .................. 12 4.1.1. Usage of "address-switch" with SIP. . . . . . . 11
4.2 String Switches ..................................... 13 4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Usage of "string-switch" with SIP ................... 14 4.2.1. Usage of "string-switch" with SIP . . . . . . . 13
4.3 Language Switches ................................... 14 4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14
4.3.1 Usage of "language-switch" with SIP ................. 15 4.3.1. Usage of "language-switch" with SIP . . . . . . 14
4.4 Time Switches ....................................... 15 4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15
4.4.1 iCalendar differences and implementation issues ..... 21 4.4.1. iCalendar differences and implementation
4.5 Priority Switches ................................... 23 issues. . . . . . . . . . . . . . . . . . . . . 20
4.5.1 Usage of "priority-switch" with SIP ................. 23 4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21
5 Location Modifiers .................................. 24 4.5.1. Usage of "priority-switch" with SIP . . . . . . 22
5.1 Explicit Location ................................... 24 5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1 Usage of "location" with SIP ........................ 25 5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23
5.2 Location Lookup ..................................... 25 5.1.1. Usage of "location" with SIP. . . . . . . . . . 23
5.2.1 Usage of "lookup" with SIP .......................... 26 5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24
5.3 Location Removal .................................... 26 5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25
5.3.1 Usage of "remove-location" with SIP ................. 27 5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25
6 Signalling Operations ............................... 27 5.3.1. Usage of "remove-location" with SIP . . . . . . 26
6.1 Proxy ............................................... 27 6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26
6.1.1 Usage of "proxy" with SIP ........................... 30 6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Redirect ............................................ 30 6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29
6.2.1 Usage of "redirect" with SIP ........................ 31 6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Reject .............................................. 31 6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30
6.3.1 Usage of "reject" with SIP .......................... 32 6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30
7 Non-signalling Operations ........................... 32 6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30
7.1 Mail ................................................ 32 7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31
7.1.1 Suggested Content of Mailed Information ............. 33 7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Log ................................................. 34 7.1.1. Suggested Content of Mailed Information . . . . 32
8 Subactions .......................................... 34 7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9 Ancillary Information ............................... 36 8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10 Default Behavior .................................... 36 9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34
11 CPL Extensions ...................................... 37 10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35
12 Examples ............................................ 38 11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1 Example: Call Redirect Unconditional ................ 38 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.2 Example: Call Forward Busy/No Answer ................ 39 12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37
12.3 Example: Call Forward: Redirect and Default ......... 40 12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38
12.4 Example: Call Screening ............................. 41 12.3. Example: Call Forward: Redirect and Default . . . . . . 39
12.5 Example: Priority and Language Routing .............. 42 12.4. Example: Call Screening . . . . . . . . . . . . . . . . 40
12.6 Example: Outgoing Call Screening .................... 43 12.5. Example: Priority and Language Routing. . . . . . . . . 41
12.7 Example: Time-of-day Routing ........................ 44 12.6. Example: Outgoing Call Screening. . . . . . . . . . . . 42
12.8 Example: Location Filtering ......................... 45 12.7. Example: Time-of-day Routing. . . . . . . . . . . . . . 43
12.9 Example: Non-signalling Operations .................. 46 12.8. Example: Location Filtering . . . . . . . . . . . . . . 44
12.10 Example: Hypothetical Extensions .................... 47 12.9. Example: Non-signalling Operations. . . . . . . . . . . 45
12.11 Example: A Complex Example .......................... 49 12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46
13 Security Considerations ............................. 50 12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48
14 IANA Considerations ................................. 51 13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
14.1 URN Sub-Namespace Registration for 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49
urn:ietf:params:xml:ns:cpl ..................................... 51 14.1. URN Sub-Namespace Registration for
14.2 Schema registration ................................. 52 urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49
14.3 MIME Registration ................................... 52 14.2. Schema registration . . . . . . . . . . . . . . . . . . 50
15 Acknowledgments ..................................... 53 14.3. MIME Registration . . . . . . . . . . . . . . . . . . . 50
A An Algorithm for Resolving Time Switches ............ 53 15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51
B Suggested Usage of CPL with H.323 ................... 55 A. An Algorithm for Resolving Time Switches . . . . . . . . . . . 52
B.1 Usage of "address-switch" with H.323 ................ 55 B. Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53
B.2 Usage of "string-switch" with H.323 ................. 57 B.1. Usage of "address-switch" with H.323. . . . . . . . . . 53
B.3 Usage of "language-switch" with H.323 ............... 57 B.2. Usage of "string-switch" with H.323 . . . . . . . . . . 55
B.4 Usage of "priority-switch" with H.323 ............... 57 B.3. Usage of "language-switch" with H.323 . . . . . . . . . 55
B.5 Usage of "location" with H.323 ...................... 57 B.4. Usage of "priority-switch" with H.323 . . . . . . . . . 55
B.6 Usage of "lookup" with H.323 ........................ 57 B.5. Usage of "location" with H.323. . . . . . . . . . . . . 56
B.7 Usage of "remove-location" with H.323 ............... 58 B.6. Usage of "lookup" with H.323. . . . . . . . . . . . . . 56
C The XML Schema for CPL .............................. 58 B.7. Usage of "remove-location" with H.323 . . . . . . . . . 56
D Changes from Earlier Versions ....................... 72 C. The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56
D.1 Changes from Draft -08 .............................. 72 Normative References . . . . . . . . . . . . . . . . . . . . . . . 70
D.2 Changes from Draft -07 .............................. 72 Informative References . . . . . . . . . . . . . . . . . . . . . . 71
D.3 Changes from Draft -06 .............................. 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
D.4 Changes from Draft -05 .............................. 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
D.5 Changes from Draft -04 .............................. 74
D.6 Changes from Draft -03 .............................. 75
D.7 Changes from Draft -02 .............................. 76
D.8 Changes from Draft -01 .............................. 77
D.9 Changes from Draft -00 .............................. 78
E Authors' Addresses .................................. 79
F Normative References ................................ 79
G Informative References .............................. 81
1 Introduction 1. Introduction
The Call Processing Language (CPL) is a language that can be used to The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is not tied to describe and control Internet telephony services. It is not tied to
any particular signalling architecture or protocol; it is anticipated any particular signalling architecture or protocol; it is anticipated
that it will be used with both the Session Initiation Protocol (SIP) that it will be used with both the Session Initiation Protocol (SIP)
[1] and H.323 [16]. [1] and H.323 [16].
CPL is powerful enough to describe a large number of services and CPL is powerful enough to describe a large number of services and
features, but it is limited in power so that it can run safely in features, but it is limited in power so that it can run safely in
Internet telephony servers. The intention is to make it impossible Internet telephony servers. The intention is to make it impossible
for users to do anything more complex (and dangerous) than describing for users to do anything more complex (and dangerous) than describe
Internet telephony services. The language is not Turing-complete, and Internet telephony services. The language is not Turing-complete,
provides no way to write loops or recursion. and provides no way to write loops or recursion.
CPL is also designed to be easily created and edited by graphical CPL is also designed to be easily created and edited by graphical
tools. It is based on the Extensible Markup Language (XML) [2], so tools. It is based on the Extensible Markup Language (XML) [2], so
parsing it is easy and many parsers for it are publicly available. parsing it is easy and many parsers for it are publicly available.
The structure of the language maps closely to its behavior, so an The structure of the language maps closely to its behavior, so an
editor can understand any valid script, even ones written by hand. editor can understand any valid script, even ones written by hand.
The language is also designed so that a server can easily confirm The language is also designed so that a server can easily confirm the
scripts' validity at the time they are delivered to it, rather that validity of a script when the server receives it, rather than
discovering them while a call is being processed. discovering problems while a call is being processed.
Implementations of CPL are expected to take place both in Internet Implementations of CPL are expected to take place both in Internet
telephony servers and in advanced clients; both can usefully process telephony servers and in advanced clients; both can usefully process
and direct users' calls. This document primarily addresses the usage and direct users' calls. This document primarily addresses the usage
in servers. A mechanism will be needed to transport scripts between in servers. A mechanism will be needed to transport scripts between
clients and servers; this document does not describe such a clients and servers; this document does not describe such a
mechanism, but related documents will. mechanism, but related documents will.
The framework and requirements for the CPL architecture are described The framework and requirements for the CPL architecture are described
in RFC 2824, "Call Processing Language Framework and Requirements" in RFC 2824, "Call Processing Language Framework and Requirements"
[17]. [17].
1.1 Conventions of This Document 1.1. Conventions of This Document
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
indicate requirement levels for compliant CPL implementations. [3] and indicate requirement levels for compliant CPL
implementations.
Some paragraphs are indented, like this; they give Some paragraphs are indented, like this; they give motivations of
motivations of design choices, advice to implementors, or design choices, advice to implementors, or thoughts on future
thoughts on future development of or extensions to CPL. development of or extensions to CPL. They are not essential to
They are not essential to the specification of the the specification of the language, and are non-normative.
language, and are non-normative.
2 Structure of CPL Scripts 2. Structure of CPL Scripts
2.1 High-level Structure 2.1. High-level Structure
A CPL script consists of two types of information: ancillary A CPL script consists of two types of information: ancillary
information about the script, and call processing actions. information about the script, and call processing actions.
A call processing action is a structured tree that describes the A call processing action is a structured tree that describes the
operations and decisions a telephony signalling server performs on a operations and decisions a telephony signalling server performs on a
call set-up event. There are two types of call processing actions: call set-up event. There are two types of call processing actions:
top-level actions and subactions. Top-level actions are actions that top-level actions and subactions. Top-level actions are actions that
are triggered by signalling events that arrive at the server. Two are triggered by signalling events that arrive at the server. Two
top-level actions are defined: "incoming", the action performed when top-level actions are defined: "incoming", the action performed when
a call arrives whose destination is the owner of the script; and a call arrives whose destination is the owner of the script, and
"outgoing", the action performed when a call arrives whose originator "outgoing", the action performed when a call arrives whose originator
is the owner of the script. Subactions are actions which can be is the owner of the script.
called from other actions. CPL forbids subactions from being called
recursively: see Section 8. Subactions are actions which can be called from other actions. CPL
forbids subactions from being called recursively: see Section 8.
Ancillary information is information which is necessary for a server Ancillary information is information which is necessary for a server
to correctly process a script, but which does not directly describe to correctly process a script, but which does not directly describe
any operations or decisions. Currently, no ancillary information is any operations or decisions. Currently, no ancillary information is
defined, but the section is reserved for use by extensions. defined, but the section is reserved for use by extensions.
2.2 Abstract Structure of a Call Processing Action 2.2. Abstract Structure of a Call Processing Action
Abstractly, a call processing action is described by a collection of Abstractly, a call processing action is described by a collection of
nodes, which describe operations that can be performed or decisions nodes that describe operations that can be performed or decisions
that can be made. A node may have several parameters, which specify that can be made. A node may have several parameters, which specify
the precise behavior of the node; they usually also have outputs, the precise behavior of the node; they usually also have outputs,
which depend on the result of the decision or action. which depend on the result of the decision or action.
For a graphical representation of a CPL action, see Figure 1. Nodes For a graphical representation of a CPL action, see Figure 1. Nodes
and outputs can be thought of informally as boxes and arrows; CPL is and outputs can be thought of informally as boxes and arrows; CPL is
designed so that actions can be conveniently edited graphically using designed so that actions can be conveniently edited graphically using
this representation. Nodes are arranged in a tree, starting at a this representation. Nodes are arranged in a tree, starting at a
single root node; outputs of nodes are connected to additional nodes. single root node; outputs of nodes are connected to additional nodes.
When an action is run, the action or decision described by the When an action is run, the action or decision described by the
action's top-level node is performed; based on the result of that action's top-level node is performed; based on the result of that
node, the server follows one of the node's outputs, and the node, the server follows one of the node's outputs, and the
subsequent node it points to is performed; this process continues subsequent node it points to is performed; this process continues
until a node with no specified outputs is reached. Because the graph until a node with no specified outputs is reached. Because the graph
is acyclic, this will occur after a bounded and predictable number of is acyclic, this will occur after a bounded and predictable number of
nodes are visited. nodes are visited.
If an output to a node does not point to another node, it indicates If an output to a node does not point to another node, it indicates
that the CPL server should perform a node- or protocol-specific that the CPL server should perform a node- or protocol-specific
action. Some nodes have specific default behavior associated with action. Some nodes have specific default behavior associated with
them; for others, the default behavior is implicit in the underlying them; for others, the default behavior is implicit in the underlying
signalling protocol, or can be configured by the administrator of the signalling protocol, or can be configured by the administrator of the
server. For further details on this, see Section 10. server. For further details on this, see Section 10.
_________________ ___________________ ________ busy _________________ ___________________ ________ busy
| Address-switch | | location | | proxy |--------\ | Address-switch | | location | | proxy |--------\
Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout| Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout|
| subfield: host | / | example.com | | 10s |--------| | subfield: host | / | example.com | | 10s |--------|
|-----------------|/ |___________________| | | failure| |-----------------|/ |___________________| | | failure|
| subdomain-of: | |________|--------| | subdomain-of: | |________|--------|
| example.com | | | example.com | |
|-----------------| ___________________________________________/ |-----------------| ___________________________________________/
| otherwise | /........................................ | otherwise | /........................................
skipping to change at page 6, line 28 skipping to change at page 6, line 25
|_________________| \. ____________________ . |_________________| \. ____________________ .
->| location | __________ . ->| location | __________ .
. | url: sip:jones@ | | redirect | . . | url: sip:jones@ | | redirect | .
. | voicemail. |->| | . . | voicemail. |->| | .
. | example.com | |__________| . . | example.com | |__________| .
. |____________________| . . |____________________| .
........................................ ........................................
Figure 1: Sample CPL Action: Graphical Version Figure 1: Sample CPL Action: Graphical Version
2.3 Location Model 2.3. Location Model
For flexibility, one piece of information necessary for CPL is not For flexibility, one piece of information necessary for CPL is not
given as node parameters: the set of locations to which a call is to given as node parameters: the set of locations to which a call is to
be directed. Instead, this set of locations is stored as an implicit be directed. Instead, this set of locations is stored as an implicit
global variable throughout the execution of a processing action (and global variable throughout the execution of a processing action (and
its subactions). This allows locations to be retrieved from external its subactions). This allows locations to be retrieved from external
sources, filtered, and so forth, without requiring general language sources, filtered, and so forth, without requiring general language
support for such operations (which could harm the simplicity and support for such operations (which could harm the simplicity and
tractability of understanding the language). The specific operations tractability of understanding the language). The specific operations
which add, retrieve, or filter location sets are given in Section 5. which add, retrieve, or filter location sets are given in Section 5.
For the incoming top-level call processing action, the location set For the incoming top-level call processing action, the location set
is initialized to the empty set. For the outgoing action, it is is initialized to the empty set. For the outgoing action, it is
initialized to the destination address of the call. initialized to the destination address of the call.
2.4 XML Structure 2.4. XML Structure
Syntactically, CPL scripts are represented by XML documents. XML is Syntactically, CPL scripts are represented by XML documents. XML is
thoroughly specified by the XML specification [2], and implementors thoroughly specified by the XML specification [2], and implementors
of this specification should be familiar with that document, but as a of this specification should be familiar with that document.
brief overview, XML consists of a hierarchical structure of tags; However, as a brief overview, XML consists of a hierarchical
each tag can have a number of attributes. It is visually and structure of tags; each tag can have a number of attributes. It is
structurally very similar to HTML [18], as both languages are visually and structurally very similar to HTML [18], as both
simplifications of the earlier and larger standard SGML [19]. languages are simplifications of the earlier and larger standard SGML
[19].
See Figure 2 for the XML document corresponding to the graphical See Figure 2 for the XML document corresponding to the graphical
representation of the CPL script in Figure 1. Both nodes and outputs representation of the CPL script in Figure 1. Both nodes and outputs
in CPL are represented by XML tags; parameters are represented by XML in CPL are represented by XML tags; parameters are represented by XML
tag attributes. Typically, node tags contain output tags, and vice- tag attributes. Typically, node tags contain output tags, and vice-
versa (with a few exceptions: see Sections 5.1, 5.3, 7.1, and 7.2). versa (with a few exceptions: see Sections 5.1, 5.3, 7.1, and 7.2).
The connection between the output of a node and another node is The connection between the output of a node and another node is
represented by enclosing the tag representing the pointed-to node represented by enclosing the tag representing the pointed-to node
inside the tag for the outer node's output. Convergence (several inside the tag for the outer node's output. Convergence (several
outputs pointing to a single node) is represented by subactions, outputs pointing to a single node) is represented by subactions,
discussed further in Section 8. discussed further in Section 8.
The higher-level structure of a CPL script is represented by tags The higher-level structure of a CPL script is represented by tags
corresponding to each piece of ancillary information, subactions, and corresponding to each piece of ancillary information, subactions, and
top-level actions, in order. This higher-level information is all top-level actions, in order. This higher-level information is all
enclosed in a special tag "cpl", the outermost tag of the XML enclosed in a special tag "cpl", the outermost tag of the XML
document. document.
A complete XML Schema for CPL is provided in Appendix C. The A complete XML Schema for CPL is provided in Appendix C. The
remainder of the main sections of this document describe the remainder of the main sections of this document describe the
semantics of CPL, while giving its syntax informally. For the formal semantics of CPL, while giving its syntax informally. For the formal
syntax, please see the appendix. syntax, please see the appendix.
3 Script Structure: Overview 3. Script Structure: Overview
As mentioned, a CPL script consists of ancillary information, As mentioned, a CPL script consists of ancillary information,
subactions, and top-level actions. The full syntax of the "cpl" node subactions, and top-level actions. The full syntax of the "cpl" node
is given in Figure 3. is given in Figure 3.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<redirect /> <redirect />
</location> </location>
skipping to change at page 8, line 45 skipping to change at page 8, line 26
Parameters: None Parameters: None
Sub-tags: "ancillary" See Section 9 Sub-tags: "ancillary" See Section 9
"subaction" See Section 8 "subaction" See Section 8
"outgoing" Top-level actions to take on this user's "outgoing" Top-level actions to take on this user's
outgoing calls outgoing calls
"incoming" Top-level actions to take on this user's "incoming" Top-level actions to take on this user's
incoming calls incoming calls
Figure 3: Syntax of the top-level "cpl" tag Figure 3: Syntax of the top-level "cpl" tag
Call processing actions, both top-level actions and sub-actions, Call processing actions, both top-level actions and subactions,
consist of a tree of nodes and outputs. Nodes and outputs are both consist of a tree of nodes and outputs. Nodes and outputs are both
described by XML tags. There are four categories of CPL nodes: described by XML tags. There are four categories of CPL nodes:
switches, which represent choices a CPL script can make; location switches, which represent choices a CPL script can make, location
modifiers, which add or remove locations from the location set; modifiers, which add or remove locations from the location set,
signalling operations, which cause signalling events in the signalling operations, which cause signalling events in the
underlying protocol; and non-signalling operations, which trigger underlying protocol, and non-signalling operations, which trigger
behavior which does not effect the underlying protocol. behavior which does not effect the underlying protocol.
4 Switches 4. Switches
Switches represent choices a CPL script can make, based on either Switches represent choices a CPL script can make, based on either
attributes of the original call request or items independent of the attributes of the original call request or items independent of the
call. call.
All switches are arranged as a list of conditions that can match a All switches are arranged as a list of conditions that can match a
variable. Each condition corresponds to a node output; the output variable. Each condition corresponds to a node output; the output
points to the next node to execute if the condition was true. The points to the next node that should be executed if the condition is
conditions are tried in the order they are presented in the script; true. The conditions are tried in the order they are presented in
the output corresponding to the first node to match is taken. the script; the output corresponding to the first node to match is
taken.
There are two special switch outputs that apply to every switch type. There are two special switch outputs that apply to every switch type.
The output "not-present", which MAY occur anywhere in the list of The output "not-present", which MAY occur anywhere in the list of
outputs, is true if the variable the switch was to match was not outputs, is true if the variable the switch was to match was not
present in the original call setup request. (In this document, this present in the original call setup request. (In this document, this
is sometimes described by saying that the information is "absent".) is sometimes described by saying that the information is "absent".)
The output "otherwise", which MUST be the last output specified if it The output "otherwise", which MUST be the last output specified if it
is present, matches if no other condition matched. is present, matches if no other condition matched.
If no condition matches and no "otherwise" output was present in the If no condition matches and no "otherwise" output was present in the
script, the default script behavior is taken. See Section 10 for more script, the default script behavior is taken. See Section 10 for
information on this. more information on this.
Switches MAY contain no outputs. They MAY contain only an "otherwise" Switches MAY contain no outputs. They MAY only contain an
output. "otherwise" output.
Such switches are not particularly useful, but might be Such switches are not particularly useful, but might be created by
created by tools which automatically generate CPL scripts. tools which automatically generate CPL scripts.
4.1 Address Switches 4.1. Address Switches
Address switches allow a CPL script to make decisions based on one of Address switches allow a CPL script to make decisions based on one of
the addresses present in the original call request. They are the addresses present in the original call request. They are
summarized in Figure 4. summarized in Figure 4.
Node: "address-switch" Node: "address-switch"
Outputs: "address" Specific addresses to match Outputs: "address" Specific addresses to match
Parameters: "field" "origin", "destination", Parameters: "field" "origin", "destination",
or "original-destination" or "original-destination"
"subfield" "address-type", "user", "host", "subfield" "address-type", "user", "host",
"port", "tel", or "display" "port", "tel", or "display"
(also: "password" and "alias-type") (also: "password" and "alias-type")
Output: "address" Output: "address"
Parameters: "is" Exact match Parameters: "is" Exact match
"contains" Substring match (for "display" only) "contains" Substring match (for "display" only)
"subdomain-of" Sub-domain match (for "host", "tel") "subdomain-of" Sub-domain match (for "host", "tel")
Figure 4: Syntax of the "address-switch" node Figure 4: Syntax of the "address-switch" node
Address switches have two node parameters: "field", and "subfield". Address switches have two node parameters: "field" and "subfield".
The mandatory "field" parameter allows the script to specify which The mandatory "field" parameter allows the script to specify which
address is to be considered for the switch: either the call's origin address is to be considered for the switch: either the call's origin
address (field "origin"), its current destination address (field address (field "origin"), its current destination address (field
"destination"), or its original destination (field "original- "destination"), or its original destination (field "original-
destination"), the destination the call had before any earlier destination"), the destination the call had before any earlier
forwarding was invoked. Servers MAY define additional field values. forwarding was invoked. Servers MAY define additional field values.
The optional "subfield" specifies what part of the address is to be The optional "subfield" specifies which part of the address is to be
considered. The possible subfield values are: "address-type", "user", considered. The possible subfield values are: "address-type",
"host", "port", "tel", and "display". Additional subfield values MAY "user", "host", "port", "tel", and "display". Additional subfield
be defined for protocol-specific values. (The subfield "password" is values MAY be defined for protocol-specific values. (The subfield
defined for SIP in Section 4.1.1; the subfield "alias-type" is "password" is defined for SIP in Section 4.1.1; the subfield "alias-
defined for H.323 in Appendix B.1.) If no subfield is specified, the type" is defined for H.323 in Appendix B.1.) If no subfield is
"entire" address is matched; the precise meaning of this is defined specified, the "entire" address is matched; the precise meaning of
for each underlying signalling protocol. Servers MAY define this is defined for each underlying signalling protocol. Servers MAY
additional subfield values. define additional subfield values.
The subfields are defined as follows: The subfields are defined as follows:
address-type This indicates the type of the underlying address; address-type: This indicates the type of the underlying address,
i.e., the URI scheme, if the address can be represented by i.e., the URI scheme, if the address can be represented by a
a URI. The types specifically discussed by this document URI. The types specifically discussed by this document are
are "sip", "tel", and "h323". The address type is not "sip", "tel", and "h323". The address type is not case-
case-sensitive. It has a value for all defined address sensitive. It has a value for all defined address types.
types.
user This subfield of the address indicates, for e-mail style user: This subfield of the address indicates, for e-mail style
addresses, the user part of the address. For telephone addresses, the user part of the address. For a telephone
number style address, it includes the subscriber number. number style address, it includes the subscriber number.
This subfield is case-sensitive; it may be absent. This subfield is case-sensitive; it may be absent.
host This subfield of the address indicates the Internet host host: This subfield of the address indicates the Internet host
name or IP address corresponding to the address, in host name or IP address corresponding to the address, in host
name, IPv4, or IPv6 [4] textual representation format. name, IPv4, or IPv6 [4] textual representation format. Host
Host names are compared as strings. IP addresses are names are compared as strings. IP addresses are compared
compared numerically. (In particular, the presence or numerically. (In particular, the presence or location of an
location of an IPv6 :: omitted-zero-bits block is not IPv6 :: omitted-zero-bits block is not significant for
significant for matching purposes.) Host names are never matching purposes.) Host names are never equal to IP
equal to IP addresses -- no DNS resolution is performed. addresses -- no DNS resolution is performed. IPv4 addresses
IPv4 addresses are never equal to IPv6 addresses, even if are never equal to IPv6 addresses, even if the IPv6 address
the IPv6 address is a v4-in-v6 embedding. This subfield is is a v4-in-v6 embedding. This subfield is not case
not case sensitive, and may be absent. sensitive, and may be absent.
For host names only, subdomain matching is supported with For host names only, subdomain matching is supported with
the "subdomain-of" match operator. The "subdomain-of" the "subdomain-of" match operator. The "subdomain-of"
operator ignores leading dots in the hostname or match operator ignores leading dots in the hostname or match
pattern, if any. pattern, if any.
port This subfield indicates the TCP or UDP port number of the port: This subfield indicates the TCP or UDP port number of the
address, numerically in decimal format. It is not case address, numerically, in decimal format. It is not case
sensitive, as it MUST only contain decimal digits. Leading sensitive, as it MUST only contain decimal digits. Leading
zeros are ignored. zeros are ignored.
tel This subfield indicates a telephone subscriber number, if tel: This subfield indicates a telephone subscriber number, if
the address contains such a number. It is not case the address contains such a number. It is not case
sensitive (the telephone numbers may contain the symbols sensitive (telephone numbers may contain the symbols 'A',
`A' `B' `C' and `D'), and may be absent. It may be matched 'B', 'C', or 'D'), and may be absent. It may be matched
using the "subdomain-of" match operator. Punctuation and using the "subdomain-of" match operator. Punctuation and
separator characters in telephone numbers are discarded. separator characters in telephone numbers are discarded.
display This subfield indicates a "display name" or user-visible display: This subfield indicates a "display name" or user-visible
name corresponding to an address. It is a Unicode string, name corresponding to an address. It is a Unicode string,
and is matched using the case-insensitive algorithm and is matched using the case-insensitive algorithm
described in Section 4.2. The "contains" operator may be described in Section 4.2. The "contains" operator may be
applied to it. It may be absent. applied to it. It may be absent.
For any completely unknown subfield, the server MAY reject the script For any completely unknown subfield, the server MAY reject the script
at the time it is submitted with an indication of the problem; if a at the time it is submitted with an indication of the problem; if a
script with an unknown subfield is executed, the server MUST consider script with an unknown subfield is executed, the server MUST consider
the "not-present" output to be the valid one. the "not-present" output to be the valid one.
The "address" output tag may take exactly one of three possible The "address" output tag may take exactly one of three possible
parameters, indicating the kind of matching allowed. parameters, indicating the kind of matching allowed.
is An output with this match operator is followed if the is: An output with this match operator is followed if the
subfield being matched in the "address-switch" exactly subfield being matched in the "address-switch" exactly
matches the argument of the operator. It may be used for matches the argument of the operator. It may be used for
any subfield, or for the entire address if no subfield was any subfield, or for the entire address if no subfield was
specified. specified.
subdomain-of This match operator applies only for the subfields subdomain-of: This match operator applies only for the subfields
"host" and "tel". In the former case, it matches if the "host" and "tel". In the former case, it matches if the
hostname being matched is a subdomain of the domain given hostname being matched is a subdomain of the domain given in
in the argument of the match operator; thus, subdomain- the argument of the match operator; thus, subdomain-
of="example.com" would match the hostnames "example.com", of="example.com" would match the hostnames "example.com",
"research.example.com", and "research.example.com", and
"zaphod.sales.internal.example.com". IP addresses may be "zaphod.sales.internal.example.com". IP addresses may be
given as arguments to this operator; however, they only given as arguments to this operator; however, they only
match exactly. In the case of the "tel" subfield, the match exactly. In the case of the "tel" subfield, the
output matches if the telephone number being matched has a output matches if the telephone number being matched has a
prefix that matches the argument of the match operator; prefix that matches the argument of the match operator;
subdomain-of="1212555" would match the telephone number "1 subdomain-of="1212555" would match the telephone number "1
212 555 1212." 212 555 1212."
contains This match operator applies only for the subfield contains: This match operator applies only for the subfield
"display". The output matches if the display name being "display". The output matches if the display name being
matched contains the argument of the match as a substring. matched contains the argument of the match as a substring.
4.1.1 Usage of "address-switch" with SIP 4.1.1. Usage of "address-switch" with SIP
For SIP, the "origin" address corresponds to the address in the For SIP, the "origin" address corresponds to the address in the
"From" header; "destination" corresponds to the "Request-URI"; and "From" header, "destination" corresponds to the "Request-URI", and
"original-destination" corresponds to the "To" header. "original-destination" corresponds to the "To" header.
The "display" subfield of an address is the display-name part of the The "display" subfield of an address is the display-name part of the
address, if it is present. Because of SIP's syntax, the "destination" address, if it is present. Because of SIP's syntax, the
address field will never have a "display" subfield. "destination" address field will never have a "display" subfield.
The "address-type" subfield of an address is the URI scheme of that The "address-type" subfield of an address is the URI scheme of that
address. Other address fields depend on that "address-type". address. Other address fields depend on that "address-type".
For SIP URIs, the "user", "host", and "port" subfields correspond to For SIP URIs, the "user", "host", and "port" subfields correspond to
the "user," "host," and "port" elements of the URI syntax. (Note the "user," "host," and "port" elements of the URI syntax. (Note
that, following the definitions of RFC 3261 [1], a SIP URI which does that, following the definitions of RFC 3261 [1], a SIP URI which does
not specify a port is not the same as an explicit port 5060; the not specify a port is not the same as an explicit port 5060; the
former is indicated by an absent port subfield.) The "tel" subfield former is indicated by an absent port subfield.) The "tel" subfield
is defined to be the "user" part of the URI, with visual separators is defined to be the "user" part of the URI, with visual separators
stripped, if the "user=phone" parameter is given to the URI, or if stripped, if the "user=phone" parameter is given to the URI, or if
the server is otherwise configured to recognize the user part as a the server is otherwise configured to recognize the user part as a
telephone number. An additional subfield, "password" is defined to telephone number. An additional subfield, "password", is defined to
correspond to the "password" element of the SIP URI, and is case- correspond to the "password" element of the SIP URI, and is case-
sensitive. However, use of this field is NOT RECOMMENDED for general sensitive. However, use of this field is NOT RECOMMENDED for general
security reasons. security reasons.
For tel URLs, the "tel" and "user" subfields are the subscriber name; For tel URLs, the "tel" and "user" subfields are the subscriber name;
in the former case, visual separators are stripped. The "host" and in the former case, visual separators are stripped. The "host" and
"port" subfields are both not present. "port" subfields are both not present.
For h323 URLs, subfields MAY be set according to the scheme described For h323 URLs, subfields MAY be set according to the scheme described
in Appendix B. in Appendix B.
For other URI schemes, only the "address-type" subfield is defined by For other URI schemes, only the "address-type" subfield is defined by
this specification; servers MAY set other pre-defined subfields, or this specification; servers MAY set other pre-defined subfields, or
MAY support additional subfields. MAY support additional subfields.
If no subfield is specified for addresses in SIP messages, the string If no subfield is specified for addresses in SIP messages, the string
matched is the URI part of the address. For "is" matches, standard matched is the URI part of the address. For "is" matches, standard
SIP URI matching rules are used; for "contains" matches, the URI is SIP URI matching rules are used; for "contains" matches, the URI is
used verbatim. used verbatim.
4.2 String Switches 4.2. String Switches
String switches allow a CPL script to make decisions based on free- String switches allow a CPL script to make decisions based on free-
form strings present in a call request. They are summarized in Figure form strings present in a call request. They are summarized in
5. Figure 5.
Node: "string-switch" Node: "string-switch"
Outputs: "string" Specific string to match Outputs: "string" Specific string to match
Parameters: "field" "subject", "organization", Parameters: "field" "subject", "organization",
"user-agent", or "display" "user-agent", or "display"
Output: "string" Output: "string"
Parameters: "is" Exact match Parameters: "is" Exact match
"contains" Substring match "contains" Substring match
Figure 5: Syntax of the "string-switch" node Figure 5: Syntax of the "string-switch" node
String switches have one node parameter: "field". The mandatory
String switches have one node parameter: "field". The mandatory
"field" parameter specifies which string is to be matched. "field" parameter specifies which string is to be matched.
String switches are dependent on the call signalling protocol being String switches are dependent on the call signalling protocol being
used. used.
Five fields are defined, listed below. The value of each of these Four fields are defined and listed below. The value of each of these
fields, except as specified, is a free-form Unicode string with no fields is a free-form Unicode string with no other structure defined.
other structure defined.
"subject" The subject of the call. subject: The subject of the call.
"organization" The organization of the originator of the call. organization: The organization of the originator of the call.
"user-agent" The name of the program or device with which the user-agent: The name of the program or device with which the call
call request was made. request was made.
"display" Free-form text associated with the call, intended to display: Free-form text associated with the call, intended to be
be displayed to the recipient, with no other semantics displayed to the recipient, with no other semantics defined
defined by the signalling protocol. by the signalling protocol.
Strings are matched as case-insensitive Unicode strings, in the Strings are matched as case-insensitive Unicode strings, in the
following manner. First, strings are canonicalized to the following manner. First, strings are canonicalized to the
"Compatibility Composition" (KC) form, as specified in Unicode "Compatibility Composition" (KC) form, as specified in Unicode
Technical Report 15 [5]. Then, strings are compared using locale- Standard Annex #15 [5]. Then, strings are compared using locale-
insensitive caseless mapping, as specified in Unicode Technical insensitive caseless mapping, as specified in Unicode Standard Annex
Report 21 [6]. #21 [6].
Code to perform the first step, in Java and Perl, is Code to perform the first step, in Java and Perl, is available;
available; see the links from Annex E of UTR 15 [5]. The see the links from Annex 5 of UAX 15 [5]. The case-insensitive
case-insensitive string comparison in the Java standard string comparison in the Java standard class libraries already
class libraries already performs the second step; other performs the second step; other Unicode-aware libraries should be
Unicode-aware libraries should be similar. similar.
The output tag of string matching is named "string", and has a The output tag of string matching is named "string", and has a
mandatory argument, one of "is" or "contains", indicating whole- mandatory argument, one of "is" or "contains", indicating whole-
string match or substring match, respectively. string match or substring match, respectively.
4.2.1 Usage of "string-switch" with SIP 4.2.1. Usage of "string-switch" with SIP
For SIP, the fields "subject", "organization", and "user-agent" For SIP, the fields "subject", "organization", and "user-agent"
correspond to the SIP header fields with the same name. These are correspond to the SIP header fields with the same name. These are
used verbatim as they appear in the message. used verbatim as they appear in the message.
The field "display" is not used, and is never present. The field "display" is not used, and is never present.
4.3 Language Switches 4.3. Language Switches
Language switches allow a CPL script to make decisions based on the Language switches allow a CPL script to make decisions based on the
languages in which the originator of the call wishes to communicate. languages in which the originator of the call wishes to communicate.
They are summarized in Figure 6. They are summarized in Figure 6.
Node: "language-switch" Node: "language-switch"
Outputs: "language" Specific string to match Outputs: "language" Specific string to match
Parameters: None Parameters: None
Output: "language" Output: "language"
Parameters: "matches" Match if the given language matches a Parameters: "matches" Match if the given language
language-range of the call. matches a language-range of the
call.
Figure 6: Syntax of the "language-switch" node Figure 6: Syntax of the "language-switch" node
Language switches take no parameters. Language switches take no parameters.
The "language" output takes one parameter, "matches". The value of The "language" output takes one parameter, "matches". The value of
the parameter is a language-tag, as defined in RFC 3066 [7]. The the parameter is a language-tag, as defined in RFC 3066 [7]. The
caller may have specified a set of language-ranges, also as defined caller may have specified a set of language-ranges, also as defined
in RFC 3066. The CPL server checks each language-tag specified by the in RFC 3066. The CPL server checks each language-tag specified by
script against the language-ranges specified in the request. the script against the language-ranges specified in the request.
See RFC 3066 for the details of how language-ranges match language- See RFC 3066 for the details of how language-ranges match language-
tags. Briefly, a language-range matches a language-tag if it exactly tags. Briefly, a language-range matches a language-tag if it exactly
equals the tag, or if it exactly equals a prefix of the tag such that equals the tag, or if it exactly equals a prefix of the tag such that
the first character following the prefix is "-". the first character following the prefix is "-".
If the caller specified the special language-range "*", it is ignored If the caller specified the special language-range "*", it is ignored
for the purpose of matching. Languages with a "q" value of 0 are also for the purpose of matching. Languages with a "q" value of 0 are
ignored. also ignored.
This switch MAY be not-present. This switch MAY be not-present.
4.3.1 Usage of "language-switch" with SIP 4.3.1. Usage of "language-switch" with SIP
The language-ranges for the "language-switch" switch are obtained The language-ranges for the "language-switch" switch are obtained
from the SIP "Accept-Language" header field. The switch is not- from the SIP "Accept-Language" header field. The switch is not-
present if the initial SIP request did not contain this header field. present if the initial SIP request did not contain this header field.
Note that because of CPL's first-match semantics in Note that because of CPL's first-match semantics in switches, "q"
switches, "q" values other than 0 of the "Accept-Language" values other than 0 of the "Accept-Language" header fields are
header fields are ignored. ignored.
4.4 Time Switches 4.4. Time Switches
Time switches allow a CPL script to make decisions based on the time Time switches allow a CPL script to make decisions based on the time
and/or date the script is being executed. They are summarized in and/or date the script is being executed. They are summarized in
Figure 7. Figure 7.
Time switches are independent of the underlying signalling protocol. Time switches are independent of the underlying signalling protocol.
Node: "time-switch" Node: "time-switch"
Outputs: "time" Specific time to match Outputs: "time" Specific time to match
Parameters: "tzid" RFC 2445 Time Zone Identifier Parameters: "tzid" RFC 2445 Time Zone Identifier
"tzurl" RFC 2445 Time Zone URL "tzurl" RFC 2445 Time Zone URL
Output: "time" Output: "time"
skipping to change at page 16, line 41 skipping to change at page 15, line 46
"wkst" First day of the work week "wkst" First day of the work week
"bysetpos" List of values within "bysetpos" List of values within
set of events specified set of events specified
Figure 7: Syntax of the "time-switch" node Figure 7: Syntax of the "time-switch" node
Time switches are based closely on the specification of recurring Time switches are based closely on the specification of recurring
intervals of time in the Internet Calendaring and Scheduling Core intervals of time in the Internet Calendaring and Scheduling Core
Object Specification (iCalendar COS), RFC 2445 [8]. Object Specification (iCalendar COS), RFC 2445 [8].
This allows CPL scripts to be generated automatically from This allows CPL scripts to be generated automatically from
calendar books. It also allows us to re-use the extensive calendar books. It also allows us to re-use the extensive
existing work specifying time intervals. existing work specifying time intervals.
If future standards-track documents are published that update or If future standards-track documents are published that update or
obsolete RFC 2445, any changes or clarifications those documents make obsolete RFC 2445, any changes or clarifications those documents make
to recurrence handling apply to CPL time-switches as well. to recurrence handling apply to CPL time-switches as well.
An algorithm to determine whether an instant falls within a given An algorithm to determine whether an instant falls within a given
recurrence is given in Appendix A. recurrence is given in Appendix A.
The "time-switch" tag takes two optional parameters, "tzid" and The "time-switch" tag takes two optional parameters, "tzid" and
"tzurl", both of which are defined in RFC 2445 (Sections 4.8.3.1 and "tzurl", both of which are defined in RFC 2445 (Sections 4.8.3.1 and
4.8.3.5 respectively). The "tzid" is the identifying label by which a 4.8.3.5 respectively). The "tzid" is the identifying label by which
time zone definition is referenced. If it begins with a forward slash a time zone definition is referenced. If it begins with a forward
(solidus), it references a to-be-defined global time zone registry; slash (solidus), it references a to-be-defined global time zone
otherwise it is locally-defined at the server. The "tzurl" gives a registry; otherwise it is locally-defined at the server. The "tzurl"
network location from which an up-to-date VTIMEZONE definition for gives a network location from which an up-to-date VTIMEZONE
the timezone can be retrieved. definition for the timezone can be retrieved.
While "tzid" labels that do not begin with a forward slash are While "tzid" labels that do not begin with a forward slash are
locally defined, it is RECOMMENDED that servers support at least the locally defined, it is RECOMMENDED that servers support at least the
naming scheme used by Olson Time Zone database [9]. Examples of naming scheme used by the Olson Time Zone database [9]. Examples of
timezone databases that use the Olson scheme are the zoneinfo files timezone databases that use the Olson scheme are the zoneinfo files
on most Unix-like systems, and the standard Java TimeZone class. on most Unix-like systems, and the standard Java TimeZone class.
Servers SHOULD resolve "tzid" and "tzurl" references to time zone Servers SHOULD resolve "tzid" and "tzurl" references to time zone
definitions at the time the script is uploaded. They MAY periodically definitions at the time the script is uploaded. They MAY
refresh these resolutions to obtain the most up-to-date definition of periodically refresh these resolutions to obtain the most up-to-date
a time zone. If a "tzurl" becomes invalid, servers SHOULD remember definition of a time zone. If a "tzurl" becomes invalid, servers
the most recent valid data retrieved from the URL. SHOULD remember the most recent valid data retrieved from the URL.
If a script is uploaded with a "tzid" and "tzurl" which the CPL If a script is uploaded with a "tzid" and "tzurl" which the CPL
server does not recognize or cannot resolve, it SHOULD diagnose and server does not recognize or cannot resolve, it SHOULD diagnose and
reject this at script upload time. If neither "tzid" nor "tzurl" are reject this at script upload time. If neither "tzid" nor "tzurl" are
present, all non-UTC times within this time switch should be present, all non-UTC times within this time switch should be
interpreted as being "floating" times, i.e. that they are specified interpreted as being "floating" times, i.e., that they are specified
in the local timezone of the CPL server. in the local timezone of the CPL server.
Because of daylight-savings-time changes over the course of Because of daylight-savings-time changes over the course of a
a year, it is necessary to specify time switches in a given year, it is necessary to specify time switches in a given
timezone. UTC offsets are not sufficient, or a time-of-day timezone. UTC offsets are not sufficient, or a time-of-day
routing rule which held between 9 am and 5 pm in the routing rule which held between 9 am and 5 pm in the eastern
eastern United States would start holding between 8 am and United States would start holding between 8 am and 4 pm at the end
4 pm at the end of October. of October.
Authors of CPL servers should be careful to handle correctly the Authors of CPL servers should be careful to handle correctly the
intervals when local time is discontinuous, at the beginning or end intervals when local time is discontinuous, at the beginning or end
of daylight-savings time. Note especially that some times may occur of daylight-savings time. Note especially that some times may occur
more than once when clocks are set back. The algorithm in Appendix A more than once when clocks are set back. The algorithm in Appendix A
is believed to handle this correctly. is believed to handle this correctly.
Time nodes specify a list of periods during which their output should Time nodes specify a list of periods during which their output should
be taken. They have two required parameters: "dtstart", which be taken. They have two required parameters: "dtstart", which
specifies the beginning of the first period of the list, and exactly specifies the beginning of the first period of the list, and exactly
one of "dtend" or "duration", which specify the ending time or the one of "dtend" or "duration", which specify the ending time or the
duration of the period, respectively. The "dtstart" and "dtend" duration of the period, respectively. The "dtstart" and "dtend"
parameters are formatted as iCalendar COS DATE-TIME values, as parameters are formatted as iCalendar COS DATE-TIME values, as
specified in Section 4.3.5 of RFC 2445 [8]. Because time zones are specified in Section 4.3.5 of RFC 2445 [8]. Because time zones are
specified in the top-level "time-switch" tag, only forms 1 or 2 specified in the top-level "time-switch" tag, only forms 1 or 2
(floating or UTC times) can be used. The "duration" parameter is (floating or UTC times) can be used. The "duration" parameter is
given as an iCalendar COS DURATION parameter, as specified in section given as an iCalendar COS DURATION parameter, as specified in section
4.3.6 of RFC 2445. Both the DATE-TIME and the DURATION syntaxes are 4.3.6 of RFC 2445. Both the DATE-TIME and the DURATION syntaxes are
subsets of the corresponding syntaxes from ISO 8601 [20]. subsets of the corresponding syntaxes from ISO 8601 [20].
For a recurring interval, the "duration" parameter MUST be small For a recurring interval, the "duration" parameter MUST be small
enough such that subsequent intervals do not overlap. For non- enough such that subsequent intervals do not overlap. For non-
recurring intervals, durations of any positive length are permitted. recurring intervals, durations of any positive length are permitted.
Zero-length and negative-length durations are not allowed. Zero-length and negative-length durations are not allowed.
If no other parameters are specified, a time node indicates only a If no other parameters are specified, a time node indicates only a
single period of time. More complicated sets periods intervals are single period of time. More complicated sets of period intervals are
constructed as recurrences. A recurrence is specified by including constructed as recurrences. A recurrence is specified by including
the "freq" parameter, which indicates the type of recurrence rule. the "freq" parameter, which indicates the type of recurrence rule.
Parameters other than "dtstart", "dtend", and "duration" SHOULD NOT Parameters other than "dtstart", "dtend", and "duration" SHOULD NOT
be specified unless "freq" is present, though CPL servers SHOULD be specified unless "freq" is present, though CPL servers SHOULD
accept scripts with such parameters present, and ignore the other accept scripts with such parameters present, and ignore the other
parameters. parameters.
The "freq" parameter takes one of the following values: "secondly", The "freq" parameter takes one of the following values: "secondly",
to specify repeating periods based on an interval of a second or to specify repeating periods based on an interval of a second or
more; "minutely", to specify repeating periods based on an interval more, "minutely", to specify repeating periods based on an interval
of a minute or more; "hourly", to specify repeating periods based on of a minute or more, "hourly", to specify repeating periods based on
an interval of an hour or more; "daily", to specify repeating periods an interval of an hour or more, "daily", to specify repeating periods
based on an interval of a day or more; "weekly", to specify repeating based on an interval of a day or more, "weekly", to specify repeating
periods based on an interval of a week or more; "monthly", to specify periods based on an interval of a week or more, "monthly", to specify
repeating periods based on an interval of a month or more; and repeating periods based on an interval of a month or more, and
"yearly", to specify repeating periods based on an interval of a year "yearly", to specify repeating periods based on an interval of a year
or more. These values are not case-sensitive. or more. These values are not case-sensitive.
The "interval" parameter contains a positive integer representing how The "interval" parameter contains a positive integer representing how
often the recurrence rule repeats. The default value is "1", meaning often the recurrence rule repeats. The default value is "1", meaning
every second for a "secondly" rule, every minute for a "minutely" every second for a "secondly" rule, every minute for a "minutely"
rule, every hour for an "hourly" rule, every day for a "daily" rule, rule, every hour for an "hourly" rule, every day for a "daily" rule,
every week for a "weekly" rule, every month for a "monthly" rule and every week for a "weekly" rule, every month for a "monthly" rule, and
every year for a "yearly" rule. every year for a "yearly" rule.
The "until" parameter defines an iCalendar COS DATE or DATE-TIME The "until" parameter defines an iCalendar COS DATE or DATE-TIME
value which bounds the recurrence rule in an inclusive manner. If the value which bounds the recurrence rule in an inclusive manner. If
value specified by "until" is synchronized with the specified the value specified by "until" is synchronized with the specified
recurrence, this date or date-time becomes the last instance of the recurrence, this date or date-time becomes the last instance of the
recurrence. If specified as a date-time value, then it MUST be recurrence. If specified as a date-time value, then it MUST be
specified in an UTC time format. If not present, and the "count" specified in UTC time format. If not present, and the "count"
parameter is not also present, the recurrence is considered to repeat parameter is not also present, the recurrence is considered to repeat
forever. forever.
The "count" parameter defines the number of occurrences at which to The "count" parameter defines the number of occurrences at which to
range-bound the recurrence. The "dtstart" parameter counts as the range-bound the recurrence. The "dtstart" parameter counts as the
first occurrence. The "until" and "count" parameters MUST NOT occur first occurrence. The "until" and "count" parameters MUST NOT occur
in the same "time" output. in the same "time" output.
The "bysecond" parameter specifies a comma-separated list of seconds The "bysecond" parameter specifies a comma-separated list of seconds
within a minute. Valid values are 0 to 59. The "byminute" parameter within a minute. Valid values are 0 to 59. The "byminute" parameter
specifies a comma-separated list of minutes within an hour. Valid specifies a comma-separated list of minutes within an hour. Valid
values are 0 to 59. The "byhour" parameter specifies a comma- values are 0 to 59. The "byhour" parameter specifies a comma-
separated list of hours of the day. Valid values are 0 to 23. separated list of hours of the day. Valid values are 0 to 23.
The "byday" parameter specifies a comma-separated list of days of the The "byday" parameter specifies a comma-separated list of days of the
week. "MO" indicates Monday; "TU" indicates Tuesday; "WE" indicates week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates
Wednesday; "TH" indicates Thursday; "FR" indicates Friday; "SA" Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA"
indicates Saturday; "SU" indicates Sunday. These values are not indicates Saturday, and "SU" indicates Sunday. These values are not
case-sensitive. case-sensitive.
Each "byday" value can also be preceded by a positive (+n) or Each "byday" value can also be preceded by a positive (+n) or
negative (-n) integer. If present, this indicates the nth occurrence negative (-n) integer. If present, this indicates the nth occurrence
of the specific day within the "monthly" or "yearly" recurrence. For of the specific day within the "monthly" or "yearly" recurrence. For
example, within a "monthly" rule, +1MO (or simply 1MO) represents the example, within a "monthly" rule, +1MO (or simply 1MO) represents the
first Monday within the month, whereas -1MO represents the last first Monday within the month, whereas -1MO represents the last
Monday of the month. If an integer modifier is not present, it means Monday of the month. If an integer modifier is not present, it means
all days of this type within the specified frequency. For example, all days of this type within the specified frequency. For example,
within a "monthly" rule, MO represents all Mondays within the month. within a "monthly" rule, MO represents all Mondays within the month.
The "bymonthday" parameter specifies a comma-separated list of days The "bymonthday" parameter specifies a comma-separated list of days
of the month. Valid values are 1 to 31 or -31 to -1. For example, -10 of the month. Valid values are 1 to 31 or -31 to -1. For example,
represents the tenth to the last day of the month. -10 represents the tenth to the last day of the month.
The "byyearday" parameter specifies a comma-separated list of days of The "byyearday" parameter specifies a comma-separated list of days of
the year. Valid values are 1 to 366 or -366 to -1. For example, -1 the year. Valid values are 1 to 366 or -366 to -1. For example, -1
represents the last day of the year (December 31st) and -306 represents the last day of the year (December 31st) and -306
represents the 306th to the last day of the year (March 1st). represents the 306th to the last day of the year (March 1st).
The "byweekno" parameter specifies a comma-separated list of ordinals The "byweekno" parameter specifies a comma-separated list of ordinals
specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. specifying weeks of the year. Valid values are 1 to 53 or -53 to -1.
This corresponds to weeks according to week numbering as defined in This corresponds to weeks according to week numbering as defined in
ISO 8601 [20]. A week is defined as a seven day period, starting on ISO 8601 [20]. A week is defined as a seven day period, starting on
the day of the week defined to be the week start (see "wkst"). Week the day of the week defined to be the week start (see "wkst"). Week
number one of the calendar year is the first week which contains at number one of the calendar year is the first week which contains at
least four (4) days in that calendar year. This parameter is only least four (4) days in that calendar year. This parameter is only
valid for "yearly" rules. For example, 3 represents the third week of valid for "yearly" rules. For example, 3 represents the third week
the year. of the year.
Note: Assuming a Monday week start, week 53 can only occur Note: Assuming a Monday week start, week 53 can only occur when
when Thursday is January 1 or if it is a leap year and January 1 is a Thursday or, for leap years, if January 1 is a
Wednesday is January 1. Wednesday.
The "bymonth" parameter specifies a comma-separated list of months of The "bymonth" parameter specifies a comma-separated list of months of
the year. Valid values are 1 to 12. the year. Valid values are 1 to 12.
The "wkst" parameter specifies the day on which the work week starts. The "wkst" parameter specifies the day on which the work week starts.
Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This is Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This
significant when a "weekly" recurrence has an interval greater than is significant when a "weekly" recurrence has an interval greater
1, and a "byday" parameter is specified. This is also significant in than 1, and a "byday" parameter is specified. This is also
a "yearly" recurrence when a "byweekno" parameter is specified. The significant in a "yearly" recurrence when a "byweekno" parameter is
default value is "MO", following ISO 8601 [20]. specified. The default value is "MO", following ISO 8601 [20].
The "bysetpos" parameter specifies a comma-separated list of values The "bysetpos" parameter specifies a comma-separated list of values
which corresponds to the nth occurrence within the set of events which corresponds to the nth occurrence within the set of events
specified by the rule. Valid values are 1 to 366 or -366 to -1. It specified by the rule. Valid values are 1 to 366 or -366 to -1. It
MUST only be used in conjunction with another byxxx parameter. For MUST only be used in conjunction with another byxxx parameter. For
example "the last work day of the month" could be represented as: example, "the last work day of the month" could be represented as:
<time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR" <time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR"
bysetpos="-1"> bysetpos="-1">
Each "bysetpos" value can include a positive (+n) or negative (-n) Each "bysetpos" value can include a positive (+n) or negative (-n)
integer. If present, this indicates the nth occurrence of the integer. If present, this indicates the nth occurrence of the
specific occurrence within the set of events specified by the rule. specific occurrence within the set of events specified by the rule.
If byxxx parameter values are found which are beyond the available If byxxx parameter values are found which are beyond the available
scope (ie, bymonthday="30" in February), they are simply ignored. scope (i.e., bymonthday="30" in February), they are simply ignored.
Byxxx parameters modify the recurrence in some manner. Byxxx rule Byxxx parameters modify the recurrence in some manner. Byxxx rule
parts for a period of time which is the same or greater than the parts for a period of time which is the same or greater than the
frequency generally reduce or limit the number of occurrences of the frequency generally reduce or limit the number of occurrences of the
recurrence generated. For example, freq="daily" bymonth="1" reduces recurrence generated. For example, freq="daily" bymonth="1" reduces
the number of recurrence instances from all days (if the "bymonth" the number of recurrence instances from all days (if the "bymonth"
parameter is not present) to all days in January. Byxxx parameters parameter is not present) to all days in January. Byxxx parameters
for a period of time less than the frequency generally increase or for a period of time less than the frequency generally increase or
expand the number of occurrences of the recurrence. For example, expand the number of occurrences of the recurrence. For example,
freq="yearly" bymonth="1,2" increases the number of days within the freq="yearly" bymonth="1,2" increases the number of days within the
yearly recurrence set from 1 (if "bymonth" parameter is not present) yearly recurrence set from 1 (if "bymonth" parameter is not present)
to 2. to 2.
If multiple Byxxx parameters are specified, then after evaluating the If multiple Byxxx parameters are specified, then after evaluating the
specified "freq" and "interval" parameters, the Byxxx parameters are specified "freq" and "interval" parameters, the Byxxx parameters are
applied to the current set of evaluated occurrences in the following applied to the current set of evaluated occurrences in the following
order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday", order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday",
"byhour", "byminute", "bysecond" and "bysetpos"; then "count" and "byhour", "byminute", "bysecond", and "bysetpos"; then "count" and
"until" are evaluated. "until" are evaluated.
Here is an example of evaluating multiple Byxxx parameters. Here is an example of evaluating multiple Byxxx parameters.
<time dtstart="19970105T083000" duration="10M" <time dtstart="19970105T083000" duration="10M"
freq="yearly" interval="2" bymonth="1" byday="SU" freq="yearly" interval="2" bymonth="1" byday="SU"
byhour="8,9" byminute="30"> byhour="8,9" byminute="30">
First, the interval="2" would be applied to freq="yearly" to arrive First, the interval="2" would be applied to freq="yearly" to arrive
at "every other year." Then, bymonth="1" would be applied to arrive at "every other year." Then, bymonth="1" would be applied to arrive
at "every January, every other year." Then, byday="SU" would be at "every January, every other year." Then, byday="SU" would be
applied to arrive at "every Sunday in January, every other year." applied to arrive at "every Sunday in January, every other year."
Then, byhour="8,9" would be applied to arrive at "every Sunday in Then, byhour="8,9" would be applied to arrive at "every Sunday in
January at 8 AM and 9 AM, every other year." Then, byminute="30" January at 8 AM and 9 AM, every other year." Then, byminute="30"
would be applied to arrive at "every Sunday in January at 8:30 AM and would be applied to arrive at "every Sunday in January at 8:30 AM and
9:30 AM, every other year." Then the second is derived from "dtstart" 9:30 AM, every other year." Then the second is derived from
to end up in "every Sunday in January from 8:30:00 AM to 8:40:00 AM, "dtstart" to end up in "every Sunday in January from 8:30:00 AM to
and from and 9:30:00 AM to 9:40:00 AM, every other year." Similarly, 8:40:00 AM, and from and 9:30:00 AM to 9:40:00 AM, every other year."
if the "byminute", "byhour", "byday", "bymonthday" or "bymonth" Similarly, if the "byminute", "byhour", "byday", "bymonthday", or
parameter were missing, the appropriate minute, hour, day or month "bymonth" parameter were missing, the appropriate minute, hour, day,
would have been retrieved from the "dtstart" parameter. or month would have been retrieved from the "dtstart" parameter.
The iCalendar COS RDATE, EXRULE and EXDATE recurrence rules are not The iCalendar COS RDATE, EXRULE, and EXDATE recurrence rules are not
specifically mapped to components of the time-switch node. Equivalent specifically mapped to components of the time-switch node.
functionality to the exception rules can be attained by using the Equivalent functionality to the exception rules can be attained by
ordering of switch rules to exclude times using earlier rules; using the ordering of switch rules to exclude times using earlier
equivalent functionality to the additional-date RDATE rules can be rules; equivalent functionality to the additional-date RDATE rules
attained by using "sub" nodes (see Section 8) to link multiple can be attained by using "sub" nodes (see Section 8) to link multiple
outputs to the same subsequent node. outputs to the same subsequent node.
The "not-present" output is never true for a time switch. However, it The "not-present" output is never true for a time switch. However,
MAY be included, to allow switch processing to be more regular. it MAY be included to allow switch processing to be more regular.
4.4.1 iCalendar differences and implementation issues 4.4.1. iCalendar Differences and Implementation Issues
(This sub-sub-section is non-normative.) (This sub-sub-section is non-normative.)
The specification of recurring events in this section is identical The specification of recurring events in this section is identical
(except for syntax and formatting issues) to that of RFC 2445 [8], (except for syntax and formatting issues) to that of RFC 2445 [8],
with only one additional restriction. That one restriction is that with only one additional restriction. That one restriction is that
consecutive instances of recurrence intervals may not overlap. consecutive instances of recurrence intervals may not overlap.
It was a matter of some debate, during the design of CPL, whether the It was a matter of some debate, during the design of CPL, whether the
entire iCalendar COS recurrence specification should be included in entire iCalendar COS recurrence specification should be included in
CPL, or whether only a subset should be included. It was eventually CPL, or whether only a subset should be included. It was eventually
decided that compatibility between the two protocols was of primary decided that compatibility between the two protocols was of primary
importance. This imposes some additional implementation issues on importance. This imposes some additional implementation issues on
implementors of CPL servers. implementors of CPL servers.
It does not appear to be possible to determine, in constant time, It does not appear to be possible to determine, in constant time,
whether a given instant of time falls within one of the intervals whether a given instant of time falls within one of the intervals
defined by a full iCalendar COS recurrence. The primary concerns are defined by a full iCalendar COS recurrence. The primary concerns are
as follows: as follows:
o The "count" parameter cannot be checked in constant running o The "count" parameter cannot be checked in constant running
time, since it requires that the server enumerate all time, since it requires that the server enumerate all
recurrences from "dtstart" to the present time, in order to recurrences from "dtstart" to the present time, in order to
determine whether the current recurrence satisfies the determine whether the current recurrence satisfies the
parameter. However, a server can expand a "count" parameter parameter. However, a server can expand a "count" parameter
once, off-line, to determine the date of the last recurrence. once, off-line, to determine the date of the last recurrence.
This date can then be treated as a virtual "until" parameter This date can then be treated as a virtual "until" parameter
for the server's internal processing. for the server's internal processing.
o Similarly, the "bysetpos" parameter requires that the server o Similarly, the "bysetpos" parameter requires that the server
enumerate all instances of the occurrence from the start of enumerate all instances of the occurrence from the start of the
the current recurrence set until the present time. This current recurrence set until the present time. This requires
requires somewhat more complex pre-processing, but generally, somewhat more complex pre-processing, but generally, a single
a single recurrence with a "bysetpos" parameter can be split recurrence with a "bysetpos" parameter can be split up into
up into several recurrences without them. several recurrences without them.
o Finally, constant running time of time switches also requires o Finally, constant running time of time switches also requires
that a candidate starting time for a recurrence can be that a candidate starting time for a recurrence can be
established quickly and uniquely, to check whether it established quickly and uniquely, to check whether it satisfies
satisfies the other restrictions. This requires that a the other restrictions. This requires that a recurrence's
recurrence's duration not be longer than its repetition duration not be longer than its repetition interval, so that a
interval, so that a given instant cannot fall within several given instant cannot fall within several consecutive potential
consecutive potential repetitions of the recurrence. The repetitions of the recurrence. The restriction that
restriction that consecutive intervals not overlap partially consecutive intervals not overlap partially satisfies this
satisfies this condition, but does not fully ensure it. Again, condition, but does not fully ensure it. Again, to some extent
to some extent pre-processing can help resolve this. pre-processing can help resolve this.
The algorithm given in Appendix A runs in constant time after these The algorithm given in Appendix A runs in constant time after these
pre-processing steps. pre-processing steps.
Servers ought to check that recurrence rules do not create any absurd Servers ought to check that recurrence rules do not create any absurd
run-time or memory requirements, and reject those that do, just as run-time or memory requirements, and reject those that do, just as
they ought to check that CPL scripts in general are not absurdly they ought to check that CPL scripts in general are not absurdly
large. large.
4.5 Priority Switches 4.5. Priority Switches
Priority switches allow a CPL script to make decisions based on the Priority switches allow a CPL script to make decisions based on the
priority specified for the original call. They are summarized in priority specified for the original call. They are summarized in
Figure 8. They are dependent on the underlying signalling protocol. Figure 8. They are dependent on the underlying signalling protocol.
Node: "priority-switch" Node: "priority-switch"
Outputs: "priority" Specific priority to match Outputs: "priority" Specific priority to match
Parameters: None Parameters: None
Output: "priority" Output: "priority"
Parameters: "less" Match if priority is less Parameters: "less" Match if priority is less
than that specified than that specified
"greater" Match if priority is greater "greater" Match if priority is greater
than that specified than that specified
"equal" Match if priority is equal "equal" Match if priority is equal
to that specified to that specified
Figure 8: Syntax of the "priority-switch" node Figure 8: Syntax of the "priority-switch" node
Priority switches take no parameters. Priority switches take no parameters.
The "priority" tag takes one of the three parameters "greater", The "priority" tag takes one of the three parameters "greater",
"less", and "equal". The values of these parameters are one of the "less", or "equal". The values of these parameters are one of the
following priorities: in decreasing order, "emergency", "urgent", following priorities: in decreasing order, "emergency", "urgent",
"normal", and "non-urgent". These values are matched in a case- "normal", and "non-urgent". These values are matched in a case-
insensitive manner. Outputs with the "less" parameter are taken if insensitive manner. Outputs with the "less" parameter are taken if
the priority of the call is less than the priority given in the the priority of the call is less than the priority given in the
argument; and so forth. argument, and so forth.
If no priority is specified in a message, the priority is considered If no priority is specified in a message, the priority is considered
to be "normal". If an unknown priority is specified in the call, it to be "normal". If an unknown priority is specified in the call, it
is considered to be equivalent to "normal" for the purposes of is considered to be equivalent to "normal" for the purposes of
"greater" and "less" comparisons, but it is compared literally for "greater" and "less" comparisons, but it is compared literally for
"equal" comparisons. "equal" comparisons.
Since every message has a priority, the "not-present" output is never Since every message has a priority, the "not-present" output is never
true for a priority switch. However, it MAY be included, to allow true for a priority switch. However, it MAY be included, to allow
switch processing to be more regular. switch processing to be more regular.
4.5.1 Usage of "priority-switch" with SIP 4.5.1. Usage of "priority-switch" with SIP
The priority of a SIP message corresponds to the "Priority" header in The priority of a SIP message corresponds to the "Priority" header in
the initial "INVITE" message. the initial "INVITE" message.
5 Location Modifiers 5. Location Modifiers
The abstract location model of CPL is described in Section 2.3. The The abstract location model of CPL is described in Section 2.3. The
behavior of several of the signalling operations (defined in Section behavior of several of the signalling operations (defined in Section
6) is dependent on the current location set specified. Location nodes 6) is dependent on the current location set specified. Location
add or remove locations from the location set. nodes add or remove locations from the location set.
There are three types of location nodes defined. Explicit locations There are three types of location nodes defined. Explicit locations
add literally-specified locations to the current location set; add literally-specified locations to the current location set,
location lookups obtain locations from some outside source; and location lookups obtain locations from some outside source, and
location filters remove locations from the set, based on some location filters remove locations from the set, based on some
specified criteria. specified criteria.
5.1 Explicit Location 5.1. Explicit Location
Explicit location nodes specify a location literally. Their syntax is Explicit location nodes specify a location literally. Their syntax
described in Figure 9. is described in Figure 9.
Explicit location nodes are dependent on the underlying signalling Explicit location nodes are dependent on the underlying signalling
protocol. protocol.
Node: "location" Node: "location"
Outputs: None (Next node follows directly) Outputs: None (Next node follows directly)
Next node: Any node Next node: Any node
Parameters: "url" URL of address to add to location set Parameters: "url" URL of address to add to location set
"priority" Priority of this location (0.0-1.0) "priority" Priority of this location (0.0-1.0)
"clear" Whether to clear the location set before "clear" Whether to clear the location set before
adding the new value adding the new value
Figure 9: Syntax of the "location" node Figure 9: Syntax of the "location" node
Explicit location nodes have three node parameters. The mandatory Explicit location nodes have three node parameters. The mandatory
"url" parameter's value is the URL of the address to add to the "url" parameter's value is the URL of the address to add to the
location set. Only one address may be specified per location node; location set. Only one address may be specified per location node;
multiple locations may be specified by cascading these nodes. multiple locations may be specified by cascading these nodes.
The optional "priority" parameter specifies a priority for the The optional "priority" parameter specifies a priority for the
location. Its value is a floating-point number between 0.0 and 1.0. location. Its value is a floating-point number between 0.0 and 1.0.
If it is not specified, the server SHOULD assume a default priority If it is not specified, the server SHOULD assume a default priority
of 1.0. The optional "clear" parameter specifies whether the location of 1.0. The optional "clear" parameter specifies whether the
set should be cleared before adding the new location to it. Its value location set should be cleared before adding the new location to it.
can be "yes" or "no", with "no" as the default. Its value can be "yes" or "no", with "no" as the default.
Basic location nodes have only one possible result, since there is no Basic location nodes have only one possible result, since there is no
way that they can fail. (If a basic location node specifies a way that they can fail. (If a basic location node specifies a
location which isn't supported by the underlying signalling protocol, location which isn't supported by the underlying signalling protocol,
the script server SHOULD detect this and report it to the user at the the script server SHOULD detect this and report it to the user at the
time the script is submitted.) Therefore, their XML representations time the script is submitted.) Therefore, their XML representations
do not have explicit output tags; the <location> tag directly do not have explicit output tags; the <location> tag directly
contains another node. contains another node.
5.1.1 Usage of "location" with SIP 5.1.1. Usage of "location" with SIP
All SIP locations are represented as URLs, so the locations specified All SIP locations are represented as URLs, so the locations specified
in "location" tags are interpreted directly. in "location" tags are interpreted directly.
5.2 Location Lookup 5.2. Location Lookup
Locations can also be specified up through external means, through Locations can also be specified up through external means, through
the use of location lookups. The syntax of these tags is given in the use of location lookups. The syntax of these tags is given in
Figure 10. Figure 10.
Location lookup is dependent on the underlying signalling protocol. Location lookup is dependent on the underlying signalling protocol.
Node: "lookup" Node: "lookup"
Outputs: "success" Next node if lookup was successful Outputs: "success" Next node if lookup was successful
"notfound" Next node if lookup found no addresses "notfound" Next node if lookup found no addresses
"failure" Next node if lookup failed "failure" Next node if lookup failed
Parameters: "source" Source of the lookup Parameters: "source" Source of the lookup
"timeout" Time to try before giving up on the lookup "timeout" Time to try before giving up on the lookup
skipping to change at page 25, line 45 skipping to change at page 24, line 34
Output: "notfound" Output: "notfound"
Parameters: none Parameters: none
Output: "failure" Output: "failure"
Parameters: none Parameters: none
Figure 10: Syntax of the "lookup" node Figure 10: Syntax of the "lookup" node
Location lookup nodes have one mandatory parameter and two optional Location lookup nodes have one mandatory parameter and two optional
parameters. The mandatory parameter is "source", the source of the parameters. The mandatory parameter is "source", the source of the
lookup. This can either be a URI, or a non-URI value. If the value of lookup. This can either be a URI, or a non-URI value. If the value
"source" is a URI, it indicates a location which the CPL server can of "source" is a URI, it indicates a location which the CPL server
query to obtain an object with the text/uri-list media type (see the can query to obtain an object with the text/uri-list media type (see
IANA registration of this type, which also appears in RFC 2483 [10]). the IANA registration of this type, which also appears in RFC 2483
The query is performed verbatim, with no additional information (such [10]). The query is performed verbatim, with no additional
as URI parameters) added. The server adds the locations contained in information (such as URI parameters) added. The server adds the
this object to the location set. locations contained in this object to the location set.
CPL servers MAY refuse to allow URI-based sources for location CPL servers MAY refuse to allow URI-based sources for location
queries for some or all URI schemes. In this case, they SHOULD reject queries for some or all URI schemes. In this case, they SHOULD
the script at script upload time. reject the script at script upload time.
There has been discussion of having CPL servers add URI There has been discussion of having CPL servers add URI parameters
parameters to the location request, so that (for instance) to the location request, so that (for instance) CGI scripts could
CGI scripts could be used to resolve them. However, the be used to resolve them. However, the consensus was that this
consensus was that this should be a CPL extension, not a should be a CPL extension, not a part of the base specification.
part of the base specification.
Non-URL sources indicate a source not specified by a URL which the Non-URL sources indicate a source not specified by a URL which the
server can query for addresses to add to the location set. The only server can query for addresses to add to the location set. The only
non-URL source currently defined is "registration", which specifies non-URL source currently defined is "registration", which specifies
all the locations currently registered with the server. all the locations currently registered with the server.
The "lookup" node also has two optional parameters. The "timeout" The "lookup" node also has two optional parameters. The "timeout"
parameter specifies the time, as a positive integer number of parameter specifies the time, as a positive integer number of
seconds, the script is willing to wait for the lookup to be seconds, the script is willing to wait for the lookup to be
performed. If this is not specified, its default value is 30. The performed. If this is not specified, its default value is 30. The
"clear" parameter specifies whether the location set should be "clear" parameter specifies whether the location set should be
cleared before the new locations are added. cleared before the new locations are added.
Lookup has three outputs: "success", "notfound", and "failure". Lookup has three outputs: "success", "notfound", and "failure".
Notfound is taken if the lookup process succeeded but did not find Notfound is taken if the lookup process succeeded but did not find
any locations; failure is taken if the lookup failed for some reason, any locations; failure is taken if the lookup failed for some reason,
including that specified timeout was exceeded. If a given output is including that the specified timeout was exceeded. If a given output
not present, script execution terminates and the default behavior is is not present, script execution terminates and the default behavior
performed. is performed.
5.2.1 Usage of "lookup" with SIP 5.2.1. Usage of "lookup" with SIP
For SIP, the "registration" lookup source corresponds to the For SIP, the "registration" lookup source corresponds to the
locations registered with the server using "REGISTER" messages. locations registered with the server using "REGISTER" messages.
5.3 Location Removal 5.3. Location Removal
A CPL script can also remove locations from the location set, through A CPL script can also remove locations from the location set, through
the use of the "remove-location" node. The syntax of this node is the use of the "remove-location" node. The syntax of this node is
defined in Figure 11. defined in Figure 11.
The meaning of this node is dependent on the underlying signalling The meaning of this node is dependent on the underlying signalling
protocol. Protocol.
Node: "remove-location" Node: "remove-location"
Outputs: None (Next node follows directly) Outputs: None (Next node follows directly)
Next node: Any node Next node: Any node
Parameters: "location" Location to remove Parameters: "location" Location to remove
Figure 11: Syntax of the "remove-location" node Figure 11: Syntax of the "remove-location" node
A "remove-location" node removes locations from the location set. It A "remove-location" node removes locations from the location set. It
is primarily useful following a "lookup" node. An example of this is is primarily useful following a "lookup" node. An example of this is
given in Section 12.8. given in Section 12.8.
The "remove-location" node has one optional parameter. The parameter The "remove-location" node has one optional parameter. The parameter
"location" gives the URI of a location to be removed from the set, in "location" gives the URI of a location to be removed from the set, in
a signalling-protocol-dependent manner. If this parameter is not a signalling-protocol-dependent manner. If this parameter is not
given, all locations are removed from the set. given, all locations are removed from the set.
The "remove-location" node has no explicit output tags. In the XML The "remove-location" node has no explicit output tags. In the XML
syntax, the XML "remove-location" tag directly encloses the next syntax, the XML "remove-location" tag directly encloses the next
node's tag. node's tag.
5.3.1 Usage of "remove-location" with SIP 5.3.1. Usage of "remove-location" with SIP
The location specified in the "location" parameter of the "remove- The location specified in the "location" parameter of the "remove-
location" node is matched against the location set using the standard location" node is matched against the location set using the standard
rules for SIP URI matching (as are used, e.g., to match Contact rules for SIP URI matching (as are used, e.g., to match Contact
addresses when refreshing registrations). addresses when refreshing registrations).
6 Signalling Operations 6. Signalling Operations
Signalling operation nodes cause signalling events in the underlying Signalling operation nodes cause signalling events in the underlying
signalling protocol. Three signalling operations are defined: signalling protocol. Three signalling operations are defined:
"proxy," "redirect," and "reject." "proxy," "redirect," and "reject."
6.1 Proxy 6.1. Proxy
Proxy causes the triggering call to be forwarded on to the currently Proxy causes the triggering call to be forwarded on to the currently
specified set of locations. The syntax of the proxy node is given in specified set of locations. The syntax of the proxy node is given in
Figure 12. Figure 12.
The specific signalling events invoked by the "proxy" node are The specific signalling events invoked by the "proxy" node are
signalling-protocol-dependent, though the general concept should signalling-protocol-dependent, though the general concept should
apply to any signalling protocol. apply to any signalling protocol.
Node: "proxy" Node: "proxy"
Outputs: "busy" Next node if call attempt returned "busy" Outputs: "busy" Next node if call attempt returned "busy"
"noanswer" Next node if call attempt was not "noanswer" Next node if call attempt was not
answered before timeout answered before timeout
skipping to change at page 28, line 42 skipping to change at page 27, line 42
Figure 12: Syntax of the "proxy" node Figure 12: Syntax of the "proxy" node
After a proxy operation has completed, the CPL server chooses the After a proxy operation has completed, the CPL server chooses the
"best" response to the call attempt, as defined by the signalling "best" response to the call attempt, as defined by the signalling
protocol or the server's administrative configuration rules. protocol or the server's administrative configuration rules.
If the call attempt was successful, CPL execution terminates and the If the call attempt was successful, CPL execution terminates and the
server proceeds to its default behavior (normally, to allow the call server proceeds to its default behavior (normally, to allow the call
to be set up). Otherwise, the next node corresponding to one of the to be set up). Otherwise, the next node corresponding to one of the
"proxy" node's outputs is taken. The "busy" output is followed if the "proxy" node's outputs is taken. The "busy" output is followed if
call was busy; "noanswer" is followed if the call was not answered the call was busy, "noanswer" is followed if the call was not
before the "timeout" parameter expired; "redirection" is followed if answered before the "timeout" parameter expired, "redirection" is
the call was redirected; and "failure" is followed if the call setup followed if the call was redirected, and "failure" is followed if the
failed for any other reason. call setup failed for any other reason.
If one of the conditions above is true, but the corresponding output If one of the conditions above is true, but the corresponding output
was not specified, the "default" output of the "proxy" node is was not specified, the "default" output of the "proxy" node is
followed instead. If there is also no "default" node specified, CPL followed instead. If there is also no "default" node specified, CPL
execution terminates and the server returns to its default behavior execution terminates and the server returns to its default behavior
(normally, to forward the best response upstream to the originator). (normally, to forward the best response upstream to the originator).
Note: CPL extensions to allow in-call or end-of-call Note: CPL extensions to allow in-call or end-of-call operations
operations will require an additional output, such as will require an additional output, such as "success", to be added.
"success", to be added.
If no locations were present in the set, or if the only locations in If no locations were present in the set, or if the only locations in
the set were locations to which the server cannot proxy a call (for the set were locations to which the server cannot proxy a call (for
example, "http" URLs), the "failure" output is taken. example, "http" URLs), the "failure" output is taken.
Proxy has three optional parameters. The "timeout" parameter Proxy has three optional parameters. The "timeout" parameter
specifies the time, as a positive integer number of seconds, to wait specifies the time, as a positive integer number of seconds, to wait
for the call to be completed or rejected; after this time has for the call to be completed or rejected; after this time has
elapsed, the call attempt is terminated and the "noanswer" branch is elapsed, the call attempt is terminated and the "noanswer" branch is
taken. If this parameter is not specified, the default value is 20 taken. If this parameter is not specified, the default value is 20
seconds if the "proxy" node has a "noanswer" or "default" output seconds if the "proxy" node has a "noanswer" or "default" output
specified; otherwise the server SHOULD allow the call to ring for a specified; otherwise the server SHOULD allow the call to ring for a
reasonably long period of time (to the maximum extent that server reasonably long period of time (to the maximum extent that server
policy allows). policy allows).
The second optional parameter is "recurse", which can take two The second optional parameter is "recurse", which can take two
values, "yes" or "no". This specifies whether the server should values, "yes" or "no". This specifies whether the server should
automatically attempt to place further call attempts to telephony automatically attempt to place further call attempts to telephony
addresses in redirection responses that were returned from the addresses in redirection responses that were returned from the
initial server. Note that if the value of "recurse" is "yes", the initial server. Note that if the value of "recurse" is "yes", the
"redirection" output to the script is never taken. In this case this "redirection" output to the script is never taken. In this case this
output SHOULD NOT be present. The default value of this parameter is output SHOULD NOT be present. The default value of this parameter is
"yes". "yes".
The third optional parameter is "ordering". This can have three The third optional parameter is "ordering". This can have three
possible values: "parallel", "sequential", and "first-only". This possible values: "parallel", "sequential", and "first-only". This
parameter specifies in what order the locations of the location set parameter specifies in what order the locations of the location set
should be tried. Parallel asks that they all be tried simultaneously; should be tried. Parallel asks that they all be tried
sequential asks that the one with the highest priority be tried simultaneously; sequential asks that the one with the highest
first, the one with the next-highest priority second, and so forth, priority be tried first, the one with the next-highest priority
until one succeeds or the set is exhausted. First-only instructs the second, and so forth, until one succeeds or the set is exhausted.
server to try only the highest-priority address in the set, and then First-only instructs the server to try only the highest-priority
follow one of the outputs. The priority of locations in a set is address in the set, and then follow one of the outputs. The priority
determined by server policy, though CPL servers SHOULD honor the of locations in a set is determined by server policy, though CPL
"priority" parameter of the "location" tag. The default value of this servers SHOULD honor the "priority" parameter of the "location" tag.
parameter is "parallel". The default value of this parameter is "parallel".
Once a proxy operation completes, if control is passed on to other Once a proxy operation completes, if control is passed on to other
nodes, all locations which have been used are cleared from the nodes, all locations which have been used are cleared from the
location set. That is, the location set is emptied of proxyable location set. That is, the location set is emptied of proxyable
locations if the "ordering" was "parallel" or "sequential"; the locations if the "ordering" was "parallel" or "sequential"; the
highest-priority item in the set is removed from the set if highest-priority item in the set is removed from the set if
"ordering" was "first-only". (In all cases, non-proxyable locations "ordering" was "first-only". (In all cases, non-proxyable locations
such as "http" URIs remain.) In the case of a "redirection" output, such as "http" URIs remain.) In the case of a "redirection" output,
the new addresses to which the call was redirected are then added to the new addresses to which the call was redirected are then added to
the location set. the location set.
6.1.1 Usage of "proxy" with SIP 6.1.1. Usage of "proxy" with SIP
For SIP, the best response to a "proxy" node is determined by the For SIP, the best response to a "proxy" node is determined by the
algorithm of the SIP specification. The node's outputs correspond to algorithm of the SIP specification. The node's outputs correspond to
the following events: the following events:
"busy" A 486 or 600 response was the best response received to busy: A 486 or 600 response was the best response received for the
the call request. call request.
"redirection" A 3xx response was the best response received to redirection: A 3xx response was the best response received for the
the call request. call request.
"failure" Any other 4xx, 5xx, or 6xx response was the best failure: Any other 4xx, 5xx, or 6xx response was the best response
response received to the call request. received for the call request.
"no-answer" No final response was received to the call request no-answer: No final response was received for the call request
before the timeout expired. before the timeout expired.
SIP servers SHOULD honor the "q" parameter of SIP registrations when SIP servers SHOULD honor the "q" parameter of SIP registrations when
determining location priority. determining location priority.
6.2 Redirect 6.2. Redirect
Redirect causes the server to direct the calling party to attempt to Redirect causes the server to direct the calling party to attempt to
place its call to the currently specified set of locations. The place its call to the currently specified set of locations. The
syntax of this node is specified in Figure 13. syntax of this node is specified in Figure 13.
The specific behavior the redirect node invokes is dependent on the The specific behavior the redirect node invokes is dependent on the
underlying signalling protocol involved, though its semantics are underlying signalling protocol involved, though its semantics are
generally applicable. generally applicable.
Node: "redirect" Node: "redirect"
Outputs: None (No node may follow) Outputs: None (No node may follow)
Next node: None Next node: None
Parameters: "permanent" Whether the redirection should be Parameters: "permanent" Whether the redirection should be
considered permanent considered permanent
Figure 13: Syntax of the "redirect" node Figure 13: Syntax of the "redirect" node
Redirect immediately terminates execution of the CPL script, so this Redirect immediately terminates execution of the CPL script, so this
node has no outputs and no next node. It has one parameter, node has no outputs and no next node. It has one parameter,
"permanent", which specifies whether the result returned should "permanent", which specifies whether the result returned should
indicate that this is a permanent redirection. The value of this indicate that this is a permanent redirection. The value of this
parameter is either "yes" or "no" and its default value is "no." parameter is either "yes" or "no" and its default value is "no."
6.2.1 Usage of "redirect" with SIP 6.2.1. Usage of "redirect" with SIP
The SIP server SHOULD send a 3xx class response to a call request The SIP server SHOULD send a 3xx class response to a call request
upon executing a "redirect" tag. If "permanent" was "yes", the server upon executing a "redirect" tag. If "permanent" was "yes", the
SHOULD send the response "301" (Moved permanently); otherwise it server SHOULD send the response "301" (Moved permanently), otherwise
SHOULD send "302" (Moved temporarily). it SHOULD send "302" (Moved temporarily).
6.3 Reject 6.3. Reject
Reject nodes cause the server to reject the call attempt. Their Reject nodes cause the server to reject the call attempt. Their
syntax is given in Figure 14. The specific behavior they invoke is syntax is given in Figure 14. The specific behavior they invoke is
dependent on the underlying signalling protocol involved, though dependent on the underlying signalling protocol involved, though
their semantics are generally applicable. their semantics are generally applicable.
Node: "reject" Node: "reject"
Outputs: None (No node may follow) Outputs: None (No node may follow)
Next node: None Next node: None
Parameters: "status" Status code to return Parameters: "status" Status code to return
"reason" Reason phrase to return "reason" Reason phrase to return
Figure 14: Syntax of the "reject" node Figure 14: Syntax of the "reject" node
A reject node immediately terminates the execution of a CPL script, A reject node immediately terminates the execution of a CPL script,
so this node has no outputs and no next node. so this node has no outputs and no next node.
This node has two arguments: "status" and "reason". The "status" This node has two arguments: "status" and "reason". The "status"
argument is required, and can take one of the values "busy", argument is required, and can take one of the values "busy",
"notfound", "reject", and "error", or a signalling-protocol-defined "notfound", "reject", "error", or a signalling-protocol-defined
status. status.
The "reason" argument optionally allows the script to specify a The "reason" argument optionally allows the script to specify a
reason for the rejection. reason for the rejection.
6.3.1 Usage of "reject" with SIP 6.3.1. Usage of "reject" with SIP
Servers which implement SIP SHOULD also allow the "status" field to Servers which implement SIP SHOULD also allow the "status" field to
be a numeric argument corresponding to a SIP status in the 4xx, 5xx, be a numeric argument corresponding to a SIP status in the 4xx, 5xx,
or 6xx range. or 6xx range.
They SHOULD send the "reason" parameter in the SIP reason phrase. They SHOULD send the "reason" parameter in the SIP reason phrase.
A suggested mapping of the named statuses is as follows. Servers MAY A suggested mapping of the named statuses is as follows. Servers MAY
use a different mapping, though similar semantics SHOULD be use a different mapping, though similar semantics SHOULD be
preserved. preserved.
"busy": 486 Busy Here "busy": 486 Busy Here
"notfound": 404 Not Found
"reject": 603 Decline "notfound": 404 Not Found
"reject": 603 Decline
"error": 500 Internal Server Error "error": 500 Internal Server Error
7 Non-signalling Operations 7. Non-signalling Operations
In addition to the signalling operations, CPL defines several In addition to the signalling operations, CPL defines several
operations which do not affect and are not dependent on the telephony operations which do not affect and are not dependent on the telephony
signalling protocol. signalling protocol.
7.1 Mail 7.1. Mail
The mail node causes the server to notify a user of the status of the The mail node causes the server to notify a user of the status of the
CPL script through electronic mail. Its syntax is given in Figure 15. CPL script through electronic mail. Its syntax is given in Figure
15.
Node: "mail" Node: "mail"
Outputs: None (Next node follows directly) Outputs: None (Next node follows directly)
Next node: Any node Next node: Any node
Parameters: "url" Mailto url to which the mail should be sent Parameters: "url" Mailto url to which the mail should be sent
Figure 15: Syntax of the "mail" node Figure 15: Syntax of the "mail" node
The "mail" node takes one argument: a "mailto" URL giving the The "mail" node takes one argument: a "mailto" URL giving the
address, and any additional desired parameters, of the mail to be address, and any additional desired parameters, of the mail to be
sent. The server sends the message containing the content to the sent. The server sends the message containing the content to the
given url; it SHOULD also include other status information about the given url; it SHOULD also include other status information about the
original call request and the CPL script at the time of the original call request and the CPL script at the time of the
notification. notification.
Using a full "mailto" URL rather than just an e-mail Using a full "mailto" URL rather than just an e-mail address
address allows additional e-mail headers to be specified, allows additional e-mail headers to be specified, such as
such as <mail <mail url="mailto:jones@example.com?subject=Lookup%20failed" />.
url="mailto:jones@example.com?subject=Lookup%20failed" />.
A mail node has only one possible result, since failure of e-mail A mail node has only one possible result, since failure of e-mail
delivery cannot reliably be known in real-time. Therefore, its XML delivery cannot reliably be known in real time. Therefore, its XML
representation does not have output tags: the <mail> tag directly representation does not have output tags: the <mail> tag directly
contains another node tag. contains another node tag.
Note that the syntax of XML requires that ampersand characters, "&", Note that the syntax of XML requires that ampersand characters, "&",
which are used as parameter separators in "mailto" URLs, be quoted as which are used as parameter separators in "mailto" URLs, be quoted as
"&amp;" inside parameter values (see Section C.12 of the XML "&amp;" inside parameter values (see Section C.12 of the XML
specification [2]). specification [2]).
7.1.1 Suggested Content of Mailed Information 7.1.1. Suggested Content of Mailed Information
This section presents suggested guidelines for the mail sent as a This section presents suggested guidelines for the mail sent as a
result of the "mail" node, for requests triggered by SIP. The message result of the "mail" node, for requests triggered by SIP. The
mailed (triggered by any protocol) SHOULD contain all this message mailed (triggered by any protocol) SHOULD contain all this
information, but servers MAY elect to use a different format. information, but servers MAY elect to use a different format.
1. If the "mailto" URI did not specify a subject header, the 1. If the "mailto" URI did not specify a subject header, the
subject of the e-mail is "[CPL]" followed by the subject subject of the e-mail is "[CPL]", followed by the subject
header of the SIP request. If the URI specified a subject header of the SIP request. If the URI specified a subject
header, it is used instead. header, it is used instead.
2. The "From" field of the e-mail is set to a CPL server 2. The "From" field of the e-mail is set to a CPL server
configured address, overriding any "From" field in the configured address, overriding any "From" field in the "mailto"
"mailto" URI. URI.
3. Any "Reply-To" header in the URI is honored. If none is 3. Any "Reply-To" header in the URI is honored. If none is given,
given, then an e-mail-ized version of the origin field of then an e-mail-ized version of the origin field of the request
the request is used, if possible (e.g., a SIP "From" header is used, if possible (e.g., a SIP "From" header with a sip: URI
with a sip: URI would be converted to an e-mail address by would be converted to an e-mail address by stripping the URI
stripping the URI scheme). scheme).
4. If the "mailto" URI specifies a body, it is used. If none 4. If the "mailto" URI specifies a body, it is used. If none was
was specified, the body SHOULD contain at least the specified, the body SHOULD contain at least the identity of the
identity of the caller (both the caller's display name and caller (both the caller's display name and address), the date
address), the date and time of day, the call subject, and and time of day, the call subject, and if available, the call
if available, the call priority. priority.
The server SHOULD honor the user's requested languages, and send the The server SHOULD honor the user's requested languages, and send the
mail notification using an appropriate language and character set. mail notification using an appropriate language and character set.
7.2 Log 7.2. Log
The Log node causes the server to log information about the call to The Log node causes the server to log information about the call to
non-volatile storage. Its syntax is specified in Figure 16. non-volatile storage. Its syntax is specified in Figure 16.
Node: "log" Node: "log"
Outputs: None (Next node follows directly) Outputs: None (Next node follows directly)
Next node: Any node Next node: Any node
Parameters: "name" Name of the log file to use Parameters: "name" Name of the log file to use
"comment" Comment to be placed in log file "comment" Comment to be placed in log file
Figure 16: Syntax of the "log" node Figure 16: Syntax of the "log" node
Log takes two arguments, both optional: "name", which specifies the Log takes two arguments, both optional: "name", which specifies the
name of the log, and "comment", which gives a comment about the name of the log, and "comment", which gives a comment about the
information being logged. Servers SHOULD also include other information being logged. Servers SHOULD also include other
information in the log, such as the time of the logged event, information in the log, such as the time of the logged event,
information that triggered the call to be logged, and so forth. Logs information that triggered the call to be logged, and so forth. Logs
are specific to the owner of the script which logged the event. If are specific to the owner of the script which logged the event. If
the "name" parameter is not given, the event is logged to a standard, the "name" parameter is not given, the event is logged to a standard,
server-defined log file for the script owner. This specification does server-defined log file for the script owner. This specification
not define how users may retrieve their logs from the server. does not define how users may retrieve their logs from the server.
The name of a log is a logical name only, and does not necessarily The name of a log is a logical name only, and does not necessarily
correspond to any physical file on the server. The interpretation of correspond to any physical file on the server. The interpretation of
the log file name is server defined, as is a mechanism to access the log file name is server defined, as is a mechanism to access
these logs. The CPL server SHOULD NOT directly map log names these logs. The CPL server SHOULD NOT directly map log names
uninterpreted onto local file names, for security reasons, lest a uninterpreted onto local file names, for security reasons, lest a
security-critical file be overwritten. security-critical file be overwritten.
A correctly operating CPL server SHOULD NOT ever allow the "log" A correctly operating CPL server SHOULD NOT ever allow the "log"
event to fail. As such, log nodes can have only one possible result, event to fail. As such, log nodes can have only one possible result,
and their XML representation does not have explicit output tags. A and their XML representation does not have explicit output tags. A
CPL <log> tag directly contains another node tag. CPL <log> tag directly contains another node tag.
8 Subactions 8. Subactions
XML syntax defines a tree. To allow more general call flow diagrams, XML syntax defines a tree. To allow more general call flow diagrams,
and to allow script re-use and modularity, we define subactions. and to allow script re-use and modularity, we define subactions.
Two tags are defined for subactions: subaction definitions and Two tags are defined for subactions: subaction definitions and
subaction references. Their syntax is given in Figure 17. subaction references. Their syntax is given in Figure 17.
Tag: "subaction" Tag: "subaction"
Subtags: Any node Subtags: Any node
Parameters: "id" Name of this subaction Parameters: "id" Name of this subaction
Pseudo-node: "sub" Pseudo-node: "sub"
Outputs: None in XML tree Outputs: None in XML tree
Parameters: "ref" Name of subaction to execute Parameters: "ref" Name of subaction to execute
Figure 17: Syntax of subactions and "sub" pseudo-nodes Figure 17: Syntax of subactions and "sub" pseudo-nodes
Subactions are defined through "subaction" tags. These tags are Subactions are defined through "subaction" tags. These tags are
placed in CPL after any ancillary information (see Section 9) but placed in the CPL script after any ancillary information (see Section
before any top-level tags. They take one argument: "id", a token 9), but before any top-level tags. They take one argument: "id", a
indicating a script-chosen name for the subaction. The "id" value for token indicating a script-chosen name for the subaction. The "id"
every "subaction" tag in a script MUST be unique within that script. value for every "subaction" tag in a script MUST be unique within
that script.
Subactions are called from "sub" tags. The "sub" tag is a "pseudo- Subactions are called from "sub" tags. The "sub" tag is a "pseudo-
node": it can be used anyplace in a CPL action that a true node could node", and can be used anyplace in a CPL action that a true node
be used. It takes one parameter, "ref", the name of the subaction to could be used. It takes one parameter, "ref", the name of the
be called. The "sub" tag contains no outputs of its own; control subaction to be called. The "sub" tag contains no outputs of its
instead passes to the subaction. own, instead control passes to the subaction.
References to subactions MUST refer to subactions defined before the References to subactions MUST refer to subactions defined before the
current action. A "sub" tag MUST NOT refer to the action which it current action. A "sub" tag MUST NOT refer to the action it appears
appears in, or to any action defined later in the CPL script. Top- in, or to any action defined later in the CPL script. Top-level
level actions cannot be called from "sub" tags, or through any other actions cannot be called from "sub" tags, or through any other means.
means. Script servers MUST verify at the time the script is submitted Script servers MUST verify at the time the script is submitted that
that no "sub" node refers to any subaction which is not its proper no "sub" node refers to any subaction that is not its proper
predecessor. predecessor.
Allowing only back-references of subs forbids any sort of Allowing only back-references of subs forbids any sort of
recursion. Recursion would introduce the possibility of recursion. Recursion would introduce the possibility of non-
non-terminating or non-decidable CPL scripts, a possibility terminating or non-decidable CPL scripts, a possibility our
our requirements specifically excluded. requirements specifically excluded.
Every sub MUST refer to a subaction ID defined within the same CPL Every sub MUST refer to a subaction ID defined within the same CPL
script. No external links are permitted. script. No external links are permitted.
Subaction IDs are case sensitive. Subaction IDs are case sensitive.
If any subsequent version or extension defines external If any subsequent version or extension defines external linkages,
linkages, it should probably use a different tag, perhaps it should probably use a different tag, perhaps XLink [21].
XLink [21]. Ensuring termination in the presence of Ensuring termination in the presence of external links is a
external links is a difficult problem. difficult problem.
9 Ancillary Information 9. Ancillary Information
No ancillary information is defined in the base CPL specification. If No ancillary information is defined in the base CPL specification.
ancillary information, not part of any operation, is found to be If ancillary information, not part of any operation, is found to be
necessary for a CPL extension, it SHOULD be placed within this tag. necessary for a CPL extension, it SHOULD be placed within this tag.
The (trivial) definition of the ancillary information tag is given in The (trivial) definition of the ancillary information tag is given in
Figure 18. Figure 18.
It may be useful to include timezone definitions inside CPL It may be useful to include timezone definitions inside CPL
scripts directly, rather than referencing them externally scripts directly, rather than referencing them externally with
with "tzid" and "tzurl" parameters. If it is, an extension "tzid" and "tzurl" parameters. If it is, an extension could be
could be defined to include them here. defined to include them here.
Tag: "ancillary" Tag: "ancillary"
Parameters: None Parameters: None
Subtags: None Subtags: None
Figure 18: Syntax of the "ancillary" tag Figure 18: Syntax of the "ancillary" tag
10 Default Behavior 10. Default Behavior
When a CPL node reaches an unspecified output, either because the When a CPL node reaches an unspecified output, either because the
output tag is not present, or because the tag is present but does not output tag is not present, or because the tag is present but does not
contain a node, the CPL server's behavior is dependent on the current contain a node, the CPL server's behavior is dependent on the current
state of script execution. This section gives the operations that state of script execution. This section gives the operations that
should be taken in each case. should be taken in each case.
no location modifications or signalling operations performed, no location modifications or signalling operations performed,
location set empty: Look up the user's location through location set empty: Look up the user's location through
whatever mechanism the server would use if no CPL script whatever mechanism the server would use if no CPL script were
were in effect. Proxy, redirect, or send a rejection in effect. Proxy, redirect, or send a rejection message,
message, using whatever policy the server would use in the using whatever policy the server would use in the absence of
absence of a CPL script. a CPL script.
no location modifications or signalling operations performed, no location modifications or signalling operations performed,
location set non-empty: (This can only happen for outgoing location set non-empty: (This can only happen for outgoing
calls.) Proxy the call to the addresses in the location calls.) Proxy the call to the addresses in the location set.
set.
location modifications performed, no signalling operations: location modifications performed, no signalling operations: Proxy
Proxy or redirect the call, whichever is the server's or redirect the call, whichever is the server's standard
standard policy, to the addresses in the current location policy, to the addresses in the current location set. If the
set. If the location set is empty, return "notfound" location set is empty, return a "notfound" rejection.
rejection.
noanswer output of proxy, no timeout given: (This is a special noanswer output of proxy, no timeout given: (This is a special
case.) If the "noanswer" output of a proxy node is case.) If the "noanswer" output of a proxy node is
unspecified, and no timeout parameter was given to the unspecified, and no timeout parameter was given to the proxy
proxy node, the call should be allowed to ring for the node, the call should be allowed to ring for the maximum
maximum length of time allowed by the server (or the length of time allowed by the server (or the request, if the
request, if the request specified a timeout). request specified a timeout).
proxy operation previously taken: Return whatever the "best" proxy operation previously taken: Return whatever the "best"
response is of all accumulated responses to the call to response is of all accumulated responses to the call to this
this point, according to the rules of the underlying point, according to the rules of the underlying signalling
signalling protocol. protocol.
11 CPL Extensions 11. CPL Extensions
Servers MAY support additional CPL features beyond those listed in Servers MAY support additional CPL features beyond those listed in
this document. Some of the extensions which have been suggested are a this document. Some of the extensions which have been suggested are
means of querying how a call has been authenticated; richer control a means of querying how a call has been authenticated, richer control
over H.323 addressing; end-system or administrator-specific features; over H.323 addressing, end-system or administrator-specific features,
regular-expression matching for strings and addresses; and mid-call regular-expression matching for strings and addresses, and mid-call
or end-of-call controls. or end-of-call controls.
CPL extensions are indicated by XML namespaces [11]. Every extension CPL extensions are indicated by XML namespaces [11]. Every extension
MUST have an appropriate XML namespace assigned to it. The XML MUST have an appropriate XML namespace assigned to it. The XML
namespace of the extension MUST be different from the XML namespace namespace of the extension MUST be different from the XML namespace
defined in Section 14. The extension MUST NOT change the syntax or defined in Section 14. The extension MUST NOT change the syntax or
semantics of the CPL schema defined in this document. All XML tags semantics of the CPL schema defined in this document. All XML tags
and attributes that are part of the extension MUST be appropriately and attributes that are part of the extension MUST be appropriately
qualified so as to place them within that namespace. qualified so as to place them within that namespace.
Tags or attributes in a CPL script which are in the global namespace Tags or attributes in a CPL script which are in the global namespace
(i.e., not associated with any namespace) are equivalent to tags and (i.e., not associated with any namespace) are equivalent to tags and
attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl". attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl".
A CPL script SHOULD NOT specify any namespaces it does not use. For A CPL script SHOULD NOT specify any namespaces it does not use. For
compatibility with non-namespace-aware parsers, a CPL script MAY omit compatibility with non-namespace-aware parsers, a CPL script MAY omit
the base CPL namespace for a script which does not use any the base CPL namespace for a script which does not use any
extensions. extensions.
A CPL server MUST reject any script which contains a reference to a A CPL server MUST reject any script containing a reference to a
namespace which it does not understand. It MUST reject any script namespace it does not understand. It MUST reject any script
which contains an extension tag or attribute which is not qualified containing an extension tag or attribute that is not qualified to be
to be in an appropriate namespace. in an appropriate namespace.
A syntax such as A syntax such as
<extension-switch> <extension-switch>
<extension has="http://www.example.com/foo"> <extension has="http://www.example.com/foo">
[extended things] [extended things]
</extension> </extension>
<otherwise> <otherwise>
[non-extended things] [non-extended things]
</otherwise> </otherwise>
</extension-switch> </extension-switch>
was suggested as an alternate way of handling extensions. was suggested as an alternate way of handling extensions. This
This would allow scripts to be uploaded to a server without would allow scripts to be uploaded to a server without requiring a
requiring a script author to somehow determine which script author to somehow determine which extensions a server
extensions a server supports. However, experience supports. However, experience developing other languages, notably
developing other languages, notably Sieve [22], was that Sieve [22], was that this added excessive complexity to languages.
this added excessive complexity to languages. The The "extension-switch" tag could, of course, itself be defined in
"extension-switch" tag could, of course, itself be defined a CPL extension.
in a CPL extension.
In the XML schema of CPL, we introduce three abstract elements, In the XML schema of CPL, we introduce three abstract elements,
namely `toplevelaction', `switch', and `action', which accordingly namely 'toplevelaction', 'switch', and 'action', which accordingly
have the abstract type `TopLevelActionType', `SwitchType', and have the abstract type 'TopLevelActionType', 'SwitchType', and
`ActionType'. Any top-level action in a CPL extension MUST be defined 'ActionType'. Any top-level action in a CPL extension MUST be
as the substitutionGroup of the abstract `toplevelaction' element, defined as the substitutionGroup of the abstract 'toplevelaction'
and has the type extended from the `TopLevelActionType'. Any switch element, and have the type extended from the 'TopLevelActionType'.
in a CPL extension MUST be defined as the substitutionGroup of the Any switch in a CPL extension MUST be defined as the
abstract `switch' element, and has the type extended from the substitutionGroup of the abstract 'switch' element, and have the type
`SwitchType'. Any action in a CPL extension MUST be defined as the extended from the 'SwitchType'. Any action in a CPL extension MUST
substitutionGroup of the abstract `action' element, and has the type be defined as the substitutionGroup of the abstract 'action' element,
extended from the `ActionType'. and have the type extended from the 'ActionType'.
12 Examples 12. Examples
12.1 Example: Call Redirect Unconditional 12.1. Example: Call Redirect Unconditional
The script in Figure 19 is a simple script which redirects all calls The script in Figure 19 is a simple script that redirects all calls
to a single fixed location. to a single fixed location.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<location url="sip:smith@phone.example.com"> <location url="sip:smith@phone.example.com">
<redirect/> <redirect/>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 19: Example Script: Call Redirect Unconditional Figure 19: Example Script: Call Redirect Unconditional
12.2 Example: Call Forward Busy/No Answer 12.2. Example: Call Forward Busy/No Answer
The script in Figure 20 illustrates some more complex behavior. We The script in Figure 20 illustrates some more complex behavior. We
see an initial proxy attempt to one address, with further operations see an initial proxy attempt to one address, with further operations
if that fails. We also see how several outputs take the same action if that fails. We also see how several outputs take the same action
subtree, through the use of subactions. subtree, through the use of subactions.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<proxy/> <proxy/>
</location> </location>
skipping to change at page 40, line 30 skipping to change at page 39, line 5
<noanswer> <noanswer>
<sub ref="voicemail"/> <sub ref="voicemail"/>
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 20: Example Script: Call Forward Busy/No Answer Figure 20: Example Script: Call Forward Busy/No Answer
12.3 Example: Call Forward: Redirect and Default 12.3. Example: Call Forward: Redirect and Default
The script in Figure 21 illustrates further proxy behavior. The The script in Figure 21 illustrates further proxy behavior. The
server initially tries to proxy to a single address. If this attempt server initially tries to proxy to a single address. If this attempt
is redirected, a new redirection is generated using the locations is redirected, a new redirection is generated using the locations
returned. In all other failure cases for the proxy node, a default returned. In all other failure cases for the proxy node, a default
operation -- forwarding to voicemail -- is performed. operation -- forwarding to voicemail -- is performed.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<location url="sip:jones@jonespc.example.com"> <location url="sip:jones@jonespc.example.com">
<proxy> <proxy>
<redirection> <redirection>
skipping to change at page 41, line 27 skipping to change at page 40, line 5
<proxy/> <proxy/>
</location> </location>
</default> </default>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 21: Example Script: Call Forward: Redirect and Default Figure 21: Example Script: Call Forward: Redirect and Default
12.4 Example: Call Screening 12.4. Example: Call Screening
The script in Figure 22 illustrates address switches and call The script in Figure 22 illustrates address switches and call
rejection, in the form of a call screening script. Note also that rejection, in the form of a call screening script. Note also that
because the address-switch lacks an "otherwise" clause, if the because the address-switch lacks an "otherwise" clause, if the
initial pattern did not match, the script does not define any initial pattern does not match, the script does not define any
operations. The server therefore proceeds with its default behavior, operations. The server therefore proceeds with its default behavior,
which would presumably be to contact the user. which would presumably be to contact the user.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<address-switch field="origin" subfield="user"> <address-switch field="origin" subfield="user">
<address is="anonymous"> <address is="anonymous">
<reject status="reject" reason="I reject anonymous calls"/> <reject status="reject" reason="I reject anonymous calls"/>
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 22: Example Script: Call Screening Figure 22: Example Script: Call Screening
12.5 Example: Priority and Language Routing 12.5. Example: Priority and Language Routing
The script in Figure 23 illustrates service selection based on a The script in Figure 23 illustrates service selection based on a
call's priority value and language settings. If the call request had call's priority value and language settings. If the call request had
a priority of "urgent" or higher, the default script behavior is a priority of "urgent" or higher, the default script behavior is
performed. Otherwise, the language field is checked for the language performed. Otherwise, the language field is checked for the language
"es" (Spanish). If it is present, the call is proxied to a Spanish- "es" (Spanish). If it is present, the call is proxied to a Spanish-
speaking operator; other calls are proxied to an English-speaking speaking operator; other calls are proxied to an English-speaking
operator. operator.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<priority-switch> <priority-switch>
<priority greater="urgent"/> <priority greater="urgent"/>
skipping to change at page 43, line 32 skipping to change at page 42, line 5
</location> </location>
</otherwise> </otherwise>
</language-switch> </language-switch>
</otherwise> </otherwise>
</priority-switch> </priority-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 23: Example Script: Priority and Language Routing Figure 23: Example Script: Priority and Language Routing
12.6 Example: Outgoing Call Screening 12.6. Example: Outgoing Call Screening
The script in Figure 24 illustrates a script filtering outgoing The script in Figure 24 illustrates a script filtering outgoing
calls, in the form of a script which prevent 1-900 (premium) calls calls, in the form of a script which prevent 1-900 (premium) calls
from being placed. This script also illustrates subdomain matching. from being placed. This script also illustrates subdomain matching.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<outgoing> <outgoing>
<address-switch field="original-destination" subfield="tel"> <address-switch field="original-destination" subfield="tel">
<address subdomain-of="1900"> <address subdomain-of="1900">
<reject status="reject" <reject status="reject"
reason="Not allowed to make 1-900 calls."/> reason="Not allowed to make 1-900 calls."/>
</address> </address>
</address-switch> </address-switch>
</outgoing> </outgoing>
</cpl> </cpl>
Figure 24: Example Script: Outgoing Call Screening Figure 24: Example Script: Outgoing Call Screening
12.7 Example: Time-of-day Routing 12.7. Example: Time-of-day Routing
Figure 25 illustrates time-based conditions and timezones. Figure 25 illustrates time-based conditions and timezones.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<time-switch tzid="America/New_York" <time-switch tzid="America/New_York"
tzurl="http://zones.example.com/tz/America/New_York"> tzurl="http://zones.example.com/tz/America/New_York">
skipping to change at page 45, line 31 skipping to change at page 44, line 5
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<proxy/> <proxy/>
</location> </location>
</otherwise> </otherwise>
</time-switch> </time-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 25: Example Script: Time-of-day Routing Figure 25: Example Script: Time-of-day Routing
12.8 Example: Location Filtering 12.8. Example: Location Filtering
Figure 26 illustrates filtering operations on the location set. In Figure 26 illustrates filtering operations on the location set. In
this example, we assume that version 0.9beta2 of the "Inadequate this example, we assume that version 0.9beta2 of the "Inadequate
Software SIP User Agent" mis-implements some features, and so we must Software SIP User Agent" mis-implements some features, and so we must
work around its problems. We know that it cannot talk successfully to work around its problems. We know that it cannot talk successfully
one particular mobile device we may have registered, so we remove to one particular mobile device we may have registered, so we remove
that location from the location set. Once this operation has been that location from the location set. Once this operation has been
completed, call setup is allowed to proceed normally. completed, call setup is allowed to proceed normally.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<string-switch field="user-agent"> <string-switch field="user-agent">
<string is="Inadequate Software SIP User Agent/0.9beta2"> <string is="Inadequate Software SIP User Agent/0.9beta2">
<lookup source="registration"> <lookup source="registration">
skipping to change at page 46, line 26 skipping to change at page 45, line 5
</remove-location> </remove-location>
</success> </success>
</lookup> </lookup>
</string> </string>
</string-switch> </string-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 26: Example Script: Location Filtering Figure 26: Example Script: Location Filtering
12.9 Example: Non-signalling Operations 12.9. Example: Non-signalling Operations
Figure 27 illustrates non-signalling operations; in particular, Figure 27 illustrates non-signalling operations; in particular,
alerting a user by electronic mail if the lookup server failed. The alerting a user by electronic mail if the lookup server failed. The
primary motivation for having the "mail" node is to allow this sort primary motivation for having the "mail" node is to allow this sort
of out-of-band notification of error conditions, as the user might of out-of-band notification of error conditions, as the user might
otherwise be unaware of any problem. otherwise be unaware of any problem.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<lookup <lookup
skipping to change at page 47, line 25 skipping to change at page 46, line 5
</success> </success>
<failure> <failure>
<mail url="mailto:mary@example.com?subject=Lookup%20failed"/> <mail url="mailto:mary@example.com?subject=Lookup%20failed"/>
</failure> </failure>
</lookup> </lookup>
</incoming> </incoming>
</cpl> </cpl>
Figure 27: Example Script: Non-signalling Operations Figure 27: Example Script: Non-signalling Operations
12.10 Example: Hypothetical Extensions 12.10. Example: Hypothetical Extensions
The example in Figure 28 shows a hypothetical extension which The example in Figure 28 shows a hypothetical extension that
implements distinctive ringing. The XML namespace implements distinctive ringing. The XML namespace
"http://www.example.com/distinctive-ring" specifies a new node named "http://www.example.com/distinctive-ring" specifies a new node named
"ring". "ring".
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.example.com/distinctive-ring" <xs:schema targetNamespace="http://www.example.com/distinctive-ring"
xmlns="http://www.example.com/distinctive-ring" xmlns="http://www.example.com/distinctive-ring"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:CPL="urn:ietf:params:xml:ns:cpl" xmlns:CPL="urn:ietf:params:xml:ns:cpl"
elementFormDefault="qualified" elementFormDefault="qualified"
skipping to change at page 48, line 42 skipping to change at page 46, line 49
http://www.example.com/distinctive-ring distinctive-ring.xsd"> http://www.example.com/distinctive-ring distinctive-ring.xsd">
<incoming> <incoming>
<address-switch field="origin"> <address-switch field="origin">
<address is="sip:boss@example.com"> <address is="sip:boss@example.com">
<dr:ring ringstyle="warble"/> <dr:ring ringstyle="warble"/>
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 28: Example Schema and Script: Hypothetical Distinctive- Figure 28: Example Schema and Script: Hypothetical
Ringing Extension Distinctive-Ringing Extension
The example in Figure 29 implements a hypothetical new attribute for The example in Figure 29 implements a hypothetical new attribute for
address switches, to allow regular-expression matches. It defines a address switches, to allow regular-expression matches. It defines a
new attribute "regex" for the standard "address" node. new attribute "regex" for the standard "address" node.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<address-switch field="origin" subfield="user" <address-switch field="origin" subfield="user"
xmlns:re="http://www.example.com/regex"> xmlns:re="http://www.example.com/regex">
<address re:regex="(.*.smith|.*.jones)"> <address re:regex="(.*.smith|.*.jones)">
<reject status="reject" <reject status="reject"
reason="I don't want to talk to Smiths or Joneses"/> reason="I don't want to talk to Smiths or Joneses"/>
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 29: Example Script: Hypothetical Regular-Expression Extension Figure 29: Example Script: Hypothetical Regular-Expression Extension
12.11 Example: A Complex Example 12.11. Example: A Complex Example
Finally, Figure 30 is a complex example which shows the sort of Finally, Figure 30 is a complex example which shows the sort of
sophisticated behavior which can be achieved by combining CPL nodes. sophisticated behavior that can be achieved by combining CPL nodes.
In this case, the user attempts to have his calls reach his desk; if In this case, the user attempts to have his calls reach his desk; if
he does not answer within a small amount of time, calls from his boss he does not answer within a small amount of time, calls from his boss
are forwarded to his mobile phone, and all other calls are directed are forwarded to his mobile phone, and all other calls are directed
to voicemail. If the call setup failed, no operation is specified, to voicemail. If the call setup failed, no operation is specified,
so the server's default behavior is performed. so the server's default behavior is performed.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
skipping to change at page 50, line 39 skipping to change at page 49, line 5
</otherwise> </otherwise>
</address-switch> </address-switch>
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 30: Example Script: A Complex Example Figure 30: Example Script: A Complex Example
13 Security Considerations 13. Security Considerations
CPL is designed to allow services to be specified in a manner which CPL is designed to allow services to be specified in a manner which
prevents potentially hostile or mis-configured scripts from launching prevents potentially hostile or mis-configured scripts from launching
security attacks, including denial-of-service attacks. Because script security attacks, including denial-of-service attacks. Because
runtime is strictly bounded by acyclicity, and because the number of script runtime is strictly bounded by acyclicity, and because the
possible script operations are strictly limited, scripts should not number of possible script operations are strictly limited, scripts
be able to inflict damage upon a CPL server. should not be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by Because scripts can direct users' telephone calls, the method by
which scripts are transmitted from a client to a server MUST be which scripts are transmitted from a client to a server MUST be
strongly authenticated. Such a method is not specified in this strongly authenticated. Such a method is not specified in this
document. document.
Script servers SHOULD allow server administrators to control the Script servers SHOULD allow server administrators to control the
details of what CPL operations are permitted. details of what CPL operations are permitted.
14 IANA Considerations 14. IANA Considerations
This document registers a new MIME type, application/cpl+xml, and a This document registers a new MIME type, application/cpl+xml, and a
new URN per RFC 2141 [12], RFC 2648 [13], and RFC 3688 [14]. new URN per RFC 2141 [12], RFC 2648 [13], and RFC 3688 [14].
The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the
version of CPL in this document and will not change. Any CPL version of CPL in this document and will not change. Any CPL
enhancements MUST be made by extensions and MUST have different enhancements MUST be made by extensions and MUST have different
namespaces. namespaces.
14.1 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl 14.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl
URI: urn:ietf:params:xml:ns:cpl
Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu> URI: urn:ietf:params:xml:ns:cpl
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
XML: Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
BEGIN XML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Call Processing Language Namespace</title>
</head>
<body>
<h1>Namespace for Call Processing Language</h1>
<h2>urn:ietf:params:xml:ns:cpl</h2>
<p><a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
[Note to RFC Editor: please replace "[[[URL of published BEGIN
RFC]]]" above with the official URL of this RFC at rfc- <?xml version="1.0"?>
editor.org, and "XXXX" above with the number of this RFC.] <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Call Processing Language Namespace</title>
</head>
<body>
<h1>Namespace for Call Processing Language</h1>
<h2>urn:ietf:params:xml:ns:cpl</h2>
<p><a href="ftp://ftp.rfc-editor.org/in-notes/rfc3880.txt">
RFC3880</a>.</p>
</body>
</html>
END
14.2 Schema registration 14.2. Schema registration
This specification registers XML Schema for CPL, as per the This specification registers XML Schema for CPL, as per the
guidelines in [14]. guidelines in [14].
URI: urn:ietf:params:xml:schema:cpl URI: urn:ietf:params:xml:schema:cpl
Registrant contact: Registrant contact:
Jonathan Lennox <lennox@cs.columbia.edu> Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
XML: The XML can be found in Section C. XML: The XML can be found in Appendix C.
14.3 MIME Registration 14.3. MIME Registration
As an XML type, CPL's MIME registration conforms with "XML Media As an XML type, CPL's MIME registration conforms with "XML Media
Types," RFC 3023 [15]. Types," RFC 3023 [15].
MIME media type name: application MIME media type name: application
MIME subtype name: cpl+xml MIME subtype name: cpl+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
As for application/xml in RFC 3023. As for application/xml in RFC 3023.
Encoding considerations: As for application/xml in RFC 3023. Encoding considerations: As for application/xml in RFC 3023.
Security considerations: See Section 13, and Section 10 of RFC Security considerations: See Section 13, and Section 10 of RFC
3023. 3023.
Interoperability considerations: Different CPL servers may use Interoperability considerations: Different CPL servers may use
incompatible address types. However, all potential incompatible address types. However, all potential
interoperability issues should be resolvable at the time a interoperability issues should be resolvable at the time a
script is uploaded; there should be no interoperability script is uploaded; there should be no interoperability
issues which cannot be detected until runtime. issues which cannot be detected until runtime.
Published specification: This document. Published specification: This document.
Applications which use this media type: SIP proxy servers and Applications which use this media type: SIP proxy servers and
other telephony servers, and client software to control other telephony servers, and client software to control
their behavior. their behavior.
Additional information: Additional information:
Magic number: None Magic number: None
File extension: .cpl or .xml File extension: .cpl or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Person and e-mail address for further information: Person and e-mail address for further information:
Jonathan Lennox <lennox@cs.columbia.edu> Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
Intended usage: COMMON Intended usage: COMMON
Author/Change Controller: The IETF. Author/Change Controller: The IETF.
15 Acknowledgments 15. Acknowledgments
This document was reviewed and commented upon by IETF IP Telephony This document was reviewed and commented upon by the IETF IP
Working Group. We specifically acknowledge the following people for Telephony Working Group. We specifically acknowledge the following
their help: people for their help:
The outgoing call screening script was written by Kenny Hom. The outgoing call screening script was written by Kenny Hom.
Paul E. Jones contributed greatly to the mappings of H.323 addresses. Paul E. Jones contributed greatly to the mappings of H.323 addresses.
The text of the time-switch section was taken (lightly modified) from The text of the time-switch section was taken (lightly modified) from
RFC 2445 [8], by Frank Dawson and Derik Stenerson. RFC 2445 [8], by Frank Dawson and Derik Stenerson.
We drew a good deal of inspiration, notably the language's lack of We drew a good deal of inspiration, notably the language's lack of
Turing-completeness and the syntax of string matching, from the Turing-completeness and the syntax of string matching, from the
specification of Sieve [22], a language for user filtering of specification of Sieve [22], a language for user filtering of
electronic mail messages. electronic mail messages.
Thomas F. La Porta and Jonathan Rosenberg had many useful Thomas F. La Porta and Jonathan Rosenberg had many useful
discussions, contributions, and suggestions. discussions, contributions, and suggestions.
Richard Gumpertz performed a very useful last-minute technical and Richard Gumpertz performed a very useful last-minute technical and
editorial review of the specification. editorial review of the specification.
A An Algorithm for Resolving Time Switches A. An Algorithm for Resolving Time Switches
The following algorithm determines whether a given instant falls The following algorithm determines whether a given instant falls
within a repetition of a "time-switch" recurrence. If the pre- within a repetition of a "time-switch" recurrence. If the pre-
processing described in Section 4.4.1 has been done, it operates in processing described in Section 4.4.1 has been done, it operates in
constant time. Open-source Java code implementing this algorithm is constant time. Open-source Java code implementing this algorithm is
available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the
world wide web. world wide web.
This algorithm is believed to be correct, but this section is non- This algorithm is believed to be correct, but this section is non-
normative. Section 4.4, and RFC 2445 [8], are the definitive normative. Section 4.4, and RFC 2445 [8], are the definitive
definitions of recurrences. definitions of recurrences.
1. Compute the time of the call, in the timezone of the time 1. Compute the time of the call, in the timezone of the time
switch. switch.
2. If the call time is earlier than "dtstart", fail NOMATCH. 2. If the call time is earlier than "dtstart", fail NOMATCH.
3. If the call time is less than "duration" after dtstart, 3. If the call time is less than "duration" after dtstart, succeed
succeed MATCH. MATCH.
4. Determine the smallest unit specified in a "byxxx" rule or 4. Determine the smallest unit specified in a "byxxx" rule or by
by the "freq." Call this the Minimum Unit. Determine the the "freq." Call this the Minimum Unit. Determine the
previous instant (before or equal to the call time) when previous instant (before or equal to the call time) when all
all the time units smaller than the minimum unit are the the time units smaller than the minimum unit are the same as
same as those of "dtstart." If the minimum unit is a those of "dtstart." If the minimum unit is a second, this time
second, this time is the same as the instant. If the is the same as the instant. If the minimum unit is a minute or
minimum unit is a minute or an hour, the minutes or the an hour, the minutes or the minutes and hours, respectively,
minutes and hours, respectively, must be the same as must be the same as "dtstart". For all other minimum units,
"dtstart". For all other minimum units, the time-of-day the time-of-day must be the same as "dtstart." If the minimum
must be the same as "dtstart." If the minimum unit is a unit is a week, the day-of-the-week must be the same as
week, the day-of-the-week must be the same as "dtstart." If "dtstart." If the minimum unit is a month, the day-of-the-
the minimum unit is a month, the day-of-the-month must be month must be the same as "dtstart." If the minimum unit is a
the same as "dtstart." If the minimum unit is a year, the year, the month and day-of-month must both be the same as
month and day-of-month must both be the same as "dtstart." "dtstart." (Note that this means it may be necessary to roll
(Note that this means it may be necessary to roll back more back more than one minimum unit -- if the minimum unit is a
than one minimum unit -- if the minimum unit is a month, month, then some months do not have a 31st (or 30th or 29th)
then some months do not have a 31st (or 30th or 29th) day; day; if the minimum unit is a year, then some years do not have
if the minimum unit is a year, then some years do not have a February 29th. In the Gregorian calendar, it is never
a February 29th. In the Gregorian calendar, it is never necessary to roll back more than two months if the minimum unit
necessary to roll back more than two months if the minimum is a month, or eight years if the minimum unit is a year.
unit is a month, or eight years if the minimum unit is a Between 1904 and 2096, it is never necessary to roll back more
year. Between 1904 and 2096, it is never necessary to roll than four years -- the eight-year rollback can only occur when
back more than four years -- the eight-year rollback can the Gregorian calendar "skips" a leap year.
only occur when the Gregorian calendar "skips" a leap year.
Call this instant the Candidate Start Time. Call this instant the Candidate Start Time.
5. If the time between the candidate start time and the call 5. If the time between the candidate start time and the call time
time is more than the duration, fail NOMATCH. is more than the duration, fail NOMATCH.
6. If the candidate start time is later than the "until" 6. If the candidate start time is later than the "until" parameter
parameter of the recurrence (or the virtual "until" of the recurrence (or the virtual "until" computed off-line
computed off-line from "count"), fail NOMATCH. from "count"), fail NOMATCH.
7. Call the unit of the "freq" parameter of the recurrence the 7. Call the unit of the "freq" parameter of the recurrence the
Frequency Unit. Determine the frequency unit enclosing the Frequency Unit. Determine the frequency unit enclosing the
Candidate Start Time, and that enclosing "dtstart". Candidate Start Time, and that enclosing "dtstart". Calculate
Calculate the number of frequency units that have passed the number of frequency units that have passed between these
between these two times. If this is not a multiple of the two times. If this is not a multiple of the "interval"
"interval" parameter, fail NOMATCH. parameter, fail NOMATCH.
8. For every "byxxx" rule, confirm that the candidate start 8. For every "byxxx" rule, confirm that the candidate start time
time matches one of the options specified by that "byxxx" matches one of the options specified by that "byxxx" rule. If
rule. If so, succeed MATCH. so, succeed MATCH.
9. Calculate a previous candidate start time. Repeat until the 9. Calculate a previous candidate start time. Repeat until the
difference between the candidate start time and the call difference between the candidate start time and the call time
time is more than the duration. If no candidate start time is more than the duration. If no candidate start time has been
has been validated, fail NOMATCH. validated, fail NOMATCH.
B Suggested Usage of CPL with H.323 B. Suggested Usage of CPL with H.323
This appendix gives a suggested usage of CPL with H.323 [16]. Study This appendix gives a suggested usage of CPL with H.323 [16]. Study
Group 16 of the ITU, which developed H.323, is proposing to work on Group 16 of the ITU, which developed H.323, is proposing to work on
official CPL mappings for that protocol. This section is therefore official CPL mappings for that protocol. This section is therefore
not normative. not normative.
B.1 Usage of "address-switch" with H.323 B.1. Usage of "address-switch" with H.323
Address switches are specified in Section 4.1. This section specifies Address switches are specified in Section 4.1. This section
the mapping between H.323 messages and the fields and subfields of specifies the mapping between H.323 messages and the fields and
address-switches subfields of address-switches.
For H.323, the "origin" address corresponds to the alias addresses in For H.323, the "origin" address corresponds to the alias addresses in
the "sourceAddress" field of the "Setup-UUIE" user-user information the "sourceAddress" field of the "Setup-UUIE" user-user information
element, and to the Q.931 [23] information element "Calling party element, and to the Q.931 [23] information element "Calling party
number." If both fields are present, or if multiple aliases addresses number." If both fields are present, or if multiple alias addresses
for "sourceAddress" are present, which one has priority is a matter for "sourceAddress" are present, which one has priority is a matter
of local server policy; the server SHOULD use the same resolution as of local server policy; the server SHOULD use the same resolution as
it would use for routing decisions in this case. Similarly, the it would use for routing decisions in this case. Similarly, the
"destination" address corresponds to the alias addresses of the "destination" address corresponds to the alias addresses of the
"destinationAddress" field, and to the Q.931 information element "destinationAddress" field, and to the Q.931 information element
"Called party number." "Called party number."
The "original-destination" address corresponds to the "Redirecting The "original-destination" address corresponds to the "Redirecting
number" Q.931 information element, if it is present; otherwise it is number" Q.931 information element, if it is present; otherwise it is
the same as the "destination" address. the same as the "destination" address.
The mapping of H.323 addresses into subfields depends on the type of The mapping of H.323 addresses into subfields depends on the type of
the alias address. An additional subfield type, "alias-type", is the alias address. An additional subfield type, "alias-type", is
defined for H.323 servers, corresponding to the type of the address. defined for H.323 servers, corresponding to the type of the address.
Possible values are "dialedDigits", "h323-ID", "url-ID", Possible values are "dialedDigits", "h323-ID", "url-ID",
"transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE". "transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE".
If future versions of the H.323 specification define additional types If future versions of the H.323 specification define additional types
of alias addresses, those names MAY also be used. of alias addresses, those names MAY also be used.
In versions of H.323 prior to version 4, "dialedDigits" was known as In versions of H.323 prior to version 4, "dialedDigits" was known as
"e164". The two names SHOULD be treated as synonyms. "e164". The two names SHOULD be treated as synonyms.
The value of the "address-type" subfield for H.323 messages is "h323" The value of the "address-type" subfield for H.323 messages is "h323"
unless the alias type is "url-ID" and the URL scheme is something unless the alias type is "url-ID" and the URL scheme is something
other than h323; in this case the address-type is the URL scheme, as other than h323; in this case the address-type is the URL scheme, as
specified in Section 4.1.1 for SIP. specified in Section 4.1.1 for SIP.
An H.323-aware CPL server SHOULD map the address subfields from the An H.323-aware CPL server SHOULD map the address subfields from the
primary alias used for routing. It MAY also map subfields from other primary alias used for routing. It MAY also map subfields from other
aliases, if subfields in the primary address are not present. aliases, if subfields in the primary address are not present.
The following mappings are used for H.323 alias types: The following mappings are used for H.323 alias types:
dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and
"user" subfields are the string of digits, as is the "user" subfields are the string of digits, as is the
"entire-address" form. The "host" and "port" subfields are "entire-address" form. The "host" and "port" subfields are
not present. not present.
url-ID: the same mappings are used as for SIP, in Section 4.1.1. url-ID: the same mappings are used as for SIP, in Section 4.1.1.
h323-ID: the "user" field is the string of characters, as is the h323-ID: the "user" field is the string of characters, as is the
"entire-address" form. All other subfields are not present. "entire-address" form. All other subfields are not present.
email-ID: the "user" and "host" subfields are set to the email-ID: the "user" and "host" subfields are set to the
corresponding parts of the e-mail address. The "port" and corresponding parts of the e-mail address. The "port" and
"tel" subfields are not present. The "entire-address" form "tel" subfields are not present. The "entire-address" form
corresponds to the entire e-mail address. corresponds to the entire e-mail address.
transportID: if the TransportAddress is of type "ipAddress," transportID: if the TransportAddress is of type "ipAddress,"
"ipSourceRoute," or "ip6Address," the "host" subfield is "ipSourceRoute," or "ip6Address," the "host" subfield is set
set to the "ip" element of the sequence, translated into to the "ip" element of the sequence, translated into the
the standard IPv4 or IPv6 textual representation, and the standard IPv4 or IPv6 textual representation, and the "port"
"port" subfield is set to the "port" element of the subfield is set to the "port" element of the sequence
sequence represented in decimal. The "tel" and "user" represented in decimal. The "tel" and "user" fields are not
fields are not present. The "entire-address" form is not present. The "entire-address" form is not defined. The
defined. The representation and mapping of transport representation and mapping of transport addresses is not
addresses is not defined for non-IP addresses. defined for non-IP addresses.
H.323 version 4 [16] defines an "h323" URI scheme. This appendix H.323 [16] defines an "h323" URI scheme. This appendix defines a
defines a mapping for these URIs onto the CPL "address-switch" mapping for these URIs onto the CPL "address-switch" subfields, as
subfields, as given in Section 4.1. This definition is also given in Section 4.1. This definition is also available as RFC 3508
available as RFC 3508 [24], which is an excerpt from the H.323 [24], which is an excerpt from the H.323 specification.
specification.
For h323 URIs, the "user", "host", and "port" subfields are set to For h323 URIs, the "user", "host", and "port" subfields are set to
the corresponding parts of the H.323 URL. The "tel" subfield is not the corresponding parts of the H.323 URL. The "tel" subfield is not
present. The "entire-address" form corresponds to the entire URI. present. The "entire-address" form corresponds to the entire URI.
This mapping MAY be used both for h323 URIs in an h323 "url-ID" This mapping MAY be used both for h323 URIs in an h323 "url-ID"
address alias, and for h323 URIs in SIP messages. address alias, and for h323 URIs in SIP messages.
B.2 Usage of "string-switch" with H.323 B.2. Usage of "string-switch" with H.323
For H.323, the "string-switch" node (see Section 4.2) is used as For H.323, the "string-switch" node (see Section 4.2) is used as
follows. The field "display" corresponds to the Q.931 information follows. The field "display" corresponds to the Q.931 information
element of the same name, copied verbatim. The fields "subject", element of the same name, copied verbatim. The fields "subject",
"organization", and "user-agent" are not used and are never present. "organization", and "user-agent" are not used and are never present.
The "display" IE is conventionally used for Caller-ID The "display" IE is conventionally used for Caller-ID purposes, so
purposes, so arguably it should be mapped to the "display" arguably it should be mapped to the "display" subfield of an
subfield of an "address-match" with the field "originator". "address-match" with the field "originator". However, since a) it
However, since a) it is a message-level information is a message-level information element, not an address-level one,
element, not an address-level one, and b) the Q.931 and b) the Q.931 specification [23] says only that "[t]he purpose
specification [23] says only that "[t]he purpose of the of the Display information element is to supply display
Display information element is to supply display information that may be displayed by the user," it seems to be
information that may be displayed by the user," it seems to more appropriate to allow it to be matched in a "string-switch"
be more appropriate to allow it to be matched in a instead.
"string-switch" instead.
B.3 Usage of "language-switch" with H.323 B.3. Usage of "language-switch" with H.323
The language-ranges for the "language-switch" switch are obtained The language-ranges for the "language-switch" switch are obtained
from the H.323 UUIE "language". The switch is not-present if the from the H.323 UUIE "language". The switch is not-present if the
initial message did not contain this UUIE. initial message did not contain this UUIE.
B.4 Usage of "priority-switch" with H.323 B.4. Usage of "priority-switch" with H.323
All H.323 messages are considered to have priority "normal" for the All H.323 messages are considered to have priority "normal" for the
purpose of a priority switch (see Section 4.5). purpose of a priority switch (see Section 4.5).
B.5 Usage of "location" with H.323 B.5. Usage of "location" with H.323
Locations in explicit location nodes (Section 5.1) are specified as Locations in explicit location nodes (Section 5.1) are specified as
URLs. Therefore, all locations added in this manner are interpreted URLs. Therefore, all locations added in this manner are interpreted
as being of alias type "url-ID" in H.323. as being of alias type "url-ID" in H.323.
Specifications of other H.323 address alias types will require a CPL Specifications of other H.323 address alias types will require a CPL
extension (see Section 11). extension (see Section 11).
B.6 Usage of "lookup" with H.323 B.6. Usage of "lookup" with H.323
For location lookup nodes (Section 5.2), the "registration" lookup For location lookup nodes (Section 5.2), the "registration" lookup
source corresponds to the locations registered with the server using source corresponds to the locations registered with the server using
"RAS" messages. "RAS" messages.
B.7 Usage of "remove-location" with H.323 B.7. Usage of "remove-location" with H.323
Location removal nodes (Section 5.3) remove addresses with alias type Location removal nodes (Section 5.3) remove addresses with the alias
"url-ID" using verbatim string matching on the URLs. If a "tel" URL type "url-ID" using verbatim string matching on the URLs. If a "tel"
is specified as the location, matching addresses (ignoring visual URL is specified as the location, matching addresses (ignoring visual
separators) with alias types "dialedDigits" ("e164"), "partyNumber", separators) with the alias types "dialedDigits" ("e164"),
"mobileUIM", or "Q.931IE" are also removed. No mechanism is provided "partyNumber", "mobileUIM", or "Q.931IE" are also removed. No
to remove other alias types. mechanism is provided to remove other alias types.
C The XML Schema for CPL C. The XML Schema for CPL
This section includes a full XML Schema describing the XML syntax of This section includes a full XML Schema describing the XML syntax of
CPL. Every script submitted to a CPL server SHOULD comply with this CPL. Every script submitted to a CPL server SHOULD comply with this
XML Schema. When parsing scripts comply with the CPL DTD in earlier XML Schema. When parsing scripts comply with the CPL DTD in earlier
drafts, the DOCTYPE lines in the scripts should be ignored. Note that documents, the DOCTYPE lines in the scripts should be ignored. Note
compliance with this schema is not a sufficient condition for that compliance with this schema is not a sufficient condition for
correctness of a CPL script, as many of the conditions described in correctness of a CPL script, as many of the conditions described in
this specification are not expressible in schema syntax. Figure 31 this specification are not expressible in schema syntax. Figure 31
shows the structure of the schema. `incoming' and `outgoing' are shows the structure of the schema. 'incoming' and 'outgoing' are
defined as the substitutionGroup of the `toplevelaction'. All the defined as the substitutionGroup of the 'toplevelaction'. All the
switches are defined as the substitutionGroup of the `switch' switches are defined as the substitutionGroup of the 'switch'
element. All the actions are defined as the substitutionGroup of the element. All the actions are defined as the substitutionGroup of the
`action' element. 'action' element.
+---------+ +------+ +--address +---------+ +------+ +--address
+-+ancillary| |switch|** +--------------+ | +-not-present +-+ancillary| |switch|** +--------------+ | +-not-present
| +---------+ +---+--+ **|address-switch+-+-+-address | +---------+ +---+--+ **|address-switch+-+-+-address
| | * +--------------+ +--otherwise | | * +--------------+ +--otherwise
| +---------+ +----+ | * +--language | +---------+ +----+ | * +--language
+-+subaction+-+Node| | * +---------------+ | +-not-present +-+subaction+-+Node| | * +---------------+ | +-not-present
| +---------+ +----+ | **|language-switch|-+-+-language | +---------+ +----+ | **|language-switch|-+-+-language
| | * +---------------+ +--otherwise | | * +---------------+ +--otherwise
| | * +--priority | | * +--priority
| | * +---------------+ | +-not-present | | * +---------------+ | +-not-present
| | **|proiroty-switch|-+-+-priority | | **|priority-switch|-+-+-priority
| | * +---------------+ +--otherwise | | * +---------------+ +--otherwise
| | * +--string | | * +--string
cpl-+ | * +-------------+ | +-not-present cpl-+ | * +-------------+ | +-not-present
| | **|string-switch|-+ +-string | | **|string-switch|-+ +-string
| | * +-------------+ +--otherwise | | * +-------------+ +--otherwise
| | * +--time | | * +--time
| +--------------+ +-+--+ * +-----------+ | +-not-present | +--------------+ +-+--+ * +-----------+ | +-not-present
+-+toplevelaction+-+Node| *|time-switch|-+-+-time +-+toplevelaction+-+Node| *|time-switch|-+-+-time
+-----*--------+ +-+--+ +-----------+ +--otherwise +-----*--------+ +-+--+ +-----------+ +--otherwise
* | +--------+ +----+ * | +--------+ +----+
* | **|location+-|Node| * | **|location+-|Node|
* | +--------+ * +--------+ +----+ * | +--------+ * +--------+ +----+
* +--------+ |-+modifier|** +------+ +-success-Node * +--------+ |-+modifier|** +------+ +-success-Node
**|incoming| | +--------+ *-|lookup+-+-notfound-Node **|incoming| | +--------+ *-|lookup+-+-notfound-Node
* +--------+ | * +------+ +-failure-Node * +--------+ | * +------+ +-failure-Node
* | +---+ * +---------------+ +----+ * | +---+ * +---------------+ +----+
* +--------+ +-+Sub+-sub **|remove-location+-+Node| * +--------+ +-+Sub+-sub **|remove-location+-+Node|
*|outgoing| | +---+ +---------------+ +----+ *|outgoing| | +---+ +---------------+ +----+
+--------+ | +---+ +--------+ | +---+
| **|log+-Node | **|log+-Node
| * +---+ | * +---+
| * +----+ | * +----+
| +------+ **|mail+-Node | +------+ **|mail+-Node
+-+action|** +----+ +-busy-Node +-+action|** +----+ +-busy-Node
---- contains +------+ * +-----+ | ---- contains +------+ * +-----+ |
**|proxy+----+-noanswer-Node **|proxy+----+-noanswer-Node
**** substitutes * +-----+ | **** substitutes * +-----+ |
* +--------+ +-failure-Node * +--------+ +-failure-Node
**|redirect| | **|redirect| |
* +--------+ +-redirection-Node * +--------+ +-redirection-Node
* +------+ | * +------+ |
*|reject| +-default-Node *|reject| +-default-Node
+------+ +------+
Figure 31: The structure of the XML schema for CPL Figure 31: The structure of the XML schema for CPL
BEGIN BEGIN
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl" <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl"
xmlns="urn:ietf:params:xml:ns:cpl" xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:complexType name="TopLevelActionType" abstract="true"> <xs:complexType name="TopLevelActionType" abstract="true">
skipping to change at page 65, line 20 skipping to change at page 63, line 20
<xs:pattern value="[w|W][e|E]"/> <xs:pattern value="[w|W][e|E]"/>
<xs:pattern value="[t|T][h|H]"/> <xs:pattern value="[t|T][h|H]"/>
<xs:pattern value="[f|F][r|R]"/> <xs:pattern value="[f|F][r|R]"/>
<xs:pattern value="[s|S][a|A]"/> <xs:pattern value="[s|S][a|A]"/>
<xs:pattern value="[s|S][u|U]"/> <xs:pattern value="[s|S][u|U]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="TimeType"> <xs:complexType name="TimeType">
<xs:annotation> <xs:annotation>
<xs:documentation>Exactly one of the two attributes "dtend" and <xs:documentation>Exactly one of the two attributes "dtend" and
"duration" must occur. None of the attributes following "duration" must occur. None of the attributes following
freq are meaningful unless freq appears. freq are meaningful unless freq appears.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="dtstart" type="xs:string" use="required"> <xs:attribute name="dtstart" type="xs:string" use="required">
<xs:annotation> <xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="dtend" type="xs:string" use="optional"> <xs:attribute name="dtend" type="xs:string" use="optional">
skipping to change at page 66, line 4 skipping to change at page 64, line 4
<xs:attribute name="until" type="xs:string" use="optional"> <xs:attribute name="until" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="count" type="xs:positiveInteger" <xs:attribute name="count" type="xs:positiveInteger"
use="optional"/> use="optional"/>
<xs:attribute name="bysecond" type="xs:string" use="optional"> <xs:attribute name="bysecond" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of seconds within a <xs:documentation>Comma-separated list of seconds within a
minute. Valid values are 0 to 59.</xs:documentation> minute. Valid values are 0 to 59.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="byminute" type="xs:string" use="optional"> <xs:attribute name="byminute" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of minutes within an <xs:documentation>Comma-separated list of minutes within an
hour. Valid values are 0 to 59.</xs:documentation> hour. Valid values are 0 to 59.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="byhour" type="xs:string" use="optional"> <xs:attribute name="byhour" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of hours of the day. <xs:documentation>Comma-separated list of hours of the day.
Valid values are 0 to 23.</xs:documentation> Valid values are 0 to 23.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="byday" type="xs:string" use="optional"> <xs:attribute name="byday" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of days of the week. <xs:documentation>Comma-separated list of days of the week.
Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and
"SU". These values are not case-sensitive. Each can be "SU". These values are not case-sensitive. Each can be
preceded by a positive (+n) or negative (-n) preceded by a positive (+n) or negative (-n)
integer.</xs:documentation> integer.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="bymonthday" type="xs:string" use="optional"> <xs:attribute name="bymonthday" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of days of the month. <xs:documentation>Comma-separated list of days of the month.
Valid values are 1 to 31 or -31 to Valid values are 1 to 31 or -31 to
-1.</xs:documentation> -1.</xs:documentation>
</xs:annotation> </xs:annotation>
skipping to change at page 66, line 45 skipping to change at page 64, line 45
<xs:attribute name="byyearday" type="xs:string" use="optional"> <xs:attribute name="byyearday" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of days of the year. <xs:documentation>Comma-separated list of days of the year.
Valid values are 1 to 366 or -366 to Valid values are 1 to 366 or -366 to
-1.</xs:documentation> -1.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="byweekno" type="xs:string" use="optional"> <xs:attribute name="byweekno" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of ordinals specifying <xs:documentation>Comma-separated list of ordinals specifying
weeks of the year. Valid values are 1 to 53 or -53 to weeks of the year. Valid values are 1 to 53 or -53 to
-1.</xs:documentation> -1.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="bymonth" type="xs:string" use="optional"> <xs:attribute name="bymonth" type="xs:string" use="optional">
<xs:annotation> <xs:annotation>
<xs:documentation>Comma-separated list of months of the year. <xs:documentation>Comma-separated list of months of the year.
Valid values are 1 to 12.</xs:documentation> Valid values are 1 to 12.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
skipping to change at page 70, line 51 skipping to change at page 68, line 51
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="default" minOccurs="0"> <xs:element name="default" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:all> </xs:all>
<xs:attribute name="timeout" type="xs:positiveInteger" <xs:attribute name="timeout" type="xs:positiveInteger"
use="optional" default="20"/> use="optional" default="20"/>
<xs:attribute name="recursive" type="YesNoType" <xs:attribute name="recurse" type="YesNoType"
use="optional" default="yes"/> use="optional" default="yes"/>
<xs:attribute name="ordering" type="OrderingType" <xs:attribute name="ordering" type="OrderingType"
use="optional" default="parallel"/> use="optional" default="parallel"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="proxy" type="ProxyAction" <xs:element name="proxy" type="ProxyAction"
substitutionGroup="action"/> substitutionGroup="action"/>
<xs:complexType name="RedirectAction"> <xs:complexType name="RedirectAction">
skipping to change at page 72, line 22 skipping to change at page 70, line 22
<xs:documentation>Any toplevel action MUST NOT appear more <xs:documentation>Any toplevel action MUST NOT appear more
than once.</xs:documentation> than once.</xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:element name="cpl" type="CPLType"/> <xs:element name="cpl" type="CPLType"/>
</xs:schema> </xs:schema>
END END
D Changes from Earlier Versions Normative References
[Note to RFC Editor: please remove this appendix before
publication as an RFC.]
D.1 Changes from Draft -08
o Define the URI for schema registration as
urn:ietf:params:xml:schema:cpl.
o Change draft-mealling-iana-xmlns-registry to RFC 3688.
o Clarify how to define XML namespaces for CPL extensions.
D.2 Changes from Draft -07
o Added Intellectual Property Statement.
o Included filenames in the references to I-Ds.
o Modified remove-location node description.
o Moved the CPL example scripts out of the IANA registration
part.
o Fixed bugs in URN registration XML.
o Added an IANA registration for CPL schema.
o Fixed bugs in the CPL schema for the format of xs:annotations
element.
o Modified CPL schema for backward compatibilities to the CPL
DTD.
D.3 Changes from Draft -06
The changebars in the Postscript and PDF versions of this document
indicate significant changes from this version.
o Added Xiaotao Wu as a co-author.
o Converted CPL DTD to CPL XML Schema.
o Dropped all features dependent on caller preferences and
callee capabilities.
o Added an XML namespace URN urn:ietf:params:xml:ns:cpl and
registration information for it.
o Separated normative and informative references.
o Updated some references; most notably, updated SIP reference
to RFC 3261. Updated text to reflect changes in these
references.
o Allowed servers more flexibility about recognizing SIP
addresses as telephone numbers.
o Restored some text, in the definition of "interval",
accidentally omitted when sub-day recurrences were re-added in
draft -05.
o Clarified the usages of "lookup" and "remove-location" with
SIP, and "remove-location" with H.323.
o Updated address of the IPTel working group's mailing list.
o Improved wording, cleaned up formatting, and corrected typos.
D.4 Changes from Draft -05
o Clarified that switch nodes are allowed to be degenerate --
they can have no outputs, and they can have only an
"otherwise" output.
o Clarified the (non-) usage of the special language-range "*".
o Clarified that the Candidate Start Time can be equal to the
call time.
o Modified the DTD to require that the "not-present" output
appear only once.
o Added DTD entries for the "time-switch" attributes re-added in
draft -05.
o Updated the reference to ISO 8601 to cite 8601:2000.
o Updated all H.323 references to cite H.323v4.
o Corrected some spelling errors.
D.5 Changes from Draft -04
o Broke out language switches into their own switch node.
o Restored the full iCalendar COS recurrence specification.
Added text describing the consequences of this for
implementors, and expanded somewhat on the recurrence
algorithm.
o Clarified when time zones are resolved.
o Spelled out "iCalendar" rather than abbreviating it "iCal."
o Clarified some points about host and port matching.
o Whole-address matching in SIP uses the standard SIP URL-match
rules.
o Specified that proxy and lookup timeouts are positive integer
number of seconds.
o Specified that "subaction" "id" parameters must be unique.
o Corrected example scripts' namespace and DTD references
indicating older drafts of this document.
o Deleted an unused subaction from the "Call Forward: Redirect
and Default" example script.
o Made empty switches legal in the DTD.
o Made the legal values for the "proxy" "ordering" parameter
explicit in the DTD.
o Made the "success" output of "lookup" optional in the DTD. It
can trigger a default action, just like anything else.
o Clarified that the time-switch resolution algorithm is non-
normative.
o Updated references to previously-unpublished RFCs, now
published.
o Thanked Richard Gumpertz.
D.6 Changes from Draft -03
o Removed an obsolete reference to a usage in examples which
wasn't actually used anywhere.
o Added forward references to "remove-location", "mail" and
"log", as well as "location", in the XML syntax as examples of
nodes that don't have explicit output tags.
o Made the usage of some terminology more consistent: "output"
vs. "next node"; "action" vs. "operation" vs. "behavior";
"sub-actions" and "subactions"; "other operations" and "non-
call operations" and "non-signalling operations"; "meta-
information" and "ancillary information."
o The "tel" subfield of addresses which come from sip URIs
should have its visual separators stripped.
o The default value of the "priority" value of the "location"
node is 1.0.
o Corrected the media type of a set of URIs to text/uri-list,
and added a reference to it.
o Added some wording clarifying how URI-based lookup queries
work.
o Corrected the syntax of "duration" parameter in the examples.
o Performed some pre-RFC textual cleanups (e.g. removing the
reference to the Internet-Draft URL from the XML namespace
identifier).
o Re-worded text in the description of the Ancillary tag which
implied that information could be placed in that node in the
base CPL specification. Clarified that the tag is for use by
extensions only.
o Expunged some references to sub-daily recurrences which had
accidentally been left in the text.
o Updated bibliography to refer to the latest versions of the
cited documents.
o Fixed a number of typographical errors.
D.7 Changes from Draft -02
o Reduced time-switches from the full iCal recurrence to an iCal
subset. Added an appendix giving an algorithm to resolve
time-switches.
o Added the extension mechanism.
o Made explicit how each node is dependent on protocol handling.
Separated out protocol-specific information -- for SIP in
subsections of the main text, for H.323 in a non-normative
appendix.
o Clarified some address mapping rules for H.323.
o Corrected the name of the "Redirecting number" in Q.931.
o Clarified that address matching on the "password" subfield is
case-sensitive.
o Added a recommendation that "tzid" labels follow the usage of
the Olson database.
o Added the "priority" parameter to "location" nodes.
o Added the "default" output to the "proxy" node.
o Made the meaning of the "proxy" node's outputs explicit.
o Added suggested content for the e-mail generated by "mail"
nodes.
o Pointed out that "&" must be escaped in XML (this is relevant
for "mailto" URIs).
o Pointed out that log names are logical names, and should not
be interpreted as verbatim filenames.
o Added some examples.
o Clarified some wording.
o Fixed some typographical errors.
D.8 Changes from Draft -01
o Completely re-wrote changes to time switches: they are now
based on iCal rather than on crontab.
o Timezone references are now defined within time switches
rather than in the ancillary section. The ancillary section is
now empty, but still defined for future use. To facilitate
this, an explicit "ancillary" tag was added.
o Added XML document type identifiers (the public identifier and
the namespace), and MIME registration information.
o Clarified that the "not-present" output can appear anywhere in
a switch.
o Re-wrote H.323 address mappings. Added the "alias-type"
subfield for H.323 addresses.
o Added the "language" and "display" string switch fields.
o Clarified why useless "not-present" outputs can appear in time
and priority switches.
o Added the "clear" parameter to "location" and "lookup" nodes.
(It had been in the DTD previously, but not in the text.)
o Weakened support for non-validating scripts from SHOULD to
MAY, to allow the use of validating XML parsers.
o Added "redirection" output of "proxy" nodes.
o Clarified some aspects of how proxy nodes handle the location
set.
o Added "permanent" parameter of "redirect" nodes.
o Add example script for outgoing call screening (from Kenny
Hom)
o Updated example scripts to use the public identifier.
o Add omitted tag to example script for call forward busy/no
answer
o Clarified in introduction that this document mainly deals with
servers.
o Updated reference to RFC 2824 now that it has been published.
o Added explanatory text to the introduction to types of nodes.
o Numerous minor clarifications and wording changes. [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
o Fixed copy-and-paste errors, typos. [2] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C Recommendation REC-xml-20040204, World Wide Web Consortium
(W3C), February 2004. Available at http://www.w3.org/XML/.
D.9 Changes from Draft -00 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
o Added high-level structure; script doesn't just start at a [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
first action. Addressing Architecture", RFC 3513, April 2003.
o Added a section giving a high-level explanation of the [5] Davis, M. F. and M. Duerst, "Unicode Normalization Forms",
location model. Unicode Standard Annex #15, Unicode Consortium, April 2003.
Revision 23; part of Unicode 4.0.0. Available at
http://www.unicode.org/unicode/reports/tr15/.
o Added informal syntax specifications for each tag so people [6] Davis, M. F., "Case Mappings", Unicode Standard Annex #21,
don't have to try to understand a DTD to figure out the Unicode Consortium, March 2001. Revision 5; part of Unicode
syntax. 3.2.0. Available at
http://www.unicode.org/unicode/reports/tr21/.
o Added subactions, replacing the old "link" tags. Links were [7] Alvestrand, H., "Tags for the Identification of Languages", BCP
far too reminiscent of gotos for everyone's taste. 47, RFC 3066, January 2001.
o Added ancillary information section, and timezone support. [8] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
o Added not-present switch output. [9] Eggert, P., "Sources for Time Zone and Daylight Saving Time
Data". Available at http://www.twinsun.com/tz/tz-link.htm.
o Added address switches. [10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary
for URN Resolution", RFC 2483, January 1999.
o Made case-insensitive string matching locale-independent. [11] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C
Recommendation REC-xml-names-19990114, World Wide Web Consortium
(W3C), January 1999. Available at http://www.w3.org/TR/REC-
xml-names/.
o Added priority switch. [12] Moats, R., "URN Syntax", RFC 2141, May 1997.
o Deleted "Other switches" section. None seem to be needed. [13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
o Unified "url" and "source" parameters of "lookup". [14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
o Added caller prefs to "lookup". [15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
o Added location filtering. Informative References
o Eliminated "clear" parameter of location setting. Instead, [16] International Telecommunication Union, "Packet-based multimedia
"proxy" "eats" locations it has used. communication systems", Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, July 2003.
o Added "recurse" and "ordering" parameters to "proxy". [17] Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
o Added default value of "timeout" for proxy. [18] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C Recommendation REC-html401-19991224, World
Wide Web Consortium (W3C), December 1999. Available at
http://www.w3.org/TR/html4/.
o Renamed "response" to "reject". [19] ISO (International Organization for Standardization),
"Information processing -- Text and office systems -- Standard
Generalized Markup Language (SGML)", ISO Standard ISO
8879:1986(E), International Organization for Standardization,
Geneva, Switzerland, October 1986.
o Changed "notify" to "mail", and simplified it. [20] ISO (International Organization for Standardization), "Data
elements and interchange formats -- Information interchange --
Representation of dates and times", ISO Standard ISO
8601:2000(E), International Organization for Standardization,
Geneva, Switzerland, December 2000.
o Simplified "log", eliminating its "failure" output. [21] DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML
Linking Language (XLink) Version 1.0", W3C Recommendation REC-
xlink-20010627, World Wide Web Consortium (W3C), June 2001.
Available at http://www.w3.org/TR/xlink/.
o Added description of default actions at various times during [22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
script processing. January 2001.
o Updated examples for these changes. [23] International Telecommunication Union, "Digital Subscriber
Signalling System No. 1 (DSS 1) - ISDN user-network interface
layer 3 specification for basic call control", Recommendation
Q.931, International Telecommunication Union, Geneva,
Switzerland, March 1993.
o Updated DTD to reflect new syntax. [24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
Registration", RFC 3508, April 2003.
E Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: lennox@cs.columbia.edu
EMail: lennox@cs.columbia.edu
Xiaotao Wu Xiaotao Wu
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: xiaotaow@cs.columbia.edu
EMail: xiaotaow@cs.columbia.edu
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu
F Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[2] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup EMail: schulzrinne@cs.columbia.edu
language (XML) 1.0 (second edition)," W3C Recommendation REC-xml-
20001006, World Wide Web Consortium (W3C), Oct. 2000. Available at
http://www.w3.org/XML/.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] R. Hinden and S. E. Deering, "IP version 6 addressing
architecture," RFC 2373, Internet Engineering Task Force, July 1998.
[5] M. F. Davis and M. Duerst, "Unicode normalization forms," Unicode
Technical Report 15, Unicode Consortium, Aug. 2000. Revision 19;
part of Unicode 3.0.1. Available at
http://www.unicode.org/unicode/reports/tr15/.
[6] M. F. Davis, "Case mappings," Unicode Technical Report 21,
Unicode Consortium, Oct. 2000. Revision 4.3. Available at
http://www.unicode.org/unicode/reports/tr21/.
[7] H. Alvestrand, "Tags for the identification of languages," RFC
3066, Internet Engineering Task Force, Jan. 2001.
[8] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
core object specification (icalendar)," RFC 2445, Internet
Engineering Task Force, Nov. 1998.
[9] P. Eggert, "Sources for time zone and daylight saving time data."
Available at http://www.twinsun.com/tz/tz-link.htm.
[10] M. Mealling and R. W. Daniel, "URI resolution services necessary
for URN resolution," RFC 2483, Internet Engineering Task Force, Jan.
1999.
[11] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C
Recommendation REC-xml-names-19900114, World Wide Web Consortium
(W3C), Jan. 1999. Available at http://www.w3.org/TR/REC-xml-names/.
[12] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
Force, May 1997.
[13] R. Moats, "A URN namespace for IETF documents," RFC 2648,
Internet Engineering Task Force, Aug. 1999.
[14] M. Mealling, "The ietf xml registry," RFC 3688, Internet
Engineering Task Force, Jan. 2004.
[15] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC
3023, Internet Engineering Task Force, Jan. 2001.
G Informative References
[16] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Nov. 2000.
[17] J. Lennox and H. Schulzrinne, "Call processing language
framework and requirements," RFC 2824, Internet Engineering Task
Force, May 2000.
[18] D. Raggett, A. Le Hors, and I. Jacobs, "HTML 4.01
specification," W3C Recommendation REC-html401-19991224, World Wide
Web Consortium (W3C), Dec. 1999. Available at
http://www.w3.org/TR/html4/.
[19] ISO (International Organization for Standardization),
"Information processing -- text and office systems -- standard
generalized markup language (SGML)," ISO Standard ISO 8879:1986(E),
International Organization for Standardization, Geneva, Switzerland,
Oct. 1986.
[20] ISO (International Organization for Standardization), "Data
elements and interchange formats -- information interchange --
representation of dates and times," ISO Standard ISO 8601:2000(E),
International Organization for Standardization, Geneva, Switzerland,
Dec. 2000.
[21] S. DeRose, E. Maler, D. Orchard, and B. Trafford, "XML linking Full Copyright Statement
language (XLink) version 1.0," W3C Candidate Recommendation CR-
xlink-20000703, World Wide Web Consortium (W3C), July 2000.
Available at http://www.w3.org/TR/xlink/.
[22] T. Showalter, "Sieve: A mail filtering language," RFC 3028, Copyright (C) The Internet Society (2004).
Internet Engineering Task Force, Jan. 2001.
[23] International Telecommunication Union, "Digital subscriber This document is subject to the rights, licenses and restrictions
signalling system no. 1 (DSS 1) - ISDN user-network interface layer 3 contained in BCP 78, and except as set forth therein, the authors
specification for basic call control," Recommendation Q.931, retain all their rights.
International Telecommunication Union, Geneva, Switzerland, Mar.
1993.
[24] O. Levin, "H.323 uniform resource locator (URL) scheme This document and the information contained herein are provided on an
registration," RFC 3508, Internet Engineering Task Force, Apr. 2003. "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the IETF's procedures with respect to rights in IETF Documents can
standards-related documentation can be found in BCP-11. Copies of be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement
Copyright (c) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Acknowledgement
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an Funding for the RFC Editor function is currently provided by the
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Internet Society.
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 437 change blocks. 
1464 lines changed or deleted 1097 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/