doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

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