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.

   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.