rfc2824.txt

RFC 的详细文档！

   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