[要約] RFC 3050は、SIPのための共通ゲートウェイインターフェース（CGI）に関する仕様です。このRFCの目的は、SIPプロトコルを使用してCGIスクリプトを実行するための標準的な方法を提供することです。
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.
Copyright（c）The Internet Society（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.
インターネットテレフォニーには、新しいサービスが迅速に作成および展開される手段が必要です。World Wide Webでは、Common Gateway Interface（CGI）は、Webサービスのプログラミングに向けて一般的な手段として機能しています。セッション開始プロトコル（SIP）とハイパーテキスト転送プロトコル（HTTP）の類似性により、CGIはSIP環境でのサービス作成の優れた候補です。このドキュメントでは、SIPサーバーでSIPサービスを提供するためのSIP CGIインターフェイスを定義しています。
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
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をローカルシステムに保存されたファイル名に単純に翻訳し、ファイルコンテンツを返しました。時間が経つにつれて、サーバーは動的なコンテンツを提供するように進化し、フォームはユーザー入力を勧誘する手段を提供しました。本質的に、進化したのは、ウェブ環境でのサービス作成の手段でした。現在、サーバー側のJavaScript、サーブレット、Common Gatewayインターフェイス（CGI）[1]など、動的Webコンテンツの作成には多くの手段があります。
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は、すべてのヘッダーのコンテンツをHTTPリクエストでCGIアプリケーションに公開します。アプリケーションは、適切と思われるようにこれらを利用し、気にしないものを無視できます。これにより、HTTPリクエストのすべての側面をコンテンツの作成に考慮することができます。SIP環境では、ヘッダーはHTTPよりも重要です。発信者とCallee、件名、連絡先住所、組織、拡張名、登録パラメーター、有効期限、コールステータス、コールルートなど、トランザクションに関する重要な情報があります。したがって、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は、メッセージ本文に加えて、ヘッダー、ステータスコード、理由フレーズを含む応答のすべての部分を作成できるという点で有利です。これは、主に身体に焦点を当てているJavaサーブレットなど、他のメカニズムには当てはまりません。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
HTTP CGIとの3つの違い
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. | |
| | | |
| ------- |
------------
Figure 1: HTTP CGI Model
図1：HTTP CGIモデル
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要求を発行します。これは、Origin Serverに直接渡され（図のように）、またはプロキシサーバーを介して転送されます。Origin ServerはCGIスクリプトを実行し、CGIスクリプトは応答を返し、クライアントに渡されます。スクリプトの主な仕事は、応答のために本体を生成することです。Origin Serverのみが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. |
| |
-------
Figure 2: SIP CGI Model
図2：SIP CGIモデル
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サーバーは4つの基本操作を実行することを懸念しています。
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.
リクエストが受信されると、上記の操作の1つ以上が一度に発生する場合があります。たとえば、SIPサーバーは暫定的な応答を生成し、新しいリクエストを生成し、2つのサーバーに元のリクエストをプロキシできます。これは、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では、各リクエストに対してスクリプトが1回実行されます。応答を生成し、終了します。一般的なルールと同じユーザーからの要求を介して維持されている状態はありません（これは、これを行うことができますが、データベースアクセスなどのより複雑なサービスの場合、クライアント側の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スクリプトはトランザクションごとに1回実行されますが、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 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.
たとえば、SIPサーバーに到着するリクエストを検討してください。サーバーは、暫定的な応答とプロキシリクエストを生成するCGIスクリプトを呼び出します。また、トークンをサーバーに返し、終了します。応答はクライアントに向かって上流に戻され、リクエストがプロキシになります。プロキシリクエストへの応答が届くと、スクリプトは再び実行されます。環境変数は、新しい応答の内容に基づいて設定されます。スクリプトはトークンも渡されます。トークンをその状態として使用して、スクリプトはリクエストを別の場所にプロキシすることを決定します。したがって、プロキシリクエストと別のトークンを返します。サーバーはこの新しい要求を転送し、応答が来たら、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スクリプトはトランザクション中に1回実行されますが、単一の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ではそうではありません。一般に、リクエストはユーザーに呼ばれるユーザーに名前を付けます。実行されるスクリプトへのマッピングは、フィールド、SIPメソッド、ステータスコード、および理由フレーズを含む他の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には存在しません。SIPCGIでは、ITに対する基本的なサポートが必要です。
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ヘッダーによって変更される場合があります。このセットは、2つのキャリッジリターンを使用して区切られています。アクションラインを使用すると、スクリプトは、デフォルト操作に加えて、上記の4つの操作のいずれかを指定できます。応答の生成は、応答のステータス行をCGI出力のアクションラインにコピーすることにより行われます。たとえば、以下は元のリクエストに200 OKを作成します。
SIP/2.0 200 OK
SIP/2.0 200 OK
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
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リモーブもサポートします。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リモーブヘッダーのサポート値は、元のメッセージのヘッダーの名前です。
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スクリプトは、どの応答を返すかを示す必要があります。たとえば、Token Abcdefghijで名前が付けられた応答を返すために、次の出力が生成されます。
CGI-FORWARD-RESPONSE abcdefghij SIP/2.0
CGI-Forward-response 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およびキャンセル要求のために、CGI-Againアクションを実行できます。
CGI-AGAIN yes SIP/2.0
cgi-again yes 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.
このアクションは、スクリプトの次の呼び出しにのみ適用されます。スクリプトをもう一度呼び出すことを意味します。「いいえ」を出力することは、スクリプトのこの呼び出しで「はい」を出力し、次にスクリプトが呼び出されたときに何も出力しません。
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と呼ばれる1つの状態を生成できます。CGI-Set-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 when the request is proxied. Any responses received to this request will have the token passed in an environment variable.
最後に、スクリプトがサーバーにリクエストをプロキシにすると、これらのリクエストへの応答が到着します。リクエストへの応答の一致を容易にするために、スクリプトはCGI CGI-Request-Tokenヘッダーにリクエストトークンを配置できます。このヘッダーは、リクエストがプロキシになったときにサーバーによって削除されます。このリクエストに受け取った回答は、トークンを環境変数で渡すことになります。
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のホームページは、URL http://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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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.
MetAvariable：サーバーからスクリプトに情報を伝達する名前付きパラメーター。それは必ずしもオペレーティングシステムの環境で変数ではありませんが、それは最も一般的な実装です。
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
(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トランザクションでは、一度に1つのCGIスクリプトのみが顕著です。その後、応答が届くとCGIスクリプトが呼び出されると、トランザクションの以前のメッセージのCGIスクリプトが終了するまで、ACKを除き、それらの処理が延期されます。メッセージは、受信される順序で処理されます。
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.
メッセージに関する情報は、メッセージヘッダーと関連するコンテンツボディの2つの異なるソースからのものです。サーバーは、この情報の一部をスクリプトで利用できるようにする必要があります。
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サーバーの実装は、サーバーからスクリプトへのメッセージに関するデータを渡すメカニズムを定義する必要があります。これらのデータを含むmetavariablesは、システム定義の方法でスクリプトによってアクセスされます。Metavariablesの文字の表現はシステム定義です。
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.
Metavariablesの表現は、未定義の値（存在しない）とヌル値（存在しますが、長さはゼロ）を区別する必要があります。ヌル値は、文法がこれを許可する人のみにのみ許可されます。
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はヌル値と未定義の値を区別しません。この仕様により、このマスフィーチャーが排除されます。null値と未定義の値は意味的に異なります。
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.
MetAvariableの名前では、ケースは重要ではありません。という点では、2つの異なる変数が存在することはできません。ここでは、キャピタルとアンダースコア（ "_"）の標準表現を使用して表示されます。名前の実際の表現は、システムが定義されています。特定のシステムの場合、表現はこれとは異なる方法で定義される場合があります。
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
auth_type content_length content_type gateway_interface remote_addr remote_host remote_ident remote_user登録request_method request_token request_uri response_status response_reason response_token script_name server_port server_portocol server_software_name
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.
メッセージのターゲットが外部アクセスにアクセス認証を必要とする場合、サーバーは、メッセージの承認ヘッダーフィールドのAuth-Schemeトークンからこの変数の値を設定する必要があります。それ以外の場合は、定義されていません。
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仕様のセクション14および15で説明されています[2]。Auth-Schemeは症例に敏感ではありません。
Servers MUST provide this metavariable to scripts if the message header included an Authorization field that was authenticated.
メッセージヘッダーに認証された承認フィールドが含まれている場合、サーバーはスクリプトにこのmetavariableを提供する必要があります。
For the complex authentication schemes, the server SHOULD perform the authentication checking itself. If the authentication failed, this metavariable SHOULD NOT be set.
複雑な認証スキームの場合、サーバーはそれ自体を確認する認証を実行する必要があります。認証が失敗した場合、このMetAvariableを設定しないでください。
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]).
このMetAvariableは、10進数のオクテットでメッセージに添付されているメッセージボディエンティティのサイズに設定されます。データが添付されていない場合、このMetAvariableは定義されていません。構文は、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.
メッセージにコンテンツレングスヘッダーフィールドが含まれていなくても、メッセージにコンテンツボディエンティティが添付されていた場合、サーバーはスクリプトにこのmetavariableを提供する必要があります。
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.
メッセージにメッセージボディが含まれている場合、content_typeは、メッセージヘッダー内のコンテンツタイプのフィールドを介してタイプが提供された場合、またはサーバーが非存在下でそれを決定できる場合、添付エンティティのインターネットメディアタイプ[6]に設定されます。提供されたコンテンツタイプのフィールドの。構文は、SIPコンテンツタイプのヘッダーフィールドと同じです。
CONTENT_TYPE = "" | media-type
content_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でのメディアタイプとその使用は、SIP/2.0仕様[2]のセクション6.16で説明されており、HTTP/1.1仕様[5]のセクション3.7に参照されています。
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:
このMetAvariableは、サーバーがスクリプトと通信するために使用されるSIP CGIの方言に設定されています。構文：
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.
主要な数字とマイナー数は別々の整数として扱われているため、それぞれが1桁以上である可能性があることに注意してください。したがって、SIP-CGI/2.4は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.
サーバーは、スクリプトにこのMetAvariableを提供する必要があります。
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 reasonable compromise. (The existing CGI libraries we checked do not seem to check the version.)
既存のHTTP CGIライブラリとの最大の互換性については、CGI 1.1の構文と可能な限り同様に保つ必要があります。ただし、これが実際にCGIであることを明確にしていることを望んでいます。HTTP CGIのバージョン識別子をSIP CGI識別子のサブストリングにすることは、合理的な妥協のように思えました。（確認した既存の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).
これらのメトバリスは、メソッドが送信されるプロトコルに固有です。これらの変数の解釈は、server_protocol metavariableの値に依存します（セクション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_」から始まる名前のMetavariablesは、使用されているプロトコルがSIPである場合、メッセージヘッダーからの値を含んでいます。各SIPヘッダーのフィールド名は大文字に変換され、「 - 」のすべての発生が「_」に置き換えられ、「SIP_」がメタヴァリアブル名を形成するために準備されています。他のプロトコルにも同様の変換が適用されます。ヘッダーデータは、クライアントによって送信されたものとして提示されるか、そのセマンティクスを変更しない方法で書き直される場合があります。同じフィールド名を持つ複数のヘッダーフィールドを受信した場合、サーバーは、メタバリアブルで表現される前に、同じセマンティクスを持つ単一のヘッダーフィールドとして受信されたかのようにそれらを書き直す必要があります。同様に、複数の行で受信されるヘッダーフィールドを単一の行に統合する必要があります。サーバーは、必要に応じて、データの表現（キャラクターセットなど）をCGI MetAvariableに適切に変更する必要があります。
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.
注：これらのMetavariablesの名前は、この仕様の最初のドラフト以降、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.
サーバーは、受信したすべてのメッセージヘッダーフィールドに対してMetAvariablesを作成する必要はありません。ただし、メッセージのセマンティックコンテンツのSIPにおけるヘッダーの比較的高い重要性があるため、サーバーは、承認などの潜在的に機密性の高い認証情報を含まないすべてのヘッダーを提供する必要があります。サーバーは、content_lengthやcontent_typeなどの他の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スクリプトは、必要に応じて、他のMetavariablesの情報が元のメッセージに含まれているか、サーバーによって合成されたかどうかを判断できます。
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 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.
このMetAvariableには、トランザクションの最初の要求のリクエスト-URIでサーバーがユーザーに登録している現在の場所にリストが含まれています。これは、プロトコルMetAvariable SIP_CONTACTと構文的に同一であるため、このドキュメントのセクション5.5.1.5およびSIP/2.0仕様[2]のセクション6.13で定義されます。サーバーに登録されているアドレスのすべての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_CONTACTがどのように表示されるかと同じです。これにより、解析コードを再利用できます。
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
remote_addr = hostnumber hostnumber = ipv4address |IPv6Address
The definitions of IPv4address and Ipv6address are provided in Appendix B of RFC 2373 [7].
IPv4AddressとIPv6Addressの定義は、RFC 2373の付録Bに記載されています[7]。
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
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]リクエストによって接続についてサポートされているID情報。
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_type metavariableが設定されている場合）、remote_user metavariableの値は、認証用に提供されるユーザーIDに設定されます。基本認証の場合、これは（デコードされた）「userid」文法要素のコンテンツです。ダイジェストの場合、それは「ユーザー名値」の内容です。PGP認証の場合、存在する場合は、承認ヘッダーの「署名」パラメーターで指定されている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.
他の認証スキームが要求された場合、このMetAvariableは、資格情報に関連付けられたユーザーまたはエンティティを識別する承認情報の適切なコンポーネントに設定する必要があります。認証が要求されなかった場合、このメタバリアブルは定義されていません。
REMOTE_USER = *OCTET
Servers SHOULD provide this metavariable to scripts.
サーバーは、スクリプトにこのMetAvariableを提供する必要があります。
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.
スクリプトをトリガーするメッセージがリクエストである場合、sip/2.0仕様[2]のセクション4.2で説明されているように、リクエスト_method metavariableはリクエストが作成された方法に設定されます。それ以外の場合は定義されていません。
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を参照してください。CGIコンテキストでのレジスタの意味については、セクション5.9で説明し、キャンセルについてはセクション5.10で説明します。SIP CGI 1.1サーバーは、スクリプトに渡すのではなく、いくつかのメソッドを直接処理することを選択できます。
Servers MUST provide this metavariable to scripts if the triggering message was a request.
トリガーメッセージがリクエストである場合、サーバーはスクリプトにこのメトバリアブルを提供する必要があります。
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.
このMetAvariableは、SIPで作成されたリクエストに固有です。
REQUEST_URI = absoluteURI ; defined in RFC 2396 [9]
request_uri = absoluteuri;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を示します。このMetAvariableは、request_methodが定義されている場合にのみ定義されます。その場合、サーバーはスクリプトに提供する必要があります。
This metavariable fills the roles of HTTP CGI's SCRIPT_NAME, PATH_INFO, and QUERY_STRING.
これにより、HTTP CGIのscript_name、path_info、およびquery_stringの役割が記入されます。
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
If the message triggering the script was a response, this variable indicates the textual string specified in the response.
スクリプトをトリガーするメッセージが応答である場合、この変数は応答で指定されたテキスト文字列を示します。
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-forward-responseの説明を参照してください。
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 metavariableは、サーバーの名前に設定されています。
SERVER_NAME = hostname | hostnumber
server_name = hostname |hostnumber
Servers MUST provide this metavariable to scripts.
サーバーは、スクリプトにこのMetAvariableを提供する必要があります。
The SERVER_PORT metavariable is set to the port on which the message was received.
server_port metavariableは、メッセージが受信されたポートに設定されます。
SERVER_PORT = 1*digit
Servers MUST provide this metavariable to scripts.
サーバーは、スクリプトにこのMetAvariableを提供する必要があります。
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 metavariableは、メッセージが届いたプロトコルの名前と改訂に設定されています。これは通常、「SIP/2.0」になります。これは、クライアントへの応答でサーバーが使用するプロトコルバージョンと必ずしも同じではありません。
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.
サーバーは、スクリプトにこのMetAvariableを提供する必要があります。
The SERVER_SOFTWARE metavariable is set to the name and version of the information server software handling the message (and running the gateway).
Server_Software MetAvariableは、メッセージを処理する（およびゲートウェイを実行する）情報サーバーソフトウェアの名前とバージョンに設定されています。
SERVER_SOFTWARE = 1*product
product = token [ "/" product-version ]
product-version = token
Servers MUST provide this metavariable to scripts.
サーバーは、スクリプトにこのMetAvariableを提供する必要があります。
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.
metAvariable content_length（セクション5.5.1.2を参照）が定義されている場合、サーバーは少なくとも標準の入力ストリーム上のスクリプトに多くのバイトを提供する必要があります。スクリプトはデータを読み取る義務はありません。サーバーは、content_lengthバイトが読み取られた後、EOF条件を信号する場合がありますが、そうする義務はありません。したがって、スクリプトは、より多くのデータが利用可能であっても、Content_Lengthバイト以上の読み取りを試みてはなりません。
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.
メッセージには正確に1つのアクションラインが含まれている必要があります。また、任意の数の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の両方）は、1行ごとに1つを指定する必要があります。SIP CGI 1.1は、継続ラインを規定していません。
The generic syntax of CGI header fields is specified in section 5.6.2.
CGIヘッダーフィールドの一般的な構文は、セクション5.6.2で指定されています。
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-version 3*digit sp reasue-phrase 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-version
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.
このアクションラインにより、サーバーは指定されたSIP URIにリクエストを転送します。リクエストによってトリガーされたスクリプトによって送信される場合があります。その場合、トリガーリクエストは転送されます。または、状態で実行されているサーバー上の応答によってトリガーされたスクリプトによって、その場合、トランザクションの最初の要求が送信されます。
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ヘッダーは、元のメッセージ全体のすべてのものを置き換えます。スクリプトが元のメッセージからヘッダー要素を保持し、新しいメッセージを追加したい場合、通常のヘッダー連結ルールによってそれらを連結し、結果をスクリプト出力に配置できます。新しいヘッダーフィールドは、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スクリプトによって生成されない元のリクエストのヘッダーは、通常プロキシサーバーによって実行される変更の後、プロキシリクエストにコピーされます。特に、サーバーはフィールドを介してAを追加し、最大値を減少させる必要があります。サーバーは、レコードルートヘッダーの追加など、適切であると思われる追加の変更を実行する場合があります。サーバーがスクリプト出力で指定されている場合、サーバーはこれらのヘッダーを追加してはなりません。
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リモーブ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.
メッセージが本体を指定していない場合、最初のリクエストのボディが使用されます。「Content-Length：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" response-name sip-version response-name = response-token |"これ"
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.
指定された応答名は、以前にResponse_Token MetAvariableで送信されたサーバーをトークンする応答であるか、文字列「This」のいずれかです。文字列「this」は、このCGIスクリプトをトリガーしたメッセージが応答である場合にのみ送信できます。これは、このトリガー応答を転送する必要があることを示しています。
Script-Cookie = "CGI-SET-COOKIE" token SIP-Version
script-cookie = "cgi-set-cookie"トークンSip-version
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の値を変更できます。この変更は、その後のすべてのスクリプトの呼び出しに影響を与えます。
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.
このアクションラインは、このトランザクションの後続の要求と回答のためにスクリプトが呼び出されるかどうかを決定します。このアクションにパラメーター「はい」が与えられた場合、次のメッセージが届くとスクリプトが再度実行されます。パラメーターが「いいえ」またはこのアクションが指定されていない場合、スクリプトは再度実行されず、サーバーは後続のすべてのメッセージに対してデフォルトアクションを実行します。
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-again、cgi-set-cookie、またはnothingのみを出力しない場合 - スクリプトデフォルトのアクションを実行します。取得するデフォルトのアクションは、スクリプトをトリガーしたイベントによって異なります。
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の応答であり、他の1xxではなく、100の応答でない限り、発信者に向かって上流にプロにされます。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
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-Request-Token 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
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リモーブヘッダーを使用すると、スクリプトが発信リクエストまたは応答から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 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.
CGIスクリプトがCGI-Proxy-Requestとともにヘッダーフィールドの有効期限を指定する場合、SIPサーバーは有効期限のタイムアウトをローカルで追跡し、メッセージをリモートサーバーに送信する必要があります。タイムアウトの有効期限が切れると、サーバーは「408リクエストタイムアウト」応答を生成する必要があります。タイムアウト応答は、セクション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スクリプトが、リモートユーザーエージェントサーバーが応答していないか、ヘッダーフィールドを適切に処理していない場合でも、ユーザーが決定した時間の後にトリガーするために「フォワードフォワードノーアンサー」などのサービスを実装できます。
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.
これは、「Call Forward No Answer」サービスを実装するための要件の残りの半分と、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スクリプトの特定のセマンティクスは、コール関連のリクエストによってトリガーされたものとは多少異なります。ただし、登録のユーザー制御を許可する場合がある場合もあります。議論する必要があるレジスタの2つの特定のアクションは、応答「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応答を送信し、現在発行されたすべてのブランチをキャンセルする必要があります。キャンセルメッセージにスクリプトを送信することは純粋にアドバイザリーであり、スクリプトはそれに応じてアクションを実行してはなりません。
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.
ただし、スクリプトが招待リクエストに対する独自の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.
サーバーが招待リクエストに対する200の非最終応答を受信した場合、それ自体でACKを生成する必要があり、そうするためのスクリプトに依存しません。SIP CGI 1.1には、この動作をオーバーライドする方法はありません。ただし、サーバーは招待のための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文字セットは、環境変数名とヘッダーフィールド名の定義に使用されます。NewLine（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文字セットは、環境変数名とヘッダーフィールド名の定義に使用されます。NewLine（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 metavariableを介してパスワードをスクリプトに渡すことはできません。
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.'
この仕様は、スクリプトに提示されたエンティティボディの長さに制限を設けません。スクリプトは、任意のサイズの静的に割り当てられたバッファが、一度に提出全体を封じ込めるのに十分であると想定してはなりません。慎重なオーバーフローチェックなしの固定長バッファーを使用すると、攻撃者がオペレーティングシステムの「スタックスマッシュ」または「スタックオーバーフロー」の脆弱性を悪用する可能性があります。スクリプトは、ディスクまたはその他のバッファリングメディアへの大規模な提出物をスプールする可能性がありますが、大規模な提出物の急速な連続により、サービス条件が拒否される可能性があります。エンティティボディのcontent_lengthがリソースの考慮事項よりも大きい場合、スクリプトは「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アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
EMail: lennox@cs.columbia.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピューターサイエンスコロンビア大学のヘニングシュルツリン部1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
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。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、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）パート2：メディアタイプ」、RFC 2046、1996年11月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[7] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年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。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。