rfc2824.txt

RFC 的详细文档！

            based on these parameters.

         -  Media description

            Call invitations specify the types of media that will flow,
            their bandwidth usage, their network destination addresses,
            etc. The script should be able to make decisions based on
            these media characteristics.




Lennox & Schulzrinne         Informational                     [Page 19]

RFC 2824                         CPL-F                          May 2000


         -  Authentication/encryption status

            Call invitations can be authenticated. Many properties of
            the authentication are relevant: the method of
            authentication/encryption, who performed the authentication,
            which specific fields were encrypted, etc.  The script
            should be able to make decisions based on these security
            parameters.

      o  Should be able to take action based on a call invitation

         There are a number of actions we can take in response to an
         incoming call setup request. We can:

         -  reject it

            We should be able to indicate that the call is not
            acceptable or not able to be completed. We should also be
            able to send more specific rejection codes (including, for
            SIP, the associated textual string, warning codes, or
            message payload).

         -  redirect it

            We should be able to tell the call initiator sender to try a
            different location.

         -  proxy it

            We should be able to send the call invitation on to another
            location, or to several other locations ("forking" the
            invitation), and await the responses. It should also be
            possible to specify a timeout value after which we give up
            on receiving any definitive responses.

      o  Should be able to take action based a response to a proxied or
         forked call invitation

         Once we have proxied an invitation, we need to be able to make
         decisions based on the responses we receive to that invitation
         (or the lack thereof).  We should be able to:

         -  consider its message fields

            We should be able to consider the same fields of a response
            as we consider in the initial invitation.





Lennox & Schulzrinne         Informational                     [Page 20]

RFC 2824                         CPL-F                          May 2000


         -  relay it on to the call originator

            If the response is satisfactory, it should be returned to
            the sender.

         -  for a fork, choose one of several responses to relay back

            If we forked an invitation, we obviously expect to receive
            several responses. There are several issues here -- choosing
            among the responses, and how long to wait if we've received
            responses from some but not all destinations.

         -  initiate other actions

            If we didn't get a response, or any we liked, we should be
            able to try something else instead (e.g., call forward on
            busy).

12.3 Base features -- non-signalling

   A number of other features that a call processing language should
   have do not refer to call signalling per se; however, they are still
   extremely desirable to implement many useful features.

   The servers which provide these features might reside in other
   Internet devices, or might be local to the server (or other
   possibilities). The language should be independent of the location of
   these servers, at least at a high level.

      o  Logging

         In addition to the CPL server's natural logging of events, the
         user will also want to be able to log arbitrary other items.
         The actual storage for this logging information might live
         either locally or remotely.

      o  Error reporting

         If an unexpected error occurs, the script should be able to
         report the error to the script's owner. This may use the same
         mechanism as the script server uses to report language errors
         to the user (see section 12.5).

      o  Access to user-location info

         Proxies will often collect information on users' current
         location, either through SIP REGISTER messages, the H.323 RRQ
         family of RAS messages, or some other mechanism (see section



Lennox & Schulzrinne         Informational                     [Page 21]

RFC 2824                         CPL-F                          May 2000


         6.2). The CPL should be able to refer to this information so a
         call can be forwarded to the registered locations or some
         subset of them.

      o  Database access

         Much information for CPL control might be stored in external
         databases, for example a wide-area address database, or
         authorization information, for a CPL under administrative
         control. The language could specify some specific database
         access protocols (such as SQL or LDAP), or could be more
         generic.

      o  Other external information

         Other external information a script could access includes web
         pages, which could be sent back in a SIP message body; or a
         clean interface to remote procedure calls such as Corba, RMI,
         or DCOM, for instance to access an external billing database.
         However, for simplicity, these interfaces may not be in the
         initial version of the protocol.

12.4 Language features

   Some features do not involve any operations external to the CPL's
   execution environment, but are still necessary to allow some standard
   services to be implemented. (This list is not exhaustive.)

      o  Pattern-matching

         It should be possible to give special treatment to addresses
         and other text strings based not only on the full string but
         also on more general or complex sub-patterns of them.

      o  Address filtering

         Once a set of addresses has been retrieved through one of the
         methods in section 12.3, the user needs to be able to choose a
         sub-set of them, based on their address components or other
         parameters.

      o  Randomization

         Some forms of call distribution are randomized as to where they
         actually end up.






Lennox & Schulzrinne         Informational                     [Page 22]

RFC 2824                         CPL-F                          May 2000


      o  Date/time information

         Users may wish to condition some services (e.g., call
         forwarding, call distribution) on the current time of day, day
         of the week, etc.

12.5 Control

   As described in section 8, we must have a mechanism to send and
   retrieve CPL scripts, and associated data, to and from a signalling
   server. This method should support reporting upload-time errors to
   users; we also need some mechanism to report errors to users at
   script execution time. Authentication is vital, and encryption is
   very useful. The specification of this mechanism can be (and probably
   ought to be) a separate specification from that of the call
   processing language itself.

13 Security Considerations

   The security considerations of transferring CPL scripts are discussed
   in sections 8 and 12.5. Some considerations about the execution of
   the language are discussed in section 12.1.

14 Acknowledgments

   We would like to thank Tom La Porta and Jonathan Rosenberg for their
   comments and suggestions.

15 Authors' Addresses

   Jonathan Lennox
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA

   EMail: [e-mail]


   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA

   EMail: [e-mail]



Lennox & Schulzrinne         Informational                     [Page 23]

RFC 2824                         CPL-F                          May 2000


16 Bibliography

   [1]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [2]  International Telecommunication Union, "Packet based multimedia
        communication systems," Recommendation H.323, Telecommunication
        Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

   [3]  K. Coar and D. Robinson, "The WWW common gateway interface
        version 1.1", Work in Progress.

   [4]  T. Showalter, "Sieve: A mail filtering language", Work in
        Progress.

   [5]  J. Lennox and H. Schulzrinne, "CPL: a language for user control
        of internet telephony services", Work in Progress.

   [6]  International Telecommunication Union, "General recommendations
        on telephone switching and signaling -- intelligent network:
        Introduction to intelligent network capability set 1,"
        Recommendation Q.1211, Telecommunication Standardization Sector
        of ITU, Geneva, Switzerland, Mar. 1993.

   [7]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.

   [8]  E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K.
        Schure, and H. Velthuijsen, "A feature interaction benchmark for
        IN and beyond," Feature Interactions in Telecommunications
        Systems, IOS Press, pp. 1-23, 1994.

   [9]  J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway
        interface for SIP", Work in Progress.

   [10] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming
        internet telephony services," Technical Report CUCS-010-99,
        Columbia University, New York, New York, Mar. 1999.

   [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
        callee capabilities", Work in Progress.










Lennox & Schulzrinne         Informational                     [Page 24]

RFC 2824                         CPL-F                          May 2000


17 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Lennox & Schulzrinne         Informational                     [Page 25]