Network Working Group J. Lennox
Request for Comments: 3050 H. Schulzrinne
Category: Informational Columbia U.
J. Rosenberg
dynamicsoft
January 2001
Network Working Group J. Lennox
Request for Comments: 3050 H. Schulzrinne
Category: Informational Columbia U.
J. Rosenberg
dynamicsoft
January 2001
Common Gateway Interface for SIP
SIP通用网关接口
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI is a good candidate for service creation in a SIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server.
在互联网电话技术中，必须有一种快速创建和部署新服务的方法。在万维网中，公共网关接口（CGI）已成为编程Web服务的流行手段。由于会话发起协议（SIP）和超文本传输协议（HTTP）之间的相似性，CGI是SIP环境中创建服务的良好候选。本文档定义了一个SIP CGI接口，用于在SIP服务器上提供SIP服务。
IESG Note
IESG注释
The IESG notes that the mechanism specified here depends on the Common Gateway Interface. Should this interface change or be enhanced changes in this specification may also be necessary or appropriate. According to the W3C, the CGI is presently maintained by the NCSA Software Development Group. See
IESG指出，此处指定的机制取决于公共网关接口。如果此接口发生更改或增强，则本规范中的更改也可能是必要的或适当的。根据W3C，CGI目前由NCSA软件开发组维护。看见
http://www.w3c.org/cgi
http://www.w3c.org/cgi
for additional information on the current state of the CGI interface.
有关CGI接口当前状态的更多信息。
Table of Contents
目录
1 Introduction ....................................... 3
2 Motivations ........................................ 4
3 Differences from HTTP CGI .......................... 5
3.1 Basic Model ........................................ 6
3.2 Persistence Model .................................. 8
3.3 SIP CGI Triggers ................................... 9
3.4 Naming ............................................. 9
3.5 Environment Variables .............................. 9
3.6 Timers ............................................. 10
4 Overview of SIP CGI ................................ 10
5 SIP CGI Specification .............................. 12
5.1 Introduction ....................................... 12
5.1.1 Relationship with HTTP CGI ......................... 12
5.1.2 Conventions of This Document ....................... 12
5.1.3 Specifications ..................................... 12
5.1.4 Terminology ........................................ 13
5.2 Notational Conventions and Generic Grammar ......... 13
5.3 Invoking the Script ................................ 14
5.4 The SIP CGI Script Command Line .................... 14
5.5 Data Input to the SIP CGI Script ................... 14
5.5.1 Message Metadata (Metavariables) ................... 14
5.5.1.1 AUTH_TYPE .......................................... 16
5.5.1.2 CONTENT_LENGTH ..................................... 16
5.5.1.3 CONTENT_TYPE ....................................... 17
5.5.1.4 GATEWAY_INTERFACE .................................. 17
5.5.1.5 Protocol-Specific Metavariables .................... 18
5.5.1.6 REGISTRATIONS ...................................... 18
5.5.1.7 REMOTE_ADDR ........................................ 19
5.5.1.8 REMOTE_HOST ........................................ 19
5.5.1.9 REMOTE_IDENT ....................................... 19
5.5.1.10 REMOTE_USER ........................................ 20
5.5.1.11 REQUEST_METHOD ..................................... 20
5.5.1.12 REQUEST_TOKEN ...................................... 21
5.5.1.13 REQUEST_URI ........................................ 21
5.5.1.14 RESPONSE_STATUS .................................... 21
5.5.1.15 RESPONSE_REASON .................................... 21
5.5.1.16 RESPONSE_TOKEN ..................................... 21
5.5.1.17 SCRIPT_COOKIE ...................................... 22
5.5.1.18 SERVER_NAME ........................................ 22
5.5.1.19 SERVER_PORT ........................................ 22
5.5.1.20 SERVER_PROTOCOL .................................... 22
5.5.1.21 SERVER_SOFTWARE .................................... 23
5.5.2 Message Bodies ..................................... 23
5.6 Data Output from the SIP CGI Script ................ 23
5.6.1 CGI Action Lines ................................... 25
5.6.1.1 Status ............................................. 25
1 Introduction ....................................... 3
2 Motivations ........................................ 4
3 Differences from HTTP CGI .......................... 5
3.1 Basic Model ........................................ 6
3.2 Persistence Model .................................. 8
3.3 SIP CGI Triggers ................................... 9
3.4 Naming ............................................. 9
3.5 Environment Variables .............................. 9
3.6 Timers ............................................. 10
4 Overview of SIP CGI ................................ 10
5 SIP CGI Specification .............................. 12
5.1 Introduction ....................................... 12
5.1.1 Relationship with HTTP CGI ......................... 12
5.1.2 Conventions of This Document ....................... 12
5.1.3 Specifications ..................................... 12
5.1.4 Terminology ........................................ 13
5.2 Notational Conventions and Generic Grammar ......... 13
5.3 Invoking the Script ................................ 14
5.4 The SIP CGI Script Command Line .................... 14
5.5 Data Input to the SIP CGI Script ................... 14
5.5.1 Message Metadata (Metavariables) ................... 14
5.5.1.1 AUTH_TYPE .......................................... 16
5.5.1.2 CONTENT_LENGTH ..................................... 16
5.5.1.3 CONTENT_TYPE ....................................... 17
5.5.1.4 GATEWAY_INTERFACE .................................. 17
5.5.1.5 Protocol-Specific Metavariables .................... 18
5.5.1.6 REGISTRATIONS ...................................... 18
5.5.1.7 REMOTE_ADDR ........................................ 19
5.5.1.8 REMOTE_HOST ........................................ 19
5.5.1.9 REMOTE_IDENT ....................................... 19
5.5.1.10 REMOTE_USER ........................................ 20
5.5.1.11 REQUEST_METHOD ..................................... 20
5.5.1.12 REQUEST_TOKEN ...................................... 21
5.5.1.13 REQUEST_URI ........................................ 21
5.5.1.14 RESPONSE_STATUS .................................... 21
5.5.1.15 RESPONSE_REASON .................................... 21
5.5.1.16 RESPONSE_TOKEN ..................................... 21
5.5.1.17 SCRIPT_COOKIE ...................................... 22
5.5.1.18 SERVER_NAME ........................................ 22
5.5.1.19 SERVER_PORT ........................................ 22
5.5.1.20 SERVER_PROTOCOL .................................... 22
5.5.1.21 SERVER_SOFTWARE .................................... 23
5.5.2 Message Bodies ..................................... 23
5.6 Data Output from the SIP CGI Script ................ 23
5.6.1 CGI Action Lines ................................... 25
5.6.1.1 Status ............................................. 25
5.6.1.2 Proxy Request ...................................... 25
5.6.1.3 Forward Response ................................... 26
5.6.1.4 Script Cookie ...................................... 26
5.6.1.5 CGI Again .......................................... 27
5.6.1.6 Default Action ..................................... 27
5.6.2 CGI Header Fields .................................. 28
5.6.2.1 Request-Token ...................................... 28
5.6.2.2 Remove ............................................. 28
5.7 Local Expiration Handling .......................... 28
5.8 Locally-Generated Responses ........................ 29
5.9 SIP CGI and REGISTER ............................... 29
5.10 SIP CGI and CANCEL ................................. 29
5.11 SIP CGI and ACK .................................... 30
5.11.1 Receiving ACK's .................................... 30
5.11.2 Sending ACK's ...................................... 30
6 System Specifications .............................. 30
6.1 Unix ............................................... 30
6.2 Microsoft Windows .................................. 31
7 Security Considerations ............................ 31
7.1 Request Initiation ................................. 31
7.2 Authenticated and Encrypted Messages ............... 31
7.3 SIP Header Fields Containing Sensitive Information.. 32
7.4 Script Interference with the Server ................ 32
7.5 Data Length and Buffering Considerations ........... 32
8 Acknowledgements ................................... 33
9 Authors' Addresses ................................. 33
10 Bibliography ....................................... 34
11 Full Copyright Statement ........................... 35
5.6.1.2 Proxy Request ...................................... 25
5.6.1.3 Forward Response ................................... 26
5.6.1.4 Script Cookie ...................................... 26
5.6.1.5 CGI Again .......................................... 27
5.6.1.6 Default Action ..................................... 27
5.6.2 CGI Header Fields .................................. 28
5.6.2.1 Request-Token ...................................... 28
5.6.2.2 Remove ............................................. 28
5.7 Local Expiration Handling .......................... 28
5.8 Locally-Generated Responses ........................ 29
5.9 SIP CGI and REGISTER ............................... 29
5.10 SIP CGI and CANCEL ................................. 29
5.11 SIP CGI and ACK .................................... 30
5.11.1 Receiving ACK's .................................... 30
5.11.2 Sending ACK's ...................................... 30
6 System Specifications .............................. 30
6.1 Unix ............................................... 30
6.2 Microsoft Windows .................................. 31
7 Security Considerations ............................ 31
7.1 Request Initiation ................................. 31
7.2 Authenticated and Encrypted Messages ............... 31
7.3 SIP Header Fields Containing Sensitive Information.. 32
7.4 Script Interference with the Server ................ 32
7.5 Data Length and Buffering Considerations ........... 32
8 Acknowledgements ................................... 33
9 Authors' Addresses ................................. 33
10 Bibliography ....................................... 34
11 Full Copyright Statement ........................... 35
1 Introduction
1导言
In Internet telephony, there must be a means by which new services are created and deployed rapidly. In traditional telephony networks, this was accomplished through IN service creation environments, which provided an interface for creating new services, often using GUI-based tools.
在互联网电话技术中，必须有一种快速创建和部署新服务的方法。在传统电话网络中，这是通过服务内创建环境实现的，该环境提供了创建新服务的接口，通常使用基于GUI的工具。
The WWW has evolved with its own set of tools for service creation. Originally, web servers simply translated URLs into filenames stored on a local system, and returned the file content. Over time, servers evolved to provide dynamic content, and forms provided a means for soliciting user input. In essence, what evolved was a means for service creation in a web environment. There are now many means for creation of dynamic web content, including server side JavaScript, servlets, and the common gateway interface (CGI) [1].
WWW已经发展出自己的一套服务创建工具。最初，web服务器只是将URL转换为存储在本地系统上的文件名，然后返回文件内容。随着时间的推移，服务器逐渐演变为提供动态内容，而表单则提供了征求用户输入的手段。本质上，所发展的是一种在web环境中创建服务的方法。现在有很多方法可以创建动态web内容，包括服务器端JavaScript、servlet和公共网关接口（CGI）[1]。
Multimedia communications, including Internet telephony, will also require a mechanism for creating services. This mechanism is strongly tied to the features provided by the signaling protocols. The Session Initiation Protocol (SIP) [2] has been developed for initiation and termination of multimedia sessions. SIP borrows heavily from HTTP, inheriting its client-server interaction and much of its syntax and semantics. For this reason, the web service creation environments, and CGI in particular, seem attractive as starting points for developing SIP based service creation environments.
多媒体通信，包括互联网电话，也需要一种创建服务的机制。该机制与信令协议提供的功能紧密相关。会话启动协议（SIP）[2]是为启动和终止多媒体会话而开发的。SIP大量借鉴了HTTP，继承了它的客户机-服务器交互以及大部分语法和语义。因此，web服务创建环境，特别是CGI，似乎是开发基于SIP的服务创建环境的起点。
2 Motivations
2动机
CGI has a number of strengths which make it attractive as an environment for creating SIP services:
CGI具有许多优势，使其成为创建SIP服务的环境：
Language independence: CGI works with perl, C, VisualBasic, tcl, and many other languages, as long as they support access to environment variables.
语言独立性：CGI与perl、C、VisualBasic、tcl和许多其他语言一起工作，只要它们支持对环境变量的访问。
Exposes all headers: CGI exposes the content of all the headers in an HTTP request to the CGI application. An application can make use of these as it sees fit, and ignore those it doesn't care about. This allows all aspects of an HTTP request to be considered for creation of content. In a SIP environment, headers have greater importance than in HTTP. They carry critical information about the transaction, including caller and callee, subject, contact addresses, organizations, extension names, registration parameters and expirations, call status, and call routes, to name a few. It is therefore critical for SIP services to have as much access to these headers as possible. For this reason, CGI is very attractive.
公开所有头：CGI向CGI应用程序公开HTTP请求中所有头的内容。应用程序可以在它认为合适的时候使用它们，而忽略那些它不关心的。这允许在创建内容时考虑HTTP请求的所有方面。在SIP环境中，头比HTTP中的头更重要。它们包含有关事务的关键信息，包括呼叫者和被呼叫者、主题、联系地址、组织、分机名、注册参数和到期时间、呼叫状态和呼叫路由等等。因此，对SIP服务来说，尽可能多地访问这些报头是至关重要的。因此，CGI非常有吸引力。
Creation of responses: CGI is advantageous in that it can create all parts of a response, including headers, status codes and reason phrases, in addition to message bodies. This is not the case for other mechanisms, such as Java servlets, which are focused primarily on the body. In a SIP environment, it is critical to be able to generate all aspects of a response (and, all aspects of new or proxied requests), since the body is usually not of central importance in SIP service creation.
创建响应：CGI的优势在于，它可以创建响应的所有部分，包括消息正文之外的标题、状态代码和原因短语。其他机制（如JavaServlets）的情况并非如此，它们主要关注于主体。在SIP环境中，能够生成响应的所有方面（以及新请求或代理请求的所有方面）是至关重要的，因为主体在SIP服务创建中通常并不重要。
Component reuse: Many of the CGI utilities allow for easy reading of environment variables, parsing of form data, and often parsing and generation of header fields. Since SIP reuses the basic RFC822 [3] syntax of HTTP, many of these tools are applicable to SIP CGI.
组件重用：许多CGI实用程序允许轻松读取环境变量、解析表单数据，通常还可以解析和生成头字段。由于SIP重用HTTP的基本RFC822[3]语法，因此这些工具中的许多都适用于SIP CGI。
Familiar environment: Many web programmers are familiar with CGI.
熟悉的环境：许多web程序员都熟悉CGI。
Ease of extensibility: Since CGI is an interface and not a language, it becomes easy to extend and reapply to other protocols, such as SIP.
易扩展性：由于CGI是一种接口而不是一种语言，因此很容易扩展并重新应用于其他协议，如SIP。
The generality, extensibility, and detailed control and access to information provided by CGI, coupled with the range of tools that exist for it, which can be immediately applied to SIP, make it a good mechanism for SIP service creation.
CGI提供的通用性、可扩展性以及对信息的详细控制和访问，加上可立即应用于SIP的现有工具范围，使其成为SIP服务创建的良好机制。
3 Differences from HTTP CGI
3与HTTP CGI的区别
While SIP and HTTP share a basic syntax and a request-response model, there are important differences. Proxies play a critical role in services for SIP, while they are less important for HTTP. SIP servers can fork requests (proxying multiple requests when a single request is received), an important capability absent from HTTP. SIP supports additional features, such as registrations, which are absent from HTTP. These differences are reflected in the differences between SIP CGI and HTTP CGI. SIP CGI runs primarily on proxy, redirect, and registrar servers, rather than user agent servers (which are the equivalent of origin servers in HTTP). SIP CGI allows the script to perform specific messaging functions not supported in HTTP CGI (such as proxying requests), and SIP CGI introduces a persistence model that allow a script to maintain control through multiple message exchanges. HTTP CGI has no persistence for scripts.
虽然SIP和HTTP共享一个基本语法和一个请求-响应模型，但它们有着重要的区别。代理在SIP服务中起着关键作用，而在HTTP服务中则不那么重要。SIP服务器可以分叉请求（在收到单个请求时代理多个请求），这是HTTP中缺少的一项重要功能。SIP支持HTTP中没有的附加功能，例如注册。这些差异反映在SIP CGI和HTTP CGI之间的差异中。SIP CGI主要运行在代理服务器、重定向服务器和注册服务器上，而不是用户代理服务器（与HTTP中的源服务器等效）。SIP CGI允许脚本执行HTTP CGI中不支持的特定消息传递功能（如代理请求），SIP CGI引入了一个持久性模型，允许脚本通过多个消息交换来维护控制。HTTP CGI没有脚本的持久性。
The basic model for HTTP CGI is depicted in figure 1.
HTTP CGI的基本模型如图1所示。
----- ------------
~~~~~~~~ |req | | -------- |
| |----------| | http | |
| client | |resp | | | server | |
| |----------| | | |w
~~~~~~~~ | | | -------- |e
----- | s| /\s |b
net | t| |t |
|e d| C |d |s
|n i| G |o |e
|v n| I |u |r
| | |t |v
| \/ | |e
| ------- |r
| | | |
| | CGI | |
| | prog. | |
| | | |
| ------- |
------------
----- ------------
~~~~~~~~ |req | | -------- |
| |----------| | http | |
| client | |resp | | | server | |
| |----------| | | |w
~~~~~~~~ | | | -------- |e
----- | s| /\s |b
net | t| |t |
|e d| C |d |s
|n i| G |o |e
|v n| I |u |r
| | |t |v
| \/ | |e
| ------- |r
| | | |
| | CGI | |
| | prog. | |
| | | |
| ------- |
------------
Figure 1: HTTP CGI Model
图1:HTTPCGI模型
A client issues an HTTP request, which is passed either directly to the origin server (as shown), or is forwarded through a proxy server. The origin server executes a CGI script, and the CGI script returns a response, which is passed back to the client. The main job of the script is to generate the body for the response. Only origin servers execute CGI scripts, not proxy servers.
客户端发出HTTP请求，该请求直接传递给源服务器（如图所示），或者通过代理服务器转发。源服务器执行一个CGI脚本，CGI脚本返回一个响应，该响应被传递回客户端。脚本的主要任务是生成响应的主体。只有源服务器执行CGI脚本，而不是代理服务器。
In a SIP server, the model is different, and is depicted in Figure 2.
在SIP服务器中，模型不同，如图2所示。
~~~~~~~~ req ------- req ------- req ~~~~~~~~
| |------| |-------| |---------| |
| client | resp | server| resp | server| resp | client |
| |------| |-------| |---------| |
~~~~~~~~ ------- ------- --------
| | CGI
| |
-------
| |
| CGI |
| prog. |
| |
-------
~~~~~~~~ req ------- req ------- req ~~~~~~~~
| |------| |-------| |---------| |
| client | resp | server| resp | server| resp | client |
| |------| |-------| |---------| |
~~~~~~~~ ------- ------- --------
| | CGI
| |
-------
| |
| CGI |
| prog. |
| |
-------
Figure 2: SIP CGI Model
图2:SIPCGI模型
The client generates a request, which is forwarded to a server. The server may generate a response (such as an error or redirect response). Or, if the server is a proxy server, the request is proxied to another server, and eventually to a user agent, and the response is passed back upstream, through the server, and back towards the client. A SIP proxy server may additionally fork requests, generating multiple requests in response to a received request. Generally, a proxy server will not generate the content in responses. These contain session descriptions created by user agents. Services, such as call forward and mobility services, are based on the decisions the server makes about (1) when, to where, and how many requests to proxy downstream, and (2) when to send a response back upstream. Creation of services such as ad-hoc bridging (where the server acts as a media mixer in a multiparty call, without being asked to do so by the end users) will require the server to generate new requests of its own, and for it to modify and generate the body in responses.
客户端生成一个请求，该请求被转发到服务器。服务器可能会生成响应（例如错误或重定向响应）。或者，如果服务器是代理服务器，则将请求代理到另一台服务器，并最终代理到用户代理，然后通过服务器将响应传递回上游，然后返回到客户端。SIP代理服务器还可以分叉请求，生成多个请求以响应接收到的请求。通常，代理服务器不会在响应中生成内容。其中包含由用户代理创建的会话描述。服务（如前向呼叫和移动服务）基于服务器做出的决定（1）何时、何地以及向下游代理发送多少请求，以及（2）何时向上游发送响应。创建诸如特设桥接（其中服务器在多方呼叫中充当媒体混合器，而无需最终用户要求这样做）之类的服务将要求服务器生成自己的新请求，并在响应中修改和生成正文。
An HTTP server is mainly concerned about generation of responses. A SIP server is generally concerned about performing four basic operations:
HTTP服务器主要关注响应的生成。SIP服务器通常涉及执行四个基本操作：
Proxying of Requests: Receiving a request, adding or modifying any of the headers, deciding on a set of servers to forward the request to, and forwarding it to them.
请求代理：接收请求、添加或修改任何标头、决定将请求转发到的一组服务器并将其转发给它们。
Returning Responses: Receiving a response, adding or modifying any of the headers, and passing the response towards the client.
返回响应：接收响应，添加或修改任何头，并将响应传递给客户端。
Generating Requests: Creating a new request, originating at the server, placing headers and a body into the message, and sending it to a server.
生成请求：创建一个新请求，在服务器上发起，在消息中放置头和正文，并将其发送到服务器。
Generation of Responses: Receiving a request, generating a response to it, and sending it back to the client.
生成响应：接收请求，生成响应，并将其发送回客户端。
When a request is received, one or more of the above operations may occur at once. For example, a SIP server may generate a provisional response, generate a new request, and proxy the original request to two servers. This implies that SIP CGI must encompass a greater set of functions than HTTP CGI. These functions are a super-set of the simple end-server request/response model.
当接收到请求时，上述一个或多个操作可能会同时发生。例如，SIP服务器可以生成临时响应，生成新请求，并将原始请求代理给两个服务器。这意味着SIP CGI必须包含比HTTP CGI更多的功能集。这些函数是简单的终端服务器请求/响应模型的超集。
In HTTP CGI, a script is executed once for each request. It generates the response, and then terminates. There is no state maintained across requests from the same user, as a general rule (although this can be done -- and is -- for more complex services such as database accesses, which essentially encapsulate state in client-side cookies or dynamically-generated URLs). A transaction is just a single request, and a response.
在HTTP CGI中，每个请求执行一次脚本。它生成响应，然后终止。作为一般规则，在来自同一用户的请求之间不存在状态维护（尽管对于更复杂的服务，如数据库访问，它本质上是将状态封装在客户端cookie或动态生成的URL中，这是可以做到的，而且是可以做到的）。事务只是一个请求和一个响应。
In SIP CGI, since a request can generate many new and proxied requests, these themselves will generate responses. A service will often require these responses to be processed, and additional requests or responses to be generated. As a result, whereas an HTTP CGI script executes once per transaction, a SIP CGI script must maintain control somehow over numerous events.
在SIP CGI中，由于请求可以生成许多新的和代理的请求，这些请求本身将生成响应。服务通常需要处理这些响应，并生成其他请求或响应。因此，HTTP CGI脚本在每个事务中执行一次，而SIP CGI脚本必须以某种方式保持对多个事件的控制。
In order to enable this, and to stay with the original CGI model, we mandate that a SIP CGI script executes when a message arrives, and after generating output (in the form of additional messages), terminate. State is maintained by allowing the CGI to return an opaque token to the server. When the CGI script is called again for the same transaction, this token is passed back to the CGI script. When called for a new transaction, no token is passed.
为了实现这一点，并保持原始CGI模型不变，我们要求SIP CGI脚本在消息到达时执行，并在生成输出（以附加消息的形式）后终止。状态是通过允许CGI向服务器返回不透明令牌来维护的。当为同一事务再次调用CGI脚本时，该令牌被传递回CGI脚本。当为新事务调用时，不会传递任何令牌。
For example, consider a request which arrives at a SIP server. The server calls a CGI script, which generates a provisional response and a proxied request. It also returns a token to the server, and then terminates. The response is returned upstream towards the client, and the request is proxied. When the response to the proxied request arrives, the script is executed again. The environment variables are set based on the content of the new response. The script is also passed back the token. Using the token as its state, the script decides to proxy the request to a different location. It therefore
例如，考虑到达SIP服务器的请求。服务器调用CGI脚本，该脚本生成临时响应和代理请求。它还向服务器返回一个令牌，然后终止。响应向上游返回到客户端，请求被代理。当对代理请求的响应到达时，脚本将再次执行。根据新响应的内容设置环境变量。脚本也会传回令牌。使用令牌作为其状态，脚本决定将请求代理到其他位置。因此
returns a proxied request, and another token. The server forwards this new request, and when the response comes, calls the CGI script once more, and passes back the token. This time, the script generates a final response, and passes this back to the server. The server sends the response to the client, destroys the token, and the transaction is complete.
返回代理请求和另一个令牌。服务器转发这个新请求，当响应到来时，再次调用CGI脚本，并传回令牌。这一次，脚本生成最终响应，并将其传递回服务器。服务器向客户端发送响应，销毁令牌，事务完成。
In many cases, calling the CGI script on the reception of every message is inefficient. CGI scripts come at the cost of significant overhead since they generally require creation of a new process. Therefore, it is important in SIP CGI for a script to indicate, after it is called the first time, under what conditions it will be called for the remainder of the transaction. If the script is not called, the server will take the "default" action, as specified in this document. This allows an application designer to trade off flexibility for computational resources. Making an analogy to the Intelligent Network (IN) - a script is able to define the triggers for its future execution.
在许多情况下，在接收每条消息时调用CGI脚本是低效的。CGI脚本的成本很高，因为它们通常需要创建一个新流程。因此，在SIP CGI中，脚本在第一次调用后，指示在什么条件下将为事务的其余部分调用它是很重要的。如果未调用脚本，服务器将执行本文档中指定的“默认”操作。这允许应用程序设计者在计算资源上权衡灵活性。与智能网络（IN）类似，脚本能够为其未来的执行定义触发器。
So, in summary, whereas an HTTP CGI script executes once during a transaction, a single SIP CGI script may execute many times during a transaction, and may specify at which points it would like to have control for the remainder of the transaction.
因此，总之，虽然HTTP CGI脚本在事务期间执行一次，但单个SIP CGI脚本在事务期间可能执行多次，并可能指定它希望在哪些点控制事务的其余部分。
In HTTP CGI, the CGI script itself is generally the resource named in the request URI of the HTTP request. This is not so in SIP. In general, the request URI names a user to be called. The mapping to a script to be executed may depend on other SIP headers, including To and From fields, the SIP method, status codes, and reason phrases. As such, the mapping of a message to a CGI script is purely a matter of local policy administration at a server. A server may have a single script which always executes, or it may have multiple scripts, and the target is selected by some parts of the header.
在HTTP CGI中，CGI脚本本身通常是HTTP请求的请求URI中命名的资源。在SIP中并非如此。通常，请求URI指定要调用的用户。到要执行的脚本的映射可能取决于其他SIP头，包括to和From字段、SIP方法、状态代码和原因短语。因此，将消息映射到CGI脚本纯粹是服务器上本地策略管理的问题。服务器可能有一个始终执行的脚本，也可能有多个脚本，并且目标由标头的某些部分选择。
In HTTP CGI, environment variables are set with the values of the paths and other aspects of the request. As there is no notion of a path in SIP, some of these environment variables do not make sense.
在HTTP CGI中，环境变量由路径值和请求的其他方面设置。由于SIP中没有路径的概念，这些环境变量中的一些没有意义。
In SIP, certain services require that the script gets called not only when a message arrives, but when some timer expires. The classic example of this is "call forward no answer." To be implemented with SIP CGI, the first time the script is executed, it must generate a proxied request, and also indicate a time at which to be called again if no response comes. This kind of feature is not present in HTTP CGI, and some rudimentary support for it is needed in SIP CGI.
在SIP中，某些服务不仅要求在消息到达时调用脚本，而且要求在某些计时器过期时调用脚本。这方面的经典示例是“呼叫转发无应答”。要使用SIP CGI实现，第一次执行脚本时，它必须生成一个代理请求，并且还指示在没有响应时再次调用的时间。这种特性在HTTP CGI中不存在，在SIP CGI中需要对其进行一些基本的支持。
4 Overview of SIP CGI
4 SIP CGI概述
When a request arrives at a SIP server, initiating a new transaction, the server will set a number of environment variables, and call a CGI script. The script is passed the body of the request through stdin.
当一个请求到达SIP服务器，启动一个新的事务时，服务器将设置许多环境变量，并调用一个CGI脚本。脚本通过stdin传递给请求主体。
The script returns, on stdout, a set of SIP action lines, each of which may be modified by CGI and/or SIP headers. This set is delimited through the use of two carriage returns. The action lines allow the script to specify any of the four operations defined above, in addition to the default operation. Generating a response is done by copying the the status line of the response into an action line of the CGI output. For example, the following will create a 200 OK to the original request:
脚本在stdout上返回一组SIP操作行，每个操作行都可以由CGI和/或SIP头修改。此集合通过使用两个回车分隔。除了默认操作之外，操作行允许脚本指定上面定义的四个操作中的任何一个。生成响应是通过将响应的状态行复制到CGI输出的操作行来完成的。例如，以下内容将为原始请求创建200 OK：
SIP/2.0 200 OK
SIP/2.0 200正常
The operation of proxying a request is supported by the CGI-PROXY-REQUEST CGI action, which takes the URL to proxy to as an argument. For example, to proxy a request to dante@inferno.com:
代理请求的操作由CGI-PROXY-request CGI操作支持，该操作将代理到的URL作为参数。例如，将请求代理给dante@inferno.com:
CGI-PROXY-REQUEST sip:dante@inferno.com SIP/2.0
Contact: sip:server1@company.com
CGI-PROXY-REQUEST sip:dante@inferno.com SIP/2.0
Contact: sip:server1@company.com
In this example, the server will take the original request, and modify any header fields normally changed during the proxy operation (such as decrementing Max-Forwards, and adding a Via field). This message is then "merged" with the output of the CGI script - SIP headers specified below the action line in the CGI output will be added to the outbound request. In the above example, the Contact header will be added. Note that the action line looks like the request line of a SIP request message. This is done in order to simplify parsing.
在本例中，服务器将接受原始请求，并修改在代理操作期间通常更改的任何头字段（例如减少最大转发，并添加一个Via字段）。然后，此消息与CGI脚本的输出“合并”——CGI输出中操作行下方指定的SIP头将添加到出站请求中。在上面的示例中，将添加联系人标题。注意，操作行看起来像SIP请求消息的请求行。这样做是为了简化解析。
To delete headers from the outgoing request, the merge process also supports the CGI header CGI-Remove. Like SIP headers, CGI headers are written underneath the action line. They are extracted by the SIP server, and used to provide the server with additional guidance.
要从传出请求中删除头，合并进程还支持CGI头CGI Remove。与SIP头一样，CGI头也写在操作行下面。它们由SIP服务器提取，并用于向服务器提供附加指导。
CGI headers always begin with CGI to differentiate them from SIP headers. In this case, the supported values for the CGI-Remove header are the names of headers in the original message.
CGI头总是以CGI开头，以区别于SIP头。在这种情况下，CGI Remove头支持的值是原始消息中头的名称。
Returning of responses is more complex. A server may receive multiple responses as the result of forking a request. The script should be able to ask the server to return any of the responses it had received previously. To support this, the server will pass an opaque token to the script through environment variables, unique for each response received. To return a response, a CGI script needs to indicate which response is to be returned. For example, to return a response named with the token abcdefghij, the following output is generated:
回复的返回更加复杂。作为请求分叉的结果，服务器可能会收到多个响应。脚本应该能够要求服务器返回它以前收到的任何响应。为了支持这一点，服务器将通过环境变量向脚本传递一个不透明令牌，该环境变量对于接收到的每个响应都是唯一的。要返回响应，CGI脚本需要指示要返回的响应。例如，要返回名为abcdefghij的响应，将生成以下输出：
CGI-FORWARD-RESPONSE abcdefghij SIP/2.0
CGI前向响应abcdefghij SIP/2.0
Finally, if the script does not output any of the above actions, the server does what it would normally do upon receiving the message that triggered the script.
最后，如果脚本没有输出上述任何操作，服务器将执行它在收到触发脚本的消息时通常会执行的操作。
A SIP CGI script is normally only executed when the original request arrives. If the script also wants to be called for subsequent messages in a transaction -- due to responses to proxied requests, or (in certain circumstances) ACK and CANCEL requests, it can perform the CGI-AGAIN action:
SIP CGI脚本通常仅在原始请求到达时执行。如果由于对代理请求的响应，或者（在某些情况下）ACK和CANCEL请求，脚本还希望为事务中的后续消息调用，则它可以执行CGI-REACH操作：
CGI-AGAIN yes SIP/2.0
CGI-再次是SIP/2.0
This action applies only to the next invocation of the script; it means to invoke the script one more time. Outputting "no" is identical to outputting "yes" on this invocation of the script and outputting nothing the next time the script is called.
此操作仅适用于脚本的下一次调用；这意味着再次调用脚本。输出“no”与在调用脚本时输出“yes”相同，在下次调用脚本时不输出任何内容。
When the script is re-executed, it may need access to some state in order to continue processing. A script can generate one piece of state, called a cookie, for any new request or proxied request. It is passed to the server through the CGI-SET-COOKIE action. The action contains a token, which is the cookie itself. The server does not examine or parse the cookie. It is simply stored. When the script is re-executed, the cookie is passed back to the script through an environment variable.
重新执行脚本时，可能需要访问某些状态才能继续处理。脚本可以为任何新请求或代理请求生成一段状态，称为cookie。它通过CGI-SET-COOKIE操作传递给服务器。该操作包含一个令牌，即cookie本身。服务器不检查或分析cookie。它只是简单地存储。重新执行脚本时，cookie通过环境变量传递回脚本。
CGI-SET-COOKIE khsihppii8asdl SIP/2.0
CGI-SET-COOKIE khsihppii8asdl SIP/2.0
Finally, when the script causes the server to proxy a request, responses to these requests will arrive. To ease matching of responses to requests, the script can place a request token in the CGI CGI-Request-Token header. This header is removed by the server
最后，当脚本使服务器代理一个请求时，将收到对这些请求的响应。为了简化响应与请求的匹配，脚本可以在CGI CGI请求令牌头中放置请求令牌。此标头已被服务器删除
when the request is proxied. Any responses received to this request will have the token passed in an environment variable.
当请求被代理时。接收到此请求的任何响应都将在环境变量中传递令牌。
5 SIP CGI Specification
5 SIP CGI规范
This SIP CGI specification is based on work-in-progress revision 1.1 of the HTTP CGI specification [1]. That document is a product of the CGI-WG mailing list, which is not an official IETF working group. CGI-WG's homepage is located at the URL http://Web.Golux.Com/coar/cgi/, and the most recent versions of the CGI specification are available there. This specification incorporates a great deal of text from the work-in-progress version of that document as of February 23, 2000. A future version of this specification may be changed to cite parts of that document by reference instead.
本SIP CGI规范基于HTTP CGI规范[1]的在制品版本1.1。该文件是CGI-WG邮件列表的产物，该邮件列表不是IETF的正式工作组。CGI-WG的主页位于URLhttp://Web.Golux.Com/coar/cgi/，并且可以在那里获得CGI规范的最新版本。本规范包含了自2000年2月23日起该文件正在进行的版本中的大量文本。本规范的未来版本可能会更改为引用该文件的部分内容。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP CGI implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[4]中的描述进行解释，并表示符合SIP CGI实施的要求级别。
Some paragraphs are indented, like this; they give motivations of design choices, or questions for future discussion in the development of SIP CGI. They are not normative to the specification of the protocol.
有些段落缩进，如下所示；它们给出了设计选择的动机，或在开发SIP CGI时供将来讨论的问题。它们不符合议定书的规范。
Not all of the functions and features of SIP CGI are defined in the main part of this specification. The following phrases are used to describe the features which are not specified:
本规范的主要部分并未定义SIP CGI的所有功能和特性。以下短语用于描述未指定的功能：
System-defined: The feature may differ between systems, but must be the same for different implementations using the same system. A system will usually identify a class of operating systems. Some systems are defined in section 6 of this document. New systems may be defined by new specifications without revision of this document.
系统定义：不同系统之间的功能可能不同，但对于使用同一系统的不同实现，功能必须相同。系统通常会识别一类操作系统。本文件第6节定义了一些系统。新系统可由新规范定义，无需修订本文件。
Implementation-defined: The behavior of the feature may vary from implementation to implementation, but a particular implementation should be consistent in its behavior.
实现定义：功能的行为可能因实现而异，但特定实现的行为应一致。
This specification uses many terms defined in the SIP/2.0 specification [2]; however, the following terms are used here in a sense which may not accord with their definitions in that document, or with their common meaning.
本规范使用了SIP/2.0规范[2]中定义的许多术语；然而，此处使用的下列术语可能与该文件中的定义或其共同含义不一致。
metavariable: A named parameter that carries information from the server to the script. It is not necessarily a variable in the operating system's environment, although that is the most common implementation.
元变量：将信息从服务器传送到脚本的命名参数。它不一定是操作系统环境中的变量，尽管这是最常见的实现。
script: The software which is invoked by the server via this interface. It need not be a standalone program, but could be a dynamically-loaded or shared library, or even a subroutine in the server. It may be a set of statements interpreted at run-time, as the term `script' is frequently understood, but that is not a requirement and within the context of this specification the term has the broader definition stated.
脚本：服务器通过此接口调用的软件。它不需要是一个独立的程序，但可以是一个动态加载的或共享的库，甚至可以是服务器中的一个子例程。它可能是在运行时解释的一组语句，因为术语“脚本”经常被理解，但这不是一项要求，在本规范的上下文中，术语具有更广泛的定义。
server: The application program which invokes the script in order to service messages.
服务器：调用脚本以服务消息的应用程序。
message: A SIP request or response, typically either the one that triggered the invocation of the CGI script, or one that the CGI script caused to be sent.
消息：SIP请求或响应，通常是触发CGI脚本调用的请求或响应，或者是CGI脚本导致发送的请求或响应。
In this specification we use the Augmented Backus-Naur Form notation as described in appendix C of the SIP/2.0 specification, RFC 2543 [2].
在本规范中，我们使用SIP/2.0规范RFC 2543[2]附录C中所述的扩充巴科斯诺尔形式符号。
The following grammatical constructs are taken from other documents; this table lists the appropriate sources.
以下语法结构取自其他文件；此表列出了适当的来源。
OCTET SIP/2.0 [2] Appendix C.1 CHAR SIP/2.0 [2] Appendix C.1 digit SIP/2.0 [2] Appendix C.1 alphanum SIP/2.0 [2] Appendix C.1 token SIP/2.0 [2] Appendix C.1 hostname SIP/2.0 [2] Section 2 SIP-URL SIP/2.0 [2] Section 2 SIP-Version SIP/2.0 [2] Section 4.3.1 Status-Code SIP/2.0 [2] Section 5.1.1 Reason-Phrase SIP/2.0 [2] Section 5.1.1 media-type HTTP/1.1 [5] Section 3.7
八位字节SIP/2.0[2]附录C.1字符SIP/2.0[2]附录C.1数字SIP/2.0[2]附录C.1字母SIP/2.0[2]附录C.1令牌SIP/2.0[2]附录C.1主机名SIP/2.0[2]第2节SIP-URL SIP/2.0[2]第2节SIP版本SIP/2.0[2]第4.3.1节状态代码SIP/2.0[2]第5.1.1节原因短语SIP/2.0[2]第5.1.1节媒体类型HTTP/1.1[5]第3.7节
(via SIP/2.0 [2] Section 6.16) field-name SIP/2.0 [2] Section 6.6
（通过SIP/2.0[2]第6.16节）字段名SIP/2.0[2]第6.6节
Other grammatical constructs taken from outside sources are noted in the text.
其他来自外部来源的语法结构在文本中有所说明。
The script is invoked in a system-defined manner. Unless specified otherwise, the file containing the script will be invoked as an executable program.
脚本是以系统定义的方式调用的。除非另有规定，否则包含脚本的文件将作为可执行程序调用。
Only one CGI script at a time may be outstanding for a SIP transaction. If subsequently arriving responses would cause a CGI script to be invoked, handling of them is deferred, except for ACK, until CGI scripts for previous messages in the transaction terminate. Messages are processed in the order they are received.
对于SIP事务，一次只能有一个CGI脚本未完成。如果随后到达的响应将导致调用CGI脚本，则对它们的处理将延迟（ACK除外），直到事务中先前消息的CGI脚本终止。消息按接收顺序进行处理。
The server SHOULD NOT provide any command line arguments to the script.
服务器不应向脚本提供任何命令行参数。
Command line arguments are used for indexed queries in HTTP CGI; HTTP indexed queries do not have an equivalent in SIP.
命令行参数用于HTTP CGI中的索引查询；HTTP索引查询在SIP中没有等效项。
Information about a message comes from two different sources: the message header, and any associated content-body. Servers MUST make portions of this information available to scripts.
有关消息的信息来自两个不同的来源：消息头和任何关联的内容体。服务器必须使部分信息可供脚本使用。
Each SIP CGI server implementation MUST define a mechanism to pass data about the message from the server to the script. The metavariables containing these data are accessed by the script in a system-defined manner. The representation of the characters in the metavariables is system-defined.
每个SIP CGI服务器实现都必须定义一种机制，将有关消息的数据从服务器传递到脚本。脚本以系统定义的方式访问包含这些数据的元变量。元变量中字符的表示是系统定义的。
The representation of metavariables MUST distinguish between undefined values (which are not present) and null values (which are present, but have zero length). Null values are only allowed for those metavariables whose grammar permits this.
元变量的表示必须区分未定义的值（不存在）和空值（存在但长度为零）。只有语法允许的元变量才允许空值。
For historical reasons, HTTP CGI does not distinguish between null values and undefined values. This specification eliminates this misfeature; null values and undefined values are semantically different.
由于历史原因，HTTP CGI不区分空值和未定义值。本规范消除了这种缺陷；空值和未定义的值在语义上是不同的。
Case is not significant in the metavariable names, in that there cannot be two different variables whose names differ in case only. Here they are shown using a canonical representation of capitals plus underscore ("_"). The actual representation of the names is system defined; for a particular system the representation MAY be defined differently than this.
在元变量名称中，大小写并不重要，因为不能有两个名称仅大小写不同的不同变量。在这里，它们使用大写字母加下划线（“\ux”）的规范表示法显示。名称的实际表示形式由系统定义；对于特定系统，表示的定义可能与此不同。
Metavariable values MUST be considered case-sensitive except as noted otherwise.
元变量值必须视为区分大小写，除非另有说明。
The canonical metavariables defined by this specification are:
本规范定义的规范元变量为：
AUTH_TYPE CONTENT_LENGTH CONTENT_TYPE GATEWAY_INTERFACE REMOTE_ADDR REMOTE_HOST REMOTE_IDENT REMOTE_USER REGISTRATIONS REQUEST_METHOD REQUEST_TOKEN REQUEST_URI RESPONSE_STATUS RESPONSE_REASON RESPONSE_TOKEN SCRIPT_COOKIE SERVER_NAME SERVER_PORT SERVER_PROTOCOL SERVER_SOFTWARE
身份验证类型内容长度内容类型网关接口远程地址远程主机远程身份远程用户注册请求方法请求令牌请求URI响应状态响应原因响应令牌脚本COOKIE服务器名称服务器端口服务器协议服务器软件
Metavariables with names beginning with the protocol name (e.g., "SIP_ACCEPT") are also canonical in their description of message header fields. The number and meaning of these fields may change independently of this specification. (See also section 5.5.1.5.)
名称以协议名称开头的元变量（例如，“SIP_ACCEPT”）在其消息头字段的描述中也是规范的。这些字段的数量和含义可能独立于本规范而改变。（另见第5.5.1.5节。）
A server MAY also specify additional non-canonical metavariables.
服务器还可以指定其他非规范元变量。
If the target of the message required access authentication for external access, then the server MUST set the value of this variable from the auth-scheme token in the message's Authorization header field. Otherwise it is not defined.
如果消息的目标需要外部访问的访问身份验证，则服务器必须从消息的Authorization header字段中的auth scheme令牌设置此变量的值。否则就没有定义。
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | "PGP" | token
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | "PGP" | token
SIP access authentication schemes are described in sections 14 and 15 of the SIP/2.0 specification [2]. The auth-scheme is not case-sensitive.
SIP访问认证方案在SIP/2.0规范[2]的第14节和第15节中进行了描述。身份验证方案不区分大小写。
Servers MUST provide this metavariable to scripts if the message header included an Authorization field that was authenticated.
如果消息头包含经过身份验证的授权字段，则服务器必须向脚本提供此元变量。
For the complex authentication schemes, the server SHOULD perform the authentication checking itself. If the authentication failed, this metavariable SHOULD NOT be set.
对于复杂的身份验证方案，服务器应该自己执行身份验证检查。如果身份验证失败，则不应设置此元变量。
If several authentication credentials, with multiple schemes, are present in the message, this variable SHOULD be set to correspond to the authenticated credentials with the strongest scheme the server supports. If credentials are present for several domains, the server SHOULD NOT perform any action on credentials from domains external to it.
如果消息中存在多个具有多个方案的身份验证凭据，则应将此变量设置为与具有服务器支持的最强方案的身份验证凭据相对应。如果存在多个域的凭据，则服务器不应对来自其外部域的凭据执行任何操作。
If both Authorization and Proxy-Authorization headers are present, the server SHOULD perform the authorizations based on the appropriate header for the context in which it is running. For example, a server which is a proxy server and a registrar would use Authorization headers for REGISTER messages aimed at its local domains, and Proxy-Authorization headers for all other messages.
如果同时存在授权头和代理授权头，则服务器应根据其运行的上下文的相应头执行授权。例如，作为代理服务器和注册器的服务器将对针对其本地域的注册消息使用授权头，对所有其他消息使用代理授权头。
This metavariable is set to the size of the message-body entity attached to the message, if any, in decimal number of octets. If no data are attached, then this metavariable is not defined. The syntax is the same as for the SIP Content-Length header field (section 6.15, SIP/2.0 specification [2]).
此元变量设置为附加到消息的消息体实体的大小（如果有），以十进制八位字节数为单位。如果未附加任何数据，则未定义此元变量。语法与SIP内容长度头字段相同（第6.15节，SIP/2.0规范[2]）。
CONTENT_LENGTH = "" | 1*digit
CONTENT_LENGTH=”“| 1*位
Servers MUST provide this metavariable to scripts if the message was a accompanied by a content-body entity, even if the message did not include a Content-Length header field.
如果消息带有内容主体实体，则服务器必须向脚本提供此元变量，即使消息未包含内容长度头字段。
If the message includes a message-body, CONTENT_TYPE is set to the Internet Media Type [6] of the attached entity if the type was provided via a Content-type field in the message header, or if the server can determine it in the absence of a supplied Content-type field. The syntax is the same as for the SIP Content-Type header field.
如果消息包含消息正文，如果类型是通过消息头中的内容类型字段提供的，或者如果服务器可以在没有提供的内容类型字段的情况下确定，则内容类型将设置为所附实体的Internet媒体类型[6]。语法与SIP内容类型标头字段的语法相同。
CONTENT_TYPE = "" | media-type
内容类型=“媒体类型”
The type, subtype, and parameter attribute names are not case-sensitive. Parameter values MAY be case sensitive. Media types and their use in SIP are described in section 6.16 of the SIP/2.0 specification [2], and by reference in section 3.7 of the HTTP/1.1 specification [5].
类型、子类型和参数属性名称不区分大小写。参数值可能区分大小写。SIP/2.0规范[2]第6.16节和HTTP/1.1规范[5]第3.7节对媒体类型及其在SIP中的使用进行了描述。
Since in SIP the Content-Type header MUST be specified if a body is present, servers MUST provide this metavariable to scripts if a body was present in the original message, unless the "body" is actually an encrypted payload.
由于在SIP中，如果存在正文，则必须指定内容类型标头，因此如果原始消息中存在正文，则服务器必须向脚本提供此元变量，除非“正文”实际上是加密的有效负载。
This metavariable is set to the dialect of SIP CGI being used by the server to communicate with the script. Syntax:
此元变量设置为服务器用于与脚本通信的SIP CGI方言。语法：
GATEWAY_INTERFACE = "SIP-CGI" "/" major "." minor
major = 1*digit
minor = 1*digit
GATEWAY_INTERFACE = "SIP-CGI" "/" major "." minor
major = 1*digit
minor = 1*digit
Note that the major and minor numbers are treated as separate integers and hence each may be more than a single digit. Thus SIP-CGI/2.4 is a lower version than SIP-CGI/2.13 which in turn is lower than SIP-CGI/12.3. Leading zeros in either the major or the minor number MUST be ignored by scripts and SHOULD NOT be generated by servers.
请注意，主要数字和次要数字被视为单独的整数，因此每个数字可能超过一个位数。因此，SIP-CGI/2.4的版本低于SIP-CGI/2.13，而SIP-CGI/2.13又低于SIP-CGI/12.3。脚本必须忽略主数字或次数字中的前导零，服务器不应生成前导零。
This document defines the 1.1 version of the SIP CGI interface ("SIP-CGI/1.1").
本文件定义了SIP CGI接口的1.1版本（“SIP-CGI/1.1”）。
Servers MUST provide this metavariable to scripts.
服务器必须向脚本提供此元变量。
For maximal compatibility with existing HTTP CGI libraries, we want to keep this as similar as possible to the syntax of CGI 1.1. However, we do want it to be clear that this is indeed SIP CGI. Making HTTP CGI's version identifier a substring of the SIP CGI identifier seemed like a
为了最大限度地兼容现有的HTTP CGI库，我们希望尽可能保持与CGI 1.1的语法相似。然而，我们确实希望清楚这确实是SIP CGI。将HTTP CGI的版本标识符作为SIP CGI标识符的子字符串似乎是一个很好的选择
reasonable compromise. (The existing CGI libraries we checked do not seem to check the version.)
合理的妥协。（我们检查的现有CGI库似乎没有检查版本。）
These metavariables are specific to the protocol via which the method is sent. Interpretation of these variables depends on the value of the SERVER_PROTOCOL metavariable (see section 5.5.1.20).
这些元变量特定于发送方法的协议。这些变量的解释取决于服务器_协议元变量的值（见第5.5.1.20节）。
Metavariables with names beginning with "SIP_" contain values from the message header, if the protocol used was SIP. Each SIP header field name is converted to upper case, has all occurrences of "-" replaced with "_", and has "SIP_" prepended to form the metavariable name. Similar transformations are applied for other protocols. The header data MAY be presented as sent by the client, or MAY be rewritten in ways which do not change its semantics. If multiple header fields with the same field-name are received then the server MUST rewrite them as though they had been received as a single header field having the same semantics before being represented in a metavariable. Similarly, a header field that is received on more than one line MUST be merged into a single line. The server MUST, if necessary, change the representation of the data (for example, the character set) to be appropriate for a CGI metavariable.
如果使用的协议是SIP，则名称以“SIP_”开头的元变量包含来自消息头的值。每个SIP头字段名都转换为大写，所有出现的“-”都替换为“\u0”，并在前面加上“SIP\u0”以形成元变量名。类似的转换也适用于其他协议。报头数据可以表示为由客户端发送，或者可以以不改变其语义的方式重写。如果接收到具有相同字段名的多个标头字段，则服务器必须重写它们，就像它们在表示为元变量之前已作为具有相同语义的单个标头字段接收一样。类似地，在多行上接收的标题字段必须合并到一行中。如有必要，服务器必须更改数据的表示形式（例如，字符集）以适合CGI元变量。
Note: these metavariables' names were changed from HTTP_* to SIP_* since the first draft of this specification. The intention had been to make it easier to use existing CGI libraries unmodified, but this convenience was felt to be outweighed by the confusion this introduced.
注意：自本规范初稿以来，这些元变量的名称已从HTTP_*更改为SIP_*。其目的是使未经修改的现有CGI库更易于使用，但这种方便被引入的混乱所抵消。
Servers are not required to create metavariables for all the message header fields they receive. However, because of the relatively high importance of headers in SIP for messages' semantic content, the server SHOULD provide all headers which do not contain potentially sensitive authorization information, such as Authorization. Servers SHOULD provide protocol-specific metavariables even for information which is available through other SIP CGI metavariables, such as CONTENT_LENGTH and CONTENT_TYPE.
服务器不需要为其接收的所有消息头字段创建元变量。然而，由于SIP中的头对于消息语义内容的重要性相对较高，服务器应该提供不包含潜在敏感授权信息（如授权）的所有头。服务器应提供特定于协议的元变量，即使对于通过其他SIP CGI元变量（如内容长度和内容类型）可用的信息也是如此。
This allows a SIP CGI script to determine, if necessary, whether the information in the other metavariables was in the original message, or was synthesized by the server.
这允许SIP CGI脚本在必要时确定其他元变量中的信息是在原始消息中还是由服务器合成的。
This metavariable contains a list the current locations the server has registered for the user in the Request-URI of the initial request of a transaction. It is syntactically identical to the protocol
此元变量包含服务器在事务初始请求的请求URI中为用户注册的当前位置的列表。它在语法上与协议相同
metavariable SIP_CONTACT, and thus is defined by section 5.5.1.5 of this document and by section 6.13 of the SIP/2.0 specification [2]. It contains all the uris, uri parameters, display names, and contact parameters for the addresses registered with the server.
元变量SIP_触点，因此由本文件第5.5.1.5节和SIP/2.0规范第6.13节定义[2]。它包含在服务器上注册的地址的所有uri、uri参数、显示名称和联系人参数。
The syntax of REGISTRATIONS is identical to how SIP_CONTACT would appear in a 302 response from a redirection server. This allows parsing code to be re-used.
注册的语法与来自重定向服务器的302响应中SIP_联系人的显示方式相同。这允许重新使用解析代码。
If a user's registrations change in the course of a transaction, the server SHOULD update this metavariable accordingly for subsequent script invocations for the transaction.
如果用户的注册在事务过程中发生更改，则服务器应相应地更新此元变量，以用于事务的后续脚本调用。
The IP address of the client that sent the message to the server. This is not necessarily that of the originating user agent client or server.
向服务器发送消息的客户端的IP地址。这不一定是原始用户代理客户端或服务器的情况。
REMOTE_ADDR = hostnumber hostnumber = IPv4address | IPv6address
远程地址=主机号主机号=IPv4address | IPV6地址
The definitions of IPv4address and Ipv6address are provided in Appendix B of RFC 2373 [7].
RFC 2373[7]附录B中提供了IPv4address和Ipv6address的定义。
For locally-generated responses (see section 5.8), this SHOULD be the loopback address (i.e., 127.0.0.1 for IPv4 or ::1 for IPv6).
对于本地生成的响应（请参见第5.8节），这应该是环回地址（即，对于IPv4为127.0.0.1，对于IPv6为：：1）。
Servers MUST supply this value to scripts.
服务器必须向脚本提供此值。
This is the fully qualified domain name of the host sending the message to this server, if available, otherwise not defined. (See section 5.5.1.7). Domain names are not case sensitive.
这是将消息发送到此服务器的主机的完全限定域名（如果可用），否则未定义。（见第5.5.1.7节）。域名不区分大小写。
REMOTE_HOST = hostname
REMOTE_HOST = hostname
Servers SHOULD provide this information to scripts.
服务器应向脚本提供此信息。
The identity information supported about the connection by a RFC 1413 [8] request, if available.
RFC 1413[8]请求支持的有关连接的标识信息（如果可用）。
REMOTE_IDENT = *CHAR
REMOTE_IDENT = *CHAR
The server MAY choose not to support this feature, and it is anticipated that not many implementations will, as the information is not particularly useful in the presence of complex proxy paths.
服务器可能会选择不支持此功能，并且预计不会有很多实现支持此功能，因为在存在复杂代理路径的情况下，信息不是特别有用。
If the message requested authentication (i.e., the AUTH_TYPE metavariable is set), then the value of the REMOTE_USER metavariable is set to the user-ID supplied for the authentication. For Basic authentication this is the content of the (decoded) "userid" grammar element; for Digest it is content of "username-value." For PGP authentication, it is the URI specified in the "signed-by" parameter of the Authorization header, if present, otherwise the URI part of the From header.
如果消息请求了身份验证（即设置了AUTH_类型元变量），则远程_用户元变量的值将设置为为为身份验证提供的用户ID。对于基本身份验证，这是（解码的）“userid”语法元素的内容；对于摘要，它是“username value”的内容。对于PGP身份验证，它是授权标头的“signed by”参数中指定的URI（如果存在），否则是From标头的URI部分。
If some other authentication scheme was requested, this metavariable SHOULD be set to an appropriate component of the authorization information identifying the user or entity associated with the credentials. If authentication was not requested, this metavariable is not defined.
如果请求了其他身份验证方案，则应将此元变量设置为授权信息的适当组件，以标识与凭据关联的用户或实体。如果未请求身份验证，则未定义此元变量。
REMOTE_USER = *OCTET
REMOTE_USER = *OCTET
Servers SHOULD provide this metavariable to scripts.
服务器应向脚本提供此元变量。
If the message triggering the script was a request, the REQUEST_METHOD metavariable is set to the method with which the request was made, as described in section 4.2 of the SIP/2.0 specification [2]; otherwise not defined.
如果触发脚本的消息是请求，则request_METHOD元变量设置为发出请求的方法，如SIP/2.0规范[2]第4.2节所述；否则未定义。
REQUEST_METHOD = sip-method
sip-method = "INVITE" | "BYE" | "OPTIONS" | "CANCEL"
| "REGISTER" | "ACK"
| extension-method
extension-method = token
REQUEST_METHOD = sip-method
sip-method = "INVITE" | "BYE" | "OPTIONS" | "CANCEL"
| "REGISTER" | "ACK"
| extension-method
extension-method = token
Note that ACK is usually not appropriate for the SIP CGI 1.1 environment; however, see section 5.11. The implications of REGISTER in the CGI context are discussed in section 5.9, and CANCEL is discussed in section 5.10. A SIP CGI 1.1 server MAY choose to process some methods directly rather than passing them to scripts.
注意，ACK通常不适用于SIP CGI 1.1环境；但是，请参见第5.11节。第5.9节讨论了CGI上下文中注册的含义，第5.10节讨论了取消。SIPCGI1.1服务器可以选择直接处理某些方法，而不是将它们传递给脚本。
Servers MUST provide this metavariable to scripts if the triggering message was a request.
如果触发消息是请求，则服务器必须向脚本提供此元变量。
REQUEST_TOKEN = token
REQUEST_TOKEN = token
If the script specified a request token in a proxied request, this token is returned to the server in responses to that request. Note that this token is chosen by the script, not by the server. Each response to a proxied request contains the same value for this token.
如果脚本在代理请求中指定了请求令牌，则该令牌将返回到服务器以响应该请求。请注意，此令牌由脚本选择，而不是由服务器选择。对代理请求的每个响应都包含此令牌的相同值。
This metavariable is specific to requests made with SIP.
此元变量特定于使用SIP发出的请求。
REQUEST_URI = absoluteURI ; defined in RFC 2396 [9]
请求_URI=绝对URI；在RFC 2396[9]中定义
If the message triggering the script was a request, this variable indicates the URI specified with the request method. This metavariable is only defined if REQUEST_METHOD is defined; in that case, servers MUST provide it to scripts.
如果触发脚本的消息是一个请求，则此变量表示使用请求方法指定的URI。仅当定义了请求_方法时，才定义此元变量；在这种情况下，服务器必须将其提供给脚本。
This metavariable fills the roles of HTTP CGI's SCRIPT_NAME, PATH_INFO, and QUERY_STRING.
此元变量填充HTTP CGI的脚本名称、路径信息和查询字符串的角色。
RESPONSE_STATUS = Status-Code
RESPONSE_STATUS = Status-Code
If the message triggering the script was a response, this variable indicates the numeric code specified in the response; otherwise it is not defined. In the former case, servers MUST provide this metavariable to scripts.
如果触发脚本的消息是响应，则此变量表示响应中指定的数字代码；否则就没有定义。在前一种情况下，服务器必须向脚本提供此元变量。
RESPONSE_REASON = Reason-Phrase
RESPONSE_REASON = Reason-Phrase
If the message triggering the script was a response, this variable indicates the textual string specified in the response.
如果触发脚本的消息是响应，则此变量表示响应中指定的文本字符串。
RESPONSE_TOKEN = token
RESPONSE_TOKEN = token
If the message triggering the script was a response, the server MUST specify a token which subsequent invocations of the CGI script can use to identify this response. This string is chosen by the server and is opaque to the CGI script. See the discussion of CGI-FORWARD-RESPONSE in section 5.6.1 below.
如果触发脚本的消息是一个响应，则服务器必须指定一个令牌，CGI脚本的后续调用可以使用该令牌来标识该响应。此字符串由服务器选择，对CGI脚本不透明。见下文第5.6.1节中关于CGI正向响应的讨论。
SCRIPT_COOKIE = token
SCRIPT_COOKIE = token
This is the value an earlier invocation of this script for this transaction passed to the server in CGI action line CGI-SET-COOKIE. See the description of that action in section 5.6.1.4 below.
这是在CGI操作行CGI-SET-COOKIE中传递给服务器的用于此事务的早期脚本调用的值。见下文第5.6.1.4节中对该行动的描述。
The SERVER_NAME metavariable is set to the name of the server.
服务器名称元变量设置为服务器的名称。
SERVER_NAME = hostname | hostnumber
服务器名称=主机名|主机号
Servers MUST provide this metavariable to scripts.
服务器必须向脚本提供此元变量。
The SERVER_PORT metavariable is set to the port on which the message was received.
服务器端口元变量设置为接收消息的端口。
SERVER_PORT = 1*digit
SERVER_PORT = 1*digit
Servers MUST provide this metavariable to scripts.
服务器必须向脚本提供此元变量。
The SERVER_PROTOCOL metavariable is set to the name and revision of the protocol with which the message arrived. This will usually be "SIP/2.0". This is not necessarily the same as the protocol version used by the server in its response to the client.
SERVER_PROTOCOL元变量设置为消息到达的协议的名称和版本。这通常是“SIP/2.0”。这不一定与服务器在响应客户端时使用的协议版本相同。
SERVER_PROTOCOL = SIP-Version | extension-version
| extension-token
extension-version = protocol "/" 1*digit "." 1*digit
protocol = 1*( alphanum | "+" | "-" | "." )
extension-token = token
SERVER_PROTOCOL = SIP-Version | extension-version
| extension-token
extension-version = protocol "/" 1*digit "." 1*digit
protocol = 1*( alphanum | "+" | "-" | "." )
extension-token = token
Servers MUST provide this metavariable to scripts.
服务器必须向脚本提供此元变量。
The SERVER_SOFTWARE metavariable is set to the name and version of the information server software handling the message (and running the gateway).
SERVER_软件元变量设置为处理消息（并运行网关）的信息服务器软件的名称和版本。
SERVER_SOFTWARE = 1*product
product = token [ "/" product-version ]
product-version = token
SERVER_SOFTWARE = 1*product
product = token [ "/" product-version ]
product-version = token
Servers MUST provide this metavariable to scripts.
服务器必须向脚本提供此元变量。
As there may be a data entity attached to the message, there MUST be a system-defined method for the script to read these data. Unless defined otherwise, this will be via the `standard input' file descriptor.
由于可能有一个数据实体附加到消息，因此必须有一个系统定义的方法供脚本读取这些数据。除非另有定义，否则这将通过“标准输入”文件描述符进行。
If the metavariable CONTENT_LENGTH (see section 5.5.1.2) is defined, the server MUST supply at least that many bytes to scripts on the standard input stream. Scripts are not obliged to read the data. Servers MAY signal an EOF condition after CONTENT_LENGTH bytes have been read, but are not obligated to do so. Therefore, scripts MUST NOT attempt to read more than CONTENT_LENGTH bytes, even if more data are available.
如果定义了元变量CONTENT_LENGTH（参见第5.5.1.2节），服务器必须为标准输入流上的脚本提供至少那么多字节。脚本没有义务读取数据。读取内容长度字节后，服务器可能会发出EOF状态信号，但没有义务这样做。因此，即使有更多数据可用，脚本也不能尝试读取超过内容长度字节的数据。
There MUST be a system-defined method for the script to send data back to the server or client. Unless defined otherwise, this will be via the `standard output' file descriptor.
脚本必须有系统定义的方法才能将数据发送回服务器或客户端。除非另有定义，否则这将通过“标准输出”文件描述符进行。
Servers MAY implement a timeout period within which data must be received from scripts, a maximum number of requests or responses that a particular CGI script can initiate, a maximum total number of requests or responses that can be sent by scripts over the lifetime of a transaction, or any other resource limitations it desires. If a script exceeds one of these limitations, the server MAY terminate the script process and SHOULD abort the transaction with either a `504 Gateway Timed Out' or a `500 Internal Server Error' response.
服务器可以实现一个超时期，在此期间必须从脚本接收数据，特定CGI脚本可以发起的请求或响应的最大数量，在事务的生命周期内脚本可以发送的请求或响应的最大总数，或者它所希望的任何其他资源限制。如果脚本超过这些限制之一，服务器可能会终止脚本进程，并应使用“504网关超时”或“500内部服务器错误”响应中止事务。
A SIP CGI script's output consists of any number of messages, each corresponding to actions which the script is requesting that the server perform. Messages consist of an action line, whose syntax is specific to the type of action, followed by CGI header fields and SIP header fields. Action lines determine the nature of the action performed, and are described in section 5.6.1. CGI header fields pass additional instructions or information to the server, and are described in section 5.6.2.
SIP CGI脚本的输出由任意数量的消息组成，每个消息对应于脚本请求服务器执行的操作。消息由动作行组成，动作行的语法特定于动作类型，后面是CGI头字段和SIP头字段。行动线决定了所执行行动的性质，如第5.6.1节所述。CGI头字段向服务器传递附加指令或信息，如第5.6.2节所述。
A message MUST contain exactly one action line, MAY also contain any number of CGI header fields and SIP header fields, and MAY contain a SIP body.
消息必须只包含一个操作行，还可以包含任意数量的CGI头字段和SIP头字段，并且可以包含SIP正文。
All header fields (both SIP and CGI) occurring in an output message MUST be specified one per line; SIP CGI 1.1 makes no provision for continuation lines.
输出消息中出现的所有头字段（SIP和CGI）必须每行指定一个；SIP CGI 1.1未规定延续线路。
The generic syntax of CGI header fields is specified in section 5.6.2.
第5.6.2节规定了CGI头字段的通用语法。
A server MAY choose to honor only some of the requests or responses; in particular, it SHOULD NOT accept any responses following a Status message which sends a definitive non-success response.
服务器可以选择只接受部分请求或响应；特别是，它不应接受在发送最终非成功响应的状态消息之后的任何响应。
The messages sent by a script are delimited as follows:
脚本发送的消息分隔如下：
1. A message begins with an action line.
1. 消息以操作行开头。
2. If the message does not contain a Content-Type header field, or if it contains the header field "Content-Length: 0", then it is terminated by a blank line.
2. 如果邮件不包含内容类型标题字段，或包含标题字段“内容长度：0”，则会以空行终止。
3. If the message contains both Content-Type and Content-Length header fields, the message has a body consisting of the Content-Length octets following the blank line below the set. The next message begins after the body (and optionally some number of blank lines). If the script closes its output prematurely, the server SHOULD report a 500-class server error.
3. 如果消息包含内容类型和内容长度标头字段，则该消息具有一个由内容长度八位字节组成的主体，该内容长度在集合下方的空白行之后。下一条消息在正文之后开始（并且可以选择一些空行）。如果脚本过早关闭其输出，服务器应报告500类服务器错误。
4. If the message contains Content-Type but not Content-Length, the message's body similarly begins with the blank line following the set; this body extends until the script closes its output. In this case, this is necessarily the last message the script can send. The server SHOULD insert a Content-Length header containing the amount of data read before the script closed its output.
4. 如果消息包含内容类型但不包含内容长度，则消息的正文类似地从集合后面的空白行开始；此正文将一直延伸到脚本关闭其输出。在这种情况下，这必然是脚本可以发送的最后一条消息。服务器应该插入一个内容长度头，其中包含在脚本关闭其输出之前读取的数据量。
5. If a message contains a non-zero Content-Length but does not contain a Content-Type, it is an error. The server SHOULD report a 500-class server error.
5. 如果消息包含非零内容长度但不包含内容类型，则为错误。服务器应报告500类服务器错误。
The output of a SIP CGI script is intended to be syntactically identical to that of a UDP packet in which multiple requests or responses are sent, so that the same message parser may be used.
SIP CGI脚本的输出在语法上与发送多个请求或响应的UDP数据包的输出相同，因此可以使用相同的消息解析器。
Status = SIP-Version 3*digit SP reason-phrase NL
状态=SIP版本3*数字SP原因短语NL
This action line causes the server to generate a SIP response and relay it upstream towards the client. The server MUST copy the To, From, Call-ID, and CSeq headers from the original request into the response if these headers are not specified in the script output. The server SHOULD copy any other headers from the request which would normally be copied in the response if these are not specified in the script output.
此操作行使服务器生成SIP响应，并将其向上游中继到客户端。如果脚本输出中未指定To、From、Call ID和CSeq头，则服务器必须将原始请求中的这些头复制到响应中。服务器应该从请求中复制任何其他头，如果脚本输出中未指定这些头，则通常会在响应中复制这些头。
For compatibility with HTTP CGI, a server MAY interpret a message containing a Content-Type header field and no action line as though it contained "SIP/2.0 200 OK". This usage is deprecated.
为了与HTTP CGI兼容，服务器可能会将包含内容类型头字段且没有操作行的消息解释为包含“SIP/2.0 200 OK”。这种用法已被弃用。
Proxy-Request = "CGI-PROXY-REQUEST" SIP-URL SIP-Version
Proxy Request=“CGI-Proxy-Request”SIP-URL SIP版本
This action line causes the server to forward a request to the specified SIP URI. It may be sent either by a script triggered by a request, in which case the triggering request is forwarded; or by a script triggered by a response on a server which is running statefully, in which case the initial request of the transaction is sent.
此操作行导致服务器将请求转发到指定的SIPURI。它可以通过请求触发的脚本发送，在这种情况下，触发请求被转发；或者由服务器上有状态运行的响应触发的脚本，在这种情况下发送事务的初始请求。
Any SIP header field MAY be specified below the action line. Specified SIP headers replace all those in the original message in their entirety; if a script wants to preserve header elements from the original message as well as adding new ones, it can concatenate them by the usual rules of header concatenation, and place the result in the script output. New header fields are added to the message after any Via headers but before any other headers.
可以在操作行下方指定任何SIP头字段。指定的SIP头全部替换原始消息中的所有SIP头；如果脚本希望保留原始消息中的头元素并添加新的头元素，它可以通过头连接的常规规则将它们连接起来，并将结果放入脚本输出中。新的头字段添加到消息的任何Via头之后，但在任何其他头之前。
Any headers from the original request which are not generated by the CGI script are copied into the proxied request, after modifications normally performed by a proxy server. In particular, the server MUST append a Via field and decrement Max-Forwards. A server MAY perform additional modifications as it sees fit, such as adding a Record-Route header. A server SHOULD NOT append these headers if they are specified in the script output.
在通常由代理服务器执行的修改之后，原始请求中未由CGI脚本生成的任何头都会复制到代理请求中。特别是，服务器必须附加一个Via字段并减少Max Forwards。服务器可以根据需要执行其他修改，例如添加记录路由头。如果在脚本输出中指定了这些头，则服务器不应附加这些头。
A script MAY specify that a SIP header is to be deleted from the message by using the CGI-Remove CGI header; see section 5.6.2.
脚本可以指定通过使用CGI-Remove-CGI报头从消息中删除SIP报头；见第5.6.2节。
If the message does not specify a body, the body from the initial request is used. A message with "Content-Length: 0" is specifying an empty body; this causes the body to be deleted from the message.
如果消息未指定正文，则使用初始请求中的正文。“内容长度：0”的消息指定的正文为空；这将导致从邮件中删除正文。
If the original request was authenticated by any means other than `basic,' the script SHOULD NOT add, change, or remove any end-to-end headers, as this would break the authentication.
如果原始请求通过“基本”以外的任何方式进行了身份验证，则脚本不应添加、更改或删除任何端到端头，因为这将破坏身份验证。
Forward-Response = "CGI-FORWARD-RESPONSE" Response-Name SIP-Version Response-Name = response-token | "this"
Forward Response=“CGI-Forward-Response”响应名称SIP版本响应名称=响应令牌|“this”
This action line causes the server to forward a response on to its appropriate final destination. The same rules apply for accompanying SIP headers and message bodies as for CGI-PROXY-REQUEST.
此操作行使服务器将响应转发到其相应的最终目标。与CGI-PROXY-REQUEST相同的规则适用于附带的SIP头和消息体。
The specified response name may either be a response token the server previously submitted in a RESPONSE_TOKEN metavariable, or the string "this." The string "this" may only be sent if the message which triggered this CGI script was a response; it indicates that this triggering response should be forwarded.
指定的响应名称可以是服务器先前在响应令牌元变量中提交的响应令牌，也可以是字符串“this”。只有在触发此CGI脚本的消息是响应时，才能发送字符串“this”；它表示应转发此触发响应。
Script-Cookie = "CGI-SET-COOKIE" token SIP-Version
脚本Cookie=“CGI-SET-Cookie”令牌SIP版本
This action line causes the server to store a script cookie, passed as a token in the action line. Subsequent script invocations for messages within the same transaction carry the token in a meta-header. The script can alter the value of the cookie by subsequent script cookie actions. This alteration will take affect for all subsequent script invocations.
此操作行导致服务器存储脚本cookie，并在操作行中作为令牌传递。同一事务中消息的后续脚本调用在元头中携带令牌。脚本可以通过后续脚本cookie操作更改cookie的值。此更改将对所有后续脚本调用生效。
CGI-Again = "CGI-AGAIN" ("yes" | "no") SIP-Version
CGI-Again = "CGI-AGAIN" ("yes" | "no") SIP-Version
This action line determines whether the script will be invoked for subsequent requests and responses for this transaction. If the parameter "yes" is given to this action, the script will be executed again when the next message arrives. If the parameter is "no," or this action is not specified, the script will not be executed again, and the server will perform its default action for all subsequent messages.
此操作行确定是否为此事务的后续请求和响应调用脚本。如果为该操作提供了参数“yes”，则在下一条消息到达时将再次执行脚本。如果参数为“否”，或者未指定此操作，则不会再次执行脚本，服务器将对所有后续消息执行其默认操作。
If none of the actions CGI-PROXY-REQUEST, CGI-FORWARD-RESPONSE, or a new response are performed -- that is to say, the script outputs only CGI-AGAIN, CGI-SET-COOKIE, or nothing -- the script performs its default action. The default action to take depends on the event which triggered the script:
如果没有执行任何操作CGI-PROXY-REQUEST、CGI-FORWARD-RESPONSE或新响应——也就是说，脚本只输出CGI-REACH、CGI-SET-COOKIE或什么都不输出——脚本将执行其默认操作。要采取的默认操作取决于触发脚本的事件：
Request received: When the request is first received, the default action of the server is to check whether the domain of the server matches the domain of the Request-URI. If it does not, the request is proxied to the request in the Request-URI. Otherwise, the server checks its registration database against the request, and either proxies or redirects the request based on the action specified by the user agent in the registration.
收到的请求：当第一次收到请求时，服务器的默认操作是检查服务器的域是否与请求URI的域匹配。如果没有，则请求将代理到请求URI中的请求。否则，服务器将根据请求检查其注册数据库，并根据用户代理在注册中指定的操作代理或重定向请求。
Proxied response received: If a response is received to a proxied request, the server forwards the response towards the caller if the response was a 200 or 600 class response, and sends a CANCEL on all pending branches. If the response was 100 class, the state machinery for that branch is updated, and the response is proxied upstream towards the caller unless the it was a 100 response, not some other 1xx. For 300, 400, and 500 class responses, an ACK is sent, and the response is forwarded upstream towards the caller if all other branches have terminated, and the response is the best received so far. If not all branches have terminated, the server does nothing. If all branches have terminated, but this response is not the best, the best is forwarded upstream. This is the basic algorithm outlined in the SIP specification.
接收到代理响应：如果接收到对代理请求的响应，则服务器将响应转发给调用方（如果响应是200或600类响应），并在所有挂起的分支上发送取消。如果响应为100类，则更新该分支的状态机制，并将响应代理到调用方的上游，除非它是100类响应，而不是其他1x响应。对于300、400和500类响应，发送ACK，如果所有其他分支都已终止，则响应向上游转发给调用者，并且响应是迄今为止收到的最佳响应。如果不是所有分支都已终止，则服务器不执行任何操作。如果所有分支都已终止，但此响应不是最佳的，则会向上游转发最佳响应。这是SIP规范中概述的基本算法。
CGI header fields syntactically resemble SIP header fields, but their names all begin with the string "CGI-". The SIP server MUST strip all CGI header fields from any message before sending it, including those it does not recognize.
CGI头字段在语法上类似于SIP头字段，但它们的名称都以字符串“CGI-”开头。SIP服务器必须在发送任何消息之前除去所有CGI头字段，包括它无法识别的消息。
CGI header fields have the generic syntax specified in section 6.6 of the SIP/2.0 specification [2]. The field-name is not case sensitive; the field value MUST conform to the grammar of that specific field in the specification where it is defined.
CGI头字段具有SIP/2.0规范[2]第6.6节中规定的通用语法。字段名不区分大小写；字段值必须符合其定义规范中特定字段的语法。
Request-Token = "CGI-Request-Token" ":" token
请求令牌=“CGI请求令牌”“：”令牌
To assist in matching responses to proxied requests, the script can place a CGI-Request-Token CGI header in a CGI-PROXY-REQUEST or new request. This header contains a token, opaque to the server. When a response to this request arrives, the token is passed back to the script as a meta-header.
为了帮助匹配对代理请求的响应，脚本可以在CGI-PROXY-Request或新请求中放置CGI请求令牌CGI头。此标头包含对服务器不透明的令牌。当对该请求的响应到达时，令牌作为元头传递回脚本。
This allows scripts to "fork" a proxy request, and correlate which response corresponds to which branch of the request.
这允许脚本“分叉”代理请求，并关联哪个响应对应于请求的哪个分支。
Remove = "CGI-Remove" ":" 1#field-name
Remove = "CGI-Remove" ":" 1#field-name
The CGI-Remove header allows the script to remove SIP headers from the outgoing request or response. The value of this header is a comma-separated list of SIP headers which should be removed before sending out the message.
CGI Remove头允许脚本从传出请求或响应中删除SIP头。此标头的值是一个以逗号分隔的SIP标头列表，在发送消息之前应将其删除。
A script MAY specify headers which are not in the request; the server SHOULD silently ignore these. A script SHOULD NOT both specify a SIP header in its output and also list that header in a CGI-Remove header; the result of doing this is undefined.
脚本可以指定不在请求中的头；服务器应该默默地忽略这些。脚本不应在其输出中指定SIP头，也不应在CGI移除头中列出该头；这样做的结果是未定义的。
If a CGI script specifies an Expires header field along with CGI-PROXY-REQUEST, the SIP server SHOULD track the expiration timeout locally as well as sending the message to the remote server. When the timeout expires, the server SHOULD generate a "408 Request
如果CGI脚本指定了Expires头字段以及CGI-PROXY-REQUEST，则SIP服务器应在本地跟踪过期超时，并将消息发送到远程服务器。超时过期时，服务器应生成“408”请求
Timeout" response. The timeout response SHOULD be handled as specified in section 5.8. At the time the request is timed out, the server SHOULD also transmit CANCEL messages for the request.
超时”响应。应按照第5.8节的规定处理超时响应。在请求超时时，服务器还应发送请求的取消消息。
This allows a SIP CGI script in a proxy server to implement services like "Call Forward No Answer" to trigger after a user-determined time, even if the remote user-agent server is not responding or does not properly handle the Expires header field.
这允许代理服务器中的SIP CGI脚本在用户确定的时间后实现“呼叫前转无应答”之类的服务，即使远程用户代理服务器没有响应或没有正确处理Expires标头字段。
In a proxy environment, locally-generated responses such as "408 Request Timeout" SHOULD be sent to the CGI script in the same manner as received messages are. However, messages which merely report a problem with a message, such as "400 Bad Request", SHOULD NOT be.
在代理环境中，本地生成的响应（例如“408请求超时”）应以与接收到的消息相同的方式发送到CGI脚本。但是，仅报告消息有问题的消息（例如“400错误请求”）不应被删除。
This is the other half of the requirements for the implementation of the "Call Forward No Answer" service, along with the local handling of the Expires header.
这是实现“呼叫前转无应答”服务的另一半要求，以及Expires报头的本地处理。
The specific semantics of a SIP CGI script which is triggered by a REGISTER request are somewhat different than that of those triggered by call-related requests; however, allowing user control of registration may in some cases be useful. The two specific actions for REGISTER that need to be discussed are the response "200" and the default action. In the former case, the server SHOULD assume that the CGI script is handling the registration internally, and SHOULD NOT add the registration to its internal registration database; in the latter case, the server SHOULD add the registration to its own database. The server also SHOULD NOT add the registration if a 3xx, 4xx, 5xx, or 6xx status was returned, or if the registration request was proxied to another location.
由寄存器请求触发的SIP CGI脚本的特定语义与由呼叫相关请求触发的脚本的特定语义有所不同；然而，允许用户控制注册在某些情况下可能是有用的。需要讨论的寄存器的两个具体操作是响应“200”和默认操作。在前一种情况下，服务器应该假设CGI脚本正在内部处理注册，并且不应该将注册添加到其内部注册数据库中；在后一种情况下，服务器应该将注册添加到自己的数据库中。如果返回3xx、4xx、5xx或6xx状态，或者注册请求被代理到其他位置，则服务器也不应添加注册。
SIP CGI servers SHOULD execute scripts when a CANCEL message is received. The script SHOULD clean up any state it has for the transaction as quickly as possible.
SIP CGI服务器应在收到取消消息时执行脚本。脚本应该尽快清除事务的任何状态。
When a CANCEL is received at a server for an existing transaction, the server SHOULD send a 200 OK response to the cancel and cancel all currently outstanding branches. The transmission of the script on a CANCEL message is purely advisory, and the script SHOULD NOT perform any actions in response to it.
当服务器接收到现有事务的取消时，服务器应向取消发送200 OK响应，并取消所有当前未完成的分支。在CANCEL消息上传输脚本纯粹是建议性的，脚本不应执行任何响应它的操作。
Under normal circumstances, if the server receives an ACK, the script is not re-executed. If the ACK is destined for the proxy (acknowledging a 300, 400, 500, or 600 response), the ACK causes response retransmissions to cease. If the ACK is for a 200 response forwarded from a downstream server, the ACK is proxied downstream.
在正常情况下，如果服务器收到ACK，则不会重新执行脚本。如果ACK的目的地是代理（确认300、400、500或600响应），则ACK导致响应重传停止。如果ACK用于从下游服务器转发的200响应，则ACK被代理到下游。
However, if the script generated its own 200 response to an INVITE request, the script SHOULD be re-executed with the ACK message. This is necessary in cases where the script is causing the proxy to act as a UAS. ACK messages can contain bodies, and would therefore be useful to the script.
但是，如果脚本对INVITE请求生成了自己的200响应，则应使用ACK消息重新执行脚本。在脚本导致代理充当UAS的情况下，这是必要的。ACK消息可以包含正文，因此对脚本很有用。
When the server receives a non-200 final response to an INVITE request, it SHOULD generate an ACK on its own, and not depend on the script to do so. There is no way in SIP CGI 1.1 to override this behavior. However, since the server will not generate an ACK for 200 responses to INVITE, a script causing the server to act as a UAC MUST generate ACK's for them.
当服务器收到对INVITE请求的非200最终响应时，它应该自己生成ACK，而不是依赖脚本来生成ACK。SIP CGI 1.1中没有办法覆盖此行为。但是，由于服务器不会为INVITE的200个响应生成ACK，因此使服务器充当UAC的脚本必须为它们生成ACK。
6 System Specifications
6系统规格
The implementation of SIP CGI on a Unix operating system platform SHOULD use environment variables as the mechanism of providing request metadata to CGI scripts.
在Unix操作系统平台上实现SIP CGI应该使用环境变量作为向CGI脚本提供请求元数据的机制。
For Unix compatible operating systems, the following are defined:
对于Unix兼容的操作系统，定义了以下内容：
Environment variables: These are accessed by the C library routine getenv.
环境变量：这些变量由C库例程getenv访问。
The current working directory: The current working directory for the script SHOULD be set to the directory containing the script.
当前工作目录：脚本的当前工作目录应设置为包含脚本的目录。
Character set: The US-ASCII character set is used for the definition of environment variable names and header field names; the newline (NL) sequence is LF; servers SHOULD also accept CR LF as a newline.
字符集：US-ASCII字符集用于定义环境变量名称和标题字段名称；换行（NL）序列为LF；服务器还应接受CR LF作为换行符。
The implementation of SIP CGI on 32-bit Microsoft Windows system platforms (Windows 95, 98, NT, and 2000) SHOULD use environment variables as the mechanism of providing request metadata to CGI scripts.
在32位Microsoft Windows系统平台（Windows 95、98、NT和2000）上实现SIP CGI应使用环境变量作为向CGI脚本提供请求元数据的机制。
For Microsoft Windows, the following are defined:
对于Microsoft Windows，定义了以下内容：
Environment variables: These are accessed by the C library routine getenv.
环境变量：这些变量由C库例程getenv访问。
The current working directory: The current working directory for the script SHOULD be set to the directory containing the script.
当前工作目录：脚本的当前工作目录应设置为包含脚本的目录。
Character set: The US-ASCII character set is used for the definition of environment variable names and header field names; the newline (NL) sequence is CR LF; servers SHOULD also accept LF as a newline.
字符集：US-ASCII字符集用于定义环境变量名称和标题字段名称；换行（NL）序列为CR-LF；服务器也应该接受LF作为换行符。
7 Security Considerations
7安全考虑
CGI scripts are able to initiate arbitrary SIP transactions, or to produce spoofed responses of any sort. This protocol does not attempt to restrict the actions CGI scripts can take. Server administrators MUST consider CGI scripts to be as security-sensitive as their SIP server itself, and perform equivalent levels of security review before installing them.
CGI脚本能够启动任意SIP事务，或生成任何类型的伪造响应。此协议不试图限制CGI脚本可以采取的操作。服务器管理员必须考虑CGI脚本作为其SIP服务器本身的安全敏感度，并在安装它们之前执行同等级别的安全审查。
CGI scripts must be careful not to interfere with authentication. In particular, adding or removing header fields that are below the Authorization header will cause the message to fail authentication at the user agent.
CGI脚本必须小心，不要干扰身份验证。特别是，添加或删除授权标头下方的标头字段将导致消息在用户代理处的身份验证失败。
When a SIP request is encrypted, the headers which are in the clear are passed to the server according to this specification. The encrypted portion of the request is passed to the script as a body. Any SIP headers output by the script will be added to the message. However, scripts should be aware that these may be discarded if they also exist within the encrypted portion.
当对SIP请求进行加密时，将根据此规范将清除中的头传递给服务器。请求的加密部分作为主体传递给脚本。脚本输出的任何SIP头都将添加到消息中。但是，脚本应该知道，如果这些脚本也存在于加密部分中，那么它们可能会被丢弃。
Some SIP header fields may carry sensitive information which the server SHOULD NOT pass on to the script unless explicitly configured to do so. For example, if the server protects the script using the Basic authentication scheme, then the client will send an Authorization header field containing a username and password. If the server, rather than the script, validates this information then the password SHOULD NOT be passed on to the script via the HTTP_AUTHORIZATION metavariable.
某些SIP头字段可能包含敏感信息，服务器不应将这些信息传递给脚本，除非明确配置为这样做。例如，如果服务器使用基本身份验证方案保护脚本，则客户端将发送一个包含用户名和密码的授权标头字段。如果服务器而不是脚本验证此信息，则不应通过HTTP_AUTHORIZATION元变量将密码传递给脚本。
The most common implementation of CGI invokes the script as a child process using the same user and group as the server process. It SHOULD therefore be ensured that the script cannot interfere with the server process, its configuration, or documents.
最常见的CGI实现将脚本作为子进程调用，使用与服务器进程相同的用户和组。因此，应确保脚本不会干扰服务器进程、其配置或文档。
If the script is executed by calling a function linked in to the server software (either at compile-time or run-time) then precautions SHOULD be taken to protect the core memory of the server, or to ensure that untrusted code cannot be executed.
如果通过调用链接到服务器软件的函数（在编译时或运行时）来执行脚本，则应采取预防措施保护服务器的核心内存，或确保不能执行不受信任的代码。
This specification places no limits on the length of entity bodies presented to the script. Scripts SHOULD NOT assume that statically allocated buffers of any size are sufficient to contain the entire submission at one time. Use of a fixed length buffer without careful overflow checking may result in an attacker exploiting `stack-smashing' or `stack-overflow' vulnerabilities of the operating system. Scripts may spool large submissions to disk or other buffering media, but a rapid succession of large submissions may result in denial of service conditions. If the CONTENT_LENGTH of an entity-body is larger than resource considerations allow, scripts SHOULD respond with `413 Request Entity Too Large.'
本规范对呈现给脚本的实体体的长度没有限制。脚本不应假定任何大小的静态分配缓冲区都足以一次包含整个提交。在未仔细检查溢出的情况下使用固定长度的缓冲区可能会导致攻击者利用操作系统的“stack smashing”或“stack overflow”漏洞进行攻击。脚本可能会将大量提交假脱机到磁盘或其他缓冲介质，但快速连续的大量提交可能会导致拒绝服务情况。如果实体正文的内容长度大于资源考虑所允许的长度，脚本应以“413请求实体太大”作为响应
8 Acknowledgements
8致谢
This work draws extremely heavily upon the HTTP CGI specification [1]; approximately half the text of the specification section is taken from that document.
这项工作极大地借鉴了HTTP CGI规范[1]；规范部分约有一半的文本取自该文件。
9 Authors' Addresses
9作者地址
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
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
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
10 Bibliography
10参考书目
[1] http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
[1] http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
[2] Handley, M, Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Handley，M，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[3] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 10, RFC 822, August 1982.
[3] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 10，RFC 822，1982年8月。
[4] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[7] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[8] St. Johns, M., "Identification Protocol", RFC 1413, January 1993.
[8] 圣约翰，M.，“身份确认协议”，RFC 1413，1993年1月。
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
11 Full Copyright Statement
11完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。