rfc2824.txt

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

         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:[e-mail],
   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:[e-mail].
   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