rfc2824.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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