Network Working Group J. Lennox
Request for Comments: 2824 H. Schulzrinne
Category: Informational Columbia University
May 2000
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.
版权所有（C）互联网协会（2000年）。版权所有。
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
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
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
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
1导言
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.
最近，已经创建了几个协议来允许通过IP网络进行电话呼叫，特别是SIP[1]和H.323[2]。这些新出现的标准为电话服务的提供提供提供了广泛而显著的分散化的可能性，因此它们可以由用户控制。
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.
许多互联网应用程序都有这样的定制环境——例如，web有CGI[3]，电子邮件有Sieve[4]或procmail。为了为互联网电话创建这样一个开放的定制环境，我们需要为这些新的服务创建者提供一种标准化、安全的方式来描述网络服务器的期望行为。
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.
如[5]所述，特定呼叫处理语言的开发实质上为本文档的开发提供了信息。通常，当本文档提到“呼叫处理语言”时，它指的是填补此角色的通用语言；“呼叫处理语言”或“CPL”指的是这种特殊语言。
2 Terminology
2术语
In this section we define some of the terminology used in this document.
在本节中，我们将定义本文档中使用的一些术语。
SIP [1] terminology used includes:
SIP[1]使用的术语包括：
invitation: The initial INVITE request of a SIP transaction, by which one party initiates a call with another.
邀请：SIP事务的初始邀请请求，一方通过该请求发起与另一方的呼叫。
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.
重定向服务器：一种SIP设备，通过通知请求发起人请求应发送到的备用地址来响应邀请和其他请求。
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.
代理服务器：接收邀请和其他请求并将其转发给其他SIP设备的SIP设备。然后，它接收对它转发的请求的响应，并将它们转发回初始请求的发送者。
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.
用户代理：一种SIP设备，用于创建和接收请求，以便设置或以其他方式影响呼叫状态。例如，这可以是电话或语音邮件系统。
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.
用户代理服务器：用户代理响应请求的部分。
H.323 [2] terminology used includes:
H.323[2]使用的术语包括：
terminal: An H.323 device which originates and receives calls, and their associated media.
终端：一种H.323设备，用于发起和接收呼叫及其相关媒体。
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.
网守：网络上的一个H.323实体，提供地址转换并控制H.323终端和其他端点对网络的访问。网守还可以向端点提供其他服务，例如带宽管理和定位网关。
gateway: A device which translates calls between an H.323 network and another network, typically the public-switched telephone network.
网关：在H.323网络和另一个网络（通常是公共交换电话网络）之间转换呼叫的设备。
RAS: The Registration, Admission and Status messages communicated between two H.323 entities, for example between an endpoint and a gatekeeper.
RAS：在两个H.323实体之间通信的注册、许可和状态消息，例如在端点和网守之间。
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.
用户位置：Internet电话设备确定在何处可以找到以特定地址命名的用户的过程。
CPL: A Call Processing Language, a simple language to describe how Internet telephony call invitations should be processed.
CPL：一种呼叫处理语言，一种描述如何处理Internet电话呼叫邀请的简单语言。
script: A particular instance of a CPL, describing a particular set of services desired.
脚本：CPL的一个特定实例，描述所需的一组特定服务。
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.
终端系统：建立呼叫的设备。它创建并接收呼叫的媒体（音频、视频等）。这可以是SIP用户代理或H.323终端。
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.
信令服务器：处理呼叫邀请路由的设备。它不会处理或与通话媒体交互。它可以是SIP代理或重定向服务器，也可以是H.323网守。
3 Example services
3示例服务
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.
为了激发后面的讨论，本节给出了一些我们希望用户能够以编程方式创建的服务的具体示例。请注意，这些示例中的一些故意有些复杂，以便演示可能的决策逻辑级别。
o Call forward on busy/no answer
o 忙/无应答时向前呼叫
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
o 信息地址
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
o 智能用户定位
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
o 基于媒体知识的智能用户定位
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
o 客户账单分配——律师事务所
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.
当来电进来时，呼叫地址与相应的客户端关联，并记录客户端的名称、地址和呼叫时间。如果找不到相应的客户，电话将转发给律师的秘书。
4 Usage scenarios
4个使用场景
A CPL would be useful for implementing services in a number of different scenarios.
CPL将有助于在许多不同的场景中实现服务。
o Script creation by end user
o 由最终用户创建脚本
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.
在使用CPL创建服务的最直接方法中，最终用户只需创建一个描述其服务的脚本。他或她只需决定他或她想要什么服务，使用CPL脚本描述它，然后将其上传到服务器。
o Third party outsourcing
o 第三方外包
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.
因为CPL是一种标准化语言，所以它还可以用于允许第三方为客户端创建或定制服务。然后，这些脚本可以在最终用户或用户的服务提供商拥有的服务器上运行。
o Administrator service definition
o 管理员服务定义
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.
服务器管理员还可以使用CPL为其控制的服务器创建简单服务或描述策略。如果服务器在任何情况下都在实现CPL服务，那么扩展服务体系结构以允许管理员和用户创建脚本是一个简单的扩展。
o Web middleware
o Web中间件
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.
最后，有许多关于使用web界面创建或定制服务的建议。CPL可以用作此类环境的后端：web应用程序可以代表用户创建CPL脚本，然后电话服务器可以实现这些服务，而不需要任何一个组件知道另一个组件的细节。
5 CPL creation
5 CPL创建
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.
还有许多方法可以用来创建CPL脚本。与HTML一样，HTML可以以多种不同的方式创建，我们设想了CPL脚本的多种创建样式。
o Hand authoring
o 手工创作
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.
最直接的是，CPL脚本可以由知识渊博的用户手工创建。[5]中描述的CPL具有简单语法的文本格式，因此手工编写将非常简单。
o Automated scripts
o 自动脚本
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.
CPL特性可以通过自动化的方式创建，如前一节所述的web中间件示例。通过使用简单的基于文本的语法，标准文本处理语言将能够轻松创建和编辑CPL脚本。
o GUI tools
o 图形用户界面工具
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.
最后，用户将能够使用GUI工具创建和编辑CPL脚本。我们预计，一旦CPL获得普及，大多数普通体验用户将采用这种方法。CPL的设计将考虑到这个应用程序，因此脚本的全部表达能力可以用图形化的方式简单而直接地表示出来。
6 Network model
6网络模型
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.
呼叫处理语言在互联网电话网络的通用模型上运行。虽然各种协议的细节各不相同，但在抽象层面上，所有主要的互联网电话体系结构都非常相似，因此它们的主要特性可以被普遍描述。本文档通常使用SIP术语，因为其作者的经验主要是使用该协议。
In the Call Processing Language's network model, an Internet telephony network contains two types of components.
在呼叫处理语言的网络模型中，Internet电话网络包含两种类型的组件。
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.
终端系统是发起和/或接收信令信息和媒体的设备。其中包括简单和复杂的电话设备、PC电话客户端和自动语音系统。CPL抽象了这些设备的功能细节。终端系统可以发起呼叫；它可以接受、拒绝或转发来电。这个过程的细节（铃声、多线电话等）对于CPL并不重要。
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.
就CPL而言，网关——例如，连接IP电话网络和PSTN之间呼叫的设备——也被视为终端系统。其他设备，如混频器或防火墙，不直接由CPL处理，这里将不讨论它们。
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.
信令服务器是中继或控制信令信息的设备。在SIP中，它们是代理服务器、重定向服务器或注册器；在H.323中，他们是守门人。
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.
代理it：将其转发到一个或多个其他网络或终端系统，返回接收到的响应之一。
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.
RFC 2543[1]有代理和重定向功能的说明。终端系统也可以执行其中一些操作：几乎可以肯定是拒绝，也可能是重定向。
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.
信令服务器通常还维护有关用户位置的信息。无论是通过注册（SIP REGISTER或H.323 RAS消息）、静态配置还是动态搜索，信令服务器都必须有某种方法来确定用户当前所在的位置，以便对其代理或重定向行为做出智能选择。
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.
信令服务器通常还能够保存通过它们的事务日志，并在编程控制下向Internet上的目的地发送电子邮件。
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.
当终端系统发出呼叫时，呼叫建立请求可以通过网络组件的各种路由进行。首先，发起端系统必须决定将其请求发送到何处。这里有两种可能性：可以配置发起者，使其所有请求都转到单个本地服务器；或者，它可以解析目标地址以定位远程信令服务器或终端系统，从而直接向其发送请求。
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.
一旦请求到达信令服务器，该服务器将使用其用户位置数据库、本地策略、DNS解析或其他方法来确定应向其发送请求的下一个信令服务器或终端系统。一个请求可以通过任意数量的信令服务器：从零（在终端系统直接通信的情况下）到原则上网络上的每个服务器。更重要的是，任何终端系统或信号服务器（原则上）都可以从任何其他系统接收请求或向任何其他系统发送请求。
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.
例如，在图1中，呼叫建立请求信息可能采用两种路径。对于路由1，发起者只知道它试图联系的用户的用户地址，并且它被配置为通过本地传出代理服务器发送传出呼叫。因此，它将请求转发到其本地服务器，该服务器将查找该地址的记录服务器，并将其转发到该服务器。
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.
但是，对于路由2，发起者知道其试图联系的特定设备地址，并且未配置为使用本地传出代理。在这种情况下，发起者可以直接联系目的地，而不必与任何网络服务器通信。
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.
因此，我们看到，在互联网电话中，信令服务器通常无法知道它们“控制”的终端系统的状态，因为信令信息可能绕过了它们。这种架构限制意味着对如何实现某些服务有许多限制。例如，网络系统不能可靠地知道终端系统当前是否繁忙；一个呼叫可能已经被放置到终端系统，而没有经过该网络系统。因此，信令消息必须显式地传送到终端系统以了解其状态；在本例中，终端系统必须显式返回“忙”指示。
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 |_____|
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
图1：呼叫设置消息的可能路径
7 Interaction of CPL with network model
7 CPL与网络模型的交互
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].
CPL脚本在信令服务器中运行，并控制系统的代理、重定向或拒绝操作，以设置特定调用。它不试图协调多个信令服务器的行为，也不试图描述智能网络体系结构中“全局功能平面”上的功能[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.
更具体地说，脚本取代了信令服务器的用户位置功能。如第6.1.2节所述，信令服务器通常维护一个可以联系到用户的位置数据库；它根据数据库的内容做出代理、重定向和拒绝决策。一个CPL脚本取代了这个基本的数据库查找功能；它获取注册信息、呼叫请求的细节以及它想要引用的其他外部信息，并选择要执行的信令操作。
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.
抽象地说，脚本可以看作是条件/动作对的列表；如果注册、请求和外部信息的某些属性与给定条件匹配，则会采取相应的操作（或更合适的操作集）。在某些情况下，可以根据第一次行动的后果和附加条件采取附加行动。如果没有与邀请匹配的条件，则执行信令服务器的标准操作（例如，其位置数据库查找）。
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.
CPL脚本通常与特定的Internet电话地址相关联。当呼叫建立请求到达作为CPL服务器的信令服务器时，该服务器将请求中指定的源地址和目的地址与其CPL脚本数据库相关联；如果一个匹配，则执行相应的脚本。
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.
一旦脚本执行完毕，如果它选择执行代理操作，将产生一个新的Internet电话地址作为代理的目标。一旦发生这种情况，服务器将再次检查其脚本数据库，以查看是否有脚本与新地址关联；如果是，也会执行该脚本（假设脚本未尝试代理服务器已尝试的地址）。有关此递归过程的更多详细信息，以及当服务器具有同时对应于脚本起始地址和目标地址的脚本时发生的情况的描述，请参阅第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:joe@example.com, 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:x26063@phones.example.com. 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."
一般来说，在互联网电话网络中，地址将表示两件事之一：用户或设备。用户地址指的是特定的个人，例如sip：joe@example.com，而不管该用户实际在何处或使用何种设备。相反，设备地址指的是特定的物理设备，如sip：x26063@phones.example.com. 其他中间类型的地址也是可能的，也有一些用途（比如“我的手机，无论它现在在哪里注册”），但我们希望它们不太常见。CPL脚本与它关联的地址类型无关；虽然与用户地址关联的脚本对于大多数服务来说可能是最有用的，但是没有理由不能将脚本与任何其他类型的地址关联。上述递归过程允许脚本与多个用户地址相关联；因此，用户脚本可以指定一个操作“在我的手机上试用我”，而设备脚本可以说“我不想在我不在家的时候接听手机。”
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
CPL脚本也可以不与一个特定的Internet电话地址相关联，而是与信令服务器处理的所有地址或一大组地址相关联。例如，管理员可能会配置一个系统来阻止来自或指向禁止的传入或传出地址列表的呼叫；应该为每个人配置这些脚本，但用户也应该能够拥有自己的自定义脚本。究竟什么时候会这样
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.
脚本应该在递归过程中执行，这取决于管理脚本的确切性质。有关这方面的进一步讨论，请参见第9.2节。
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.
用户可以在其呼叫建立请求通过的任何网络服务器上拥有CPL脚本，并且与之具有信任关系。例如，在图1中的示例中，发起用户可以在传出代理上拥有脚本，而目标用户可以在公司服务器和部门服务器上拥有脚本。这些脚本通常会执行不同的功能，与它们所在的服务器的角色有关；例如，公司范围服务器上的脚本可用于自定义用户希望在哪个部门找到，而部门服务器上的脚本可用于更细粒度的位置自定义。某些服务（如过滤掉不需要的呼叫）可能位于任一服务器上。请参见第9.3节，了解类似场景的一些含义。
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.
此模型未指定用户定位支持CPL的网络服务器的方式。一般来说，这将通过相同的方式进行，通过这种方式，他们可以找到本地互联网电话服务器进行注册；这可以通过手动配置，也可以通过诸如服务位置协议之类的自动方式[7]。有人建议，自动定位此类服务器的方法应包括一个字段，以指示服务器是否允许用户上传CPL。
8 Creation and transport of a call processing language script
8呼叫处理语言脚本的创建和传输
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.
用户通常在终端设备上创建呼叫处理语言脚本，并通过网络将其传输到信令服务器。脚本在信令服务器中持续存在，直到被更改或删除，除非特别指定了过期时间；支持CPL脚本的网络系统需要稳定的存储。
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.
用户创建CPL脚本的终端设备不需要与实际进行调用的终端设备有任何关系。例如，可以在PC上创建CPL脚本，而通话可以在简单的纯音频电话上接收。实际上，在其上创建脚本的设备可能根本不是第6.1.1节所述的“终端设备”；例如，用户可以从不支持多媒体的web终端创建并上传CPL脚本。
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.
就网络而言，CPL也不一定是在靠近终端设备或信令服务器的设备上创建的。例如，用户可能仅在到达远程位置后才决定将其呼叫转发到该位置。
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.
终端设备向服务器传输脚本的确切方式有待确定；许多解决方案可能会共存。几乎在所有情况下，都需要对该方法进行身份验证。建议的方法包括web文件上载、SIP注册消息有效负载、远程方法调用、SNMP、ACAP、LDAP和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.
如果用户与多个信令服务器有信任关系（如第7.3节所述），则用户可以选择将脚本上载到任何或所有这些服务器。这些脚本可以完全独立。
9 Feature interaction behavior
9特征交互行为
Feature interaction is the term used in telephony systems when two or more requested features produce ambiguous or conflicting behavior [8]. Feature interaction issues for features implemented with a call processing language can be roughly divided into three categories: feature-to-feature in one server, script-to-script in one server, and server-to-server.
当两个或多个请求的功能产生模糊或冲突行为时，功能交互是电话系统中使用的术语[8]。使用调用处理语言实现的功能的功能交互问题可以大致分为三类：一台服务器中的功能到功能、一台服务器中的脚本到脚本以及服务器到服务器。
Due to the explicit nature of event conditions discussed in the previous section, feature-to-feature interaction is not likely to be a problem in a call processing language environment. Whereas a subscriber to traditional telephone features might unthinkingly subscribe to both "call waiting" and "call forward on busy," a user creating a CPL script would only be able to trigger one action in response to the condition "a call arrives while the line is busy." Given a good user interface for creation, or a CPL server which can check for unreachable code in an uploaded script, contradictory condition/action pairs can be avoided.
由于前一节中讨论的事件条件的显式性质，在调用处理语言环境中，功能对功能的交互不太可能是一个问题。传统电话功能的用户可能会不假思索地同时订阅“呼叫等待”和“占线时呼叫转发”，而创建CPL脚本的用户只能触发一个动作来响应“占线时呼叫到达”的条件。如果有良好的创建用户界面，或者一个CPL服务器，它可以检查上传脚本中不可访问的代码，可以避免矛盾的条件/动作对。
Script-to-script interactions arise when a server invokes multiple scripts for a single call, as described in section 7.2. This can occur in a number of cases: if both the call originator and the destination have scripts specified on a single server; if a script forwards a request to another address which also has a script; or if an administrative script is specified as well as a user's individual script.
如第7.2节所述，当服务器为一次调用调用多个脚本时，会出现脚本到脚本的交互。这可能发生在许多情况下：如果呼叫发起人和目标都在单个服务器上指定了脚本；如果脚本将请求转发到另一个地址，该地址也有脚本；或者，如果指定了管理脚本以及用户的单个脚本。
The solution to this interaction is to determine an ordering among the scripts to be executed. In this ordering, the "first" script is executed first; if this script allows or permits the call to be proxied, the script corresponding to the next address is executed. When the first script says to forward the request to some other address, those actions are considered as new requests which arrive at the second script. When the second script sends back a final response, that response arrives at the first script in the same manner as if a request arrived over the network. Note that in some cases, forwarding can be recursive; a CPL server must be careful to prevent forwarding loops.
这种交互的解决方案是确定要执行的脚本之间的顺序。在该排序中，首先执行“第一”脚本；如果此脚本允许或允许代理调用，则执行与下一个地址对应的脚本。当第一个脚本要求将请求转发到其他地址时，这些操作被视为到达第二个脚本的新请求。当第二个脚本发回最终响应时，该响应以与通过网络到达请求相同的方式到达第一个脚本。注意，在某些情况下，转发可以是递归的；CPL服务器必须小心防止转发循环。
Abstractly, this can be viewed as equivalent to having each script execute on a separate signalling server. Since the CPL architecture is designed to allow scripts to be executed on multiple signalling servers in the course of locating a user, we can conceptually transform script-to-script interactions into the server-to-server interactions described in the next section, reducing the number of types of interactions we need to concern ourselves with.
抽象地说，这相当于让每个脚本在单独的信令服务器上执行。由于CPL体系结构旨在允许在定位用户的过程中在多个信令服务器上执行脚本，因此我们可以在概念上将脚本到脚本的交互转换为下一节中描述的服务器到服务器的交互，从而减少我们需要关注的交互类型的数量。
The question, then, is to determine the correct ordering of the scripts. For the case of a script forwarding to an address which also has a script, the ordering is obvious; the other two cases are somewhat more subtle. When both originator and destination scripts exist, the originator's script should be executed before the destination script; this allows the originator to perform address translation, call filtering, etc., before a destination address is determined and a corresponding script is chosen.
那么，问题是确定脚本的正确顺序。对于脚本转发到也有脚本的地址的情况，排序是明显的；另外两种情况则更为微妙。当发起人脚本和目标脚本同时存在时，发起人脚本应在目标脚本之前执行；这允许发起者在确定目标地址和选择相应脚本之前执行地址转换、呼叫过滤等。
Even more complicated is the case of the ordering of administrative scripts. Many administrative scripts, such as ones that restrict source and destination addresses, need to be run after originator scripts, but before destination scripts, to avoid a user's script evading administrative restrictions through clever forwarding; however, others, such as a global address book translation function, would need to be run earlier or later. Servers which allow
更复杂的是管理脚本的排序问题。许多管理脚本，例如限制源和目标地址的脚本，需要在发起人脚本之后但在目标脚本之前运行，以避免用户的脚本通过巧妙的转发规避管理限制；但是，其他功能（如全局通讯簿翻译功能）需要更早或更晚运行。允许
administrative scripts to be run will need to allow the administrator to configure when in the script execution process a particular administrative script should fall.
要运行的管理脚本需要允许管理员在脚本执行过程中配置某个特定的管理脚本。
The third case of feature interactions, server-to-server interactions, is the most complex of these three. The canonical example of this type of interaction is the combination of Originating Call Screening and Call Forwarding: a user (or administrator) may wish to prevent calls from being placed to a particular address, but the local script has no way of knowing if a call placed to some other, legitimate address will be proxied, by a remote server, to the banned address. This type of problem is unsolvable in an administratively heterogeneous network, even a "lightly" heterogeneous network such as current telephone systems. CPL does not claim to solve it, but the problem is not any worse for CPL scripts than for any other means of deploying services.
功能交互的第三种情况，即服务器到服务器的交互，是这三种情况中最复杂的。这类交互的典型示例是发起呼叫屏蔽和呼叫转发的组合：用户（或管理员）可能希望阻止将呼叫放在特定地址，但本地脚本无法知道放在其他合法地址的呼叫是否会被远程服务器代理，到被禁止的地址。这种类型的问题在管理异构网络中是无法解决的，即使是“轻微”异构的网络，如当前的电话系统。CPL并没有声称能够解决这个问题，但CPL脚本的问题并不比任何其他部署服务的方法更糟糕。
Another class of server-to-server interactions are best resolved by the underlying signalling protocol, since they can arise whether the signalling servers are being controlled by a call processing language or by some entirely different means. One example of this is forwarding loops, where user X may have calls forwarded to Y, who has calls forwarded back to X. SIP has a mechanism to detect such loops. A call processing language server thus does not need to define any special mechanisms to prevent such occurrences; it should, however, be possible to trigger a different set of call processing actions in the event that a loop is detected, and/or to report back an error to the owner of the script through some standardized run-time error reporting mechanism.
另一类服务器到服务器的交互最好通过底层信令协议来解决，因为无论信令服务器是由呼叫处理语言控制还是通过一些完全不同的方式控制，都可能出现这种情况。其中一个例子是转发循环，其中用户X可能将呼叫转发给Y，Y将呼叫转发回X。SIP具有检测此类循环的机制。因此，呼叫处理语言服务器不需要定义任何特殊机制来防止此类事件的发生；但是，在检测到循环的情况下，应该可以触发一组不同的调用处理操作，和/或通过一些标准化的运行时错误报告机制向脚本所有者报告错误。
As an aside, [8] discusses a fourth type of feature interaction for traditional telephone networks, signalling ambiguity. This can arise when several features overload the same operation in the limited signal path from an end station to the network: for example, flashing the switch-hook can mean both "add a party to a three-way call" and "switch to call waiting." Because of the explicit nature of signalling in both the Internet telephony protocols discussed here, this issue does not arise.
作为旁白，[8]讨论了传统电话网络的第四种功能交互，即信令模糊性。当多个功能在从终端站到网络的有限信号路径中使同一操作过载时，可能会出现这种情况：例如，闪烁交换机挂钩可能意味着“将一方添加到三路呼叫”和“交换机到呼叫等待”。由于此处讨论的两种互联网电话协议中的信令的明确性质，这个问题没有出现。
10 Relationship with existing languages
10与现有语文的关系
This document's description of the CPL as a "language" is not intended to imply that a new language necessarily needs to be implemented from scratch. A server could potentially implement all
本文档将CPL描述为一种“语言”，并不意味着需要从头开始实现一种新的语言。服务器可能会实现所有功能
the functionality described here as a library or set of extensions for an existing language; Java, or the various freely-available scripting languages (Tcl, Perl, Python, Guile), are obvious possibilities.
此处描述为现有语言的库或扩展集的功能；Java或各种免费提供的脚本语言（Tcl、Perl、Python、Guile）显然是可能的。
However, there are motivations for creating a new language. All the existing languages are, naturally, expressively complete; this has two inherent disadvantages. The first is that any function implemented in them can take an arbitrarily long time, use an arbitrarily large amount of memory, and may never terminate. For call processing, this sort of resource usage is probably not necessary, and as described in section 12.1, may in fact be undesirable. One model for this is the electronic mail filtering language Sieve [4], which deliberately restricts itself from being Turing-complete.
然而，创造一种新的语言是有动机的。所有现有的语言，自然地，表达上是完整的；这有两个固有的缺点。首先，在它们中实现的任何函数都可能花费任意长的时间，使用任意大的内存量，并且可能永远不会终止。对于呼叫处理，这种资源使用可能是不必要的，如第12.1节所述，实际上可能是不可取的。其中一个模型是电子邮件过滤语言Sieve[4]，它故意限制自己不具有图灵完整性。
Similar levels of safety and protection (though not automatic generation and parsing) could also be achieved through the use of a "sandbox" such as is used by Java applets, where strict bounds are imposed on the amount of memory, cpu time, stack space, etc., that a program can use. The difficulty with this approach is primarily in its lack of transparency and portability: unless the levels of these bounds are imposed by the standard, a bad idea so long as available resources are increasing exponentially with Moore's Law, a user can never be sure whether a particular program can successfully be executed on a given server without running into the server's resource limits, and a program which executes successfully on one server may fail unexpectedly on another. Non-expressively-complete languages, on the other hand, allow an implicit contract between the script writer and the server: so long as the script stays within the rules of the language, the server will guarantee that it will execute the script.
类似级别的安全和保护（虽然不是自动生成和解析）也可以通过使用“沙箱”来实现，如Java小程序所使用的沙箱，其中对程序可以使用的内存量、cpu时间、堆栈空间等施加严格的限制。这种方法的困难主要在于缺乏透明度和可移植性：除非这些界限的级别由标准规定，只要可用资源按照摩尔定律呈指数增长，这是一个坏主意，用户永远无法确定某个特定程序是否可以在给定服务器上成功执行而不受服务器资源限制，并且在一台服务器上成功执行的程序可能会在另一台服务器上意外失败。另一方面，非表达完整的语言允许脚本编写者和服务器之间的隐式契约：只要脚本保持在语言规则范围内，服务器将保证它将执行脚本。
The second disadvantage with expressively complete languages is that they make automatic generation and parsing of scripts very difficult, as every parsing tool must be a full interpreter for the language. An analogy can be drawn from the document-creation world: while text markup languages like HTML or XML can be, and are, easily manipulated by smart editors, powerful document programming languages such as LaTeX or Postscript usually cannot be. While there are word processors that can save their documents in LaTeX form, they cannot accept as input arbitrary LaTeX documents, let alone preserve the structure of the original document in an edited form. By contrast, essentially any HTML editor can edit any HTML document from the web, and the high-quality ones preserve the structure of the original documents in the course of editing them.
表达完整语言的第二个缺点是，它们使得脚本的自动生成和解析非常困难，因为每个解析工具都必须是该语言的完整解释器。可以从文档创建世界中得出一个类比：虽然像HTML或XML这样的文本标记语言可以并且可以很容易地被智能编辑器操纵，但像LaTeX或Postscript这样强大的文档编程语言通常不能。虽然有些文字处理器可以以LaTeX形式保存文档，但它们不能接受任意LaTeX文档作为输入，更不用说以编辑过的形式保留原始文档的结构。相比之下，本质上任何HTML编辑器都可以从web编辑任何HTML文档，高质量的编辑器在编辑过程中保留原始文档的结构。
11 Related work
11相关工作
The ITU's IN series describe, on an abstract level, service creation environments [6]. These describe services in a traditional circuit-switched telephone network as a series of decisions and actions arranged in a directed acyclic graph. Many vendors of IN services use modified and extended versions of this for their proprietary service creation environments.
ITU的系列标准在抽象级别上描述了服务创建环境[6]。它们将传统电路交换电话网络中的服务描述为以有向无环图排列的一系列决策和动作。许多IN-services供应商在其专有的服务创建环境中使用此服务的修改版和扩展版。
SIP CGI [9] is an interface for implementing services on SIP servers. Unlike a CPL, it is a very low-level interface, and would not be appropriate for services written by non-trusted users.
SIP CGI[9]是用于在SIP服务器上实现服务的接口。与CPL不同，它是一个非常低级的接口，不适合由不受信任的用户编写的服务。
The paper "Programming Internet Telephony Services" [10] discusses the similarities and contrasts between SIP CGI and CPL in more detail.
“互联网电话服务编程”[10]一文更详细地讨论了SIP CGI和CPL之间的相似性和对比。
12 Necessary language features
12必要的语言特征
This section lists those properties of a call processing language which we believe to be necessary to have in order to implement the motivating examples, in line with the described architecture.
本节列出了调用处理语言的那些属性，我们认为这些属性是实现激励示例所必需的，符合所描述的体系结构。
These are some abstract attributes which any proposed call processing language should possess.
这些是任何提出的调用处理语言都应该具备的一些抽象属性。
o Light-weight, efficient, easy to implement
o 重量轻、效率高、易于实施
In addition to the general reasons why this is desirable, a network server might conceivably handle very large call volumes, and we don't want CPL execution to be a major bottleneck. One way to achieve this might be to compile scripts before execution.
除了需要这样做的一般原因之外，网络服务器还可以处理非常大的呼叫量，我们不希望CPL执行成为主要的瓶颈。实现这一点的一种方法可能是在执行之前编译脚本。
o Easily verifiable for correctness
o 易于验证其正确性
For a script which runs in a server, mis-configurations can result in a user becoming unreachable, making it difficult to indicate run-time errors to a user (though a second-channel error reporting mechanism such as e-mail could ameliorate this). Thus, it should be possible to verify, when the script
对于在服务器中运行的脚本，错误配置可能会导致用户无法访问，从而难以向用户指示运行时错误（尽管第二个通道错误报告机制（如电子邮件）可以改善这一点）。因此，当脚本
is committed to the server, that it is at least syntactically correct, does not have any obvious loops or other failure modes, and does not use too many server resources.
提交给服务器，至少在语法上是正确的，没有任何明显的循环或其他故障模式，并且不使用太多的服务器资源。
o Executable in a safe manner
o 以安全的方式执行
No action the CPL script takes should be able to subvert anything about the server which the user shouldn't have access to, or affect the state of other users without permission. Additionally, since CPL scripts will typically run on a server on which users cannot normally run code, either the language or its execution environment must be designed so that scripts cannot use unlimited amounts of network resources, server CPU time, storage, or memory.
CPL脚本所采取的任何操作都不能破坏用户无权访问的服务器的任何内容，也不能在未经许可的情况下影响其他用户的状态。此外，由于CPL脚本通常在用户无法正常运行代码的服务器上运行，因此必须设计语言或其执行环境，以便脚本不能使用无限量的网络资源、服务器CPU时间、存储或内存。
o Easily writeable and parsable by both humans and machines.
o 人和机器都可以轻松编写和分析。
For maximum flexibility, we want to allow humans to write their own scripts, or to use and customize script libraries provided by others. However, most users will want to have a more intuitive user-interface for the same functionality, and so will have a program which creates scripts for them. Both cases should be easy; in particular, it should be easy for script editors to read human-generated scripts, and vice-versa.
为了获得最大的灵活性，我们希望允许人们编写自己的脚本，或者使用和自定义他人提供的脚本库。但是，大多数用户都希望为相同的功能提供更直观的用户界面，因此会有一个为他们创建脚本的程序。这两种情况都应该很容易；特别是，脚本编辑器应该很容易读取人工生成的脚本，反之亦然。
o Extensible
o 可扩展
It should be possible to add additional features to a language in a way that existing scripts continue to work, and existing servers can easily recognize features they don't understand and safely inform the user of this fact.
应该可以通过现有脚本继续工作的方式向语言添加其他功能，并且现有服务器可以轻松识别他们不理解的功能，并安全地通知用户这一事实。
o Independent of underlying signalling details
o 独立于底层信令细节
The same scripts should be usable whether the underlying protocol is SIP, H.323, a traditional telephone network, or any other means of setting up calls. It should also be agnostic to address formats. (We use SIP terminology in our descriptions of requirements, but this should map fairly easily to other systems.) It may also be useful to have the language extend to processing of other sorts of communication, such as e-mail or fax.
无论底层协议是SIP、H.323、传统电话网络还是任何其他建立呼叫的方式，都应该可以使用相同的脚本。它也应该是不可知的地址格式。（我们在需求描述中使用SIP术语，但这应该很容易映射到其他系统。）将该语言扩展到处理其他类型的通信（如电子邮件或传真）也可能有用。
To be useful, a call processing language obviously should be able to react to and initiate call signalling events.
为了有用，呼叫处理语言显然应该能够响应和启动呼叫信令事件。
o Should execute actions when a call request arrives
o 应在呼叫请求到达时执行操作
See section 7, particularly 7.1.
见第7节，特别是第7.1节。
o Should be able to make decisions based on event properties
o 应该能够根据事件属性做出决策
A number of properties of a call event are relevant for a script's decision process. These include, roughly in order of importance:
调用事件的许多属性与脚本的决策过程相关。这些措施大致按重要性顺序包括：
- Destination address
- 目的地址
We want to be able to do destination-based routing or screening. Note that in SIP we want to be able to filter on either or both of the addresses in the To header and the Request-URI.
我们希望能够进行基于目的地的路由或筛选。请注意，在SIP中，我们希望能够对to头和请求URI中的一个或两个地址进行筛选。
- Originator address
- 发起者地址
Similarly, we want to be able to do originator-based screening or routing.
同样，我们希望能够进行基于发起人的筛选或路由。
- Caller Preferences
- 呼叫方首选项
In SIP, a caller can express preferences about the type of device to be reached -- see [11]. The script should be able to make decisions based on this information.
在SIP中，调用者可以表示要访问的设备类型的首选项——请参见[11]。脚本应该能够基于此信息做出决策。
- Information about caller or call
- 关于呼叫者或呼叫的信息
SIP has textual fields such as Subject, Organization, Priority, etc., and a display name for addresses; users can also add non-standard additional headers. H.323 has a single Display field. The script should be able to make decisions based on these parameters.
SIP具有主题、组织、优先级等文本字段，以及地址的显示名称；用户还可以添加非标准的附加标题。323只有一个显示字段。脚本应该能够根据这些参数做出决策。
- 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.
呼叫邀请指定将流动的媒体类型、带宽使用情况、网络目标地址等。脚本应能够根据这些媒体特征做出决策。
- 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
o 应该能够根据电话邀请采取行动
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).
我们应该能够表明呼叫不可接受或无法完成。我们还应该能够发送更具体的拒绝代码（对于SIP，包括相关的文本字符串、警告代码或消息负载）。
- 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
o 应能够基于对代理或分支呼叫邀请的响应采取行动
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.
我们应该能够考虑与最初邀请中所考虑的响应相同的领域。
- 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
- 对于fork，从几个响应中选择一个进行中继
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).
如果我们没有得到回复，或者没有任何我们喜欢的回复，我们应该可以尝试其他方式（例如，在忙时向前呼叫）。
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.
提供这些功能的服务器可能位于其他Internet设备中，也可能位于服务器本地（或其他可能性）。语言应该独立于这些服务器的位置，至少在较高级别上是这样。
o Logging
o 登录中
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.
除了CPL服务器自然记录事件外，用户还希望能够记录任意其他项目。此日志记录信息的实际存储可能位于本地或远程。
o Error reporting
o 错误报告
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).
如果发生意外错误，脚本应该能够向脚本的所有者报告错误。这可能使用与脚本服务器向用户报告语言错误相同的机制（参见第12.5节）。
o Access to user-location info
o 访问用户位置信息
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
代理通常会通过SIP注册消息、H.323 RRQ系列RAS消息或其他一些机制收集关于用户当前位置的信息（参见第节）
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.
6.2). CPL应该能够参考此信息，以便将呼叫转发到注册位置或其中的某个子集。
o Database access
o 数据库访问
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.
CPL控制的许多信息可能存储在外部数据库中，例如广域地址数据库，或管理控制下CPL的授权信息。该语言可以指定某些特定的数据库访问协议（如SQL或LDAP），也可以更通用。
o Other external information
o 其他外部信息
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.
脚本可以访问的其他外部信息包括可以在SIP消息体中发回的网页；或者是远程过程调用（例如Corba、RMI或DCOM）的干净接口，以访问外部计费数据库。但是，为简单起见，这些接口可能不在协议的初始版本中。
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.)
一些特性不涉及CPL执行环境之外的任何操作，但仍然是实现一些标准服务所必需的。（此列表并非详尽无遗。）
o Pattern-matching
o 模式匹配
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
o 地址过滤
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.
一旦通过第12.3节中的一种方法检索到一组地址，用户需要能够根据地址组件或其他参数选择一个子集。
o Randomization
o 随机化
Some forms of call distribution are randomized as to where they actually end up.
某些形式的呼叫分布是随机化的，以确定它们的最终位置。
o Date/time information
o 日期/时间信息
Users may wish to condition some services (e.g., call forwarding, call distribution) on the current time of day, day of the week, etc.
用户可能希望在一天中的当前时间、一周中的某一天等调整某些服务（例如呼叫转接、呼叫分配）。
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.
如第8节所述，我们必须有一种机制来向信令服务器发送和检索CPL脚本以及相关数据。此方法应支持向用户报告上载时间错误；我们还需要一些机制在脚本执行时向用户报告错误。身份验证至关重要，加密非常有用。这种机制的规范可以（也可能应该）是一种独立于调用处理语言本身的规范。
13 Security Considerations
13安全考虑
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.
第8节和第12.5节讨论了传输CPL脚本的安全注意事项。第12.1节讨论了有关语言执行的一些注意事项。
14 Acknowledgments
14致谢
We would like to thank Tom La Porta and Jonathan Rosenberg for their comments and suggestions.
我们要感谢Tom La Porta和Jonathan Rosenberg的评论和建议。
15 Authors' Addresses
15作者地址
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系Jonathan Lennox 0401
EMail: lennox@cs.columbia.edu
EMail: lennox@cs.columbia.edu
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系，邮编：10027
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
16 Bibliography
16参考书目
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1] Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[2] International Telecommunication Union, "Packet based multimedia communication systems," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[2] 国际电信联盟，“基于分组的多媒体通信系统”，建议H.323，国际电联电信标准化部门，瑞士日内瓦，1998年2月。
[3] K. Coar and D. Robinson, "The WWW common gateway interface version 1.1", Work in Progress.
[3] K.Coar和D.Robinson，“WWW公共网关接口1.1版”，正在进行中。
[4] T. Showalter, "Sieve: A mail filtering language", Work in Progress.
[4] T.Showalter，“筛选：邮件过滤语言”，正在进行中。
[5] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services", Work in Progress.
[5] J.Lennox和H.Schulzrinne，“CPL：互联网电话服务的用户控制语言”，正在进行中。
[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.
[6] 国际电信联盟，“关于电话交换和信令的一般建议——智能网：智能网能力集1简介”，建议Q.1211，国际电联电信标准化部门，瑞士日内瓦，1993年3月。
[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[7] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[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.
[8] E.J.Cameron，N.D.Griffeth，Y.-J.Lin，M.E.Nilson，W.K.Schure和H.Velthuijsen，“IN和beyond的功能交互基准”，电信系统中的功能交互，IOS出版社，1994年1-23页。
[9] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway interface for SIP", Work in Progress.
[9] J.Lennox、J.Rosenberg和H.Schulzrinne，“SIP公共网关接口”，正在进行中。
[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.
[10] J.Rosenberg、J.Lennox和H.Schulzrinne，“互联网电话服务编程”，技术报告CUCS-010-99，哥伦比亚大学，纽约，纽约，1999年3月。
[11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in Progress.
[11] H.Schulzrinne和J.Rosenberg，“SIP呼叫方偏好和被呼叫方能力”，正在进行中。
17 Full Copyright Statement
17版权声明全文
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。