Network Working Group J. Lennox
Request for Comments: 2824 H. Schulzrinne
Category: Informational Columbia University
May 2000
Call Processing Language Framework and Requirements
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language.
私たちは、インターネット電話用可能にしたい多数のサービスが完了するまでに、多くの場合、ネットワークデバイスで、シグナルの操作のかなり精巧な組み合わせが必要です。私たちは、彼らがより簡単に実装し、デプロイするために作るために、このようなサービスを作成するためのシンプルで標準化された方法を求めています。この文書では、我々は、呼処理言語を呼び出すようなメカニズムのためのアーキテクチャフレームワークを、説明しています。また、このような言語のための要件の概要を説明します。
Table of Contents
目次
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Example services .................................... 4
4 Usage scenarios ..................................... 6
5 CPL creation ........................................ 6
6 Network model ....................................... 7
6.1 Model components .................................... 7
6.1.1 End systems ......................................... 7
6.1.2 Signalling servers .................................. 8
6.2 Component interactions .............................. 8
7 Interaction of CPL with network model ............... 10
7.1 What a script does .................................. 10
7.2 Which script is executed ............................ 11
7.3 Where a script runs ................................. 12
8 Creation and transport of a call processing
language script ..................................... 12
9 Feature interaction behavior ........................ 13
9.1 Feature-to-feature interactions ..................... 13
9.2 Script-to-script interactions ....................... 14
9.3 Server-to-server interactions ....................... 15
9.4 Signalling ambiguity ................................ 15
10 Relationship with existing languages ................ 15
11 Related work ........................................ 17
11.1 IN service creation environments .................... 17
11.2 SIP CGI ............................................. 17
12 Necessary language features ......................... 17
12.1 Language characteristics ............................ 17
12.2 Base features -- call signalling .................... 19
12.3 Base features -- non-signalling ..................... 21
12.4 Language features ................................... 22
12.5 Control ............................................. 23
13 Security Considerations ............................. 23
14 Acknowledgments ..................................... 23
15 Authors' Addresses .................................. 23
16 Bibliography ........................................ 24
17 Full Copyright Statement ............................ 25
1 Introduction
1はじめに
Recently, several protocols have been created to allow telephone calls to be made over IP networks, notably SIP [1] and H.323 [2]. These emerging standards have opened up the possibility of a broad and dramatic decentralization of the provisioning of telephone services so they can be under the user's control.
最近、いくつかのプロトコルは、電話の通話がIPネットワーク上で行うことができるようにするために作成された、特にSIP [1]やH.323 [2]。彼らは、ユーザーの制御下に置くことができるように、これらの新しい規格は、電話サービスのプロビジョニングの広範かつ劇的な分権化の可能性を切り開いてきました。
Many Internet telephony services can, and should, be implemented entirely on end devices. Multi-party calls, for instance, or call waiting alert tones, or camp-on services, depend heavily on end-system state and on the specific content of media streams, information which often is only available to the end system. A variety of services, however -- those involving user location, call distribution, behavior when end systems are busy, and the like -- are independent of a particular end device, or need to be operational even when an end device is unavailable. These services are still best located in a network device, rather than in an end system.
多くのインターネット電話サービスは、および、エンドデバイスに完全に実装する必要がありますすることができます。マルチパーティコールは、例えば、またはアラートトーンを待って呼び出し、またはキャンプオンサービス、エンド・システムの状態にし、多くの場合、エンドシステムにのみ使用可能ですメディアストリームの特定のコンテンツ、情報に大きく依存しています。しかし、様々なサービス、 - ユーザーの場所、呼分配、エンドシステムがビジーでの行動などを伴うものは - 特定のエンドデバイスから独立している、またはエンドデバイスが利用できない場合でも、運用する必要があります。これらのサービスは、まだ最高のネットワークデバイスではなく、エンド・システムに配置されています。
Traditionally, network-based services have been created only by service providers. Service creation typically involved using proprietary or restricted tools, and there was little range for customization or enhancement by end users. In the Internet environment, however, this changes. Global connectivity and open protocols allow end users or third parties to design and implement new or customized services, and to deploy and modify their services dynamically without requiring a service provider to act as an intermediary.
伝統的に、ネットワークベースのサービスは、サービスプロバイダによってのみ作成されています。サービスの作成は、通常、独自または制限ツールを使用して関与し、エンドユーザーによるカスタマイズや機能拡張のために少し範囲がありました。インターネット環境では、しかし、これは変更されます。グローバルコネクティビティおよびオープンプロトコルは、エンドユーザーまたは第三者が設計および実装、新規またはカスタマイズされたサービスを、および仲介者として行動するサービスプロバイダを必要とせずに、動的にそのサービスを展開したり変更したりすることができます。
A number of Internet applications have such customization environments -- the web has CGI [3], for instance, and e-mail has Sieve [4] or procmail. To create such an open customization environment for Internet telephony, we need a standardized, safe way for these new service creators to describe the desired behavior of network servers.
インターネットアプリケーションの数は、このようなカスタマイズ環境を持っている - ウェブCGI [3]は、例えば、電子メールふるい[4]又はprocmailのを有しています。インターネット電話のために、このようなオープンなカスタマイズ環境を作成するために、我々はこれらの新しいサービスの作成者がネットワーク・サーバの所望の動作を記述するための標準化され、安全な方法が必要です。
This document describes an architecture in which network devices respond to call signalling events by triggering user-created programs written in a simple, static, non-expressively-complete language. We call this language a call processing language.
この文書では、ネットワークデバイスは、単純な、静的、非表情豊かに、完全な言語で書かれたユーザーが作成したプログラムをトリガすることにより、シグナル伝達事象の呼び出しに応答したアーキテクチャについて説明します。私たちは、呼処理言語この言語を呼び出します。
The development of this document has been substantially informed by the development of a particular call processing language, as described in [5]. In general, when this document refers to "a call processing language," it is referring to a generic language that fills this role; "the call processing language" or "the CPL" refers to this particular language.
[5]で説明されるように、この文書の開発は、実質的に、特定の呼処理言語の発達により通知されました。一般的には、この文書では、「呼処理言語、」それがこの役割を満たす一般的な言語を参照しているを参照するとき。 「呼処理言語」または「CPL」は、この特定の言語を指します。
2 Terminology
2用語
In this section we define some of the terminology used in this document.
このセクションでは、このドキュメントで使用される用語のいくつかを定義します。
SIP [1] terminology used includes:
SIP [1]で使用される用語を含みます：
invitation: The initial INVITE request of a SIP transaction, by which one party initiates a call with another.
招待状：一方の当事者が相互に通話を開始することにより、SIPトランザクションの初期INVITE要求。
redirect server: A SIP device which responds to invitations and other requests by informing the request originator of an alternate address to which the request should be sent.
要求が送信すべき代替アドレスの要求元に通知することにより、招待および他の要求に応答するSIPデバイス：サーバをリダイレクト。
proxy server: A SIP device which receives invitations and other requests, and forwards them to other SIP devices. It then receives the responses to the requests it forwarded, and forwards them back to the sender of the initial request.
プロキシサーバー：招待状や他の要求を受け、他のSIPデバイスに転送し、SIPデバイス。それはそれは転送された要求に対する応答を受信して、最初の要求の送信元に戻ってそれらを転送します。
user agent: A SIP device which creates and receives requests, so as to set up or otherwise affect the state of a call. This may be, for example, a telephone or a voicemail system.
ユーザーエージェント：セットアップまたはそうでなければ、呼の状態に影響を与えるように、要求を作成し、受信したSIPデバイス。これは、例えば、電話やボイスメールシステムであってもよいです。
user agent client: The portion of a user agent which initiates requests.
ユーザエージェントクライアント：要求を開始するユーザーエージェントの一部。
user agent server: The portion of a user agent which responds to requests.
ユーザエージェントサーバ：要求に応答するユーザーエージェントの一部。
H.323 [2] terminology used includes:
H.323 [2]で使用される用語を含みます：
terminal: An H.323 device which originates and receives calls, and their associated media.
ターミナル：H.323コールを発信および受信する装置、およびそれらに関連するメディア。
gatekeeper: An H.323 entity on the network that provides address translation and controls access to the network for H.323 terminals and other endpoints. The gatekeeper may also provide other services to the endpoints such as bandwidth management and locating gateways.
ゲートキーパー：H.323端末と他のエンドポイントのネットワークへのアドレス変換とコントロールのアクセスを提供するネットワーク上のH.323エンティティ。ゲートキーパはまた、帯域幅管理及び位置決めゲートウェイなどのエンドポイントに他のサービスを提供してもよいです。
gateway: A device which translates calls between an H.323 network and another network, typically the public-switched telephone network.
ゲートウェイ：H.323ネットワークと他のネットワーク、典型的には、公衆交換電話網との間のコールを変換する装置。
RAS: The Registration, Admission and Status messages communicated between two H.323 entities, for example between an endpoint and a gatekeeper.
RAS：登録、許可およびステータスメッセージは、エンドポイントとゲートキーパーの間で、たとえば、2つのH.323エンティティ間で通信します。
General terminology used in this document includes:
この文書で使用されている一般的な用語が含まれています：
user location: The process by which an Internet telephony device determines where a user named by a particular address can be found.
ユーザ位置：特定のアドレスによって指定されたユーザを見つけることができる場合、インターネット電話装置が決定するプロセス。
CPL: A Call Processing Language, a simple language to describe how Internet telephony call invitations should be processed.
CPL：コール処理言語、インターネット電話通話の招待状が処理されるべき方法を記述するためのシンプルな言語です。
script: A particular instance of a CPL, describing a particular set of services desired.
スクリプト：CPLの特定のインスタンス、所望のサービスの特定のセットを記述する。
end system: A device from which and to which calls are established. It creates and receives the call's media (audio, video, or the like). This may be a SIP user agent or an H.323 terminal.
エンドシステムから及びコールが確立されるデバイス。これは、作成して、コールのメディア（オーディオ、ビデオなど）を受け取ります。これは、SIPユーザエージェントまたはH.323端末であってもよいです。
signalling server: A device which handles the routing of call invitations. It does not process or interact with the media of a call. It may be a SIP proxy or redirect server, or an H.323 gatekeeper.
シグナリング・サーバー：コールの招待状のルーティングを処理デバイス。これは、処理したり、コールのメディアと相互作用しません。これは、SIPプロキシであるか、またはサーバ、またはH.323ゲートキーパーをリダイレクトすることができます。
3 Example services
3例サービス
To motivate the subsequent discussion, this section gives some specific examples of services which we want users to be able to create programmatically. Note that some of these examples are deliberately somewhat complicated, so as to demonstrate the level of decision logic that should be possible.
その後の議論のやる気を引き出すために、このセクションでは、我々は、ユーザーがプログラムで作成できるようにしたいサービスのいくつかの具体的な例を示します。可能なはず意思決定ロジックのレベルを証明するように、これらの例のいくつかが故意にやや複雑であることに注意してください。
o Call forward on busy/no answer
O忙しい/無応答にコール転送
When a new call comes in, the call should ring at the user's desk telephone. If it is busy, the call should always be redirected to the user's voicemail box. If, instead, there's no answer after four rings, it should also be redirected to his or her voicemail, unless it's from a supervisor, in which case it should be proxied to the user's cell phone if it is currently registered.
新しいコールが着信すると、コールは、ユーザーのデスクの電話で鳴るはずです。それがビジー状態の場合、呼び出しは常にユーザーのボイスメールボックスにリダイレクトされなければなりません。代わりに、4輪の後に何も答えはありません場合は、それが現在登録されている場合、それはユーザーの携帯電話にプロキシする必要があり、その場合には監督からでない限り、それはまた、彼または彼女のボイスメールにリダイレクトする必要があります。
o Information address
O情報アドレス
A company advertises a general "information" address for prospective customers. When a call comes in to this address, if it's currently working hours, the caller should be given a list of the people currently willing to accept general information calls. If it's outside of working hours, the caller should get a webpage indicating what times they can call.
同社は、見込み客のための一般的な「情報」のアドレスをアドバタイズします。呼び出しは、このアドレスに入って来たとき、それは現在の時間を働いている場合、発信者は、一般的な情報の呼び出しを受け入れて、現在喜んで人々のリストを与えられるべきです。それは勤務時間外だ場合、発信者は、彼らが呼び出すことができますどのような時間を示すWebページを取得する必要があります。
o Intelligent user location
Oインテリジェントユーザーの場所
When a call comes in, the list of locations where the user has registered should be consulted. Depending on the type of call (work, personal, etc.), the call should ring at an appropriate subset of the registered locations, depending on information in the registrations. If the user picks up from more than one station, the pick-ups should be reported back separately to the calling party.
電話がかかってきた場合、ユーザーが登録した場所のリストが相談する必要があります。コール（仕事、個人的な、等）の種類に応じて、呼が登録の情報に応じて、登録された場所の適切なサブセットで鳴るべきです。ユーザーが複数の駅からピックアップした場合、ピックアップは、発呼者に個別に戻って報告する必要があります。
o Intelligent user location with media knowledge
メディアの知識を持つOインテリジェントユーザーの場所
When a call comes in, the call should be proxied to the station the user has registered from whose media capabilities best match those specified in the call request. If the user does not pick up from that station within four rings, the call should be proxied to the other stations from which he or she has registered, sequentially, in order of decreasing closeness of match.
電話がかかってきた場合、呼び出しは駅にプロキシする必要があるユーザーは、そのメディア機能最高のコール要求で指定されたものと一致してから、登録しています。ユーザーは、4つのリングの中にそのステーションからピックアップしていない場合は、呼び出しは、彼または彼女は試合の近さを減少させるためには、順次、登録したから、他のステーションにプロキシする必要があります。
o Client billing allocation -- lawyer's office
Oクライアントへの課金の割り当て - 弁護士事務所
When a call comes in, the calling address is correlated with the corresponding client, and client's name, address, and the time of the call is logged. If no corresponding client is found, the call is forwarded to the lawyer's secretary.
電話がかかってきた場合、呼び出し元アドレスは、対応するクライアントと相関している、そしてクライアントの氏名、住所、およびコールの時間が記録されます。該当するクライアントが見つからない場合、コールは弁護士の秘書に転送されます。
4 Usage scenarios
4つの使用シナリオ
A CPL would be useful for implementing services in a number of different scenarios.
CPLは、さまざまなシナリオの数にサービスを実装するために有用であろう。
o Script creation by end user
エンドユーザーによるOスクリプトの作成
In the most direct approach for creating a service with a CPL, an end user simply creates a script describing their service. He or she simply decides what service he or she wants, describes it using a CPL script, and then uploads it to a server.
CPLとサービスを作成するための最も直接的なアプローチでは、エンドユーザは、単に彼らのサービスを記述したスクリプトを作成します。彼または彼女は単に、彼または彼女が望んでいるサービスを決定するCPLスクリプトを使用して、それを説明し、その後、それをサーバにアップロードします。
o Third party outsourcing
Oサードパーティのアウトソーシング
Because a CPL is a standardized language, it can also be used to allow third parties to create or customize services for clients. These scripts can then be run on servers owned by the end user or the user's service provider.
CPLは、標準化された言語であるため、また、第三者が作成したり、クライアントのためにサービスをカスタマイズできるようにするために使用することができます。これらのスクリプトは、エンドユーザまたはユーザのサービスプロバイダが所有しているサーバー上で実行することができます。
o Administrator service definition
O管理者のサービス定義
A CPL can also be used by server administrators to create simple services or describe policy for servers they control. If a server is implementing CPL services in any case, extending the service architecture to allow administrators as well as users to create scripts is a simple extension.
CPLは、単純なサービスを作成したり、それらが制御するサーバー用のポリシーを記述するために、サーバ管理者が使用することができます。サーバは、管理者だけでなく、ユーザーがスクリプトを作成できるようにするサービスアーキテクチャを拡張し、どのような場合にCPLサービスを実施している場合は、単純な拡張です。
o Web middleware
Oウェブミドルウェア
Finally, there have been a number of proposals for service creation or customization using web interfaces. A CPL could be used as the back-end to such environments: a web application could create a CPL script on behalf of a user, and the telephony server could then implement the services without either component having to be aware of the specifics of the other.
最後に、ウェブインターフェースを使用して、サービスの作成やカスタマイズのための多くの提案がなされています。 Webアプリケーションがユーザーに代わってCPLスクリプトを作成することができ、およびテレフォニーサーバは、コンポーネントのいずれかが他の仕様を意識することなく、サービスを実装することができます：CPLは、このような環境へのバックエンドとして使用することができ。
5 CPL creation
5 CPLの作成
There are also a number of means by which CPL scripts could be created. Like HTML, which can be created in a number of different manners, we envision multiple creation styles for a CPL script.
CPLスクリプトを作成することができたことにより、多くの手段もあります。多くの異なる方法で作成することができますHTML、同じように、私たちは、CPLスクリプトの複数の作成スタイルを想定しています。
o Hand authoring
ハンドオーサリングO
Most directly, CPL scripts can be created by hand, by knowledgeable users. The CPL described in [5] has a text format with an uncomplicated syntax, so hand authoring will be straightforward.
最も直接的、CPLスクリプトは知識のあるユーザーが、手動で作成することができます。 CPL [5]は単純な構文を使用してテキストフォーマットを有するで説明するので、ハンドオーサリングが簡単になります。
o Automated scripts
O自動化スクリプト
CPL features can be created by automated means, such as in the example of the web middleware described in the previous section. With a simple, text-based syntax, standard text-processing languages will be able to create and edit CPL scripts easily.
CPLの特徴は、前のセクションで説明したWebミドルウェアの例のように自動化された手段によって作成することができます。シンプルな、テキストベースの構文を使用すると、標準のテキスト処理言語は、簡単にCPLスクリプトを作成し、編集することができます。
o GUI tools
お ぐい とおｌｓ
Finally, users will be able to use GUI tools to create and edit CPL scripts. We expect that most average-experience users will take this approach once the CPL gains popularity. The CPL will be designed with this application in mind, so that the full expressive power of scripts can be represented simply and straightforwardly in a graphical manner.
最後に、ユーザーは、CPLスクリプトを作成し、編集するGUIツールを使用することができるようになります。私たちは、ほとんどの平均経験のユーザーは、CPLの利益の人気度、このアプローチを取ることを期待しています。スクリプトの完全な表現力は、グラフィカルな方法で簡単かつ直接的に表現することができるように、CPLは、念頭に置いて、このアプリケーションを使用して設計されます。
6 Network model
6ネットワークモデル
The Call Processing Language operates on a generalized model of an Internet telephony network. While the details of various protocols differ, on an abstract level all major Internet telephony architectures are sufficiently similar that their major features can be described commonly. This document generally uses SIP terminology, as its authors' experience has mainly been with that protocol.
コール処理言語は、インターネット電話ネットワークの一般化モデルで動作します。さまざまなプロトコルの詳細は異なるが、抽象的なレベルで、すべての主要なインターネット電話・アーキテクチャは、その主要な機能は、一般的に説明することができることを十分に類似しています。その著者の経験は、主にそのプロトコルであったようにこの文書では、一般的に、SIPの用語を使用しています。
In the Call Processing Language's network model, an Internet telephony network contains two types of components.
コール処理言語のネットワークモデルでは、インターネット電話ネットワークは、コンポーネントの2種類が含まれています。
End systems are devices which originate and/or receive signalling information and media. These include simple and complex telephone devices, PC telephony clients, and automated voice systems. The CPL abstracts away the details of the capabilities of these devices. An end system can originate a call; and it can accept, reject, or forward incoming calls. The details of this process (ringing, multi-line telephones, and so forth) are not important for the CPL.
エンドシステムは、発信および/または情報とメディアのシグナリングを受信する装置です。これらは、単純および複雑な電話装置、PCテレフォニークライアント、および自動音声システムが含まれます。 CPLは、これらのデバイスの機能の詳細を抽象化。エンドシステムは、コールを発信することができます。そしてそれは、受け入れ拒否、または着信呼を転送することができます。このプロセスの詳細は、（マルチライン電話を鳴らすなど）CPLのために重要ではありません。
For the purposes of the CPL, gateways -- for example, a device which connects calls between an IP telephony network and the PSTN -- are also considered to be end systems. Other devices, such as mixers or firewalls, are not directly dealt with by the CPL, and they will not be discussed here.
CPLの目的のために、ゲートウェイは、 - 例えば、IPテレフォニーネットワークとPSTNとの間の通話を接続する装置は、 - また、エンドシステムであると考えられます。そのようなミキサーやファイアウォールなどの他のデバイスは、直接CPLによって対処されていない、と彼らはここで議論されることはありません。
Signalling servers are devices which relay or control signalling information. In SIP, they are proxy servers, redirect servers, or registrars; in H.323, they are gatekeepers.
シグナリングサーバは、リレーや制御シグナリング情報機器です。 SIPでは、彼らは、サーバー、または登録機関をリダイレクトするプロキシサーバーです。 H.323で、彼らは門番です。
Signalling servers can perform three types of actions on call setup information. They can:
シグナリングサーバは、呼設定情報に対する操作の3種類を行うことができます。彼らは、次のことができます。
proxy it: forward it on to one or more other network or end systems, returning one of the responses received.
プロキシそれ：受信した応答のいずれかを返す、一の以上の他のネットワークまたはエンドシステムにそれを転送します。
redirect it: return a response informing the sending system of a different address to which it should send the request.
それをリダイレクトします。それは、要求を送信する先の異なるアドレスの送信システムを知らせる応答を返します。
reject it: inform the sending system that the setup request could not be completed.
それを拒否：セットアップ要求を完了できませんでした送信側システムに通知します。
RFC 2543 [1] has illustrations of proxy and redirect functionality. End systems may also be able to perform some of these actions: almost certainly rejection, and possibly redirection.
RFC 2543 [1]は、プロキシのイラストがあり、機能をリダイレクトします。ほぼ確実に除去、おそらくリダイレクト：エンドシステムは、これらのアクションのいくつかを実行することができます。
Signalling servers also normally maintain information about user location. Whether by means of registrations (SIP REGISTER or H.323 RAS messages), static configuration, or dynamic searches, signalling servers must have some means by which they can determine where a user is currently located, in order to make intelligent choices about their proxying or redirection behavior.
シグナリングサーバーは、通常、ユーザーの位置に関する情報を保持します。登録によって、サーバのシグナリング（SIP REGISTERまたはH.323 RASメッセージ）、静的な設定、または動的検索は、そのプロキシについてのインテリジェントな選択をするためには、ユーザが現在どこにあるか、彼らが判断することができるいくつかの手段を持っている必要があるかどうかまたはリダイレクト行動。
Signalling servers are also usually able to keep logs of transactions that pass through them, and to send e-mail to destinations on the Internet, under programmatic control.
シグナリングサーバーは、通常、また、それらを通過するトランザクションのログを維持する、とプログラム制御の下で、インターネット上の宛先に電子メールを送信することができます。
When an end system places a call, the call establishment request can proceed by a variety of routes through components of the network. To begin with, the originating end system must decide where to send its requests. There are two possibilities here: the originator may be configured so that all its requests go to a single local server; or it may resolve the destination address to locate a remote signalling server or end system to which it can send the request directly.
エンドシステムがコールをかけたときに、呼確立要求は、ネットワークの構成要素を介して種々の経路で進行することができます。まず、元のエンドシステムは、どこにその要求を送信することを決定しなければなりません。二つの可能性がここにあります：すべての要求は、単一のローカルサーバに行くように、発信者が構成することができます。またはそれは要求を直接送信することができたリモートシグナリングサーバまたはエンドシステムの位置を確認するために、宛先アドレスを解決することができます。
Once the request arrives at a signalling server, that server uses its user location database, its local policy, DNS resolution, or other methods, to determine the next signalling server or end system to which the request should be sent. A request may pass through any number of signalling servers: from zero (in the case when end systems communicate directly) to, in principle, every server on the network. What's more, any end system or signalling server can (in principle) receive requests from or send them to any other.
要求は、シグナリング・サーバに到着すると、そのサーバは、要求が送信すべき次シグナリングサーバまたはエンドシステムを決定するために、そのユーザ位置データベース、ローカルポリシー、DNS解決、または他の方法を使用します。リクエストは、サーバシグナリングの任意の数を通過することができる：（エンドシステムが直接通信する場合には）ゼロからの、原理的には、ネットワーク上のすべてのサーバを。しかも、すべてのエンドシステムまたはシグナリングサーバは（原則として）からの要求を受信したり、他に送信することができます。
For example, in figure 1, there are two paths the call establishment request information may take. For Route 1, the originator knows only a user address for the user it is trying to contact, and it is configured to send outgoing calls through a local outgoing proxy server. Therefore, it forwards the request to its local server, which finds the server of record for that address, and forwards it on to that server.
例えば、図1に、呼確立要求情報が取り得る2つの経路が存在します。ルート1の場合、発信者は、連絡しようとしている、そして地元の発信プロキシサーバを介して発信コールを送信するように設定されているユーザーのための唯一のユーザアドレスを知っています。したがって、それはそのアドレスのレコードのサーバーを見つけ、そのローカルサーバーに要求を転送し、そのサーバに転送します。
In this case, the organization the destination user belongs to uses a multi-stage setup to find users. The corporate server identifies which department a user is part of, then forwards the request to the appropriate departmental server, which actually locates the user. (This is similar to the way e-mail forwarding is often configured.) The response to the request will travel back along the same path.
この場合、先のユーザーが属する組織がユーザーを見つけるために、多段階のセットアップを使用しています。企業のサーバーは、ユーザーがの一部である部署を識別する、実際にユーザーを見つけ、適切な部門サーバに要求を転送します。 （これは、電子メール転送がしばしば構成されている方法と同様である。）の要求への応答は同じ経路に沿って戻って移動します。
For Route 2, however, the originator knows the specific device address it is trying to contact, and it is not configured to use a local outgoing proxy. In this case, the originator can directly contact the destination without having to communicate with any network servers at all.
ルート2の場合は、しかし、創始者は、連絡しようとしている特定のデバイスのアドレスを知っている、そして地元の発信プロキシを使用するように構成されていません。この場合、発信者は直接まったくネットワークサーバと通信することなく、先に連絡することができます。
We see, then, that in Internet telephony signalling servers cannot in general know the state of end systems they "control," since signalling information may have bypassed them. This architectural limitation implies a number of restrictions on how some services can be implemented. For instance, a network system cannot reliably know if an end system is currently busy or not; a call may have been placed to the end system without traversing that network system. Thus, signalling messages must explicitly travel to end systems to find out their state; in the example, the end system must explicitly return a "busy" indication.
私たちは、シグナリング情報は、それらをバイパスしている可能性があるからインターネット電話では、シグナリングサーバは、一般的に「制御」エンドシステム彼らの状態を知ることができないということ、それから、参照してください。このアーキテクチャ上の制限は、いくつかのサービスを実装する方法の制限数を意味します。エンドシステムが現在ビジーであるかどうかたとえば、ネットワークシステムが確実に知ることができません。コールは、そのネットワークシステムを横断することなく、エンド・システムに配置されている可能性があります。このように、シグナリングメッセージは、明示的にそれらの状態を調べるためにシステムを終了するには移動しなければなりません。一例では、エンド・システムは、明示的に「ビジー」表示を返さなければなりません。
Outgoing Corporate Departmental
Proxy Server Server
_______ Outgoing proxy contacts _______ _______
| | corporate server | | | |
| | -------------------------> | | ---------> | |
|_____| |_____| |_____|
Route 1 ^ \Searches
/ \ for
Sends to/ \ User
proxy / _|
_______ _______
| | Route 2 | |
| | ---------------------------------------------------> | |
|_____| Originator directly contacts destination |_____|
Originator Destination
発信先
Figure 1: Possible paths of call setup messages
図1：呼設定メッセージの可能なパス
7 Interaction of CPL with network model
ネットワークモデルとCPLの7の相互作用
A CPL script runs in a signalling server, and controls that system's proxy, redirect, or rejection actions for the set-up of a particular call. It does not attempt to coordinate the behavior of multiple signalling servers, or to describe features on a "Global Functional Plane" as in the Intelligent Network architecture [6].
CPLスクリプトは、シグナリングサーバで実行され、特定のコールのセットアップのため、そのシステムのプロキシ、リダイレクト、または拒否のアクションを制御します。これは、複数のシグナリングサーバーの動作を調整しようとしない、またはインテリジェントネットワークアーキテクチャ[6]のように「グローバル・機能面」に機能を説明します。
More specifically, a script replaces the user location functionality of a signalling server. As described in section 6.1.2, a signalling server typically maintains a database of locations where a user can be reached; it makes its proxy, redirect, and rejection decisions based on the contents of that database. A CPL script replaces this basic database lookup functionality; it takes the registration information, the specifics of a call request, and other external information it wants to reference, and chooses the signalling actions to perform.
具体的には、このスクリプトは、シグナリングサーバのユーザ位置の機能を置き換えます。セクション6.1.2で説明したように、シグナリング・サーバは、典型的には、ユーザが到達できる場所のデータベースを維持します。それはそのプロキシ、リダイレクト、およびそのデータベースの内容に基づいて拒否を決定します。 CPLスクリプトは、この基本的なデータベース検索機能を置き換えます。それが参照したい登録情報、コール要求の詳細、およびその他の外部情報を取得し、実行するためのシグナリングアクションを選択します。
Abstractly, a script can be considered as a list of condition/action pairs; if some attribute of the registration, request, and external information matches a given condition, then the corresponding action (or more properly set of actions) is taken. In some circumstances, additional actions can be taken based on the consequences of the first action and additional conditions. If no condition matches the invitation, the signalling server's standard action -- its location database lookup, for example -- is taken.
抽象的に、スクリプトは条件/アクションのペアのリストとして考えることができます。登録、要求、および外部情報の一部の属性が与えられた条件に一致した場合、その後、（より適切にアクションのセットまたは）、対応するアクションが実行されます。状況によっては、追加のアクションは、最初のアクションと追加条件の結果に基づいて撮影することができます。そのロケーションデータベース検索、例えば - - 取られるいかなる条件が招待、シグナリング・サーバの標準アクションと一致しない場合。
CPL scripts are usually associated with a particular Internet telephony address. When a call establishment request arrives at a signalling server which is a CPL server, that server associates the source and destination addresses specified in the request with its database of CPL scripts; if one matches, the corresponding script is executed.
CPLスクリプトは通常、特定のインターネット電話アドレスに関連付けられています。呼確立要求は、CPLサーバでシグナリング・サーバに到着すると、そのサーバは、CPLスクリプトをそのデータベースと、要求で指定された送信元アドレスと宛先アドレスを関連付けます。 1が一致した場合、対応するスクリプトが実行されます。
Once the script has executed, if it has chosen to perform a proxy action, a new Internet telephony address will result as the destination of that proxying. Once this has occurred, the server again checks its database of scripts to see if any of them are associated with the new address; if one is, that script as well is executed (assuming that a script has not attempted to proxy to an address which the server has already tried). For more details of this recursion process, and a description of what happens when a server has scripts that correspond both to a scripts origination address and its destination address, see section 9.2.
スクリプトが実行されたら、それはプロキシアクションを実行することを選択した場合は、新しいインターネット電話アドレスは、そのプロキシの宛先として発生します。これが発生すると、サーバが再びそれらのいずれかを新しいアドレスに関連付けられているかどうかを確認するために、スクリプトのそのデータベースをチェックします。一方があれば、同様に実行されるスクリプトは、（スクリプトは、サーバーが既に試みたアドレスにプロキシにしようとしていないと仮定して）。もっとこの再帰処理の詳細、およびサーバがスクリプトの発信元アドレスと宛先アドレスの両方に対応するスクリプトを持っているときに何が起こるかの説明については、セクション9.2を参照。
In general, in an Internet telephony network, an address will denote one of two things: either a user, or a device. A user address refers to a particular individual, for example sip:joe@example.com, regardless of where that user actually is or what kind of device he or she is using. A device address, by contrast, refers to a particular physical device, such as sip:x26063@phones.example.com. Other, intermediate sorts of addresses are also possible, and have some use (such as an address for "my cell phone, wherever it currently happens to be registered"), but we expect them to be less common. A CPL script is agnostic to the type of address it is associated with; while scripts associated with user addresses are probably the most useful for most services, there is no reason that a script could not be associated with any other type of address as well. The recursion process described above allows scripts to be associated with several of a user's addresses; thus, a user script could specify an action "try me at my cell phone," whereas a device script could say "I don't want to accept cell phone calls while I'm out of my home area."
ユーザー、またはデバイスのいずれか：一般的には、インターネット電話ネットワークで、アドレスは2つのうちのいずれかを表します。かかわらず、そのユーザーが実際にあるか、彼または彼女が使用しているデバイスの種類をどこの、joe@example.com：ユーザーのアドレスは、例えば、SIPのために、特定の個人を指します。 x26063@phones.example.com：デバイスアドレスは、対照的に、SIPなど、特定の物理デバイスを指します。アドレスの他、中間のソートも可能であり、かつ（「現在登録されていることを起こるところはどこでも私の携帯電話、」などのアドレスなど）いくつかの使用を持っているが、我々は彼らがあまり一般的であることを期待しています。 CPLスクリプトは、それが関連付けられているアドレスの種類にとらわれません。ユーザーのアドレスに関連付けられたスクリプトは、おそらくほとんどのサービスのために最も有用であるが、スクリプトは同様のアドレスの他のタイプに関連付けることができなかったという理由はありません。上記再帰プロセスは、スクリプトは、ユーザのアドレスのいくつかに関連することが可能となります。デバイススクリプトが言うことができるのに対し、このように、ユーザースクリプトは「私の携帯電話で私を試してみてください」アクションを指定することができ、「私は私のホームエリアの外だしながら、携帯電話の通話を受け入れるようにしたくありません。」
It is also possible for a CPL script to be associated not with one specific Internet telephony address, but rather with all addresses handled by a signalling server, or a large set of them. For instance, an administrator might configure a system to prevent calls from or to a list of banned incoming or outgoing addresses; these should presumably be configured for everyone, but users should still to be able to have their own custom scripts as well. Exactly when such scripts should be executed in the recursion process depends on the precise nature of the administrative script. See section 9.2 for further discussion of this.
CPLスクリプトはなく、むしろ、シグナリングサーバ、またはそれらの大規模なセットで扱うすべてのアドレスと、ある特定のインターネット電話のアドレスに関連付けられていないすることも可能です。たとえば、管理者が禁止着信または発信アドレスのリストから、またはへの呼び出しを防ぐために、システムを構成することができます。これらはおそらく皆のために設定する必要がありますが、ユーザーはまだだけでなく、独自のカスタムスクリプトを持つことができるようにすべきです。そのようなスクリプトは、再帰プロセスで実行する必要があります正確にいつ管理スクリプトの正確な性質に依存します。これのさらなる議論のためのセクション9.2を参照してください。
Users can have CPL scripts on any network server which their call establishment requests pass through and with which they have a trust relationship. For instance, in the example in figure 1, the originating user could have a script on the outgoing proxy, and the destination user could have scripts on both the corporate server and the departmental server. These scripts would typically perform different functions, related to the role of the server on which they reside; a script on the corporate-wide server could be used to customize which department the user wishes to be found at, for instance, whereas a script at the departmental server could be used for more fine-grained location customization. Some services, such as filtering out unwanted calls, could be located at either server. See section 9.3 for some implications of a scenario like this.
ユーザーは、呼確立要求が通過していると、彼らは信頼関係を持っている任意のネットワーク・サーバ上のCPLスクリプトを持つことができます。例えば、図1の例では、発信側ユーザが発信プロキシ上でスクリプトを持っている可能性があり、宛先ユーザは、企業のサーバーや部門サーバーの両方でスクリプトを持つことができます。これらのスクリプトは、通常、彼らが置かれているサーバーの役割に関連し、異なる機能を実行することになり、全社的なサーバー上のスクリプトは、部門サーバーでのスクリプトは、よりきめの細かい場所のカスタマイズのために使用することができたユーザーは、例えば、で見つけることを希望する部署をカスタマイズするために使用することができます。不要な通話をフィルタリングするなど、一部のサービスは、いずれかのサーバーに配置することができます。このようなシナリオのいくつかの意味合いのためのセクション9.3を参照してください。
This model does not specify the means by which users locate a CPL-capable network server. In general, this will be through the same means by which they locate a local Internet telephony server to register themselves with; this may be through manual configuration, or through automated means such as the Service Location Protocol [7]. It has been proposed that automated means of locating such servers should include a field to indicate whether the server allows users to upload CPLs.
このモデルは、ユーザーがCPL対応のネットワーク・サーバを見つけるする手段を指定しません。一般的に、これは彼らが自分自身を登録するローカルインターネットテレフォニーサーバを見つけたことで、同じ手段でになります。これは、手動設定を介して、又はそのようなサービスロケーションプロトコル[7]のような自動化された手段を介してもよいです。そのようなサーバを配置する自動化された手段は、サーバーは、ユーザーがのCPLをアップロードすることを可能にするかどうかを示すためにフィールドを含めるべきであると提案されています。
8 Creation and transport of a call processing language script
8作成し、呼処理言語スクリプトの輸送
Users create call processing language scripts, typically on end devices, and transmit them through the network to signalling servers. Scripts persist in signalling servers until changed or deleted, unless they are specifically given an expiration time; a network system which supports CPL scripting will need stable storage.
ユーザーは、エンドデバイスに一般的に、呼処理言語スクリプトを作成、およびシグナリングサーバにネットワークを介してそれらを送信します。スクリプトは、彼らが特に有効期限を与えられていない限り、変更または削除されるまでのサーバに信号を送るに固執します。 CPLスクリプトをサポートしているネットワークシステムは、安定したストレージが必要になります。
The end device on which the user creates the CPL script need not bear any relationship to the end devices to which calls are actually placed. For example, a CPL script might be created on a PC, whereas calls might be intended to be received on a simple audio-only telephone. Indeed, the device on which the script is created may not be an "end device" in the sense described in section 6.1.1 at all; for instance, a user could create and upload a CPL script from a non-multimedia-capable web terminal.
ユーザーがエンドデバイスへのいかなる関係を持つ必要はありませんCPLスクリプトを作成するには、エンドデバイスは、呼び出しが実際に配置されています。呼び出しは、単純な音声のみの電話で受信されることを意図されるかもしれないのに対し、例えば、CPLスクリプトは、PC上で作成されることがあります。実際に、スクリプトが作成されたデバイスは、すべてのセクション6.1.1に記載の意味において、「エンドデバイス」でなくてもよいです。例えば、ユーザーは、非マルチメディア対応のWeb端末からCPLスクリプトを作成してアップロードすることができます。
The CPL also might not necessarily be created on a device near either the end device or the signalling server in network terms. For example, a user might decide to forward his or her calls to a remote location only after arriving at that location.
CPLはまた、必ずしもエンドデバイスまたはネットワーク用語でシグナリング・サーバーのいずれかの近くにデバイス上に作成されないことがあります。たとえば、ユーザーが唯一のその場所に到着した後、遠隔地に彼または彼女のコールを転送することを決定するかもしれません。
The exact means by which the end device transmits the script to the server remains to be determined; it is likely that many solutions will be able to co-exist. This method will need to be authenticated in almost all cases. The methods that have been suggested include web file upload, SIP REGISTER message payloads, remote method invocation, SNMP, ACAP, LDAP, and remote file systems such as NFS.
エンドデバイスは、サーバにスクリプトを送信する正確な手段がまだ決定されていません。多くのソリューションが共存できるようになると思われます。この方法は、ほとんどすべての場合には、認証する必要があります。提案されている方法は、Webファイルのアップロード、SIP REGISTERメッセージのペイロードを、リモートメソッドの呼び出し、SNMP、ACAP、LDAP、およびNFSなどのリモート・ファイル・システムが含まれます。
Users can also retrieve their current script from the network to an end system so it can be edited. The signalling server should also be able to report errors related to the script to the user, both static errors that could be detected at upload time, and any run-time errors that occur.
それは編集することができるので、ユーザーはまた、エンドシステムにネットワークから自分の現在のスクリプトを取得することができます。シグナリング・サーバはまた、静的アップロード時に検出することができ、エラー、および発生したすべての実行時エラーの両方のユーザにスクリプトに関連するエラーを報告することができるはずです。
If a user has trust relationships with multiple signalling servers (as discussed in section 7.3), the user may choose to upload scripts to any or all of those servers. These scripts can be entirely independent.
ユーザーが複数のシグナリングサーバ（7.3節で説明したように）との信頼関係を持っている場合、ユーザーは、これらのサーバーのいずれかまたは全てにスクリプトをアップロードすることもできます。これらのスクリプトは、完全に独立することができます。
9 Feature interaction behavior
9機能の相互作用行動
Feature interaction is the term used in telephony systems when two or more requested features produce ambiguous or conflicting behavior [8]. Feature interaction issues for features implemented with a call processing language can be roughly divided into three categories: feature-to-feature in one server, script-to-script in one server, and server-to-server.
機能の相互作用は、二つ以上の要求された機能は、あいまいなまたは矛盾する行動を生成するとき、テレフォニーシステムで使用される用語である[8]。一つのサーバにスクリプトをスクリプト、一つのサーバで機能ツー機能を、およびサーバー間：呼処理言語で実装された機能のための機能の相互作用の問題は大きく3つのカテゴリに分けることができます。
Due to the explicit nature of event conditions discussed in the previous section, feature-to-feature interaction is not likely to be a problem in a call processing language environment. Whereas a subscriber to traditional telephone features might unthinkingly subscribe to both "call waiting" and "call forward on busy," a user creating a CPL script would only be able to trigger one action in response to the condition "a call arrives while the line is busy." Given a good user interface for creation, or a CPL server which can check for unreachable code in an uploaded script, contradictory condition/action pairs can be avoided.
前のセクションで説明したイベント条件の明示的な性質のために、機能・ツー・機能の相互作用は、呼処理言語環境で問題になりそうではありません。従来の電話機能への加入者がunthinkingly「キャッチホン」との両方に加入する可能性があるのに対し、「忙しい上のコール転送、」CPLスクリプトを作成しているユーザーのみ「状態に応答して、1つのアクションをトリガーすることができるだろうコールはラインながら到着します忙しい。"創造のための優れたユーザー・インターフェース、またはアップロードスクリプトに到達不能コードをチェックすることができるCPLサーバーを考えると、矛盾した条件/アクションのペアを回避することができます。
Script-to-script interactions arise when a server invokes multiple scripts for a single call, as described in section 7.2. This can occur in a number of cases: if both the call originator and the destination have scripts specified on a single server; if a script forwards a request to another address which also has a script; or if an administrative script is specified as well as a user's individual script.
7.2節で説明したように、サーバーは、単一の呼び出しのために複数のスクリプトを呼び出したときに、スクリプト・ツー・スクリプトの相互作用が生じます。これは、多くのケースで発生する可能性があります発信と宛先の両方を単一のサーバー上で指定されたスクリプトがある場合。また、このスクリプトは、スクリプトを持っている別のアドレスに要求を転送する場合。または管理スクリプトは、ユーザーの個々のスクリプトとしても指定されている場合。
The solution to this interaction is to determine an ordering among the scripts to be executed. In this ordering, the "first" script is executed first; if this script allows or permits the call to be proxied, the script corresponding to the next address is executed. When the first script says to forward the request to some other address, those actions are considered as new requests which arrive at the second script. When the second script sends back a final response, that response arrives at the first script in the same manner as if a request arrived over the network. Note that in some cases, forwarding can be recursive; a CPL server must be careful to prevent forwarding loops.
この相互作用を解決するには、実行されるスクリプトの間の順序を決定することです。この順序では、「最初の」スクリプトが最初に実行されます。このスクリプトは、プロキシされるための呼び出しを許可するか、許可する場合、次のアドレスに対応するスクリプトが実行されます。最初のスクリプトは、いくつかの他のアドレスに要求を転送するために言うとき、これらのアクションは、2番目のスクリプトに到着する新しい要求として考えられています。 2番目のスクリプトは、最終的な応答を返す場合、要求は、ネットワークを介して到着したかのように、その応答は、同様に最初のスクリプトに到達します。いくつかのケースでは、転送は再帰することができないことに注意してください。 CPLサーバーは、転送ループを防ぐために注意しなければなりません。
Abstractly, this can be viewed as equivalent to having each script execute on a separate signalling server. Since the CPL architecture is designed to allow scripts to be executed on multiple signalling servers in the course of locating a user, we can conceptually transform script-to-script interactions into the server-to-server interactions described in the next section, reducing the number of types of interactions we need to concern ourselves with.
抽象的に、これは、各スクリプトは別個のシグナリングサーバ上で実行することと等価とみなすことができます。 CPLアーキテクチャはスクリプトは、ユーザの位置を特定する過程で複数のシグナリング・サーバ上で実行されることを可能にするように設計されているので、我々は、概念的に低減、次のセクションで説明したサーバー間の相互作用にスクリプト・ツー・スクリプトの相互作用を変換することができ相互作用の種類の数は、私たちはと自分自身を懸念する必要があります。
The question, then, is to determine the correct ordering of the scripts. For the case of a script forwarding to an address which also has a script, the ordering is obvious; the other two cases are somewhat more subtle. When both originator and destination scripts exist, the originator's script should be executed before the destination script; this allows the originator to perform address translation, call filtering, etc., before a destination address is determined and a corresponding script is chosen.
問題は、その後、スクリプトの正しい順序を決定することです。また、スクリプトを持っていたアドレスに転送するスクリプトの場合には、順序は明白です。他の2例は、やや微妙です。両方の発信元と送信先のスクリプトが存在する場合には、発信者のスクリプトは、先のスクリプトの前に実行する必要があります。宛先アドレスが決定され、対応するスクリプトが選択される前には、発信等アドレス変換、コールフィルタリングを実行することを可能にします。
Even more complicated is the case of the ordering of administrative scripts. Many administrative scripts, such as ones that restrict source and destination addresses, need to be run after originator scripts, but before destination scripts, to avoid a user's script evading administrative restrictions through clever forwarding; however, others, such as a global address book translation function, would need to be run earlier or later. Servers which allow administrative scripts to be run will need to allow the administrator to configure when in the script execution process a particular administrative script should fall.
さらに複雑な管理スクリプトの順序付けの場合です。そのような送信元と送信先アドレスを制限するものとして、多くの管理スクリプトは、発信元のスクリプトの後に実行する必要があるが、先のスクリプトの前に、巧妙な転送による行政の制限を回避するユーザーのスクリプトを避けるために、しかし、そのようなグローバルアドレス帳変換機能として他の人が、前または後に実行する必要があります。スクリプトの実行過程で、特定の管理スクリプトが落ちる必要があるときに管理スクリプトを実行することを可能にするサーバーは、管理者が設定できるようにする必要があります。
The third case of feature interactions, server-to-server interactions, is the most complex of these three. The canonical example of this type of interaction is the combination of Originating Call Screening and Call Forwarding: a user (or administrator) may wish to prevent calls from being placed to a particular address, but the local script has no way of knowing if a call placed to some other, legitimate address will be proxied, by a remote server, to the banned address. This type of problem is unsolvable in an administratively heterogeneous network, even a "lightly" heterogeneous network such as current telephone systems. CPL does not claim to solve it, but the problem is not any worse for CPL scripts than for any other means of deploying services.
機能の相互作用、サーバ間の相互作用の三番目のケースでは、これら三つの中で最も複雑です。この種の相互作用の標準的な例は、発信通話スクリーニングと通話転送の組み合わせです：ユーザー（または管理者）が特定のアドレスに配置されてからの呼び出しを防ぐことを望むかもしれませんが、地元のスクリプトがあれば通話を知る方法はありませんいくつかの他に置かれ、正当なアドレスが禁止されたアドレスに、リモートサーバによって、プロキシされます。この種の問題は、行政異種ネットワークでは、このような現在の電話システムとしても、「軽く」異種ネットワーク解決不可能です。 CPLは、それを解決するために主張しませんが、問題は、サービスを展開する他の手段よりもCPLスクリプトの任意の悪いことではありません。
Another class of server-to-server interactions are best resolved by the underlying signalling protocol, since they can arise whether the signalling servers are being controlled by a call processing language or by some entirely different means. One example of this is forwarding loops, where user X may have calls forwarded to Y, who has calls forwarded back to X. SIP has a mechanism to detect such loops. A call processing language server thus does not need to define any special mechanisms to prevent such occurrences; it should, however, be possible to trigger a different set of call processing actions in the event that a loop is detected, and/or to report back an error to the owner of the script through some standardized run-time error reporting mechanism.
彼らは、シグナリングサーバは、呼処理言語によって、あるいはいくつかの全く異なる手段によって制御されているかどうか発生する可能性があるため、サーバー間の相互作用の別のクラスは最高の、基本的なシグナリングプロトコルによって解決されます。この一例は、ユーザXは、そのようなループを検出するための機構を有するX. SIPにバック転送されたコールを有するYに転送されたコールを有することができるループを転送しています。呼処理言語サーバは、このような発生を防ぐために、特別なメカニズムを定義する必要はありません。しかし、ループが検出された場合に、呼処理動作の異なるセットをトリガすることが可能でなければならない、および/またはいくつかの標準化された実行時エラー報告機構を介してスクリプトの所有者にエラーを折り返し報告します。
As an aside, [8] discusses a fourth type of feature interaction for traditional telephone networks, signalling ambiguity. This can arise when several features overload the same operation in the limited signal path from an end station to the network: for example, flashing the switch-hook can mean both "add a party to a three-way call" and "switch to call waiting." Because of the explicit nature of signalling in both the Internet telephony protocols discussed here, this issue does not arise.
余談として、[8]曖昧さをシグナリング、従来の電話ネットワークのための機能競合の第4のタイプを説明します。例えば、スイッチフックを点滅意味することができます両方呼び出すことと「スイッチ「の三者通話にパーティを追加」：いくつかの機能は、ネットワークへのエンドステーションからの制限された信号経路に同じ操作をオーバーロードするとき、これが発生する可能性が待っています。」そのため、ここで議論し、インターネットテレフォニープロトコルの両方におけるシグナル伝達の明示的な性質から、この問題は発生しません。
10 Relationship with existing languages
既存の言語と10の関係
This document's description of the CPL as a "language" is not intended to imply that a new language necessarily needs to be implemented from scratch. A server could potentially implement all the functionality described here as a library or set of extensions for an existing language; Java, or the various freely-available scripting languages (Tcl, Perl, Python, Guile), are obvious possibilities.
「言語」としてのCPLのこのドキュメントの説明は、新しい言語は、必ずしも最初から実装する必要があることを意味するものではありません。サーバーは、潜在的にライブラリとして、ここで説明したり、既存の言語の拡張セットのすべての機能を実装することができ、 Javaの、または様々な自由に利用可能なスクリプト言語（TCL、PerlやPython、ガイル）、明白な可能性があります。
However, there are motivations for creating a new language. All the existing languages are, naturally, expressively complete; this has two inherent disadvantages. The first is that any function implemented in them can take an arbitrarily long time, use an arbitrarily large amount of memory, and may never terminate. For call processing, this sort of resource usage is probably not necessary, and as described in section 12.1, may in fact be undesirable. One model for this is the electronic mail filtering language Sieve [4], which deliberately restricts itself from being Turing-complete.
しかし、新しい言語を作成するための動機があります。すべての既存の言語は、自然に、表情豊かに完了しています。これは、二つの固有の欠点があります。最初は彼らに実装する関数は、任意に長い時間がかかり、メモリの任意の大きな量を使用し、終了しないかもしれないということです。呼処理のために、リソースの使用状況のこの種は、おそらく必要ではなく、セクション12.1で説明したように、実際には望ましくないかもしれません。このための一つのモデルは、電子メール故意チューリング完全であることから自分自身を制限するフィルタリング言語ふるい[4]です。
Similar levels of safety and protection (though not automatic generation and parsing) could also be achieved through the use of a "sandbox" such as is used by Java applets, where strict bounds are imposed on the amount of memory, cpu time, stack space, etc., that a program can use. The difficulty with this approach is primarily in its lack of transparency and portability: unless the levels of these bounds are imposed by the standard, a bad idea so long as available resources are increasing exponentially with Moore's Law, a user can never be sure whether a particular program can successfully be executed on a given server without running into the server's resource limits, and a program which executes successfully on one server may fail unexpectedly on another. Non-expressively-complete languages, on the other hand, allow an implicit contract between the script writer and the server: so long as the script stays within the rules of the language, the server will guarantee that it will execute the script.
安全保護（ない自動生成及び解析が）同様のレベルはまた、厳密な境界は、メモリの量に課されるJavaアプレット、CPU時間、スタック領域で使用されるような「サンドボックス」を使用することによって達成することができますなど、プログラムを使用することができます。このアプローチの難しさは、透明性と移植性の欠如で、主に次のとおりです。これらの境界のレベルは、標準によって課されていない限り、悪い考えであれば、利用可能なリソースは、ユーザーがかどうかを確認することはできません、ムーアの法則で指数関数的に増加しているとして、特定のプログラムが正常にサーバのリソース制限に実行することなく、特定のサーバー上で実行することができ、1台のサーバー上で正常に実行するプログラムは、他に予期せずに失敗してもよいです。非表情豊かに完全な言語は、他の一方で、スクリプトライターとサーバ間の暗黙の契約を許可する：限り、スクリプト言語のルール内に留まるように、サーバは、それがスクリプトを実行することを保証します。
The second disadvantage with expressively complete languages is that they make automatic generation and parsing of scripts very difficult, as every parsing tool must be a full interpreter for the language. An analogy can be drawn from the document-creation world: while text markup languages like HTML or XML can be, and are, easily manipulated by smart editors, powerful document programming languages such as LaTeX or Postscript usually cannot be. While there are word processors that can save their documents in LaTeX form, they cannot accept as input arbitrary LaTeX documents, let alone preserve the structure of the original document in an edited form. By contrast, essentially any HTML editor can edit any HTML document from the web, and the high-quality ones preserve the structure of the original documents in the course of editing them.
表情豊かに完全な言語と第2の欠点は、すべての解析ツールが言語のための完全な通訳でなければならないとして、彼らはスクリプトの自動生成と解析が非常に困難になるということです。アナロジーは、文書作成の世界から引き出すことができる：HTMLやXMLなどのテキストマークアップ言語をすることができながら、かつ、簡単にスマートエディタによって操作され、例えばラテックスまたはポストスクリプトなどの強力な文書のプログラミング言語は、通常はすることはできません。 LaTeXの形でその文書を保存することができますワードプロセッサがあるが、それらは入力任意のLaTeX文書として受け入れ、おろか編集した形で、元の文書の構造を維持することはできません。これとは対照的に、本質的に任意のHTMLエディタでは、ウェブから任意のHTMLドキュメントを編集することができ、高品質のものは、それらを編集する過程で、元の文書の構造を維持します。
11 Related work
11関連作品
The ITU's IN series describe, on an abstract level, service creation environments [6]. These describe services in a traditional circuit-switched telephone network as a series of decisions and actions arranged in a directed acyclic graph. Many vendors of IN services use modified and extended versions of this for their proprietary service creation environments.
シリーズのITUのは、サービス作成環境は、[6]、抽象的なレベルで、説明します。これらは、非循環有向グラフに配置された意思決定とアクションのシリーズとして従来の回線交換電話網でのサービスについて説明します。 INサービスの多くのベンダーは、彼らの独自のサービス作成環境のため、このの修正および拡張バージョンを使用します。
SIP CGI [9] is an interface for implementing services on SIP servers. Unlike a CPL, it is a very low-level interface, and would not be appropriate for services written by non-trusted users.
SIP CGI [9]はSIPサーバ上のサービスを実装するためのインタフェースです。 CPLとは異なり、それは非常に低レベルのインタフェースであり、信頼できないユーザによって書かれたサービスのために適切ではありません。
The paper "Programming Internet Telephony Services" [10] discusses the similarities and contrasts between SIP CGI and CPL in more detail.
論文「プログラミングインターネット電話サービス」[10]の類似性を説明し、より詳細にSIP CGIおよびCPL間は対照的です。
12 Necessary language features
12の必要な言語機能
This section lists those properties of a call processing language which we believe to be necessary to have in order to implement the motivating examples, in line with the described architecture.
このセクションでは説明したアーキテクチャに沿って、私たちはやる気の例を実装するために持っていることが必要であると信じる呼処理言語のこれらのプロパティを示しています。
These are some abstract attributes which any proposed call processing language should possess.
これらは、いずれの提案呼処理言語は持っていなければならないいくつかの抽象的属性です。
o Light-weight, efficient, easy to implement
実装するO軽量、効率的で、使いやすいです
In addition to the general reasons why this is desirable, a network server might conceivably handle very large call volumes, and we don't want CPL execution to be a major bottleneck. One way to achieve this might be to compile scripts before execution.
これが望ましい理由は、一般的な理由に加えて、ネットワーク・サーバは、おそらく非常に大規模なコールボリュームを扱うかもしれない、と私たちは、CPLの実行が大きなボトルネックになりたくありません。これを達成する1つの方法は、実行前にスクリプトをコンパイルするかもしれません。
o Easily verifiable for correctness
正しさのためにOを簡単に検証可能
For a script which runs in a server, mis-configurations can result in a user becoming unreachable, making it difficult to indicate run-time errors to a user (though a second-channel error reporting mechanism such as e-mail could ameliorate this). Thus, it should be possible to verify, when the script is committed to the server, that it is at least syntactically correct, does not have any obvious loops or other failure modes, and does not use too many server resources.
（電子メールなどのメカニズムを報告する第二チャネル・エラーがこれを改善することができますが）サーバーで実行されるスクリプトの場合は、誤構成は、それが困難なユーザーに実行時エラーを示すために作り、到達不能になってユーザーにつながることができます。このように、スクリプトはそれが、少なくとも文法的に正しいことを、サーバーにコミットされたとき、それは、検証することが可能なはずである、任意の明白なループまたは他の故障モードを持っていない、とあまりにも多くのサーバリソースを使用しません。
o Executable in a safe manner
安全な方法で実行可能なO
No action the CPL script takes should be able to subvert anything about the server which the user shouldn't have access to, or affect the state of other users without permission. Additionally, since CPL scripts will typically run on a server on which users cannot normally run code, either the language or its execution environment must be designed so that scripts cannot use unlimited amounts of network resources, server CPU time, storage, or memory.
CPLスクリプトが取るアクションは、ユーザーがアクセス権を持っている、または許可なしに、他のユーザの状態に影響を与えるべきではないサーバーについては何も覆すことはできないはずです。また、CPL以来、スクリプトは通常、スクリプトは、ネットワークリソースの無制限の量を使用することはできませんように、言語やその実行環境のいずれかが、サーバーのCPU時間、ストレージ、メモリを設計する必要があり、ユーザーは通常のコードを実行することはできませんれているサーバー上で実行されます。
o Easily writeable and parsable by both humans and machines.
O簡単に書き込み可能と人間と機械の両方によって解析可能。
For maximum flexibility, we want to allow humans to write their own scripts, or to use and customize script libraries provided by others. However, most users will want to have a more intuitive user-interface for the same functionality, and so will have a program which creates scripts for them. Both cases should be easy; in particular, it should be easy for script editors to read human-generated scripts, and vice-versa.
最大の柔軟性のために、私たちは人間が独自のスクリプトを書くこと、または他者が提供するスクリプトライブラリを使用してカスタマイズできるようにしたいです。しかし、ほとんどのユーザーは、同じ機能のために、より直感的なユーザ・インタフェースを持っていることになるでしょう、そしてので、それらのスクリプトを作成するプログラムを持っています。どちらの場合は、簡単にする必要があります。特に、それはスクリプトエディタ人間が生成したスクリプトを読むこと、およびその逆のために簡単にする必要があります。
o Extensible
O拡張
It should be possible to add additional features to a language in a way that existing scripts continue to work, and existing servers can easily recognize features they don't understand and safely inform the user of this fact.
既存のスクリプトが動作し続けるように、言語に追加機能を追加することが可能であるべきであり、既存のサーバーを簡単に、彼らは理解していない機能を認識し、安全にこの事実をユーザに知らせることができます。
o Independent of underlying signalling details
基本的なシグナリングの詳細とは独立してO
The same scripts should be usable whether the underlying protocol is SIP, H.323, a traditional telephone network, or any other means of setting up calls. It should also be agnostic to address formats. (We use SIP terminology in our descriptions of requirements, but this should map fairly easily to other systems.) It may also be useful to have the language extend to processing of other sorts of communication, such as e-mail or fax.
同じスクリプトは、基礎となるプロトコルは、SIP、H.323、伝統的な電話網、または呼の設定の任意の他の手段であるか否かを利用可能であるべきです。また、アドレス形式にとらわれないでなければなりません。 （私たちは、要件の私たちの説明でSIPの用語を使用していますが、これは他のシステムにかなり容易にマップする必要があります。）また、言語は、このような電子メールやファックスなどの通信の他の種類の処理に及ぶ持つことが有用である可能性があります。
To be useful, a call processing language obviously should be able to react to and initiate call signalling events.
有用であるために、呼処理言語は明らかに反応し、コールシグナリングイベントを開始することができなければなりません。
o Should execute actions when a call request arrives
コール要求が到着したときにoがアクションを実行する必要があります
See section 7, particularly 7.1.
セクション7、特に7.1を参照してください。
o Should be able to make decisions based on event properties
oはイベントプロパティに基づいて意思決定を行うことができるはずです
A number of properties of a call event are relevant for a script's decision process. These include, roughly in order of importance:
コールイベントのプロパティの数は、スクリプトの決定プロセスに関連しています。これらは、重要性の高い順におおまかに、次のとおりです。
- Destination address
- 宛先アドレス
We want to be able to do destination-based routing or screening. Note that in SIP we want to be able to filter on either or both of the addresses in the To header and the Request-URI.
私たちは、宛先ベースのルーティングまたはスクリーニングを行うことができるようにしたいです。 SIPに我々はToヘッダー内のアドレスとRequest-URIのいずれかまたは両方にフィルタリングできるようにすることに注意してください。
- Originator address
- 発信元アドレス
Similarly, we want to be able to do originator-based screening or routing.
同様に、我々は、発信元ベースのスクリーニングやルーティングを行うことができるようにしたいです。
- Caller Preferences
- 発信者の環境設定
In SIP, a caller can express preferences about the type of device to be reached -- see [11]. The script should be able to make decisions based on this information.
SIPは、発呼者に到達するデバイスのタイプに関する好みを表現することができる - [11]を参照します。スクリプトは、この情報に基づいて意思決定を行うことができるはずです。
- Information about caller or call
- 発信者またはコールに関する情報
SIP has textual fields such as Subject, Organization, Priority, etc., and a display name for addresses; users can also add non-standard additional headers. H.323 has a single Display field. The script should be able to make decisions based on these parameters.
SIPは、など件名、組織、優先順位、およびアドレスの表示名などのテキストフィールドがあります。ユーザーはまた、非標準の追加のヘッダを追加することができます。 H.323は、単一の表示フィールドを持っています。このスクリプトは、これらのパラメータに基づいて決定を下すことができるはずです。
- Media description
- メディアの説明
Call invitations specify the types of media that will flow, their bandwidth usage, their network destination addresses, etc. The script should be able to make decisions based on these media characteristics.
通話の招待状は、スクリプトがこれらのメディアの特性に基づいて決定を下すことができるはず、など彼らの帯域幅の使用、彼らのネットワークの宛先アドレスを、流入するメディアの種類を指定します。
- Authentication/encryption status
- 認証/暗号化ステータス
Call invitations can be authenticated. Many properties of the authentication are relevant: the method of authentication/encryption, who performed the authentication, which specific fields were encrypted, etc. The script should be able to make decisions based on these security parameters.
通話の招待状を認証することができます。認証の多くのプロパティは関連していますなどの特定のフィールドが暗号化された認証を行い、認証/暗号化の方法、スクリプトは、これらのセキュリティパラメータに基づいて決定を下すことができるはずです。
o Should be able to take action based on a call invitation
oは、コールの招待状に基づいて行動を取ることができるはずです
There are a number of actions we can take in response to an incoming call setup request. We can:
私たちは、着信呼設定要求に応じて実行できるアクションの数があります。私たちはできる：
- reject it
- それを拒否
We should be able to indicate that the call is not acceptable or not able to be completed. We should also be able to send more specific rejection codes (including, for SIP, the associated textual string, warning codes, or message payload).
私たちは、呼び出しが完了することができ許容できるかどうかではないことを示すことができるはずです。我々はまた、（関連するテキスト文字列、警告コード、またはメッセージ・ペイロード、SIPのため、など）、より具体的な拒絶コードを送信することができなければなりません。
- redirect it
- それをリダイレクト
We should be able to tell the call initiator sender to try a different location.
私たちは、別の場所を試してコールイニシエータの送信者に伝えることができるはずです。
- proxy it
- プロキシそれ
We should be able to send the call invitation on to another location, or to several other locations ("forking" the invitation), and await the responses. It should also be possible to specify a timeout value after which we give up on receiving any definitive responses.
私たちは別の場所に、またはいくつかの他の場所に（招待状を「フォーク」）上のコールの招待状を送信することができ、および応答を待つ必要があります。また、我々はすべての決定的な応答を受信をあきらめた後のタイムアウト値を指定することが可能なはずです。
o Should be able to take action based a response to a proxied or forked call invitation
oはプロキシやフォークコールの招待への応答に基づく行動をとることができるはずです
Once we have proxied an invitation, we need to be able to make decisions based on the responses we receive to that invitation (or the lack thereof). We should be able to:
私たちは招待状をプロキシしたら、我々はその招待状（またはその欠如）に受信応答に基づいて決定を下すことができるようにする必要があります。私たちは、ことができるようになります。
- consider its message fields
- そのメッセージのフィールドを考えます
We should be able to consider the same fields of a response as we consider in the initial invitation.
私たちは、最初の招待状に考えると応答の同じフィールドを考慮することができるはずです。
- relay it on to the call originator
- 呼び出し元にそれをリレー
If the response is satisfactory, it should be returned to the sender.
応答が満足のいくものであるならば、それは送信者に返されるべきです。
- for a fork, choose one of several responses to relay back
- フォークのために、バック中継するために、いくつかの応答のいずれかを選択します。
If we forked an invitation, we obviously expect to receive several responses. There are several issues here -- choosing among the responses, and how long to wait if we've received responses from some but not all destinations.
私たちは招待状をフォークした場合、我々は明らかにいくつかの応答を受け取ることを期待しています。いくつかの問題がここにあります - 応答の中から選択し、どのくらい我々はいくつかのではなく、すべての宛先からの応答を受信した場合に待機します。
- initiate other actions
- 他のアクションを開始
If we didn't get a response, or any we liked, we should be able to try something else instead (e.g., call forward on busy).
私たちは、応答を取得していない、またはいずれかの私たちが好きなら、我々は（例えば、忙しい上のコール転送）の代わりに何か他のものを試すことができるはずです。
A number of other features that a call processing language should have do not refer to call signalling per se; however, they are still extremely desirable to implement many useful features.
呼処理言語が持つべき他の機能の数は、それ自体がコールシグナリングを指すものではありません。しかし、彼らはまだ多くの便利な機能を実装するために非常に望ましいものです。
The servers which provide these features might reside in other Internet devices, or might be local to the server (or other possibilities). The language should be independent of the location of these servers, at least at a high level.
これらの機能を提供するサーバは、他のインターネット・デバイスに常駐可能性がある、またはサーバー（または他の可能性）へのローカルかもしれません。言語は、少なくともハイレベルで、これらのサーバーの場所と無関係であるべきです。
o Logging
Oロギング
In addition to the CPL server's natural logging of events, the user will also want to be able to log arbitrary other items. The actual storage for this logging information might live either locally or remotely.
イベントのCPLサーバの自然のログに加えて、ユーザーは任意の他の項目を記録することができるようになるでしょう。このログ情報の実際のストレージは、ローカルまたはリモートで生きるかもしれません。
o Error reporting
Oエラー報告
If an unexpected error occurs, the script should be able to report the error to the script's owner. This may use the same mechanism as the script server uses to report language errors to the user (see section 12.5).
予期しないエラーが発生した場合、スクリプトはスクリプトの所有者にエラーを報告することができるはずです。スクリプトサーバがユーザに言語のエラーを報告するために使用するように、これは、同じメカニズムを使用することができます（セクション12.5を参照してください）。
o Access to user-location info
ユーザーの位置情報へのOアクセス
Proxies will often collect information on users' current location, either through SIP REGISTER messages, the H.323 RRQ family of RAS messages, or some other mechanism (see section
プロキシは、多くの場合、ユーザーの現在位置に関する情報を収集する、のいずれかSIP REGISTERメッセージを介して、RASメッセージのH.323 RRQファミリー、または他のいくつかのメカニズムが（セクションを参照してください
6.2). The CPL should be able to refer to this information so a call can be forwarded to the registered locations or some subset of them.
6.2）。コールが登録された場所またはそれらのいくつかのサブセットに転送することができるので、CPLは、この情報を参照することができるはずです。
o Database access
Oデータベースアクセス
Much information for CPL control might be stored in external databases, for example a wide-area address database, or authorization information, for a CPL under administrative control. The language could specify some specific database access protocols (such as SQL or LDAP), or could be more generic.
CPLの制御のための多くの情報は、例えば管理下CPLのための広域アドレスデータベース、または許可情報、ために、外部のデータベースに格納される可能性があります。言語は、（SQLやLDAPなど）いくつかの特定のデータベース・アクセス・プロトコルを指定することができ、またはより一般的である可能性があります。
o Other external information
その他の外部情報O
Other external information a script could access includes web pages, which could be sent back in a SIP message body; or a clean interface to remote procedure calls such as Corba, RMI, or DCOM, for instance to access an external billing database. However, for simplicity, these interfaces may not be in the initial version of the protocol.
スクリプトがアクセスすることができ、他の外部情報は、SIPメッセージボディに送り返すことができ、ウェブページを含み;またはリモート・プロシージャにクリーンなインタフェースは、外部の課金データベースにアクセスするために、例えば、そのようなCORBA、RMI、またはDCOMとして呼び出します。しかし、簡単のため、これらのインターフェイスは、プロトコルの初期バージョンではないかもしれません。
Some features do not involve any operations external to the CPL's execution environment, but are still necessary to allow some standard services to be implemented. (This list is not exhaustive.)
一部の機能には、CPLの実行環境の外部の任意の操作を必要とするが、それでもいくつかの標準的なサービスを実装することを可能にするのに必要なありません。 （このリストは網羅的なものではありません。）
o Pattern-matching
Oパターンマッチング
It should be possible to give special treatment to addresses and other text strings based not only on the full string but also on more general or complex sub-patterns of them.
完全な文字列でも、それらのより一般的なまたは複雑なサブパターンにだけでなく、ベースアドレスおよびその他のテキスト文字列に特別な治療を与えることが可能でなければなりません。
o Address filtering
Oアドレスフィルタリング
Once a set of addresses has been retrieved through one of the methods in section 12.3, the user needs to be able to choose a sub-set of them, based on their address components or other parameters.
アドレスのセットは、セクション12.3内のいずれかの方法で取得された後、ユーザは、自分のアドレス成分または他のパラメータに基づいて、それらのサブセットを選択することができる必要があります。
o Randomization
お らんどみざちおん
Some forms of call distribution are randomized as to where they actually end up.
呼分配のいくつかの形態は、それらが実際に終わるところへとランダム化されています。
o Date/time information
O日付/時刻情報
Users may wish to condition some services (e.g., call forwarding, call distribution) on the current time of day, day of the week, etc.
ユーザーは、現在の時刻、曜日などにいくつかのサービスを（例えば、分布を呼び出し、転送を呼び出す）を調整することを望むかもしれません
As described in section 8, we must have a mechanism to send and retrieve CPL scripts, and associated data, to and from a signalling server. This method should support reporting upload-time errors to users; we also need some mechanism to report errors to users at script execution time. Authentication is vital, and encryption is very useful. The specification of this mechanism can be (and probably ought to be) a separate specification from that of the call processing language itself.
セクション8で説明したように、我々は、シグナリングサーバへとから、CPLスクリプトを送信して取得するためのメカニズム、および関連するデータを持っている必要があります。この方法では、ユーザーにアップロード時のエラーを報告してサポートする必要があります。我々はまた、スクリプト実行時にユーザーにエラーを報告するために、いくつかのメカニズムが必要です。認証が不可欠である、と暗号化は非常に便利です。このメカニズムの仕様があること（おそらくあるべき）呼処理言語自体とは別の指定ができます。
13 Security Considerations
13のセキュリティの考慮事項
The security considerations of transferring CPL scripts are discussed in sections 8 and 12.5. Some considerations about the execution of the language are discussed in section 12.1.
転送CPLスクリプトのセキュリティ上の考慮事項は、セクション8と12.5で説明されています。言語の実行に関するいくつかの考慮事項は、セクション12.1で説明されています。
14 Acknowledgments
14の謝辞
We would like to thank Tom La Porta and Jonathan Rosenberg for their comments and suggestions.
我々は彼らのコメントや提案のためにトム・ラ・ポルタとジョナサンローゼンバーグに感謝したいと思います。
15 Authors' Addresses
15本の著者のアドレス
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのジョナサン・レノックス部門、NY 10027 USA
EMail: lennox@cs.columbia.edu
メールアドレス：lennox@cs.columbia.edu
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
16 Bibliography
16参考文献
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[2] International Telecommunication Union, "Packet based multimedia communication systems," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[2]国際電気通信連合、「パケットベースのマルチメディア通信システム、」勧告H.323、ITU、ジュネーブ、スイス、1998年2月の電気通信標準化部門。
[3] K. Coar and D. Robinson, "The WWW common gateway interface version 1.1", Work in Progress.
[3] K. COAR及びD.ロビンソン、 "WWW共通ゲートウェイインターフェイスバージョン1.1"、ProgressのWork。
[4] T. Showalter, "Sieve: A mail filtering language", Work in Progress.
[4] T.ショーウォルター監督、 "ふるい：メールフィルタリング言語"、ProgressのWork。
[5] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services", Work in Progress.
[5] J.レノックスとH. Schulzrinneと、「CPL：インターネット電話サービスのユーザ制御のための言語」が進行中で働いています。
[6] International Telecommunication Union, "General recommendations on telephone switching and signaling -- intelligent network: Introduction to intelligent network capability set 1," Recommendation Q.1211, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.
[6]国際電気通信連合を、 - ：勧告Q.1211、ITU、ジュネーブ、スイス、1993年3月の電気通信標準化部門「の電話交換およびシグナル伝達に対する一般的な推奨事項インテリジェントネットワークは、インテリジェントなネットワーク機能の概要は、1を設定しました」。
[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[7]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[8] E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. Schure, and H. Velthuijsen, "A feature interaction benchmark for IN and beyond," Feature Interactions in Telecommunications Systems, IOS Press, pp. 1-23, 1994.
[8] E. J.キャメロン、N. D. Griffeth、Y.-J.林、M. E.ニルソン、W. K. Schure、およびH. Velthuijsen、 "INための機能の相互作用ベンチマーク以降、" 電気通信システム、IOSを押し、頁におけるサービス競合。1-23、1994。
[9] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway interface for SIP", Work in Progress.
[9] J.レノックス、J.ローゼンバーグ、およびH. Schulzrinneと、 "SIPのための共通ゲートウェイ・インターフェース"、ProgressのWork。
[10] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming internet telephony services," Technical Report CUCS-010-99, Columbia University, New York, New York, Mar. 1999.
[10] J.ローゼンバーグ、J.レノックス、およびH. Schulzrinneと、 "プログラミングのインターネット電話サービス、" テクニカルレポートCUCS-010から99、コロンビア大学、ニューヨーク、ニューヨーク、1999年3月。
[11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in Progress.
[11] H. SchulzrinneとおよびJ.ローゼンバーグ、 "SIP発信者の好みと呼び出し先機能"、ProgressのWork。
17 Full Copyright Statement
17完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。