SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
Call Processing Language (CPL) |
CPL description from the 2002-01 Draft: "The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs."
[April 05, 2000] CPL is under design and development by the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. "The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is not tied to any particular signalling architecture or protocol; it is anticipated that it will be used with both SIP [Session Initiation Protocol] and H.323 [ITU "Visual telephone systems and equipment for local area networks..."]. The CPL is powerful enough to describe a large number of services and features, but it is limited in power so that it can run safely in Internet telephony servers. The intention is to make it impossible for users to do anything more complex (and dangerous) than describing Internet telephony services. The language is not Turing-complete, and provides no way to write a loop or a function."
"The CPL is also designed to be easily created and edited by graphical tools. It is based on XML, so parsing it is easy and many parsers for it are publicly available. The structure of the language maps closely to its behavior, so an editor can understand any valid script, even ones written by hand. The language is also designed so that a server can easily confirm scripts' validity at the time they are delivered to it, rather that discovering them while a call is being processed. Implementations of the CPL are expected to take place both in Internet telephony servers and in advanced clients; both can usefully process and direct users' calls. In the former case, a mechanism will be needed to transport scripts between clients and servers; this document does not describe such a mechanism, but related documents will."
References
[October 09, 2002] "An Extensible Markup Language Schema for Call Processing Language (CPL)." By Xiaotao Wu, Henning Schulzrinne, and Jonathan Lennox (Department of Computer Science, Columbia University). Internet Engineering Task Force (IETF), Internet Draft. Reference: 'draft-wu-cpl-schema-00.txt'. October 7, 2002, expires March 2003. "The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is based on the Extensible Markup Language (XML), a common hierarchical format for describing structured data. This document provides an Extensible Markup Language (XML) Schema for the Call Processing Language (CPL). The original CPL specification only provides a Document Type Declaration (DTD) to describe the structure of the language. Compared with XML DTDs, XML schemas have many advantages such as performing stricter type checking, providing pre-defined data types and being able to derive new data types from existing ones... And we recommend that all future extensions of CPL should use schema definitions only..." [cache]
[February 21, 2002] "CPL: A Language for User Control of Internet Telephony Services." Internet Engineering Task Force, Internet Draft. IPTEL WG. Reference: 'draft-ietf-iptel-cpl-06.txt'. January 15, 2002; expires: July, 2002. By Jonathan Lennox and Henning Schulzrinne (Department of Computer Science Columbia University). "The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is not tied to any particular signalling architecture or protocol; it is anticipated that it will be used with both SIP and H.323. The CPL is powerful enough to describe a large number of services and features, but it is limited in power so that it can run safely in Internet telephony servers. The intention is to make it impossible for users to do anything more complex (and dangerous) than describing Internet telephony services. The language is not Turing-complete, and provides no way to write loops or recursion. The CPL is also designed to be easily created and edited by graphical tools. It is based on XML, so parsing it is easy and many parsers for it are publicly available. The structure of the language maps closely to its behavior, so an editor can understand any valid script, even ones written by hand. The language is also designed so that a server can easily confirm scripts' validity at the time they are delivered to it, rather that discovering them while a call is being processed. Implementations of the CPL are expected to take place both in Internet telephony servers and in advanced clients; both can usefully process and direct users' calls. This document primarily addresses the usage in servers. A mechanism will be needed to transport scripts between clients and servers; this document does not describe such a mechanism, but related documents will." Also in Postscript. [cache]
CPL XML DTD [2002-01-15 draft].
"CPL: A Language for User Control of Internet Telephony Services." Internet Engineering Task Force, IPTEL WG. Internet Draft 'ietf-iptel-cpl-00.txt'. February 26, 1999. By Jonathan Lennox (Department of Computer Science, Columbia University) and Henning Schulzrinne (Department of Computer Science, Columbia University). "The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs." Also available in Postscript and PDF format.
[March 10, 2000] "CPL: A Language for User Control of Internet Telephony Services." March 10, 2000. Internet Engineering Task Force, Interet Draft. 'draft-ietf-iptel-cpl-01.txt'.
CPL Draft February 26, 1999, local archive copy, alt URL
CPL DTD (from Appendix A, February 26, 1999)
"Call Processing Language Framework and Requirements." Network Working Group. Request for Comments: 2824. May 2000.
"Call Processing Language Framework and Requirements." Internet Engineering Task Force (IPTEL WG), Internet Draft 'draft-ietf-iptel-cpl-framework-02.txt'. By Jonathan Lennox and Henning Schulzrinne (Department of Computer Science, Columbia University). "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." [cache]
[September 04] "Programming Internet Telephony Services." By Jonathan Rosenberg (Bell Laboratories), Jonathan Lennox (Columbia University), and Henning Schulzrinne (Columbia University). In IEEE Internet Computing [IEEE Computer Society] Volume 3, Number 3 (May/June1999), pages 63-72. "[Programming new Internet telephony services requires decisions regarding such things as where the code executes and how it interfaces with network protocols. The authors propose a CGI solution for trusted user/developers and the Call Processing Language for untrusted user/developers.'] ". . . While SIP CGI is an ideal service creation tool for trusted users, it is too flexible for service creation by untrusted users. We have therefore developed a new scripting language, called the Call Processing Language (CPL), which allows untrusted users to define services. Users can upload CPL scripts to network servers. The logic can be read in and verified, and the service instantiated instantly. In this section we overview the requirements for a language that can be used in this fashion, describe its design, and discuss its primitive constructs. . . Based on the [stated] requirements, we chose to follow the IN service creation models and design a language that represents services in a decision graph. The individual nodes of the decision graph are the primitives of the language. They are specific decisions to be made or actions to be taken in the course of specifying the service. These decisions and actions are arranged in a directed acyclic graph (DAG), which defines the service. Control begins at a single root node, and each node can have several outputs, depending on the result of the choice or action taken at that node. Node outputs then lead down the tree to further actions or decisions. It is possible for some or all outputs of a node to be left unspecified. In the absence of a CPL script, the server should then take its normal or default action in the current call state. Similarly, many parameters to conditions or actions can be left unspecified, also taking default values. . . We decided to represent the decision graphs using a scripting language based on Extended Markup Language. XML is similar to HTML; it contains tags that describe the data in the document. We considered using traditional scripting languages, such as Perl, Tcl, or Python; portable programming languages, such as Java; and application-specific languages, such as sieve, which is used for e-mail filtering. However, XML had several important features. XML documents are perfect for representing structured data, particularly tree structures with optional links, which is the exact structure needed to represent the DAGs that define call services. In addition, since XML contains no specific keywords, we were able to define a precise set representing control primitives and information accesses. XML was also useful since the syntax and semantics of a script can be verified using XML validation against a document type definition (DTD). XML can be produced and read by both humans and machines, satisfying another design goal of CPL. XML is also a good choice because it is easily extended. Every tag and attribute has an explicitly specified name; thus, a parser can immediately determine whether it can support all requested features, and decide what to do if it cannot support them. Furthermore, XML has built-in mechanisms for adding new tags and attributes, which can come from namespaces specified in the head of the document. XML is by no means perfect. It tends to be verbose, requiring relatively long programs for simple services. In addition, since XML is not a programming language, but rather a syntax, inclusion of certain language features, such as variable assignment, are awkward. However, its limited flexibility is more an advantage than a disadvantage in this application. Mapping the CPL onto XML is straightforward. There is an enclosing XML tag named call that contains an entire CPL script, indicating the point where execution begins. Both nodes and their outputs are represented as XML tags; parameters are represented as XML tag attributes. Node tags typically contain output tags, and vice versa, representing descent down the decision tree. Convergence (where several outputs point to a single node) is represented with links. . ."
IETF IPTEL Working Group Homepage Hosted by Bell Labs, the research and development division of Lucent Technologies.'
IPTEL WG Charter
"The IETF Internet Telephony Architecture and Protocols." By H. Schulzrinne, J. Rosenberg. See the full issue.
Contact: Jonathan Rosenberg, IPTEL Working Group Chair
See related topics:
|
| Receive daily news updates from Managing Editor, Robin Cover.
|
|