As per Relevance of the word signalling, we have this rfc below:
Network Working Group J.
Request for Comments: 2824 H.
Category: Informational Columbia
May 2000
Call Processing Language Framework and
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
A large number of the services we wish to make possible for
telephony require fairly elaborate combinations of
operations, often in network devices, to complete. We want a
and standardized way to create such services to make them easier
implement and deploy. This document describes an
framework for such a mechanism, which we call a call
language. It also outlines requirements for such a language
Table of
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Example services .................................... 4
4 Usage scenarios ..................................... 6
5 CPL creation ........................................ 6
6 Network model ....................................... 7
6.1 Model components .................................... 7
6.1.1 End systems ......................................... 7
6.1.2 Signalling servers .................................. 8
6.2 Component interactions .............................. 8
7 Interaction of CPL with network model ............... 10
7.1 What a script does .................................. 10
7.2 Which script is executed ............................ 11
7.3 Where a script runs ................................. 12
8 Creation and transport of a call
language script ..................................... 12
9 Feature interaction behavior ........................ 13
9.1 Feature-to-feature interactions ..................... 13
Lennox & Schulzrinne Informational [Page 1]
RFC 2824 CPL-F May 2000
9.2 Script-to-script interactions ....................... 14
9.3 Server-to-server interactions ....................... 15
9.4 Signalling ambiguity ................................ 15
10 Relationship with existing languages ................ 15
11 Related work ........................................ 17
11.1 IN service creation environments .................... 17
11.2 SIP CGI ............................................. 17
12 Necessary language features ......................... 17
12.1 Language characteristics ............................ 17
12.2 Base features -- call signalling .................... 19
12.3 Base features -- non-signalling ..................... 21
12.4 Language features ................................... 22
12.5 Control ............................................. 23
13 Security Considerations ............................. 23
14 Acknowledgments ..................................... 23
15 Authors' Addresses .................................. 23
16 Bibliography ........................................ 24
17 Full Copyright Statement ............................ 25
1
Recently, several protocols have been created to allow
calls to be made over IP networks, notably SIP [1] and H.323 [2].
These emerging standards have opened up the possibility of a
and dramatic decentralization of the provisioning of
services so they can be under the user's control
Many Internet telephony services can, and should, be
entirely on end devices. Multi-party calls, for instance, or
waiting alert tones, or camp-on services, depend heavily on end
system state and on the specific content of media streams
information which often is only available to the end system.
variety of services, however -- those involving user location,
distribution, behavior when end systems are busy, and the like --
independent of a particular end device, or need to be
even when an end device is unavailable. These services are still
located in a network device, rather than in an end system
Traditionally, network-based services have been created only
service providers. Service creation typically involved
proprietary or restricted tools, and there was little range
customization or enhancement by end users. In the
environment, however, this changes. Global connectivity and
protocols allow end users or third parties to design and
new or customized services, and to deploy and modify their
dynamically without requiring a service provider to act as
intermediary
Lennox & Schulzrinne Informational [Page 2]
RFC 2824 CPL-F May 2000
A number of Internet applications have such
environments -- the web has CGI [3], for instance, and e-mail
Sieve [4] or procmail. To create such an open
environment for Internet telephony, we need a standardized, safe
for these new service creators to describe the desired behavior
network servers
This document describes an architecture in which network
respond to call signalling events by triggering user-created
written in a simple, static, non-expressively-complete language.
call this language a call processing language
The development of this document has been substantially informed
the development of a particular call processing language,
described in [5]. In general, when this document refers to "a
processing language," it is referring to a generic language
fills this role; "the call processing language" or "the CPL"
to this particular language
2
In this section we define some of the terminology used in
document
SIP [1] terminology used includes
invitation: The initial INVITE request of a SIP transaction,
which one party initiates a call with another
redirect server: A SIP device which responds to invitations
other requests by informing the request originator of
alternate address to which the request should be sent
proxy server: A SIP device which receives invitations and
requests, and forwards them to other SIP devices. It
receives the responses to the requests it forwarded,
forwards them back to the sender of the initial request
user agent: A SIP device which creates and receives requests,
as to set up or otherwise affect the state of a call.
may be, for example, a telephone or a voicemail system
user agent client: The portion of a user agent which
requests
user agent server: The portion of a user agent which responds
requests
Lennox & Schulzrinne Informational [Page 3]
RFC 2824 CPL-F May 2000
H.323 [2] terminology used includes
terminal: An H.323 device which originates and receives calls,
their associated media
gatekeeper: An H.323 entity on the network that provides
translation and controls access to the network for H.323
terminals and other endpoints. The gatekeeper may
provide other services to the endpoints such as
management and locating gateways
gateway: A device which translates calls between an H.323
and another network, typically the public-switched
network
RAS: The Registration, Admission and Status messages
between two H.323 entities, for example between an
and a gatekeeper
General terminology used in this document includes
user location: The process by which an Internet telephony
determines where a user named by a particular address can
found
CPL: A Call Processing Language, a simple language to describe
Internet telephony call invitations should be processed
script: A particular instance of a CPL, describing a
set of services desired
end system: A device from which and to which calls
established. It creates and receives the call's
(audio, video, or the like). This may be a SIP user agent
an H.323 terminal
signalling server: A device which handles the routing of
invitations. It does not process or interact with the
of a call. It may be a SIP proxy or redirect server, or
H.323 gatekeeper
3 Example
To motivate the subsequent discussion, this section gives
specific examples of services which we want users to be able
create programmatically. Note that some of these examples
deliberately somewhat complicated, so as to demonstrate the level
decision logic that should be possible
Lennox & Schulzrinne Informational [Page 4]
RFC 2824 CPL-F May 2000
o Call forward on busy/no
When a new call comes in, the call should ring at the user'
desk telephone. If it is busy, the call should always
redirected to the user's voicemail box. If, instead, there's
answer after four rings, it should also be redirected to his
her voicemail, unless it's from a supervisor, in which case
should be proxied to the user's cell phone if it is
registered
o Information
A company advertises a general "information" address
prospective customers. When a call comes in to this address,
it's currently working hours, the caller should be given a
of the people currently willing to accept general
calls. If it's outside of working hours, the caller should
a webpage indicating what times they can call
o Intelligent user
When a call comes in, the list of locations where the user
registered should be consulted. Depending on the type of
(work, personal, etc.), the call should ring at an
subset of the registered locations, depending on information
the registrations. If the user picks up from more than
station, the pick-ups should be reported back separately to
calling party
o Intelligent user location with media
When a call comes in, the call should be proxied to the
the user has registered from whose media capabilities
match those specified in the call request. If the user does
pick up from that station within four rings, the call should
proxied to the other stations from which he or she
registered, sequentially, in order of decreasing closeness
match
o Client billing allocation -- lawyer's
When a call comes in, the calling address is correlated
the corresponding client, and client's name, address, and
time of the call is logged. If no corresponding client
found, the call is forwarded to the lawyer's secretary
Lennox & Schulzrinne Informational [Page 5]
RFC 2824 CPL-F May 2000
4 Usage
A CPL would be useful for implementing services in a number
different scenarios
o Script creation by end
In the most direct approach for creating a service with a CPL
an end user simply creates a script describing their service
He or she simply decides what service he or she wants
describes it using a CPL script, and then uploads it to
server
o Third party
Because a CPL is a standardized language, it can also be
to allow third parties to create or customize services
clients. These scripts can then be run on servers owned by
end user or the user's service provider
o Administrator service
A CPL can also be used by server administrators to
simple services or describe policy for servers they control
If a server is implementing CPL services in any case,
the service architecture to allow administrators as well
users to create scripts is a simple extension
o Web
Finally, there have been a number of proposals for
creation or customization using web interfaces. A CPL could
used as the back-end to such environments: a web
could create a CPL script on behalf of a user, and
telephony server could then implement the services
either component having to be aware of the specifics of
other
5 CPL
There are also a number of means by which CPL scripts could
created. Like HTML, which can be created in a number of
manners, we envision multiple creation styles for a CPL script
Lennox & Schulzrinne Informational [Page 6]
RFC 2824 CPL-F May 2000
o Hand
Most directly, CPL scripts can be created by hand,
knowledgeable users. The CPL described in [5] has a
format with an uncomplicated syntax, so hand authoring will
straightforward
o Automated
CPL features can be created by automated means, such as in
example of the web middleware described in the
section. With a simple, text-based syntax, standard text
processing languages will be able to create and edit
scripts easily
o GUI
Finally, users will be able to use GUI tools to create and
CPL scripts. We expect that most average-experience users
take this approach once the CPL gains popularity. The CPL
be designed with this application in mind, so that the
expressive power of scripts can be represented simply
straightforwardly in a graphical manner
6 Network
The Call Processing Language operates on a generalized model of
Internet telephony network. While the details of various
differ, on an abstract level all major Internet
architectures are sufficiently similar that their major features
be described commonly. This document generally uses SIP terminology
as its authors' experience has mainly been with that protocol
6.1 Model
In the Call Processing Language's network model, an
telephony network contains two types of components
6.1.1 End
End systems are devices which originate and/or receive
information and media. These include simple and complex
devices, PC telephony clients, and automated voice systems. The
abstracts away the details of the capabilities of these devices.
end system can originate a call; and it can accept, reject,
forward incoming calls. The details of this process (ringing, multi
line telephones, and so forth) are not important for the CPL
Lennox & Schulzrinne Informational [Page 7]
RFC 2824 CPL-F May 2000
For the purposes of the CPL, gateways -- for example, a device
connects calls between an IP telephony network and the PSTN --
also considered to be end systems. Other devices, such as mixers
firewalls, are not directly dealt with by the CPL, and they will
be discussed here
6.1.2 Signalling
Signalling servers are devices which relay or control
information. In SIP, they are proxy servers, redirect servers,
registrars; in H.323, they are gatekeepers
Signalling servers can perform three types of actions on call
information. They can
proxy it: forward it on to one or more other network or
systems, returning one of the responses received
redirect it: return a response informing the sending system of
different address to which it should send the request
reject it: inform the sending system that the setup request
not be completed
RFC 2543 [1] has illustrations of proxy and redirect functionality
End systems may also be able to perform some of these actions:
certainly rejection, and possibly redirection
Signalling servers also normally maintain information about
location. Whether by means of registrations (SIP REGISTER or H.323
RAS messages), static configuration, or dynamic searches,
servers must have some means by which they can determine where a
is currently located, in order to make intelligent choices
their proxying or redirection behavior
Signalling servers are also usually able to keep logs of
that pass through them, and to send e-mail to destinations on
Internet, under programmatic control
6.2 Component
When an end system places a call, the call establishment request
proceed by a variety of routes through components of the network.
begin with, the originating end system must decide where to send
requests. There are two possibilities here: the originator may
configured so that all its requests go to a single local server;
it may resolve the destination address to locate a remote
server or end system to which it can send the request directly
Lennox & Schulzrinne Informational [Page 8]
RFC 2824 CPL-F May 2000
Once the request arrives at a signalling server, that server uses
user location database, its local policy, DNS resolution, or
methods, to determine the next signalling server or end system
which the request should be sent. A request may pass through
number of signalling servers: from zero (in the case when end
communicate directly) to, in principle, every server on the network
What's more, any end system or signalling server can (in principle
receive requests from or send them to any other
For example, in figure 1, there are two paths the call
request information may take. For Route 1, the originator knows
a user address for the user it is trying to contact, and it
configured to send outgoing calls through a local outgoing
server. Therefore, it forwards the request to its local server
which finds the server of record for that address, and forwards it
to that server
In this case, the organization the destination user belongs to uses
multi-stage setup to find users. The corporate server
which department a user is part of, then forwards the request to
appropriate departmental server, which actually locates the user
(This is similar to the way e-mail forwarding is often configured.)
The response to the request will travel back along the same path
For Route 2, however, the originator knows the specific
address it is trying to contact, and it is not configured to use
local outgoing proxy. In this case, the originator can
contact the destination without having to communicate with
network servers at all
We see, then, that in Internet telephony signalling servers cannot
general know the state of end systems they "control,"
signalling information may have bypassed them. This
limitation implies a number of restrictions on how some services
be implemented. For instance, a network system cannot reliably
if an end system is currently busy or not; a call may have
placed to the end system without traversing that network system
Thus, signalling messages must explicitly travel to end systems
find out their state; in the example, the end system must
return a "busy" indication
Lennox & Schulzrinne Informational [Page 9]
RFC 2824 CPL-F May 2000
Outgoing Corporate
Proxy Server
_______ Outgoing proxy contacts _______ _______
| | corporate server | | | |
| | -------------------------> | | ---------> | |
|_____| |_____| |_____|
Route 1 ^ \
/ \
Sends to/ \
proxy / _|
_______ _______
| | Route 2 | |
| | ---------------------------------------------------> | |
|_____| Originator directly contacts destination |_____|
Originator
Figure 1: Possible paths of call setup
7 Interaction of CPL with network
7.1 What a script
A CPL script runs in a signalling server, and controls that system'
proxy, redirect, or rejection actions for the set-up of a
call. It does not attempt to coordinate the behavior of
signalling servers, or to describe features on a "Global
Plane" as in the Intelligent Network architecture [6].
More specifically, a script replaces the user location
of a signalling server. As described in section 6.1.2, a
server typically maintains a database of locations where a user
be reached; it makes its proxy, redirect, and rejection
based on the contents of that database. A CPL script replaces
basic database lookup functionality; it takes the
information, the specifics of a call request, and other
information it wants to reference, and chooses the signalling
to perform
Abstractly, a script can be considered as a list of condition/
pairs; if some attribute of the registration, request, and
information matches a given condition, then the corresponding
(or more properly set of actions) is taken. In some circumstances
additional actions can be taken based on the consequences of
first action and additional conditions. If no condition matches
invitation, the signalling server's standard action -- its
database lookup, for example -- is taken
Lennox & Schulzrinne Informational [Page 10]
RFC 2824 CPL-F May 2000
7.2 Which script is
CPL scripts are usually associated with a particular
telephony address. When a call establishment request arrives at
signalling server which is a CPL server, that server associates
source and destination addresses specified in the request with
database of CPL scripts; if one matches, the corresponding script
executed
Once the script has executed, if it has chosen to perform a
action, a new Internet telephony address will result as
destination of that proxying. Once this has occurred, the
again checks its database of scripts to see if any of them
associated with the new address; if one is, that script as well
executed (assuming that a script has not attempted to proxy to
address which the server has already tried). For more details of
recursion process, and a description of what happens when a
has scripts that correspond both to a scripts origination address
its destination address, see section 9.2.
In general, in an Internet telephony network, an address will
one of two things: either a user, or a device. A user address
to a particular individual, for example sip:joe@example.com
regardless of where that user actually is or what kind of device
or she is using. A device address, by contrast, refers to
particular physical device, such as sip:x26063@phones.example.com
Other, intermediate sorts of addresses are also possible, and
some use (such as an address for "my cell phone, wherever
currently happens to be registered"), but we expect them to be
common. A CPL script is agnostic to the type of address it
associated with; while scripts associated with user addresses
probably the most useful for most services, there is no reason that
script could not be associated with any other type of address
well. The recursion process described above allows scripts to
associated with several of a user's addresses; thus, a user
could specify an action "try me at my cell phone," whereas a
script could say "I don't want to accept cell phone calls while I'
out of my home area."
It is also possible for a CPL script to be associated not with
specific Internet telephony address, but rather with all
handled by a signalling server, or a large set of them. For instance
an administrator might configure a system to prevent calls from or
a list of banned incoming or outgoing addresses; these
presumably be configured for everyone, but users should still to
able to have their own custom scripts as well. Exactly when
Lennox & Schulzrinne Informational [Page 11]
RFC 2824 CPL-F May 2000
scripts should be executed in the recursion process depends on
precise nature of the administrative script. See section 9.2
further discussion of this
7.3 Where a script
Users can have CPL scripts on any network server which their
establishment requests pass through and with which they have a
relationship. For instance, in the example in figure 1,
originating user could have a script on the outgoing proxy, and
destination user could have scripts on both the corporate server
the departmental server. These scripts would typically
different functions, related to the role of the server on which
reside; a script on the corporate-wide server could be used
customize which department the user wishes to be found at,
instance, whereas a script at the departmental server could be
for more fine-grained location customization. Some services, such
filtering out unwanted calls, could be located at either server.
section 9.3 for some implications of a scenario like this
This model does not specify the means by which users locate a CPL
capable network server. In general, this will be through the
means by which they locate a local Internet telephony server
register themselves with; this may be through manual configuration
or through automated means such as the Service Location Protocol [7].
It has been proposed that automated means of locating such
should include a field to indicate whether the server allows users
upload CPLs
8 Creation and transport of a call processing language
Users create call processing language scripts, typically on
devices, and transmit them through the network to signalling servers
Scripts persist in signalling servers until changed or deleted
unless they are specifically given an expiration time; a
system which supports CPL scripting will need stable storage
The end device on which the user creates the CPL script need not
any relationship to the end devices to which calls are
placed. For example, a CPL script might be created on a PC,
calls might be intended to be received on a simple audio-
telephone. Indeed, the device on which the script is created may
be an "end device" in the sense described in section 6.1.1 at all
for instance, a user could create and upload a CPL script from
non-multimedia-capable web terminal
Lennox & Schulzrinne Informational [Page 12]
RFC 2824 CPL-F May 2000
The CPL also might not necessarily be created on a device near
the end device or the signalling server in network terms.
example, a user might decide to forward his or her calls to a
location only after arriving at that location
The exact means by which the end device transmits the script to
server remains to be determined; it is likely that many
will be able to co-exist. This method will need to be
in almost all cases. The methods that have been suggested
web file upload, SIP REGISTER message payloads, remote
invocation, SNMP, ACAP, LDAP, and remote file systems such as NFS
Users can also retrieve their current script from the network to
end system so it can be edited. The signalling server should also
able to report errors related to the script to the user, both
errors that could be detected at upload time, and any run-time
that occur
If a user has trust relationships with multiple signalling
(as discussed in section 7.3), the user may choose to upload
to any or all of those servers. These scripts can be
independent
9 Feature interaction
Feature interaction is the term used in telephony systems when two
more requested features produce ambiguous or conflicting
[8]. Feature interaction issues for features implemented with a
processing language can be roughly divided into three categories
feature-to-feature in one server, script-to-script in one server,
server-to-server
9.1 Feature-to-feature
Due to the explicit nature of event conditions discussed in
previous section, feature-to-feature interaction is not likely to
a problem in a call processing language environment. Whereas
subscriber to traditional telephone features might
subscribe to both "call waiting" and "call forward on busy," a
creating a CPL script would only be able to trigger one action
response to the condition "a call arrives while the line is busy."
Given a good user interface for creation, or a CPL server which
check for unreachable code in an uploaded script,
condition/action pairs can be avoided
Lennox & Schulzrinne Informational [Page 13]
RFC 2824 CPL-F May 2000
9.2 Script-to-script
Script-to-script interactions arise when a server invokes
scripts for a single call, as described in section 7.2. This
occur in a number of cases: if both the call originator and
destination have scripts specified on a single server; if a
forwards a request to another address which also has a script; or
an administrative script is specified as well as a user's
script
The solution to this interaction is to determine an ordering
the scripts to be executed. In this ordering, the "first" script
executed first; if this script allows or permits the call to
proxied, the script corresponding to the next address is executed
When the first script says to forward the request to some
address, those actions are considered as new requests which arrive
the second script. When the second script sends back a
response, that response arrives at the first script in the
manner as if a request arrived over the network. Note that in
cases, forwarding can be recursive; a CPL server must be careful
prevent forwarding loops
Abstractly, this can be viewed as equivalent to having each
execute on a separate signalling server. Since the CPL
is designed to allow scripts to be executed on multiple
servers in the course of locating a user, we can
transform script-to-script interactions into the server-to-
interactions described in the next section, reducing the number
types of interactions we need to concern ourselves with
The question, then, is to determine the correct ordering of
scripts. For the case of a script forwarding to an address
also has a script, the ordering is obvious; the other two cases
somewhat more subtle. When both originator and destination
exist, the originator's script should be executed before
destination script; this allows the originator to perform
translation, call filtering, etc., before a destination address
determined and a corresponding script is chosen
Even more complicated is the case of the ordering of
scripts. Many administrative scripts, such as ones that
source and destination addresses, need to be run after
scripts, but before destination scripts, to avoid a user's
evading administrative restrictions through clever forwarding
however, others, such as a global address book translation function
would need to be run earlier or later. Servers which
Lennox & Schulzrinne Informational [Page 14]
RFC 2824 CPL-F May 2000
administrative scripts to be run will need to allow the
to configure when in the script execution process a
administrative script should fall
9.3 Server-to-server
The third case of feature interactions, server-to-
interactions, is the most complex of these three. The
example of this type of interaction is the combination of
Call Screening and Call Forwarding: a user (or administrator)
wish to prevent calls from being placed to a particular address,
the local script has no way of knowing if a call placed to
other, legitimate address will be proxied, by a remote server, to
banned address. This type of problem is unsolvable in
administratively heterogeneous network, even a "lightly
heterogeneous network such as current telephone systems. CPL does
claim to solve it, but the problem is not any worse for CPL
than for any other means of deploying services
Another class of server-to-server interactions are best resolved
the underlying signalling protocol, since they can arise whether
signalling servers are being controlled by a call processing
or by some entirely different means. One example of this
forwarding loops, where user X may have calls forwarded to Y, who
calls forwarded back to X. SIP has a mechanism to detect such loops
A call processing language server thus does not need to define
special mechanisms to prevent such occurrences; it should, however
be possible to trigger a different set of call processing actions
the event that a loop is detected, and/or to report back an error
the owner of the script through some standardized run-time
reporting mechanism
9.4 Signalling
As an aside, [8] discusses a fourth type of feature interaction
traditional telephone networks, signalling ambiguity. This can
when several features overload the same operation in the
signal path from an end station to the network: for example,
the switch-hook can mean both "add a party to a three-way call"
"switch to call waiting." Because of the explicit nature
signalling in both the Internet telephony protocols discussed here
this issue does not arise
10 Relationship with existing
This document's description of the CPL as a "language" is
intended to imply that a new language necessarily needs to
implemented from scratch. A server could potentially implement
Lennox & Schulzrinne Informational [Page 15]
RFC 2824 CPL-F May 2000
the functionality described here as a library or set of
for an existing language; Java, or the various freely-
scripting languages (Tcl, Perl, Python, Guile), are
possibilities
However, there are motivations for creating a new language. All
existing languages are, naturally, expressively complete; this
two inherent disadvantages. The first is that any
implemented in them can take an arbitrarily long time, use
arbitrarily large amount of memory, and may never terminate. For
processing, this sort of resource usage is probably not necessary
and as described in section 12.1, may in fact be undesirable.
model for this is the electronic mail filtering language Sieve [4],
which deliberately restricts itself from being Turing-complete
Similar levels of safety and protection (though not
generation and parsing) could also be achieved through the use of
"sandbox" such as is used by Java applets, where strict bounds
imposed on the amount of memory, cpu time, stack space, etc., that
program can use. The difficulty with this approach is primarily
its lack of transparency and portability: unless the levels of
bounds are imposed by the standard, a bad idea so long as
resources are increasing exponentially with Moore's Law, a user
never be sure whether a particular program can successfully
executed on a given server without running into the server's
limits, and a program which executes successfully on one server
fail unexpectedly on another. Non-expressively-complete languages,
the other hand, allow an implicit contract between the script
and the server: so long as the script stays within the rules of
language, the server will guarantee that it will execute the script
The second disadvantage with expressively complete languages is
they make automatic generation and parsing of scripts very difficult
as every parsing tool must be a full interpreter for the language.
analogy can be drawn from the document-creation world: while
markup languages like HTML or XML can be, and are, easily
by smart editors, powerful document programming languages such
LaTeX or Postscript usually cannot be. While there are
processors that can save their documents in LaTeX form, they
accept as input arbitrary LaTeX documents, let alone preserve
structure of the original document in an edited form. By contrast
essentially any HTML editor can edit any HTML document from the web
and the high-quality ones preserve the structure of the
documents in the course of editing them
Lennox & Schulzrinne Informational [Page 16]
RFC 2824 CPL-F May 2000
11 Related
11.1 IN service creation
The ITU's IN series describe, on an abstract level, service
environments [6]. These describe services in a traditional circuit
switched telephone network as a series of decisions and
arranged in a directed acyclic graph. Many vendors of IN services
modified and extended versions of this for their proprietary
creation environments
11.2 SIP
SIP CGI [9] is an interface for implementing services on SIP servers
Unlike a CPL, it is a very low-level interface, and would not
appropriate for services written by non-trusted users
The paper "Programming Internet Telephony Services" [10]
the similarities and contrasts between SIP CGI and CPL in
detail
12 Necessary language
This section lists those properties of a call processing
which we believe to be necessary to have in order to implement
motivating examples, in line with the described architecture
12.1 Language
These are some abstract attributes which any proposed call
language should possess
o Light-weight, efficient, easy to
In addition to the general reasons why this is desirable,
network server might conceivably handle very large
volumes, and we don't want CPL execution to be a
bottleneck. One way to achieve this might be to compile
before execution
o Easily verifiable for
For a script which runs in a server, mis-configurations
result in a user becoming unreachable, making it difficult
indicate run-time errors to a user (though a second-
error reporting mechanism such as e-mail could
this). Thus, it should be possible to verify, when the
Lennox & Schulzrinne Informational [Page 17]
RFC 2824 CPL-F May 2000
is committed to the server, that it is at least
correct, does not have any obvious loops or other
modes, and does not use too many server resources
o Executable in a safe
No action the CPL script takes should be able to
anything about the server which the user shouldn't have
to, or affect the state of other users without permission
Additionally, since CPL scripts will typically run on a
on which users cannot normally run code, either the language
its execution environment must be designed so that
cannot use unlimited amounts of network resources, server
time, storage, or memory
o Easily writeable and parsable by both humans and machines
For maximum flexibility, we want to allow humans to write
own scripts, or to use and customize script libraries
by others. However, most users will want to have a
intuitive user-interface for the same functionality, and
will have a program which creates scripts for them. Both
should be easy; in particular, it should be easy for
editors to read human-generated scripts, and vice-versa
o
It should be possible to add additional features to a
in a way that existing scripts continue to work, and
servers can easily recognize features they don't understand
safely inform the user of this fact
o Independent of underlying signalling
The same scripts should be usable whether the
protocol is SIP, H.323, a traditional telephone network, or
other means of setting up calls. It should also be agnostic
address formats. (We use SIP terminology in our descriptions
requirements, but this should map fairly easily to
systems.) It may also be useful to have the language extend
processing of other sorts of communication, such as e-mail
fax
Lennox & Schulzrinne Informational [Page 18]
RFC 2824 CPL-F May 2000
12.2 Base features -- call
To be useful, a call processing language obviously should be able
react to and initiate call signalling events
o Should execute actions when a call request
See section 7, particularly 7.1.
o Should be able to make decisions based on event
A number of properties of a call event are relevant for
script's decision process. These include, roughly in order
importance
- Destination
We want to be able to do destination-based routing
screening. Note that in SIP we want to be able to filter
either or both of the addresses in the To header and
Request-URI
- Originator
Similarly, we want to be able to do originator-
screening or routing
- Caller
In SIP, a caller can express preferences about the type
device to be reached -- see [11]. The script should be
to make decisions based on this information
- Information about caller or
SIP has textual fields such as Subject, Organization
Priority, etc., and a display name for addresses; users
also add non-standard additional headers. H.323 has a
Display field. The script should be able to make
based on these parameters
- Media
Call invitations specify the types of media that will flow
their bandwidth usage, their network destination addresses
etc. The script should be able to make decisions based
these media characteristics
Lennox & Schulzrinne Informational [Page 19]
RFC 2824 CPL-F May 2000
- Authentication/encryption
Call invitations can be authenticated. Many properties
the authentication are relevant: the method
authentication/encryption, who performed the authentication
which specific fields were encrypted, etc. The
should be able to make decisions based on these
parameters
o Should be able to take action based on a call
There are a number of actions we can take in response to
incoming call setup request. We can
- reject
We should be able to indicate that the call is
acceptable or not able to be completed. We should also
able to send more specific rejection codes (including,
SIP, the associated textual string, warning codes,
message payload).
- redirect
We should be able to tell the call initiator sender to try
different location
- proxy
We should be able to send the call invitation on to
location, or to several other locations ("forking"
invitation), and await the responses. It should also
possible to specify a timeout value after which we give
on receiving any definitive responses
o Should be able to take action based a response to a proxied
forked call
Once we have proxied an invitation, we need to be able to
decisions based on the responses we receive to that
(or the lack thereof). We should be able to
- consider its message
We should be able to consider the same fields of a
as we consider in the initial invitation
Lennox & Schulzrinne Informational [Page 20]
RFC 2824 CPL-F May 2000
- relay it on to the call
If the response is satisfactory, it should be returned
the sender
- for a fork, choose one of several responses to relay
If we forked an invitation, we obviously expect to
several responses. There are several issues here --
among the responses, and how long to wait if we've
responses from some but not all destinations
- initiate other
If we didn't get a response, or any we liked, we should
able to try something else instead (e.g., call forward
busy).
12.3 Base features -- non-
A number of other features that a call processing language
have do not refer to call signalling per se; however, they are
extremely desirable to implement many useful features
The servers which provide these features might reside in
Internet devices, or might be local to the server (or
possibilities). The language should be independent of the location
these servers, at least at a high level
o
In addition to the CPL server's natural logging of events,
user will also want to be able to log arbitrary other items
The actual storage for this logging information might
either locally or remotely
o Error
If an unexpected error occurs, the script should be able
report the error to the script's owner. This may use the
mechanism as the script server uses to report language
to the user (see section 12.5).
o Access to user-location
Proxies will often collect information on users'
location, either through SIP REGISTER messages, the H.323
family of RAS messages, or some other mechanism (see
Lennox & Schulzrinne Informational [Page 21]
RFC 2824 CPL-F May 2000
6.2). The CPL should be able to refer to this information so
call can be forwarded to the registered locations or
subset of them
o Database
Much information for CPL control might be stored in
databases, for example a wide-area address database,
authorization information, for a CPL under
control. The language could specify some specific
access protocols (such as SQL or LDAP), or could be
generic
o Other external
Other external information a script could access includes
pages, which could be sent back in a SIP message body; or
clean interface to remote procedure calls such as Corba, RMI
or DCOM, for instance to access an external billing database
However, for simplicity, these interfaces may not be in
initial version of the protocol
12.4 Language
Some features do not involve any operations external to the CPL'
execution environment, but are still necessary to allow some
services to be implemented. (This list is not exhaustive.)
o Pattern-
It should be possible to give special treatment to
and other text strings based not only on the full string
also on more general or complex sub-patterns of them
o Address
Once a set of addresses has been retrieved through one of
methods in section 12.3, the user needs to be able to choose
sub-set of them, based on their address components or
parameters
o
Some forms of call distribution are randomized as to where
actually end up
Lennox & Schulzrinne Informational [Page 22]
RFC 2824 CPL-F May 2000
o Date/time
Users may wish to condition some services (e.g.,
forwarding, call distribution) on the current time of day,
of the week, etc
12.5
As described in section 8, we must have a mechanism to send
retrieve CPL scripts, and associated data, to and from a
server. This method should support reporting upload-time errors
users; we also need some mechanism to report errors to users
script execution time. Authentication is vital, and encryption
very useful. The specification of this mechanism can be (and
ought to be) a separate specification from that of the
processing language itself
13 Security
The security considerations of transferring CPL scripts are
in sections 8 and 12.5. Some considerations about the execution
the language are discussed in section 12.1.
14
We would like to thank Tom La Porta and Jonathan Rosenberg for
comments and suggestions
15 Authors'
Jonathan
Dept. of Computer
Columbia
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
EMail: lennox@cs.columbia.
Henning
Dept. of Computer
Columbia
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
EMail: schulzrinne@cs.columbia.
Lennox & Schulzrinne Informational [Page 23]
RFC 2824 CPL-F May 2000
16
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] International Telecommunication Union, "Packet based
communication systems," Recommendation H.323,
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[3] K. Coar and D. Robinson, "The WWW common gateway
version 1.1", Work in Progress
[4] T. Showalter, "Sieve: A mail filtering language", Work
Progress
[5] J. Lennox and H. Schulzrinne, "CPL: a language for user
of internet telephony services", Work in Progress
[6] International Telecommunication Union, "General
on telephone switching and signaling -- intelligent network
Introduction to intelligent network capability set 1,"
Recommendation Q.1211, Telecommunication Standardization
of ITU, Geneva, Switzerland, Mar. 1993.
[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "
Location Protocol, Version 2", RFC 2608, June 1999.
[8] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K
Schure, and H. Velthuijsen, "A feature interaction benchmark
IN and beyond," Feature Interactions in
Systems, IOS Press, pp. 1-23, 1994.
[9] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common
interface for SIP", Work in Progress
[10] J. Rosenberg, J. Lennox, and H. Schulzrinne, "
internet telephony services," Technical Report CUCS-010-99,
Columbia University, New York, New York, Mar. 1999.
[11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences
callee capabilities", Work in Progress
Lennox & Schulzrinne Informational [Page 24]
RFC 2824 CPL-F May 2000
17 Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Lennox & Schulzrinne Informational [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
