RFC2824 日本語訳
2824 Call Processing Language Framework and Requirements. J. Lennox,H. Schulzrinne. May 2000. (Format: TXT=58711 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lennox
Request for Comments: 2824 H. Schulzrinne
Category: Informational Columbia University
May 2000
コメントを求めるワーキンググループJ.レノックス要求をネットワークでつないでください: 2824時間Schulzrinneカテゴリ: 情報のコロンビア大学2000年5月
Call Processing Language Framework and Requirements
言語フレームワークと要件に処理に電話をしてください。
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
Abstract
要約
A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language.
しばしばインターネット電話が合図操作の入念な組み合わせを公正に必要とするネットワークデバイスで可能にして、終了したいと思う多くのサービス。 私たちは、実装して、それらを配布するのをより簡単にするようにそのようなサービスを作成する簡単で標準化された方法が欲しいと思います。 このドキュメントはそのようなメカニズムのために建築フレームワークについて説明します。(私たちは呼び出し処理言語をそれと呼びます)。 また、それはそのような言語のための要件について概説します。
Table of Contents
目次
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Example services .................................... 4
4 Usage scenarios ..................................... 6
5 CPL creation ........................................ 6
6 Network model ....................................... 7
6.1 Model components .................................... 7
6.1.1 End systems ......................................... 7
6.1.2 Signalling servers .................................. 8
6.2 Component interactions .............................. 8
7 Interaction of CPL with network model ............... 10
7.1 What a script does .................................. 10
7.2 Which script is executed ............................ 11
7.3 Where a script runs ................................. 12
8 Creation and transport of a call processing
language script ..................................... 12
9 Feature interaction behavior ........................ 13
9.1 Feature-to-feature interactions ..................... 13
1つの序論… 2 2用語… 3 3の例のサービス… 4 4の用法シナリオ… 6 5CPL作成… 6 6はモデルをネットワークでつなぎます… 7 6.1 コンポーネントをモデル化してください… 7 6.1 .1 システムを終わらせてください… 7 6.1 .2 サーバに合図します… 8 6.2 コンポーネント相互作用… ネットワークモデルとのCPLの8 7相互作用… 10 7.1 どんなスクリプトはそうするか… 10 7.2 どのスクリプトが作成されるか… 11 7.3 スクリプトが稼働するところ… 12 呼び出し処理言語スクリプトの8作成と輸送… 12 9 相互作用の振舞いを特徴としてください… 13 9.1 特徴から特徴相互作用… 13
Lennox & Schulzrinne Informational [Page 1] RFC 2824 CPL-F May 2000
レノックスと情報[1ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
9.2 Script-to-script interactions ....................... 14 9.3 Server-to-server interactions ....................... 15 9.4 Signalling ambiguity ................................ 15 10 Relationship with existing languages ................ 15 11 Related work ........................................ 17 11.1 IN service creation environments .................... 17 11.2 SIP CGI ............................................. 17 12 Necessary language features ......................... 17 12.1 Language characteristics ............................ 17 12.2 Base features -- call signalling .................... 19 12.3 Base features -- non-signalling ..................... 21 12.4 Language features ................................... 22 12.5 Control ............................................. 23 13 Security Considerations ............................. 23 14 Acknowledgments ..................................... 23 15 Authors' Addresses .................................. 23 16 Bibliography ........................................ 24 17 Full Copyright Statement ............................ 25
9.2 スクリプトからスクリプトへの相互作用… 14 9.3 サーバからサーバへの相互作用… 15 9.4 あいまいさに合図します… 既存の言語との15 10関係… 関係づけられた15 11は働いています… 17 11.1 INサービス生成環境… 17 11.2 CGIをちびちび飲んでください… 17 12の必要な言語機能… 17 12.1 言語の特性… 17 12.2 基地の機能--合図に電話をしてください… 19 12.3 特徴(非合図)を基礎づけてください… 21 12.4 言語機能… 22 12.5 制御してください… 23 13のセキュリティ問題… 23 14の承認… 23 15人の作者のアドレス… 23 16図書目録… 24 17の完全な著作権宣言文… 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.
伝統的に、ネットワークベースのサービスは単にサービスプロバイダーによって作成されました。 サービス作成は、独占であるか制限されたツールを使用することを通常伴いました、そして、エンドユーザによる改造か増進のために範囲がほとんどありませんでした。 しかしながら、インターネット環境で、これは変化します。 グローバルな接続性とオープン・プロトコルで、サービスプロバイダーが仲介者として機能する必要でない、エンドユーザか第三者が、ダイナミックに彼らのサービスを新しいかカスタマイズされたサービスを設計して、実装して、配布して、変更します。
Lennox & Schulzrinne Informational [Page 2] RFC 2824 CPL-F May 2000
レノックスと情報[2ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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]があります、そして、メールには、Sieve[4]かプロックメールがあります。 インターネット電話のためにそのような開いている改造環境を作成するために、私たちはこれらの新しいサービスクリエイターがネットワークサーバの望まれた行動について説明する標準化されて、安全な方法を必要とします。
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.
このドキュメントはネットワークデバイスがaに簡単な状態で書かれたユーザー作成プログラムの引き金となることで合図イベントを呼ぶために反応するアーキテクチャについて説明します、静的である、非表情豊かに完成する、言語。 私たちは、この言語を呼び出し処理言語と呼びます。
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.
ユーザエージェントサーバ: 要求に応じるユーザエージェントの一部。
Lennox & Schulzrinne Informational [Page 3] RFC 2824 CPL-F May 2000
レノックスと情報[3ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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: Registration、Admission、およびStatusメッセージは例えば、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: Call Processing Language、インターネット電話呼び出し招待状がどう処理されるべきであるかを説明するのが簡単である言語。
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.
その後の議論を動機づけるために、このセクションはいくつかの特定の私たちが、ユーザにプログラムに基づいて作成できて欲しいサービスの例を出します。 これらの例のいくつかが故意にいくらか複雑であることに注意してください、可能であるべき決定論理のレベルを示すために。
Lennox & Schulzrinne Informational [Page 4] RFC 2824 CPL-F May 2000
レノックスと情報[4ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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個のリングの後に代わりになければ、それはその人のボイスメールに向け直されるべきです、それが現在、登録されて、監督から来ていない場合、その場合、ユーザの携帯電話にproxiedされるべきです。
o Information address
o 情報アドレス
A company advertises a general "information" address for
prospective customers. When a call comes in to this address, if
it's currently working hours, the caller should be given a list
of the people currently willing to accept general information
calls. If it's outside of working hours, the caller should get
a webpage indicating what times they can call.
会社は予想購買者のために一般的な「情報」アドレスの広告を出します。 このアドレスに呼び出しを入らせるとき、それが現在、労働時間であるなら、現在一般情報呼び出しを受け入れても構わないと思っている人々のリストを訪問者に与えるべきです。 それが労働時間の外にあるなら、訪問者はウェブページに彼らがどんな回を呼ぶことができるかを示させるべきです。
o Intelligent user location
o 知的なユーザ位置
When a call comes in, the list of locations where the user has
registered should be consulted. Depending on the type of call
(work, personal, etc.), the call should ring at an appropriate
subset of the registered locations, depending on information in
the registrations. If the user picks up from more than one
station, the pick-ups should be reported back separately to the
calling party.
呼び出しが入るとき、ユーザが登録した位置のリストは相談されるべきです。 呼び出しのタイプに頼る、(仕事をであって、個人的ななど、)、呼び出しは登録された位置の適切な部分集合におけるリング、登録証明書で情報によるのがそうするべきです。 ユーザが1つ以上のステーションから回復するなら、ピックアップは別々に起呼側に報告を持ちかえられるべきです。
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.
呼び出しが入ると、呼び出しはだれのメディア能力が発呼要求で指定されたものに最もよく合うかからユーザが登録したステーションにproxiedされるべきです。 ユーザが4個のリングの中のそのステーションから回復しないなら、呼び出しはマッチの密接を減少させることの順にその人が連続して登録した他のステーションにproxiedされるべきです。
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.
呼び出しが入るとき、呼ぶアドレスは対応するクライアントと共に関連します、そして、呼び出しのクライアントの名前、アドレス、および時間は登録されます。 どんな対応するクライアントも見つけないなら、弁護士の秘書に呼び出しを送ります。
Lennox & Schulzrinne Informational [Page 5] RFC 2824 CPL-F May 2000
レノックスと情報[5ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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.
最終的に、サービス作成か改造のためのウェブインタフェースを使用する多くの提案がありました。 バックエンドとしてそのような環境にCPLを使用できました: ウェブアプリケーションはユーザを代表してCPLスクリプトを作成するかもしれません、そして、次に、電話サーバはどちらのもう片方の詳細を意識しなければならないコンポーネントなしでもサービスを実装するかもしれません。
5 CPL creation
5CPL作成
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スクリプトのために複数の作成スタイルを思い描きます。(多くの異なったマナーでそれを作成できます)。
Lennox & Schulzrinne Informational [Page 6] RFC 2824 CPL-F May 2000
レノックスと情報[6ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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の特徴を作成できます、前項で説明されたウェブミドルウェアに関する例などのように。 簡単で、テキストベースの構文で、標準のテキスト処理言語は、容易に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.
最終的に、ユーザは、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.
Call Processing Languageはインターネット電話ネットワークの一般化されたモデルを作動させます。 一般的に説明されていた状態で異なってください、抽象的なレベルでは、すべての主要なインターネット電話アーキテクチャが十分同様であるというそれらの主要な特徴があることができる様々なプロトコルの詳細をゆったり過ごしてください。 作者の経験がそのプロトコルと共に主にあったとき、一般に、このドキュメントはSIP用語を使用します。
6.1 Model components
6.1 モデルの部品
In the Call Processing Language's network model, an Internet telephony network contains two types of components.
Call Processing Languageのネットワークモデルでは、インターネット電話ネットワークは2つのタイプの成分を含んでいます。
6.1.1 End systems
6.1.1 エンドシステム
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には、このプロセス(鳴ること、マルチ系列電話など)の細部は重要ではありません。
Lennox & Schulzrinne Informational [Page 7] RFC 2824 CPL-F May 2000
レノックスと情報[7ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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によって直接対処されていません、そして、ここでそれらについて議論しないでしょう。
6.1.2 Signalling servers
6.1.2 合図サーバ
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.
プロキシ、それ: 応答のひとりが受け取った他の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.
RFC2543[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.
また、通常、合図サーバはユーザ位置の情報を保守します。 登録証明書..メッセージ..静的..構成..ダイナミック..検索..合図..サーバ..持つ..手段..決定..ユーザ..現在..場所を見つける..作る..利口な選択..リダイレクション..振舞い
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.
合図サーバは、それらを通り抜けるトランザクションに関するログを保って、また、通常、インターネットの目的地にメールを送ることができます、プログラムに従ったコントロールの下で。
6.2 Component interactions
6.2 コンポーネント相互作用
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つの可能性がここにあります: 創始者が構成されるかもしれないので、すべての要求がただ一つのローカルサーバに行きます。 または、それは、それが直接要求を送ることができるリモート合図サーバかエンドシステムの場所を見つけるように送付先アドレスを決議するかもしれません。
Lennox & Schulzrinne Informational [Page 8] RFC 2824 CPL-F May 2000
レノックスと情報[8ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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つの経路があります。 Route1に関しては、創始者はそれが連絡しようとしているユーザでユーザアドレスだけを知っています、そして、ローカルの外向的なプロキシサーバを通して発信電話を送るのは構成されています。したがって、それは、そのアドレスに関して記録のサーバを見つけるローカルサーバへの要求を転送して、そのサーバにそれを送ります。
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.
この場合、目的地ユーザが属す組織は、ユーザを見つけるのにマルチステージセットアップを使用します。 法人のサーバは、部のaユーザがどれの一部であるかを特定して、次に、適切な部門のサーバに要求を転送します。(実際に、それは、ユーザの居場所を見つけます)。 (これはメール推進がしばしば構成される方法と同様です。) 要求への応答は同じ経路に沿って移動するでしょう。
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.
しかしながら、Route2に関しては、創始者はそれが連絡しようとしている特定のデバイスアドレスを知っています、そして、それは、地元の辞職しているプロキシを使用するために構成されません。 この場合、全くどんなネットワークサーバともコミュニケートする必要はなくて、創始者は目的地に直接接触できます。
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.
次に、私たちは、電話が一般に、エンドシステムの事情を知ることができないとサーバに合図するインターネットではそれらが「制御すること」がわかります、合図情報がそれらを迂回させたかもしれないので。 この建築制限はどういくつかのサービスを実装することができるかに関する多くの制限を含意します。 例えば、ネットワーク・システムは、エンドシステムが現在忙しいかどうかを確かに知ることができません。 そのネットワーク・システムを横断しないで、電話はエンドシステムに出されたかもしれません。 したがって、合図メッセージはそれらの状態を見つけるためにシステムを終わらせるために明らかに移動しなければなりません。 例では、エンドシステムは明らかに「忙しい」指示を返さなければなりません。
Lennox & Schulzrinne Informational [Page 9] RFC 2824 CPL-F May 2000
レノックスと情報[9ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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 |_____|
外向的な法人の部門のProxyサーバサーバ_______ 外向的なプロキシ接触_______ _______ | | 法人のサーバ| | | | | | ------------------------->|、| --------->|、| |_____| |_____| |_____| /\Userプロキシ/_へのSendsのルート1^ \検索/\| _______ _______ | | ルート2| | | | --------------------------------------------------->|、| |_____| 創始者は目的地に直接接触します。|_____|
Originator Destination
創始者の目的地
Figure 1: Possible paths of call setup messages
図1: 呼び出しセットアップメッセージの可能な経路
7 Interaction of CPL with network model
ネットワークモデルとのCPLの7相互作用
7.1 What a script does
7.1 スクリプトがすること
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スクリプトは合図サーバ、およびコントロールでそのシステムのプロキシ、特定の呼び出しのセットアップのための再直接か拒絶動作を実行します。 それは、Intelligent Networkアーキテクチャ[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.
抽象的に、状態/動作組のリストであるとスクリプトをみなすことができます。 登録、要求、および外部の情報の何らかの属性が与えられた状態に合っているなら、対応する行動を取ります(より適切に動作をセットしてください)。 いくつかの事情では、最初の動作と追加条件の結果に基づいて追加行動を取ることができます。 どんな状態も招待に合っていないなら、合図サーバのものは標準の行動(例えば、位置のデータベースルックアップ)を取ります。
Lennox & Schulzrinne Informational [Page 10] RFC 2824 CPL-F May 2000
レノックスと情報[10ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
7.2 Which script is executed
7.2に、どのスクリプトが作成されますか?
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.
プロキシ動作を実行するのを選んだなら、一度、スクリプトはその目的地としての結果がproxyingされて、アドレスがそうする新しいインターネット電話を実行したことがあります。 これがいったん起こると、サーバはそれらのどれかが新しいアドレスに関連しているかどうか確認するために再びスクリプトに関するデータベースをチェックします。 1つがそうなら、また、そのスクリプトは作成されます(それは既に仮定してみましたスクリプトがサーバが持っているアドレスへのプロキシに試みていない)。 この再帰プロセスに関するその他の詳細、およびサーバにスクリプト創作アドレスとその送付先アドレスに一致しているスクリプトがあるとき、何が起こるかに関する記述に関しては、セクション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つのものの1つを指示するでしょう: ユーザかデバイスのどちらか。 ユーザアドレスは特定の個人について言及します、例えば、一口: そのユーザが実際にどこにいるか、そして、またはその人がどういうデバイスを使用しているかにかかわらず joe@example.com 。 対照的に、デバイスアドレスは一口などの特定のフィジカル・デバイスについて言及します: x26063@phones.example.com 。 他です、中間的種類のアドレスがまた、可能であり、何らかの使用を持っている、(アドレス、「私の携帯電話、登録されるのが現在どこで起こっても)、私たちだけが、それらがそれほど一般的でないと予想します。 それが関連しているアドレスのタイプにおいて、CPLスクリプトは不可知論者です。 ユーザアドレスに関連しているスクリプトはたぶんほとんどのサービスの最も役に立ちますが、また、いかなる他のタイプのアドレスにもスクリプトを関連づけることができなかった理由が全くありません。 上で説明された再帰プロセスは、スクリプトがユーザのいくつかのアドレスに関連しているのを許容します。 したがって、ユーザスクリプトはデバイススクリプトが裁くことができましたが、動作が「私の携帯電話で私を裁く」という「私が私のホームの地域から脱している間に携帯電話呼び出しを受け入れたいと思わない」言いたい事を指定するかもしれません。
It is also possible for a CPL script to be associated not with one specific Internet telephony address, but rather with all addresses handled by a signalling server, or a large set of them. For instance, an administrator might configure a system to prevent calls from or to a list of banned incoming or outgoing addresses; these should presumably be configured for everyone, but users should still to be able to have their own custom scripts as well. Exactly when such
また、CPLスクリプトがむしろ1つの特定のインターネット電話アドレスではなく、合図サーバ、または大きいセットのそれらによって扱われるすべてのアドレスに関連しているのも、可能です。 例えば、管理者は、防ぐシステムがリストか禁止された入って来るか外向的なアドレスのリストに呼ぶのを構成するかもしれません。 これらは皆のためにおそらく構成されるべきですが、ユーザは、また、それら自身のカスタムスクリプトを持つことができるように静まるべきです。 ちょうどそのようなものです。
Lennox & Schulzrinne Informational [Page 11] RFC 2824 CPL-F May 2000
レノックスと情報[11ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
scripts should be executed in the recursion process depends on the precise nature of the administrative script. See section 9.2 for further discussion of this.
スクリプトは再帰で実行されて、プロセスが管理スクリプトの正確な本質によるということであるべきです。 このさらなる議論に関してセクション9.2を見てください。
7.3 Where a script runs
7.3 スクリプトが稼働するところ
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のできるネットワークサーバの場所を見つける手段を指定しません。一般に、これはそれらが自分たちを登録するローカルのインターネット電話サーバの場所を見つけるのと同じ手段であるでしょう。 これは手動の構成を通して、または、Service Locationプロトコル[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で説明された意味で「端末装置」でないかもしれません。 例えば、ユーザは、できる非マルチメディアウェブ端末からのCPLスクリプトを作成して、アップロードできました。
Lennox & Schulzrinne Informational [Page 12] RFC 2824 CPL-F May 2000
レノックスと情報[12ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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.
端末装置がスクリプトをサーバに伝える正確な手段は決定するために残っています。 多くのソリューションが共存できそうでしょう。 このメソッドは、ほとんどすべての場合認証される必要があるでしょう。 示されたメソッドはNFSなどのウェブファイルアップロード、SIP REGISTERメッセージペイロード、リモートメソッド実施、SNMP、ACAP、LDAP、およびリモートファイルシステムを含んでいます。
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.
機能競合は電話技術システムの使用という2以上が、特徴があいまいであるか闘争振舞い[8]を起こすよう要求した用語です。 およそ呼び出し処理言語で実装された特徴のための機能競合問題を3つのカテゴリに分割できます: 1つのサーバにおける特徴から特徴、1つのサーバ、およびサーバからサーバのスクリプトからスクリプト。
9.1 Feature-to-feature interactions
9.1 特徴から機能競合
Due to the explicit nature of event conditions discussed in the previous section, feature-to-feature interaction is not likely to be a problem in a call processing language environment. Whereas a subscriber to traditional telephone features might unthinkingly subscribe to both "call waiting" and "call forward on busy," a user creating a CPL script would only be able to trigger one action in response to the condition "a call arrives while the line is busy." Given a good user interface for creation, or a CPL server which can check for unreachable code in an uploaded script, contradictory condition/action pairs can be avoided.
前項で議論したイベント状態の明白な本質のために、特徴から機能競合は呼び出し処理言語環境における問題である傾向がありません。 伝統的な電話の特徴への加入者は、「キャッチホン」を両方に軽率に申し込んで、「忙しい状態でフォワードを訪問するかもしれません」が、CPLスクリプトを作成するユーザは「回線が話し中ですが、呼び出しは到着する」という条件に対応して1つの動作しか引き金となることができないでしょう。 作成、またはアップロードされたスクリプトによる手の届かないコードがないかどうかチェックできるCPLサーバのための良いユーザーインタフェースを考えて、相容れない状態/動き組を避けることができます。
Lennox & Schulzrinne Informational [Page 13] RFC 2824 CPL-F May 2000
レノックスと情報[13ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
9.2 Script-to-script interactions
9.2 スクリプトからスクリプトへの相互作用
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.
この相互作用へのソリューションはスクリプトの中の注文が実行されることを決定することです。 この注文では、「1番目」のスクリプトは最初に、作成されます。 このスクリプトがproxiedされるという要求を許容するか、または可能にするなら、次のアドレスに対応するスクリプトは作成されます。 最初のスクリプトがある他のアドレスに要求を転送するために言うとき、それらの動作は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
さらに複雑にさえされるのは、管理スクリプトの注文に関するケースです。 多くの管理スクリプトは、賢明な推進でユーザのスクリプト回避管理上の制約を避けるのにソースと送付先アドレスを制限するものなどのように創始者スクリプトの後に実行されるのが必要ですが、目的地スクリプトの前に必要があります。 しかしながら、グローバルアドレス本の翻訳機能などの他のものは、より早期か後で実行される必要があるでしょう。 サーバ、どれ、許容
Lennox & Schulzrinne Informational [Page 14] RFC 2824 CPL-F May 2000
レノックスと情報[14ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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.
実行されるべき管理スクリプトは、管理者が、スクリプト実行プロセスでは、特定の管理スクリプトがいつ当たるべきであるかを構成するのを許容する必要があるでしょう。
9.3 Server-to-server interactions
9.3 サーバからサーバへの相互作用
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人の複合体です。 このタイプの相互作用の正準な例はOriginating Call ScreeningとCall Forwardingの組み合わせです: ユーザ(または、管理者)が、電話が特定のアドレスに出されるのを防ぎたがっているかもしれませんが、ローカルのスクリプトには入賞して、aであるなら電話をするように知る方法が全くない、ある他の正統のアドレスはproxiedされるでしょう、リモートサーバで、禁止されたアドレスに。 このタイプの問題が行政上種々雑多なネットワークで「非-解決でき」である、現在の電話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. SIPに送って戻させるかに、この1つの例が輪を進めていて、そのような輪を検出するメカニズムがあります。(そこでは、ユーザXは呼び出しをYに送らせるかもしれません)。 その結果、呼び出し処理言語サーバはそのような発生を防ぐためにどんな特別なメカニズムも定義する必要はありません。 しかしながら、異なったセットの呼び出し処理機能の輪が検出される場合引き金となって、いくつかを通したスクリプトの所有者への誤りがメカニズムを報告するランタイム誤りを標準化したと報告し返すのは可能であるべきです。
9.4 Signalling ambiguity
9.4 合図のあいまいさ
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
このドキュメントの「言語」としてのCPLの記述が、新しい言語が、必ず最初から実装される必要であるのを含意することを意図しません。 サーバは潜在的にすべてを実装するかもしれません。
Lennox & Schulzrinne Informational [Page 15] RFC 2824 CPL-F May 2000
レノックスと情報[15ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
the functionality described here as a library or set of extensions for an existing language; Java, or the various freely-available scripting languages (Tcl, Perl, Python, Guile), are obvious possibilities.
機能性は、既存の言語のための拡大をここでライブラリと説明したか、またはセットしました。 Java、または様々な自由に利用可能なスクリプト言語(Tcl、Perl、パイソン、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つのモデルがチューリング完全であるので故意にそれ自体を制限する言語Sieve[4]をフィルターにかける電子メールです。
Similar levels of safety and protection (though not automatic generation and parsing) could also be achieved through the use of a "sandbox" such as is used by Java applets, where strict bounds are imposed on the amount of memory, cpu time, stack space, etc., that a program can use. The difficulty with this approach is primarily in its lack of transparency and portability: unless the levels of these bounds are imposed by the standard, a bad idea so long as available resources are increasing exponentially with Moore's Law, a user can never be sure whether a particular program can successfully be executed on a given server without running into the server's resource limits, and a program which executes successfully on one server may fail unexpectedly on another. Non-expressively-complete languages, on the other hand, allow an implicit contract between the script writer and the server: so long as the script stays within the rules of the language, the server will guarantee that it will execute the script.
また、厳しい領域がメモリー容量、cpu time、スタックスペースなどに課されるところでJavaアプレットによって使用されるようなプログラムが使用できる「サンドボックス」の使用で同じ水準の安全と保護(もっとも、自動生成と構文解析でない)を達成できるでしょう。 主としてその透明性の不足と移植性にはこのアプローチにおける困難があります: これらの領域のレベルが課されない場合、利用可能資源がムーアの法則で指数関数的に増加しているのに従ってユーザが当然のことのサーバで首尾よくサーバのリソース限界を出くわさないで特定のプログラムを実行できるか、そして、aがどれをプログラムするかを確信しているはずがないようにとても長い考えが、あるサーバで首尾よく実行する標準と、a悪さは別のもので不意に失敗するかもしれません。 非表情豊かに完成する、他方では、言語はスクリプト作家とサーバとの暗黙の契約を許容します: スクリプトが言語の規則の範囲内にとどまる限り、サーバは、スクリプトを作成するのを保証するでしょう。
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などの強力なドキュメントプログラミング言語はあるはずがありません。 取っておかれることができるワードプロセッサがある間、LaTeXのそれらのドキュメントが形成されて、それらは、入力の任意のLaTeXが記録するように受け入れることができませんし、まして、編集されたフォームに正本の構造を保存できません。 対照的に、本質的にはどんなHTMLエディタもウェブからのどんなHTMLドキュメントも編集できます、そして、それらを編集することの間に高品質な方は正本の構造を保存します。
Lennox & Schulzrinne Informational [Page 16] RFC 2824 CPL-F May 2000
レノックスと情報[16ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
11 Related work
11 関連仕事
11.1 IN service creation environments
11.1 INサービス生成環境
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のINシリーズは抽象的なレベルでサービス生成環境[6]について説明します。 一連の決定と動作が指示された非循環のグラフで手配されたので、これらは伝統的な回路切り換えられた電話網におけるサービスについて説明します。 INサービス使用の多くのベンダーが、彼らの独占サービス生成環境のためにこのバージョンを変更して、広げました。
11.2 SIP CGI
11.2 一口CGI
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.
このセクションは私たちが動機づけている例を実装するために持つのに必要であると信じている呼び出し処理言語のそれらの特性を記載します、説明されたアーキテクチャに沿って。
12.1 Language characteristics
12.1 言語の特性
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
サーバへ駆け込むスクリプトのために、誤構成は手が届かなくなるユーザをもたらすことができます、ランタイム誤りをユーザに示すのを難しくして(メールなどの2番目のチャンネル誤り報告メカニズムがこれを改善するかもしれませんが)。 スクリプトであるときに、したがって、それは確かめるのにおいて可能であるべきです。
Lennox & Schulzrinne Informational [Page 17] RFC 2824 CPL-F May 2000
レノックスと情報[17ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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用語を使用しますが、これはかなり容易に他のシステムに写像されるべきです。) また、言語を他の種類に関するコミュニケーションの処理に達させるのも、役に立つかもしれません、メールやファックスのように。
Lennox & Schulzrinne Informational [Page 18] RFC 2824 CPL-F May 2000
レノックスと情報[18ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
12.2 Base features -- call signalling
12.2の基地の機能--合図に電話をしてください。
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には、Subjectや、Organizationや、Priorityや、などや、アドレスのためのディスプレイ名などの原文の分野があります。 また、ユーザは標準的でない追加ヘッダーを加えることができます。 H.323には、ただ一つのDisplay分野があります。 スクリプトはこれらに基づいた決定をパラメタにすることができるべきです。
- 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.
呼び出し招待状は流れるメディア、それらの帯域幅用法、それらのネットワーク送付先アドレスなどのタイプを指定します。 スクリプトはこれらに基づいた決定をメディアの特性にすることができるべきです。
Lennox & Schulzrinne Informational [Page 19] RFC 2824 CPL-F May 2000
レノックスと情報[19ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
- 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.
私たちは、もう1つの位置か、他の数個の位置への呼び出し招待(招待を「分岐させる」)を送って、応答を待つはずであることができます。 また、私たちがどんな決定的な応答も受けるのに見切りをつけるタイムアウト値を指定するのも可能であるべきです。
o Should be able to take action based a response to a proxied or
forked call invitation
o aへのベースのa応答がproxiedした動きか股状の呼び出し招待を取ることができるべきです。
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:
いったん招待状をproxiedすると、私たちは、私たちがその招待(または、それの不足)に受ける応答に基づく決定をすることができる必要があります。 私たちは以下にできるべきです。
- consider its message fields
- メッセージ分野を考えてください。
We should be able to consider the same fields of a response
as we consider in the initial invitation.
私たちは初期の招待で考えるように応答の同じ分野を考えることができるはずです。
Lennox & Schulzrinne Informational [Page 20] RFC 2824 CPL-F May 2000
レノックスと情報[20ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
- 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
- フォークに、リレーし返すいくつかの応答の1つを選んでください。
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).
私たちが返事をもらわなかったか、または私たちがいくらか好きであるなら、代わりに他の何かを試みることができるでしょうに(例えば、忙しい状態でフォワードを訪問してください)。
12.3 Base features -- non-signalling
12.3の基地の機能--非合図
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ファミリー、またはある他のメカニズムを通して(セクションを見てください。
Lennox & Schulzrinne Informational [Page 21] RFC 2824 CPL-F May 2000
レノックスと情報[21ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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などの遠隔手続き呼び出しへの清潔なインタフェース、外部の支払いデータベースにアクセスするために。 しかしながら、簡単さのために、これらのインタフェースがプロトコルの初期のバージョンにないかもしれません。
12.4 Language features
12.4 言語機能
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.
1セットのアドレスがセクション12.3でメソッドの1つでいったん検索されると、ユーザは、それらの部分集合を選ぶことができる必要があります、それらのアドレス構成要素か他のパラメタに基づいて。
o Randomization
o 無作為化
Some forms of call distribution are randomized as to where they
actually end up.
呼び出し分配のいくつかのフォームがそれらが実際に終わるところに関してランダマイズされます。
Lennox & Schulzrinne Informational [Page 22] RFC 2824 CPL-F May 2000
レノックスと情報[22ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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.
ユーザはいくつかのサービス(例えば、推進に電話をしてください、呼び出し分配)を現在の時刻、曜日などを条件とさせたがっているかもしれません。
12.5 Control
12.5 コントロール
As described in section 8, we must have a mechanism to send and retrieve CPL scripts, and associated data, to and from a signalling server. This method should support reporting upload-time errors to users; we also need some mechanism to report errors to users at script execution time. Authentication is vital, and encryption is very useful. The specification of this mechanism can be (and probably ought to be) a separate specification from that of the call processing language itself.
セクション8で説明されるように、私たちにはサーバと合図サーバからのCPLスクリプト、および関連データを送って、検索するメカニズムがなければなりません。このメソッドはユーザへのアップロード時間の誤りを報告にサポートするべきです。 また、私たちは、スクリプト実行時間に誤りをユーザに報告するために何らかのメカニズムを必要とします。 認証は重大です、そして、暗号化は非常に役に立ちます。 このメカニズムの仕様は呼び出し処理言語自体のものからの(そして、たぶん、あるべきです)別々の仕様であるかもしれません。
13 Security Considerations
13 セキュリティ問題
The security considerations of transferring CPL scripts are discussed in sections 8 and 12.5. Some considerations about the execution of the language are discussed in section 12.1.
セクション8と12.5でCPLが原稿を書く移すことのセキュリティ問題について議論します。 セクション12.1で言語の実行に関するいくつかの問題について議論します。
14 Acknowledgments
14の承認
We would like to thank Tom La Porta and Jonathan Rosenberg for their comments and suggestions.
彼らのコメントと提案についてトム・ラ・ポルタとジョナサン・ローゼンバーグに感謝申し上げます。
15 Authors' Addresses
15人の作者のアドレス
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスColumbia University1214アムステルダムアベニューのジョナサンレノックス部、ニューヨーク、ニューヨーク10027の米国のM.C.0401
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
コンピュータサイエンスColumbia University1214アムステルダムアベニューのヘニングSchulzrinne部、ニューヨーク、ニューヨーク10027の米国のM.C.0401
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Lennox & Schulzrinne Informational [Page 23] RFC 2824 CPL-F May 2000
レノックスと情報[23ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
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.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[2] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[2]国際電気通信連合、「パケットはマルチメディア通信システムを基礎づけた」Recommendation H.323、ITUのTelecommunication Standardization Sector、ジュネーブスイス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:」 「インターネット電話サービスのユーザコントロールのための言語」、ProgressのWork。
[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] 国際電気通信連合、「一般推薦、切り換えるのとシグナリング--インテリジェントネットワークは電話をします:、」 Recommendation Q.1211、ITUのTelecommunication Standardization Sector、ジュネーブスイス1993年3月の「インテリジェントネットワーク能力セット1への紹介。」
[7] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[7] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[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.シュレー、およびH.Velthuijsen、「INと以遠への機能競合ベンチマーク」、Telecommunications Systems、IOS Press、ページのFeature Interactions 1-23, 1994.
[9] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway
interface for SIP", Work in Progress.
Progressの[9] J.レノックス、J.ローゼンバーグとH.Schulzrinne、「SIPのためのコモンゲートウェイインターフェース」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「インターネット電話サービスをプログラムする」Technical Report 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。
Lennox & Schulzrinne Informational [Page 24] RFC 2824 CPL-F May 2000
レノックスと情報[24ページ]のSchulzrinneのRFCの2824CPL-Fの2000年5月
17 Full Copyright Statement
17 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Lennox & Schulzrinne Informational [Page 25]
レノックスとSchulzrinne情報です。[25ページ]
一覧
スポンサーリンク
