draft-ietf-iptel-cpl-05.txt   draft-ietf-iptel-cpl-06.txt 
Internet Engineering Task Force IPTEL WG Internet Engineering Task Force IPTEL WG
Internet Draft Lennox/Schulzrinne Internet Draft Lennox/Schulzrinne
draft-ietf-iptel-cpl-05.txt Columbia University draft-ietf-iptel-cpl-06.txt Columbia University
November 21, 2001 January 15, 2002
Expires: May, 2002 Expires: July, 2002
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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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
to execute arbitrary programs, as it has no variables, loops, or to execute arbitrary programs, as it has no variables, loops, or
ability to run external programs. ability to run external programs.
This document is a product of the IP Telephony (IPTEL) working group This document is a product of the IP Telephony (IPTEL) working group
of the Internet Engineering Task Force. Comments are solicited and of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at should be addressed to the working group's mailing list at
iptel@lists.research.bell-labs.com and/or the authors. iptel@lists.research.bell-labs.com and/or the authors.
Table of Contents
1 Introduction ........................................ 4
1.1 Conventions of This Document ........................ 4
2 Structure of CPL Scripts ............................ 4
2.1 High-level Structure ................................ 5
2.2 Abstract Structure of a Call Processing Action ...... 5
2.3 Location Model ...................................... 6
2.4 XML Structure ....................................... 6
3 Document Information ................................ 7
3.1 CPL Document Identifiers for XML .................... 7
3.2 MIME Registration ................................... 8
4 Script Structure: Overview .......................... 9
5 Switches ............................................ 10
5.1 Address Switches .................................... 11
5.1.1 Usage of "address-switch" with SIP .................. 13
5.2 String Switches ..................................... 14
5.2.1 Usage of "string-switch" with SIP ................... 15
5.3 Language Switches ................................... 15
5.3.1 Usage of "language-switch" with SIP ................. 16
5.4 Time Switches ....................................... 16
5.4.1 iCalendar differences and implementation issues ..... 22
5.5 Priority Switches ................................... 23
5.5.1 Usage of "priority-switch" with SIP ................. 24
6 Location Modifiers .................................. 24
6.1 Explicit Location ................................... 25
6.1.1 Usage of "location" with SIP ........................ 26
6.2 Location Lookup ..................................... 26
6.2.1 Usage of "lookup" with SIP .......................... 28
6.3 Location Removal .................................... 28
6.3.1 Usage of "remove-location" with SIP ................. 29
7 Signalling Operations ............................... 29
7.1 Proxy ............................................... 29
7.1.1 Usage of "proxy" with SIP ........................... 32
7.2 Redirect ............................................ 32
7.2.1 Usage of "redirect" with SIP ........................ 32
7.3 Reject .............................................. 33
7.3.1 Usage of "reject" with SIP .......................... 33
8 Non-signalling Operations ........................... 34
8.1 Mail ................................................ 34
8.1.1 Suggested Content of Mailed Information ............. 35
8.2 Log ................................................. 35
9 Subactions .......................................... 36
10 Ancillary Information ............................... 37
11 Default Behavior .................................... 38
12 CPL Extensions ...................................... 39
13 Examples ............................................ 40
13.1 Example: Call Redirect Unconditional ................ 40
13.2 Example: Call Forward Busy/No Answer ................ 40
13.3 Example: Call Forward: Redirect and Default ......... 40
13.4 Example: Call Screening ............................. 42
13.5 Example: Priority and Language Routing .............. 42
13.6 Example: Outgoing Call Screening .................... 42
13.7 Example: Time-of-day Routing ........................ 43
13.8 Example: Location Filtering ......................... 44
13.9 Example: Non-signalling Operations .................. 44
13.10 Example: Hypothetical Extensions .................... 45
13.11 Example: A Complex Example .......................... 45
14 Security Considerations ............................. 48
15 IANA Considerations ................................. 49
16 Acknowledgments ..................................... 49
A An Algorithm for Resolving Time Switches ............ 49
B Suggested Usage of CPL with H.323 ................... 51
B.1 Usage of "address-switch" with H.323 ................ 51
B.2 Usage of "string-switch" with H.323 ................. 53
B.3 Usage of "language-switch" with H.323 ............... 53
B.4 Usage of "priority-switch" with H.323 ............... 53
B.5 Usage of "location" with H.323 ...................... 53
B.6 Usage of "lookup" with H.323 ........................ 53
B.7 Usage of "remove-location" with H.323 ............... 54
C The XML DTD for CPL ................................. 54
D Changes from Earlier Versions ....................... 60
D.1 Changes from Draft -05 .............................. 60
D.2 Changes from Draft -04 .............................. 61
D.3 Changes from Draft -03 .............................. 62
D.4 Changes from Draft -02 .............................. 62
D.5 Changes from Draft -01 .............................. 63
D.6 Changes from Draft -00 .............................. 65
E Authors' Addresses .................................. 66
F Bibliography ........................................ 66
1 Introduction 1 Introduction
The Call Processing Language (CPL) is a language that can be used to The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is not tied to describe and control Internet telephony services. It is not tied to
any particular signalling architecture or protocol; it is anticipated any particular signalling architecture or protocol; it is anticipated
that it will be used with both 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
skipping to change at page 8, line 49 skipping to change at page 10, line 49
outputs, is true if the variable the switch was to match was not outputs, is true if the variable the switch was to match was not
present in the original call setup request. (In this document, this present in the original call setup request. (In this document, this
is sometimes described by saying that the information is "absent".) is sometimes described by saying that the information is "absent".)
The output "otherwise", which MUST be the last output specified if it The output "otherwise", which MUST be the last output specified if it
is present, matches if no other condition matched. is present, matches if no other condition matched.
If no condition matches and no "otherwise" output was present in the If no condition matches and no "otherwise" output was present in the
script, the default script behavior is taken. See Section 11 for more script, the default script behavior is taken. See Section 11 for more
information on this. information on this.
Switches MAY contain no outputs. They MAY contain only an "otherwise"
output.
Such switches are not particularly useful, but might be
created by tools which automatically generate CPL scripts.
5.1 Address Switches 5.1 Address Switches
Address switches allow a CPL script to make decisions based on one of Address switches allow a CPL script to make decisions based on one of
the addresses present in the original call request. They are the addresses present in the original call request. They are
summarized in Figure 4. summarized in Figure 4.
Node: "address-switch" Node: "address-switch"
Outputs: "address" Specific addresses to match Outputs: "address" Specific addresses to match
Parameters: "field" "origin", "destination", or "original-destination" Parameters: "field" "origin", "destination",
"subfield" "address-type", "user", "host", "port", "tel", or "display" or "original-destination"
"subfield" "address-type", "user", "host", "port",
"tel", or "display"
(also: "password" and "alias-type") (also: "password" and "alias-type")
Output: "address" Output: "address"
Parameters: "is" exact match Parameters: "is" exact match
"contains" substring match (for "display" only) "contains" substring match (for "display" only)
"subdomain-of" sub-domain match (for "host", "tel" only) "subdomain-of" sub-domain match (for "host", "tel" only)
Figure 4: Syntax of the "address-switch" node Figure 4: Syntax of the "address-switch" node
Address switches have two node parameters: "field", and "subfield". Address switches have two node parameters: "field", and "subfield".
skipping to change at page 13, line 43 skipping to change at page 16, line 4
For SIP, the fields "subject", "organization", and "user-agent" For SIP, the fields "subject", "organization", and "user-agent"
correspond to the SIP header fields with the same name. These are correspond to the SIP header fields with the same name. These are
used verbatim as they appear in the message. used verbatim as they appear in the message.
The field "display" is not used, and is never present. The field "display" is not used, and is never present.
5.3 Language Switches 5.3 Language Switches
Language switches allow a CPL script to make decisions based on the Language switches allow a CPL script to make decisions based on the
languages in which the originator of the call wishes to communicate. languages in which the originator of the call wishes to communicate.
They are summarized in Figure 6.
Language switches take no parameters. They are summarized in Figure 6.
The "language" outputs take one parameter, "matches". The value of
one of these parameters is a language-tag, as defined in RFC 3066
[12]. The caller may have specified a set of language-ranges, also as
defined in RFC 3066. The CPL server checks each language-tag
Node: "language-switch" Node: "language-switch"
Outputs: "language" Specific string to match Outputs: "language" Specific string to match
Parameters: None Parameters: None
Output: "language" Output: "language"
Parameters: "matches" Match if the given language matches a Parameters: "matches" Match if the given language matches a
language-range of the call. language-range of the call.
Figure 6: Syntax of the "language-switch" node Figure 6: Syntax of the "language-switch" node
Language switches take no parameters.
The "language" outputs take one parameter, "matches". The value of
one of these parameters is a language-tag, as defined in RFC 3066
[12]. The caller may have specified a set of language-ranges, also as
defined in RFC 3066. The CPL server checks each language-tag
specified by the script against the language-ranges specified in the specified by the script against the language-ranges specified in the
request. request.
See RFC 3066 for the details of how language-ranges match language- See RFC 3066 for the details of how language-ranges match language-
tags. Briefly, a language-range matches a language-tag if it exactly tags. Briefly, a language-range matches a language-tag if it exactly
equals the tag, or if it exactly equals a prefix of the tag such that equals the tag, or if it exactly equals a prefix of the tag such that
the first character following the prefix is "-". the first character following the prefix is "-".
The special language-range "*" is ignored for the purpose of If the caller specified the special language-range "*", it is ignored
matching. Languages with a "q" value of 0 are also ignored. for the purpose of matching. Languages with a "q" value of 0 are
also ignored.
This switch MAY be not-present. This switch MAY be not-present.
5.3.1 Usage of "language-switch" with SIP 5.3.1 Usage of "language-switch" with SIP
The language-ranges for the "language-switch" switch are obtained The language-ranges for the "language-switch" switch are obtained
from the SIP "Accept-Language" header field. The switch is not- from the SIP "Accept-Language" header field. The switch is not-
present if the initial SIP request did not contain this header field. present if the initial SIP request did not contain this header field.
Note that because of CPL's first-match semantics in Note that because of CPL's first-match semantics in
skipping to change at page 14, line 38 skipping to change at page 17, line 4
The language-ranges for the "language-switch" switch are obtained The language-ranges for the "language-switch" switch are obtained
from the SIP "Accept-Language" header field. The switch is not- from the SIP "Accept-Language" header field. The switch is not-
present if the initial SIP request did not contain this header field. present if the initial SIP request did not contain this header field.
Note that because of CPL's first-match semantics in Note that because of CPL's first-match semantics in
switches, "q" values other than 0 of the "Accept-Language" switches, "q" values other than 0 of the "Accept-Language"
header fields are ignored. header fields are ignored.
5.4 Time Switches 5.4 Time Switches
Time switches allow a CPL script to make decisions based on the time Time switches allow a CPL script to make decisions based on the time
and/or date the script is being executed. They are summarized in and/or date the script is being executed. They are summarized in
Figure 7. Figure 7.
Time switches are independent of the underlying signalling protocol. Time switches are independent of the underlying signalling protocol.
Time switches are based closely on the specification of recurring
intervals of time in the Internet Calendaring and Scheduling Core
Node: "time-switch" Node: "time-switch"
Outputs: "time" Specific time to match Outputs: "time" Specific time to match
Parameters: "tzid" RFC 2445 Time Zone Identifier Parameters: "tzid" RFC 2445 Time Zone Identifier
"tzurl" RFC 2445 Time Zone URL "tzurl" RFC 2445 Time Zone URL
Output: "time" Output: "time"
Parameters: "dtstart" Start of interval (RFC 2445 DATE-TIME) Parameters: "dtstart" Start of interval (RFC 2445 DATE-TIME)
"dtend" End of interval (RFC 2445 DATE-TIME) "dtend" End of interval (RFC 2445 DATE-TIME)
"duration" Length of interval (RFC 2445 DURATION) "duration" Length of interval (RFC 2445 DURATION)
"freq" Frequency of recurrence (one of "secondly", "freq" Frequency of recurrence (one of "secondly",
"minutely", "hourly", "daily", "minutely", "hourly", "daily",
"weekly", "monthly", or "yearly") "weekly", "monthly", or "yearly")
"interval" How often the recurrence repeats "interval" How often the recurrence repeats
"until" Bound of recurrence (RFC 2445 DATE-TIME) "until" Bound of recurrence (RFC 2445 DATE-TIME)
"count" Number of occurences of recurrence "count" Number of occurrences of recurrence
"bysecond" List of seconds within a minute "bysecond" List of seconds within a minute
"byminute" List of minutes within an hour "byminute" List of minutes within an hour
"byhour" List of hours of the day "byhour" List of hours of the day
"byday" List of days of the week "byday" List of days of the week
"bymonthday" List of days of the month "bymonthday" List of days of the month
"byyearday" List of days of the year "byyearday" List of days of the year
"byweekno" List of weeks of the year "byweekno" List of weeks of the year
"bymonth" List of months of the year "bymonth" List of months of the year
"wkst" First day of the workweek "wkst" First day of the workweek
"bysetpos" List of values within set of events specified "bysetpos" List of values within set of events specified
Figure 7: Syntax of the "time-switch" node Figure 7: Syntax of the "time-switch" node
Time switches are based closely on the specification of recurring
intervals of time in the Internet Calendaring and Scheduling Core
Object Specification (iCalendar COS), RFC 2445 [13]. Object Specification (iCalendar COS), RFC 2445 [13].
This allows CPLs to be generated automatically from This allows CPL scripts to be generated automatically from
calendar books. It also allows us to re-use the extensive calendar books. It also allows us to re-use the extensive
existing work specifying time intervals. existing work specifying time intervals.
If future standards-track documents are published that obsolete RFC If future standards-track documents are published that update or
2445, any changes or clarifications those documents make to obsolete RFC 2445, any changes or clarifications those documents make
recurrence handling apply to CPL time-switches as well. to recurrence handling apply to CPL time-switches as well.
An algorithm to whether an instant falls within a given recurrence is An algorithm to whether an instant falls within a given recurrence is
given in Appendix A. given in Appendix A.
The "time-switch" tag takes two optional parameters, "tzid" and The "time-switch" tag takes two optional parameters, "tzid" and
"tzurl", both of which are defined in RFC 2445 (Sections 4.8.3.1 and "tzurl", both of which are defined in RFC 2445 (Sections 4.8.3.1 and
4.8.3.5 respectively). The TZID is the identifying label by which a 4.8.3.5 respectively). The TZID is the identifying label by which a
time zone definition is referenced. If it begins with a forward slash time zone definition is referenced. If it begins with a forward slash
(solidus), it references a to-be-defined global time zone registry; (solidus), it references a to-be-defined global time zone registry;
otherwise it is locally-defined at the server. The TZURL gives a otherwise it is locally-defined at the server. The TZURL gives a
skipping to change at page 17, line 9 skipping to change at page 19, line 19
duration of the period, respectively. The "dtstart" and "dtend" duration of the period, respectively. The "dtstart" and "dtend"
parameters are formatted as iCalendar COS DATE-TIME values, as parameters are formatted as iCalendar COS DATE-TIME values, as
specified in Section 4.3.5 of RFC 2445 [13]. Because time zones are specified in Section 4.3.5 of RFC 2445 [13]. Because time zones are
specified in the top-level "time-switch" tag, only forms 1 or 2 specified in the top-level "time-switch" tag, only forms 1 or 2
(floating or UTC times) can be used. The "duration" parameter is (floating or UTC times) can be used. The "duration" parameter is
given as an iCalendar COS DURATION parameter, as specified in section given as an iCalendar COS DURATION parameter, as specified in section
4.3.6 of RFC 2445. Both the DATE-TIME and the DURATION syntaxes are 4.3.6 of RFC 2445. Both the DATE-TIME and the DURATION syntaxes are
subsets of the corresponding syntaxes from ISO 8601 [15]. subsets of the corresponding syntaxes from ISO 8601 [15].
For a recurring interval, the "duration" parameter MUST be small For a recurring interval, the "duration" parameter MUST be small
enough such that subsequent intervals do not overlap. enough such that subsequent intervals do not overlap. For non-
recurring intervals, durations of any positive length are permitted.
For non-recurring intervals, durations of any positive length are Zero-length and negative-length durations are not allowed.
permitted. Zero-length and negative-length durations are not allowed.
If no other parameters are specified, a time node indicates only a If no other parameters are specified, a time node indicates only a
single period of time. More complicated sets periods intervals are single period of time. More complicated sets periods intervals are
constructed as recurrences. A recurrence is specified by including constructed as recurrences. A recurrence is specified by including
the "freq" parameter, which indicates the type of recurrence rule. No the "freq" parameter, which indicates the type of recurrence rule. No
parameters other than "dtstart", "dtend", and "duration" SHOULD be parameters other than "dtstart", "dtend", and "duration" SHOULD be
specified unless "freq" is present, though CPL servers SHOULD accept specified unless "freq" is present, though CPL servers SHOULD accept
scripts with such parameters present, and ignore the other scripts with such parameters present, and ignore the other
parameters. parameters.
The "freq" parameter takes one of the following values: "secondly", The "freq" parameter takes one of the following values: "secondly",
to specify repeating periods based on an interval of a second or to specify repeating periods based on an interval of a second or
more; "minutely", to specify repeating periods based on an interval more; "minutely", to specify repeating periods based on an interval
of a minute or more; "hourly", to specify repeating periods based on of a minute or more; "hourly", to specify repeating periods based on
an interval of an hour or more; an interval of an hour or more; "daily", to specify repeating periods
based on an interval of a day or more; "weekly", to specify repeating
"daily", to specify repeating periods based on an interval of a day periods based on an interval of a week or more; "monthly", to specify
or more; "weekly", to specify repeating periods based on an interval repeating periods based on an interval of a month or more; and
of a week or more; "monthly", to specify repeating periods based on "yearly", to specify repeating periods based on an interval of a year
an interval of a month or more; and "yearly", to specify repeating or more. These values are not case-sensitive.
periods based on an interval of a year or more. These values are not
case-sensitive.
The "interval" parameter contains a positive integer representing how The "interval" parameter contains a positive integer representing how
often the recurrence rule repeats. The default value is "1", meaning often the recurrence rule repeats. The default value is "1", meaning
every day for a "daily" rule, every week for a "weekly" rule, every every day for a "daily" rule, every week for a "weekly" rule, every
month for a "monthly" rule and every year for a "yearly" rule. month for a "monthly" rule and every year for a "yearly" rule.
The "until" parameter defines an iCalendar COS DATE or DATE-TIME The "until" parameter defines an iCalendar COS DATE or DATE-TIME
value which bounds the recurrence rule in an inclusive manner. If the value which bounds the recurrence rule in an inclusive manner. If the
value specified by "until" is synchronized with the specified value specified by "until" is synchronized with the specified
recurrence, this date or date-time becomes the last instance of the recurrence, this date or date-time becomes the last instance of the
skipping to change at page 21, line 15 skipping to change at page 23, line 19
It does not appear to be possible to determine, in constant time, It does not appear to be possible to determine, in constant time,
whether a given instant of time falls within one of the intervals whether a given instant of time falls within one of the intervals
defined by a full iCalendar COS recurrence. The primary concerns are defined by a full iCalendar COS recurrence. The primary concerns are
as follows: as follows:
o The "count" parameter cannot be checked in constant running o The "count" parameter cannot be checked in constant running
time, since it requires that the server enumerate all time, since it requires that the server enumerate all
recurrences from "dtstart" to the present time, in order to recurrences from "dtstart" to the present time, in order to
determine whether the current recurrence satisfies the determine whether the current recurrence satisfies the
parameter. However, a server can expand a "count" paramter parameter. However, a server can expand a "count" parameter
once, off-line, to determime the date of the last recurrence. once, off-line, to determine the date of the last recurrence.
This date can then be treated as a virtual "until" parameter This date can then be treated as a virtual "until" parameter
for the server's internal processing. for the server's internal processing.
o Similarly, the "bysetpos" parameter requires that the server o Similarly, the "bysetpos" parameter requires that the server
enumerate all instances of the currence from the start of the enumerate all instances of the occurrence from the start of
current recurrence set until the present time. This requires the current recurrence set until the present time. This
somewhat more complex pre-processing, but generally, a single requires somewhat more complex pre-processing, but generally,
recurrence with a "bysetpos" parameter can be split up into a single recurrence with a "bysetpos" parameter can be split
several recurrences without them. up into several recurrences without them.
o Finally, constant running time of time switches also requires o Finally, constant running time of time switches also requires
that a candidate starting time for a recurrence can be that a candidate starting time for a recurrence can be
established quickly and uniquely, to check whether it established quickly and uniquely, to check whether it
satisfies the other restrictions. This requires that a satisfies the other restrictions. This requires that a
recurrence's duration not be longer than its repetition recurrence's duration not be longer than its repetition
interval, so that a given instant cannot fall within several interval, so that a given instant cannot fall within several
consecutive potential repetitions of the recurrence. The consecutive potential repetitions of the recurrence. The
restriction that consecutive intervals not overlap partially restriction that consecutive intervals not overlap partially
satisfies this condition, but does not fully ensure it. Again, satisfies this condition, but does not fully ensure it. Again,
skipping to change at page 27, line 48 skipping to change at page 30, line 5
7.1 Proxy 7.1 Proxy
Proxy causes the triggering call to be forwarded on to the currently Proxy causes the triggering call to be forwarded on to the currently
specified set of locations. The syntax of the proxy node is given in specified set of locations. The syntax of the proxy node is given in
Figure 12. Figure 12.
The specific signalling events invoked by the "proxy" node are The specific signalling events invoked by the "proxy" node are
signalling-protocol-dependent, though the general concept should signalling-protocol-dependent, though the general concept should
apply to any signalling protocol. apply to any signalling protocol.
After a proxy operation 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.
Node: "proxy" Node: "proxy"
Outputs: "busy" Next node if call attempt returned "busy" Outputs: "busy" Next node if call attempt returned "busy"
"noanswer" Next node if call attempt was not answered "noanswer" Next node if call attempt was not answered
before timeout before timeout
"redirection" Next node if call attempt was redirected "redirection" Next node if call attempt was redirected
"failure" Next node if call attempt failed "failure" Next node if call attempt failed
"default" Default next node for unspecified outputs "default" Default next node for unspecified outputs
Parameters: "timeout" Time to try before giving up on the call attempt Parameters: "timeout" Time to try before giving up on the call attempt
"recurse" Whether to recursively look up redirections "recurse" Whether to recursively look up redirections
"ordering" What order to try the location set in. "ordering" What order to try the location set in.
skipping to change at page 28, line 33 skipping to change at page 30, line 33
Parameters: none Parameters: none
Output: "failure" Output: "failure"
Parameters: none Parameters: none
Output: "default" Output: "default"
Parameters: none Parameters: none
Figure 12: Syntax of the "proxy" node Figure 12: Syntax of the "proxy" node
After a proxy operation has completed, the CPL server chooses the
"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, CPL execution terminates and the If the call attempt was successful, CPL execution terminates and the
server proceeds to its default behavior (normally, to allow the call server proceeds to its default behavior (normally, to allow the call
to be set up). Otherwise, the next node corresponding to one of the to be set up). Otherwise, the next node corresponding to one of the
"proxy" node's outputs is taken. The "busy" output is followed if the "proxy" node's outputs is taken. The "busy" output is followed if the
call was busy; "noanswer" is followed if the call was not answered call was busy; "noanswer" is followed if the call was not answered
before the "timeout" parameter expired; "redirection" is followed if before the "timeout" parameter expired; "redirection" is followed if
the call was redirected; and "failure" is followed if the call setup the call was redirected; and "failure" is followed if the call setup
failed for any other reason. failed for any other reason.
If one of the conditions above is true, but the corresponding output If one of the conditions above is true, but the corresponding output
skipping to change at page 30, line 37 skipping to change at page 32, line 42
7.2 Redirect 7.2 Redirect
Redirect causes the server to direct the calling party to attempt to Redirect causes the server to direct the calling party to attempt to
place its call to the currently specified set of locations. The place its call to the currently specified set of locations. The
syntax of this node is specified in Figure 13. syntax of this node is specified in Figure 13.
The specific behavior the redirect node invokes is dependent on the The specific behavior the redirect node invokes is dependent on the
underlying signalling protocol involved, though its semantics are underlying signalling protocol involved, though its semantics are
generally applicable. generally applicable.
Node: "redirect"
Outputs: None (no node may follow)
Next node: None
Parameters: "permanent" Whether the redirection should be
considered permanent
Figure 13: Syntax of the "redirect" node
Redirect immediately terminates execution of the CPL script, so this Redirect immediately terminates execution of the CPL script, so this
node has no outputs and no next node. It has one parameter, node has no outputs and no next node. It has one parameter,
"permanent", which specifies whether the result returned should "permanent", which specifies whether the result returned should
indicate that this is a permanent redirection. The value of this indicate that this is a permanent redirection. The value of this
parameter is either "yes" or "no" and its default value is "no." parameter is either "yes" or "no" and its default value is "no."
7.2.1 Usage of "redirect" with SIP 7.2.1 Usage of "redirect" with SIP
The SIP server SHOULD send a 3xx class response to a call request The SIP server SHOULD send a 3xx class response to a call request
Node: "redirect"
Outputs: None (no node may follow)
Next node: None
Parameters: "permanent" Whether the redirection should be
considered permanent
Figure 13: Syntax of the "redirect" node
upon executing a "redirect" tag. If "permanent" was "yes", the server upon executing a "redirect" tag. If "permanent" was "yes", the server
SHOULD send the response "301 Moved permanently"; otherwise it SHOULD SHOULD send the response "301 Moved permanently"; otherwise it SHOULD
send "302 Moved temporarily". send "302 Moved temporarily".
7.3 Reject 7.3 Reject
Reject nodes cause the server to reject the call attempt. Their Reject nodes cause the server to reject the call attempt. Their
syntax is given in Figure 14. The specific behavior they invoke is syntax is given in Figure 14. The specific behavior they invoke is
dependent on the underlying signalling protocol involved, though dependent on the underlying signalling protocol involved, though
their semantics are generally applicable. their semantics are generally applicable.
skipping to change at page 33, line 46 skipping to change at page 36, line 5
if available, the call priority. if available, the call priority.
The server SHOULD honor the user's requested languages, and send the The server SHOULD honor the user's requested languages, and send the
mail notification using an appropriate language and character set. mail notification using an appropriate language and character set.
8.2 Log 8.2 Log
The Log node causes the server to log information about the call to The Log node causes the server to log information about the call to
non-volatile storage. Its syntax is specified in Figure 16. non-volatile storage. Its syntax is specified in Figure 16.
Log takes two arguments, both optional: "name", 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
Node: "log" Node: "log"
Outputs: None (next node follows directly) Outputs: None (next node follows directly)
Next node: Any node Next node: Any node
Parameters: "name" Name of the log file to use Parameters: "name" Name of the log file to use
"comment" Comment to be placed in log file "comment" Comment to be placed in log file
Figure 16: Syntax of the "log" node Figure 16: Syntax of the "log" node
Log takes two arguments, both optional: "name", which specifies the
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 logged the event. If are specific to the owner of the script which logged the event. If
the "name" parameter is not given, the event is logged to a standard, the "name" parameter is not given, the event is logged to a standard,
server-defined log file for the script owner. This specification does server-defined log file for the script owner. This specification does
not define how users may retrieve their logs from the server. not define how users may retrieve their logs from the server.
The name of a log is a logical name only, and does not necessarily The name of a log is a logical name only, and does not necessarily
correspond to any physical file on the server. The interpretation of correspond to any physical file on the server. The interpretation of
the log file name is server defined, as is a mechanism to access the log file name is server defined, as is a mechanism to access
these logs. The CPL server SHOULD NOT directly map log names these logs. The CPL server SHOULD NOT directly map log names
uninterpreted onto local file names, for security reasons, lest a uninterpreted onto local file names, for security reasons, lest a
skipping to change at page 34, line 43 skipping to change at page 37, line 5
Two tags are defined for subactions: subaction definitions and Two tags are defined for subactions: subaction definitions and
subaction references. Their syntax is given in Figure 17. subaction references. Their syntax is given in Figure 17.
Subactions are defined through "subaction" tags. These tags are Subactions are defined through "subaction" tags. These tags are
placed in the CPL after any ancillary information (see Section 10) placed in the CPL after any ancillary information (see Section 10)
but before any top-level tags. They take one argument: "id", a token but before any top-level tags. They take one argument: "id", a token
indicating a script-chosen name for the subaction. The "id" value for indicating a script-chosen name for the subaction. The "id" value for
every "subaction" tag in a script MUST be unique within that script. every "subaction" tag in a script MUST be unique within that script.
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.
Tag: "subaction" Tag: "subaction"
Subtags: Any node Subtags: Any node
Parameters: "id" Name of this subaction Parameters: "id" Name of this subaction
Pseudo-node: "sub" Pseudo-node: "sub"
Outputs: None in XML tree Outputs: None in XML tree
Parameters: "ref" Name of subaction to execute Parameters: "ref" Name of subaction to execute
Figure 17: Syntax of subactions and "sub" pseudo-nodes Figure 17: Syntax of subactions and "sub" pseudo-nodes
Subactions are 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 References to subactions MUST refer to subactions defined before the
current action. A "sub" tag MUST NOT refer to the action which it current action. A "sub" tag MUST NOT refer to the action which it
appears in, or to any action defined later in the CPL script. Top- 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 level actions cannot be called from "sub" tags, or through any other
means. Script servers MUST verify at the time the script is submitted means. Script servers MUST verify at the time the script is submitted
that no "sub" node refers to any subaction which is not its proper that no "sub" node refers to any subaction which is not its proper
predecessor. predecessor.
Allowing only back-references of subs forbids any sort of Allowing only back-references of subs forbids any sort of
recursion. Recursion would introduce the possibility of recursion. Recursion would introduce the possibility of
skipping to change at page 38, line 28 skipping to change at page 40, line 37
method for validating XML documents, as well as improving method for validating XML documents, as well as improving
upon DTDs' expressive power in many other ways. upon DTDs' expressive power in many other ways.
13 Examples 13 Examples
13.1 Example: Call Redirect Unconditional 13.1 Example: Call Redirect Unconditional
The script in Figure 19 is a simple script which redirects all calls The script in Figure 19 is a simple script which redirects all calls
to a single fixed location. to a single fixed location.
13.2 Example: Call Forward Busy/No Answer
The script in Figure 20 illustrates some more complex behavior. We
see an initial proxy attempt to one address, with further operations
if that fails. We also see how several outputs take the same action
subtree, through the use of subactions.
13.3 Example: Call Forward: Redirect and Default
The script in Figure 21 illustrates further proxy behavior. The
server initially tries to proxy to a single address. If this attempt
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<location url="sip:smith@phone.example.com"> <location url="sip:smith@phone.example.com">
<redirect /> <redirect />
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 19: Example Script: Call Redirect Unconditional Figure 19: Example Script: Call Redirect Unconditional
13.2 Example: Call Forward Busy/No Answer
The script in Figure 20 illustrates some more complex behavior. We
see an initial proxy attempt to one address, with further operations
if that fails. We also see how several outputs take the same action
subtree, through the use of subactions.
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com" > <location url="sip:jones@voicemail.example.com" >
<proxy /> <proxy />
</location> </location>
</subaction> </subaction>
skipping to change at page 39, line 31 skipping to change at page 41, line 43
<noanswer> <noanswer>
<sub ref="voicemail" /> <sub ref="voicemail" />
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 20: Example Script: Call Forward Busy/No Answer Figure 20: Example Script: Call Forward Busy/No Answer
13.3 Example: Call Forward: Redirect and Default
The script in Figure 21 illustrates further proxy behavior. The
server initially tries to proxy to a single address. If this attempt
is redirected, a new redirection is generated using the locations is redirected, a new redirection is generated using the locations
returned. In all other failure cases for the proxy node, a default returned. In all other failure cases for the proxy node, a default
operation -- forwarding to voicemail -- is performed. operation -- forwarding to voicemail -- is performed.
13.4 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
operations. The server therefore proceeds with its default behavior,
which would presumably be to contact the user.
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<location url="sip:jones@jonespc.example.com"> <location url="sip:jones@jonespc.example.com">
<proxy> <proxy>
<redirection> <redirection>
<redirect /> <redirect />
</redirection> </redirection>
skipping to change at page 40, line 27 skipping to change at page 42, line 27
<proxy /> <proxy />
</location> </location>
</default> </default>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 21: Example Script: Call Forward: Redirect and Default Figure 21: Example Script: Call Forward: Redirect and Default
13.4 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
operations. The server therefore proceeds with its default behavior,
which would presumably be to contact the user.
13.5 Example: Priority and Language Routing
The script in Figure 23 illustrates service selection based on a
call's priority value and language settings. If the call request had
a priority of "urgent" or higher, the default script behavior is
performed. Otherwise, the language field is checked for the language
"es" (Spanish). If it is present, the call is proxied to a Spanish-
speaking operator; other calls are proxied to an English-speaking
operator.
13.6 Example: Outgoing Call Screening
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<address-switch field="origin" subfield="user"> <address-switch field="origin" subfield="user">
<address is="anonymous"> <address is="anonymous">
<reject status="reject" <reject status="reject"
reason="I don't accept anonymous calls" /> reason="I don't accept anonymous calls" />
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 22: Example Script: Call Screening Figure 22: Example Script: Call Screening
13.5 Example: Priority and Language Routing The script in Figure 24 illustrates a script filtering outgoing
calls, in the form of a script which prevent 1-900 (premium) calls
from being placed. This script also illustrates subdomain matching.
The script in Figure 23 illustrates service selection based on a <?xml version="1.0" ?>
call's priority value and language settings. If the call request had <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
a priority of "urgent" or higher, the default script behavior is
performed. Otherwise, the language field is checked for the language <cpl>
"es" (Spanish). If it is present, the call is proxied to a Spanish- <outgoing>
speaking operator; other calls are proxied to an English-speaking <address-switch field="original-destination" subfield="tel">
operator. <address subdomain-of="1900">
<reject status="reject"
reason="Not allowed to make 1-900 calls." />
</address>
</address-switch>
</outgoing>
</cpl>
Figure 24: Example Script: Outgoing Call Screening
13.7 Example: Time-of-day Routing
Figure 25 illustrates time-based conditions and timezones.
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<priority-switch> <priority-switch>
<priority greater="urgent" /> <priority greater="urgent" />
<otherwise> <otherwise>
<language-switch> <language-switch>
skipping to change at page 41, line 38 skipping to change at page 44, line 32
</location> </location>
</otherwise> </otherwise>
</language-switch> </language-switch>
</otherwise> </otherwise>
</priority-switch> </priority-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 23: Example Script: Priority and Language Routing Figure 23: Example Script: Priority and Language Routing
13.6 Example: Outgoing Call Screening 13.8 Example: Location Filtering
The script in Figure 24 illustrates a script filtering outgoing
calls, in the form of a script which prevent 1-900 (premium) calls
from being placed. This script also illustrates subdomain matching.
13.7 Example: Time-of-day Routing
Figure 25 illustrates time-based conditions and timezones.
<?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> Figure 26 illustrates filtering operations on the location set. In
<outgoing> this example, we assume that version 0.9beta2 of the "Inadequate
<address-switch field="original-destination" subfield="tel"> Software SIP User Agent" mis-implements some features, and so we must
<address subdomain-of="1900"> work around its problems. We assume, first, that the value of its
<reject status="reject" "feature" parameter in caller preferences is known to be unreliable,
reason="Not allowed to make 1-900 calls." /> so we ignore it; we also know that it cannot talk successfully to one
</address> particular mobile device we may have registered, so we remove that
</address-switch> location from the location set. Once these two operations have been
</outgoing> completed, call setup is allowed to proceed normally.
</cpl>
Figure 24: Example Script: Outgoing Call Screening 13.9 Example: Non-signalling Operations
Figure 27 illustrates non-signalling operations; in particular,
alerting a user by electronic mail if the lookup server failed. The
primary motivation for having the "mail" node is to allow this sort
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<time-switch tzid="America/New_York" <time-switch tzid="America/New_York"
tzurl="http://zones.example.com/tz/America/New_York"> tzurl="http://zones.example.com/tz/America/New_York">
<time dtstart="20000703T090000" duration="PT8H" <time dtstart="20000703T090000" duration="PT8H"
freq="weekly" byday="MO,TU,WE,TH,FR"> freq="weekly" byday="MO,TU,WE,TH,FR">
<lookup source="registration"> <lookup source="registration">
skipping to change at page 43, line 5 skipping to change at page 45, line 30
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<proxy /> <proxy />
</location> </location>
</otherwise> </otherwise>
</time-switch> </time-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 25: Example Script: Time-of-day Routing Figure 25: Example Script: Time-of-day Routing
13.8 Example: Location Filtering of out-of-band notification of error conditions, as the user might
otherwise be unaware of any problem.
Figure 26 illustrates filtering operations on the location set. In 13.10 Example: Hypothetical Extensions
this example, we assume that version 0.9beta2 of the "Inadequate
Software SIP User Agent" mis-implements some features, and so we must The example in Figure 28 shows a hypothetical extension which
work around its problems. We assume, first, that the value of its implements distinctive ringing. The XML namespace
"feature" parameter in caller preferences is known to be unreliable, "http://www.example.com/distinctive-ring" specifies a new node named
so we ignore it; we also know that it cannot talk successfully to one "ring".
particular mobile device we may have registered, so we remove that
location from the location set. Once these two operations have been
completed, call setup is allowed to proceed normally.
The example in Figure 29 implements a hypothetical new attribute for
address switches, to allow regular-expression matches. It defines a
new attribute "regex" for the standard "address" node. In this
example, the global namespace is not specified.
13.11 Example: A Complex Example
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<string-switch field="user-agent"> <string-switch field="user-agent">
<string is="Inadequate Software SIP User Agent/0.9beta2"> <string is="Inadequate Software SIP User Agent/0.9beta2">
<lookup source="registration" ignore="feature"> <lookup source="registration" ignore="feature">
<success> <success>
<remove-location location="sip:me@mobile.provider.net"> <remove-location location="sip:me@mobile.provider.net">
skipping to change at page 43, line 38 skipping to change at page 46, line 25
</remove-location> </remove-location>
</success> </success>
</lookup> </lookup>
</string> </string>
</string-switch> </string-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 26: Example Script: Location Filtering Figure 26: Example Script: Location Filtering
13.9 Example: Non-signalling Operations
Figure 27 illustrates non-signalling operations; in particular,
alerting a user by electronic mail if the lookup server failed. The
primary motivation for having 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.
13.10 Example: Hypothetical Extensions
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<lookup <lookup
source="http://www.example.com/cgi-bin/locate.cgi?user=jones" source="http://www.example.com/cgi-bin/locate.cgi?user=jones"
timeout="8"> timeout="8">
<success> <success>
<proxy /> <proxy />
</success> </success>
<failure> <failure>
<mail url="mailto:jones@example.com?subject=lookup%20failed" /> <mail url="mailto:jones@example.com?subject=lookup%20failed" />
</failure> </failure>
</lookup> </lookup>
</incoming> </incoming>
</cpl> </cpl>
Figure 27: Example Script: Non-signalling Operations Figure 27: Example Script: Non-signalling Operations
The example in Figure 28 shows a hypothetical extension which
implements distinctive ringing. The XML namespace
"http://www.example.com/distinctive-ring" specifies a new node named
"ring".
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl xmlns="http://www.rfc-editor.org/rfc/rfcXXXX.txt" <cpl xmlns="http://www.rfc-editor.org/rfc/rfcXXXX.txt"
xmlns:dr="http://www.example.com/distinctive-ring"> xmlns:dr="http://www.example.com/distinctive-ring">
<incoming> <incoming>
<address-switch field="origin"> <address-switch field="origin">
<address is="sip:boss@example.com"> <address is="sip:boss@example.com">
<dr:ring ringstyle="warble" /> <dr:ring ringstyle="warble" />
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 28: Example Script: Hypothetical Distinctive-Ringing Extension Figure 28: Example Script: Hypothetical Distinctive-Ringing Extension
The example in Figure 29 implements a hypothetical new attribute for
address switches, to allow regular-expression matches. It defines a
new attribute "regex" for the standard "address" node. In this
example, the global namespace is not specified.
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<incoming> <incoming>
<address-switch field="origin" subfield="user" <address-switch field="origin" subfield="user"
xmlns:re="http://www.example.com/regex"> xmlns:re="http://www.example.com/regex">
<address re:regex="(.*.smith|.*.jones)"> <address re:regex="(.*.smith|.*.jones)">
<reject status="reject" <reject status="reject"
reason="I don't want to talk to Smiths or Joneses" /> reason="I don't want to talk to Smiths or Joneses" />
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 29: Example Script: Hypothetical Regular-Expression Extension Figure 29: Example Script: Hypothetical Regular-Expression Extension
13.11 Example: A Complex Example
Finally, Figure 30 is a complex example which shows the sort of Finally, Figure 30 is a complex example which shows the sort of
sophisticated behavior which can be achieved by combining CPL nodes. sophisticated behavior 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 mobile phone, and all other calls are directed are forwarded to his mobile phone, and all other calls are directed
to voicemail. If the call setup failed, no operation is specified, to voicemail. If the call setup failed, no operation is specified,
so the server's default behavior is performed. so the server's default behavior is performed.
14 Security Considerations
The CPL is designed to allow services to be specified in a manner
which prevents potentially hostile or mis-configured scripts from
launching security attacks, including denial-of-service attacks.
Because script runtime is strictly bounded by acyclicity, and because
the number of possible script operations are strictly limited,
scripts should not be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by
which scripts are transmitted from a client to a server MUST be
<?xml version="1.0" ?> <?xml version="1.0" ?>
<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">
<cpl> <cpl>
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<redirect /> <redirect />
</location> </location>
</subaction> </subaction>
skipping to change at page 46, line 39 skipping to change at page 48, line 40
</otherwise> </otherwise>
</address-switch> </address-switch>
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 30: Example Script: A Complex Example Figure 30: Example Script: A Complex Example
14 Security Considerations
The CPL is designed to allow services to be specified in a manner
which prevents potentially hostile or mis-configured scripts from
launching security attacks, including denial-of-service attacks.
Because script runtime is strictly bounded by acyclicity, and because
the number of possible script operations are strictly limited,
scripts should not be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by
which scripts are transmitted from a client to a server MUST be
strongly authenticated. Such a method is not specified in this strongly authenticated. Such a method is not specified in this
document. document.
Script servers SHOULD allow server administrators to control the Script servers SHOULD allow server administrators to control the
details of what CPL operations are permitted. details of what CPL operations are permitted.
15 IANA Considerations 15 IANA Considerations
This document registers the MIME type application/cpl+xml. See This document registers the MIME type application/cpl+xml. See
Section 3.2. Section 3.2.
skipping to change at page 47, line 52 skipping to change at page 50, line 15
1. Compute the time of the call, in the timezone of the time 1. Compute the time of the call, in the timezone of the time
switch. switch.
2. If the call time is earlier than "dtstart", fail NOMATCH. 2. If the call time is earlier than "dtstart", fail NOMATCH.
3. If the call time is less than "duration" after dtstart, 3. If the call time is less than "duration" after dtstart,
succeed MATCH. succeed MATCH.
4. Determine the smallest unit specified in a "byxxx" rule or 4. Determine the smallest unit specified in a "byxxx" rule or
by the "freq." Call this the Minimum Unit. Determine the by the "freq." Call this the Minimum Unit. Determine the
previous instant (before the call time) when all the time previous instant (before or equal to the call time) when
units smaller than the minimum unit are the same as those all the time units smaller than the minimum unit are the
of "dtstart." If the minimum unit is a second, this time is same as those of "dtstart." If the minimum unit is a
the same as the instant. If the minimum unit is a minute or second, this time is the same as the instant. If the
an hour, the minutes or the minutes and hours, minimum unit is a minute or an hour, the minutes or the
respectively, must be the same as "dtstart". For all other minutes and hours, respectively, must be the same as
minimum units, the time-of-day must be the same as "dtstart". For all other minimum units, the time-of-day
"dtstart." If the minimum unit is a week, the day-of-the- must be the same as "dtstart." If the minimum unit is a
week must be the same as "dtstart." If the minimum unit is week, the day-of-the-week must be the same as "dtstart." If
a month, the day-of-the-month must be the same as the minimum unit is a month, the day-of-the-month must be
"dtstart." If the minimum unit is a year, the month and the same as "dtstart." If the minimum unit is a year, the
day-of-month must both be the same as "dtstart." (Note that month and day-of-month must both be the same as "dtstart."
this means it may be necessary to roll back more than one (Note that this means it may be necessary to roll back more
minimum unit -- if the minimum unit is a month, then some than one minimum unit -- if the minimum unit is a month,
months do not have a 31st (or 30th or 29th) day; if the then some months do not have a 31st (or 30th or 29th) day;
minimum unit is a year, then some years do not have a if the minimum unit is a year, then some years do not have
February 29th. In the Gregorian calendar, it is never a February 29th. In the Gregorian calendar, it is never
necessary to roll back more than two months if the minimum necessary to roll back more than two months if the minimum
unit is a month, or eight years if the minimum unit is a unit is a month, or eight years if the minimum unit is a
year. Between 1904 and 2096, it is never necessary to roll year. Between 1904 and 2096, it is never necessary to roll
back more than four years -- the eight-year rollback can back more than four years -- the eight-year rollback can
only occur when the Gregorian calendar "skips" a leap year. only occur when the Gregorian calendar "skips" a leap year.
Call this instant the Candidate Start Time. Call this instant the Candidate Start Time.
5. If the time between the candidate start time and the call 5. If the time between the candidate start time and the call
time is more than the duration, fail NOMATCH. time is more than the duration, fail NOMATCH.
skipping to change at page 50, line 30 skipping to change at page 52, line 41
transportID: if the TransportAddress is of type "ipAddress," transportID: if the TransportAddress is of type "ipAddress,"
"ipSourceRoute," or "ip6Address," the "host" subfield is "ipSourceRoute," or "ip6Address," the "host" subfield is
set to the "ip" element of the sequence, translated into set to the "ip" element of the sequence, translated into
the standard IPv4 or IPv6 textual representation, and the the standard IPv4 or IPv6 textual representation, and the
"port" subfield is set to the "port" element of the "port" subfield is set to the "port" element of the
sequence represented in decimal. The "tel" and "user" sequence represented in decimal. The "tel" and "user"
fields are not present. The "entire-address" form is not fields are not present. The "entire-address" form is not
defined. The representation and mapping of transport defined. The representation and mapping of transport
addresses is not defined for non-IP addresses. addresses is not defined for non-IP addresses.
H.323 version 4 [23] and the Internet-Draft draft-levin-iptel-h323- H.323 version 4 [2] defines an "h323" URI scheme. This appendix
url-scheme-00 [24] define a "h323" URI scheme. This appendix defines defines a mapping for these URIs onto the CPL "address-switch"
a mapping for these URIs onto the CPL "address-switch" subfields, as subfields, as given in Section 5.1. This definition is also
given in Section 5.1. Neither of these documents has yet been available as RFC YYYY [23], which is an excerpt from the H.323
formally published in a final form, so this appendix is non- specification. [Note to RFC Editor: "RFC YYYY" indicates the
normative. publication as an RFC of draft-levin-iptel-h323-url-scheme-04, which
is currently in the RFC Editor's Queue.]
For h323 URIs, the the "user", "host", and "port" subfields are set For h323 URIs, the the "user", "host", and "port" subfields are set
to the corresponding parts of the H.323 URL. The "tel" subfield is to the corresponding parts of the H.323 URL. The "tel" subfield is
not present. The "entire-address" form corresponds to the entire URI. not present. The "entire-address" form corresponds to the entire URI.
This mapping MAY be used both for h323 URIs in an h323 "url-ID" This mapping MAY be used both for h323 URIs in an h323 "url-ID"
address alias, and for h323 URIs in SIP messages. address alias, and for h323 URIs in SIP messages.
B.2 Usage of "string-switch" with H.323 B.2 Usage of "string-switch" with H.323
skipping to change at page 53, line 7 skipping to change at page 55, line 7
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 MAY allow minor variations from it, DTD. However, CPL servers MAY allow minor variations from it,
particularly in the ordering of the outputs of nodes. Note that particularly in the ordering of the outputs of nodes. Note that
compliance with this DTD is not a sufficient condition for compliance with this DTD is not a sufficient condition for
correctness of a CPL script, as many of the conditions described in correctness of a CPL script, as many of the conditions described in
this specification are not expressible in DTD syntax. this specification are not expressible in DTD syntax.
<?xml version="1.0" encoding="US-ASCII" ?> <?xml version="1.0" encoding="US-ASCII" ?>
<!--
Draft DTD for CPL, corresponding to
draft-ietf-iptel-cpl-01.
-->
<!-- Nodes. --> <!-- Nodes. -->
<!-- Switch nodes --> <!-- Switch nodes -->
<!ENTITY % Switch 'address-switch|string-switch|language-switch| <!ENTITY % Switch 'address-switch|string-switch|language-switch|
time-switch|priority-switch' > time-switch|priority-switch' >
<!-- Location nodes --> <!-- Location nodes -->
<!ENTITY % Location 'location|lookup|remove-location' > <!ENTITY % Location 'location|lookup|remove-location' >
<!-- Signalling action nodes --> <!-- Signalling action nodes -->
<!ENTITY % SignallingAction 'proxy|redirect|reject' > <!ENTITY % SignallingAction 'proxy|redirect|reject' >
skipping to change at page 53, line 44 skipping to change at page 55, line 39
<!-- Switches: choices a CPL script can make. --> <!-- Switches: choices a CPL script can make. -->
<!-- All switches can have an 'otherwise' output. --> <!-- All switches can have an 'otherwise' output. -->
<!ELEMENT otherwise ( %Node; ) > <!ELEMENT otherwise ( %Node; ) >
<!-- All switches can have a 'not-present' output. --> <!-- All switches can have a 'not-present' output. -->
<!ELEMENT not-present ( %Node; ) > <!ELEMENT not-present ( %Node; ) >
<!-- Address-switch makes choices based on addresses. --> <!-- Address-switch makes choices based on addresses. -->
<!ELEMENT address-switch ( (address|not-present)*, otherwise? ) > <!ELEMENT address-switch ( address*, (not-present, address*)?,
otherwise? ) >
<!-- <not-present> must appear at most once --> <!-- <not-present> must appear at most once -->
<!ATTLIST address-switch <!ATTLIST address-switch
field CDATA #REQUIRED field CDATA #REQUIRED
subfield CDATA #IMPLIED subfield CDATA #IMPLIED
> >
<!ELEMENT address ( %Node; ) > <!ELEMENT address ( %Node; ) >
<!ATTLIST address <!ATTLIST address
is CDATA #IMPLIED is CDATA #IMPLIED
contains CDATA #IMPLIED contains CDATA #IMPLIED
subdomain-of CDATA #IMPLIED subdomain-of CDATA #IMPLIED
> <!-- Exactly one of these three attributes must appear --> > <!-- Exactly one of these three attributes must appear -->
<!-- String-switch makes choices based on strings. --> <!-- String-switch makes choices based on strings. -->
skipping to change at page 54, line 14 skipping to change at page 56, line 10
<!ELEMENT address ( %Node; ) > <!ELEMENT address ( %Node; ) >
<!ATTLIST address <!ATTLIST address
is CDATA #IMPLIED is CDATA #IMPLIED
contains CDATA #IMPLIED contains CDATA #IMPLIED
subdomain-of CDATA #IMPLIED subdomain-of CDATA #IMPLIED
> <!-- Exactly one of these three attributes must appear --> > <!-- Exactly one of these three attributes must appear -->
<!-- String-switch makes choices based on strings. --> <!-- String-switch makes choices based on strings. -->
<!ELEMENT string-switch ( (string|not-present)*, otherwise? ) > <!ELEMENT string-switch ( string*, (not-present, string*)?,
otherwise? ) >
<!-- <not-present> must appear at most once --> <!-- <not-present> must appear at most once -->
<!ATTLIST string-switch <!ATTLIST string-switch
field CDATA #REQUIRED field CDATA #REQUIRED
> >
<!ELEMENT string ( %Node; ) > <!ELEMENT string ( %Node; ) >
<!ATTLIST string <!ATTLIST string
is CDATA #IMPLIED is CDATA #IMPLIED
contains CDATA #IMPLIED contains CDATA #IMPLIED
> <!-- Exactly one of these two attributes must appear --> > <!-- Exactly one of these two attributes must appear -->
<!-- Language-switch makes choices based on the originator's preferred <!-- Language-switch makes choices based on the originator's preferred
languages. --> languages. -->
<!ELEMENT language-switch ( (language|not-present)*, otherwise? ) > <!ELEMENT language-switch ( language*, (not-present, language*)?,
otherwise? ) >
<!-- <not-present> must appear at most once --> <!-- <not-present> must appear at most once -->
<!ELEMENT language ( %Node; ) > <!ELEMENT language ( %Node; ) >
<!ATTLIST language <!ATTLIST language
matches CDATA #REQUIRED matches CDATA #REQUIRED
> >
<!-- Time-switch makes choices based on the current time. --> <!-- Time-switch makes choices based on the current time. -->
<!ELEMENT time-switch ( (time|not-present)*, otherwise? ) > <!ELEMENT time-switch ( time*, (not-present, time*)?, otherwise? ) >
<!ATTLIST time-switch <!ATTLIST time-switch
tzid CDATA #IMPLIED tzid CDATA #IMPLIED
tzurl CDATA #IMPLIED tzurl CDATA #IMPLIED
> >
<!ELEMENT time ( %Node; ) > <!ELEMENT time ( %Node; ) >
<!-- Exactly one of the two attributes "dtend" and "duration" <!-- Exactly one of the two attributes "dtend" and "duration"
must occur. --> must occur. -->
<!-- The value of "freq" is (daily|weekly|monthly|yearly). It is <!-- The value of "freq" is (daily|weekly|monthly|yearly). It is
skipping to change at page 55, line 16 skipping to change at page 57, line 14
<!-- None of the attributes following freq are meaningful unless freq <!-- None of the attributes following freq are meaningful unless freq
appears. --> appears. -->
<!-- The value of "wkst" is (MO|TU|WE|TH|FR|SA|SU). It is <!-- The value of "wkst" is (MO|TU|WE|TH|FR|SA|SU). It is
case-insensitive, so it is not given as a DTD switch. --> case-insensitive, so it is not given as a DTD switch. -->
<!ATTLIST time <!ATTLIST time
dtstart CDATA #REQUIRED dtstart CDATA #REQUIRED
dtend CDATA #IMPLIED dtend CDATA #IMPLIED
duration CDATA #IMPLIED duration CDATA #IMPLIED
freq CDATA #IMPLIED freq CDATA #IMPLIED
until CDATA #IMPLIED until CDATA #IMPLIED
count CDATA #IMPLIED
interval CDATA "1" interval CDATA "1"
bysecond CDATA #IMPLIED
byminute CDATA #IMPLIED
byhour CDATA #IMPLIED
byday CDATA #IMPLIED byday CDATA #IMPLIED
bymonthday CDATA #IMPLIED bymonthday CDATA #IMPLIED
byyearday CDATA #IMPLIED byyearday CDATA #IMPLIED
byweekno CDATA #IMPLIED byweekno CDATA #IMPLIED
bymonth CDATA #IMPLIED bymonth CDATA #IMPLIED
wkst CDATA "MO" wkst CDATA "MO"
bysetpos CDATA #IMPLIED
> >
<!-- Priority-switch makes choices based on message priority. --> <!-- Priority-switch makes choices based on message priority. -->
<!ELEMENT priority-switch ( (priority|not-present)*, otherwise? ) > <!ELEMENT priority-switch ( priority*, (not-present, priority*)?,
otherwise? ) >
<!-- <not-present> must appear at most once --> <!-- <not-present> must appear at most once -->
<!ENTITY % PriorityVal '(emergency|urgent|normal|non-urgent)' > <!ENTITY % PriorityVal '(emergency|urgent|normal|non-urgent)' >
<!ELEMENT priority ( %Node; ) > <!ELEMENT priority ( %Node; ) >
<!-- Exactly one of these three attributes must appear --> <!-- Exactly one of these three attributes must appear -->
<!ATTLIST priority <!ATTLIST priority
less %PriorityVal; #IMPLIED less %PriorityVal; #IMPLIED
greater %PriorityVal; #IMPLIED greater %PriorityVal; #IMPLIED
skipping to change at page 58, line 24 skipping to change at page 60, line 26
<!-- The top-level element of the script. --> <!-- The top-level element of the script. -->
<!ELEMENT cpl ( %Ancillary;,%Subactions;,%TopLevelActions; ) > <!ELEMENT cpl ( %Ancillary;,%Subactions;,%TopLevelActions; ) >
D Changes from Earlier Versions D Changes from Earlier Versions
[Note to RFC Editor: please remove this appendix before [Note to RFC Editor: please remove this appendix before
publication as an RFC.] publication as an RFC.]
D.1 Changes from Draft -04 D.1 Changes from Draft -05
The changebars in the Postscript and PDF versions of this document The changebars in the Postscript and PDF versions of this document
indicate significant changes from this version. indicate significant changes from this version.
o Clarified that switch nodes are allowed to be degenerate --
they can have no outputs, and they can have only an
"otherwise" output.
o Clarified the (non-) usage of the special language-range "*".
o Clarified that the Candidate Start Time can be equal to the
call time.
o Modified the DTD to require that the "not-present" output
appear only once.
o Added DTD entries for the "time-switch" attributes re-added in
draft -05.
o Updated the reference to ISO 8601 to cite 8601:2000.
o Updated all H.323 references to cite H.323v4.
o Corrected some spelling errors.
D.2 Changes from Draft -04
o Broke out language switches into their own switch node. o Broke out language switches into their own switch node.
o Restored the full iCalendar COS recurrence specification. o Restored the full iCalendar COS recurrence specification.
Added text describing the consequences of this for Added text describing the consequences of this for
implementors, and expanded somewhat on the recurrence implementors, and expanded somewhat on the recurrence
algorithm. algorithm.
o Clarified when time zones are resolved. o Clarified when time zones are resolved.
o Spelled out "iCalendar" rather than abbreviating it "iCal." o Spelled out "iCalendar" rather than abbreviating it "iCal."
skipping to change at page 59, line 29 skipping to change at page 62, line 5
can trigger a default action, just like anything else. can trigger a default action, just like anything else.
o Clarified that the time-switch resolution algorithm is non- o Clarified that the time-switch resolution algorithm is non-
normative. normative.
o Updated references to previously-unpublished RFCs, now o Updated references to previously-unpublished RFCs, now
published. published.
o Thanked Richard Gumpertz. o Thanked Richard Gumpertz.
D.2 Changes from Draft -03 D.3 Changes from Draft -03
o Removed an obsolete reference to a usage in examples which o Removed an obsolete reference to a usage in examples which
wasn't actually used anywhere. wasn't actually used anywhere.
o Added forward references to "remove-location", "mail" and o Added forward references to "remove-location", "mail" and
"log", as well as "location", in the XML syntax as examples of "log", as well as "location", in the XML syntax as examples of
nodes that don't have explicit output tags. nodes that don't have explicit output tags.
o Made the usage of some terminology more consistent: "output" o Made the usage of some terminology more consistent: "output"
vs. "next node"; "action" vs. "operation" vs. "behavior"; vs. "next node"; "action" vs. "operation" vs. "behavior";
skipping to change at page 60, line 27 skipping to change at page 62, line 51
extensions only. extensions only.
o Expunged some references to sub-daily recurrences which had o Expunged some references to sub-daily recurrences which had
accidentally been left in the text. accidentally been left in the text.
o Updated bibliography to refer to the latest versions of the o Updated bibliography to refer to the latest versions of the
cited documents. cited documents.
o Fixed a number of typographical errors. o Fixed a number of typographical errors.
D.3 Changes from Draft -02 D.4 Changes from Draft -02
o Reduced time-switches from the full iCal recurrence to an iCal o Reduced time-switches from the full iCal recurrence to an iCal
subset. Added an appendix giving an algorithm to resolve subset. Added an appendix giving an algorithm to resolve
time-switches. time-switches.
o Added the extension mechanism. o Added the extension mechanism.
o Made explicit how each node is dependent on protocol handling. o Made explicit how each node is dependent on protocol handling.
Separated out protocol-specific information -- for SIP in Separated out protocol-specific information -- for SIP in
subsections of the main text, for H.323 in a non-normative subsections of the main text, for H.323 in a non-normative
appendix. appendix.
skipping to change at page 61, line 22 skipping to change at page 63, line 46
o Pointed out that log names are logical names, and should not o Pointed out that log names are logical names, and should not
be interpreted as verbatim filenames. be interpreted as verbatim filenames.
o Added some examples. o Added some examples.
o Clarified some wording. o Clarified some wording.
o Fixed some typographical errors. o Fixed some typographical errors.
D.4 Changes from Draft -01 D.5 Changes from Draft -01
o Completely re-wrote changes to time switches: they are now o Completely re-wrote changes to time switches: they are now
based on iCal rather than on crontab. based on iCal rather than on crontab.
o Timezone references are now defined within time switches o Timezone references are now defined within time switches
rather than in the ancillary section. The ancillary section is rather than in the ancillary section. The ancillary section is
now empty, but still defined for future use. To facilitate now empty, but still defined for future use. To facilitate
this, an explicit "ancillary" tag was added. this, an explicit "ancillary" tag was added.
o Added XML document type identifiers (the public identifier and o Added XML document type identifiers (the public identifier and
skipping to change at page 62, line 29 skipping to change at page 65, line 7
servers. servers.
o Updated reference to RFC 2824 now that it has been published. o Updated reference to RFC 2824 now that it has been published.
o Added explanatory text to the introduction to types of nodes. o Added explanatory text to the introduction to types of nodes.
o Numerous minor clarifications and wording changes. o Numerous minor clarifications and wording changes.
o Fixed copy-and-paste errors, typos. o Fixed copy-and-paste errors, typos.
D.5 Changes from Draft -00 D.6 Changes from Draft -00
o Added high-level structure; script doesn't just start at a o Added high-level structure; script doesn't just start at a
first action. first action.
o Added a section giving a high-level explanation of the o Added a section giving a high-level explanation of the
location model. location model.
o Added informal syntax specifications for each tag so people o Added informal syntax specifications for each tag so people
don't have to try to understand a DTD to figure out the don't have to try to understand a DTD to figure out the
syntax. syntax.
skipping to change at page 64, line 4 skipping to change at page 66, line 31
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
F Bibliography F 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," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[2] International Telecommunication Union, "Packet based multimedia [2] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. Standardization Sector of ITU, Geneva, Switzerland, Nov. 2000.
[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 (second edition)," W3C Recommendation REC-xml- language (XML) 1.0 (second edition)," W3C Recommendation REC-xml-
20001006, World Wide Web Consortium (W3C), Oct. 2000. Available at 20001006, World Wide Web Consortium (W3C), Oct. 2000. Available at
http://www.w3.org/XML/. http://www.w3.org/XML/.
[4] J. Lennox and H. Schulzrinne, "Call processing language framework [4] J. Lennox and H. Schulzrinne, "Call processing language framework
and requirements," Request for Comments 2824, Internet Engineering and requirements," Request for Comments 2824, Internet Engineering
Task Force, May 2000. Task Force, May 2000.
skipping to change at page 65, line 16 skipping to change at page 67, line 44
[13] F. Dawson and D. Stenerson, "Internet calendaring and scheduling [13] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
core object specification (icalendar)," Request for Comments 2445, core object specification (icalendar)," Request for Comments 2445,
Internet Engineering Task Force, Nov. 1998. Internet Engineering Task Force, Nov. 1998.
[14] P. Eggert, "Sources for time zone and daylight saving time [14] P. Eggert, "Sources for time zone and daylight saving time
data." Available at http://www.twinsun.com/tz/tz-link.htm. data." Available at http://www.twinsun.com/tz/tz-link.htm.
[15] ISO (International Organization for Standardization), "Data [15] ISO (International Organization for Standardization), "Data
elements and interchange formats -- information interchange -- elements and interchange formats -- information interchange --
representation of dates and times," ISO Standard ISO 8601:1988(E), representation of dates and times," ISO Standard ISO 8601:2000(E),
International Organization for Standardization, Geneva, Switzerland, International Organization for Standardization, Geneva, Switzerland,
June 1986. Dec. 2000.
[16] M. Mealling and R. Daniel, "URI resolution services necessary [16] M. Mealling and R. Daniel, "URI resolution services necessary
for URN resolution," Request for Comments 2483, Internet Engineering for URN resolution," Request for Comments 2483, Internet Engineering
Task Force, Jan. 1999. Task Force, Jan. 1999.
[17] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and [17] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task callee capabilities," Internet Draft, Internet Engineering Task
Force, Nov. 2000. Work in progress. Force, Nov. 2001. Work in progress.
[18] S. DeRose, E. Maler, D. Orchard, and B. Trafford, "XML linking [18] S. DeRose, E. Maler, D. Orchard, and B. Trafford, "XML linking
language (XLink) version 1.0," W3C Candidate Recommendation CR- language (XLink) version 1.0," W3C Candidate Recommendation CR-
xlink-20000703, World Wide Web Consortium (W3C), July 2000. xlink-20000703, World Wide Web Consortium (W3C), July 2000.
Available at http://www.w3.org/TR/xlink/. Available at http://www.w3.org/TR/xlink/.
[19] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C [19] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C
Recommendation REC-xml-names-19900114, World Wide Web Consortium Recommendation REC-xml-names-19900114, World Wide Web Consortium
(W3C), Jan. 1999. Available at http://www.w3.org/TR/REC-xml-names/. (W3C), Jan. 1999. Available at http://www.w3.org/TR/REC-xml-names/.
skipping to change at page 65, line 50 skipping to change at page 68, line 29
[21] D. C. Fallside, "XML schema part 0: Primer," W3C Candidate [21] D. C. Fallside, "XML schema part 0: Primer," W3C Candidate
Recommendation CR-xmlschema-0-20001024, World Wide Web Consortium Recommendation CR-xmlschema-0-20001024, World Wide Web Consortium
(W3C), Oct. 2000. Available at http://www.w3.org/TR/xmlschema-0/. (W3C), Oct. 2000. Available at http://www.w3.org/TR/xmlschema-0/.
[22] International Telecommunication Union, "Digital subscriber [22] International Telecommunication Union, "Digital subscriber
signalling system no. 1 (dss 1) - isdn user-network interface layer 3 signalling system no. 1 (dss 1) - isdn user-network interface layer 3
specification for basic call control," Recommendation Q.931, specification for basic call control," Recommendation Q.931,
Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
Mar. 1993. Mar. 1993.
[23] International Telecommunication Union, "Packet based multimedia [23] O. Levin, "H.323 URL scheme definition," Internet Draft,
communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Nov. 2000.
[24] O. Levin, "H.323 URL scheme definition," Internet Draft,
Internet Engineering Task Force, Nov. 2001. Work in progress. Internet Engineering Task Force, Nov. 2001. Work in progress.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2001). All Rights Reserved. Copyright (c) The Internet Society (2002). 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 66, line 36 skipping to change at line 3069
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
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
1 Introduction ........................................ 2
1.1 Conventions of This Document ........................ 2
2 Structure of CPL Scripts ............................ 2
2.1 High-level Structure ................................ 3
2.2 Abstract Structure of a Call Processing Action ...... 3
2.3 Location Model ...................................... 4
2.4 XML Structure ....................................... 4
3 Document Information ................................ 5
3.1 CPL Document Identifiers for XML .................... 5
3.2 MIME Registration ................................... 6
4 Script Structure: Overview .......................... 7
5 Switches ............................................ 8
5.1 Address Switches .................................... 8
5.1.1 Usage of "address-switch" with SIP .................. 11
5.2 String Switches ..................................... 12
5.2.1 Usage of "string-switch" with SIP ................... 13
5.3 Language Switches ................................... 13
5.3.1 Usage of "language-switch" with SIP ................. 14
5.4 Time Switches ....................................... 14
5.4.1 iCalendar differences and implementation issues ..... 20
5.5 Priority Switches ................................... 21
5.5.1 Usage of "priority-switch" with SIP ................. 22
6 Location Modifiers .................................. 22
6.1 Explicit Location ................................... 23
6.1.1 Usage of "location" with SIP ........................ 23
6.2 Location Lookup ..................................... 24
6.2.1 Usage of "lookup" with SIP .......................... 25
6.3 Location Removal .................................... 26
6.3.1 Usage of "remove-location" with SIP ................. 27
7 Signalling Operations ............................... 27
7.1 Proxy ............................................... 27
7.1.1 Usage of "proxy" with SIP ........................... 30
7.2 Redirect ............................................ 30
7.2.1 Usage of "redirect" with SIP ........................ 31
7.3 Reject .............................................. 31
7.3.1 Usage of "reject" with SIP .......................... 31
8 Non-signalling Operations ........................... 32
8.1 Mail ................................................ 32
8.1.1 Suggested Content of Mailed Information ............. 33
8.2 Log ................................................. 33
9 Subactions .......................................... 34
10 Ancillary Information ............................... 35
11 Default Behavior .................................... 36
12 CPL Extensions ...................................... 37
13 Examples ............................................ 38
13.1 Example: Call Redirect Unconditional ................ 38
13.2 Example: Call Forward Busy/No Answer ................ 38
13.3 Example: Call Forward: Redirect and Default ......... 39
13.4 Example: Call Screening ............................. 39
13.5 Example: Priority and Language Routing .............. 40
13.6 Example: Outgoing Call Screening .................... 41
13.7 Example: Time-of-day Routing ........................ 41
13.8 Example: Location Filtering ......................... 43
13.9 Example: Non-signalling Operations .................. 43
13.10 Example: Hypothetical Extensions .................... 43
13.11 Example: A Complex Example .......................... 45
14 Security Considerations ............................. 45
15 IANA Considerations ................................. 46
16 Acknowledgments ..................................... 47
A An Algorithm for Resolving Time Switches ............ 47
B Suggested Usage of CPL with H.323 ................... 48
B.1 Usage of "address-switch" with H.323 ................ 49
B.2 Usage of "string-switch" with H.323 ................. 50
B.3 Usage of "language-switch" with H.323 ............... 51
B.4 Usage of "priority-switch" with H.323 ............... 51
B.5 Usage of "location" with H.323 ...................... 51
B.6 Usage of "lookup" with H.323 ........................ 51
B.7 Usage of "remove-location" with H.323 ............... 51
C The XML DTD for CPL ................................. 52
D Changes from Earlier Versions ....................... 58
D.1 Changes from Draft -04 .............................. 58
D.2 Changes from Draft -03 .............................. 59
D.3 Changes from Draft -02 .............................. 60
D.4 Changes from Draft -01 .............................. 61
D.5 Changes from Draft -00 .............................. 62
E Authors' Addresses .................................. 63
F Bibliography ........................................ 63
 End of changes. 

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