draft-ietf-iptel-cpl-00.txt   draft-ietf-iptel-cpl-01.txt 
Internet Engineering Task Force IPTEL WG Internet Engineering Task Force IPTEL WG
Internet Draft Lennox/Schulzrinne Internet Draft Lennox/Schulzrinne
ietf-iptel-cpl-00.txt Columbia University draft-ietf-iptel-cpl-01.txt Columbia University
February 26, 1999 March 10, 2000
Expires: September 1999 Expires: September 2000
CPL: A Language for User Control of Internet Telephony Services CPL: A Language for User Control of Internet Telephony Services
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
To view the list Internet-Draft Shadow Directories, see The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
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 designed to describe and control Internet telephony services. It is designed to
be implementable on either network servers or user agent servers. It be implementable on either network servers or user agent servers. It
is meant to be simple, extensible, easily edited by graphical is meant to be simple, extensible, easily edited by graphical
clients, and independent of operating system or signalling protocol. clients, and independent of operating system or signalling protocol.
It is suitable for running on a server where users may not be allowed It is suitable for running on a server where users may not be allowed
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 SIP [1] and H.323 [2]. that it will be used with both SIP [1] and H.323 [2].
The CPL is powerful enough to describe a large number of services and The 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 describing
Internet telephony services. The language is not Turing-complete, and Internet telephony services. The language is not Turing-complete, and
provides no way to write a loop or a function. provides no way to write loops or recursion.
The CPL is also designed to be easily created and edited by graphical The CPL is also designed to be easily created and edited by graphical
tools. It is based on XML [3], so parsing it is easy and many tools. It is based on XML [3], so parsing it is easy and many
parsers for it are publicly available. The structure of the language parsers for it are publicly available. The structure of the language
maps closely to its behavior, so an editor can understand any valid maps closely to its behavior, so an editor can understand any valid
script, even ones written by hand. The language is also designed so script, even ones written by hand. The language is also designed so
that a server can easily confirm scripts' validity at the time they that a server can easily confirm scripts' validity at the time they
are delivered to it, rather that discovering them while a call is are delivered to it, rather that discovering them while a call is
being processed. being processed.
Implementations of the CPL are expected to take place both in Implementations of the CPL are expected to take place both in
Internet telephony servers and in advanced clients; both can usefully Internet telephony servers and in advanced clients; both can usefully
process and direct users' calls. In the former case, a mechanism will process and direct users' calls. In the former case, a mechanism will
be needed to transport scripts between clients and servers; this be needed to transport scripts between clients and servers; this
document does not describe such a mechanism, but related documents document does not describe such a mechanism, but related documents
will. will.
1.1 Conventions Of This Document The framework and requirements for the CPL architecture are described
in the document "Call Processing Language Framework and
Requirements," which will be an Informational RFC; it is currently
available as the Internet-Draft draft-ietf-iptel-cpl-framework-02
[4].
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 [4] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and
indicate requirement levels for compliant CPL implementations. indicate requirement levels for compliant CPL implementations.
In examples, non-XML strings such as -action1- , -action2- , and so In examples, non-XML strings such as -action1, -action2, and so
forth, are sometimes used. These represent further parts of the forth, are sometimes used. These represent further parts of the
script which are not relevant to the example in question. script which are not relevant to the example in question.
Some paragraphs are indented, like this; they give Some paragraphs are indented, like this; they give
motivations of design choices, or questions for future motivations of design choices, or questions for future
discussion in the development of the CPL, and are not discussion in the development of the CPL, and are not
essential to the specification of the language. essential to the specification of the language.
2 Structure of CPL scripts 2 Structure of CPL scripts
2.1 Abstract structure 2.1 High-level structure
Abstractly, a CPL script is described by a collection of nodes, which
describe actions that can be performed or choices which 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 condition or action.
For a graphical representation of a CPL script, see figure 1. Nodes 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
decisions and actions a telephony signalling server performs on a
call set-up event. There are two types of call processing actions:
top-level actions are actions that are triggered by signalling events
that arrive at the server. Two top-level action names 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. Sub-actions
are actions which can be called from other actions. The CPL forbids
sub-actions from being called recursively: see section 8.
Note: The names "action," "sub-action," and "top-level
action" are probably not ideal. Suggestions for better
names for these concepts are welcomed.
Ancillary information is information which is necessary for a server
to correctly process a script, but which does not directly describe
any actions. Currently, the only type of ancillary information
defined is timezone definitions; see section 9.
2.2 Abstract structure of a call processing action
Abstractly, a call processing action is described by a collection of
nodes, which describe actions that can be performed or choices which
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 condition 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; the CPL and outputs can be thought of informally as boxes and arrows; the CPL
is designed so that it can be conveniently edited graphically using is designed so that actions can be conveniently edited graphically
this representation. Nodes are arranged in a directed acyclic graph, using this representation. Nodes are arranged in a tree, starting at
starting at a single root node; outputs of nodes are connected to a single root node; outputs of nodes are connected to additional
additional nodes. When a CPL script is run, the action or condition nodes. When an action is run, the action or condition described by
described by the root node is performed; based on the result of that the top-level node is performed; based on the result of that node,
node, the server follows one of the node's outputs, and that action the server follows one of the node's outputs, and that action or
or condition is performed; this process continues until a node with condition is performed; this process continues until a node with no
no specified outputs is reached. Because the graph is acyclic, this specified outputs is reached. Because the graph is acyclic, this
will occur after a bounded and predictable number of nodes are will occur after a bounded and predictable number of nodes are
visited. visited.
If an output to a node is not specified, it indicates that the CPL If an output to a node is not specified, it indicates that the CPL
server should perform a node- or protocol-specific action. Some nodes server should perform a node- or protocol-specific action. Some nodes
have specific default actions associated with them; for others, the have specific default actions associated with them; for others, the
default action is implicit in the underlying signalling protocol, or default action is implicit in the underlying signalling protocol, or
can be configured by the administrator of the server. can be configured by the administrator of the server. For further
details on this, see section 10.
_________________ ___________________ _______ _________________ ___________________ ________ busy
Call --->| String-switch | | location | | proxy |---------\ | Address-switch | | location | | proxy |--------\
| field: from | ->| url: sip:jones@ |--->| | busy | Call --->| field: origin | ->| url: sip:jones@ |--->|timeout:| timeout|
|-----------------| / | example.com | | |---------| | subfield: host | / | example.com | | 10s |--------|
| match: |/ |___________________| | | timeout | |-----------------|/ |___________________| | | failure|
| *@example.com | |_______|---------| | subaddress-of: | |________|--------|
|-----------------| failure | | example.com | |
| otherwise | ____________________________________________/ |-----------------| _____________________________________________/
| |\ / ____________________ __________ | otherwise | /..........................................
|_________________| \| | location | | redirect | | |\|. Voicemail .
->| url: sip:jones@ |--->| | |_________________| \. ____________________ .
| voicemail. | |__________| ->| location | __________ .
| example.com | . | url: sip:jones@ | | redirect | .
| merge: clear | . | voicemail. |--->| | .
|____________________| . | example.com | |__________| .
. |____________________| .
..........................................
Figure 1: Sample CPL Script: Graphical Version Figure 1: Sample CPL Action: Graphical Version
2.2 XML Structure 2.3 Location model
For flexibility, one piece of information necessary for the function
of a 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 sub-actions). This allows locations to be
retrieved from external sources, filtered, and so forth, without
requiring general language support for such actions (which could harm
the simplicity and tractability of understanding the language). The
specific actions which add, retrieve, or filter location sets are
given in section 5.
For the incoming top-level 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 Syntactically, CPL scripts are represented by XML documents. XML is
thoroughly specified by [3], and implementors of this specification thoroughly specified by [3], and implementors of this specification
should be familiar with that document, but as a brief overview, XML should be familiar with that document, but as a brief overview, XML
consists of a hierarchical structure of tags; each tag can have a consists of a hierarchical structure of tags; each tag can have a
number of attributes. It is visually and structurally very similar to number of attributes. It is visually and structurally very similar to
HTML [5], as both languages are simplifications of the earlier and HTML [6], as both languages are simplifications of the earlier and
larger standard SGML [6]. larger standard SGML [7].
See figure 2 for the XML document corresponding to the graphical See figure 2 for the XML document corresponding to the graphical
representation of a CPL script in figure 1. Both nodes and outputs in representation of the CPL script in figure 1. Both nodes and outputs
the CPL are represented by XML tags; parameters are represented by in the CPL are represented by XML tags; parameters are represented by
XML tag attributes. Typically, node tags contain output tags, and XML tag attributes. Typically, node tags contain output tags, and
vice-versa (with one exception; see section 4.1). vice-versa (with one exception; see section 2.3).
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 links, discussed outputs pointing to a single node) is represented by sub-actions,
further in section 7. The top-level node is enclosed in the special discussed further in section 8.
tag call; this is therefore the outermost tag of the XML.
The higher-level structure of a CPL script is represented by tags
corresponding to each piece of meta-information, sub-actions, 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 Document Type Declaration for the CPL is provided in A complete Document Type Declaration for the CPL is provided in
Appendix A. The remainder of the main sections of this document Appendix A. The remainder of the main sections of this document
describe the semantics of the CPL; for its syntax, please see the describe the semantics of the CPL, while giving its syntax
appendix. informally. For the formal syntax, please see the appendix.
3 Switches
Switches represent choices the CPL script can make, based on either 3 Script structure: overview
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 As mentioned, a CPL script consists of ancillary information,
variable, each with one output pointing to the next node to execute subactions, and top-level actions. The full syntax of the cpl node is
if that condition is matched. The conditions specified are tried in given in figure 3.
the order they are presented in the script; the output corresponding
to the first node to match is taken. Switches also have an optional
otherwise output, following all the other outputs, that matches if no
previous node matched. If a switch does not have an otherwise
output, and no condition matched, the server should take a default
action, just as for any other un-attached node output, as discussed
in section 2.1.
The variable to match is specified in the initial switch tag, as a Call processing actions, both top-level actions and sub-actions,
field parameter. What variables are legal depends on which switch
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd"> <!DOCTYPE cpl SYSTEM "cpl.dtd">
<call> <cpl>
<string-switch field="from"> <subaction id="voicemail">
<string matches="*@example.com"> <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"> <location url="sip:jones@example.com">
<proxy> <proxy>
<busy> <link ref="voicemail" /> </busy> <busy> <sub ref="voicemail" /> </busy>
<noanswer> <link ref="voicemail" /> </noanswer> <noanswer> <sub ref="voicemail" /> </noanswer>
<failure> <link ref="voicemail" /> </failure> <failure> <sub ref="voicemail" /> </failure>
</proxy> </proxy>
</location> </location>
</string> </address>
<otherwise> <otherwise>
<location url="sip:jones@voicemail.example.com" <sub ref="voicemail" />
merge="clear" id="voicemail">
<redirect />
</location>
</otherwise> </otherwise>
</string-switch> </address-switch>
</call> </incoming>
</cpl>
Figure 2: Sample CPL Script: XML Version Figure 2: Sample CPL Script: XML Version
type is specified; some variables are optional, and CPL servers MAY consist of nodes and outputs. Nodes and outputs are both described by
define additional variables for each switch type. Because some XML tags. There are four categories of CPL nodes: switches , location
variables may not be supported by a server, CPL servers SHOULD modifiers , signalling actions , and non-signalling actions.
verify, at the time a script is submitted, that they support all the
variables specified in the script.
3.1 String Switch 4 Switches
String-switch is a condition which allows string matching on a string Switches represent choices a CPL script can make, based on either
variable. The node tag is named string-switch, and takes one attributes of the original call request or items independent of the
argument, field, as discussed above. The output tags are named call.
string, and take one mandatory and one optional argument. The
mandatory argument's name is one of is, contains, or matches,
indicating exact string match, substring match, or glob match of the
variable respectively.
The optional argument of string output tags is comparator, which All switches are arranged as a list of conditions that can match a
allows for internationalization of string matching. Strings to be variable. Each condition corresponds to a node output; the output
matched are always considered as strings of UTF-8 characters. CPL points to the next node to execute if the condition was true. The
servers MUST support the two comparators i;octet, indicating literal conditions are tried in the order they are presented in the script;
comparison of UTF-8 octets, and i;ascii-casemap, which indicates that the output corresponding to the first node to match is taken.
alphabetic characters in the US-ASCII range should have their upper
and lower cases compared the same. If no comparitor is specified,
i;ascii-casemap is assumed. Comparators are defined by ACAP [7]; for
more information, see that specification. CPL servers SHOULD verify
at script submission time that all requested comparators are
supported by the server.
The naming scheme of comparators is as defined by ACAP; the Node: cpl
motivation of the "i;" prefix of the comparators is Parameters: none
unclear, but it seems to be some sort of namespace for Outputs: timezone See section 9
future use. 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
Question: should comparator be an attribute of the whole Output: outgoing
string-switch as opposed to an attribute of each Parameters: none
comparison? There are arguments for either behavior.
All CPL servers MUST define the fields to and from for string Output: incoming
matching, containing URIs referring to the called and calling Parameters: none
addresses, respectively. CPL servers which run on SIP SHOULD also
define request-uri, subject, organization, priority, containing the
contents of the equivalent SIP headers, if present, and also
display-to, and display-from, containing the display names
corresponding to the called and calling addresses. CPL servers which
run on H.323 SHOULD define XXX.
Question: what are the appropriate string fields for H.323? Figure 3: Syntax of the top-level cpl tag
In this example, action1 is performed if the URL representation of There are two special switch outputs that apply to every switch type.
the caller's address exactly matches "sip:lennox@cs.columbia.edu," The output not-present is true if the variable the switch was to
action2 is performed for any string which matches any user at any match was not present in the original call. The output otherwise,
host in the cs.columbia.edu domain, and action3 is taken in all other which MUST be the last output specified, matches if no other
cases. condition matched.
<string-switch field="from"> If no condition matches and no otherwise output was present in the
<string is="sip:lennox@cs.columbia.edu"> script, the default script action is taken. See section 10 for more
-action1- information on this.
</string>
<string matches="*@*cs.columbia.edu">
-action2-
</string>
<otherwise>
-action3-
</otherwise>
</string-match>
3.2 Time Switch 4.1 Address switches
Time-switch is a condition which allows matching on the time and/or Address switches allow a CPL script to make decisions based on one of
date the triggering call was placed. Times are matched in the the addresses present in the original call request. They are
server's time zone. The node tag is named time-switch, and takes no summarized in figure 4.
arguments; the output tags are named time.
Note: while it would be nice to allow clients to specify Address switches have two node parameters: field, and subfield. The
their own time zone, there doesn't currently appear to be mandatory field parameter allows the script to specify which address
any standard registry of time zone names, and we don't want is to be considered for the switch: either the call's origin address
to have to define one just for the CPL. Leveraging off of (field "origin"), its current destination address (field
the iCalendar standard [8] would be nice, but their time "destination"), or its original destination (field "original-
zone specification seems excessively heavyweight -- it destination"), the destination the call had before any earlier
defines time zone rules explicitly (and very verbosely) in forwarding was invoked. Servers MAY define additional subfield
its own syntax. Just specifying time zones as UTC offsets values.
would be possible, but this doesn't cover daylight-savings
time rules. Thus, we currently ignore the problem.
The time outputs can take the following optional arguments: year, The optional subfield specifies what part of the address is to be
considered. The possible subfield values are: address-type, user,
host, port, tel, and display. Additional subfield values MAY be
defined: two additional ones, password and asn1 are defined
Node: address-switch
Outputs: address Specific addresses to match
Parameters: field origin, destination, or original-destination
subfield address-type, user, host, port, tel, display,
password, or asn1
Output: address
Parameters: is exact match
contains substring match (for display only)
subdomain-of sub-domain match (for host, tel only)
Figure 4: Syntax of the address-switch node
specifically for SIP and H.323 respectively, in sections 4.1.1 and
4.1.2 below. If no subfield is specified, the "entire" address is
matched; the precise meaning of this is defined for each underlying
signalling protocol.
The subfields are defined as follows:
address-type This indicates the type of the underlying address;
i.e., the URI scheme, if the address can be represented by
the URI. The types specifically discussed by this document
are sip, tel, and h323. The address type is not case-
sensitive; it is always present if the address is present.
user This subfield of the address indicates, for e-mail style
addresses, the user part of the address. For telephone
number style address, it includes the subscriber number.
This subfield is case-sensitive; it may be not present.
host This subfield of the address indicates the Internet host
name or IP address corresponding to the address, in host
name, IPv4, or IPv6 format. For host names only, subdomain
matching is supported with the subdomain-of match operator.
It is not case sensitive, and may be not present.
port This subfield indicates the TCP or UDP port number of the
address, numerically in decimal format. It is not case
sensitive, as it MUST only contain decimal digits. It may
be not present; however, for address types with default
ports, an absent port matches the default port number.
tel This subfield indicates a telephone subscriber number, if
the address contains such a number. It is not case
sensitive (the telephone numbers may contain the symbols
`A' `B' `C' and `D'), and may be not present. It may be
matched using the subdomain-of match operator. Punctuation
and separator characters in telephone numbers are
discarded.
display This subfield indicates a "display name" or user-visible
name corresponding to an address. It is a Unicode string,
and is matched using the case-insensitive algorithm
described in section 4.2. The contains operator may be
applied to it. It may be not present.
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
script with an unknown subfield is executed, the server MUST consider
the not-present output to be the valid one.
The address output tag may take exactly one of three possible
parameters, indicating the kind of matching allowed.
is An output with this match operator is followed if the
subfield being matched in the address-switch exactly
matches the argument of the operator. It may be used for
any subfield, or for the entire address if no subfield was
specified.
subdomain-of This match operator applies only for the subfields
host and tel. In the former case, it matches if the
hostname being matched is a subdomain of the domain given
in the argument of the match operator; thus,
match="example.com" would match the hostnames
"example.com", "research.example.com", and
"zaphod.sales.internal.example.com". IP addresses may be
given as arguments to this operator; however, they only
match exactly. In the case of the tel subfield, the output
matches if the telephone number being matched has a prefix
that matches the argument of the match operator;
match="1212555" would match the telephone number "1 212 555
1212."
contains This match operator applies only for the subfield
display. The output matches if the display name being
matched contains the argument of the match as a substring.
4.1.1 Address switch mapping for SIP
For SIP, the origin address corresponds to the address in the From
header; destination corresponds to the Request-URI; and original-
destination corresponds to the To header.
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 field will never have a display subfield.
The address-type subfield of an address is the URI scheme of that
address. Other address fields depend on that address-type.
For sip URLs, the user, host, and port subfields correspond to the
"user," "host," and "port" elements of the URI syntax. The tel
subfield is defined to be the "user" part of the URI if and only if
the "user=phone" parameter is given to the URI. An additional
subfield, password is defined to correspond to the "password" element
of the SIP URI; however, use of this field is NOT RECOMMENDED for
general security reasons.
For tel URLs, the tel and user subfields are the subscriber name; in
the former case, "noise" characters are stripped. the host and port
subfields are both not present.
For other URI schemes, only the address-type subfield is defined by
this specification; servers MAY set others of the pre-defined
subfields, or MAY support additional subfields.
If no subfield is specified for addresses in SIP messages, the string
matched is the URI part of the address, with all parameters stripped.
4.1.2 Address switch mapping for H.323
For H.323, the origin address corresponds to the address in the
sourceAddress field; both destination and original-destination
correspond to the destinationAddress field, as H.323 has no
indication of original destination.
For all addresses in H.323 messages, the value of the address-type
field is h323. The tel tag is set to the AliasAddress, if its type is
e164. The user tag is set to h323-ID; host is set to
transportID/TransportAddress/ipAddress, translated to a dotted-quad;
port is set to transportID/TransportAddress/ipAddress/port. The
display tag is not present. An additional subfield, asn1, is defined
as the textually-encoded ASN.1 of the address. The matching if no
subfield is specified is undefined at this time.
TODO: Have this looked over by an H.323 expert for
accuracy/completeness. Once an h323 URL scheme is defined,
it should be used for the whole-address matching.
4.2 String switches
String switches allow a CPL script to make decisions based on free-
form Unicode strings present in a call request. They are summarized
in figure 5.
Node: string-switch
Outputs: string Specific string to match
Parameters: field subject, organization, or user-agent
Output: string
Parameters: is exact match
contains substring match
Figure 5: Syntax of the string-switch node
String switches have one node parameter: field. The mandatory field
parameter specifies which string is to be matched. Currently three
fields are defined: subject, indicating the subject of the call;
organization, indicating the originator's organization; and user-
agent, indicating the program or device with which the call request
was made. All these fields correspond to SIP strings.
TODO: Need H.323 free-form strings. "Data"?
Strings are matched as case-insensitive Unicode strings, in the
following manner. First, strings are canonicalized to the
"Compatibility Composition" (KC) form, as specified in Unicode
Technical Report 15 [8]. Then, strings are compared using locale-
insensitive caseless mapping, as specified in Unicode Technical
Report 21 [9].
Code to perform the first step, in Java and Perl, is
available; see the links from Annex E of UTR 15 [8]. The
case-insensitive string comparison in the Java standard
class libraries already performs the second step; other
Unicode-aware libraries should be similar.
The output tags of string matching are named string, and have a
mandatory argument, one of is or contains, indicating whole-string
match or substring match, respectively.
4.3 Time switches
Time switches allow a CPL script to make decisions based the time
and/or date the script is being executed. They are summarized in
figure 6.
Node: time-switch
Outputs: time Specific time to match
Parameters: timezone local, utc, or other (see section 9)
Output: time
Parameters: year Years to match
month Months to match
date Days of month to match
weekday Days of week to match
timeofday Times of day to match
Figure 6: Syntax of the time-switch node
Time switches take one optional parameter, timezone, which specifies
the time zone in which matching is to take place. Two values of this
are predefined: local indicates the time zone in which the server is
located, and utc indicates Universal Coordinated Time. Timezones may
also be specified in the ancillary information; see section 9.
The time outputs can take the following optional parameters: year,
month, date, day, and timeofday. Each argument is syntactically month, date, day, and timeofday. Each argument is syntactically
expressed as a list of numeric ranges. Ranges are delimited as expressed as a list of numeric ranges. Ranges are delimited as
value-value; lists elements are separated by commas. Months are value-value; lists elements are separated by commas. Months are
specified in the range 1-12; date as 1-31, day as 0-6 (where 0 is specified in the range 1-12; date as 1-31, day as 0-6 (where 0 is
Sunday), and times of day as 24-hour times in the range 0000-2359; Sunday), and times of day as 24-hour times in the range 0000-2359;
years are unlimited in range, though only positive values are years are unlimited in range, though only positive values are
allowed. allowed.
An output node matches if the time the triggering call was placed An output node matches if the time the triggering call was placed
falls within one of the ranges in all of the specified arguments. falls within one of specified the ranges in each of the specified
parameters.
The following examples show sample time nodes, and descriptions of The following examples show sample time nodes, and descriptions of
the corresponding time periods they indicate: the corresponding time periods they indicate:
<time month="12" date="25" year="1999"> <time month="12" date="25" year="1999">
December 25th, 1999, all day December 25th, 1999, all day
<time month="5" date="4"> <time month="5" date="4">
May 4th, every year, all day May 4th, every year, all day
<time day="1-5" timeofday="0900-1700"> <time day="1-5" timeofday="0900-1700">
9 AM -- 5 PM, Monday through Friday, every week 9 AM -- 5 PM, Monday through Friday, every week
<time timeofday="1310-1425,1440-1555,1610-1725" day="2,4"> <time timeofday="1310-1425,1440-1555,1610-1725" day="2,4">
1:10 -- 2:25 PM, 2:40 -- 3:55 PM, and 4:10 -- 5:25 PM, Tuesdays 1:10 -- 2:25 PM, 2:40 -- 3:55 PM, and 4:10 -- 5:25 PM,
and Thursdays, every week Tuesdays and Thursdays, every week
<time date="1-7" day="1"> <time date="1-7" day="1">
The first Monday of every month, all day The first Monday of every month, all day
If more complicated time ranges need to be specified, they SHOULD be If more complicated time ranges need to be specified, they SHOULD be
broken down into component ranges specifiable in this syntax, and broken down into component ranges specifiable in this syntax, and
their outputs connected the outputs to the same subsequent node with their outputs connected the outputs to the same subsequent node with
links (see section 7). subactions (see section 8).
3.3 Other Switches The not-present output is never true for a time switch.
Question: how should we switch based on media? We need a Note: XML schemas [10] define their own "time instant" and
syntax for this. We could just switch on media type as a "time duration" syntax. Would it be better to base this
MIME type; the problem is that you may have several media syntax on that? It doesn't seem to be quite as powerful.
types defined. Other important attributes of media include
required bandwidth (numeric) and source address (IPv4
address, usually, but IPv6 in the future) -- do we need
switch types for these?
4 Locations Note: the question of whether the week should start at
Sunday or Monday, and of whether numbering starts at 0 or
1, was a matter of some dispute. In the absence of any
convincing argument in favor of any one proposal, the
current choice (Sunday is 0) was chosen semi-arbitrarily,
because it corresponds to the tm_wday field of C's struct
tm.
A number of CPL actions (defined in section 5) need to have locations Note: the way of specifying "first Monday of month" and
specified. An executing CPL always has some set of locations "last Monday of month" is awfully hackish. Would it be
specified; CPLs use location nodes to add or clear locations from the worthwhile to add a week parameter, which could optionally
set. be negative to count from the end of the month?
By default, location nodes add to the current set of locations. 4.4 Priority switches
Alternately, they can re-initialize the set, clearing it before
adding additional nodes. This is specified with the argument merge,
which can take two possible values, merge and clear. Its default
value is merge.
4.1 Basic Location Priority switches allow a CPL script to make decisions based on the
priority specified for the original call. They are summarized in
figure 7.
Basic location nodes (which have the tag name location) specify a Priority switches take no parameters.
location literally, as a URL. They take a single argument, url; the
desired location is given as an argument. Only one location may be Node: priority-switch
specified per location node; multiple locations may be specified by Outputs: priority Specific priority to match
cascading these nodes. Parameters: none
Output: priority
Parameters: less Match if priority is less than specified
greater Match if priority is greater than specified
equal Match if priority is equal to specified
Figure 7: Syntax of the priority-switch node
The priority tags take one of the three parameters greater, less, and
equal. The values of these tags are the priorities specified in SIP
[1]: in decreasing order, emergency, urgent, normal, and non-urgent.
These values are matched in a case-insensitive manner. Outputs with
the less parameter are taken if the priority of the message is less
than the priority given in the argument; and so forth.
If no priority header is specified in a message, the priority is
considered to be normal. If an unknown priority is given, the
priority is considered to be equivalent to normal for the purposes of
greater and less comparisons, but it is compared literally for equal
comparisons.
Since every message has a priority, the not-present output is never
true for a priority switch.
5 Location modifiers
The abstract location model of the CPL is described in section 2.3.
The behavior of several of the signalling actions (defined in section
6) is dependent on the current location set specified. Location nodes
add to or remove locations from the location set.
There are three types of location nodes defined. Explicit locations
add literally-specified locations to the current location set;
location lookups obtain locations from some outside source; and
location filters remove locations from the set, based on some
specified criteria.
5.1 Explicit location
Explicit location nodes specify a location literally. Their syntax is
described in figure 8.
Node: location
Outputs: any node
Parameters: url URL of address to add to location set
Figure 8: Syntax of the location node
Explicit location nodes have one node parameter: url, whose value is
the URL of the address to add to the location set. Only one address
may be specified per location node; multiple locations may be
specified by cascading these nodes.
Basic location nodes have only one possible output, since there is no Basic location nodes have only one possible output, 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, its XML representation does time the script is submitted.) Therefore, its XML representation does
not have explicit output nodes; the <location> tag directly contains not have explicit output nodes; the <location> tag directly contains
another node tag. another node tag.
4.2 Location Lookup 5.2 Location lookup
Locations can also be looked up through external means, through the Locations can also be specified up through external means, through
use of the lookup tag. The location to look up the result can be the use of location lookups. The syntax of these tags is given in
specified either as a url, or as another source. External URLs, are figure 9.
specified with the attribute url, and should refer to an external
source which returns the application/url media type. Other sources
are specified with the attribute source. The only source currently
defined is registration, which specifies all the locations currently
registered with the server, using SIP REGISTER or H.323 RAS messages.
A lookup tag MUST specify exactly one of url or source.
Lookup also has an optional attribute, timeout, which specifies the Location lookup nodes have one mandatory parameter, and three
time in seconds the script is willing to wait for the lookup to be optional parameters. The mandatory parameter is source, the source of
performed. Lookup has three outputs: success, notfound, and failure. the lookup. This can either be a URL, or a non-URL value. If the
Notfound is taken if the lookup process succeeded but did not find value of source is a URL, it indicates a location which returns the
any locations; failure is taken if the lookup failed for some reason, application/url media type. The server adds the locations returned by
including that specified timeout was exceeded. If failure is not the URL to the location set.
specified, the action corresponding to notfound is taken; if notfound
is not specified, the success output is taken, but the current Non-URL sources indicate a source not specified by a URL which the
location set is not modified. The success output must be given. server can query for addresses to add to the location set. The only
non-URL source currently defined is registration, which specifies all
the locations currently registered with the server, using SIP
REGISTER or H.323 RAS messages.
The lookup node also has an three optional parameters. The timeout
parameter which specifies the time, in seconds, the script is willing
to wait for the lookup to be performed. If this is not specified,
its default value is 30.
Node: lookup
Outputs: success Action if lookup was successful
notfound Action if lookup found no addresses
failure Action if lookup failed
Parameters: source Source of the lookup
timeout Time to try before giving up on the lookup
use Caller preferences fields to use
ignore Caller preferences fields to ignore
Output: success
Parameters: none
Output: notfound
Parameters: none
Output: failure
Parameters: none
Figure 9: Syntax of the lookup node
The other two optional parameters affect the interworking of the CPL
script with caller preferences and caller capabilities. These are
defined in the Internet-Draft "SIP Caller Preferences and Callee
Capabilities" [11]. By default, a CPL server SHOULD invoke caller
preferences filtering when performing a lookup action. The two
parameters use and ignore allow the script to modify how the script
applies caller preferences filtering. The use and ignore parameters
both take as their arguments comma-separated lists of caller
preferences parameters. If use is given, the server applies the
caller preferences resolution algorithm only to those preference
parameters given in the use parameter, and ignores all others; if the
ignore parameter is given, the server ignores the specified
parameters, and uses all the others. Only one of use and ignore can
be specified. The addr-spec part of the caller preferences is always
applied, and the script cannot modify it.
Note: this is very SIP-specific. Does H.323 have a similar
endpoint-capabilities and requested-capabilities mechanism?
TODO: Add examples. This is confusing.
Lookup has three outputs: success, notfound, and failure. Notfound is
taken if the lookup process succeeded but did not find any locations;
failure is taken if the lookup failed for some reason, including that
specified timeout was exceeded. If failure is not specified, the
action corresponding to notfound is taken; if notfound is not
specified, the success output is taken, but the current location set
is not modified. The success output MUST be included.
Clients SHOULD specify the three outputs success, notfound, and Clients SHOULD specify the three outputs success, notfound, and
failure in that order, so their script complies with the DTD given in failure in that order, so their script complies with the DTD given in
Appendix A, but servers SHOULD accept them in any order. Appendix A, but servers SHOULD accept them in any order.
5 Signalling Actions 5.3 Location filtering
A CPL script can also filter addresses out of the address set,
through the use of a mechanism very similar to caller preferences:
the remove-location node. The syntax of these nodes is defined in
figure 10.
Node: remove-location
Outputs: any node
Parameters: param Caller preference parameter to apply
value Value of caller preference parameter
location Caller preference location to apply
Figure 10: Syntax of the remove-location node
A remove-location node has the same effect on the location set as a
Reject-Contact header in caller preferences [11]. The value of the
location parameter is treated as though it were the addr-spec field
of a Reject-Contact header; an absent header is equivalent to an
addr-spec of "*" in that specification. If param and value are
present, their values are comma-separated lists of caller preferences
parameters and corresponding values, respectively. There MUST be the
same number of parameters as values specified. These are treated, for
location filtering purposes, as though they appeared in the params
field of a Reject-Location header, as "; param=value" for each one.
Note: do we want to be able to switch based on whether
there are any locations left in the set after a lookup?
Note: this is also very SIP-specific. Does H.323 have a
similar endpoint-capabilities mechanism?
TODO: Add examples. This is also confusing.
6 Signalling actions
Signalling action nodes cause signalling events in the underlying Signalling action nodes cause signalling events in the underlying
signalling protocol. signalling protocol. Three signalling actions are defined: "proxy,"
"redirect," and "reject."
5.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 server chooses the "best" response to specified set of locations. The syntax of the proxy node is given in
the call attempt, as defined by the protocol or its configuration figure 11.
rules. If the call attempt was successful, CPL execution terminates;
otherwise, one of the three outputs busy, noanswer, or failure is Node: lookup
taken. Outputs: busy Action if call attempt returned "busy"
noanswer Action if call attempt was not answered before timeout
failure Action if call attempt failed
Parameters: timeout Time to try before giving up on the call attempt
recurse Whether to recursively look up redirections
ordering What order to try the location set in.
Output: busy
Parameters: none
Output: noanswer
Parameters: none
Output: failure
Parameters: none
Figure 11: Syntax of the proxy node
After a proxy action has completed, the CPL server chooses the "best"
response to the call attempt, as defined by the signalling protocol
or the server's administrative configuration rules.
If the call attempt was successful, or if a redirection response was
the "best" response and recurse was not specified, CPL execution
terminates and the best response is forwarded back upstream to the
originator. Otherwise, one of the three outputs busy, noanswer, or
failure is taken.
Note: future extension of the CPL to allow in-call or end- Note: future extension of the CPL to allow in-call or end-
of-call actions will require success outputs to be added as of-call actions will require success outputs to be added.
well.
Question: What other outputs are needed? Redirect? More Question: should an explicit redirection output be added
varieties of failure? for the case when recurse was false? How should it interact
with the location set?
If no locations are specified at the time the proxy command is Proxy has three optional parameters. The timeout parameter specifies
executed, the server SHOULD attempt to proxy the call to its standard the time, in seconds, to wait for the call to be completed or
set of addresses for the user, or inform the caller that the caller rejected; after this time has elapsed, the call attempt is terminated
is unavailable. and the noanswer branch is taken. If this parameter is not
specified, the default value is 20 seconds if the proxy node has a
no-answer output specified; otherwise the server SHOULD allow the
call to ring for an arbitrarily long period of time.
Proxy has one argument: timeout, which specifies the time, in Question: is 20 seconds a good value? How should such a
seconds, to wait for the call to be completed or rejected, after value be chosen?
which time the call attempt is terminated and the noanswer branch is
taken.
Question: Do we want to be able to specify timeouts in The second optional parameter is recurse, which can take two values,
other units, notably "number of rings"? yes or no. This specifies whether the server should automatically
attempt to place further call attempts to telephony addresses in
redirection responses that were returned from the initial server.
5.2 Redirect The third optional parameter is ordering. This can have three
possible values: parallel, sequential, and first-only. This
parameter specifies in what order the locations of the location set
should be tried. Parallel asks that they all be tried simultaneously;
sequential asks that the first one be tried first, the second second,
and so forth, until one succeeds or the set is exhausted; first-only
instructs the server to try only the first address in the set, and
then follow one of the outputs. The default value of this parameter
is parallel.
Once a proxy action completes, if control is passed on to other
actions, all locations which have been used are cleared from the
location set. That is, the location set is emptied if ordering was
parallel or sequential; the first item in the set is removed from the
set if ordering was first-only.
For the proper actions when outputs are unspecified, see section 10.
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. This place its call to the currently specified set of locations. The
immediately terminates execution of the CPL script, so this node has syntax of this node is specified in figure 12.
no outputs. This node also has no arguments other than the standard
Link ID target (see section 7).
5.3 Response Node: redirect
Outputs: none
Parameters: none
Response causes the server to reject the call attempt. This Figure 12: Syntax of the redirect node
immediately terminates execution of the CPL script, so this node has
no outputs.
This node has two arguments in addition to the standard Link ID (see Redirect immediately terminates execution of the CPL script, so this
section 7): status and reason. The status argument is required, and node has no outputs. It also takes no arguments.
can take one of the values busy, notfound, reject, and error.
Servers which implement SIP MAY also allow a numeric argument here
corresponding to a SIP status in the 4xx, 5xx, or 6xx range, but
scripts SHOULD NOT use them if they wish to be portable.
The reason argument optionally allows the script to specify a reason Question: should there be some way of distinguishing
for the rejection. CPL servers MAY ignore the reason, but ones that between "moved temporarily" and "moved permanently" (SIP
implement SIP SHOULD send them in the SIP reason phrase. 301 and 302) redirections?
The CPL does not define any way to send intermediate responses to 6.3 Reject
call attempts. Servers SHOULD send them automatically, as
appropriate.
Note: we need more named statuses. Reject nodes cause the server to reject the call attempt. Their
syntax is given in figure 13.
Question: Success and redirection are also responses. Node: reject
Should this node be called "failure" or "reject" instead? Outputs: none
Parameters: status Status code to return
reason Reason phrase to return
6 Other Actions Figure 13: Syntax of the reject node
This immediately terminates execution of the CPL script, so this node
has no outputs.
This node has two arguments: status and reason. The status argument
is required, and can take one of the values busy, notfound, reject,
and error. Servers which implement SIP MAY also allow a numeric
argument corresponding to a SIP status in the 4xx, 5xx, or 6xx range,
but scripts SHOULD NOT use them if they wish to be portable.
The reason argument optionally allows the script to specify a reason
for the rejection. CPL servers MAY ignore the reason, but ones that
implement SIP SHOULD send them in the SIP reason phrase.
7 Other actions
In addition to the signalling actions, the CPL defines several In addition to the signalling actions, the CPL defines several
actions which do not affect the telephony signalling protocol. actions which do not affect the telephony signalling protocol.
6.1 Notify 7.1 Mail
The Notify node causes the server to notify a user of the status of The mail node causes the server to notify a user of the status of the
the CPL script through some non-telephony means; for instance, CPL script through electronic mail. Its syntax is given in figure 14.
sending electronic mail, or delivering an instant message. It takes
two arguments: a required URL indicating the means and address to
contact (attribute url), and optionally a comment to be included in
that message (attribute comment). The server sends the message
containing the content to the given url; it SHOULD also include other
status information about the state of the call and the CPL script at
the time of the notification. Servers SHOULD check the specified
address at script submission time to ensure that they understand the
specified URL scheme.
This node has two outputs, success and failure. The success branch is Node: mail
mandatory; if no failure branch is specified, the success branch is Outputs: any node
taken. The outputs SHOULD be specified in the order given. Parameters: url Mailto url to which the mail should be sent
Question: is this too general? Notification is a very broad Figure 14: Syntax of the mail node
concept. Would simply having a "Mailto" tag be cleaner?
6.2 Log The mail node takes one argument: a mailto URL giving the address,
and any additional desired parameters, of the mail to be sent. The
server sends the message containing the content to the given url; it
SHOULD also include other status information about the state of the
call and the CPL script at the time of the notification.
Mail nodes have only one output, since failure of e-mail delivery
cannot reliably be known in real-time. Therefore, its XML
representation does not have explicit output nodes: the <mail> tag
directly contains another node tag.
Using a full mailto URL rather than just an e-mail address
allows additional e-mail headers to be specified, such as
<mail
url="mailto:jones@example.com;subject=lookup%20failed" />.
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. It takes two arguments, both optional: name, non-volatile storage. Its syntax is specified in figure 15.
which specifies the name of the log, and comment, which gives a
comment about the information being logged. Servers SHOULD also
include other information in the log, such as the time of the logged
event, information that triggered the call to be logged, and so
forth. Logs are specific to the owner of the script which log event.
This specification does not define how users may retrieve their logs
from the server.
This node has two outputs, success and failure. The success branch is Log takes two arguments, both optional: name, which specifies the
mandatory; if no failure branch is specified, the success branch is name of the log, and comment, which gives a comment about the
taken. The outputs SHOULD be specified in the order given. information being logged. Servers SHOULD also include other
information in the log, such as the time of the logged event,
information that triggered the call to be logged, and so forth. Logs
are specific to the owner of the script which log event. If the name
parameter is not given, the event is logged to a standard, server-
Node: log
Outputs: any node
Parameters: name Name of the log file to use
comment Comment to be placed in log file
7 Links Figure 15: Syntax of the log node
XML syntax defines a tree. Because the general structure of the CPL
is instead intended to be a directed acyclic graph, we provide the
link structure to allow several node outputs to connect to a single
node.
Every XML tag which represents a node has an optional argument id, defined logfile for the script owner. This specification does not
which can be any XML id. (The id attribute is a standard XML define how users may retrieve their logs from the server.
attribute, defined in section 3.3.1 of the XML specification.) Any
output which normally contains a node can, instead, contain a link
tag with a ref attribute specifying the ID of some other node.
Every link ref MUST refer to a link ID specified in the same CPL A correctly operating CPL server SHOULD NOT ever allow the log event
to fail. As such, log nodes have only one output, and their XML
representation does not have explicit output nodes. A CPL <log> tag
directly contains another node tag.
8 Subactions
XML syntax defines a tree. To allow more general call flow diagrams,
and to allow script re-use and modularity, we define subactions.
Two tags are defined for subactions: subaction definitions and
subaction references. Their syntax is given in figure 16.
Tag: subaction
Subtags: any node
Parameters: id Name of this subaction
Pseudo-node: sub
Outputs: none in XML tree
Parameters: ref Name of subaction to execute
Figure 16: Syntax of subactions and sub pseudo-nodes
Subactions are defined through subaction tags. These tags are placed
in the CPL after any ancillary information (see section 9) but before
any top-level tags. They take one argument: id, a token indicating a
script-chosen name for the subaction.
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 be
used. It takes one parameter, ref, the name of the subaction to be
called. The sub tag contains no outputs of its own; control instead
passes to the subaction.
References to subactions MUST refer to subactions defined before the
current action. A sub tag MUST NOT refer to the action which it
appears in, or to any action defined later in the CPL script. Top-
level actions cannot be called from sub tags, or through any other
means. Script servers MUST verify at the time the script is submitted
that no sub node refers to any sub-action which is not its proper
predecessor.
Allowing only back-references of subs forbids any sort of
recursion. Recursion would introduce the possibility of
non-terminating or non-decidable CPL scripts, a possibility
our requirements specifically excluded.
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.
If any subsequent version ever defines external linkages, If any subsequent version ever defines external linkages,
it will use a different tag, perhaps XLINK [9]. it will use a different tag, perhaps XLink [12]. Ensuring
termination in the presence of external links is a
difficult problem.
When the CPL server initially processes the script, it MUST verify 9 Ancillary information
that no link refers to a node that is its parent in the tree; i.e.,
it MUST verify that the directed graph created by the tree and the
links is acyclic. If it is not, the server SHOULD treat this error
in the same manner as any other syntax error in a script. (This
verification is algorithmically simply a matter of verifying that a
depth-first search of the directed graph contains no back edges; see,
for instance, [10], Lemma 23.10. It can typically be done
simultaneously with the resolution of links.)
If cycles were allowed in the graph, it would introduce the Only one sort of ancillary information is currently defined for CPL
possibility of non-terminating CPL scripts, a possibility scripts: timezone information. The syntax of timezone specifications
our requirements specifically excluded. is given in figure 17.
CPL servers MAY use link IDs to identify nodes for other purposes, Timezone specifications consist, conceptually, of three parts: the
for instance to report errors or to provide real-time debugging or name of the timezone, as used by time switches in the script; the GMT
flow information. Thus, scripts SHOULD provide IDs for every node for offset and abbreviation of each offset used in the timezone; and the
which they are interested in such information, even if no link instants at which each offset takes effect.
connects to that node.
8 Examples The name of the timezone is given by the name parameter to the
timezone tag. This is the name which time-switch tags can specify in
their timezone parameter.
8.1 Example: Call Redirect Unconditional The timezone tag must contain at least one instance of the standard
tag, which has mandatory arguments offset, giving the zone's offset
in minutes from UTC, and abbr, giving the standard abbreviation of
the timezone. If more than one time offset is in use in a timezone
during a year, the timezone tag contains another tag, daylight, which
takes the same parameters as standard; and each of standard and
Tag: timezone
Parameters: name Name of this timezone
Outputs: standard Specification of standard time
daylight Specification of daylight (summer) time
The script in figure 3 is a simple script which redirects all calls Tag: standard
Parameters: offset UTC offset during standard time
abbr abbreviation of this timezone
year year that this timezone transition occurs
month month that this timezone transition occurs
date day of month that this timezone transition occurs
weekday weekday that this timezone transition occurs
timeofday time of day that this timezone transition occurs
Tag: daylight
Parameters: ... same as for standard
Figure 17: Syntax of the timezone tag
daylight has parameters, using the same syntax as time-switch tags
(section 4.3, specifying a set of instants when the time zone rule
takes effect, in the local time of the other offset.
Currently only two classes of offsets are supported. A timezone rule
MAY contain several definitions each of standard and daylight if, for
instance, different rules are in effect for different years.
Figure 18 shows the timezone specification for most of the eastern
United States.
<timezone name="US/Eastern">
<standard offset="-0500" abbr="EST" month="10" date="25-31"
day="0" timeofday="0200" />
<!-- 2 AM, last Sunday in October -->
<daylight offset="-0400" abbr="EDT" month="4" date="1-7"
day="0" timeofday="0200" />
<!-- 2 AM, first Sunday in April -->
</timezone>
Figure 18: Timezone rule for the eastern United States.
Figure 19 shows a simpler timezone rule for the state of Arizona,
United States; most of Arizona does not observe daylight savings
time.
<timezone name="US/Arizona">
<standard offset="-0700" abbr="MST" />
</timezone>
Figure 19: Timezone rule for Arizona, United States.
Note: the syntax for specifying the first or last weekday
of a month is very clumsy. A proper week parameter might be
a good thing to add.
10 Default actions
When a CPL action reaches an unspecified output, the action it takes
is dependent on the current state of script execution. This section
gives the actions that should be taken in each case.
no location or signalling actions performed, location set empty:
Look up the user's location through whatever mechanism the
server would use if no CPL script were in effect. Proxy,
redirect, or send a rejection message, using whatever
policy the server would use in the absence of a CPL script.
no location or signalling actions performed, location set non-
empty: (This can only happen for outgoing calls.) Proxy
the call to the addresses in the location set.
location actions performed, no signalling actions: Proxy or
redirect the call, whichever is the server's standard
policy, to the addresses in the current location set. If
the location set is empty, return notfound rejection.
noanswer output of proxy, no timeout given: (This is a special
case.) If the noanswer output of a proxy node is
unspecified, and no timeout parameter was given to the
proxy node, the call should be allowed to ring for the
maximum length of time allowed by the server (or the
request, if the request specified a timeout).
proxy action previously taken: Return whatever the "best"
response is of all accumulated responses to the call to
this point, according to the rules of the underlying
signalling protocol.
11 Examples
TODO: these examples don't illustrate many of the new
features added to the CPL in draft -01. Add these.
11.1 Example: Call Redirect Unconditional
The script in figure 20 is a simple script which redirects all calls
to a single fixed location. to a single fixed location.
8.2 Example: Call Forward Busy/No Answer
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd"> <!DOCTYPE cpl SYSTEM "cpl.dtd">
<call> <cpl>
<incoming>
<location url="sip:smith@phone.example.com"> <location url="sip:smith@phone.example.com">
<redirect /> <redirect />
</location> </location>
</call> </incoming>
</cpl>
Figure 3: Example Script: Call Redirect Unconditional Figure 20: Example Script: Call Redirect Unconditional
The script in figure 4 illustrates some more complex behavior. We see 11.2 Example: Call Forward Busy/No Answer
an initial proxy attempt to one address, with further actions if that
fails. We also see how several outputs can point to the same node, The script in figure 21 illustrates some more complex behavior. We
through the use of the link tag. see an initial proxy attempt to one address, with further actions if
that fails. We also see how several outputs take the same action,
through the use of subactions.
11.3 Example: Call Screening
The script in figure 22 illustrates address switches and call
rejection, in the form of a call screening script. Note also that
because the address-switch lacks an otherwise clause, if the initial
pattern did not match, the script does not define any action. The
server therefore proceeds with its default action, which would
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd"> <!DOCTYPE cpl SYSTEM "cpl.dtd">
<call> <cpl>
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com" >
<proxy />
</location>
</subaction>
<incoming>
<location url="sip:jones@jonespc.example.com"> <location url="sip:jones@jonespc.example.com">
<proxy timeout="8s"> <proxy timeout="8s">
<busy> <busy>
<location url="sip:jones@voicemail.example.com" merge="clear"
id="voicemail" >
<proxy />
</location>
</busy> </busy>
<noanswer> <noanswer>
<link ref="voicemail" /> <sub ref="voicemail" />
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</call> </incoming>
</cpl>
Figure 4: Example Script: Call Forward Busy/No Answer
8.3 Example: Call Screening Figure 21: Example Script: Call Forward Busy/No Answer
The script in figure 5 illustrates string switches and call
rejection, in the form of a call screening script. Note also that
because the string-switch lacks an otherwise clause, if the initial
pattern did not match, the script does not define any action. The
server therefore proceeds with its default action, which would
presumably be to contact the user. presumably be to contact the user.
<?xml version="1.0" ?> 11.4 Example: Time-of-day Routing
<!DOCTYPE call SYSTEM "cpl.dtd">
<call> Figure 23 illustrates time-based conditions and timezones.
<string-switch field="from">
<string matches="anonymous@*">
<response status="reject"
reason="I don't accept anonymous calls" />
</string>
</string-switch>
</call>
Figure 5: Example Script: Call Screening 11.5 Example: Non-call Actions
8.4 Example: Time-of-day Routing Figure 24 illustrates non-call actions; in particular, alerting a
user by electronic mail if the lookup server failed. The primary
reason for the mail node is to allow this sort of out-of-band
notification of error conditions, as the user might otherwise be
unaware of any problem.
Figure 6 illustrates time-based conditions. 11.6 Example: A Complex Example
8.5 Example: Non-call Actions Finally, figure 25 is a complex example which shows the sort of
<?xml version="1.0" ?>
<!DOCTYPE cpl SYSTEM "cpl.dtd">
Figure 7 illustrates non-call actions; in particular, alerting a user <cpl>
by electronic mail if the lookup server failed. The primary reason <incoming>
for the Notify node is to allow this sort of out-of-band notification <address-switch field="origin" subfield="user">
of error conditions, as the user might otherwise be unaware of any <address is="anonymous">
problem. <reject status="reject"
reason="I don't accept anonymous calls" />
</address>
</address-switch>
</incoming>
</cpl>
8.6 Example: A Complex Example Figure 22: Example Script: Call Screening
Finally, figure 8 is a complex example which shows the sort of
sophisticated behavior which can be achieved by combining CPL nodes. sophisticated behavior which 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 celphone, and all other calls are directed to are forwarded to his celphone, and all other calls are directed to
voicemail. voicemail.
9 Security Considerations 12 Security considerations
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<time-switch>
<time day="1-5" timeofday="0900-1700">
<lookup source="registration">
<success>
<proxy />
</success>
</lookup>
</time>
<otherwise>
<location url="sip:jones@voicemail.example.com">
<proxy />
</location>
</otherwise>
</time-switch>
</call>
Figure 6: Example Script: Time-of-day Routing
The CPL is designed to allow services to be specified in a manner The CPL is designed to allow services to be specified in a manner
which prevents potentially hostile or mis-configured scripts from which prevents potentially hostile or mis-configured scripts from
launching security attacks, including denial-of-service attacks. launching security attacks, including denial-of-service attacks.
Because script runtime is strictly bounded by acyclicity, and because Because script runtime is strictly bounded by acyclicity, and because
the number of possible script actions are strictly limited, scripts the number of possible script actions are strictly limited, scripts
should not 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 actions are permitted. details of what CPL actions are permitted.
10 Acknowledgments 13 Acknowledgments
We would like to thank Tom La Porta and Jonathan Rosenberg for their We would like to thank Tom La Porta and Jonathan Rosenberg for their
contributions and suggestions. contributions and suggestions.
We drew a good deal of inspiration, notably the language's lack of
Turing-completeness and the syntax of string matching, from the
specification of Sieve [11], a language for user filtering of
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd"> <!DOCTYPE cpl SYSTEM "cpl.dtd">
<call> <cpl>
<lookup url="http://www.example.com/cgi-bin/locate.cgi?user=jones" <timezone name="US/Eastern">
timeout="8s"> <standard offset="-0500" abbr="EST" month="10" date="25-31"
day="0" timeofday="0200" />
<!-- 2 AM, last Sunday in October -->
<daylight offset="-0400" abbr="EDT" month="4" date="1-7"
day="0" timeofday="0200" />
<!-- 2 AM, first Sunday in April -->
</timezone>
<incoming>
<time-switch timezone="US/Eastern">
<time day="1-5" timeofday="0900-1700">
<lookup source="registration">
<success> <success>
<proxy /> <proxy />
</success> </success>
<failure>
<notify url="mailto:jones@example.com"
comment="The lookup server failed">
<success>
<response status="error" />
</success>
</notify>
</failure>
</lookup> </lookup>
</call> </time>
<otherwise>
<location url="sip:jones@voicemail.example.com">
<proxy />
</location>
</otherwise>
</time-switch>
</incoming>
</cpl>
Figure 7: Example Script: Non-call Actions Figure 23: Example Script: Time-of-day Routing
We drew a good deal of inspiration, notably the language's lack of
Turing-completeness and the syntax of string matching, from the
specification of Sieve [13], a language for user filtering of
electronic mail messages. electronic mail messages.
A The XML DTD for CPL A The XML DTD for CPL
This section includes a full DTD describing the XML syntax of the This section includes a full DTD describing the XML syntax of the
CPL. Every script submitted to a CPL server SHOULD comply with this CPL. Every script submitted to a CPL server SHOULD comply with this
DTD; however, CPL servers SHOULD allow minor variations from it, DTD; however, CPL servers SHOULD allow minor variations from it,
particularly in the ordering of output branches of nodes. Note that particularly in the ordering of output branches of nodes. Note that
compliance with this DTD is not a sufficient condition for compliance with this DTD is not a sufficient condition for
<?xml version="1.0" ?>
<!DOCTYPE cpl SYSTEM "cpl.dtd">
<cpl>
<incoming>
<lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones"
timeout="8">
<success>
<proxy />
</success>
<failure>
<mail url="mailto:jones@example.com;subject=lookup%20failed" />
</failure>
</lookup>
</incoming>
</cpl>
Figure 24: Example Script: Non-call Actions
correctness of a CPL script, as many of the conditions described correctness of a CPL script, as many of the conditions described
above are not expressible in DTD syntax. above are not expressible in DTD syntax.
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd"> <!DOCTYPE cpl SYSTEM "cpl.dtd">
<call> <cpl>
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<redirect />
</location>
</subaction>
<incoming>
<location url="sip:jones@phone.example.com"> <location url="sip:jones@phone.example.com">
<proxy timeout="8s"> <proxy timeout="8s">
<busy> <busy>
<location url="sip:jones@voicemail.example.com" merge="clear"> <sub ref="voicemail" />
<redirect />
</location>
</busy> </busy>
<noanswer> <noanswer>
<string-switch field="from"> <address-switch field="origin">
<string matches="boss@*example.com"> <address contains="boss@example.com">
<location url="phone:+19175551212" merge="clear"> <location url="tel:+19175551212">
<proxy /> <proxy />
</location> </location>
</string> </address>
<otherwise> <otherwise>
<location url="sip:jones@voicemail.example.com" merge="clear"> <sub ref="voicemail" />
<redirect />
</location>
</otherwise> </otherwise>
</string-switch> </address-switch>
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</call> </incoming>
</cpl>
Figure 8: Example Script: A Complex Example Figure 25: Example Script: A Complex Example
<?xml version="1.0" encoding="US-ASCII" ?> <?xml version="1.0" encoding="US-ASCII" ?>
<!-- <!--
Initial draft DTD for CPL, corresponding to Draft DTD for CPL, corresponding to
draft-ietf-iptel-cpl-00. draft-ietf-iptel-cpl-01.
--> -->
<!-- Define types of nodes --> <!-- Top-level tags of the CPL -->
<!-- Ancillary information -->
<!ENTITY % Ancillary 'timezone' >
<!-- Subactions -->
<!ENTITY % Subactions 'subaction' >
<!-- Top-level actions -->
<!ENTITY % TopLevelAction 'incoming|outgoing' >
<!-- Nodes. -->
<!-- Switch nodes --> <!-- Switch nodes -->
<!ENTITY % Switch 'string-switch|time-switch' > <!ENTITY % Switch 'address-switch|string-switch|time-switch|
priority-switch' >
<!-- Location nodes --> <!-- Location nodes -->
<!ENTITY % Location 'location|lookup' > <!ENTITY % Location 'location|lookup|remove-location' >
<!-- Signalling action nodes --> <!-- Signalling action nodes -->
<!ENTITY % SignallingAction 'proxy|redirect|response' > <!ENTITY % SignallingAction 'proxy|redirect|reject' >
<!-- Other actions --> <!-- Other actions -->
<!ENTITY % OtherAction 'notify|log' > <!ENTITY % OtherAction 'mail|log' >
<!-- Nodes are one of the above four categories, or a link. <!-- Links to subactions -->
This entity (macro) describes the contents of an output. --> <!ENTITY % Sub 'sub' >
<!ENTITY % Node '%Location;|%Switch;|%SignallingAction;|
%OtherAction;|link' >
<!-- Nodes can have link IDs. Since this is an attribute of every <!-- Nodes are one of the above four categories, or a subaction.
node, we need to define it early. --> This entity (macro) describes the contents of an output.
<!ENTITY % Link-ID 'id ID #IMPLIED'> Note that a node can be empty, implying default action. -->
<!ENTITY % Node '(%Location;|%Switch;|%SignallingAction;|
%OtherAction;|%Sub;)?' >
<!-- Switches: choices a CPL script can make. --> <!-- Switches: choices a CPL script can make. -->
<!-- All switches contain an 'otherwise' node. --> <!-- All switches can have an 'otherwise' output. -->
<!ELEMENT otherwise ( %Node; ) > <!ELEMENT otherwise ( %Node; ) >
<!-- All switches can have a 'not-present' output. -->
<!ELEMENT not-present ( %Node; ) >
<!-- Address-switch makes choices based on addresses. -->
<!ELEMENT address-switch ( (address|not-present)+, otherwise? ) >
<!ATTLIST address-switch
field CDATA #REQUIRED
subfield CDATA #IMPLIED
>
<!ELEMENT address ( %Node; ) >
<!ATTLIST address
is CDATA #IMPLIED
contains CDATA #IMPLIED
subdomain-of CDATA #IMPLIED
>
<!-- String-switch makes choices based on strings. --> <!-- String-switch makes choices based on strings. -->
<!ELEMENT string-switch ( string+, otherwise? ) > <!ELEMENT string-switch ( (string|not-present)+, otherwise? ) >
<!ATTLIST string-switch <!ATTLIST string-switch
field CDATA #REQUIRED field CDATA #REQUIRED
%Link-ID;
> >
<!ELEMENT string ( %Node; ) > <!ELEMENT string ( %Node; ) >
<!ATTLIST string <!ATTLIST string
is CDATA #IMPLIED is CDATA #IMPLIED
contains CDATA #IMPLIED contains CDATA #IMPLIED
matches CDATA #IMPLIED
comparator CDATA "i;ascii-casemap"
> >
<!-- Time-switch makes choices based on the current time. --> <!-- Time-switch makes choices based on the current time. -->
<!ELEMENT time-switch ( time+, otherwise? ) > <!ELEMENT time-switch ( (time|not-present)+, otherwise? ) >
<!ATTLIST time-switch <!ATTLIST time-switch
%Link-ID; timezone CDATA #IMPLIED
> >
<!ELEMENT time ( %Node; ) > <!ELEMENT time ( %Node; ) >
<!ATTLIST time <!ATTLIST time
year CDATA #IMPLIED year CDATA #IMPLIED
month CDATA #IMPLIED month CDATA #IMPLIED
date CDATA #IMPLIED date CDATA #IMPLIED
day CDATA #IMPLIED day CDATA #IMPLIED
timeofday CDATA #IMPLIED timeofday CDATA #IMPLIED
> >
<!-- Priority-switch makes choices based on message priority. -->
<!ELEMENT priority-switch ( (priority|not-present)+, otherwise? ) >
<!ENTITY % PriorityVal '(emergency|urgent|normal|non-urgent)' >
<!ELEMENT priority ( %Node; ) >
<!ATTLIST priority
less %PriorityVal; #IMPLIED
greater %PriorityVal; #IMPLIED
equal CDATA #IMPLIED
>
<!-- Locations: ways to specify the location a subsequent action <!-- Locations: ways to specify the location a subsequent action
(proxy, redirect) will attempt to contact. --> (proxy, redirect) will attempt to contact. -->
<!ENTITY % Merge 'merge (merge|clear) "merge"' > <!ENTITY % Clear 'clear (yes|no) "no"' >
<!ELEMENT location ( %Node; ) > <!ELEMENT location ( %Node; ) >
<!ATTLIST location <!ATTLIST location
url CDATA #REQUIRED url CDATA #REQUIRED
%Merge; %Clear;
%Link-ID;
> >
<!-- Sources of location lookups that aren't URIs. -->
<!ENTITY % Sources '(registration)' >
<!ELEMENT lookup ( success,notfound?,failure? ) > <!ELEMENT lookup ( success,notfound?,failure? ) >
<!ATTLIST lookup <!ATTLIST lookup
url CDATA #IMPLIED source CDATA #REQUIRED
source %Sources; #IMPLIED timeout CDATA "30"
timeout CDATA #IMPLIED use CDATA #IMPLIED
%Merge; ignore CDATA #IMPLIED
%Link-ID; %Clear;
> >
<!ELEMENT success ( %Node; ) > <!ELEMENT success ( %Node; ) >
<!ELEMENT notfound ( %Node; ) > <!ELEMENT notfound ( %Node; ) >
<!ELEMENT failure ( %Node; ) > <!ELEMENT failure ( %Node; ) >
<!ELEMENT remove-location ( %Node; ) >
<!ATTLIST remove-location
param CDATA #IMPLIED
value CDATA #IMPLIED
location CDATA #IMPLIED
>
<!-- Signalling Actions: call-signalling actions the script can <!-- Signalling Actions: call-signalling actions the script can
take. --> take. -->
<!ELEMENT proxy ( busy?,noanswer?,failure? ) > <!ELEMENT proxy ( busy?,noanswer?,failure? ) >
<!ATTLIST proxy <!ATTLIST proxy
timeout CDATA #IMPLIED timeout CDATA "20"
%Link-ID; recurse (yes|no) "yes"
ordering CDATA "parallel"
> >
<!ELEMENT busy ( %Node; ) > <!ELEMENT busy ( %Node; ) >
<!ELEMENT noanswer ( %Node; ) > <!ELEMENT noanswer ( %Node; ) >
<!-- "failure" repeats from lookup above. XXX? --> <!-- "failure" repeats from lookup above. XXX? -->
<!ELEMENT redirect EMPTY > <!ELEMENT redirect EMPTY >
<!ATTLIST redirect
%Link-ID;
>
<!-- Statuses we can return --> <!-- Statuses we can return -->
<!ELEMENT response EMPTY > <!ELEMENT reject EMPTY >
<!ATTLIST response <!ATTLIST reject
status CDATA #REQUIRED status CDATA #REQUIRED
reason CDATA #IMPLIED reason CDATA #IMPLIED
%Link-ID;
> >
<!-- Non-signalling actions: actions that don't affect the call --> <!-- Non-signalling actions: actions that don't affect the call -->
<!ELEMENT notify ( success,failure? ) > <!ELEMENT mail ( %Node; ) >
<!ATTLIST notify <!ATTLIST mail
url CDATA #REQUIRED url CDATA #REQUIRED
comment CDATA #IMPLIED
%Link-ID;
> >
<!ELEMENT log ( success,failure? ) > <!ELEMENT log ( success,failure? ) >
<!ATTLIST log <!ATTLIST log
name CDATA #IMPLIED name CDATA #IMPLIED
comment CDATA #IMPLIED comment CDATA #IMPLIED
%Link-ID;
> >
<!-- Links to other nodes. --> <!-- Calls to subactions. -->
<!ELEMENT link EMPTY > <!ELEMENT sub EMPTY >
<!ATTLIST link <!ATTLIST sub
ref IDREF #REQUIRED ref IDREF #REQUIRED
> >
<!-- Ancillary data -->
<!-- Timezone information -->
<!ELEMENT timezone ( standard,daylight? ) >
<!ATTLIST timezone
name CDATA #REQUIRED
>
<!ENTITY % ZoneParams
abbr CDATA #REQUIRED
year CDATA #IMPLIED
month CDATA #IMPLIED
date CDATA #IMPLIED
day CDATA #IMPLIED
timeofday CDATA #IMPLIED' >
<!ELEMENT standard EMPTY>
<!ATTLIST standard
%ZoneParams;
>
<!ELEMENT daylight EMPTY>
<!ATTLIST daylight
%ZoneParams;
>
<!-- Top-level action nodes -->
<!ELEMENT subaction ( %Node; )>
<!ATTLIST subaction
id ID #REQUIRED
>
<!ELEMENT outgoing ( %Node; )>
<!ELEMENT incoming ( %Node; )>
<!-- The top-level element of the script. --> <!-- The top-level element of the script. -->
<!ELEMENT call ( %Node; ) > <!ELEMENT cpl ( timezone*,subaction*,outgoing?,incoming? ) >
B Authors' Addresses B TODO
See also the TODO notes in in motivation comments scattered
throughout the document.
o Investigate XML Schemas as an alternative to DTDs: they may be
more flexible and/or powerful.
o Determine proper system and public identifiers for the DTD.
o Register application/cpl as a MIME media type.
C Changes from earlier versions
C.1 Changes from draft -00
The changebars in the Postscript and PDF versions of this document
indicate significant changes from this version.
o Added high-level structure; script doesn't just start at a
first action.
o Added a section giving a high-level explanation of the
location model.
o Added informal syntax specifications for each tag so people
don't have to try to understand a DTD to figure out the
syntax.
o Added subactions, replacing the old link tags. Links were far
too reminiscent of gotos for everyone's taste.
o Added ancillary information section, and timezone support.
o Added not-present switch output.
o Added address switches.
o Made case-insensitive string matching locale-independent.
o Added priority switch.
o Deleted "Other switches" section. None seem to be needed.
o Unified url and source parameters of lookup.
o Added caller prefs to lookup.
o Added location filtering.
o Eliminated "clear" parameter of location setting. Instead,
proxy "eats" locations it has used.
o Added recurse and ordering parameters to proxy.
o Added default value of timeout for proxy.
o Renamed response to reject.
o Changed notify to mail, and simplified it.
o Simplified log, eliminating its failure output.
o Added description of default actions at various times during
script processing.
o Updated examples for these changes.
o Updated DTD to reflect new syntax.
D 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 electronic mail: lennox@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 electronic mail: schulzrinne@cs.columbia.edu
C Bibliography E Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Internet Draft, Internet Engineering session initiation protocol," Request for Comments (Proposed
Task Force, Jan. 1999. Work in progress. Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[2] International Telecommunication Union, "Visual telephone systems [2] International Telecommunication Union, "Packet based multimedia
and equipment for local area networks which provide a non-guaranteed communication systems," Recommendation H.323, Telecommunication
quality of service," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[3] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup [3] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup
language (XML) 1.0," W3C Recommendation 10-February-1998, World Wide language (XML) 1.0," W3C Recommendation REC-xml-19980210, World Wide
Web Consortium (W3C), Feb. 1998. http://www.w3.org/TR/REC-xml. Web Consortium (W3C), Feb. 1998. Available at
http://www.w3.org/TR/REC-xml.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement [4] J. Lennox and H. Schulzrinne, "Call processing language framework
levels," BC 2119, Internet Engineering Task Force, Mar. 1997. and requirements," Internet Draft, Internet Engineering Task Force,
July 1999. Work in progress.
[5] D. Raggett, A. L. Hors, and I. Jacobs, "HTML 4.0 specification," [5] S. Bradner, "Key words for use in RFCs to indicate requirement
W3C Recommendation revised on 24-Apr-1998, World Wide Web Consortium levels," Request for Comments (Best Current Practice) 2119, Internet
(W3C), Apr. 1998. http://www.w3.org/TR/REC-html40/. Engineering Task Force, Mar. 1997.
[6] ISO (International Organization for Standardization), [6] D. Raggett, A. L. Hors, and I. Jacobs, "HTML 4.0 specification,"
W3C Recommendation REC-html40-19980424, World Wide Web Consortium
(W3C), Apr. 1998. Available at http://www.w3.org/TR/REC-html40/.
[7] ISO (International Organization for Standardization),
"Information processing -- text and office systems -- standard "Information processing -- text and office systems -- standard
generalized markup language (SGML)," ISO Standard ISO 8879:1986(E), generalized markup language (SGML)," ISO Standard ISO 8879:1986(E),
International Organization for Standardization, Geneva, Oct. 1986. International Organization for Standardization, Geneva, Switzerland,
Oct. 1986.
[7] J. Myers and C. Newman, "ACAP -- application configuration access [8] M. Davis and M. Dust, "Unicode normalization forms," Unicode
protocol," Request for Comments (Proposed Standard) 2244, Internet Technical Report 15, Unicode Consortium, Nov. 1999. Revision 18.0.
Engineering Task Force, Dec. 1997. Available at http://www.unicode.org/unicode/reports/tr15/.
[8] F. Dawson and D. Stenerson, "Internet calendaring and scheduling [9] M. Davis, "Case mapping," Unicode Technical Report 21, Unicode
core object specification (icalendar)," Request for Comments Consortium, Nov. 1999. Revision 3.0. Available at
(Proposed Standard) 2445, Internet Engineering Task Force, Nov. 1998. http://www.unicode.org/unicode/reports/tr21/.
[9] E. Maler and S. DeRose, "XML linking language (XLink)," Working [10] D. C. Fallside, "XML schema part 0: Primer," Working Draft WD-
Draft 3-March-1998, World Wide Web Consortium (W3C), Mar. 1998. xmlschema-0-20000225, World Wide Web Consortium (W3C), Feb. 2000.
http://www.w3.org/TR/WD-xlink. Available at http://www.w3.org/TR/xmlschema-0/.
[10] T. H. Cormen, C. E. Leiserson, and R. L. Rivest, Introduction to [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
Algorithms New York: McGraw-Hill, 1990. callee capabilities," Internet Draft, Internet Engineering Task
Force, Mar. 2000. Work in progress.
[11] T. Showalter, "Sieve: A mail filtering language," Internet [12] S. DeRose, E. Maler, D. Orchard, and B. Trafford, "XML linking
Draft, Internet Engineering Task Force, Jan. 1999. Work in progress. language (XLink)," Working Draft WD-xlink-20000221, World Wide Web
Consortium (W3C), Feb. 2000. Available at
http://www.w3.org/TR/xlink/.
[13] T. Showalter, "Sieve: A mail filtering language," Internet
Draft, Internet Engineering Task Force, Mar. 1999. Work in progress.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (1999). All Rights Reserved. Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 22, line 46 skipping to change at page 40, line 18
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 1
1.1 Conventions Of This Document ........................ 2 1.1 Conventions of this document ........................ 2
2 Structure of CPL scripts ............................ 2 2 Structure of CPL scripts ............................ 3
2.1 Abstract structure .................................. 2 2.1 High-level structure ................................ 3
2.2 XML Structure ....................................... 4 2.2 Abstract structure of a call processing action ...... 3
3 Switches ............................................ 4 2.3 Location model ...................................... 4
3.1 String Switch ....................................... 5 2.4 XML structure ....................................... 5
3.2 Time Switch ......................................... 7 3 Script structure: overview .......................... 5
3.3 Other Switches ...................................... 8 4 Switches ............................................ 6
4 Locations ........................................... 8 4.1 Address switches .................................... 7
4.1 Basic Location ...................................... 8 4.1.1 Address switch mapping for SIP ...................... 9
4.2 Location Lookup ..................................... 9 4.1.2 Address switch mapping for H.323 .................... 10
5 Signalling Actions .................................. 9 4.2 String switches ..................................... 11
5.1 Proxy ............................................... 9 4.3 Time switches ....................................... 12
5.2 Redirect ............................................ 10 4.4 Priority switches ................................... 13
5.3 Response ............................................ 10 5 Location modifiers .................................. 14
6 Other Actions ....................................... 11 5.1 Explicit location ................................... 14
6.1 Notify .............................................. 11 5.2 Location lookup ..................................... 15
6.2 Log ................................................. 11 5.3 Location filtering .................................. 17
7 Links ............................................... 11 6 Signalling actions .................................. 18
8 Examples ............................................ 12 6.1 Proxy ............................................... 18
8.1 Example: Call Redirect Unconditional ................ 12 6.2 Redirect ............................................ 19
8.2 Example: Call Forward Busy/No Answer ................ 12 6.3 Reject .............................................. 20
8.3 Example: Call Screening ............................. 13 7 Other actions ....................................... 20
8.4 Example: Time-of-day Routing ........................ 14 7.1 Mail ................................................ 21
8.5 Example: Non-call Actions ........................... 14 7.2 Log ................................................. 21
8.6 Example: A Complex Example .......................... 14 8 Subactions .......................................... 22
9 Security Considerations ............................. 14 9 Ancillary information ............................... 23
10 Acknowledgments ..................................... 15 10 Default actions ..................................... 25
A The XML DTD for CPL ................................. 16 11 Examples ............................................ 26
B Authors' Addresses .................................. 20 11.1 Example: Call Redirect Unconditional ................ 26
C Bibliography ........................................ 21 11.2 Example: Call Forward Busy/No Answer ................ 26
11.3 Example: Call Screening ............................. 26
11.4 Example: Time-of-day Routing ........................ 27
11.5 Example: Non-call Actions ........................... 27
11.6 Example: A Complex Example .......................... 27
12 Security considerations ............................. 28
13 Acknowledgments ..................................... 28
A The XML DTD for CPL ................................. 29
B TODO ................................................ 36
C Changes from earlier versions ....................... 36
C.1 Changes from draft -00 .............................. 36
D Authors' Addresses .................................. 38
E Bibliography ........................................ 38
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/