Request for Comments: 3880 X. Wu
Category: Standards Track H. Schulzrinne
Columbia University
October 2004
Call Processing Language (CPL):
A Language for User Control of Internet Telephony Services
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines the Call Processing Language (CPL), a language
to describe and control Internet telephony services. It is designed
to be implementable on either network servers or user agents. It is
meant to be simple, extensible, easily edited by graphical clients,
and independent of operating system or signalling protocol. It is
suitable for running on a server where users may not be allowed to
execute arbitrary programs, as it has no variables, loops, or ability
to run external programs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions of This Document. . . . . . . . . . . . . . 4
2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4
2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4
2.2. Abstract Structure of a Call Processing Action. . . . . 5
2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6
2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6
3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7
4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9
4.1.1. Usage of "address-switch" with SIP. . . . . . . 11
4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Usage of "string-switch" with SIP . . . . . . . 13
4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14
4.3.1. Usage of "language-switch" with SIP . . . . . . 14
4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15
4.4.1. iCalendar differences and implementation
issues. . . . . . . . . . . . . . . . . . . . . 20
4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21
4.5.1. Usage of "priority-switch" with SIP . . . . . . 22
5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23
5.1.1. Usage of "location" with SIP. . . . . . . . . . 23
5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24
5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25
5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25
5.3.1. Usage of "remove-location" with SIP . . . . . . 26
6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26
6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29
6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30
6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30
7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31
7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1.1. Suggested Content of Mailed Information . . . . 32
7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34
10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35
11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37
12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38
12.3. Example: Call Forward: Redirect and Default . . . . . . 39
12.4. Example: Call Screening . . . . . . . . . . . . . . . . 40
12.5. Example: Priority and Language Routing. . . . . . . . . 41
12.6. Example: Outgoing Call Screening. . . . . . . . . . . . 42
12.7. Example: Time-of-day Routing. . . . . . . . . . . . . . 43
12.8. Example: Location Filtering . . . . . . . . . . . . . . 44
12.9. Example: Non-signalling Operations. . . . . . . . . . . 45
12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46
12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48
13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49
14.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49
14.2. Schema registration . . . . . . . . . . . . . . . . . . 50
14.3. MIME Registration . . . . . . . . . . . . . . . . . . . 50
15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51
A. An Algorithm for Resolving Time Switches . . . . . . . . . . . 52
B. Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53
B.1. Usage of "address-switch" with H.323. . . . . . . . . . 53
B.2. Usage of "string-switch" with H.323 . . . . . . . . . . 55
B.3. Usage of "language-switch" with H.323 . . . . . . . . . 55
B.4. Usage of "priority-switch" with H.323 . . . . . . . . . 55
B.5. Usage of "location" with H.323. . . . . . . . . . . . . 56
B.6. Usage of "lookup" with H.323. . . . . . . . . . . . . . 56
B.7. Usage of "remove-location" with H.323 . . . . . . . . . 56
C. The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56
Normative References . . . . . . . . . . . . . . . . . . . . . . . 70
Informative References . . . . . . . . . . . . . . . . . . . . . . 71
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction
The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is not tied to
any particular signalling architecture or protocol; it is anticipated
that it will be used with both the Session Initiation Protocol (SIP)
[1] and H.323 [16].
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
Internet telephony servers. The intention is to make it impossible
for users to do anything more complex (and dangerous) than describe
Internet telephony services. The language is not Turing-complete,
and provides no way to write loops or recursion.
CPL is also designed to be easily created and edited by graphical
tools. It is based on the Extensible Markup Language (XML) [2], so
parsing it is easy and many parsers for it are publicly available.
The structure of the language maps closely to its behavior, so an
editor can understand any valid script, even ones written by hand.
The language is also designed so that a server can easily confirm the
validity of a script when the server receives it, rather than
discovering problems while a call is being processed.
Implementations of CPL are expected to take place both in Internet
telephony servers and in advanced clients; both can usefully process
and direct users’ calls. This document primarily addresses the usage
in servers. A mechanism will be needed to transport scripts between
clients and servers; this document does not describe such a
mechanism, but related documents will.
The framework and requirements for the CPL architecture are described
in RFC 2824, "Call Processing Language Framework and Requirements"
[17].
1.1. Conventions of This Document
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[3] and indicate requirement levels for compliant CPL
implementations.
Some paragraphs are indented, like this; they give motivations of
design choices, advice to implementors, or thoughts on future
development of or extensions to CPL. They are not essential to
the specification of the language, and are non-normative.
2. Structure of CPL Scripts
2.1. High-level Structure
A CPL script consists of two types of information: ancillary
information about the script, and call processing actions.
A call processing action is a structured tree that describes the
operations and decisions a telephony signalling server performs on a
call set-up event. There are two types of call processing actions:
top-level actions and subactions. Top-level actions are actions that
are triggered by signalling events that arrive at the server. Two
top-level actions are defined: "incoming", the action performed when
a call arrives whose destination is the owner of the script, and
"outgoing", the action performed when a call arrives whose originator
is the owner of the script.
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
to correctly process a script, but which does not directly describe
any operations or decisions. Currently, no ancillary information is
defined, but the section is reserved for use by extensions.
2.2. Abstract Structure of a Call Processing Action
Abstractly, a call processing action is described by a collection of
nodes that describe operations that can be performed or decisions
that can be made. A node may have several parameters, which specify
the precise behavior of the node; they usually also have outputs,
which depend on the result of the decision or action.
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
designed so that actions can be conveniently edited graphically using
this representation. Nodes are arranged in a tree, starting at a
single root node; outputs of nodes are connected to additional nodes.
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
node, the server follows one of the node’s outputs, and the
subsequent node it points to is performed; this process continues
until a node with no specified outputs is reached. Because the graph
is acyclic, this will occur after a bounded and predictable number of
nodes are visited.
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
action. Some nodes have specific default behavior associated with
them; for others, the default behavior is implicit in the underlying
signalling protocol, or can be configured by the administrator of the
server. For further details on this, see Section 10.
_________________ ___________________ ________ busy
| Address-switch | | location | | proxy |--------\
Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout|
| subfield: host | / | example.com | | 10s |--------|
|-----------------|/ |___________________| | | failure|
| subdomain-of: | |________|--------|
| example.com | |
|-----------------| ___________________________________________/
| otherwise | /........................................
| |\|. Voicemail .
|_________________| \. ____________________ .
->| location | __________ .
. | url: sip:jones@ | | redirect | .
. | voicemail. |->| | .
. | example.com | |__________| .
. |____________________| .
........................................
Figure 1: Sample CPL Action: Graphical Version
2.3. Location Model
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
be directed. Instead, this set of locations is stored as an implicit
global variable throughout the execution of a processing action (and
its subactions). This allows locations to be retrieved from external
sources, filtered, and so forth, without requiring general language
support for such operations (which could harm the simplicity and
tractability of understanding the language). The specific operations
which add, retrieve, or filter location sets are given in Section 5.
For the incoming top-level call processing action, the location set
is initialized to the empty set. For the outgoing action, it is
initialized to the destination address of the call.
2.4. XML Structure
Syntactically, CPL scripts are represented by XML documents. XML is
thoroughly specified by the XML specification [2], and implementors
of this specification should be familiar with that document.
However, as a brief overview, XML consists of a hierarchical
structure of tags; each tag can have a number of attributes. It is
visually and structurally very similar to HTML [18], as both
languages are simplifications of the earlier and larger standard SGML
[19].
See Figure 2 for the XML document corresponding to the graphical
representation of the CPL script in Figure 1. Both nodes and outputs
in CPL are represented by XML tags; parameters are represented by XML
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).
The connection between the output of a node and another node is
represented by enclosing the tag representing the pointed-to node
inside the tag for the outer node’s output. Convergence (several
outputs pointing to a single node) is represented by subactions,
discussed further in Section 8.
The higher-level structure of a CPL script is represented by tags
corresponding to each piece of ancillary information, subactions, and
top-level actions, in order. This higher-level information is all
enclosed in a special tag "cpl", the outermost tag of the XML
document.
A complete XML Schema for CPL is provided in Appendix C. The
remainder of the main sections of this document describe the
semantics of CPL, while giving its syntax informally. For the formal
syntax, please see the appendix.
3. Script Structure: Overview
As mentioned, a CPL script consists of ancillary information,
subactions, and top-level actions. The full syntax of the "cpl" node
is given in Figure 3.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<redirect />
</location>
</subaction>
<incoming>
<address-switch field="origin" subfield="host">
<address subdomain-of="example.com">
<location url="sip:jones@example.com">
<proxy timeout="10">
<busy> <sub ref="voicemail" /> </busy>
<noanswer> <sub ref="voicemail" /> </noanswer>
<failure> <sub ref="voicemail" /> </failure>
</proxy>
</location>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</incoming>
</cpl>
Figure 2: Sample CPL Script: XML Version
Tag: "cpl"
Parameters: None
Sub-tags: "ancillary" See Section 9
"subaction" See Section 8
"outgoing" Top-level actions to take on this user’s
outgoing calls
"incoming" Top-level actions to take on this user’s
incoming calls
Figure 3: Syntax of the top-level "cpl" tag
Call processing actions, both top-level actions and subactions,
consist of a tree of nodes and outputs. Nodes and outputs are both
described by XML tags. There are four categories of CPL nodes:
switches, which represent choices a CPL script can make, location
modifiers, which add or remove locations from the location set,
signalling operations, which cause signalling events in the
underlying protocol, and non-signalling operations, which trigger
behavior which does not effect the underlying protocol.
4. Switches
Switches represent choices a CPL script can make, based on either
attributes of the original call request or items independent of the
call.
All switches are arranged as a list of conditions that can match a
variable. Each condition corresponds to a node output; the output
points to the next node that should be executed if the condition is
true. The conditions are tried in the order they are presented in
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.
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
present in the original call setup request. (In this document, this
is sometimes described by saying that the information is "absent".)
The output "otherwise", which MUST be the last output specified if it
is present, matches if no other condition matched.
If no condition matches and no "otherwise" output was present in the
script, the default script behavior is taken. See Section 10 for
more information on this.
Switches MAY contain no outputs. They MAY only contain an
"otherwise" output.
Such switches are not particularly useful, but might be created by
tools which automatically generate CPL scripts.
4.1. Address Switches
Address switches allow a CPL script to make decisions based on one of
the addresses present in the original call request. They are
summarized in Figure 4.
Node: "address-switch"
Outputs: "address" Specific addresses to match
Parameters: "field" "origin", "destination",
or "original-destination"
"subfield" "address-type", "user", "host",
"port", "tel", or "display"
(also: "password" and "alias-type")
Output: "address"
Parameters: "is" Exact match
"contains" Substring match (for "display" only)
"subdomain-of" Sub-domain match (for "host", "tel")
Figure 4: Syntax of the "address-switch" node
Address switches have two node parameters: "field" and "subfield".
The mandatory "field" parameter allows the script to specify which