Network Working Group V. Gurbani, Ed.
Request for Comments: 3910 A. Brusilovsky
Category: Standards Track I. Faynberg
Lucent Technologies, Inc.
J. Gato
Vodafone Espana
H. Lu
Bell Labs/Lucent Technologies
M. Unmehopa
Lucent Technologies, Inc.
October 2004
The SPIRITS (Services in PSTN requesting Internet Services) Protocol
SPIRITS（インターネットサービスを要求してPSTNにおけるサービス）プロトコル
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built.
この文書は、インターネットサービス（SPIRITS）プロトコルを要求（公衆交換電話網）PSTNでのサービスについて説明します。 SPIRITSプロトコルの目的は、細胞または有線PSTNに由来し、PSTNとインターネットとの間の相互作用を必要とするサービスをサポートすることです。 PSTN側では、SPIRITSサービスは、ほとんどの場合、インテリジェントネットワーク（IN）エンティティから開始されます。セルラーネットワーク上のロケーションベースのサービスがそうであるように、インターネットキャッチホンとインターネット発信者ID配達は、SPIRITSサービスの例です。プロトコルは、他の多くのサービスを構築することができ、そこからビルディングブロックを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document. . . . . . . . . . . 3
2. Overview of operations. . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . 6
3. Using XML for subscription and notification . . . . . . . . . 7
4. XML format definition . . . . . . . . . . . . . . . . . . . . 8
5. Call-related events . . . . . . . . . . . . . . . . . . . . . 10
5.1. IN-specific requirements . . . . . . . . . . . . . . . 11
5.2. Detection points and required parameters . . . . . . . 12
5.2.1. Originating-side DPs. . . . . . . . . . . . . 12
5.2.2. Terminating-side DPs. . . . . . . . . . . . . 14
5.3. Services through dynamic DPs . . . . . . . . . . . . . 15
5.3.1. Normative usage . . . . . . . . . . . . . . . 15
5.3.2. Event package name. . . . . . . . . . . . . . 16
5.3.3. Event package parameters. . . . . . . . . . . 16
5.3.4. SUBSCRIBE bodies. . . . . . . . . . . . . . . 16
5.3.5. Subscription duration . . . . . . . . . . . . 17
5.3.6. NOTIFY bodies . . . . . . . . . . . . . . . . 17
5.3.7. Notifier processing of SUBSCRIBE requests . . 18
5.3.8. Notifier generation of NOTIFY requests. . . . 18
5.3.9. Subscriber processing of NOTIFY requests. . . 19
5.3.10. Handling of forked requests . . . . . . . . . 19
5.3.11. Rate of notifications . . . . . . . . . . . . 19
5.3.12. State Agents. . . . . . . . . . . . . . . . . 20
5.3.13. Examples. . . . . . . . . . . . . . . . . . . 20
5.3.14. Use of URIs to retrieve state . . . . . . . . 25
5.4. Services through static DPs. . . . . . . . . . . . . . 25
5.4.1. Internet Call Waiting . . . . . . . . . . . . 26
5.4.2. Call disposition choices. . . . . . . . . . . 26
5.4.3. Accepting an ICW session using VoIP . . . . . 28
6. Non-call related events . . . . . . . . . . . . . . . . . . . 29
6.1. Non-call events and their required parameters. . . . . 29
6.2. Normative usage. . . . . . . . . . . . . . . . . . . . 30
6.3. Event package name . . . . . . . . . . . . . . . . . . 30
6.4. Event package parameters . . . . . . . . . . . . . . . 31
6.5. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . 31
6.6. Subscription duration. . . . . . . . . . . . . . . . . 31
6.7. NOTIFY bodies. . . . . . . . . . . . . . . . . . . . . 32
6.8. Notifier processing of SUBSCRIBE requests. . . . . . . 32
6.9. Notifier generation of NOTIFY requests . . . . . . . . 32
6.10. Subscriber processing of NOTIFY requests . . . . . . . 33
6.11. Handling of forked requests. . . . . . . . . . . . . . 33
6.12. Rate of notifications. . . . . . . . . . . . . . . . . 33
6.13. State Agents . . . . . . . . . . . . . . . . . . . . . 33
6.14. Examples . . . . . . . . . . . . . . . . . . . . . . . 33
6.15. Use of URIs to retrieve state. . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Registering event packages . . . . . . . . . . . . . . 38
7.2. Registering MIME type. . . . . . . . . . . . . . . . . 38
7.3. Registering URN. . . . . . . . . . . . . . . . . . . . 39
7.4. Registering XML schema . . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. XML schema definition . . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 45
11. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 48
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50
SPIRITS (Services in the PSTN Requesting Internet Services) is an IETF architecture and an associated protocol that enables call processing elements in the telephone network to make service requests that are then processed on Internet hosted servers. The term Public Switched Telephone Network (PSTN) is used here to include the wireline circuit-switched network, as well as the wireless circuit-switched network.
SPIRITSは、（PSTNでのサービスは、インターネットサービスを要求）IETFアーキテクチャおよびサーバーをホスティングされ、その後、インターネット上で処理されているサービス要求を作成する電話ネットワークにおける呼処理要素を可能に関連するプロトコルです。公衆交換電話網（PSTN）用語は、有線の回線交換網と同様に、無線回線交換網を含めるために、ここで使用されています。
The earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated in the reverse direction - from the Internet to PSTN.
インターネットからPSTNへ - PSTN /インターネットインターワーキング（PINT）の以前のIETF仕事は逆方向に開始されたサービスをサポートするためにプロトコル（RFC 2848）が生じました。
This document has been written in response to the SPIRITS WG chairs call for SPIRITS Protocol proposals. Among other contributions, this document is based on:
この文書は、WGチェアがSPIRITSプロトコルの提案のための呼び出しSPIRITSに応じて書かれています。他の貢献の中で、この文書はに基づいています。
o Informational "Pre-SPIRITS implementations" [10] o Informational "The SPIRITS Architecture" [1] o Informational "SPIRITS Protocol Requirements" [4]
情報O O情報 "プレSPIRITS実装" [10] "SPIRITSアーキテクチャ" [1] O情報 "SPIRITSプロトコル要件" [4]
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 BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
The purpose of the SPIRITS protocol is to enable the execution of services in the Internet based on certain events occurring in the PSTN. The term PSTN is used here to include all manner of switching; i.e. wireline circuit-switched network, as well as the wireless circuit-switched network.
SPIRITSプロトコルの目的は、PSTNで発生する特定のイベントに基づいて、インターネットでのサービスの実行を可能にするためです。用語PSTNは、スイッチングのすべての方法を含むようにここに使用されます。すなわち、有線回路交換ネットワーク、ならびに無線回線交換網。
In general terms, an Internet host is interested in getting notifications of certain events occurring in the PSTN. When the event of interest occurs, the PSTN notifies the Internet host. The Internet host can execute appropriate services based on these notifications.
一般的には、インターネットホストは、PSTNで発生する特定のイベントの通知を得ることに興味があります。興味のあるイベントが発生すると、PSTNは、インターネットホストに通知します。インターネットホストは、これらの通知に基づいて、適切なサービスを実行することができます。
+------+
| PSTN |
|Events|
+------+
/ \
/ \
+-------+ +--------+
|Call | |Non-Call|
|Related| |Related |
+-------+ +--+-----+
/ \ |
/ \ |
+---/--+ +---\---+ +--+-----------------+
|Static| |Dynamic| |Mobility Management/|
| | | | |Registration/De- |
+------+ +-------+ |registration |
+--------------------+
Figure 1: The SPIRITS Hierarchy.
図1：SPIRITS階層。
Figure 1 contains the SPIRITS events hierarchy, including their subdivision in two discrete classes for service execution: events related to the setup, teardown and maintenance of a call and events un-related to call setup, teardown or maintenance. Example of the latter class of events are geo-location mobility events that are tracked by the cellular PSTN. SPIRITS will specify the framework to provide services for both of these types of events.
コールのセットアップ、ティアダウンやメンテナンスに関連するイベントやイベントのセットアップ、ティアダウンやメンテナンスを呼び出すために、非関連：図1は、サービス実行のための2つの別々のクラスでの細分化を含め、SPIRITSイベントの階層が含まれています。イベントの後者のクラスの例は、細胞PSTNによって追跡されるジオロケーションモビリティイベントです。 SPIRITSは、イベントのこれらのタイプの両方のためのサービスを提供するためのフレームワークを指定します。
Call-related events, its further subdivisions, and how they enable services in the Internet is contained in Section 5. Services enabled from events not related to call setup, teardown, or maintenance are covered in detail in Section 6.
コール関連のイベント、そのさらに細分化し、それらがどのようにインターネットでサービスを有効に設定、ティアダウン、またはメンテナンスを呼び出すために関係のない事象から有効5.サービスは、第6節で詳しく説明されているセクションに含まれています。
For reference, the SPIRITS architecture from [1] is reproduced below. This document is focused on interfaces B and C only. Interface D is a matter of local policy; the PSTN operator may have a functional interface between the SPIRITS client or a message passing interface. This document does not discuss interface D in any detail.
参考のために、[1]からSPIRITSアーキテクチャが以下に再現されます。この文書は、インタフェースB及びCのみに焦点を当てています。インターフェースDは、ローカルポリシーの問題です。 PSTNオペレータはSPIRITSクライアントまたはメッセージパッシングインタフェースとの間の機能的なインターフェイスを有していてもよいです。このドキュメントは、詳細には、インタフェースDについては説明しません。
+--------------+
| Subscriber's |
| IP Host | +--------------+
| | | |
| +----------+ | | +----------+ |
| | PINT | | A | | PINT | |
| | Client +<-------/-------->+ Gateway +<-----+
| +----------+ | | +----------+ | |
| | | | |
| +----------+ | | +----------+ | |
| | SPIRITS | | B | | SPIRITS | | |
| | Server +<-------/-------->+ Gateway | | |
| +----------+ | | +--------+-+ | |
| | | ^ | |
+--------------+ +----------|---+ |
| |
IP Network | |
------------------------------------------|--------|---
PSTN / C / E
| |
v |
+----+------+ |
| SPIRITS | |
| Client | v
+-------------------+ +---+-----D-----+-++
| Service Switching |INAP/SS7 | Service Control |
| Function +---------+ Function |
+----+--------------+ +------------------+
|
|line
+-+
[0] Subscriber's telephone
Figure 2: The SPIRITS Architecture.
図2：SPIRITSアーキテクチャ。
(Note: The interfaces A-E are described in detail in the SPIRITS Architecture document [1].)
（注：インターフェースA-Eは、SPIRITSアーキテクチャ文書[1]に詳細に記載されています。）
The PSTN today supports service models such as the Intelligent Network (IN), whereby some features are executed locally on switching elements called Service Switching Points (SSPs). Other features are executed on service elements called Service Control Points (SCPs). The SPIRITS architecture [1] permits these SCP elements to act as intelligent entities to leverage and use Internet hosts and capabilities to further enhance the telephone end-user's experience.
PSTN今日は、このようないくつかの機能は、スイッチングサービスと呼ばれるスイッチング素子ポイント（SSPの）上でローカルに実行されていることにより、インテリジェントネットワーク（IN）、などのサービスモデルをサポートしています。その他の機能は、サービス制御ポイント（SCPに）と呼ばれるサービス要素上で実行されています。 SPIRITSアーキテクチャは、[1]、さらに電話、エンドユーザーの体験を向上させるために、インターネットホストおよび機能を活用して使用するなどのインテリジェントエンティティを動作するようにこれらのSCP要素を可能にします。
The protocol used on interfaces B and C consists of the SPIRITS protocol, and is based on SIP and SIP event notification [3]. The requirements of a SPIRITS protocol and the choice of using SIP as an enabler are detailed in [4].
インターフェースB及びCに使用されるプロトコルはSPIRITSプロトコルからなり、SIP及びSIPイベント通知に基づいている[3]。 SPIRITSプロトコルとイネーブラとしてSIPを使用しての選択の要件は、[4]に詳述されています。
The SPIRITS protocol is a set of two "event packages" [3]. It contains the procedural rules and semantic context that must be applied to these rules for processing SIP transactions. The SPIRITS protocol has to carry subscriptions for events from the SPIRITS server to the SPIRITS client and notifications of these events from the SPIRITS client to the SPIRITS server. Extensible Markup Language (XML) [12] is used to codify the subscriptions and notifications.
SPIRITSプロトコルは、2つの「イベント・パッケージ」の組である[3]。これは、SIPトランザクションを処理するためにこれらのルールに適用されなければならない手続規則とセマンティックコンテキストが含まれています。 SPIRITSプロトコルはSPIRITSサーバにSPIRITSクライアントからSPIRITSクライアントとこれらのイベントの通知にSPIRITSサーバからのイベントのサブスクリプションを運ぶために持っています。拡張マークアップ言語（XML）[12]は、サブスクリプションと通知を体系化するために使用されます。
Finally, in the context of ensuing discussion, the terms "SPIRITS server" and "SPIRITS client" are somewhat confusing since the roles appear reversed; to wit, the "SPIRITS server" issues a subscription which is accepted by a "SPIRITS client". To mitigate such ambiguity, from now on, we will refer to the "SPIRITS server" as a "SPIRITS subscriber" and to the "SPIRITS client" as a "SPIRITS notifier". This convention adheres to the nomenclature outlined in [3]; the SPIRITS server in Figure 2 is a subscriber (issues subscriptions to events), and the SPIRITS client in Figure 2 is a notifier (issues notifications whenever the event of interest occurs).
最後に、議論をその後の文脈では、用語「SPIRITSサーバ」と「SPIRITSクライアントは、」役割が逆転現れるので、多少混乱しています。ウィットに、「SPIRITSサーバは」「SPIRITSクライアント」によって受け入れられているサブスクリプションを発行します。今から、そのような曖昧さを緩和するために、我々は「通知SPIRITS」として「SPIRITS加入者」と「SPIRITSクライアント」へと「SPIRITSサーバ」を参照してくださいます。この規則は、[3]に概説された命名法に準拠します。図2のSPIRITSサーバは、加入者（イベントへの問題のサブスクリプションを）であり、図2のSPIRITSクライアントは、通知（該当するイベントが発生するたびに問題の通知）です。
For ease of reference, we provide a terminology of the SPIRITS actors discussed in the preceding above:
参照を容易にするために、我々は、上記の先行で議論SPIRITS俳優の用語を提供します。
Service Control Function (SCF): A PSTN entity that executes service logic. It provides capabilities to influence the call processing occurring in the Service Switching Function (SSF). For more information on how a SCF participates in the SPIRITS architecture, please see Sections 5 and 5.1.
サービス制御機能（SCF）：サービスロジックを実行PSTNエンティティ。これは、サービス交換機能（SSF）で発生した呼処理に影響を与えるための機能を提供します。 SCFはSPIRITSアーキテクチャの参加方法の詳細については、セクション5と5.1を参照してください。
SPIRITS client: see SPIRITS notifier.
SPIRITSクライアント：SPIRITS通知を参照してください。
SPIRITS server: see SPIRITS subscriber.
SPIRITSサーバ：SPIRITS加入者を参照してください。
SPIRITS notifier: A User Agent (UA) in the PSTN that accepts subscriptions from SPIRITS subscribers. These subscriptions contain events that the SPIRITS subscribers are interested in receiving a notification for. The SPIRITS notifier interfaces with the Service Control Function such that when the said event occurs, a notification will be sent to the relevant SPIRITS subscriber.
通知SPIRITS：SPIRITS加入者からのサブスクリプションを受け入れるPSTNにおけるユーザーエージェント（UA）。これらのサブスクリプションは、SPIRITS加入者がのために通知を受け取ることに興味があるイベントが含まれています。精神は、前記イベントが発生した場合、通知が関連SPIRITS加入者に送信されるように、サービス制御機能とインターフェースをチェッカー。
SPIRITS subscriber: A UA in the Internet that issues a subscription containing events in the PSTN that it is interested in receiving a notification for.
SPIRITS加入者：それはのための通知を受信することに関心があるPSTN内のイベントを含むサブスクリプションを発行し、インターネットでUA。
The SPIRITS protocol requirements mandate that "SPIRITS-related parameters be carried in a manner consistent with SIP practices" (RFC3298:Section 3). SIP already provides payload description capabilities through the use of headers (Content-Type, Content-Length). This document defines a new MIME type -- "application/spirits-event+xml" -- and registers it with IANA (Section 7). This MIME type MUST be present in the "Content-Type" header of SPIRITS requests and responses, and it describes an XML document that contains SPIRITS-related information.
（：第3 RFC3298）、「SPIRITS関連パラメータがSIP慣行と一致する形で実施すること」というSPIRITSプロトコル要件委任。 SIPは、既にヘッダ（コンテンツタイプ、コンテンツ長）の使用を介してペイロード記述機能を提供します。 「アプリケーション/霊イベント+ xmlの」 - - この文書は、新しいMIMEタイプを定義し、IANA（第7節）とそれを登録します。このMIMEタイプは、「Content-Typeの」SPIRITSの要求と応答のヘッダ内に存在しなければならない、そしてそれはSPIRITS関連の情報を含むXML文書を記述しています。
This document defines a base XML schema for subscriptions to PSTN events. The list of events that can be subscribed to is defined in the SPIRITS protocol requirements document [4] and this document provides an XML schema for it. All SPIRITS subscribers (any SPIRITS entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request) MUST support this schema. All SPIRITS notifiers (any SPIRITS entity capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE request) MUST support this schema. The schema is defined in Section 9.
この文書では、PSTNイベントへのサブスクリプションベースのXMLスキーマを定義します。加入することができるイベントのリストがSPIRITSプロトコル要件文書に定義されている[4]この文書は、それのためのXMLスキーマを提供します。すべてのSPIRITS加入者（、SUBSCRIBE REGISTER、またはINVITEリクエストを発行することができる任意のSPIRITS実体）は、このスキーマをサポートしなければなりません。全てSPIRITSの通知（SUBSCRIBE REGISTER、またはINVITE要求を受信して処理することができる任意のSPIRITSエンティティ）は、このスキーマをサポートしなければなりません。スキーマは、セクション9で定義されています。
The support for the SIP REGISTER request is included for PINT compatibility (RFC3298:Section 6).
SIP REGISTER要求のサポートはPINT互換性（：セクション6 RFC3298）のために含まれています。
The support for the SIP INVITE request is mandated because pre-existing SPIRITS implementations did not use the SIP event notification scheme. Instead, the initial PSTN detection point always arrived via the SIP INVITE request.
既存のSPIRITS実装がSIPのイベント通知スキームを使用していなかったので、SIP INVITEリクエストをのサポートが義務付けられています。代わりに、最初のPSTN検出点は、常にSIP INVITE要求を経由して到着しました。
This document also defines a base XML schema for notifications of events (Section 9). All SPIRITS notifiers MUST generate XML documents that correspond to the base notification schema. All SPIRITS subscribers MUST support XML documents that correspond to this schema.
この文書はまた、イベント（第9）の通知のためのベースXMLスキーマを定義します。すべてのSPIRITS通知者は、基本通知スキーマに対応するXML文書を生成しなければなりません。すべてのSPIRITS加入者は、このスキーマに対応するXML文書をサポートしなければなりません。
The set of events that can be subscribed to and the amount of notification that is returned by the PSTN entity may vary among different PSTN operators. Some PSTN operators may have a rich set of events that can be subscribed to, while others have only the primitive set of events outlined in the SPIRITS protocol requirements document [4]. This document defines a base XML schema (in Section 9) which MUST be used for the subscription and notification of the primitive set of events. In order to support a richer set of event subscription and notification, implementations MAY use additional XML namespaces corresponding to alternate schemas in a SPIRITS XML document. However, all implementations MUST support the base XML schema defined in Section 9 of this document. Use of the base schema ensures interoperability across implementations, and the inclusion of additional XML namespaces allows for customization.
加入することができ、PSTNエンティティによって返された通知の量が異なるPSTN事業者の間で変化することができるイベントのセット。他のものはSPIRITSプロトコル要件文書[4]に概説されたイベントのみプリミティブセットを有するが、いくつかのPSTNオペレータは、サブスクライブすることができるイベントの豊富なセットを有することができます。この文書では、イベントのプリミティブセットの加入と通知のために使用されなければならない（セクション9）ベースのXMLスキーマを定義します。イベント・サブスクリプションと通知の豊かなセットをサポートするために、実装はSPIRITS XMLドキュメント内の代替スキーマに対応する追加のXML名前空間を使用するかもしれません。ただし、すべての実装は、このドキュメントのセクション9で定義された基本XMLスキーマをサポートしなければなりません。ベーススキーマの使用は、実装間の相互運用性を保証し、そして追加のXML名前空間を含めることは、カスタマイズを可能にします。
A logical flow of the SPIRITS protocol is depicted below (note: this example shows a temporal flow; XML documents and related SPIRITS protocol syntax is specified in later sections of this document). In the flow below, S is the SPIRITS subscriber and N is the SPIRITS notifier. The SPIRIT Gateway is presumed to have a pure proxying functionality and thus is omitted for simplicity:
SPIRITSプロトコルの論理的な流れを以下に示されている（注：この例では、時間的な流れを示し、XML文書と関連SPIRITSプロトコルの構文は、この文書の後のセクションで指定されています）。以下のフローでは、Sは、SPIRITS加入者であり、Nは、通知SPIRITSあります。 SPIRITゲートウェイは、純粋なプロキシ機能を持っていると推定されるので、簡単のために省略されています。
1 S->N Subscribe (events of interest in an XML document instance using base subscription schema) 2 N->S 200 OK (Subscribe) 3 N->S Notify 4 S->N 200 OK (Notify communicating current resource state) 5 ... 6 N->S Notify (Notify communicating change in resource state; payload is an XML document instance using XML extensions to the base notification schema) 7 S->N 200 OK (Notify)
1 S-> N（ベース・サブスクリプション・スキーマを使用してXMLドキュメントインスタンスへの関心のイベント）2 N-> S 200 OK（購読）3 N-> S 4 S-> Nに通知する200 OKを（現在のリソース状態を通信する通知）購読5 ... 6 N-> S通知（リソース状態の変化を通信する通知、ペイロードは、基本通知スキーマにXML拡張を使用して、XML文書インスタンスである）7 S-> N 200 OK（通知）
In line 1, the SPIRITS subscriber subscribes to certain events using an XML document based on the base schema defined in this document. In line 6, the SPIRITS notifier notifies the SPIRITS subscriber of the occurrence of the event using extensions to the base notification schema. Note that this document defines a base schema for event notification as well; the SPIRITS notifier could have availed itself of these. Instead, it chooses to pass to the SPIRITS subscriber an XML document composed of extensions to the base notification schema. The SPIRITS subscriber, if it understands the extensions, can interpret the XML document accordingly. However, in the event that the SPIRITS subscriber is not programmed to understand the extensions, it MUST search the XML document for the mandatory elements. These elements MUST be present in all notification schemas and are detailed in Section 9.
1行目では、SPIRITS加入者は、この文書で定義されたベース・スキーマに基づいたXML文書を使用して、特定のイベントをサブスクライブ。 6行目では、スピリッツ通知基地通知スキーマに拡張を使用して、イベントの発生のSPIRITS加入者に通知します。この文書は、同様に、イベント通知のためのベース・スキーマを定義することに注意してください。 SPIRITSは通知これらの自分自身を役に立つことができました。代わりに、ベース通知スキーマの拡張からなるXML文書を加入者SPIRITSに渡すことを選択します。 SPIRITS加入者は、それが拡張を理解している場合、それに応じてXMLドキュメントを解釈することができます。しかし、SPIRITS加入者が拡張を理解するようにプログラムされていない場合には、それは必須要素のためのXML文書を検索する必要があります。これらの要素は、すべての通知のスキーマに存在しなければならず、第9章で詳しく説明されています。
This section defines the XML-encoded SPIRITS payload format. Such a payload is a well formed XML document and is produced by SPIRITS notifiers and SPIRITS subscribers.
このセクションでは、XMLでエンコードされたスピリッツペイロードフォーマットを定義します。そのようなペイロードは整形式XML文書であり、スピリッツの通知とSPIRITS加入者によって生成されます。
The namespace URI for elements defined in this document is a Uniform Resource Name (URN) [14], using the namespace identifier 'ietf' defined in [15] and extended by [16]:
この文書で定義された要素の名前空間URIは、[15]で定義されており[16]によって拡張「IETF」名前空間識別子を使用して、ユニフォームリソース名（URN）[14]です。
urn:ietf:params:xml:ns:spirits-1.0
URN：IETF：のparams：XML：NS：霊-1.0
SPIRITS XML documents may have a default namespace, or they may be associated with a namespace prefix following the convention established in XML namespaces [17]. Regardless, the elements and attributes of SPIRITS XML documents MUST conform to the SPIRITS XML schema specified in Section 9.
SPIRITS XMLドキュメントには、デフォルトの名前空間を有していてもよく、またはそれらは、XML名前空間[17]で設立大会次の名前空間接頭辞に関連付けられてもよいです。かかわらず、SPIRITS XMLドキュメントの要素と属性は、セクション9で指定されたSPIRITS XMLスキーマに従わなければなりません。
The <spirits-event> element The root of a SPIRITS XML document (characterized by a Content-Type header of "application/spirits-event+xml">) is the <spirits-event> element. This element MUST contain a namespace declaration ('xmlns') to indicate the namespace on which the XML document is based. XML documents compliant to the SPIRITS protocol MUST contain the URN "urn:ietf:params:xml:ns:spirits-1.0" in the namespace declaration. Other namespaces may be specified as needed.
<スピリッツイベント>要素（ "アプリケーション/スピリッツイベント+ XML" のContent-Typeヘッダによって特徴付け>）SPIRITS XMLドキュメントのルート要素> <スピリッツイベントです。この要素は、XML文書が基づいている名前空間を示すために、名前空間宣言（「のxmlns」）を含まなければなりません。名前空間宣言でSPIRITSプロトコルに準拠したXMLドキュメントはURN "：IETF：のparams：XML：：NS-霊1.0 URN" を含まなければなりません。必要に応じて他の名前空間を指定することができます。
<spirits-event> element MUST contain at least one <Event> element, and MAY contain more than one.
<霊-イベント>要素は、少なくとも一つの<イベント>要素を含まなければならない、と以上のものを含むかもしれません。
The <Event> element The <Event> element contains three attributes, two of which are mandatory. The first mandatory attribute is a 'type' attribute whose value is either "INDPs" or "userprof".
<イベント>要素<イベント>要素は必須ですそのうち2つ3つの属性が含まれています。最初の必須属性は、値が「INDPs」または「userprof」のいずれかである「タイプ」属性です。
These types correspond, respectively, to call-related events described in Section 5 and non-call related events described in Section 6.
これらのタイプは、セクション5で説明イベント、セクション6に記載された非呼関連イベント関連を呼び出すために、それぞれ対応します。
The second mandatory attribute is a 'name' attribute. Values for this attribute MUST be limited to the SPIRITS mnemonics defined in Section 5.2.1, Section 5.2.2, and Section 6.1.
第二の必須属性は、「名前」属性です。この属性の値は、5.2.1項、5.2.2項、および6.1節で定義されているSPIRITSニーモニックに限定されなければなりません。
The third attribute, which is optional, is a 'mode' attribute. The value of 'mode' is either "N" or "R", corresponding respectively to (N)otification or (R)equest (RFC3298:Section 4). The default value of this attribute is "N".
オプションである第三の属性は、「モード」属性です。 'モード' の値（N）otification又は（R）equest（：第4 RFC3298）にそれぞれ対応し、 "N" または "R" のいずれかです。この属性のデフォルト値は「N」です。
If the 'type' attribute of the <Event> element is "INDPs", then it MUST contain at least one or more of the following elements (unknown elements MAY be ignored): <CallingPartyNumber>, <CalledPartyNumber>, <DialledDigits>, or <Cause>. These elements are defined in Section 5.2; they MUST not contain any attributes and MUST not be used further as parent elements. These elements contain a string value as described in Section 5.2.1 and 5.2.2.
<イベント>の「タイプ」属性は要素が「INDPs」であれば、それは（未知の要素は無視される）以下の要素の少なくとも一つ以上を含まなければなりません：<CallingPartyNumber>、<CalledPartyNumber>、<DialledDigits>、または<原因>。これらの要素は、セクション5.2で定義されています。彼らは、任意の属性を含んではならないと親要素としてさらに使用することはできません。 5.2.1と5.2.2で説明したように、これらの要素は、文字列値が含まれています。
If the 'type' attribute of the <Event> element is "userprof", then it MUST contain a <CalledPartyNumber> element and it MAY contain a <Cell-ID> element. None of these elements contain any attributes and neither must be used further as a parent element. These elements contain a string value as described in Section 6.1. All other elements MAY be ignored if not understood.
<イベント>の「タイプ」属性は要素が「userprof」であれば、それは、<CalledPartyNumber>要素を含まなければならないし、それが<セル-ID>要素を含むかもしれません。これらの要素のいずれも、属性が含まれていないし、どちらも親要素としてさらに使用する必要があります。 6.1節で説明したように、これらの要素は、文字列値が含まれています。理解されていない場合は他のすべての要素は無視されるかもしれません。
A SPIRITS-compliant XML document using the XML namespace defined in this document might look like the following example:
この文書で定義されたXML名前空間を使用してSPIRITS準拠のXML文書は、次の例のようになります。
<?xml version="1.0" encoding="UTF-8"?> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="INDPs" name="OD" mode="N"> <CallingPartyNumber>5551212</CallingPartyNumber> </Event> <Event type="INDPs" name="OAB" mode="N"> <CallingPartyNumber>5551212</CallingPartyNumber> </Event> </spirits-event>
<？xml version = "1.0" エンコード= "UTF-8"？> <霊イベントのxmlns = "壷：IETF：のparams：XML：NS：霊-1.0"> <イベントタイプ= "INDPs" 名前= "OD "モード=" N "> <CallingPartyNumber> 5551212 </ CallingPartyNumber> </イベント> <イベント・タイプ=" INDPs」NAME = "OAB" モード= "N"> <CallingPartyNumber> 5551212 </ CallingPartyNumber> </イベント> < /霊イベント>
For readers who may not be familiar with the service execution aspects of PSTN/IN, we provide a brief tutorial next. Interested readers are urged to consult [19] for a detailed treatment of this subject.
PSTN / INのサービス実行側面に精通していないことが読者のために、我々は次の簡単なチュートリアルを提供しています。興味のある読者は、この主題の詳細な治療のために[19]に相談するように付勢されています。
Services in the PSTN/IN are executed based on a call model. A call model is a finite state machine used in SSPs and other call processing elements that accurately and concisely reflects the current state of a call at any given point in time. Call models consist of states called PICs (Points In Call) and transitions between states. Inter-state transitions pass through elements called Detection Points or DPs. DPs house one or more triggers. Every trigger has a firing criteria associated with it. When a trigger is armed (made active), and its associated firing criteria are satisfied, it fires. The particulars of firing criteria may vary based on the call model being supported.
PSTN IN /におけるサービスは、コール・モデルに基づいて実行されます。コールモデルは、SSPを正確かつ簡潔時間内の任意の点でのコールの現在の状態を反映する他の呼処理要素に用いられる有限状態機械です。コールモデルは、状態が状態間（呼び出しでポイント）のPICやトランジションと呼ばれる構成されています。間の状態遷移は、検出点かのDPと呼ばれる要素を通過します。 DPの家1以上のトリガー。すべてのトリガーは、それに関連付けられた焼成条件を持っています。トリガが武装（アクティブに）され、そしてそれに関連する発火基準が満たされたとき、それが発火します。焼成条件の詳細は、コール・モデルがサポートされているに基づいて異なる場合があります。
When a trigger fires, a message is formatted with call state information and transmitted by the SSP to the SCP. The SCP then reads this call related data and generates a response which the SSP then uses in further call processing.
ときにトリガーが起動、メッセージがコール状態情報でフォーマットし、SCPにSSPによって送信されます。 SCPは、このコールに関連するデータを読み取り、SSPは、さらなるコール処理に使用する応答を生成します。
Detection Points are of two types: TDPs (or Trigger Detection Points), and EDPs (or Event Detection Points). TDPs are provisioned with statically armed triggers (armed through Service Management Tools). EDPs are dynamically armed triggers (armed by the SCP as call processing proceeds). DPs may also be classified as "Request" or "Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and EDP-N's.
TDPS（またはトリガ検出ポイント）、およびEDPS（またはイベント検出ポイント）：検出ポイントは2つのタイプがあります。 TDPSは静的武装トリガ（サービス管理ツールを通じて武装）でプロビジョニングされています。 EDPSは、動的に（呼処理が進むにつれてSCPによって武装）武装トリガです。 DPSがまた、「要求」または「通知」のDPとして分類することができます。このように、一つはTDP-Rの、TDP-Nさん、EDP-RのとEDP-Nさんを持つことができます。
The "-R" type of DPs require the SSP to suspend call processing when communication with the SCP is initiated. Call processing resumes when a response is received. The "-N" type of DPs enable the SSP to continue with call processing when the trigger fires, after it sends out the message to the SCP, notifying it that a certain event has occurred.
DPの「-R」タイプは、SCPとの通信が開始されたときに呼処理を中断するSSPが必要です。応答が受信されたときにコール処理が再開されます。 DPの「-N」タイプときトリガーが起動それは特定のイベントが発生したことを通知し、SCPにメッセージを送信した後、呼処理を継続するSSPを有効にします。
Call models typically support different types of detection points. Note that while INAP and the IN Capability Set (CS)-2 [7] call model are used in this document as examples, and for ease of explanation, other call models possess similar properties. For example, the Wireless Intelligent Network (WIN) call model also supports the dynamic arming of triggers. Thus, the essence of this discussion applies not just to the wireline domain, but applies equally well to the wireless domain as well.
コールモデルは、通常、検出ポイントの種類をサポートしています。 INAPとIN能力セット（CS）が-2 [7]コールモデルを例として、説明を簡単にするため、この文書で使用されている間、他の呼モデルは同様の特性を有することに留意されたいです。例えば、無線インテリジェントネットワーク（WIN）コールモデルは、トリガーのダイナミックなアーミングをサポートしています。したがって、この議論の本質は、単に有線ドメインにありません適用されますが、同様に無線ドメインにも同様に適用されます。
When the SCP receives the INAP formatted message from the SSP, if the SCP supports the SPIRITS architecture, it can encode the INAP message contents into a SPIRITS protocol message which is then transmitted to SPIRITS-capable elements in the IP network. Similarly, when it receives responses back from said SPIRITS capable elements, it can reformat the response content into the INAP format and forward these messages back to SSPs. Thus the process of inter-conversion and/or encoding between the INAP parameters and the SPIRITS protocol is of primary interest.
SCPは、SSPからINAPフォーマットされたメッセージを受信すると、SCPはSPIRITSアーキテクチャをサポートしている場合、それは、次に、IPネットワークにおけるSPIRITS可能な要素に伝達されるSPIRITSプロトコルメッセージにINAPメッセージの内容をコードすることができます。それはSPIRITS可能な要素が前記のバック応答を受信した場合同様に、それは、INAPフォーマットに応答コンテンツを再フォーマットとのSSPにこれらのメッセージをバック転送することができます。したがってINAPパラメータとSPIRITSプロトコル間の相互変換、および/または符号化のプロセスが主要な関心です。
An SCP is a physical manifestation of the Service Control Function. An SSP is a physical manifestation of the Service Switching Function (and the Call Control Function). To support uniformity of nomenclature between the various SPIRITS drafts, we shall use the terms SCP and SCF, and SSP and SSF interchangeably in this document.
SCPは、サービス制御機能の物理的な現れです。 SSPは、サービス交換機能（およびコール制御機能）の物理的な現れです。様々なSPIRITSドラフト間の命名法の均一性をサポートするために、我々は、この文書では交換可能用語SCPとSCF、およびSSPとSSFを使用しなければなりません。
Section 4 of [4] outlines the IN-related requirements on the SPIRITS protocol. The SUBSCRIBE request arriving at the SPIRITS notifier MUST contain the events to be monitored (in the form of a DP list), the mode (request or a notification, the difference being that for a request, the SPIRITS subscriber can influence subsequent call processing and for a notification, no further influence is needed), and any DP-related parameters.
[4]のセクション4はSPIRITSプロトコルにIN関連要件を概説します。スピリッツに到着SUBSCRIBEリクエストが通知差が要求に対して、SPIRITS加入者が後続の呼処理に影響を与えることができることである、（DPリストの形で）監視されるイベント、モード（要求や通知を含まなければなりませんと通知のため、更なる影響）が必要とされない、任意のDP関連パラメータ。
Section 4 of [4] also enumerates a list of Capability Set 3 (CS-3) DPs for SPIRITS services. It is a requirement (RFC3298:Section 4) that the SPIRITS protocol specify the relevant parameters of the DPs. These DPs and their relevant parameters to be carried in a SUBSCRIBE request are codified in an XML schema. All SPIRITS subscribers MUST understand this schema for subscribing to the DPs in the PSTN. The schema is defined in Section 9.
[4]のセクション4はSPIRITSサービスのための能力セット3（CS-3）のDPのリストを列挙します。 SPIRITSプロトコルのDPの関連するパラメータを指定すること：それは要件（セクション4 RFC3298）です。これらのDPとその関連パラメータは、XMLスキーマで体系化されているSUBSCRIBEリクエストで運ばれます。すべてのSPIRITS加入者は、PSTNでのDPに加入するために、このスキーマを理解する必要があります。スキーマは、セクション9で定義されています。
When a DP fires, a notification -- using a SIP NOTIFY request -- is transmitted from the SPIRITS notifier to the SPIRITS subscriber. The NOTIFY request contains an XML document which describes the DP that fired and any relevant parameters. The DPs and their relevant parameters to be carried in a NOTIFY request are codified in an XML schema. All SPIRITS notifiers MUST understand this schema; this schema MAY be extended. The schema is defined in Section 9.
DP火災、通知とき - SIPを使用して要求をNOTIFY - SPIRITSから通知SPIRITS加入者に送信されます。 NOTIFYリクエストは解雇DPとの関連パラメータを記述したXMLドキュメントが含まれています。 DPとその関連パラメータは、XMLスキーマで体系化されてNOTIFYリクエストで運ばれます。すべてのSPIRITS通知者は、このスキーマを理解する必要があります。このスキーマは、延長することができます。スキーマは、セクション9で定義されています。
In addition, Appendices A and B of [6] contain a select subset of CS-2 DPs that may be of interest to the reader. However, this document will only refer to CS-3 DPs outlined in [4].
また、[6]の付録AおよびBは、読者に興味があるかもしれCS-2のDPの選択サブセットを含みます。しかし、この文書は、[4]に概説さCS-3のDPを参照します。
The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4) are described next. IN DPs are characterized by many parameters, however, not all such parameters are required -- or even needed -- by SPIRITS. This section, thus, serves to list the mandatory parameters for each DP that MUST be specified in subscriptions and notifications. Implementations can specify additional parameters as XML extensions associated with a private (or public and standardized) namespace.
次に説明されています（第4 RFC3298）ではCS-3のDPはSPIRITSサービスのために想定されます。あるいは必要に応じて - - SPIRITSでのDP INしかし、すべてではないようなパラメータが必要とされ、多くのパラメータによって特徴付けられます。このセクションでは、このようにして、サブスクリプションおよび通知で指定する必要があり、各DPの必須パラメータを一覧表示するのに役立ちます。実装はプライベート（またはパブリックおよび標準化された）名前空間に関連付けられているXMLの拡張機能として追加のパラメータを指定することができます。
The exhaustive list of IN CS-3 DPs and their parameters can be found in reference [13].
IN CS-3のDP及びそのパラメータの完全なリストは、参考文献[13]に見出すことができます。
Each DP is given a SPIRITS-specific mnemonic for use in the subscriptions and notifications.
各DPは、サブスクリプションと通知で使用するためSPIRITS特有のニーモニックを与えています。
Origination Attempt Authorized SPIRITS mnemonic: OAA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
ニーモニック発信試み認定SPIRITS：SUBSCRIBEでOAA必須パラメータ：NOTIFYでCallingPartyNumber必須パラメータ：CallingPartyNumber、CalledPartyNumber
CallingPartyNumber: A string used to identify the calling party for the call. The actual length and encoding of this parameter depend on the particulars of the dialing plan used.
CallingPartyNumber：通話のための発信者を特定するために使用される文字列。このパラメータの実際の長さと符号が使用ダイヤルプランの詳細に依存します。
CalledPartyNumber: A string containing the number (e.g., called directory number) used to identify the called party. The actual length and encoding of this parameter depend on the particulars of the dialing plan used.
CalledPartyNumber：番号を含む文字列（例えば、電話番号と呼ばれる）被呼者を識別するために使用されます。このパラメータの実際の長さと符号が使用ダイヤルプランの詳細に依存します。
Collected Information SPIRITS mnemonic: OCI Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
ニーモニック収集情報SPIRITS：SUBSCRIBEでOCI必須パラメータ：NOTIFYでCallingPartyNumber必須パラメータ：CallingPartyNumber、DialledDigits
DialledDigits: This parameter contains non-translated address information collected/received from the originating user/line/trunk
DialledDigits：このパラメータは非変換アドレス情報収集/発信ユーザ/ライン/トランクから受信含まれてい
Analyzed Information SPIRITS mnemonic: OAI Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
ニーモニック分析された情報のSPIRITS：SUBSCRIBEでOAI必須パラメータ：NOTIFYでCallingPartyNumber必須パラメータ：CallingPartyNumber、DialledDigits
Origination Answer SPIRITS mnemonic: OA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
ニーモニック発信回答SPIRITS：SUBSCRIBEでOA必須パラメータ：NOTIFYでCallingPartyNumber必須パラメータ：CallingPartyNumber、CalledPartyNumber
Origination Term Seized SPIRITS mnemonic: OTS Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
NOTIFYにCallingPartyNumber必須パラメータ：SUBSCRIBEでOTS必須パラメータ：オリジネーション用語は、ニーモニックSPIRITSを押収CallingPartyNumber、CalledPartyNumberを
Origination No Answer SPIRITS mnemonic: ONA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
NOTIFYでCallingPartyNumber必須パラメータ：オリジSPIRITSニーモニック無回答：SUBSCRIBEでONA必須パラメータをCallingPartyNumber、CalledPartyNumber
Origination Called Party Busy SPIRITS mnemonic: OCPB Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
ニーモニック発信着信側忙しいSPIRITS：SUBSCRIBEでOCPB必須パラメータ：NOTIFYでCallingPartyNumber必須パラメータ：CallingPartyNumber、CalledPartyNumber
Route Select Failure SPIRITS mnemonic: ORSF Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
ニーモニックルート選択の失敗SPIRITS：SUBSCRIBEでORSF必須パラメータ：CallingPartyNumber必須パラメータNOTIFYで：CallingPartyNumber、CalledPartyNumber
Origination Mid Call SPIRITS mnemonic: OMC Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
オリジネーションミッドコールSPIRITSニーモニック：SUBSCRIBEでOMC必須パラメータ：CallingPartyNumber必須パラメータNOTIFYで：CallingPartyNumber
Origination Abandon SPIRITS mnemonic: OAB
オリジネーション放棄SPIRITSニーモニック：OAB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
SUBSCRIBEで必須のパラメータ：CallingPartyNumber必須パラメータNOTIFYで：CallingPartyNumber
Origination Disconnect SPIRITS mnemonic: OD Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
ニーモニック発信切断SPIRITS：SUBSCRIBEでOD必須パラメータ：NOTIFYでCallingPartyNumber必須パラメータ：CallingPartyNumber、CalledPartyNumber
Termination Answer SPIRITS mnemonic: TA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
ニーモニック終了回答SPIRITS：SUBSCRIBEにおけるTA必須パラメータ：NOTIFYでCalledPartyNumber必須パラメータ：CallingPartyNumber、CalledPartyNumber
Termination No Answer SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
終了SPIRITSニーモニック無回答：SUBSCRIBEでTNA必須パラメータ：NOTIFYでCalledPartyNumber必須パラメータ：CallingPartyNumber、CalledPartyNumberを
Termination Mid-Call SPIRITS mnemonic: TMC Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
NOTIFYでCalledPartyNumber必須パラメータ：終了ニーモニック通話中SPIRITS：SUBSCRIBEでTMC必須パラメータCalledPartyNumber
Termination Abandon SPIRITS mnemonic: TAB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
NOTIFYにCalledPartyNumber必須パラメータ：SUBSCRIBEでTAB必須パラメータ：終了は、ニーモニックSPIRITSを放棄CalledPartyNumberを
Termination Disconnect SPIRITS mnemonic: TD Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
ニーモニック終了切断SPIRITS：SUBSCRIBEにおけるTD必須パラメータ：NOTIFYでCalledPartyNumber必須パラメータ：CalledPartyNumber、CallingPartyNumber
Termination Attempt Authorized SPIRITS mnemonic: TAA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
終了試行認可SPIRITSニーモニック：SUBSCRIBEでTAA必須パラメータ：NOTIFYでCalledPartyNumber必須パラメータ：CalledPartyNumber、CallingPartyNumber
Termination Facility Selected and Available SPIRITS mnemonic: TFSA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
SUBSCRIBEでTFSA必須パラメータ：CalledPartyNumber必須パラメータNOTIFYに：SPIRITSニーモニック選択し、利用可能な終端施設CalledPartyNumber
Termination Busy SPIRITS mnemonic: TB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber, Cause
ニーモニック終了ビジーSPIRITS：SUBSCRIBEでTB必須パラメータ：NOTIFYでCalledPartyNumber必須パラメータ：CalledPartyNumber、CallingPartyNumber、原因
Cause: This parameter contains a string value of either "Busy" or "Unreachable". The difference between these is translated as a requirement (RFC3298:Section 5) to aid in the SPIRITS subscriber in determining if the called party is indeed busy (engaged), or if the called party is unavailable (as it would be if it were on the cellular PSTN and the mobile subscriber was not registered with the network).
原因：このパラメータは、「ビジー」または「到達不能」のいずれかの文字列値が含まれています。着信側が実際に（係合）ビジー状態の場合、またはそれが上だったら、それはなように、着信側が（利用できないかどうかを判断するにはSPIRITS加入者を支援するためにこれらの違いは、要件（第5節RFC3298）として翻訳されますセルラPSTN、モバイル加入者）は、ネットワークに登録されていませんでした。
Triggers in the PSTN can be armed dynamically, often outside the context of a call. The SIP event notification mechanism [3] is, therefore, a convenient means to exploit in those cases where triggers housed in EDPs fire (see section 3 of [4]). Note that [4] uses the term "persistent" to refer to call-related DP arming and associated interactions.
PSTNでのトリガは、多くの場合、呼び出しのコンテキスト外で、動的に武装することができます。 SIPイベント通知機構[3]（[4]のセクション3を参照）、したがって、EDPS火災に収容されたトリガな場合に利用するのに便利な手段です。 [4] DPのアーミングおよび関連する相互作用関係を呼び出すために参照するために「永続的」という用語を使用することに注意してください。
The SIP Events Package enables IP endpoints (or hosts) to subscribe to and receive subsequent notification of events occurring in the PSTN. With reference to Figure 2, this includes communication on the interfaces marked "B" and "C".
SIPイベントパッケージに加入し、PSTNで発生するイベントの次の通知を受信するIPエンドポイント（またはホスト）を可能にします。図2を参照して、これはインターフェイス上の通信は、「B」および「C」とマーク含みます。
A subscriber will issue a SUBSCRIBE request which identifies a set of events (DPs) it is interested in getting the notification of. This set MUST contain at least one DP, it MAY contain more than one. The SUBSCRIBE request is routed to the notifier, where it is accepted, pending a successful authentication.
加入者は、通知を得ることに興味を持っているイベント（DPS）のセットを識別するSUBSCRIBEリクエストを発行します。このセットは、少なくとも一つのDPを含まなければならない、それ以上のものを含むかもしれません。 SUBSCRIBEリクエストは成功した認証を保留し、それが受け入れられた通知にルーティングされます。
When any of the DPs identified in the set of events fires, the notifier will format a NOTIFY request and direct it towards the subscriber. The NOTIFY request will contain information pertinent to the event that was triggered. The un-encountered DPs MUST be subsequently dis-armed by the SPIRITS notifier and/or the SCF.
DPのいずれかのイベント火災のセットで特定された場合、通知は、NOTIFYリクエストをフォーマットし、加入者の方にそれを指示します。 NOTIFYリクエストがトリガされたイベントに関連する情報が含まれています。未遭遇DPSが、その後通知SPIRITSおよび/またはSCFによって武装DISなければなりません。
The dialog established by the SUBSCRIBE terminates when the event of interest occurs and this notification is passed to the subscriber through a NOTIFY request. If the subscriber is interested in the future occurrence of the same event, it MUST issue a new SUBSCRIBE request, establishing a new dialog.
興味のあるイベントが発生すると、この通知は、NOTIFYリクエストを通じて加入者に渡されたときに、SUBSCRIBEによって確立されたダイアログが終了します。加入者が同じイベントの将来の発生に興味があるならば、それは新しいダイアログを確立し、新しいSUBSCRIBEリクエストを発行しなければなりません。
When the subscriber receives a NOTIFY request, it can subsequently choose to act in a manner appropriate to the notification.
加入者がNOTIFYリクエストを受信すると、その後通知に適切な方法で行動することを選択できます。
The remaining sections fill in the specific package responsibilities raised in RFC3265 [3], Section 4.4.
残りのセクションはRFC3265 [3]は、セクション4.4に上昇させ、特定のパッケージの責任を埋めます。
This document defines two event packages; the first of these is defined in this section and is called "spirits-INDPs". This package MUST be used for events corresponding to IN detection points in the cellular or wireline PSTN. All entities that implement the SPIRITS protocol and support IN detection points MUST set the "Event" request header [3] to "spirits-INDPs." The "Allow-Events" general header [3] MUST include the token "spirits-INDPs" if the entity implements the SPIRITS protocol and supports IN detection points.
この文書では、2つのイベントパッケージを定義します。これらの最初は、このセクションで定義され、「霊-INDPs」と呼ばれています。このパッケージは、細胞または有線PSTNにIN検出点に対応するイベントに使用されなければなりません。検出点でSPIRITSプロトコル及びサポートを実装するすべてのエンティティは、[3]に「霊-INDPs。」「イベント」要求ヘッダを設定しなければなりませんエンティティはSPIRITSプロトコルを実装し、検出点でサポートしている場合、「許可・イベント」の一般的なヘッダは、[3]トークン「スピリッツ-INDPs」を含まなければなりません。
Event: spirits-INDPs Allow-Events: spirits-INDPs
イベント：霊-INDPsを許可 - イベント：霊-INDPs
The second event package is defined and discussed in Section 6.
第2のイベントパッケージを定義し、セクション6で説明されています。
The "spirits-INDPs" event package does not support any additional parameters to the Event header.
「霊-INDPs」イベントパッケージはEventヘッダーへの追加パラメータをサポートしていません。
SUBSCRIBE requests that serve to terminate the subscription MAY contain an empty body; however, SUBSCRIBE requests that establish a dialog MUST contain a body which encodes three pieces of information:
空のボディを含むかもしれサブスクリプションを終了するのに役立つSUBSCRIBE要求。しかし、3つの情報をコード化体を含まなければならないダイアログを確立SUBSCRIBEリクエスト：
(1) The set of events (DPs) that is being subscribed to. A subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request, or MAY issue a different SUBSCRIBE request for each DP it is interested in receiving a notification for. The protocol allows for both forms of representation, however, it recommends the former manner of subscribing to DPs if the service depends on any of the DPs being triggered.
（1）に加入されているイベント（DPS）のセット。加入者は1 SUBSCRIBEリクエストをして、複数のDPに加入することができる、またはそれはのための通知を受信することに関心がある各DPに異なるSUBSCRIBEリクエストを発行することができます。プロトコルは、しかし、それはサービスがトリガされるのDPのいずれかに依存している場合のDPに加入の前者の方法を推奨し、表現の両方の形態を可能にします。
(2) Because of the requirement [4] that IN be informed whether the detection point is set as the request or notification, all events in the "spirits-INDPs" package (but not in the "spirits-user-prof" package) are required to provide a "mode" parameter, whose values are "R" (for Request) and "N" for notification.
（2）そのための要件[4]という点では、（「スピリッツユーザ-PROF」パッケージではなく）検出点を要求または通知として設定されているか、「スピリッツ-INDPs」パッケージ内のすべてのイベントを通知されますその値である「R」（要求用）「モード」パラメータ、および通知のための「N」を提供するために必要とされます。
(3) A list of the values of the parameters associated with the event detection point (Note: the term "event" here refers to the IN usage -- a dynamically armed DP is called an Event Detection Point). Please see Section 5.2.1 and Section 5.2.2 for a list of parameters associated with each DP.
（3）イベント検出ポイントに関連するパラメータの値のリストを（注：ここで用語「イベント」は、INの使用を意味する - 動的武装DPは、イベント検出ポイントと呼ばれます）。各DPに関連するパラメータのリストについては、5.2.1項および5.2.2項を参照してください。
The default body type for SUBSCRIBEs in SPIRITS is denoted by the MIME type "application/spirits-event+xml". The "Accept" header, if present, MUST include this MIME type.
SPIRITSで加入するためのデフォルトのボディタイプは、MIMEタイプ「アプリケーション/霊イベント+ xmlの」によって示されます。 「同意」ヘッダは、存在する場合、このMIMEタイプを含まなければなりません。
For package "spirits-INDPs", the purpose of the SUBSCRIBE request is to arm the DP, since as far as IN is concerned, being armed is the first essential pre-requisite. A DP maybe armed either statically (for instance, through service provisioning), or dynamically (by the SCF). A statically armed DP remains armed until it is disarmed proactively. A dynamically armed DP remains armed for the duration of a call (or more appropriately, no longer than the duration of a particular SSF-SCF relationship).
パッケージ「霊-INDPs」の場合は、SUBSCRIBEリクエストの目的は、限りINが懸念しているとして、武装されて以来、DPを武装させるである第一の必須の前提条件です。 （SCFによって）静的（例えば、サービスプロビジョニングを介して）、または動的DP多分武装。それは積極的に武装解除されるまで静的に武装DPは武装したまま。動的武装DPは、呼の持続時間武装（又はより適切に、もはや特定のSSF-SCF関係の持続時間より）されたままです。
Dynamically armed DPs are automatically disarmed when the event of interest occurs in the notifier. It is up to the subscriber to re-arm the DPs within the context of a call, if it so desires.
興味のあるイベントが通知で発生したときに動的に武装DPSが自動的に武装解除されます。それによって、もし望むのであれば、呼び出しのコンテキスト内でのDPを再武装させるの加入者に任されています。
Statically armed DPs are considered outside the scope of the SPIRITS protocol requirements [4] and thus will not be considered any further.
静的武装のDPはSPIRITSプロトコル要件の範囲外であると考えられる[4]したがって、さらなる考慮されないであろう。
Bodies in NOTIFY requests for the "spirits-INDPs" package are optional. If present, they MUST be of the MIME type "application/spirits-event+xml". The body in a NOTIFY request encapsulates the following pieces of information which can be used by the subscriber:
「霊-INDPs」パッケージのNOTIFYリクエストを内ボディはオプションです。存在する場合、それらは、MIMEタイプ「アプリケーション/霊イベント+ xml」である必要があります。 NOTIFYリクエストボディは、加入者が使用することができる以下の情報をカプセル化します。
(1) The event that resulted in the NOTIFY being generated (typically, but not always, this will be the same event present in the corresponding SUBSCRIBE request).
（1）をもたらしたイベントNOTIFY生成される（典型的には、常にではないが、これは対応で同じイベントの存在は、SUBSCRIBEリクエストをあろう）。
(2) The "mode" parameter; it is simply reflected back from the corresponding SUBSCRIBE request.
（2）「モード」パラメータを、単にバック対応するSUBSCRIBEリクエストから反射されます。
(3) A list of values of the parameters associated with the event that the NOTIFY is being generated for. Depending on the actual event, the list of the parameters will vary.
（3）NOTIFYイベントに関連付けられているパラメータの値のリストをするために生成されています。実際のイベントに応じて、パラメータのリストが異なります。
If the subscriber armed multiple DPs as part of a single SUBSCRIBE request, all the un-encountered DPs that were part of the same SUBSCRIBE dialog MUST be dis-armed by the SPIRITS notifier and/or the SCF/SCP.
加入者が単一のSUBSCRIBEリクエストの一部として複数のDP武装した場合、すべての未遭遇のDP通知SPIRITSによってDIS-武装しなければならない同じSUBSCRIBEダイアログの一部であった、および/またはSCF / SCPこと。
When the notifier receives a SUBSCRIBE request, it MUST authenticate the request and ensure that the subscriber is authorized to access the resource being subscribed to, in this case, PSTN/IN events on a certain PSTN line.
通知は、SUBSCRIBEリクエストを受信すると、要求を認証し、加入者が、この場合には、PSTN /特定のPSTN回線上のイベントでは、サブスクライブされたリソースへのアクセスを許可されていることを確認しなければなりません。
Once the SUBSCRIBE request has been authenticated and authorized, the notifier interfaces with the SCF over interface D to arm the detection points corresponding to the PSTN line contained in the SUBSCRIBE body. The particulars about interface D is out of scope for this document; here we will simply assume that the notifier can affect the arming (and disarming) of triggers in the PSTN through interface D.
SUBSCRIBEリクエストが認証および承認された後、インターフェースD上SCFと通知インタフェースはSUBSCRIBEボディーに含まPSTNラインに対応する検出点をアームに。インターフェースDについての詳細はこの文書の範囲外です。ここでは単にインターフェースD.を通じてPSTNでのトリガの通知がアーミングに影響を与える（と武装解除）できることを前提としています
If the notifier expects the arming of triggers to take more than 200 ms, it MUST send a 202 response to the SUBSCRIBE request immediately, accepting the subscription. It should then send a NOTIFY request with an empty body. This NOTIFY request MUST have a "Subscription-State" header with a value of "pending".
通知がトリガのアーミングが200ミリ秒以上を取ることを期待する場合は、サブスクリプションを受け入れ、すぐにSUBSCRIBE要求に202応答を送らなければなりません。その後、空のボディを持つNOTIFYリクエストを送信する必要があります。このNOTIFYリクエストは、「保留」の値を持つ「サブスクリプション・ステート」ヘッダを持たなければなりません。
This immediate NOTIFY with an empty body is needed since the
resource identified in the SUBSCRIBE request does not have as
yet a meaningful state.
Once the notifier has successfully interfaced with the SCF, it MUST send a subsequent NOTIFY request with an empty body and a "Subscription-State" header with a value of "active."
通知が正常SCFとインタフェースしたら、それは空の本体との値が「サブスクリプション状態」ヘッダを持つ後続のNOTIFYリクエスト送信しなければならない「アクティブ」を
When the event of interest identified in the SUBSCRIBE request occurs, the notifier sends out a new NOTIFY request which MUST contain a body (see Section 5.3.6). The NOTIFY request MUST have a "Subscription-State" header and its value MUST be set to "terminated" with a reason parameter of "fired".
SUBSCRIBEリクエストで特定され、関心のイベントが発生すると、通知は、体を（5.3.6項を参照）を含まなければならない新しいNOTIFYリクエストを送信します。 NOTIFYリクエストは、「サブスクリプション・ステート」ヘッダを持たなければならないし、その値が「発射」の理由パラメータで「終了」するために設定しなければなりません。
The exact steps executed at the subscriber when it gets a NOTIFY request will depend on the service being implemented. As a generality, the UA associated with the subscriber should somehow impart this information to the user by visual or auditory means, if at all possible.
それはNOTIFYリクエストを受け取る際に、加入者で実行される正確な手順が実装されているサービスに依存します。可能であれば一般性として、加入者に関連付けられたUAは何とか、視覚的または聴覚的手段によってユーザにこの情報を与えるべきです。
If the NOTIFY request contained a "Subscription-State" header with a value of "terminated" and a reason parameter of "fired", the UA associated with the subscriber MAY initiate a new subscription for the event that was just reported through the NOTIFY request.
NOTIFYリクエストは、「終了」の値を持つ「サブスクリプション・ステート」ヘッダーと「解雇」の理由パラメータが含まれていた場合、加入者に関連したUAはちょうどNOTIFYリクエストによって報告されたイベントのための新しいサブスクリプションを開始することができます。
Whether or not to initiate a new subscription when an existing
one expires is up to the context of the service that is being
implemented. For instance, a user may configure her UA to
always re-subscribe to the same event when it fires, but this
is not necessarily the normative case.
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE request is targeted towards the PSTN, highly irregular behaviors occur if the request is allowed to fork. The normal SIP DNS lookup and routing rules [11] should result in a target set with exactly one element: the notifier.
SUBSCRIBEリクエストのフォークは禁止されています。 SUBSCRIBEリクエストがPSTNを対象としているので、要求がフォークに許可されている場合、高度に不規則な挙動が発生します。通知：通常のSIPのDNSルックアップおよびルーティング規則[11]は正確に一つの要素に設定された目標をもたらすはずです。
For reasons of security more than network traffic, it is RECOMMENDED that the notifier issue two or, at most three NOTIFY requests for a subscription. If the subscription was accepted with a 202 response, a NOTIFY will be sent immediately towards the subscriber. This NOTIFY serves to inform the subscriber that the request has been accepted and is being acted on.
ネットワークトラフィックよりもセキュリティ上の理由から、通知の問題2または、高々3は、サブスクリプションの要求を通知することを推奨されますサブスクリプションが202応答で受け入れられた場合、NOTIFYは加入者の方にすぐに送信されます。これは、NOTIFYリクエストを受け付けたとが作用している加入者に通知するのに役立ちます。
Once the resource (detection points) identified in the SUBSCRIBE request have been initialized, the notifier MUST send a second NOTIFY request. This request contains the base state of the resource.
SUBSCRIBEリクエストで識別されたリソース（検出点）が初期化されたら、通知は、第二のNOTIFY要求を送信しなければなりません。この要求は、リソースの基本状態が含まれています。
When an event of interest occurs which leads to the firing of the trigger associated with the detection points identified in the SUBSCRIBE request, a final NOTIFY is sent to the subscriber. This NOTIFY request contains more information about the event of interest.
関心のあるイベントがSUBSCRIBE要求で識別された検出点に関連付けられたトリガの発火につながる発生した場合、最終的には、加入者に送信されるNOTIFY。これは、リクエストが対象のイベントに関する詳細な情報が含まれていNOTIFY。
If the subscription was accepted with a 200 response, the notifier simply sends two NOTIFY requests: one containing the base state of the resource, and the other containing information that lead to the firing of the detection point.
リソースの基底状態を含むもの、及び他の情報を含む検出点の発火につながる：サブスクリプションが200応答で受け入れられた場合は、通知は、単に2はNOTIFYリクエストを送信します。
State agents are not used in SPIRITS.
状態エージェントはSPIRITSで使用されていません。
This section contains example call flows for a SPIRITS service called Internet Caller-ID Delivery (ICID). One of the benchmark SPIRITS service, as described in section 2.2 of [1] is Internet Caller-ID delivery:
このセクションでは、例の呼び出しがインターネット発信者ID配達（ICID）と呼ばれるSPIRITSサービスのフローが含まれています。 [1]のセクション2.2に記載されているようにベンチマークSPIRITSサービスの一つは、インターネット発信者ID送達です。
This service allows the subscriber to see the caller's number or name or both while being connected to the Internet. If the subscriber has only one telephone line and is using the very line for the Internet connection, the service is a subset of the ICW service and follows the relevant description in Section 2.1. Otherwise, the subscriber's IP host serves as an auxiliary device of the telephone to which the call is first sent.
このサービスは、加入者がインターネットに接続された状態で、発信者の番号や名前、またはその両方を見ることができます。加入者が一つだけの電話回線を持っており、インターネット接続のための非常にラインを使用している場合、サービスはICWサービスのサブセットであり、2.1節で関連の記述に従っています。そうでない場合は、加入者のIPホストは、コールが最初に送信された電話の補助装置として機能します。
We present an example of a SPIRITS call flow to realize this service. Note that this is an example only, not a normative description of the Internet Caller-ID service.
私たちは、このサービスを実現するために、フローを呼び出しSPIRITSの例を提示します。これはインターネット発信者IDサービスの規範的な記述例だけではないことに注意してください。
Further text and details of SIP messages below refer to the call flow provided in Figure 3. Figure 3 depicts the 4 entities that are an integral part of any SPIRITS service (the headings of the entities refer to the names established in Figure 1 in [1]) -- the SPIRITS subscriber, the SPIRITS notifier and the SCF. Note that the SPIRITS gateway is not included in this figure; logically, SPIRITS messages flow between the SPIRITS server and the SPIRITS client. A gateway, if present, may act as a proxy.
さらに、テキストおよびSIPメッセージの詳細は以下の図において提供される呼の流れを参照。図3は、任意のSPIRITSサービス（エンティティの見出し[1の図1で確立名を参照の不可欠な一部である4つのエンティティを示しています]） - SPIRITS加入、通知スピリッツ、SCF。 SPIRITSゲートウェイは、この図には含まれていないことに注意してください。論理的に、SPIRITSメッセージがSPIRITSサーバとSPIRITSクライアントの間を流れます。ゲートウェイは、存在する場合、プロキシとして動作してもよいです。
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Arm DP |
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 3: Sample call flow
図3：サンプルコールフロー
This call flow depicts an overall operation of a "subscriber" successfully subscribing to the IN Termination_Attempt_Authorized DP (the "subscriber" is assumed to be a user, possibly at work, who is interested in knowing when he/she gets a phone call to his/her home phone number) -- this interaction is captured in messages F1 through F8 in Figure 3. The user sends (F1) a SIP SUBSCRIBE request identifying the DP it is interested in along with zero or more parameters relevant to that DP (in this example, the Termination_Attempt_DP will be employed). The SPIRITS notifier in turns interacts with the SCF to arm the Termination_Attempt_DP for the service (F2). An immediate NOTIFY with the current state information is send to the subscriber (F4, F5).
このコールフローが成功し、彼/彼女は彼に電話を取得するときに知ることに興味を持っている、IN Termination_Attempt_Authorized DP（「加入者が」おそらく仕事で、利用者を想定している、に加入する「加入者」の全体的な動作を示しています/彼女の家の電話番号） - この相互作用は、（図3.ユーザが送信する（F1）SIPは、それに沿ってそのDPに関連するゼロ又はそれ以上のパラメータを持つことに興味がありDPを識別SUBSCRIBEリクエストでF8を介してメッセージF1に捕捉されますこの例では、Termination_Attempt_DP）が使用されるであろう。通知ターンにおけるSPIRITSサービス（F2）のためTermination_Attempt_DPアームためにSCFと相互作用します。当面は、加入者（F4、F5）に送信された現在の状態情報を通知します。
At some point after the above sequence of events has transpired, the PSTN gets a call to the users phone. The SSF informs the SCF of this event when it encounters an armed Termination_Attempt_DP (not shown in Figure 3). The SCF informs the SPIRITS notifier of this event (F6).
イベントの上記のシーケンスが蒸散した後のある時点で、PSTNは、ユーザーの携帯電話へのコールを取得します。それは武装Termination_Attempt_DP（図3には図示せず）に遭遇したときSSFは、このイベントのSCFに通知します。 SCFは、このイベント（F6）のSPIRITS通知を通知します。
When the SPIRITS notifier receives this event, it forms a SIP NOTIFY request and directs it to the SPIRITS subscriber (F7). This NOTIFY will contain all the information elements necessary to identify the caller to the subscriber. The subscriber, upon receiving the notification (F8) may pop open a window with the date/time and the number of the caller.
霊が通知このイベントを受信すると、SIPのNOTIFY要求を形成し、SPIRITS加入者（F7）に導きます。これは、加入者に発信者を特定するために必要なすべての情報要素が含まれていますNOTIFY。通知（F8）を受信すると、加入者は、日付/時刻および発呼者の番号で開いているウィンドウを開くことができます。
The rest of this section contains the details of the SIP messages in Figure 3. The call flow details below assume that the SPIRITS gateway is, for the purpose of this example, a SIP proxy that serves as the default outbound proxy for the notifier and an ingress host of the myprovider.com domain for the subscriber. The subscriber and notifier may be in separate administrative domains.
このセクションの残りの部分は、仮定図3以下コールフローの詳細でSIPメッセージの詳細が含まれてSPIRITSゲートウェイであり、この例の目的のために、デフォルトのアウトバウンド通知のためのプロキシとして機能するSIPプロキシ加入者のためのmyprovider.comドメインの進入ホスト。加入と通知は、別の管理ドメインであってもよいです。
F1: S->N
F1：S> N
SUBSCRIBE sip:myprovider.com SIP/2.0 From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com> CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds Expires: 3600 Event: spirits-INDPs Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
SIP SUBSCRIBE：myprovider.comをSIP / 2.0 <SIP：vkg@example.com>;タグ= 8177-AFD-991に<SIP：16302240216@myprovider.com>のCSeq：18992 SUBSCRIBEコールIDをホスト@ 3329as77を.example.comと連絡先：<SIP：vkg@host.example.com>ビア：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bK776asdhdsが有効期限：3600イベント：霊-INDPs許可 - イベント：霊-INDPs、霊-user-教授は受け入れ：アプリケーション/霊-イベント+ xmlのコンテンツタイプ：アプリケーション/霊イベント+ XMLコンテンツ-長さ：...
<?xml version="1.0" encoding="UTF-8"?> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="INDPs" name="TAA" mode="N"> <CalledPartyNumber>6302240216</CalledPartyNumber> </Event> </spirits-event>
<？xml version = "1.0" エンコード= "UTF-8"？> <霊イベントのxmlns = "壷：IETF：のparams：XML：NS：霊-1.0"> <イベントタイプ= "INDPs" 名前= "TAA "モード=" N "> <CalledPartyNumber> 6302240216 </ CalledPartyNumber> </イベント> </霊イベント>
The subscriber forms a SIP SUBSCRIBE request which identifies the DP that it wants to subscribe to (in this case, the TAA DP) and the actual line it wants that DP armed for (in this case, the line associated with the phone number 6302240216). This request eventually arrives at the SIPRITS notifier, N, which authenticates it (not shown) and sends a successful response to the subscriber:
加入者はそれを購読したいDPを識別するSIP SUBSCRIBEリクエストを形成し、それはDPがために武装することを望んでいる実際のライン（この場合、電話番号6302240216に関連付けられた行）（この場合、TAA DPで） 。この要求は最終的にそれを認証する（図示せず）と、加入者に成功した応答を送信するSIPRITS通知、N、到着します：
F3: N->S
F3：N-> S
SIP/2.0 200 OK From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds Expires: 3600 Accept: application/spirits-event+xml Content-Length: 0
SIP / 2.0 200 OKから<SIP：vkg@example.com>;タグ= 8177-AFD-991に<SIP：16302240216@myprovider.com>;タグ=スピリッツ-TAA-6302240216のCSeq：18992 SUBSCRIBEコールID ：3329as77@host.example.com連絡先：<SIP：notifier.myprovider.com>ビア：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bK776asdhds有効期限：3600は、受け入れ：アプリケーション/霊イベント+ XMLコンテンツ長：0
The notifier interacts with the SCF to arm the DP and also sends an immediate NOTIFY towards the subscriber informing the subscriber of the current state of the notification:
通知は、DPアームためにSCFと相互作用しても、即時に送信する通知の現在の状態を加入者に通知する加入者に向けて通知します：
F4: N->S
F4：N-> S
NOTIFY sip:vkg@host.example.com SIP/2.0 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 To: <sip:vkg@example.com>;tag=8177-afd-991 Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9 Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Subscription-State: active CSeq: 3299 NOTIFY Accept: application/spirits-event+xml Content-Length: 0
vkg@host.example.com SIP / 2.0：SIPのNOTIFY <SIP：16302240216@myprovider.com>;タグ=スピリッツ-TAA-6302240216に<SIP：vkg@example.com>;タグ= 8177、afd- 991経由：SIP / 2.0 / UDP gateway.myprovider.com;ブランチ= z9hG4bK-9 $ 0-1経由：SIP / 2.0 / UDP notifier.myprovider.com;ブランチ= z9hG4bKqo - 9コールID：3329as77@host.example .COM連絡先：<SIP：notifier.myprovider.com>サブスクリ - 状態：アクティブのCSeq：アプリケーション/霊-イベント+ xmlのコンテンツの長さを：：3299を受け入れるNOTIFY 0
F5: S->N
F5：S-> N
SIP/2.0 200 OK From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 To: <sip:vkg@example.com>;tag=8177-afd-991 Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9 Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> CSeq: 3299 NOTIFY Accept: application/spirits-event+xml Content-Length: 0
SIP / 2.0 200 OKから<SIP：16302240216@myprovider.com>;タグ=スピリッツ-TAA-6302240216に<SIP：vkg@example.com>;タグ= 8177-AFD-991のVia：SIP / 2.0 / UDP gateway.myprovider.com;ブランチ= z9hG4bK-9 $ 0-1経由：SIP / 2.0 / UDP notifier.myprovider.com;ブランチ= z9hG4bKqo - 9コールID：3329as77@host.example.com連絡先：<SIP：VKG @ host.example.com>のCSeq：アプリケーション/霊イベント+ XMLコンテンツ-長さ：：3299を受け入れるNOTIFY 0
At some later point in time (before the subscription established in F1 expires at the notifier), a call arrives at the number identified in XML-encoded body of F1 -- 6302240216. The SCF notifies the notifier (F6). Included in this notification is the relevant information from the PSTN, namely, the phone number of the party attempting to call 6302240216. The notifier uses this information to create a SIP NOTIFY request and sends it to the subscriber. The SIP NOTIFY request has a XML-encoded body with the relevant information from the PSTN:
SCFは、通知（F6）を通知6302240216. - （F1で確立サブスクリプションが通知で期限切れになる前に）時間的にいくつかの後の時点で、コールはF1のXMLエンコード体で同定された数に到達します。この通知に含まれる、すなわち、6302240216.を呼び出そうとパーティの電話番号が通知NOTIFYリクエストをSIPを作成するには、この情報を使用し、加入者に送信し、PSTNからの関連情報です。 SIPリクエストは、PSTNからの関連情報をXMLでエンコードされた本体を有するNOTIFY。
F7: N->S
F7：N-> S
NOTIFY sip:vkg@host.example.com SIP/2.0 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 To: <sip:vkg@example.com>;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7 Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> CSeq: 3300 NOTIFY Subscription-State: terminated;reason=fired Accept: application/spirits-event+xml Event: spirits-INDPs Allow-Events: spirits-INDPs, spirits-user-prof Content-Type: application/spirits-event+xml Content-Length: ...
vkg@host.example.com SIP / 2.0：SIPのNOTIFY <SIP：16302240216@myprovider.com>;タグ=スピリッツ-TAA-6302240216に<SIP：vkg@example.com>;タグ= 8177、afd- 991経由：SIP / 2.0 / UDP notifier.myprovider.com;ブランチ= z9hG4bK9inn- = U7コール-ID：3329as77@host.example.com連絡先：<SIP：notifier.myprovider.com>のCSeq：3300 NOTIFYスクリプション・ステート：終了;理由は=受け入れ解雇：アプリケーション/霊イベント+ XMLイベント：霊-INDPs許可 - イベント：霊-INDPs、霊ユーザー-profのコンテンツタイプ：アプリケーション/霊イベント+ XMLコンテンツ-長さ：...
<?xml version="1.0" encoding="UTF-8"?> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="INDPs" name="TAA" mode="N"> <CalledPartyNumber>6302240216</CalledPartyNumber> <CallingPartyNumber>3125551212</CallingPartyNumber> </Event> </spirits-event>
<？xml version = "1.0" エンコード= "UTF-8"？> <霊イベントのxmlns = "壷：IETF：のparams：XML：NS：霊-1.0"> <イベントタイプ= "INDPs" 名前= "TAA "モード=" N "> <CalledPartyNumber> 6302240216 </ CalledPartyNumber> <CallingPartyNumber> 3125551212 </ CallingPartyNumber> </イベント> </スピリッツイベント>
There are two important issues to note in the call flows for F7:
F7のためのコールフローに注意するには、2つの重要な問題があります。
(1) The body of the NOTIFY request contains the information passed to the SPIRITS notifier from the SCF. In this particular example, this is the phone number of the party (3125551212) that attempted to call 6302240216.
（1）NOTIFYリクエストのボディは、SCFから通知SPIRITSに渡された情報を含みます。この特定の例では、これは6302240216を呼び出すことを試み党（3125551212）の電話番号です。
(2) Since the notification occurred, the subscription established in F1 terminated (as evident by the Subscription-State header). The subscription terminated normally due to the DP associated with TAA firing (hence the reason code of "fired" in the Subscription-State header). If the subscriber wants to get notified of another attempt to call the number 6302240216, he/she should send a new SUBSCRIBE request to the notifier.
通知が発生したため（2）、F1で確立サブスクリプションは、（サブスクリプション・ステート・ヘッダーによって明らかなように）終了しました。サブスクリプションが原因TAAは、発射に関連したDP（サブスクリステートヘッダに「発射」のそれ故に理由コード）に正常に終了しました。加入者が番号6302240216を呼び出すための別の試みの通知を取得したい場合は、彼/彼女は通知に新しいSUBSCRIBEリクエストを送信する必要があります。
The subscriber can take any appropriate action upon the receipt of the NOTIFY in F7. A reasonable implementation may pop up a window populated with the information contained in the body of F12, along with a button asking the subscriber if they would like to re-subscribe to the same event. Alternatively, a re-subscription could be generated automatically by the subscriber's UA based on his/her preferences.
加入者は、F7にNOTIFYを受信すると、任意の適切な行動を取ることができます。合理的な実装では、彼らが同じイベントに再サブスクライブしたい場合は、加入者を求めて、ボタンと一緒に、F12のボディに含まれる情報で埋めウィンドウをポップアップします。また、再加入は、彼/彼女の好みに基づいて加入者のUAによって自動的に生成することができます。
To complete the protocol, the subscriber also sends a 200 OK message towards the notifier:
プロトコルを完了するために、加入者はまた、通知に対する200 OKメッセージを送信します。
F8: S->N
F8：S-> N
200 OK SIP/2.0 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 To: <sip:vkg@example.com>;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7 Call-ID: 3329as77@host.example.com CSeq: 3300 NOTIFY Content-Length: 0
200 OK SIP / 2.0 <SIP：16302240216@myprovider.com>;タグ=スピリッツ-TAA-6302240216に<SIP：vkg@example.com>;タグ= 8177-AFD-991のVia：SIP / 2.0 / UDP notifier.myprovider.com; z9hG4bK9inn- = U7のCall-ID：3329as77@host.example.comのCSeq：3300は、コンテンツの長さをNOTIFY：0
The "spirits-INDPs" package MUST NOT use URIs to retrieve state. It is expected that most state information for this package is compact enough to fit in a SIP message. However, to err on the side of caution, implementations MUST follow the convention outlined in Section 18.1.1 of [5] and use a congestion controlled transport if the size of the request is within 200 bytes of the path MTU if known, or if the request size is larger than 1300 bytes and the path MTU is unknown.
「霊-INDPs」パッケージには、状態を取得するためのURIを使用してはなりません。このパッケージのほとんどの状態情報は、SIPメッセージに収まるほどコンパクトであることが期待されます。しかし、注意の側に誤るために、実装は、[5]のセクション18.1.1に概説慣例に従い、要求のサイズが既知の場合は、パスMTUの200バイト以内である場合、または場合は、輻輳制御トランスポートを使用しなければなりませんリクエストのサイズが1300バイトより大きいと、パスMTUは不明です。
We mentioned in Section 5.1 that the first trigger that fires during call processing is typically a TDP since there isn't any pre-existing control relationship between the SSF and the SCF. Some Internet hosts may have expressed an interest in executing services based on TDPs (through an a-priori arrangement, which is not a part of this specification). Thus, the PSTN will notify such hosts. To do so, it will send a SIP request (typically an INVITE) towards the Internet host. The body of the SIP request MUST contain multi-part MIME with two MIME components: the first part corresponding to the normal payload, if any, of the request; and the second part will contain
我々は、セクション5.1で述べたものSSFとSCFとの間の任意の既存の制御関係がないので、呼処理中の火災は、典型的にはTDPである最初のトリガ。いくつかのインターネットホストは、（本明細書の一部ではない演繹的配置を通じて）TDPSに基づいてサービスを実行することに関心を表明していることができます。したがって、PSTNは、そのようなホストに通知します。そのためには、インターネットホストに向けて（通常はINVITE）SIPリクエストを送信します。 SIP要求の本体は、二つのMIMEコンポーネントとマルチパートMIMEを含まなければならない：通常のペイロードに対応する第一の部分、もしあれば、要求の;第2の部分は含まれています
SPIRITS-specific information (e.g., the DP that fired). Responses to the INVITE request, or subsequent SUBSCRIBE messages from the Internet host to the PSTN within a current call context may result in EDPs being armed.
SPIRITS固有の情報（例えば、焼成DP）。 INVITE要求、または後続の現在の呼コンテキスト内PSTN、インターネットホストからのメッセージをサブスクライブする応答が武装さEDPSをもたらすことができます。
ICW as a benchmark SPIRITS service actually predates SPIRITS itself. Pre-SPIRITS implementations of ICW are detailed in [10]. However, as the document notes, while a diversity of implementations exists, these implementations are not interoperable. At the time [10] was published, the industry did not have the depth of experience with SIP as is the case now. The use of SIP in [10] does not constitute normative usage of SIP as described in [5]; for instance, no mention is made of the SDP (if any) in the initial INVITE (especially since this pertains to "accept the call using VoIP" case). Thus this section serves to provide a normative description of ICW in SPIRITS.
ベンチマークSPIRITSサービスとしてICWが実際SPIRITS自体に先行します。 ICWのプレSPIRITS実装は[10]に詳述されています。実装の多様性が存在している間しかし、文書のメモとして、これらの実装は、相互運用可能ではありません。ケースは今のように時間[10]発表されたとき、業界はSIPの経験の深さを持っていませんでした。 [5]に記載されているように[10]におけるSIPの使用は、SIPの規範的な使用法を構成するものではありません。 （もしあれば）は、例えば、全く言及は、初期にSDPで作られていない（これはケース「のVoIPを使用してコールを受け入れる」に関係し、特に以来）INVITE。したがって、このセクションはスピリット中ICWの規範的な説明を提供するのに役立ちます。
The description of ICW is deceptively simple: it is a service most useful for single line phone subscribers that use the line to establish an Internet session. In a nutshell, the service enables a subscriber engaged in an Internet dial-up session to
ICWの説明は一見シンプルです：それは、インターネットセッションを確立するためにラインを使用し、単一ライン電話加入者のための最も便利なサービスです。一言で言えば、このサービスは、インターネットへのダイヤルアップセッションに従事した加入者を可能にします
o be notified of an incoming call to the very same telephone line that is being used for the Internet connection,
O、インターネット接続のために使用されている非常に同じ電話回線への着信が通知され、
o specify the desirable treatment of the call, and
Oコールの望ましい治療を指定し、
o have the call handled as specified.
O指定として扱わ電話を持っています。
Section 2 of [10] details the call disposition outcome of a ICW session. They are reproduced here as a numbered list for further discussion:
[10]の第2節では、ICWセッションのコール配置結果を詳述します。これらは、さらなる議論のための番号付きリストとして、ここに再現されています。
1. Accepting the call over the PSTN line, thus terminating the Internet (modem) connection
1.従ってインターネット（モデム）接続を終了する、PSTN回線を介して通話を受け入れます
4. Playing a pre-recorded message to the calling party and disconnecting the call
4.発呼者に事前に録音されたメッセージを再生し、通話を切断します
7. Rejecting (or Forwarding) on no Response - If the subscriber fails to respond within a certain period of time after the dialog box has been displayed, the incoming call can be either rejected or handled based on the treatment pre-defined by the subscriber.
7.拒否（または転送）無応答に - 加入者がダイアログボックスが表示された後、一定期間内に応答しなかった場合、着信コールは、いずれかの拒否または治療の加入者が事前に定義されたに基づいて処理することができます。
It should be pointed out for the sake of completeness that ICW as a SPIRITS service is not possible without making the SCP aware of the fact that the subscriber line is being used for an Internet session. That awareness, however, is not a part of the ICW service, but solely a pre-requisite. One of the following three methods MUST be utilized to impart this information to the SCP:
これは、ICW SPIRITSサービスとして加入者線は、インターネットセッションのために使用されているという事実のSCPは意識せずに可能ではない完全を期すために指摘されるべきです。その意識は、しかし、ICWサービスの一部が、もっぱらの前提条件ではありません。次の3つの方法の一つは、SCPにこの情報を与えるために使用しなければなりません。
A. ICW subscriber based method: the ICW client on the subscriber's PC notifies the SCP of the Internet session by issuing a SIP REGISTER request.
A. ICW加入者ベースの方法：ICWクライアント加入者のPC上では、SIP REGISTERリクエストを発行することによってインターネットセッションのSCPに通知します。
B. IN based method: SCP maintains a list of Internet Service Provider (ISP) access numbers for a geographical area; when one of these numbers is dialed and connected to, it (the SCP) assumes that the calling party is engaged in an Internet session.
Bに基づいた方法は：SCPは、地理的地域のためのインターネットサービスプロバイダ（ISP）のアクセス番号のリストを保持します。これらのいずれかの番号がダイヤルに接続されている場合、それ（SCP）は、発呼者がインターネットセッションに従事していることを前提としています。
C. Any combination of methods A and B.
C.方法AおよびBの任意の組み合わせ
ICW depends on a TDP to be provisioned in the SSP. When the said TDP is encountered, the SSP suspends processing of the call and sends a request to the SPIRITS-capable SCP. The SCP determines that the subscriber line is being used for an Internet session. It instructs the SPIRITS notifier on the SCP to create a SIP INVITE request and send it to the SPIRITS subscriber running on the subscriber's IP host.
ICWは、SSPでプロビジョニングするTDPによって異なります。言っTDPが発生した場合は、SSPは、コールの処理を中断して、SPIRITS対応のSCPに要求を送信します。 SCPは、加入者線は、インターネットセッションのために使用されていることを決定します。これは、INVITEリクエストをし、加入者のIPホスト上で実行されているSPIRITS加入者に送信SIPを作成するために、SCPに通知SPIRITSに指示します。
The SPIRITS subscriber MUST return one of the possible call disposition outcomes catalogued in Section 5.4.2. Note that outcomes 1 and 4 through 7 can all be coalesced into one case, namely redirecting (using the SIP 3xx response code) the call to an alternative SIP URI. In case of 1, the URI of the redirected call MUST match the very same number being used by the customer to get online. Rejecting the call implies sending a non-2xx and non-3xx final response; the remaining outcomes result in the call being redirected to an alternate URI which provides the desired service (i.e., play a pre-recorded announcement, or record a voice message).
SPIRITS加入者は、セクション5.4.2でカタログ可能コール処分の結果のいずれかを返さなければなりません。 7を介して1と4を成果ノートはすべて1つの場合、すなわち、（SIP 3XX応答コードを使用して）リダイレクト別のSIP URIへのコールに合体することができます。 1の場合は、リダイレクトコールのURIは、オンラインで取得するために、顧客によって使用されている非常に同じ番号が一致しなければなりません。通話を拒否すると、非2xxの非3xxの最終応答を送信することを意味し;残りの結果は、所望のサービスを提供する、代替URIにリダイレクトされるコールに（すなわち、事前録音アナウンスを再生、または音声メッセージを録音）をもたらします。
Further processing of a SPIRITS notifier when it receives a final response can be summarized by the following steps:
それは最終的な応答は、以下のステップに要約することができる受信通知SPIRITSのさらなる処理：
1. If the response is a 4xx, 5xx, or 6xx class of response, generate and transmit an ACK request and instruct the SSP to play a busy tone to the caller.
応答が4xxの、5xxの、または応答の6xxのクラスがある場合は1、生成し、ACK要求を送信して、発信者にビジートーンを再生するためにSSPを指示します。
2. Else, for all 3xx responses, generate and transmit an ACK request, and compare the redirected URI to the subscriber's line number:
そうでなければ2、すべての3xx応答のために、生成し、ACK要求を送信し、加入者回線番号にリダイレクトURIを比較します。
2a. If the comparison indicates a match, instruct the SSP to hold onto the call for just enough time to allow the SPIRITS subscriber to disconnect the modem, thus freeing up the line; and then continue with normal call processing, which will result in the subscriber's phone to ring.
図2（a）。比較が一致を示している場合、SSPは、このようにラインを解放、SPIRITS加入者がモデムを切断することを可能にするだけの十分な時間のための呼び出しに保持するよう指示。その後、リングに加入者の電話になり、通常の呼処理、に進みます。
2b. If the comparison fails, instruct the SSP to route the call to the redirected URI.
図2b。比較が失敗した場合、ルートにリダイレクトURIへの呼び出しをSSPに指示します。
One call handling option in ICW is to "accept an incoming call using VoIP". The SPIRITS notifier has no way of knowing a-priori if the subscriber (callee) will be choosing this option; nonetheless, it has to account for such a choice by adding a SDP in the body of the INVITE request. A possible way of accomplishing this is to have the SPIRITS notifier control a PSTN gateway and allocate appropriate resources on it. Once this is done, the SPIRITS notifier adds network information (IP address of the gateway and port numbers where media will be received) and codec information as the SDP portion of the body in the INVITE request. SPIRITS requires the DP information to be carried in the request body as well. To that extent, the SPIRITS notifier MUST also add the information associated with the TDP that triggered the service. Thus, the body of the INVITE MUST contain multi-part MIME, with two components.
ICWでオプションを扱う一つの呼び出しは、「VoIPのを使用して、着信コールを受け入れる」ことです。 SPIRITSは通知加入者（呼び出し先）は、このオプションを選択する場合は事前に知る方法はありません。それにもかかわらず、それは、INVITEリクエストのボディにSDPを追加することによって、そのような選択を考慮する必要があります。これを達成する可能な方法は、霊が通知PSTNゲートウェイを制御し、その上に適切なリソースを割り当てることです。これが行われると、霊が通知INVITE要求にボディのSDP部分のようなネットワーク情報（メディアが受信され、ゲートウェイとポート番号のIPアドレス）及びコーデック情報を付加します。 SPIRITSは、同様にリクエストボディに搭載するDPの情報を必要とします。その程度まで、SPIRITSは通知もサービスをトリガTDPに関連した情報を追加する必要があります。したがって、INVITEの本体は、2つの成分と、マルチパートMIMEを含まなければなりません。
The SPIRITS notifier transmits the INVITE request to the subscriber and now waits for a final response. Further processing when the SPIRITS subscriber returns a 200 OK MUST be handled as follows:
霊が通知加入者にINVITE要求を送信し、現在最終的な応答を待ちます。次のようにSPIRITS加入者は200 OKを返すさらなる処理が処理されなければなりません。
On the receipt of a 200 OK containing the SDP of the subscriber's UA, the SPIRITS notifier will instruct the SSP to terminate the call on a pre-allocated port on the gateway. This port MUST be correlated by the gateway to the SDP that was sent in the earlier INVITE.
加入者UAのSDPを含む200 OKを受信すると、霊が通知ゲートウェイに事前に割り当てられたポート上でコールを終了するSSPに指示します。このポートは、INVITE以前に送信されたSDPにゲートウェイによって相関されなければなりません。
The end result is that the caller and callee hold a voice session with part of the session occurring over VoIP.
最終結果は、呼び出し元と呼び出し先がVoIPにわたって発生セッションの一部で音声セッションを保持することです。
There are network events that are not related to setting up, maintaining, or tearing down voice calls. Such events occur on the cellular wireless network and can be used by SPIRITS to provide services. The SPIRITS protocol requirement explicitly includes the following events for which SPIRITS notification is needed (RFC3298:Section 5(b)):
セットアップ、維持、または音声通話を切断に関係しないネットワークイベントがあります。このようなイベントは、セルラー無線ネットワーク上で発生し、サービスを提供するために、SPIRITSで使用することができます。 SPIRITSプロトコル要件は、明示的SPIRITS通知が必要とされるため、以下のイベントを含む（RFC3298：セクション5（b）参照）。
1. Location update in the same Visitor Location Register (VLR) service area
同じビジターロケーションレジスタ（VLR）サービスエリア内の1位置更新
Each of the five non-call related event is given a SPIRITS-specific mnemonic for use in subscriptions and notifications.
5非呼関連イベントのそれぞれは、サブスクリプションと通知で使用するためSPIRITS特有のニーモニックを与えています。
Location update in the same VLR area SPIRITS mnemonic: LUSV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
ニーモニック同じVLRエリアSPIRITSにおける位置更新：SUBSCRIBEでLUSV必須パラメータ：CalledPartyNumber必須パラメータNOTIFYで：CalledPartyNumber、セルID
Cell-ID: A string used to identify the serving Cell-ID. The actual length and representation of this parameter depend on the particulars of the cellular provider's network.
セルID：サービングセル-IDを識別するために使用される文字列。このパラメータの実際の長さとの表現は、携帯電話プロバイダのネットワークの詳細に依存します。
Location update in different VLR area SPIRITS mnemonic: LUDV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
ニーモニック異なるVLRエリアSPIRITSにおける位置更新：SUBSCRIBEでLUDV必須パラメータ：中CalledPartyNumber必須パラメータは、NOTIFY：CalledPartyNumber、セルIDを
IMSI attach SPIRITS mnemonic: REG Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
NOTIFYにCalledPartyNumber必須パラメータ：SUBSCRIBEでREG必須パラメータ：IMSIは、ニーモニックSPIRITSを添付CalledPartyNumber、セルID
MS initiated IMSI detach SPIRITS mnemonic: UNREGMS Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
MSは、IMSIは、ニーモニックSPIRITSを切り離し開始：SUBSCRIBEに必須パラメータをUNREGMS：NOTIFYでCalledPartyNumber必須パラメータを：CalledPartyNumber
Network initiated IMSI detach SPIRITS mnemonic: UNREGNTWK Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
NOTIFYにCalledPartyNumber必須パラメータ：SUBSCRIBEでUNREGNTWK必須パラメータ：ネットワークは、IMSIは、ニーモニックSPIRITSを切り離し開始CalledPartyNumber
A subscriber will issue a SUBSCRIBE request which identifies a set of non-call related PSTN events it is interested in getting the notification of. This set MAY contain exactly one event, or it MAY contain multiple events. The SUBSCRIBE request is routed to the notifier where it is accepted, pending a successful authentication.
加入者は、通知を得ることに興味を持っている非呼関連PSTNイベントのセットを特定するSUBSCRIBEリクエストを発行します。このセットは、1つのイベントを含んでいてもよく、またはそれは複数のイベントを含むかもしれません。 SUBSCRIBEリクエストは成功した認証を保留し、それが受け入れられた通知にルーティングされます。
When any of the events identified in the set occurs, the notifier will format a NOTIFY request and direct it towards the subscriber. The NOTIFY request will contain information pertinent to the one of the event whose notification was requested.
イベントのいずれかがセット発生において同定場合、通知は、NOTIFYリクエストをフォーマットし、加入者に向けて指示します。 NOTIFYリクエストは、通知要求されたイベントの一つに関連する情報が含まれています。
The dialog established by the SUBSCRIBE persists until it expires normally, or is explicitly expired by the subscriber. This behavior is different than the behavior for subscriptions associated with the "spirits-INDPs" package. In the cellular network, the events subscribed for may occur at a far greater frequency than those compared to the wireline network (consider location updates as a cellular user moves around). Thus it is far more expedient to allow the subscription to expire normally.
SUBSCRIBEによって確立されたダイアログでは、それは通常、期限が切れるまで持続する、または明示的に加入者によって有効期限が切れています。この動作は、「霊-INDPs」パッケージに関連付けられたサブスクリプションの動作とは異なります。セルラーネットワークでは、加入のためのイベントは（セルラーユーザが動き回るように位置更新を考える）有線ネットワークと比較したものよりもはるかに高い周波数で起こり得ます。したがって、サブスクリプションが正常に期限切れにできるようにするためにはるかに有利です。
When a subscriber receives a NOTIFY request, it can subsequently choose to act in a manner appropriate to the notification.
加入者がNOTIFYリクエストを受信すると、その後通知に適切な方法で行動することを選択できます。
The remaining sections fill in the specific package responsibilities raised in RFC3265 [3], Section 4.4.
残りのセクションはRFC3265 [3]は、セクション4.4に上昇させ、特定のパッケージの責任を埋めます。
This document defines two event packages; the first was defined in Section 5.3. The second package, defined in this section is called "spirits-user-prof". This package MUST be used for events corresponding to non-call related events in the cellular network. All entities that implement the SPIRITS protocol and support the non-call related events outlined in the SPIRITS protocol requirements (RFC3298:Section 5(b)) MUST set the "Event" header request header[3] to "spirits-user-prof." The "Allow-Events" general header [3] MUST include the token "spirits-user-prof" as well.
この文書では、2つのイベントパッケージを定義します。最初は、セクション5.3で定義されました。このセクションで定義された第二のパッケージは、「霊 - ユーザー教授」と呼ばれています。このパッケージには、セルラーネットワークにおける非コール関連のイベントに対応するイベントのために使用しなければなりません。 SPIRITSプロトコルを実装し、SPIRITSプロトコル要件に概説非呼関連のイベントをサポートするすべてのエンティティは、（RFC3298：セクション5（B））[3]「スピリッツユーザ-PROFに「イベント」ヘッダ要求ヘッダーを設定しなければなりません。 " 「許可・イベント」の一般的なヘッダは、[3]同様にトークン「スピリッツ・ユーザ教授」を含まなければなりません。
Example:
例：
Event: spirits-user-prof Allow-Events: spirits-user-prof, spirits-INDPs
イベント：霊ユーザー-profの許可 - イベント：霊ユーザー-profの、霊-INDPs
The "spirits-user-prof" event package does not support any additional parameters to the Event header
「霊ユーザー-profの」イベントパッケージはEventヘッダーへの追加パラメータをサポートしていません。
SUBSCRIBE requests that serve to terminate the subscriptions MAY contain an empty body; however, SUBSCRIBE requests that establish a dialog MUST contain a body which encodes two pieces of information:
空のボディを含むかもしれサブスクリプションを終了するのに役立つSUBSCRIBE要求。しかし、2つの情報をコード化する体を含まなければならないダイアログを確立SUBSCRIBEリクエスト：
(1) The set of events that is being subscribed to. A subscriber MAY subscribe to multiple events in one SUBSCRIBE request, or MAY issue a different SUBSCRIBE request for each event it is interested in receiving a notification for. The protocol allows for both forms of representation. However, note that if one SUBSCRIBE is used to subscribe to multiple events, then an expiry for the dialog associated with that subscription affects all such events.
（1）に加入されているイベントのセット。加入者は1 SUBSCRIBEリクエストをして、複数のイベントに加入することができる、またはそれはのための通知を受信することに関心があるイベントごとに異なるSUBSCRIBEリクエストを発行することができます。プロトコルは、表現の両方の形態を可能にします。しかし、1は複数のイベントをサブスクライブするために使用されたSUBSCRIBE場合、そのサブスクリプションに関連付けられているダイアログの有効期限は、すべてこのようなイベントに影響することに注意してください。
(2) A list of values of the parameters associated with the event. Please see Section 6.1 for a list of parameters associated with each event.
（2）イベントに関連付けられたパラメータの値のリスト。各イベントに関連するパラメータのリストについては、セクション6.1を参照してください。
The default body type for SUBSCRIBEs in SPIRITS is denoted by the MIME type "application/spirits-event+xml". The "Accept" header, if present, MUST include this MIME type.
SPIRITSで加入するためのデフォルトのボディタイプは、MIMEタイプ「アプリケーション/霊イベント+ xmlの」によって示されます。 「同意」ヘッダは、存在する場合、このMIMEタイプを含まなければなりません。
The duration of a dialog established by a SUBSCRIBE request is limited to the expiration time negotiated between the subscriber and notifier when the dialog was established. The subscriber MUST send a new SUBSCRIBE to refresh the dialog if it is interested in keeping it alive. A dialog can be terminated by sending a new SUBSCRIBE request with an "Expires" header value of 0, as outlined in [3].
SUBSCRIBEリクエストによって確立されたダイアログの継続時間は、ダイアログが確立された加入者との間で交渉通知有効期限に制限されます。加入者は新しいが、それが生きている保つことに関心がある場合、ダイアログをリフレッシュするSUBSCRIBE送らなければなりません。ダイアログ[3]に概説されるように、0のヘッダの値を「有効期限」と新しいSUBSCRIBEリクエストを送信することによって終了することができます。
Bodies in NOTIFY requests for the "spirits-user-prof" package are optional. If present, they MUST be of the MIME type "application/spirits-event+xml". The body in a NOTIFY request encapsulates the following pieces of information which can be used by the subscriber:
「霊ユーザー-profの」パッケージのNOTIFYリクエストを内ボディはオプションです。存在する場合、それらは、MIMEタイプ「アプリケーション/霊イベント+ xml」である必要があります。 NOTIFYリクエストボディは、加入者が使用することができる以下の情報をカプセル化します。
(1) The event that resulted in the NOTIFY being generated (typically, but not always, this will be the same event present in the corresponding SUBSCRIBE request).
（1）をもたらしたイベントNOTIFY生成される（典型的には、常にではないが、これは対応で同じイベントの存在は、SUBSCRIBEリクエストをあろう）。
(2) A list of values of the parameters associated with the event that the NOTIFY is being generated for. Depending on the actual event, the list of the parameters will vary.
（2）NOTIFYイベントに関連付けられたパラメータの値のリストをするために生成されています。実際のイベントに応じて、パラメータのリストが異なります。
When the notifier receives a SUBSCRIBE request, it MUST authenticate the request and ensure that the subscriber is authorized to access the resource being subscribed to, in this case, non-call related cellular events for a mobile phone.
通知は、SUBSCRIBEリクエストを受信すると、要求を認証し、加入者が、この場合には、非コール携帯電話用細胞事象を関連に加入されているリソースへのアクセスを許可されていることを保証しなければなりません。
Once the SUBSCRIBE request has been authenticated and authorized, the notifier interfaces with the SCF over interface D to set marks in the HLR corresponding to the mobile phone number contained in the SUBSCRIBE body. The particulars of interface D are outside the scope of this document; here we simply assume that the notifier is able to set the appropriate marks in the HLR.
SUBSCRIBEリクエストが認証および承認された後、インターフェースD上SCFと通知インターフェイスは、SUBSCRIBEボディーに含まれている携帯電話番号に対応するHLRにマークを設定します。インターフェースDの詳細は、この文書の範囲外です。ここでは、単に通知をHLRに適切なマークを設定することが可能であることを前提としています。
If the notifier expects the setting of marks in the HLR to take more than 200 ms, it MUST send a 202 response to the SUBSCRIBE request immediately, accepting the subscription. It should then send a NOTIFY request with an empty body. This NOTIFY request MUST have a "Subscription-State" header with a value of "pending".
通知は、HLR内のマークの設定は、200ミリ秒以上を取ることを期待する場合は、サブスクリプションを受け入れ、すぐにSUBSCRIBE要求に202応答を送らなければなりません。その後、空のボディを持つNOTIFYリクエストを送信する必要があります。このNOTIFYリクエストは、「保留」の値を持つ「サブスクリプション・ステート」ヘッダを持たなければなりません。
This immediate NOTIFY with an empty body is needed since the resource identified in the SUBSCRIBE request does not have as yet a meaningful state.
SUBSCRIBEリクエストで特定されたリソースは、まだ意味のある状態を持っていないので、空の体が必要とされていると、この即時に通知します。
Once the notifier has successfully interfaced with the SCF, it MUST send a subsequent NOTIFY request with an empty body and a "Subscription-State" header with a value of "active."
通知が正常SCFとインタフェースしたら、それは空の本体との値が「サブスクリプション状態」ヘッダを持つ後続のNOTIFYリクエスト送信しなければならない「アクティブ」を
When the event of interest identified in the SUBSCRIBE request occurs, the notifier sends out a new NOTIFY request which MUST contain a body as described in Section 6.7.
SUBSCRIBEリクエストで特定され、関心のイベントが発生すると、通知は、6.7節で説明したように体を含まなければならない新しいNOTIFYリクエストを送信します。
The exact steps executed at the subscriber when it receives a NOTIFY request depend on the nature of the service that is being implemented. As a generality, the UA associated with the subscriber should somehow impart this information to the user by visual or auditory means, if at all possible.
それはNOTIFYリクエストを受信する加入者で実行される正確な手順が実施されているサービスの性質に依存します。可能であれば一般性として、加入者に関連付けられたUAは何とか、視覚的または聴覚的手段によってユーザにこの情報を与えるべきです。
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE request is targeted towards the PSTN, highly irregular behaviors occur if the request is allowed to fork. The normal SIP DNS lookup and routing rules [11] should result in a target set with exactly one element: the notifier.
SUBSCRIBEリクエストのフォークは禁止されています。 SUBSCRIBEリクエストがPSTNを対象としているので、要求がフォークに許可されている場合、高度に不規則な挙動が発生します。通知：通常のSIPのDNSルックアップおよびルーティング規則[11]は正確に一つの要素に設定された目標をもたらすはずです。
For reasons of congestion control, it is important that the rate of notifications not become excessive. For instance, if a subscriber subscribes to the location update event for a notifier moving through the cellular network at a high enough velocity, it is entirely conceivable that the notifier may generate many NOTIFY requests in a small time frame. Thus, within this package, the location update event needs an appropriate throttling mechanism.
輻輳制御の理由から、通知の割合が過大にならないことが重要です。加入者が十分に高い速度でセルラーネットワークを介して移動通知するための位置更新イベントをサブスクライブしている場合、例えば、その通知は、多くの小さな時間枠でNOTIFYリクエストを生成してもよいことは全く考えられます。したがって、このパッケージ内に、位置更新イベントは、適切な絞り機構を必要とします。
Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST start a timer (Tn) with a value of 15 seconds. If a subsequent location update NOTIFY request needs to be sent out before the timer has expired, it MUST be discarded. Any future location update NOTIFY requests MUST be transmitted only if Tn has expired (i.e. 15 seconds have passed since the last NOTIFY request was send out). If a location update NOTIFY is send out, Tn should be reset to go off again in 15 seconds.
SPIRITS通知が位置更新を通知送信するたびに、それは15秒の値をタイマー（TN）を起動する必要があります。その後の位置更新要求がタイマが満了する前に送信する必要があるNOTIFY場合は、それを捨てなければなりません。任意の将来の位置更新要求が（すなわち、15秒、最後のNOTIFYリクエスト経過した送り出した）Tnが期限切れになった場合にのみ送信されなければならないNOTIFY。位置更新が送信されたNOTIFY場合、Tnが15秒で再びオフに行くためにリセットする必要があります。
State agents are not used in SPIRITS.
状態エージェントはSPIRITSで使用されていません。
This section contains an example of a SPIRITS service that may be used to update the presence status of a mobile user. The call flow is depicted in Figure 4 below.
このセクションでは、モバイルユーザのプレゼンス状態を更新するために使用されてもよいSPIRITSサービスの例を含んでいます。コールフローは、以下の図4に示されています。
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Set HLR mark|
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 4: Sample call flow
図4：サンプルコールフロー
In F1 of Figure 4, the subscriber indicates an interest in receiving a notification when a mobile user registers with the cellular network. The cellular network notes this event (F2) and confirms the subscription (F3-F5). When the mobile user turns on her cell phone and registers with the network, this event is detected (F6). The cellular network then sends out a notification to the subscriber informing it of this event (F7-F8).
図4のF1において、加入者は、モバイルユーザがセルラネットワークに登録通知を受信することに関心を示しています。携帯電話ネットワークのメモこのイベント（F2）およびサブスクリプション（F3-F5）を確認。モバイルユーザが自分の携帯電話をオンにし、ネットワークに登録するとき、このイベントは、（F6）が検出されます。セルラーネットワークは、このイベント（F7-F8）をそれに知らせる加入者に通知を送出します。
We present the details of the call flow next.
私たちは、次のコールフローの詳細を提示します。
In F1, the subscriber subscribes to the registration event (REG) of a cellular phone number.
F1において、加入者は携帯電話番号の登録イベント（REG）に加入します。
F1: S->N SUBSCRIBE sip:myprovider.com SIP/2.0 From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com> CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8 Expires: 3600 Event: spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
F1：S-> N SUBSCRIBE SIP：myprovider.com SIP / 2.0 <SIP：vkg@example.com>;タグ= 8177-AFD-991に<SIP：16302240216@myprovider.com>のCSeq：18992コールをSUBSCRIBE -ID：3329as77@host.example.com連絡先：<SIP：vkg@host.example.com>ビア：SIP / 2.0 / UDP host.example.com;枝は= z9hG4bK776asdhdsa8有効期限：3600イベント：霊ユーザー-profのを許可します - イベント：霊-INDPs、霊ユーザー-profの受け入れ：アプリケーション/霊-イベント+ xmlのコンテンツタイプ：アプリケーション/霊イベント+ XMLコンテンツ-長さ：...
<?xml version="1.0" encoding="UTF-8"?> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="userprof" name="REG"> <CalledPartyNumber>6302240216</CalledPartyNumber> </Event> </spirits-event>
<？xml version = "1.0" エンコード= "UTF-8"？> <霊イベントのxmlns = "壷：IETF：のparams：XML：NS：霊-1.0"> <イベントタイプ=名= "REG "userprof" 「> <CalledPartyNumber> 6302240216 </ CalledPartyNumber> </イベント> </霊イベント>
The subscription reaches the notifier which authenticates the request (not shown) and interacts with the SCF to update the subscribers database for this event. The notifier sends out a successful response to the subscription:
サブスクリプションは、要求（図示せず）を認証し、このイベントの加入者データベースを更新するために、SCFと相互作用通知に達します。通知は、サブスクリプションに成功した応答を送信します。
F3: N->S SIP/2.0 200 OK From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8 Expires: 3600 Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Length: 0
F3：N-> S SIP / 2.0 200 OKから<SIP：vkg@example.com>;タグ= 8177-AFD-991に<SIP：16302240216@myprovider.com>;タグ=スピリッツ-REG-16302240216のCSeq ：18992コールIDをSUBSCRIBE：3329as77@host.example.com連絡先：<SIP：notifier.myprovider.com>ビア：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bK776asdhdsa8が有効期限：3600許可 - イベント：spirits- INDPs、霊ユーザー-profの受け入れ：アプリケーション/霊イベント+のxmlのContent-Length：0
The notifier also sends out a NOTIFY request confirming the subscription:
通知はまた、サブスクリプションを確認するNOTIFYリクエストを送信します。
F4: N->S NOTIFY sip:vkg@host.example.com SIP/2.0 To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9121 NOTIFY
F4：N-> S NOTIFY SIP：vkg@host.example.com SIP / 2.0 <SIP：vkg@example.com>;タグ= 8177-AFD-991から<SIP：16302240216@myprovider.com>。タグ= SPIRITS-REG-16302240216のCSeq：9121は、NOTIFY
Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Subscription-State: active Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Length: 0
コールID：3329as77@host.example.com連絡先：<SIP：notifier.myprovider.com>サブスクリ - 状態：アクティブ経由：SIP / 2.0 / UDP notifier.myprovider.com;ブランチ= z9hG4bK7007-091a許可 - イベント：スピリッツ-INDPs、霊ユーザー-profの受け入れ：アプリケーション/霊-イベント+ xmlのコンテンツの長さ：0
The subscriber confirms the receipt of the NOTIFY request:
加入者は、NOTIFYリクエストの受信を確認します：
F5: S->N SIP/2.0 200 OK To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9121 NOTIFY Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a Content-Length: 0
F5：S-> N SIP / 2.0 200 OKに<SIP：vkg@example.com>;タグ= 8177-AFD-991から<SIP：16302240216@myprovider.com>;タグ=スピリッツ-REG-16302240216のCSeq ：9121 NOTIFYコールID：3329as77@host.example.com連絡先：<SIP：vkg@host.example.com>ビア：SIP / 2.0 / UDP notifier.myprovider.com;ブランチ= z9hG4bK7007-091aのContent-Length：0
In F6, the mobile user identified by the PSTN number "6302240216" turns the mobile phone on, thus causing it to register with the cellular network. The cellular network detects this event, and since a subscriber has indicated an interest in receiving a notification of this event, a SIP NOTIFY request is transmitted towards the subscriber:
F6では、PSTN番号「6302240216」で識別されるモバイルユーザは、それがセルラーネットワークに登録させる、携帯電話をオンにします。セルラーネットワークは、このイベントを検出し、加入者は、このイベントの通知を受信することに関心を示しているので、SIP NOTIFYリクエストは、加入者に向けて送信されます。
F7: N->S NOTIFY sip:vkg@host.example.com SIP/2.0 To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9122 NOTIFY Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Subscription-State: terminated;reason=fired Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12 Event: spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
F7：N-> S NOTIFY SIP：vkg@host.example.com SIP / 2.0 <SIP：vkg@example.com>;タグ= 8177-AFD-991から<SIP：16302240216@myprovider.com>。タグ= SPIRITS-REG-16302240216のCSeq：9122 NOTIFYコールIDを：3329as77@host.example.com連絡先：<SIP：notifier.myprovider.com>サブスクリ - 状態：終了;理由は=経由解雇：SIP / 2.0 / UDP通知を.myprovider.com;ブランチ= z9hG4bK7yi-P12イベント：霊ユーザー-profの許可 - イベント：霊-INDPs、霊ユーザー-profの受け入れ：アプリケーション/霊-イベント+ xmlのコンテンツタイプ：アプリケーション/霊イベント+ xmlのコンテンツの長さ：...
<?xml version="1.0" encoding="UTF-8"?> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0"> <Event type="userprof" name="REG"> <CalledPartyNumber>6302240216</CalledPartyNumber> <Cell-ID>45987</Cell-ID> </Event> </spirits-event>
<？xml version = "1.0" エンコード= "UTF-8"？> <霊イベントのxmlns = "壷：IETF：のparams：XML：NS：霊-1.0"> <イベントタイプ=名= "REG "userprof" 「> <CalledPartyNumber> 6302240216 </ CalledPartyNumber> <セル-ID> 45987 </セルID> </イベント> </霊イベント>
The subscriber receives the notification and acknowledges it by sending a response:
加入者は、通知を受信し、応答を送信することによって、それを承認します：
F8: S->N
F8：S-> N
SIP/2.0 200 OK To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9122 NOTIFY Call-ID: 3329as77@host.example.com Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12 Content-Length: 0
SIP / 2.0 200 OKに<SIP：vkg@example.com>;タグ= 8177-AFD-991から<SIP：16302240216@myprovider.com>;タグ=スピリッツ-REG-16302240216のCSeq：9122 NOTIFYコールID ：3329as77@host.example.com経由：SIP / 2.0 / UDP notifier.myprovider.com;ブランチ= z9hG4bK7yi-P12のコンテンツ長：0
Note that once the subscriber has received this notification, it can execute appropriate services. In this particular instance, an appropriate service may consist of the subscriber acting as a composer of a presence service and turning the presence status of the user associated with the phone number "6302240216" to "on". Also note in F7 that the notifier included a Cell ID in the notification.
加入者がこの通知を受けた後、それが適切なサービスを実行できることに注意してください。この特定の例では、適切なサービスは、加入者がプレゼンスサービスの作曲として作用し、「オン」に電話番号「6302240216」に関連付けられたユーザのプレゼンス状態を回すから成ってもよいです。また、通知は、通知でセルIDを含めF7に注意してください。
The Cell ID can be used as a basis for location specific services; however, a discussion of such services is out of the scope of this document.
セルIDは、位置特定サービスのための基礎として使用することができます。しかし、このようなサービスの議論は、この文書の範囲外です。
The "spirits-user-prof" package MUST NOT use URIs to retrieve state. It is expected that most state information for this package is compact enough to fit in a SIP message. However, to err on the side of caution, implementations MUST follow the convention outlined in Section 18.1.1 of [5] and use a congestion controlled transport if the size of the request is within 200 bytes of the path MTU if known, or if the request size is larger than 1300 bytes and the path MTU is unknown.
「霊ユーザー-profの」パッケージには、状態を取得するためのURIを使用してはなりません。このパッケージのほとんどの状態情報は、SIPメッセージに収まるほどコンパクトであることが期待されます。しかし、注意の側に誤るために、実装は、[5]のセクション18.1.1に概説慣例に従い、要求のサイズが既知の場合は、パスMTUの200バイト以内である場合、または場合は、輻輳制御トランスポートを使用しなければなりませんリクエストのサイズが1300バイトより大きいと、パスMTUは不明です。
This document calls for IANA to:
このドキュメントは、IANAのために呼び出します。
o register two new SIP Event Packages per [3].
Oごとに2つの新しいSIPイベントパッケージを登録する[3]。
o register a new MIME type per [20].
O [20]あたりの新しいMIMEタイプを登録します。
o register a new namespace URN per [16].
O [16]あたりの新しい名前空間のURNを登録します。
o register a new XML schema per [16].
O [16]あたりの新しいXMLスキーマを登録します。
Package Name: spirits-INDPs
パッケージ名：霊-INDPs
Type: package
タイプ：パッケージ
Contact: Vijay K. Gurbani, vkg@lucent.com
連絡先：ビジェイK. Gurbani、vkg@lucent.com
Reference: RFC 3910
参考：RFC 3910
Package Name: spirits-user-prof
パッケージ名：精霊ユーザー-profの
Type: package
タイプ：パッケージ
Contact: Vijay K. Gurbani, vkg@lucent.com
連絡先：ビジェイK. Gurbani、vkg@lucent.com
Reference: RFC 3910
参考：RFC 3910
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: spirits-event+xml
MIMEサブタイプ名：精霊イベント+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: charset (same semantics of charset parameter in application/xml [9])
オプションのパラメータ：文字セット（アプリケーション/ XMLでcharsetパラメータの同じセマンティクス[9]）
Encoding considerations: same as considerations outlined for application/xml in [9].
符号化の考慮事項：[9]にアプリケーション/ XMLについて概説考慮事項と同じ。
Security considerations: Section 10 of [9] and Section 8 of this document.
セキュリティの考慮事項：[9]のセクション10と、このドキュメントのセクション8。
Interoperability considerations: none.
相互運用性に関する注意事項：なし。
Published specifications: this document.
公開された仕様：このドキュメント。
Applications which use this media type: SPIRITS aware entities which adhere to this document.
このメディアタイプを使用するアプリケーション：この文書に準拠SPIRITS意識の実体。
Additional information:
追加情報：
Magic number(s): none.
マジックナンバー（S）：なし。
File extension(s): none.
ファイルの拡張子（S）：なし。
Macintosh file type code(s): none.
Macintoshのファイルタイプコード（S）：なし。
Object Identifier(s) or OID(s): none.
オブジェクト識別子（S）またはOID（S）：なし。
Person and email address for further information: Vijay K. Gurbani, <vkg@lucent.com>
詳しくは、人とEメールアドレス：ビジェイK. Gurbani、<vkg@lucent.com>
Intended usage: Common
意図している用法：コモン
Author/Change controller: The IETF
著者/変更コントローラ：IETF
URI urn:ietf:params:xml:ns:spirits-1.0
URI骨壷：IETF：のparams：XML：NS：霊-1.0
Description This is the XML namespace URI for XML elements defined by this document. Such elements describe the SPIRITS information in the "application/ spirits-event+xml" content type.
説明これは、このドキュメントで定義されたXML要素のXML名前空間URIです。そのような要素は、「アプリケーション/スピリッツイベント+ XML」コンテンツタイプにSPIRITS情報を記述する。
Registrant Contact IESG.
登録者連絡先IESG。
XML BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <title>Namespace for SPIRITS-related information</title> </head> <body> <h1>Namespace for SPIRITS-related information</h1>
！XML BEGIN <？xmlのバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml -basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <メタHTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = UTF -8" /> <タイトル>スピリッツ関連情報の名前空間</タイトル> </ head> <body> <H1>スピリッツ関連情報の名前空間</ H1>
<h2>application/spirits-event+xml</h2> <p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p> </body> </html> END
<H2>アプリケーション/霊-イベント+ xmlの</ H2> <P>公表RFC]]]"> RFC3910 </a>での<a href="[[[URLを参照してください。</ P> </ BODY> < / HTML> END
URI urn:ietf:params:xml:schema:spirits-1.0
URI骨壷：IETF：のparams：XML：スキーマ：霊-1.0
Description XML base schema for SPIRITS entities.
SPIRITSエンティティの説明XMLベーススキーマ。
Registrant Contact IESG.
登録者連絡先IESG。
XML Please see XML schema definition in Section 9 of this document.
XMLは、このドキュメントのセクション9でのXMLスキーマ定義を参照してください。
This section focuses on security considerations which are unique to SPIRITS. SIP security mechanisms are discussed in detail in the core SIP specification [5] and are outside the scope of this document. SPIRITS security mechanisms are based on and strengthen SIP security [5], for example, SPIRITS mandates the support of S/MIME. Beyond that, any other security solutions specified in [5], i.e., TLS or HTTP Digest authentication, may be utilized by SPIRITS operators.
このセクションでは、SPIRITSにユニークなセキュリティ上の考慮事項に焦点を当てています。 SIPのセキュリティメカニズムは、コアSIP仕様で詳細に説明されている[5]この文書の範囲外です。 SPIRITSセキュリティメカニズムは、に基づいており、SIPのセキュリティを強化している[5]、例えば、精神はS / MIMEのサポートを義務付け。それを越えて、[5]、すなわち、TLSやHTTPダイジェスト認証で指定された他のセキュリティソリューションは、SPIRITSオペレータによって利用されてもよいです。
As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the following security aspects are applicable to the SPIRITS protocol:
RFC3298の第9章（セキュリティ考察）に概説されるように[4]は、以下のセキュリティ態様はSPIRITSプロトコルに適用可能です。
Authentication
認証
Integrity
整合性
Confidentiality
機密性
Non-repudiation
否認防止
The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B, C, D, and E. Of these, only two -- B and C -- are of interest to SPIRITS. Interfaces A and E are PINT interfaces and are thus assumed secured by the PINT RFC [8]. Security for interface D is out of scope in this document since it deals primarily with the PSTN infrastructure. We will discuss security aspects on interfaces B and C predicated on certain assumptions.
図1のSPIRITSアーキテクチャは5つのインターフェース含ま - A、B、C、D、及びこれらのうちE.を、2つだけ - BおよびC - SPIRITSに関心があります。インタフェースAとEはPINTインターフェースであり、したがって、PINTのRFC [8]によって固定想定されます。それはPSTNインフラで主に扱っているので、インタフェースDのセキュリティは、この文書の範囲外です。当社は、一定の仮定を前提インタフェースBとCのセキュリティ面について説明します。
A driving assumption for SPIRITS security is that the SPIRITS gateway is owned by the same PSTN operator that owns the SPIRITS notifier. Thus, it is attractive to simply relegate security of interface C to the PSTN operator, and in fact, there are merits to doing just that since interface C crosses the IP Network and PSTN boundaries. However, a closer inspection reveals that both interfaces B and C transmit the SPIRITS protocol; thus, any security arrangement we arrive at for interface B can be suitably applied to interface C as well. This makes it possible to secure interface C in case the SPIRITS gateway is not owned by the same PSTN operator that owns the SPIRITS notifier.
SPIRITSセキュリティの駆動仮定はSPIRITSゲートウェイが通知精神を所有している同じPSTNオペレータによって所有されていることです。したがって、単にPSTNオペレータにインターフェースCのセキュリティを格下げすることは魅力的である、実際には、インターフェースので、CはIPネットワークとPSTNの境界を横断するだけのことをやってのメリットがあります。しかし、精密検査は、インタフェースBとCの両方がSPIRITSプロトコルを伝送することが明らかになりました。従って、我々は、インタフェースBのために到着するすべてのセキュリティ構成は、好適同様にCをインターフェイスに適用することができます。これはSPIRITSゲートウェイが通知精神を所有している同じPSTNオペレータによって所有されていない場合には、インタフェースCを確保することができます。
The ensuing security discussion assumes that the SPIRITS subscriber is communicating directly to the SPIRITS notifier (and vice-versa) and specifies a security apparatus for this arrangement. However, the same apparatus can be used to secure the communication between a SPIRITS subscriber and an intermediary (like the SPIRITS gateway), and the same intermediary and the SPIRITS notifier.
その後、セキュリティの議論はSPIRITS加入者が通知（およびその逆）SPIRITSに直接通信し、この構成のセキュリティ装置を指定していることを前提としています。しかしながら、同じ装置が通知SPIRITS加入者と（SPIRITSゲートウェイ等）の中間、同じ中間、スピリッツ間の通信を保護するために使用することができます。
Confidentiality of the SPIRITS protocol is essential since the information carried in the protocol data units is of a sensitive nature and may lead to privacy concerns if revealed to non-authorized parties. The communication path between the SPIRITS notifier and the SPIRITS subscriber should be secured through S/MIME [18] to alleviate privacy concerns, as is described in the Security Consideration section of the core SIP specification [5].
プロトコルデータユニットに運ばれた情報は、機密性のものであり、非認可関係者に明らかにした場合のプライバシーの問題につながる可能性があるためSPIRITSプロトコルの機密性が必要不可欠です。コアSIP仕様のセキュリティ考察のセクションに記載されているように通知スピリッツ、SPIRITS加入者との間の通信経路は、プライバシーの懸念を軽減するためにS / MIME [18]を介して固定されるべきである[5]。
S/MIME is an end-to-end security mechanism which encrypts the SPIRITS bodies for transit across an open network. Intermediaries need not be cognizant of S/MIME in order to route the messages (routing headers travel in the clear).
S / MIMEは、オープンネットワーク全体でのトランジットのためSPIRITS体を暗号化し、エンドツーエンドのセキュリティメカニズムです。仲介はルーティングするために、メッセージS / MIMEを認識している必要はない（ルーティングヘッダは平文で移動します）。
S/MIME provides all the security aspects for SPIRITS outlined at the beginning of this section: authentication, message integrity, confidentiality, and non-repudiation. Authentication properties provided by S/MIME would allow the recipient of a SPIRITS message to ensure that the SPIRITS payload was generated by an authorized entity. Encryption would ensure that only those SPIRITS entities possessing a particular decryption key are capable of inspecting encapsulated SPIRITS bodies in a SIP request.
認証、メッセージの整合性、機密性、および否認防止：S / MIMEは、このセクションの冒頭で概説SPIRITSのすべてのセキュリティの側面を提供します。 S / MIMEによって提供される認証特性はSPIRITSメッセージの受信者がSPIRITSペイロードが許可エンティティによって生成されたことを確認することを可能にします。暗号化は、特定の復号鍵を有するものだけSPIRITS実体は、SIPリクエストにカプセル化SPIRITS体を検査することができることを確実にするでしょう。
All SPIRITS endpoints MUST support S/MIME signatures (CMS SignedData) and MUST support encryption (CMS EnvelopedData).
すべてのSPIRITSエンドポイントは、S / MIME署名（CMSのSignedData）をサポートしなければならないと暗号化（CMS EnvelopedDataの）をサポートしなければなりません。
If the B and C interfaces are owned by the same PSTN operator, it is possible that public keys will be installed in the SPIRITS endpoints.
B及びCインタフェースが同じPSTNオペレータによって所有されている場合、公開鍵はSPIRITSエンドポイントにインストールされることが可能です。
S/MIME supports two methods -- issuerAndSerialNumber and subjectKeyIdentifier -- of naming the public key needed to validate a signature. Between these, subjectKeyIdentifier works with X.509 certificates and other schemes as well, while issuerAndSerialNumber works with X.509 certificates only. If the administrator configures the necessary public keys, providing integrity through procedural means, then S/MIME can be used without X.509 certificates.
issuerAndSerialNumberとsubjectKeyIdentifier - - 署名を検証するために必要な公開鍵を命名のS / MIMEは、2つのメソッドをサポートしています。 issuerAndSerialNumberのみX.509証明書と連携しながら、これらの間に、subjectKeyIdentifierは、同様にX.509証明書や他の方式で動作します。管理者は、手続きの手段で整合性を提供し、必要な公開鍵を設定した場合、S / MIMEは、X.509証明書なしで使用することができます。
All requests (and responses) between SPIRITS entities MUST be encrypted.
SPIRITSエンティティ間のすべての要求（および応答）は、暗号化されなければなりません。
When a request arrives at a SPIRITS notifier from a SPIRITS subscriber, the SPIRITS notifier MUST authenticate the request. The subscription (or registration) from a SPIRITS subscriber MUST be rejected if the authentication fails. If the SPIRITS subscriber successfully authenticated itself to the SPIRITS notifier, the SPIRITS notifier MUST, at the very least, ensure that the SPIRITS subscriber is indeed allowed to receive notifications of the events it is subscribing to.
リクエストがSPIRITS加入者から通知SPIRITSに到着すると、SPIRITSは、通知要求を認証しなければなりません。認証が失敗した場合SPIRITS加入者からのサブスクリプション（または登録）が拒絶しなければなりません。 SPIRITS加入者が正常に通知SPIRITSに自分自身を認証された場合は、SPIRITSは、通知、非常に少なくとも、SPIRITS加入者が実際にそれがに加入されたイベントの通知を受信するために許可されていることを確認しなければなりません。
Note that this document does not proscribe how the SPIRITS notifier achieves this. In practice, it could be through access control lists (ACL) that are populated by a service management system in the PSTN, or through a web interface of some sort.
このドキュメントはSPIRITS通知がこれをどのように達成するか禁止していないことに注意してください。実際には、PSTN、またはある種のウェブインタフェースを介してサービス管理システムにより取り込まれているアクセス制御リスト（ACL）を介してであってもよいです。
Requests from the SPIRITS notifier to the SPIRITS subscribers MUST also be authenticated, lest a malicious party attempts to fraudulently pose as a SPIRITS notifier to hijack a session.
悪意のあるパーティが不正にセッションをハイジャックする通知SPIRITSとして提起しようとしないようにSPIRITSからの要求は、通知SPIRITSへの加入者はまた、認証を受ける必要があります。
The SPIRITS payload is specified in XML; this section defines the base XML schema for documents that make up the SPIRITS payload. All SPIRITS entities that transport a payload characterized by the MIME type "application/spirits-event+xml" MUST support documents corresponding to the base schema below.
SPIRITSペイロードは、XMLで指定されています。このセクションでは、SPIRITSペイロードを構成する文書のためのベースのXMLスキーマを定義します。 MIMEタイプ「アプリケーション/霊イベント+ xmlの」によって特徴づけられるペイロードを運ぶすべてのSPIRITS実体は、以下の基本スキーマに対応する文書をサポートしなければなりません。
Multiple versions of the base schema are not expected; rather, any additional functionality (e.g., conveying new PSTN events) must be accomplished through the definition of a new XML namespace and a corresponding schema. Elements from the new XML namespace will then co-exist with elements from the base schema in a document.
ベーススキーマの複数のバージョンが期待されていません。むしろ、（例えば、新しいPSTNイベントを伝達する）、任意の追加機能は、新しいXML名前空間の定義と対応するスキーマを介して達成されなければなりません。新しいXML名前空間からの要素は、ドキュメント内のベース・スキーマの要素と共存します。
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0" xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：霊-1.0" のxmlns：TNS = "壷：IETF：のparams：XML：NS：霊-1.0" のxmlns：XS = "のhttp：// WWW .w3.org / 2001 / XMLスキーマ」のelementFormDefault = "資格" attributeFormDefault = "非修飾">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation> <xs:documentation xml:lang="en"> Describes SPIRITS events. </xs:documentation> </xs:annotation>
<XS：注釈> <XS：ドキュメントのxml：langは= "en" が> SPIRITSイベントを記述します。 </ XS：ドキュメンテーション> </ XS：注釈>
<xs:element name="spirits-event" type="tns:SpiritsEventType"/>
<XS：要素名= "霊イベント" タイプ= "TNS：SpiritsEventType" />
<xs:complexType name="SpiritsEventType"> <xs:sequence> <xs:element name="Event" type="tns:EventType" minOccurs="1" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<XS：complexTypeの名前= "SpiritsEventType"> <XS：シーケンス> <XS：要素名= "イベント" タイプ= "TNS：イベントタイプ" のminOccurs = "1" のmaxOccurs = "無制限" /> <XS：任意の名前空間=」 ##他の」のprocessContents = "緩い" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの>
<xs:complexType name="EventType"> <xs:sequence> <xs:element name="CalledPartyNumber" type="xs:token" minOccurs="0" maxOccurs="1"/> <xs:element name="CallingPartyNumber" type="xs:token" minOccurs="0" maxOccurs="1"/> <xs:element name="DialledDigits" type="xs:token" minOccurs="0" maxOccurs="1"/> <xs:element name="Cell-ID" type="xs:token" minOccurs="0" maxOccurs="1"/> <xs:element name="Cause" type="tns:CauseType" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="type" type="tns:PayloadType" use="required"/> <xs:attribute name="name" type="tns:EventNameType" use="required"/> <xs:attribute name="mode" type="tns:ModeType" use="optional" default="N"/> </xs:complexType>
<XS：complexTypeの名前= "イベントタイプ"> <XS：配列> <XS：要素名= "CalledPartyNumber" タイプ= "XS：トークン" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名=」 CallingPartyNumber」TYPE = "XS：トークン" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名= "DialledDigits" タイプ= "XS：トークン" のminOccurs = "0" のmaxOccurs = "1" /> < XS：要素名= "セルID" タイプ= "XS：トークン" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名= "原因" タイプ= "TNS：CauseType" のminOccurs = "0" maxOccurs = "1" /> </ XS：シーケンス> <XS：属性名= "タイプ" タイプ= "TNS：PayloadType" 使用= "必要" /> <XS：属性名= "名前" タイプ= "TNS： EventNameType」使用= "必要" /> <XS：属性名= "モード" タイプ= "TNS：ModeType" 使用= "オプションの" デフォルト= "N" /> </ XS：complexTypeの>
<xs:simpleType name="PayloadType"> <!-- The <spirits-event> will contain either a list of --> <!-- INDPs events or a list of userprof events --> <xs:restriction base="xs:string"> <xs:enumeration value="INDPs"/> <xs:enumeration value="userprof"/> </xs:restriction> </xs:simpleType>
<XS：単純名= "PayloadType"> < - INDPsイベントやuserprofイベントのリスト - > <！ - - <霊-イベントは>のリストのいずれかが含まれます！> <XS：制限ベースを= "XS：文字列"> <XS：列挙値= "INDPs" /> <XS：列挙値= "userprof" /> </ XS：制限> </ XS：simpleTypeの>
<xs:simpleType name="EventNameType"> <xs:restriction base="xs:string"> <!-- These are the call related events (DPs). If the --> <!-- PaylaodType is "INDPs", then the value of the "name" --> <!-- attribute is one of these; example --> <!-- <spirits-event type="INDPs" name="OCI"> --> <xs:enumeration value="OAA"/> <xs:enumeration value="OCI"/> <xs:enumeration value="OAI"/> <xs:enumeration value="OA"/> <xs:enumeration value="OTS"/> <xs:enumeration value="ONA"/> <xs:enumeration value="OCPB"/> <xs:enumeration value="ORSF"/> <xs:enumeration value="OMC"/> <xs:enumeration value="OAB"/> <xs:enumeration value="OD"/> <xs:enumeration value="TA"/> <xs:enumeration value="TMC"/> <xs:enumeration value="TAB"/> <xs:enumeration value="TD"/> <xs:enumeration value="TAA"/> <xs:enumeration value="TFSA"/> <xs:enumeration value="TB"/> <!-- These are the non-call related events. If the --> <!-- PayloadType is "user-prof", then the value of the --> <!-- "name" attribute is one of these; example --> <!-- <spirits-event type="userprof" name="LUDV"> --> <xs:enumeration value="LUSV"/> <xs:enumeration value="LUDV"/> <xs:enumeration value="REG"/> <xs:enumeration value="UNREGMS"/> <xs:enumeration value="UNREGNTWK"/> </xs:restriction> </xs:simpleType>
<XS：単純型名= "EventNameType"> <！XS：制限ベース= "XS：文字列"> < - これらは、コール関連イベント（DPS）です。 > <！ - - > < - - PaylaodType「INDPs」、「名前」の、値である場合、属性は、これらの一つです！。例 - > <！ - <霊-イベントタイプ= "INDPs" 名前= "OCI"> - > <XS：列挙値= "OAA" /> <XS：列挙値= "OCI" /> <XS ：列挙値= "OAI" /> <XS：列挙値= "OA" /> <XS：列挙値= "OTS" /> <XS：列挙値= "ONA" /> <XS：列挙値= "OCPB "/> <XS：列挙値=" ORSF "/> <XS：列挙値=" OMC "/> <XS：列挙値=" OAB "/> <XS：列挙値=" OD "/> <XS：列挙値= "TA" /> <XS：列挙値= "TMC" /> <XS：列挙値= "タブ" /> <XS：列挙値= "TD" /> <XS：列挙値= "TAA" /> <XS：列挙値= "TFSA" /> <XS：列挙値= "TB" /> < - これらは、非呼関連イベントです！。もし - > < - > < - - PayloadTypeは、「ユーザー・教授」の、値である「name」属性は、これらの一つです！！。例 - > < - <霊 - イベントタイプ=名= "LUDV" "userprof"！> - > <XS：列挙値= "LUSV" /> <XS：列挙値= "LUDV" /> <XS ：列挙値= "REG" /> <XS：列挙値= "UNREGMS" /> <XS：列挙値= "UNREGNTWK" /> </ XS：制限> </ XS：simpleTypeの>
<xs:simpleType name="ModeType"> <!-- One of two values: "N"otification or "R"equest --> <xs:restriction base="xs:string">
<XS：単純名= "ModeType"> < - 2つの値の一つ： "N" otificationまたは "R" equest - > <XS：制限ベース= "XS：文字列">
<xs:enumeration value="N"/> <xs:enumeration value="R"/> </xs:restriction> </xs:simpleType>
<XS：列挙値= "N" /> <XS：列挙値= "R" /> </ XS：制限> </ XS：simpleTypeの>
<xs:simpleType name="CauseType"> <xs:restriction base="xs:string"> <xs:enumeration value="Busy"/> <xs:enumeration value="Unreachable"/> </xs:restriction> </xs:simpleType> </xs:schema>
<XS：単純型名= "CauseType"> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "ビジー" /> <XS：列挙値= "到達不能" /> </ XS：制限> </ XS：単純> </ XS：スキーマ>
The authors are grateful to participants in the SPIRITS WG for the discussion that contributed to this work. These include J-L. Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B. Chatras, O. Cleuziou, L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W. Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg, H. Sinnreich, L. Slutsman, D. Varney, and W. Zeuch. The authors also acknowledge Steve Bellovin, Allison Mankin and Jon Peterson for help provided on the Security section.
作者はこの仕事に貢献議論のためSPIRITS WGの参加者に感謝しています。これらは、J-Lが含まれます。バッカー、J. Bjorkner、J.ブラー、J-E。 Chapron、B. Chatras、O. Cleuziou、L.コンロイ、R.フォーブス、F. Haerens、J.ハンフリー、J.コジック、W.モンゴメリー、S. Nyckelgard、M. O'Doherty、A.ローチ、J.ローゼンバーグ、H. Sinnreich、L. Slutsman、D.バーニー、およびW. Zeuch。著者らはまた、セキュリティセクションで提供されるヘルプのためにスティーブBellovin氏、アリソンマンキンとジョン・ピーターソンを認めます。
ACL Access Control List CS Capability Set DP Detection Point DTD Document Type Definition EDP Event Detection Point EDP-N Event Detection Point "Notification" EDP-R Event Detection Point "Request" IANA Internet Assigned Numbers Authority ICW Internet Call Waiting IMSI International Mobile Subscriber Identity IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol ISP Internet Service Provider ITU International Telecommunications Union MIME Multipurpose Internet Mail Extensions MS Mobile Station (or Mobile Subscriber) OBCSM Originating Basic Call State Model PIC Point In Call PINT PSTN/Internet Interworking PSTN Public Switched Telephone Network SCF Service Control Function
ACLアクセス制御リストCS能力セットDP検出ポイントDTD文書型定義EDPイベント検出ポイントEDP-Nイベント検出ポイント「通知」EDP-Rイベント検出ポイント「要求」IANAインターネット割り当て番号機関ICWインターネットキャッチホンIMSI国際移動加入者識別コールPINT PSTN /インターネットのインターワーキングPSTNでOBCSM発信基本呼状態モデルPICポイントインテリジェントネットワークINAPインテリジェントネットワークアプリケーションプロトコルIPインターネットプロトコルISPインターネットサービスプロバイダITU国際電気通信連合MIME多目的インターネットメール拡張MS移動局（または移動電話加入者）は、公衆交換電話網SCFサービス制御機能
SCP Service Control Point SDP Session Description Protocol SIP Session Initiation Protocol SIP-T SIP for Telephones SPIRITS Services in the PSTN/IN Requesting InTernet Services SSF Service Switching Function SSP Service Switching Point STD State Transition Diagram TBCSM Terminating Basic Call State Model TDP Trigger Detection Point TDP-N Trigger Detection Point "Notification" TDP-R Trigger Detection Point "Request" TLS Transport Layer Security UA User Agent VLR Visitor Location Register WIN Wireless Intelligent Network XML Extensible Markup Language
PSTNにおける電話のSPIRITSサービスのSCPサービス制御ポイントSDPセッション記述プロトコルSIPセッション開始プロトコルSIP-T SIP /ポイントSTD状態遷移図TBCSM終端基本呼状態モデルTDPトリガ検出ポイントを切り替えインターネットサービスSSFサービス切替機能SSPサービスを要求する際にTDP-Nトリガー検出ポイント「通知」TDP-Rトリガー検出ポイント「要求」TLSトランスポート層セキュリティUAユーザエージェントVLRビジターロケーションレジスタWINワイヤレスインテリジェントネットワークXML拡張マークアップ言語
[1] Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The SPIRITS Architecture", RFC 3136, June 2001.
[1] Slutsman、L.、Faynberg、I.、陸、H.、およびM.ワイズマン、 "SPIRITSアーキテクチャ"、RFC 3136、2001年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[4] Faynberg, I., Gato, J., Lu, H., and L. Slutsman, "Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements", RFC 3298, August 2002.
[4] Faynberg、I.、ガトー、J.、陸、H.、およびL. Slutsmanを、RFC "公共の場でのサービスは、インターネットサービス（SPIRITS）プロトコル要件を要求する電話網/インテリジェントネットワーク（PSTN / IN）をスイッチ" 3298、2002年8月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[6] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F. Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection of IN parameters to be carried by the SPIRITS Protocol", Work In Progress, January 2003.
[6] M. Unmehopa、K. Vemuri、A. Brusilovsky、E. Dacloush、A.ザキ、F. Haerens、J-L。バッカー、B. Chatras、およびJ. Dobrowolski、進歩、2003年1月の作業「SPIRITSプロトコルによって運ばれるINパラメータの選択に」。
[7] Intelligent Network Capability Set 2. ITU-T, Recommendation Q.1228.
[7]インテリジェントネットワーク能力2 ITU-T、勧告Q.1228設定します。
[8] 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.
[8] 2000 Petrackと、S.とL.コンロイ、 "パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張"、RFC 2848、2000年6月を。
[9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[9]村田、M.、St.Laurent、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[10] Lu, H., 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.
[10]呂、H.、Faynberg、I.、Voelker、J.、ワイスマン、M.、チャン、W.、Rhim、S.、黄、J.、前、S.、Moeenuddin、S.、Hadvani、 S.、Nyckelgard、S.、ヨーカム、J.、およびL. ROBART、 "PSTN-開始サービスの事前スピリッツの実装"、RFC 2995、2000年11月。
[11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[11]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001. <http://www.w3c.org/XML/>.
[12]トンプソン、H.、ブナ、D.、マロニー、M.およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C REC REC-XMLSCHEMA-1から20010502、2001年5月<HTTP：// WWW .w3c.org / XML />。
[13] "Interface recommendations for intelligent network capability set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June 2000.
[13] "インテリジェントネットワーク機能のためのインターフェースの推奨セット3：SCF-SSFインタフェース"、ITU-T勧告Q.1238.2、2000年6月。
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[15]堀、R.、 "IETF文書のURN名前空間"、RFC 2648、1999年8月。
[16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[16] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in XML", W3C recommendation: xml-names, 14th January 1999, <http://www.w3.org/ TR/REC-xml-names>.
[17]ティム・ブレイ、デイブ・ホランダー、そしてアンドリュー素人、 "XMLで名前空間"、W3C勧告：XML-名、1999年1月14日、<http://www.w3.org/ TR / REC-XML-名>。
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[18] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services", McGraw-Hill, 1997.
[19] Faynberg、I.、L. Gabuzda、M.カプラン、およびN.Shah、 "インテリジェントネットワーク規格：サービスへの応用"、マグロウヒル、1997。
[20] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[20]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
ムーア、K.、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張」、RFC 2047、1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
解放された、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、BCP 13、RFC 2048、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
解放された、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
Kumar Vemuri Lucent Technologies, Inc. 2000 Naperville Rd. Naperville, IL 60566 USA
クマールVemuriルーセント・テクノロジーズ株式会社2000ネーパーヴィルRdを。ネーパーヴィル、IL 60566 USA
EMail: vvkumar@lucent.com
メールアドレス：vvkumar@lucent.com
Vijay K. Gurbani, Editor 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA
Viyay K. Gurbani、エディタ2000 Lutsentレーン前記Pindケトン誘導体-440 Napervile、IL 60566 USA
EMail: vkg@lucent.com
メールアドレス：vkg@lucent.com
Alec Brusilovsky 2601 Lucent Lane Lisle, IL 60532-3640 USA
アレックBrusilovsky 2601ルーセントレーンイリノイ州60532から3640 USA
EMail: abrusilovsky@lucent.com
メールアドレス：abrusilovsky@lucent.com
Igor Faynberg Lucent Technologies, Inc. 101 Crawfords Corner Rd. Holmdel, NJ 07733 USA
イゴールFaynbergルーセント・テクノロジーズ株式会社101 CrawfordsコーナーRdを。ホルムデル、NJ 07733 USA
EMail: faynberg@lucent.com
メールアドレス：faynberg@lucent.com
Jorge Gato Vodafone Espana Isabel Colbrand, 22 28050 Madrid Spain
ホルヘ・ガトーイザベルColbrandボーダフォンエスパーニャ、22 28050マドリードスペイン
EMail: jorge.gato@vodafone.com
メールアドレス：jorge.gato@vodafone.com
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
Musa Unmehopa Lucent Technologies, Inc. Larenseweg 50, Postbus 1168 1200 BD, Hilversum, The Netherlands
ムーサUnmehopaルーセント・テクノロジーズ株式会社Larenseweg 50、私書箱1168 1200 BD、ヴァーシュム、オランダ
EMail: unmehopa@lucent.com
メールアドレス：unmehopa@lucent.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。