Network Working Group I. Faynberg, Editor
Request for Comments: 3298 Lucent Technologies
Category: Informational J. Gato
Vodaphone
H. Lu
Lucent Technologies
L. Slutsman
AT&T
August 2002
Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
公共でのサービス交換電話網/インテリジェントネットワーク（PSTN / IN）の要求インターネットサービス（SPIRITS）プロトコル要件
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
この文書は、（「インターネットサービスを要求する際に/ PSTNにサービス」の略です。SPIRITS）プロトコルの目的は、公衆に発信サービスは電話を交換サポートすることであるRFC 3136で提示アーキテクチャに基づいSPIRITSプロトコル要件について説明しネットワーク（PSTN）とPSTNとインターネットの間の相互作用を必要とします。同様に、このようなサービスはSPIRITSサービスと呼ばれます。 （インターネットキャッチホン、インターネット発信者ID配達、及びインターネット電話転送は、SPIRITサービスの例ですが、プロトコルは、他の多くのサービスを構築することができ、そこからのビルディングブロックを定義することです。）PSTN側では、SPIRITSサービスが開始されていますインテリジェントネットワーク（IN）エンティティから。 PSTN /インターネットインターワーキング（PINT）の以前のIETF仕事はサービスのサポートにプロトコル（RFC 2848）の結果の周りに他の方法で開始 - インターネットからPSTNへの。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
このため、このドキュメントはSPIRITSプロトコルのための一般的な要件と同様に、無線では、およびPINTビルディングブロックに関連するものをを示しています。文書はまた、シグナリングプロトコルSPIRITSの選択にSPIRITS WGコンセンサスを提示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristics-- services being invoked from an IP network (vs. PSTN).
それ以外の場合は資格のない限り、用語のPINT本PINTサービスおよびプロトコルを参照しないように、ここで使用されますが、一般的なPINTの範囲を参照して（対SPIRITS）サービスcharacteristics--サービスは、IPネットワーク（対から呼び出されていますPSTN）。
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service.") The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
この文書は、RFC 3136で提示アーキテクチャに基づいSPIRITSプロトコル要件を記述する（SPIRITS「は、PSTNで/インターネットサービスを要求する際にサービス。」の略）プロトコルの目的は、電話を公衆交換に由来するサービスをサポートすることですネットワーク（PSTN）とPSTNとインターネットの間の相互作用を必要とします。このようなサービスはSPIRITSサービスと呼ばれます。 （インターネットキャッチホン、インターネット発信者ID配達、及びインターネット電話転送は、SPIRITサービスの例ですが、プロトコルは、他の多くのサービスを構築することができ、そこからのビルディングブロックを定義することです。）PSTN側では、SPIRITSサービスが開始されていますインテリジェントネットワーク（IN）エンティティから。 PSTN /インターネットインターワーキング（PINT）の以前のIETF仕事はサービスのサポートにプロトコル（RFC 2848）の結果の周りに他の方法で開始 - インターネットからPSTNへの。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. The joint PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.
このため、このドキュメントはSPIRITSプロトコルのための一般的な要件と同様に、無線では、およびPINTビルディングブロックに関連するものをを示しています。文書はまた、シグナリングプロトコルSPIRITSの選択にSPIRITS WGコンセンサスを提示します。 （[1]に記載）関節PINT / SPIRITSアーキテクチャが図1に示されています。
It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in [2].)
PSTN / INの代わりに動作するように、このような方法で（PSTN-指定インターフェースD上）スピリッツクライアントがINサービス制御機能（SCF）と同じ場所に配置又はそれと連通しているいずれかのものとします。 （[2]に報告されているようにこの仮定は、現在の実装によって確認されました。）
The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS gateway. The Spirits gateway processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or
（INサービス制御ポイント[SCP]またはサービス・ノード[SN]にある）SPIRITSクライアントからのメッセージがSPIRITSゲートウェイへのインターフェイスCに到達したときSPIRITSサービスが呼び出される（そして、続いて、SPIRITSプロトコルが開始されます）。スピリッツゲートウェイは、メッセージを処理し、次いで、SPIRITSサーバにインターフェースB上にそれを渡します。最も実用的に重要なケースでは、SPIRITSクライアントからの要求は、最終的には、SCPのいずれかに送信された中央局（すなわち、電話交換機）からの要求によって引き起こされますか、
SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. (Definitely, none of the SPIRITS benchmark services are initiated in such a way, so, for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Service Switching Function.)
セントラルオフィスによってトリガされていなかったこれらの要素により、インターネットベースのサービス開始もののSNは、理論的には可能です。 （確かに、SPIRITSのいずれもベンチマークサービスは、このような方法で開始され、そう、SPIRITSプロトコルの開発のために、サービス呼び出しがサービス切替機能により、以前のアクションの直接の結果であると仮定しなければなりません。）
......................
+----------------+ . .
| +------------+ | . +------------+ .
| | | | A . | | .
| | PINT Client|********************|PINT Server/|********
| | | | . | Gateway | *
| +------------+ | . +------------+ . *
| | . . *
| Subscriber's | . . *
| | . . *
| IP Host | . . *
| | . +------------+ . *
| +------------+ | . | SPIRITS | . *
| | SPIRITS | | B . | Gateway | . *
| | Server |********************| | . * E
| | | | . +------------+ . *
| +------------+ | . * . *
+----------------+ . * . *
...........*.......... *
* *
* *
Subscriber's * C *
Telephone * *
* *
(---) * *
* * *
* * * *
++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++
* * *
* * *
* +------------------+ *
* Line | SPIRITS Client | *
* | | *
+--------------------+ +---+----- D ---------+-*+
| | INAP/SS7 | |
|Service Switching ************Service Control Function |
| Function | | |
| | +-------------------------+
| |
| |
+--------------------+
Figure 1. Joint PINT/SPIRITS Architecture
図1.共同PINT / SPIRITSアーキテクチャ
With PINT (and that also applies to the PINT architecture and protocol as described in [3]), the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by [3]) or communicate with it over the PSTN-specific interface E.
PINTと（そしてそれはまた、[3]に記載のようにPINTアーキテクチャ及びプロトコルに適用される）PINT Serverはどちらかと同じ場所に配置することができるインターフェースA.上、PINTサーバーへサービス要求が常にPINTクライアントによって開始されますINサービス制御やPSTN固有のインタフェースE.上にそれと通信する（[3]により、「執行システム」と呼ぶ）は、類似のエンティティ
As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co-located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Gateway or PINT Server and SPIRITS Client other than by listing the overall PINT-related requirements.
図1に示すように、PINTクライアントとSPIRITSサーバは、加入者のIPホストに同じ場所に配置されています。実際には、両方のは、一つのプロセスとして実行するように実装することができます。規定はPINTクライアントとスピリッツサーバーの間の相互作用のために作られていません。同様に、PINTサーバ/ PINTゲートウェイ、スピリッツゲートウェイは、あまりにも、同じ場所に配置されているものとします。この仮定は便利であるが、必須ではないです。 PINTサーバもSPIRITSクライアントと同じ場所に配置することができます。いずれの場合においても、特別規定をPINTサーバとスピリッツGatewayまたは全体的なPINTに関連する要件をリストすることによって以外PINTサーバ、スピリッツのクライアントのいずれかとの間のインターワーキングを定義するためになされていません。
Since the currently deployed worldwide wireless networks are based on circuit switching, they are considered PSTN networks for the SPIRITS purposes. Adding SPIRITS type of services to wireless networks can allow new services to be developed (for example geolocation information can be handled in the IP network).
現在展開、世界中のワイヤレスネットワークは、回線交換に基づいているので、それらはSPIRITSのためにPSTN網と考えられています。無線ネットワークへのサービスの霊タイプを追加する（例えば、ジオロケーション情報は、IPネットワークで処理することができる）、新たなサービスを開発することを可能にすることができます。
Nevertheless, there are certain peculiarities of wireless networks, which force considerations to be made in the protocol requirements and in the SPIRITS architecture.
それにもかかわらず、プロトコルの要件で、スピリッツアーキテクチャにおいてなされる考察を強制無線ネットワークの特定の特殊性があります。
A particular Wireless IN standard development being considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The relevant service and architectural considerations and protocol requirements are presented later in this document. As far as the architecture is concerned, certain wireless events are generated by Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC) (a wireless equivalent of the SSP). These events are communicated to Service Control, at which point they use the same mechanism for invoking SPIRITS services that the IN would.
ここで検討されている標準的な開発中の特定の無線は、第三世代パートナーシップ・グループ（3GPP）によって標準化され、CAMELフェーズ3です。関連するサービスおよび建築検討事項とプロトコルの要件は、このドキュメントの後半で提示されています。限りアーキテクチャに関しては、特定の無線のイベントは、しかし、移動交換局（MSC）（SSPのワイヤレス相当）の一部である必要はありませんかもしれホームロケーションレジスタ（HLR）、によって生成されます。これらのイベントは、その時点では、INが希望SPIRITSサービスを呼び出すために同じメカニズムを使用して、サービスコントロールに伝達されています。
The rest of this document addresses the general requirements, IN Requirements, specific Wireless IN requirements, PINT Requirements, the protocol development methodology, and security issues, in that order.
このドキュメントの残りの部分は、そのためには、要件では、要件、PINT要件、プロトコルの開発方法論、およびセキュリティ上の問題で特定のワイヤレスの一般的な要件に対応しています。
Based on the success of extending SIP for PINT ([3]) and, especially, the results of pre-SPIRITS implementations reported in [2], the Session Initiation Protocol (SIP) [7] has been chosen as the signaling base protocol for SPIRITS.
PINTのためにSIPを拡張の成功（[3]）に基づいており、特に、に報告プレSPIRITS実装の結果[2]、セッション開始プロトコル（SIP）は、[7]のためのシグナリング・ベースのプロトコルとして選択されていますSPIRITS。
Thus, it is a requirement that specific SPIRITS-related parameters be carried in a manner consistent with SIP practices. In particular, either Session Description Protocol (SDP) [8] or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this purpose. Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and extensions already defined in PINT, no new SIP extensions are foreseen; instead the SPIRITS protocol is to rely on the above extension mechanisms.
したがって、特定SPIRITS関連パラメータがSIP慣行と一致する形で実施することが必要です。いずれか、特に、セッション記述プロトコル（SDP）[8]または多目的インターネットメール拡張MIME [5-6]は、この目的のために使用することができます。 [4]提案された新たなSUBSCRIBE / NOTIFY機構を除いて、既にPINTで定義された拡張は、新たなSIPの拡張は予見されません。代わりSPIRITSプロトコルは、上記拡張メカニズムに依存することです。
It is by no means a requirement that any SPIRITS implementation automatically support PINT services. The SPIRITS protocol must be defined in a manner where, as the minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated [2] that combining PINT building blocks with those of SPIRITS is beneficial to building rich, enhanced PSTN/Internet services, so the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document.
それは決してすべてのSPIRITS実装が自動的にPINTサービスをサポートする要件です。 SPIRITSプロトコルは最低限として、それはPINTサービスに依存するか、そうでなければPSTNとの永続的な相互作用に依存することなく、基本的な通知メカニズムをサポートすることができ、ように定義されなければなりません。それにもかかわらず、それが実証されている[2] SPIRITSのものとPINTのビルディングブロックを組み合わせることSPIRITSプロトコルは、このドキュメントのセクション7に記載されているPINT関連の要件を満たす必要がありますので、豊かな、強化PSTN /インターネットサービスの構築に有益であること。
One specific example demonstrating the application of the latter requirement, which is elaborated on further in this document, is as follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method; however, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to obtain further notifications of the PSTN events. Subsequently, these events will be reported on by means of the NOTIFY method.
次のように本書でさらに上に詳述されている後者の要件、のアプリケーションを示す一の具体例である：SUBSCRIBE / NOTIFYの実装限り最小SPIRITSプロトコルが懸念されるように必須ではありません。したがって、最初のPSTN（検出ポイント）の通知は、常に方法を、SIP INVITEを介して到着します。しかしながら、PSTNとの永続的な相互作用を実現するために、SUBSCRIBEメソッドは、PSTNイベントの更なる通知を得るために使用することができます。その後、これらのイベントは、NOTIFYの方法により、報告されます。
The interface immediately relevant to IN is that between the SPIRITS Client and SPIRITS Gateway (interface C). A typical message (which starts a SPIRITS service) looks like this:
INに直接関連するインターフェースは、SPIRITSクライアントおよびスピリッツゲートウェイ（インターフェースC）の間です。 （SPIRITSサービスを開始します）一般的なメッセージは次のようになります。
C -> G: <Event Notification>, <Parameter-List (DP)>
C - > G <イベント通知>、<パラメータリスト（DP）>
The relevant events correspond to the detection points (DPs) of the IN Basic Call State Model (BCSM). The <Parameter-List> is a function of a specific DP; it contains the parameters relevant to it. The following requirements apply:
関連イベントは、IN基本呼状態モデル（BCSM）の検出点（DPS）に対応しています。 <パラメータ・リスト>特定のDPの関数です。それは、それに関連するパラメータが含まれています。次の要件が適用されます。
1) The list of the DPs to be covered encompasses those defined in the IN Capability Set 3 BCSM as well as those which relate to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.
1）被覆されるのDPのリストは、ITU-TにおけるIMT 2000プロジェクトで指定された無線IN（WIN）に関連するもの、ならびに3 BCSMをセット内の能力の定義されたものを包含する。
2) Not all parameters associated with such DPs are needed by the SPIRITS benchmark services, nor may all the parameters be needed in SPIRITS. The selection of the relevant parameters is part of the SPIRITS protocol definition.
2）などのDPに関連するすべてのパラメータがSPIRITSベンチマークサービスによって必要とされ、またSPIRITSですべてのパラメータを必要とすることができるわけではありません。関連するパラメータの選択はSPIRITSプロトコル定義の一部です。
3) It is desirable to avoid semantic overload of protocol messages. (One way to achieve that is to match each type of an event with a message that corresponds to it.) As the SPIRITS protocol is designed as a set of extensions to another (existing) protocol with the defined message set, the syntax and semantics of the extensions should be defined with this requirement in mind.
3）プロトコルメッセージの意味の過負荷を回避することが望ましいです。 （これを達成する一つの方法は、それに対応するメッセージとイベントの各タイプと一致することである。）SPIRITSプロトコルが定義されたメッセージ・セット、構文およびセマンティクスを有する別の（既存の）プロトコルの拡張のセットとして設計されているよう拡張子の心の中でこの要件を定義する必要があります。
4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) to specify the semantics of the IN Application Protocol (INAP) parameters, which are expected to be binary-encoded. Neither the use of the ASN.1, nor the requirement for binary encoding are the typical requirements for the IETF application protocols. Recognizing that, provisions must be made for careful specification of the conversion of the INAP parameters to text, which must preserve their original semantics. The actual conversion of the parameters is the function of the SPIRITS Client.
4）ITU-T勧告は、バイナリエンコードであることが期待されるINアプリケーションプロトコル（INAP）パラメータのセマンティクスを指定する抽象構文記法（ASN.1）を使用します。 ASN.1の使用、またバイナリ符号化のための要件のいずれもIETFアプリケーションプロトコルのための典型的な要件です。規定は、元のセマンティクスを保護しなければならない、テキストにINAPパラメータの変換の慎重な仕様のために作られなければならない、ということを認識。パラメータの実際の変換はSPIRITSクライアントの関数です。
In order to issue an initial query (or a notification) to service control, a switch must have such a DP set. This can be done statically via service management (this particular action should be left to implementation and thus is considered outside of the scope of SPIRITS Protocol) or dynamically--but only for the purpose of a particular call--from the service control. In the latter case, it is part of the SPIRITS (or PINT) protocol to request the event notification from the service control. The SIP specific event notification scheme [4] should be specifically considered. This function can be performed by either the Spirits Client or PINT Server, the distinction being further discussed in the next section. Assuming that it is performed by the SPIRITS Client, the relevant message should look like:
コントロールにサービスを提供するために、最初のクエリ（または通知）を発行するためには、スイッチは、DPのセットを持っている必要があります。しかし、特定の呼び出しの目的のために - - サービスコントロールからこの動的（この特定のアクションは実装に委ねられるべきであり、従ってSPIRITSプロトコルの範囲外であると考えられる）、またはサービス管理を介して静的に行うことができます。後者の場合には、サービスコントロールからのイベント通知を要求するために魂（またはPINT）プロトコルの一部です。 SIP特定イベント通知方式[4]具体的に考慮されるべきです。この関数は、スピリッツクライアントまたはPINTサーバ、さらに次のセクションで説明される違いのいずれかによって行うことができます。それはSPIRITSクライアントによって実行されると仮定すると、関連するメッセージは、次のようになります。
G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,
G-> C：SUBSCRIBE <イベント> <モード> <DP固有のパラメータ>
where <Event> refers to a particular DP; <Mode> determines whether the Event Detection Point (EDP) is to be armed as EDP Request (EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is not foreseen because it would not provide any additional capability for SPIRITS); and the <DP-specific parameters> is the list of the values of the parameters associated with the EDP (for example, if the DP in question is O_No_Answer, then the value of the appropriate timer should be included in the list). Note that such a subscription may also originate at a) PINT Client or b) SPIRITS Gateway, either of which may (but does not have to) have a locally significant definition of the <Event>. In either case, it is the function of the SPIRITS Client to translate the definition of the Event into a particular DP (or set of DPs) when passing the message to Service Control. To summarize, for the case when PINT and SPIRITS events are defined in a way where they do not refer to the BCSM DPs, it is the function of the SPIRITS Client to define a mapping:
ここで、<イベント>は、特定のDPを指します。 <モード>イベント検出ポイント（EDP）はEDP要求（EDP-R）、EDP通知（EDP-N）として装備される、又はそれがなるので、TDP-R（TDP-Nの必要性が予見されていないか否かを判断します）SPIRITS用の追加機能を提供しません。そして<DP固有のパラメータ>（当該DPがO_No_Answerある場合、例えば、適切なタイマの値がリストに含まれるべきである）EDPに関連付けられたパラメータの値のリストです。 （しかし）<イベント>のローカルで有効な定義を持っている必要はありませんかもしれいずれかが、そのようなサブスクリプションはまた、a）のPINTクライアントまたはb）SPIRITSゲートウェイで生じてもよいことに注意してください。サービスコントロールにメッセージを渡すときのいずれかの場合には、（DPSのセット又は）特定のDPにイベントの定義を翻訳するSPIRITSクライアントの関数です。要約すると、PINTとSPIRITSイベントは、彼らがBCSMのDPを参照していない方法で定義されている場合のために、マッピングを定義するSPIRITSクライアントの関数であります：
Event -> DP List,
イベント - > DP一覧
for each event for which the PSTN notification is needed.
PSTN通知が必要とされている各イベントの。
The list of CS-3 DPs envisioned in SPIRITS is:
SPIRITSで想定されるCS-3のDPのリストは、次のとおりです。
- origination_attempt_authorized (the SPIRITS service can control call attempts, (for example, to limit calls during specific time periods)
- （例えば、特定の時間期間中にコールを制限する）、（SPIRITSサービスが呼の試行を制御することができるorigination_attempt_authorized
- collected_information and analyzed_information (for SPIRITS outgoing call screening)
- （SPIRITS発信コールスクリーニングのため）collected_informationとanalyzed_information
- o_answer, o_term_seized, and t_answer (to release SPIRITS resources after the call is complete and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
- o_answer、o_term_seized、およびt_answer（呼び出しが完了した後SPIRITSのリソースを解放して、このような固定電話、携帯電話、SMS、またはページングのような様々な手段を介してパーティに到達するための試みの記録を作成するなど、関連するOA＆Mのアクションを実行します。 ）
- o_no_answer, route_select_failure, and t_no_answer (to re-route a call)
- o_no_answer、route_select_failure、及びt_no_answer（再ルートコールへ）
- o_called_party_busy (to re-route a call and for Internet Call Waiting)
- o_called_party_busy（再ルーティングコールに、インターネットコールウェイティング用）
- o_mid_call and t_mid_call (to assist a midcall action)
- o_mid_callとt_mid_call（通話中のアクションを支援するために）
- o_abandon, o_disconnect, t_abandon, and t_disconnect (to terminate a SPIRITS service and release the resources and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
- o_abandon、o_disconnect、t_abandon、およびT_DISCONNECT（SPIRITSサービスを終了し、リソースを解放して、このような固定電話、携帯電話、SMS、など様々な手段を介してパーティに到達するための試みの記録を作成するなど、関連するOA＆Mのアクションを実行しますページング。）
In addition, the following DPs are relevant to the present SPIRITS milestone services:
また、以下のDPSが存在SPIRITSマイルストーンサービスに関連しています。
- termination_attempt_authorized
- termination_attempt_authorized
- facility_selected_and_available (could be used in SPIRITS Internet Caller-ID)
- facility_selected_and_available（SPIRITSインターネット発信者IDに使用することができます）
- t_busy (for Internet Call Waiting and Call Forwarding).
- t_busy（インターネットキャッチホンおよび通話転送のため）。
Wireless IN covers several types of "calls," which are neither circuit switched nor have an effect on circuit switched calls. For this reason, those are not considered in SPIRITS requirements. To further clarify this point, the types of "calls" not considered are:
ワイヤレスINはどちらの回路は、通話を切り替え回路に影響を切り替えたり持っている「コール」のいくつかのタイプをカバーしています。このため、これらはSPIRITS要件では考慮されません。この点をさらに明確にするために、考えられない「呼び出し」の種類は次のとおりです。
- USSD (Unstructured Supplementary Service Data)
- USSD（非構造化付加サービスデータ）
- GPRS (General Packet Radio System)
- GPRS（汎用パケット無線システム）
- SMS (Short Message System)
- SMS（ショートメッセージシステム）
The types of calls relevant to SPIRITS are as follows:
次のようにSPIRITSに関連する通話のタイプは次のとおりです。
a) Voice Calls. In this case no new DP is needed since CAMEL DPs are included in CS2. The only special case is "Not Reachable" (when it is detected that the mobile user is out of coverage or has switched off), which is mapped as a special cause in the Busy DP. Since the Busy DP parameters would be received (if a SPIRITS service has subscribed to Busy), it would be possible to distinguish a "busy" from a "not reachable" situation.
a）は音声電話します。 CAMELのDPはCS2に含まれているので、この場合は新しいDPは必要ありません。 （モバイルユーザがカバレージ外であるか、またはオフに切り替わったことが検出された場合）にのみ特別なケースは、ビジーDPにおける特別な原因としてマッピングされ、「到達不能」です。 （SPIRITSサービスがビジーに加入している場合）、ビジーDPパラメータが受信されますので、「到達できない」状況から「忙しい」を区別することが可能です。
This translates into the requirement that one of the parameters in the Event Notification message (from SPIRITS Client to SPIRITS Gateway, over the interface C) denotes the "cause" for the Busy Detection Point.
これは、（インターフェースC上SPIRITSクライアントからSPIRITSゲートウェイに、）イベント通知メッセージ内のパラメータのいずれかがビジー検出ポイントのための「原因」を意味要件に変換されます。
Another aspect of difference, when compared to PSTN, is setting of static DPs. In CAMEL networks, this is done in the Home Location Register (HLR) (and copied to the VLR during location update). It is important to note this difference, even though it has no effect on SPIRITS protocol.
PSTNと比較した場合の差の別の態様は、静的のDPの設定されています。 CAMELネットワークでは、これは、ホームロケーションレジスタ（HLR）で行われ（および位置更新時のVLRにコピーされました）。 SPIRITSプロトコルには影響しませんにもかかわらず、この違いに注意することが重要です。
b) Mobility Management events. This allows a SPIRITS server to be notified of changes of location of a mobile user. The events would only be applicable to mobile users reachable through a Circuit-Switched network. To provide for this function, the subscription marks must be set in the subscriber's HLR. This is equivalent to setting TDPs in the SSP. In this case, the marks in the HLR (which are copied to the Visitor Location Register [VLR] on location update) are not mapped into Trigger Detection Points.
b）のモビリティ管理イベント。これはSPIRITSサーバは、モバイルユーザの位置の変更を通知することができます。イベントは回線交換ネットワークを介して到達可能なモバイルユーザーに適用可能です。この機能を提供するために、サブスクリプションのマークは、加入者のHLRに設定する必要があります。これは、SSPにTDPSを設定することと同じです。この場合、（ビジターロケーションレジスタ位置更新の[VLR]にコピーされる）HLR内のマークは、トリガ検出ポイントにマッピングされていません。
As with TDP setting, this is outside of the scope of SPIRITS protocol.
TDP設定と同様に、これはSPIRITSプロトコルの範囲外です。
In order to support this function in SPIRITS, the SPIRITS protocol should be able to map the CAMEL specific operations into events notification to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface. (This is just an extension of the DP notification mechanism from the SPIRITS client to the SPIRITS gateway).
SPIRITSでこの機能をサポートするために、SPIRITSプロトコルはSPIRITSクライアントにイベント通知にCAMEL特定の操作をマッピングすることができるはずです。 SCPは、モビリティ状態に関する情報を受信するので、これは、Cインタフェースを含みます。 （これは、SPIRITSゲートウェイにSPIRITSクライアントからDP通知メカニズムの単なる拡張です）。
The events (which are not DP-related) which need notifications are:
通知を必要とする（DP-関連していない）イベントは次のとおりです。
- Location Update in the same VLR service area
- 同じVLRサービスエリア内の位置更新
- Location Update in another VLR service area
- 他のVLRサービスエリア内の位置更新
- IMSI attach
- IMSIアタッチ
- MS initiated IMSI detach
- MSは、IMSIデタッチを開始しました
- Network initiated IMSI detach.
- ネットワークは、IMSIデタッチを開始しました。
With this mechanism, the SPIRITS services can use the user-profile-based location information. For example, the Internet Call Waiting service can re-direct the call to a mobile phone.
このメカニズムで、SPIRITSサービスは、ユーザプロファイルに基づく位置情報を使用することができます。例えば、インターネットキャッチホンサービスは、携帯電話への通話を再指示することができます。
c) Supplementary Services Notification.
C）付加サービスの通知。
This mechanism makes a SPIRITS server aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber, or Multi-Party.
このメカニズムは、以下の付加サービスのいずれかを呼び出さした加入者の意識SPIRITSサーバを作る：明示的なコール転送、コールのたわみは、ビジー加入者、またはマルチパーティに完了を呼び出します。
Before a SPIRITS service can be invoked, the relevant IP Host must be registered. Thus, Registration is an essential service, which is initiated from the IP side. The registration information is ultimately used by the PSTN to authenticate the subscriber.
SPIRITSサービスを呼び出すことができる前に、関連するIPホストを登録する必要があります。したがって、登録はIP側から開始される不可欠なサービスです。登録情報は、最終的に加入者を認証するためにPSTNによって使用されます。
Depending on the model, this can be done in two ways with the present architecture:
モデルによっては、これは本アーキテクチャを持つ2つの方法で行うことができます。
1) The PINT Client issues the appropriate Register message over the interface A, which is then passed by the PINT server to the SPIRITS Gateway and SPIRITS Client:
1）PINTクライアントは、SPIRITSゲートウェイとSPIRITSクライアントにPINTサーバによって渡され、インタフェースA上適切なREGISTERメッセージを発行します：
PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS C.]. In this case the SPIRITS Client (co-located with the service control) is responsible for record keeping and the authentication.
PINT C： - 登録 - > PINT S.、[ - >スピリッツゲートウェイ - >スピリッツC.]。この場合、SPIRITSクライアント（サービス制御と同じ場所に配置）は、記録保持および認証を担当しています。
2) The PINT Client issues the appropriate Register message to the PINT Server, which then passes this information to the PSTN service control "by magic".
2）PINTクライアントは、「魔法」PSTNサービス制御にこの情報を渡しPINTサーバへの適切なRegisterメッセージを発行します。
The second model is much easier to handle, because it involves only one relevant interface ("A"); however it assumes no interworking between PINT and SPIRITS except that the SPIRITS Client finds "by magic" that a friendly and expecting IP Host is alive and well.
それが唯一の関連するインターフェース（「A」）を必要とするため、2番目のモデルでは、扱いが非常に簡単です。しかし、それはSPIRITSクライアントがフレンドリーで期待IPホストが健在であることを「魔法で」見つけたことを除いて、PINTとSPIRITS間のインターワーキングを負いません。
Finally, in the event PINT is not implemented, the SIP SUBSCRIBE mechanism can be used.
イベントPINTが実装されていないで最後に、SIPメカニズムを使用することができるSUBSCRIBE。
As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT building blocks [3] must be extended for their use in SPIRITS for the purposes of setting DPs/getting DP event notifications. (A more general SIP mechanism for the same PINT-introduced block is described in [4]; it provides the necessary mechanism for specifying relevant events.) Conversely, the same building blocks for the functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP).
前節で述べたように、既存のPINTビルディングブロックをSUBSCRIBE / NOTIFY [3] DPのイベント通知を取得/のDPを設定する目的のためSPIRITSでの使用のために拡張する必要があります。 （同じPINT-導入ブロックのためのより一般的なSIPメカニズムは、[4]に記載され、それは関連するイベントを指定するために必要なメカニズムを提供する。）逆に、機能的能力のために、同じビルディングブロックは両方PINTとSPIRITSプロトコルで使用することができます。スピリット中PSTN通知が（静的に設定DPの場合）、イベントに特定のサブスクリプションなしで到着することができることは、注意してください。
The requirements of this section are neither PINT-specific, nor IN-specific; their role is to outline the remaining element necessary for the delivery of the SPIRITS service, which is the reaction to the notification received.
このセクションの要件は、どちらもPINT特有の、またIN-固有のものです。それらの役割は、受信された通知に反応であるSPIRITSサービスの配信のために必要な残りの要素を概説することです。
In a particular scenario where:
特定のシナリオではここで、
a) The IP subscriber registers a SPIRITS service;
A）IP加入者はSPIRITSサービスを登録します。
b) A call triggering the SPIRITS service is received (and notification is sent); and
B）SPIRITSサービスをトリガするコールが受信される（および通知が送信されます）。そして
c) The call disposition is performed by the end user, the signalling flow is demonstrated in Figure 2.
C）コール配置がエンドユーザによって実行される、シグナリング・フローは図2に示されています。
|----> Registration ----->|
SPIRITS |<-- Event Notification <-- | SPIRITS
Gateway |---> Call Disposition ---->| Client
| |
|
|
|
V
Service Control
|
|
V
SSP
Figure 2: Sequence of SPIRITS actions
図2：SPIRITSアクションのシーケンス
One of the following actions is required by benchmark services:
次のアクションの一つは、ベンチマークサービスによって必要とされます。
a) Accept the incoming call
a）は、着信コールを受け入れます
b) Reject the incoming call
b）の着信を拒否
c) Redirect the incoming call
C）着信コールをリダイレクト
d) Accept the call via VoIP (this particular item is outside of the scope of SPIRITS WG).
D）（この特定のアイテムがSPIRITS WGの範囲外である）のVoIPを介してコールを受け入れます。
Accordingly, the SPIRITS protocol should define the following message types:
したがって、SPIRITSプロトコルは次のメッセージタイプを定義する必要があります。
a) S->G: <Accept Call>
A）S-> G：<コールを受け入れます>
b) S->G: <[Reject Call],[Cause]>
B）S-> G <>、[原因] [着信拒否]
c) S->G: <[Redirect Call],[Redirection Destination]>
C）S-> G <[リダイレクトコール]、[リダイレクト先]>
To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set of messages), the PSTN events associated with each detection point of the Basic Call State Model should be examined. To date, the CS-3 BSCM has the richest set of DPs, although not all switching exchanges have implemented it.
MINIMUM SPIRITSプロトコル語彙（メッセージの、すなわち、セット）を決定するために、基本呼状態モデルの各検出点に関連付けられたPSTNイベントが検討されるべきです。いないすべてのスイッチング交流はそれを実装しているが、現在までに、CS-3 BSCMは、のDPの豊かなセットを持っています。
To determine the MINIMUM information available to the SPIRITS client (this information is to be carried by the SPIRITS protocol from SPIRITS client to SPIRITS server), each DP-specific information elements needs to be examined.
SPIRITSクライアントに利用可能な最小限の情報を（この情報はSPIRITSサーバにSPIRITSクライアントからSPIRITSプロトコルによって運ばれるべきである）を決定するために、各DP固有情報要素を検討する必要があります。
Parameters should be event-specific, the following generic types of parameters are expected to be mandatory:
パラメータは、イベント固有である必要があり、以下のパラメータの一般的なタイプが必須であることが予想されています。
- timer (for no answer)
- タイマー（応答なしの場合）
- midcall control info (for mid_call)
- 通話中の制御情報（mid_call用）
- number of digits (for collected_information)
- 桁数（collected_information用）
Overall, the basic aspects of security apply to SPIRITS protocol:
全体的に、セキュリティの基本的な側面は、SPIRITSプロトコルに適用されます。
- Authentication: In the communications between the SPIRITS Client and SPIRITS Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is required that the information be sent between known and trusted partners.
- 認証：SPIRITSクライアントとSPIRITSゲートウェイなどSPIRITSゲートウェイとSPIRITSサーバ間の通信では、それは情報が既知の信頼できるパートナーとの間で送信する必要があります。
- Integrity: It is a requirement that no exchanged data be modified in transit.
- 完全性：それはありませんが、データが転送中に変更することが交換条件です。
- Confidentiality: It is a requirement that any private user information or confidential network data be protected by the protocol (typically through encryption, for which the protocol should allow a choice in the algorithm selection.
- 機密性：それはすべてのプライベートユーザ情報や機密ネットワークデータは、プロトコルは、アルゴリズムの選択で選択を許可するべきであるため、通常、暗号化によるプロトコル（によって保護されるという要件です。
- Availability: It is a requirement that the communicating endpoints remain in service for authorized use only.
- 可用性：それは、通信のエンドポイントのみが許可された使用のためのサービスに残る要件です。
In addition, the protocol should support non-repudiation for those control messages pertinent to charging the PSTN subscriber.
また、プロトコルは、PSTN加入者の課金に関連するこれらの制御メッセージの否認防止をサポートしなければなりません。
As Figure 1 demonstrates, there are two distinct communications interfaces, B and C. The B interface is, in general, across the public Internet and is thus most vulnerable to security attacks resulting in theft or denial of service. The C interface, on the other hand is likely to be implemented across a service providers intranet, where the security measures should be applied at the discretion of the service provider. Even then, because at least one IP host (the PINT gateway) is connected to the Internet, special measures (e.g., installation of firewalls, although this particular measure alone may be insufficient) need to be taken to protect the interface C and the rest of the network from security attacks.
図1が示すように、二つの別個の通信インタフェース、BおよびC Bのインタフェースは、公衆インターネット上、一般的に、あるので、盗難やサービスの拒否をもたらすセキュリティ攻撃に対して最も脆弱です。 Cインタフェースは、一方のセキュリティ対策は、サービスプロバイダの裁量で適用すべきサービスプロバイダイントラネット、渡って実施される可能性が高いです。その場合でも、少なくとも1つのIPホスト（PINTゲートウェイ）がインターネットに接続されているため、特別な措置（例えば、ファイアウォールの設置、単独でこの特定の措置が不十分であってもよいが）界面Cと残りの部分を保護するために取られる必要がありますセキュリティ攻撃からネットワークの。
The assumption that the PINT Client and SPIRITS server are co-located, dictates that the security considerations for the A and B interfaces are exactly same. Detailed security requirements and solutions for interface A (and, consequently, B) can be found in RFC 2848 [3].
PINTクライアントとSPIRITSサーバが同じ場所に配置されていることを仮定は、AとBのインターフェイスのためのセキュリティ問題は全く同じであることを指示します。インターフェースA（及び、従って、B）の詳細なセキュリティ要件およびソリューションは、RFC 2848に見出すことができる[3]。
Possible security attacks can result in both theft and denial of services. In addition, such attacks may violate the privacy of a PSTN subscriber. For example, with Internet Call Waiting, a fraudulent registration (or a manipulation of integrity of a valid registration) may force a network operator to provide to an authorized party a full log of attempted telephone calls (accompanied by the identification of callers). Furthermore, the calls may be diverted to wrong recipients (who may further defraud the unsuspecting calling party). In this case, the calling party is using only the PSTN and thus expecting the security of communications that are typical of the PSTN. The PSTN service providers may be liable for the consequences of establishing wrong connections. In addition, the PSTN service providers may be liable for inadvertent divulging of the private information of the subscriber.
可能性のあるセキュリティ攻撃は、サービスの窃盗と否定の両方をもたらす可能性があります。また、このような攻撃は、PSTN加入者のプライバシーを侵害することがあります。例えば、インターネットキャッチホン、不正登録（または有効な登録の整合性の操作）で認可パーティにしようとした電話の通話（発信者の識別を伴う）の完全なログを提供するために、ネットワークオペレータを強制することがあります。さらに、呼び出しは（さらに疑うことを知らない発信者をだますこと）間違った受信者に流用することができます。この場合、発呼者は唯一のPSTNを使用して、したがって、PSTNの典型的な通信のセキュリティを期待しています。 PSTNサービスプロバイダは、間違った接続を確立するの結果について責任を負うことがあります。また、PSTNサービスプロバイダーは、加入者の個人情報の不用意な漏洩のために責任を負うことがあります。
The service and network providers need to review the possibilities of the security attacks and prepare the means of protection from them. Some of this may be achieved by using the means outside of those provided by the protocol itself. For example, administrative information (such as statistics collected by PINT MIB or SPIRITS MIB) can help in determining violations and thwarting them. As far as the protocol is concerned, it must provide the means for authenticating a subscriber as well as a session. It must also provide a capability to carry encrypted information in its body.
サービスおよびネットワークプロバイダがセキュリティ攻撃の可能性を検討し、それらからの保護の手段を準備する必要があります。これのいくつかは、プロトコル自体によって提供されるものの外の手段を使用することによって達成することができます。例えば、（例えばPINT MIBまたはSPIRITS MIBによって収集された統計情報など）の管理情報は、違反を決定し、それらを阻止するのに役立ちます。限りプロトコルに関しては、それは加入者だけでなく、セッションを認証するための手段を提供しなければなりません。また、その本体内の暗号化された情報を運ぶための機能を提供しなければなりません。
The authors are grateful to all participants in the SPIRITS group for the discussion that has been shaping this work. Many thanks go to Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren Nyckelgard, and John Voelker for their incisive comments. Special thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose careful, detailed reviews of several versions of this document have been particularly helpful in improving its quality.
作者はこの作品を形作るされてきた議論のためSPIRITSグループ内のすべての参加者に感謝しています。多くのおかげでは、彼らの鋭いコメントをヨルゲンBjorkner、アレックBrusilovsky、ジム・ブラー、ローレンスコンロイ、ソレンNyckelgard、ジョンVoelkerに行きます。特別な感謝は、その慎重に、このドキュメントのいくつかのバージョンの詳細なレビューは、その質の向上に特に役立っているビジェイGurbani、デイブHewins、とクマーVemuriにあります。
[1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits Architecture", RFC 3136, June 2001.
[1] Slutsman、L.、Faynberg、I.、陸、H.およびM.ワイズマン、 "スピリッツアーキテクチャ"、RFC 3136、2001年6月。
[2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang, W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS Implementations of PSTN-Initiated Services", RFC 2995, November 2000.
[2]呂、H.（編集）、Faynberg、I.、Voelker、J.、ワイスマン、M.、チャン、W.、Rhim、S.、黄、J.、前、S.、Moeenuddin、S. 、Hadvani、S.、Nyckelgard、S.、ヨーカム、J.及びL. ROBART、 "PSTN-開始サービスのプレSPIRITS実装"、RFC 2995、2000年11月。
[3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[3] 2000 Petrackと、S.とL.コンロイ、 "パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張"、RFC 2848、2000年6月を。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[7]ハンドレー、M.、学生はE.、Schulzrinneと、H.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[8] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8]ハンドレー、M.およびV.ヤコブセン、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
Lev Slutsman AT&T Laboratories 200 Laurel Ave. Middletown, New Jersey, 07748
レフSlutsman AT＆T研究所200ローレルアベニュー。ミドルタウン、ニュージャージー州、07748
Phone: (732) 420-3752 EMail: lslutsman@att.com
電話：（732）420-3752 Eメール：lslutsman@att.com
Igor Faynberg Bell Labs/Lucent Technologies Room 4D-601A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
イゴールFaynbergベル研究所/ルーセント・テクノロジーズルーム4D-601A、101 Crawfordsコーナー道路ホルムデル、ニュージャージー州、07733
Phone: (732) 949-0137 EMail: faynberg@lucent.com
電話：（732）949-0137 Eメール：faynberg@lucent.com
Jorge Gato Vodaphone Avda de Europa, 1. 28108 Alcobendas (Madrid). Spain
ホルヘ・ガトーボーダフォン星Avdaデエウロパ、1つの28108のアルコベンダス（マドリード）。スペイン
Phone: +34 607 13 31 10 Fax: +34 607 13 30 57 EMail: jgato@airtel.es
電話：+34 607 13 31 10ファックス：+34 607 13 30 57 Eメール：jgato@airtel.es
Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
ホイ-LANルーベル研究所/ルーセント・テクノロジーズルーム4C-607A、101 Crawfordsコーナー道路ホルムデル、ニュージャージー州、07733
Phone: (732) 949-0321 EMail: huilanlu@lucent.com
電話：（732）949-0321 Eメール：huilanlu@lucent.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。