[要約] RFC 2824は、通話処理言語のフレームワークと要件に関するものであり、通話処理の標準化と効率化を目的としています。
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.
Copyright（c）The Internet Society（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.
多くのインターネットアプリケーションには、このようなカスタマイズ環境があります。たとえば、WebにはCGI [3]があり、電子メールにはSieve [4]またはProcmailがあります。インターネットテレフォニーのためにこのようなオープンなカスタマイズ環境を作成するには、これらの新しいサービスクリエイターがネットワークサーバーの望ましい動作を説明するための標準化された安全な方法が必要です。
This document describes an architecture in which network devices respond to call signalling events by triggering user-created programs written in a simple, static, non-expressively-complete language. We call this language a call processing language.
このドキュメントでは、シンプルで静的な、非発現的に完全に複雑な言語で記述されたユーザーが作成したプログラムをトリガーすることにより、ネットワークデバイスが通話シグナリングイベントに応答するアーキテクチャについて説明します。この言語を通話処理言語と呼びます。
The development of this document has been substantially informed by the development of a particular call processing language, as described in [5]. In general, when this document refers to "a call processing language," it is referring to a generic language that fills this role; "the call processing language" or "the CPL" refers to this particular language.
このドキュメントの開発は、[5]に記載されているように、特定のコール処理言語の開発によって実質的に通知されています。一般に、このドキュメントが「コール処理言語」を指す場合、この役割を満たす一般的な言語を指します。「コール処理言語」または「CPL」は、この特定の言語を指します。
2 Terminology
2用語
In this section we define some of the terminology used in this document.
このセクションでは、このドキュメントで使用されている用語の一部を定義します。
SIP [1] terminology used includes:
使用されるSIP [1]用語には以下が含まれます。
invitation: The initial INVITE request of a SIP transaction, by which one party initiates a call with another.
招待状：SIPトランザクションの最初の招待リクエスト。
redirect server: A SIP device which responds to invitations and other requests by informing the request originator of an alternate address to which the request should be sent.
リダイレクトサーバー：リクエストのオリジネーターにリクエストを送信する代替アドレスを通知することにより、招待状やその他のリクエストに応答するSIPデバイス。
proxy server: A SIP device which receives invitations and other requests, and forwards them to other SIP devices. It then receives the responses to the requests it forwarded, and forwards them back to the sender of the initial request.
プロキシサーバー：招待状やその他のリクエストを受信し、他のSIPデバイスに転送するSIPデバイス。その後、転送されたリクエストへの応答を受信し、最初のリクエストの送信者に転送します。
user agent: A SIP device which creates and receives requests, so as to set up or otherwise affect the state of a call. This may be, for example, a telephone or a voicemail system.
ユーザーエージェント：リクエストを作成および受信するSIPデバイス。これは、たとえば、電話またはボイスメールシステムです。
user agent client: The portion of a user agent which initiates requests.
ユーザーエージェントクライアント：リクエストを開始するユーザーエージェントの部分。
user agent server: The portion of a user agent which responds to requests.
ユーザーエージェントサーバー：リクエストに応答するユーザーエージェントの部分。
H.323 [2] terminology used includes:
H.323 [2]使用される用語には以下が含まれます。
terminal: An H.323 device which originates and receives calls, and their associated media.
端末：呼び出しを発信および受信するH.323デバイス、および関連するメディア。
gatekeeper: An H.323 entity on the network that provides address translation and controls access to the network for H.323 terminals and other endpoints. The gatekeeper may also provide other services to the endpoints such as bandwidth management and locating gateways.
GateKeeper：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 Webミドルウェア
Finally, there have been a number of proposals for service creation or customization using web interfaces. A CPL could be used as the back-end to such environments: a web application could create a CPL script on behalf of a user, and the telephony server could then implement the services without either component having to be aware of the specifics of the other.
最後に、Webインターフェイスを使用したサービスの作成またはカスタマイズに関する多くの提案がありました。CPLはそのような環境へのバックエンドとして使用できます。Webアプリケーションはユーザーに代わってCPLスクリプトを作成でき、テレフォニーサーバーは、どちらのコンポーネントも他のコンポーネントの詳細を認識しなくてもサービスを実装できます。。
5 CPL creation
5 CPL作成
There are also a number of means by which CPL scripts could be created. Like HTML, which can be created in a number of different manners, we envision multiple creation styles for a CPL script.
CPLスクリプトを作成できる手段もいくつかあります。さまざまなマナーで作成できるHTMLと同様に、CPLスクリプトの複数の作成スタイルを想定しています。
o Hand authoring
o ハンドオーサリング
Most directly, CPL scripts can be created by hand, by knowledgeable users. The CPL described in [5] has a text format with an uncomplicated syntax, so hand authoring will be straightforward.
ほとんどの場合、CPLスクリプトは、知識豊富なユーザーが手作業で作成できます。[5]で説明されているCPLには、複雑でない構文を備えたテキスト形式があるため、ハンドオーサリングは簡単です。
o Automated scripts
o 自動スクリプト
CPL features can be created by automated means, such as in the example of the web middleware described in the previous section. With a simple, text-based syntax, standard text-processing languages will be able to create and edit CPL scripts easily.
CPL機能は、前のセクションで説明したWebミドルウェアの例のように、自動化された手段によって作成できます。シンプルなテキストベースの構文により、標準のテキスト処理言語はCPLスクリプトを簡単に作成および編集できます。
o GUI tools
o GUIツール
Finally, users will be able to use GUI tools to create and edit CPL scripts. We expect that most average-experience users will take this approach once the CPL gains popularity. The CPL will be designed with this application in mind, so that the full expressive power of scripts can be represented simply and straightforwardly in a graphical manner.
最後に、ユーザーはGUIツールを使用してCPLスクリプトを作成および編集できます。CPLが人気を獲得すると、ほとんどの平均経験ユーザーがこのアプローチを採用することを期待しています。CPLは、このアプリケーションを念頭に置いて設計され、スクリプトの完全な表現力をグラフィカルな方法で簡単かつ簡単に表現できます。
6 Network model
6ネットワークモデル
The Call Processing Language operates on a generalized model of an Internet telephony network. While the details of various protocols differ, on an abstract level all major Internet telephony architectures are sufficiently similar that their major features can be described commonly. This document generally uses SIP terminology, as its authors' experience has mainly been with that protocol.
コール処理言語は、インターネットテレフォニーネットワークの一般化モデルで動作します。さまざまなプロトコルの詳細は異なりますが、抽象的なレベルでは、すべての主要なインターネットテレフォニーアーキテクチャは十分に類似しているため、主要な機能を一般的に説明できます。著者の経験は主にそのプロトコルで行われているため、このドキュメントは一般にSIP用語を使用しています。
In the Call Processing Language's network model, an Internet telephony network contains two types of components.
コール処理言語のネットワークモデルでは、インターネットテレフォニーネットワークには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の目的のために、GATEWAYS（たとえば、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.
プロキシIT：他の1つまたは複数のネットワークまたはエンドシステムに転送し、受信した応答の1つを返します。
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レジスタまたは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.
エンドシステムが通話を行うと、コール設定リクエストは、ネットワークのコンポーネントを介してさまざまなルートで進行できます。そもそも、元のエンドシステムは、リクエストを送信する場所を決定する必要があります。ここには2つの可能性があります。すべての要求が単一のローカルサーバーに送られるように、オリジネーターを構成することができます。または、宛先アドレスを解決して、リクエストを直接送信できるリモート信号サーバーまたはエンドシステムを見つけます。
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
7 CPLとネットワークモデルの相互作用
A CPL script runs in a signalling server, and controls that system's proxy, redirect, or rejection actions for the set-up of a particular call. It does not attempt to coordinate the behavior of multiple signalling servers, or to describe features on a "Global Functional Plane" as in the Intelligent Network architecture [6].
CPLスクリプトはシグナリングサーバーで実行され、特定の呼び出しのセットアップのために、システムのプロキシ、リダイレクト、または拒否アクションを制御します。複数の信号サーバーの動作を調整したり、インテリジェントネットワークアーキテクチャ[6]のように「グローバル機能面」の機能を説明しようとはしません。
More specifically, a script replaces the user location functionality of a signalling server. As described in section 6.1.2, a signalling server typically maintains a database of locations where a user can be reached; it makes its proxy, redirect, and rejection decisions based on the contents of that database. A CPL script replaces this basic database lookup functionality; it takes the registration information, the specifics of a call request, and other external information it wants to reference, and chooses the signalling actions to perform.
より具体的には、スクリプトが信号サーバーのユーザーロケーション機能を置き換えます。セクション6.1.2で説明されているように、信号サーバーは通常、ユーザーに到達できる場所のデータベースを維持します。そのデータベースの内容に基づいて、プロキシ、リダイレクト、および拒否の決定を行います。CPLスクリプトは、この基本的なデータベースルックアップ機能を置き換えます。登録情報、コールリクエストの詳細、および参照したいその他の外部情報を取得し、実行するシグナリングアクションを選択します。
Abstractly, a script can be considered as a list of condition/action pairs; if some attribute of the registration, request, and external information matches a given condition, then the corresponding action (or more properly set of actions) is taken. In some circumstances, additional actions can be taken based on the consequences of the first action and additional conditions. If no condition matches the invitation, the signalling server's standard action -- its location database lookup, for example -- is taken.
抽象的には、スクリプトは条件/アクションペアのリストと見なすことができます。登録、リクエスト、および外部情報の属性が特定の条件と一致する場合、対応するアクション（またはより適切に一連のアクション）が取得されます。状況によっては、最初のアクションと追加の条件の結果に基づいて、追加のアクションを実行できます。条件が招待状に一致しない場合、シグナリングサーバーの標準アクション（たとえば、その場所データベースの検索など）が取得されます。
CPL scripts are usually associated with a particular Internet telephony address. When a call establishment request arrives at a signalling server which is a CPL server, that server associates the source and destination addresses specified in the request with its database of CPL scripts; if one matches, the corresponding script is executed.
CPLスクリプトは通常、特定のインターネットテレフォニーアドレスに関連付けられています。CPLサーバーのシグナリングサーバーに呼び出しのリクエストが到着すると、そのサーバーはリクエストで指定されたソースと宛先アドレスをCPLスクリプトのデータベースに関連付けます。一致する場合、対応するスクリプトが実行されます。
Once the script has executed, if it has chosen to perform a proxy action, a new Internet telephony address will result as the destination of that proxying. Once this has occurred, the server again checks its database of scripts to see if any of them are associated with the new address; if one is, that script as well is executed (assuming that a script has not attempted to proxy to an address which the server has already tried). For more details of this recursion process, and a description of what happens when a server has scripts that correspond both to a scripts origination address and its destination address, see section 9.2.
スクリプトが実行されると、プロキシアクションを実行することを選択した場合、そのプロキシの目的地として新しいインターネットテレフォニーアドレスが生じます。 これが発生すると、サーバーは再びスクリプトのデータベースをチェックして、それらのいずれかが新しいアドレスに関連付けられているかどうかを確認します。 ある場合、そのスクリプトも実行されます（スクリプトがサーバーがすでに試したアドレスにプロキシを試みようとしていないと仮定します）。 この再帰プロセスの詳細、およびサーバーがスクリプトのオリジネーションアドレスとその宛先アドレスの両方に対応するスクリプトがある場合に何が起こるかの説明については、セクション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つのことのいずれかを示します。ユーザーまたはデバイスのいずれかです。ユーザーアドレスとは、そのユーザーが実際にどこにあるか、または使用しているデバイスの種類に関係なく、SIP：joe@example.comなどの特定の個人を指します。対照的に、デバイスアドレスは、SIP：x26063@phones.example.comなどの特定の物理デバイスを指します。他の中間の種類のアドレスも可能であり、何らかの使用が可能です（「現在登録されているところはどこでも私の携帯電話」のアドレスなど）が、それらはあまり一般的ではないと予想しています。CPLスクリプトは、関連付けられているアドレスのタイプに不可知論されます。ユーザーアドレスに関連付けられているスクリプトは、おそらくほとんどのサービスにとって最も便利ですが、スクリプトが他のタイプのアドレスにも関連付けられない理由はありません。上記の再帰プロセスにより、スクリプトをユーザーのアドレスのいくつかに関連付けることができます。したがって、ユーザースクリプトは、「携帯電話で私を試してみてください」というアクションを指定できますが、デバイスのスクリプトは「私は自分の家の外に出ている間は携帯電話を受け入れたくない」と言うことができます。
It is also possible for a CPL script to be associated not with one specific Internet telephony address, but rather with all addresses handled by a signalling server, or a large set of them. For instance, an administrator might configure a system to prevent calls from or to a list of banned incoming or outgoing addresses; these should presumably be configured for everyone, but users should still to be able to have their own custom scripts as well. Exactly when such 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スクリプトを1つの特定のインターネットテレフォニーアドレスではなく、信号サーバーまたはそれらの大規模なセットで処理されるすべてのアドレスに関連付けることも可能です。たとえば、管理者は、禁止された着信または発信アドレスからの通話を防止するシステムを構成する場合があります。これらはおそらくすべての人向けに構成されるべきですが、ユーザーも独自のカスタムスクリプトを持つことができる必要があります。そのようなスクリプトが再帰プロセスで実行される場合、正確には、管理スクリプトの正確な性質に依存します。これについての詳細については、セクション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]。このようなサーバーを見つける自動化された手段には、サーバーがユーザーがCPLSをアップロードできるかどうかを示すフィールドを含める必要があることが提案されています。
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レジスタメッセージペイロード、リモートメソッドの呼び出し、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.
ユーザーは、現在のスクリプトをネットワークからエンドシステムに取得して、編集することもできます。また、Signaling Serverは、スクリプトに関連するエラーをユーザーに報告できる必要があります。どちらも、アップロード時に検出される静的エラー、および実行時のエラーが発生します。
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.
特徴の相互作用は、2つ以上の要求された機能が曖昧または矛盾する動作を生成する場合、テレフォニーシステムで使用される用語です[8]。コール処理言語を使用して実装された機能の機能相互作用の問題は、1つのサーバー内の機能への機能、1つのサーバーのスクリプトからスクリプト、サーバーからサーバーの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.
前のセクションで説明したイベント条件の明示的な性質により、機能間の相互作用は、コール処理言語環境では問題になる可能性は低いです。従来の電話機能へのサブスクライバーは、「Call White」と「Call Forward on Busy」の両方を概説していない場合がありますが、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で説明されているように、サーバーが1回の呼び出しに対して複数のスクリプトを呼び出すと、スクリプトからスクリプトへの相互作用が発生します。これは、多くの場合に発生する可能性があります。コールオリジネーターと宛先の両方に、単一のサーバーでスクリプトが指定されている場合。スクリプトがスクリプトもある別のアドレスにリクエストを転送する場合。または、ユーザーの個々のスクリプトと同様に管理スクリプトが指定されている場合。
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.
フィーチャインタラクションの3番目のケースであるサーバーからサーバーの相互作用は、これら3つの中で最も複雑です。このタイプの相互作用の標準的な例は、発信するコールスクリーニングとコール転送の組み合わせです。ユーザー（または管理者）は、呼び出しが特定のアドレスに配置されないようにしたい場合がありますが、ローカルスクリプトには呼び出しがあるかどうかを知る方法がありません。他のいくつかの正当な住所に配置され、リモートサーバーによって禁止されたアドレスにaxiedされます。このタイプの問題は、管理上の異種ネットワークでは、現在の電話システムなどの「軽く」不均一なネットワークでさえも解決できません。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.
サーバーからサーバーへの相互作用の別のクラスは、信号サーバーがコール処理言語によって制御されているか、まったく異なる手段によって制御されているかどうかを発生させることができるため、基礎となるシグナリングプロトコルによって最もよく解決されます。この1つの例は、転送ループです。ユーザーXには、呼び出しがYに転送される場合があります。YはXに転送されます。SIPには、そのようなループを検出するメカニズムがあります。したがって、通話処理言語サーバーは、そのような発生を防ぐために特別なメカニズムを定義する必要はありません。ただし、ループが検出された場合に異なる一連のコール処理アクションをトリガーしたり、標準化された実行時間エラー報告メカニズムを使用してスクリプトの所有者にエラーを報告したりすることが可能です。
As an aside, [8] discusses a fourth type of feature interaction for traditional telephone networks, signalling ambiguity. This can arise when several features overload the same operation in the limited signal path from an end station to the network: for example, flashing the switch-hook can mean both "add a party to a three-way call" and "switch to call waiting." Because of the explicit nature of signalling in both the Internet telephony protocols discussed here, this issue does not arise.
余談ですが、[8]は、従来の電話ネットワークの4番目のタイプの機能相互作用について説明し、曖昧さを示しています。これは、いくつかの機能がエンドステーションからネットワークへの限定信号パスで同じ操作を過負荷にすると発生する可能性があります。たとえば、スイッチフックをフラッシュすると、「パーティーを3ウェイコールに追加する」と「通話へのスイッチの両方を意味する場合があります。待っている。"ここで説明したインターネットテレフォニープロトコルの両方でシグナリングの明確な性質のため、この問題は発生しません。
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、Guile）は、明らかな可能性です。
However, there are motivations for creating a new language. All the existing languages are, naturally, expressively complete; this has two inherent disadvantages. The first is that any function implemented in them can take an arbitrarily long time, use an arbitrarily large amount of memory, and may never terminate. For call processing, this sort of resource usage is probably not necessary, and as described in section 12.1, may in fact be undesirable. One model for this is the electronic mail filtering language Sieve [4], which deliberately restricts itself from being Turing-complete.
ただし、新しい言語を作成する動機があります。既存の言語はすべて、当然、表現的に完了しています。これには2つの固有の欠点があります。1つ目は、それらに実装されている関数は、任意に長い時間をかけ、任意の大量のメモリを使用し、決して終了しない可能性があることです。通話処理の場合、この種のリソース使用はおそらく必要ではなく、セクション12.1で説明されているように、実際には望ましくない可能性があります。これの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.
同様のレベルの安全性と保護レベル（自動生成と解析ではありませんが）は、メモリの量、CPU時間、スタックスペースに厳密な境界が課されるJavaアプレットが使用する「サンドボックス」を使用することで達成できます。、プログラムが使用できるなど。このアプローチの難しさは主に透明性と携帯性の欠如にあります。これらの境界のレベルが標準によって課されない限り、利用可能なリソースがムーアの法律で指数関数的に増加している限り、ユーザーはユーザーが決して確信できない限り、悪い考え特定のプログラムは、サーバーのリソース制限に巻き込まれることなく、特定のサーバーで正常に実行できます。また、あるサーバーで正常に実行されるプログラムは、別のサーバーで予期せずに失敗する可能性があります。一方、非発現的に完全に複雑な言語では、スクリプトライターとサーバー間の暗黙の契約を許可します。スクリプトが言語のルール内にとどまる限り、サーバーはスクリプトを実行することを保証します。
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やPostScriptなどの強力なドキュメントプログラミング言語が操作できません。 ドキュメントをラテックス形式で保存できるワードプロセッサがありますが、入力任意のラテックスドキュメントとして受け入れることはできません。編集されたフォームで元のドキュメントの構造を保存することはできません。 対照的に、基本的にHTMLエディターはWebからHTMLドキュメントを編集でき、高品質のドキュメントは編集中に元のドキュメントの構造を保存できます。
11 Related work
11関連作業
The ITU's IN series describe, on an abstract level, service creation environments [6]. These describe services in a traditional circuit-switched telephone network as a series of decisions and actions arranged in a directed acyclic graph. Many vendors of IN services use modified and extended versions of this for their proprietary service creation environments.
ITUは、抽象的なレベルで、サービス作成環境で説明しています[6]。これらは、従来の回路が切り替えられた電話ネットワーク内のサービスを、指示された非環式グラフに配置された一連の決定と行動として説明しています。In Servicesの多くのベンダーは、独自のサービス作成環境に修正されたバージョンと拡張バージョンを使用しています。
SIP CGI [9] is an interface for implementing services on SIP servers. Unlike a CPL, it is a very low-level interface, and would not be appropriate for services written by non-trusted users.
SIP CGI [9]は、SIPサーバーにサービスを実装するためのインターフェイスです。CPLとは異なり、非常に低レベルのインターフェイスであり、トラストされていないユーザーが書いたサービスには適していません。
The paper "Programming Internet Telephony Services" [10] discusses the similarities and contrasts between SIP CGI and CPL in more detail.
論文「プログラミングインターネットテレフォニーサービス」[10]では、SIP CGIとCPLの類似性とコントラストについて詳しく説明します。
12 Necessary language features
12の必要な言語機能
This section lists those properties of a call processing language which we believe to be necessary to have in order to implement the motivating examples, in line with the described architecture.
このセクションには、説明されたアーキテクチャに沿って、やる気を起こさせる例を実装するために必要だと思われるコール処理言語のプロパティをリストします。
These are some abstract attributes which any proposed call processing language should possess.
これらは、提案されたコール処理言語が持つべき抽象的な属性です。
o Light-weight, efficient, easy to implement
o 軽量で効率的で、実装しやすい
In addition to the general reasons why this is desirable, a network server might conceivably handle very large call volumes, and we don't want CPL execution to be a major bottleneck. One way to achieve this might be to compile scripts before execution.
これが望ましい一般的な理由に加えて、ネットワークサーバーは非常に大きなコールボリュームを処理する可能性があり、CPLの実行を主要なボトルネックにしたくないでしょう。これを達成する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用語を使用しますが、これは他のシステムにかなり簡単にマッピングされるはずです。）また、電子メールやFAXなどの他の種類の通信の処理に言語を拡張することも役立つ場合があります。
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 Headerと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 Serverのイベントの自然なロギングに加えて、ユーザーは任意の他のアイテムを記録できるようにすることも望みます。このロギング情報の実際のストレージは、ローカルまたはリモートで存在する場合があります。
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 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.
プロキシは、多くの場合、SIPレジスタメッセージ、RASメッセージのH.323 RRQファミリー、またはその他のメカニズムを介して、ユーザーの現在の場所に関する情報を収集します（セクション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メッセージ本文で送信される可能性のあるWebページが含まれています。または、たとえば外部請求データベースにアクセスするために、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のメソッドの1つを通じて一連のアドレスが取得されると、ユーザーはアドレスコンポーネントまたはその他のパラメーターに基づいて、それらのサブセットを選択できる必要があります。
o Randomization
o ランダム化
Some forms of call distribution are randomized as to where they actually end up.
いくつかの形式の呼び出し分布は、実際にどこで終わるかについてランダム化されています。
o Date/time information
o 日付/時刻情報
Users may wish to condition some services (e.g., call forwarding, call distribution) on the current time of day, day of the week, etc.
ユーザーは、現在の時刻、曜日などにいくつかのサービス（例：通話転送、通話配布など）を条件付けることをお勧めします。
As described in section 8, we must have a mechanism to send and retrieve CPL scripts, and associated data, to and from a signalling server. This method should support reporting upload-time errors to users; we also need some mechanism to report errors to users at script execution time. Authentication is vital, and encryption is very useful. The specification of this mechanism can be (and probably ought to be) a separate specification from that of the call processing language itself.
セクション8で説明されているように、CPLスクリプトと関連するデータを送信および取得して、シグナリングサーバーとの間でメカニズムを取得するメカニズムが必要です。この方法では、ユーザーへのアップロード時間エラーの報告をサポートする必要があります。また、スクリプト実行時間でユーザーにエラーを報告するメカニズムも必要です。認証は不可欠であり、暗号化は非常に便利です。このメカニズムの仕様は、コール処理言語自体の仕様とは別の仕様となる可能性があります（おそらくあるべきです）。
13 Security Considerations
13セキュリティ上の考慮事項
The security considerations of transferring CPL scripts are discussed in sections 8 and 12.5. Some considerations about the execution of the language are discussed in section 12.1.
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アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
EMail: lennox@cs.columbia.edu
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
16 Bibliography
16書誌
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、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、1998年2月、スイス、ジュネーブのITUの電気通信標準化セクター。
[3] K. Coar and D. Robinson, "The WWW common gateway interface version 1.1", Work in Progress.
[3] K. CoarとD. Robinson、「WWW Common Gateway Interfaceバージョン1.1」、進行中の作業。
[4] T. Showalter, "Sieve: A mail filtering language", Work in Progress.
[4] T. Showalter、「Sive：A Mail Filtering Language」、進行中の作業。
[5] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services", Work in Progress.
[5] J. LennoxとH. Schulzrinne、「CPL：インターネットテレフォニーサービスのユーザー制御のための言語」、進行中の作業。
[6] International Telecommunication Union, "General recommendations on telephone switching and signaling -- intelligent network: Introduction to intelligent network capability set 1," Recommendation Q.1211, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.
[6] 国際電気通信ユニオン、「電話の切り替えと信号に関する一般的な推奨事項 - インテリジェントネットワーク：インテリジェントネットワーク機能セット1の紹介」、推奨Q.1211、1993年3月、スイス、ジュネーブ、ITUの電気通信標準化セクター。
[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[7] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol、Version 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。グリフス、Y.-J。Lin、M。E。Nilson、W。K。Schure、およびH. Velthuijsen、「In and Beyondの機能相互作用ベンチマーク」、Telecommunications Systems、iOS Press、pp。1-23、1994の特徴インタラクション。
[9] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway interface for SIP", Work in Progress.
[9] J. Lennox、J。Rosenberg、およびH. Schulzrinne、「SIP用の共通ゲートウェイインターフェイス」が進行中です。
[10] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming internet telephony services," Technical Report CUCS-010-99, Columbia University, New York, New York, Mar. 1999.
[10] J. Rosenberg、J。Lennox、およびH. Schulzrinne、「プログラミングインターネットテレフォニーサービス」、テクニカルレポートCUCS-010-99、コロンビア大学、ニューヨーク、ニューヨーク、1999年3月。
[11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities", Work in Progress.
[11] H. SchulzrinneおよびJ. Rosenberg、「SIP Callerの好みとCallee機能」、進行中の作業。
17 Full Copyright Statement
17完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。