[要約] RFC 3910は、PSTNからインターネットサービスを要求するためのSPIRITSプロトコルに関するものです。このRFCの目的は、PSTNとインターネットの間でのサービス要求と応答の相互運用性を提供することです。
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
スピリッツ（インターネットサービスを要求する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）The Internet Society（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プロトコルの目的は、CellularまたはWireline PSTNに由来するサービスをサポートし、PSTNとインターネット間の相互作用を必要とすることです。PSTN側では、Spiritsサービスはほとんどの場合、インテリジェントネットワーク（In）エンティティから開始されます。インターネットコールとインターネット発信者-ID配信は、セルラーネットワーク上のロケーションベースのサービスと同様に、スピリッツサービスの例です。プロトコルは、他の多くのサービスを構築できるビルディングブロックを定義します。
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.
以前のIETF作業は、PSTN/Internet Interworking（PINT）での作業により、インターネットからPSTNまでの逆方向に開始されたサービスをサポートするプロトコル（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椅子に応じて記述されています。他の貢献の中でも、このドキュメントは以下に基づいています。
o Informational "Pre-SPIRITS implementations" [10] o Informational "The SPIRITS Architecture" [1] o Informational "SPIRITS Protocol Requirements" [4]
o 情報「プリスピリットの実装」[10] o情報「スピリットアーキテクチャ」[1] o情報「スピリッツプロトコル要件」[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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：スピリッツ階層。
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 Architectureを以下に再現します。このドキュメントは、インターフェイス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：スピリッツアーキテクチャ。
(Note: The interfaces A-E are described in detail in the SPIRITS Architecture document [1].)
（注：インターフェイスA-Eは、Spirits Architecture Document [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は今日、インテリジェントネットワーク（IN）などのサービスモデルをサポートしています。これにより、一部の機能は、サービススイッチングポイント（SSP）と呼ばれるスイッチング要素でローカルに実行されます。その他の機能は、サービスコントロールポイント（SCPS）と呼ばれるサービス要素で実行されます。Spirits Architecture [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 Server」と「Spiritsクライアント」という用語は、役割が逆転しているように見えるので、やや混乱しています。WITに、「Spirits Server」は、「Spiritsクライアント」によって受け入れられるサブスクリプションを発行します。このような曖昧さを軽減するために、これからは「Spirits Server」を「Spirits Subscriber」と呼び、「Spiritsクライアント」を「Spirits Notifier」と呼びます。この条約は、[3]で概説されている命名法に準拠しています。図2のSpiritsサーバーはサブスクライバー（イベントへのサブスクリプションを発行）であり、図2のSpiritsクライアントはNotifierです（関心のあるイベントが発生する場合はいつでも通知を発行します）。
For ease of reference, we provide a terminology of the SPIRITS actors discussed in the preceding above:
参照のために、上記の前について議論された霊の俳優の用語を提供します。
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 Notifierを参照してください。
SPIRITS server: see SPIRITS subscriber.
Spirits Server：Spirits Subscriberを参照してください。
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 Notifier：PSTNのユーザーエージェント（UA）は、Spiritsの加入者からのサブスクリプションを受け入れます。これらのサブスクリプションには、Spiritsの加入者が通知を受信することに関心があるイベントが含まれています。Spirits Notifierは、当該イベントが発生したときに通知が関連する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 Subscriber：インターネット内のUAは、通知を受信することに関心があるPSTNのイベントを含むサブスクリプションを発行します。
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.
Spiritsプロトコルの要件は、「SIPプラクティスと一致する方法でスピリッツ関連のパラメーターが運ばれる」ことを義務付けています（RFC3298：セクション3）。SIPは、ヘッダー（コンテンツタイプ、コンテンツレングス）を使用して、ペイロードの説明機能を既に提供しています。このドキュメントでは、新しいMIMEタイプ「Application/Spirits-Event XML」を定義し、IANA（セクション7）で登録します。このMIMEタイプは、スピリッツリクエストと応答の「コンテンツタイプ」ヘッダーに存在する必要があり、スピリッツ関連の情報を含む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サブスクライバー（サブスクライブ、登録、または招待リクエストを発行できるスピリッツエンティティ）は、このスキーマをサポートする必要があります。すべてのスピリット通知者（サブスクライブ、登録、または招待リクエストを受け取って処理できるスピリットエンティティ）は、このスキーマをサポートする必要があります。スキーマはセクション9で定義されています。
The support for the SIP REGISTER request is included for PINT compatibility (RFC3298:Section 6).
SIPレジスタリクエストのサポートは、パイント互換性（RFC3298：セクション6）に含まれています。
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.
SIP Inviteリクエストのサポートは、既存のSpiritsの実装がSIPイベント通知スキームを使用しなかったため義務付けられています。代わりに、最初の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.
このドキュメントでは、イベントの通知のベースXMLスキーマも定義しています（セクション9）。すべてのSpirits Notifiersは、基本通知スキーマに対応する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オペレーターが異なる場合があります。一部のPSTNオペレーターには、サブスクライブできる豊富な一連のイベントがある場合がありますが、Spiritsプロトコル要件ドキュメント[4]で概説されている原始的なイベントセットのみを持っている人もいます。このドキュメントでは、サブスクリプションとプリミティブセットのイベントセットの通知に使用する必要があるベースXMLスキーマ（セクション9）を定義します。イベントサブスクリプションと通知のより豊富なセットをサポートするために、実装は、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 Notifierです。スピリットゲートウェイは、純粋なプロキシ機能を持っていると推定されるため、簡単にするために省略されています。
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ドキュメントインスタンスへの関心のあるイベント）5 ... 6 n-> s通知（リソース状態の変化の通知の通知;ペイロードはXML拡張機能をベース通知スキーマに使用してXMLドキュメントインスタンスです）7 s-> n 200 ok（notify）
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 Notifierは、ベース通知スキーマへの拡張機能を使用して、イベントの発生をSpiritsサブスクライバーに通知します。このドキュメントは、イベント通知の基本スキーマを定義していることに注意してください。Spirits Notifierはこれらを利用できた可能性があります。代わりに、ベース通知スキーマへの拡張で構成される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 Notifiers and 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
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.
<Spirits-Event>要素Spirits XMLドキュメントのルート（「Application/Spirits-Event XML」のコンテンツタイプのヘッダーで特徴）は、<Spirits-Event>要素です。この要素には、XMLドキュメントの基礎となる名前空間を示すために、名前空間宣言（ 'xmlns'）を含める必要があります。Spiritsプロトコルに準拠したXMLドキュメントには、urn "urn：ietf：params：xml：ns：spirits-1.0"が名前空間宣言に含まれている必要があります。必要に応じて、他の名前空間を指定することができます。
<spirits-event> element MUST contain at least one <Event> element, and MAY contain more than one.
<Spirits-Event>要素には、少なくとも1つの<Event>要素が含まれている必要があり、複数の要素が含まれている必要があります。
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".
<Event>要素<Event>要素には3つの属性が含まれており、そのうち2つが必須です。最初の必須属性は、値が「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.
2番目の必須属性は、「名前」属性です。この属性の値は、セクション5.2.1、セクション5.2.2、およびセクション6.1で定義されているスピリットに限定されなければなりません。
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".
オプションである3番目の属性は、「モード」属性です。「モード」の値は「n」または「r」のいずれかで、それぞれ（n）耳または（r）equest（RFC3298：セクション4）に対応します。この属性のデフォルト値は「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.
<Event>要素の「タイプ」属性が「indps」である場合、次の要素の少なくとも1つ以上を含める必要があります（未知の要素は無視される場合があります）：<CallingPartynumber>、<CallPartynumber>、<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.
<Event>要素の「タイプ」属性が「userprof」である場合、<callpartynumber>要素を含める必要があり、<Cell-ID>要素が含まれる場合があります。これらの要素には属性が含まれておらず、親要素としてさらに使用する必要はありません。これらの要素には、セクション6.1で説明されている文字列値が含まれています。他のすべての要素は、理解されていない場合は無視される場合があります。
A SPIRITS-compliant XML document using the XML namespace defined in this document might look like the following example:
このドキュメントで定義されているXML名空間を使用したSpirits Compliant 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>
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のサービスは、コールモデルに基づいて実行されます。コールモデルは、SSPSおよびその他のコール処理要素で使用される有限状態マシンであり、特定の時点でのコールの現在の状態を正確かつ簡潔に反映しています。呼び出しモデルは、写真と呼ばれる状態（コールのポイント）と州間の遷移で構成されています。状態間遷移は、検出ポイントまたはDPSと呼ばれる要素を通過します。DPSは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.
トリガーが発火すると、メッセージが通話状態情報でフォーマットされ、SSPからSCPに送信されます。次に、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.
検出ポイントは、TDP（またはトリガー検出ポイント）とEDP（またはイベント検出ポイント）の2つのタイプです。TDPは、静的な武装トリガー（サービス管理ツールを通じて武装）でプロビジョニングされます。EDPは動的に武装したトリガーです（コール処理が進行するため、SCPによって武装しています）。DPSは、「リクエスト」または「通知」DPSとして分類される場合があります。したがって、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がコール処理を停止する必要があります。応答が受信されると、コール処理が再開されます。「-N」タイプのDPは、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 IN機能セット（CS）-2 [7]呼び出しモデルが例として使用されており、説明を容易にするために、他のコールモデルは同様の特性を持っていることに注意してください。たとえば、ワイヤレスインテリジェントネットワーク（WIN）コールモデルは、トリガーの動的な武装もサポートしています。したがって、この議論の本質は、Wirelineドメインだけでなく、ワイヤレスドメインにも同様に適用されます。
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アーキテクチャをサポートする場合、INAPメッセージの内容をSpiritsプロトコルメッセージにエンコードできます。同様に、Spirits対応の要素から応答を受け取ると、応答コンテンツをINAP形式に再フォーマットし、これらのメッセージをSSPに転送できます。したがって、INAPパラメーターとスピリッツプロトコル間の相互変換および/またはエンコードのプロセスが主に関心を持っています。
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は、サービススイッチング関数（およびコールコントロール関数）の物理的症状です。このドキュメントでは、さまざまなスピリッツドラフト間の命名法の均一性をサポートするために、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プロトコルに関する関連する要件の概要を示しています。Spirits Notifierに到着する購読要求には、監視対象のイベント（DPリストの形式）、モード（要求または通知）が含まれている必要があります。違いは、リクエストの場合、Spiritsサブスクライバーが後続のコール処理に影響を与える可能性があり、通知のために、それ以上の影響は必要ありません）、および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では、スピリッツサービス用の機能セット3（CS-3）DPSのリストも列挙しています。SpiritsプロトコルがDPSの関連パラメーターを指定することは、要件（RFC3298：セクション4）です。これらのDPSおよびサブスクライブリクエストで携帯する関連パラメーターは、XMLスキーマで成文化されています。すべてのSpiritsの加入者は、PSTNのDPSに購読するためのこのスキーマを理解する必要があります。スキーマはセクション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通知リクエストを使用した通知がSpirits NotifierからSpiritsサブスクライバーに送信されます。Notifyリクエストには、起動したDPと関連するパラメーターを記述するXMLドキュメントが含まれています。Notifyリクエストで携帯するDPSとその関連パラメーターは、XMLスキーマで成文化されています。すべてのスピリット通知者は、このスキーマを理解する必要があります。このスキーマは拡張される場合があります。スキーマはセクション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 DPSの選択されたサブセットが含まれています。ただし、このドキュメントでは、[4]で概説されているCS-3 DPSのみを参照します。
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.
スピリッツサービス（RFC3298：セクション4）に想定されているCS-3 DPSについて説明します。DPSでは多くのパラメーターによって特徴付けられますが、そのようなすべてのパラメーターがスピリットによって必要である、あるいは必要であるとは限りません。したがって、このセクションでは、サブスクリプションと通知で指定する必要がある各DPの必須パラメーターをリストするのに役立ちます。実装では、プライベート（またはパブリックおよび標準化された）名前空間に関連付けられたXML拡張機能として追加のパラメーターを指定できます。
The exhaustive list of IN CS-3 DPs and their parameters can be found in reference [13].
CS-3 DPSとそのパラメーターの徹底的なリストは、参照[13]に記載されています。
Each DP is given a SPIRITS-specific mnemonic for use in the subscriptions and notifications.
各DPには、サブスクリプションと通知で使用するためのスピリット固有のニーモニックが与えられます。
Origination Attempt Authorized SPIRITS mnemonic: OAA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: 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.
オリジネーションの試み承認されたスピリッツニーモニック：subscribeのOAA必須パラメーター：通話パルティナンバーの必須パラメーターNotify：CallingPartynumber、CallingPartynumber 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.
Callpartynumber：呼び出されたパーティーを識別するために使用される番号（たとえば、ディレクトリ番号と呼ばれる番号など）を含む文字列。このパラメーターの実際の長さとエンコーディングは、使用されるダイヤル計画の詳細によって異なります。
Collected Information SPIRITS mnemonic: OCI Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
収集された情報スピリッツニーモニック：購読のOCI必須パラメーター：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
分析された情報スピリッツニーモニック：購読中のOAI必須パラメーター：通話パラティナンバルの必須パラメーターNotify：CallingPartynumber、DialledDigits
Origination Answer SPIRITS mnemonic: OA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
オリジネーション回答スピリッツニーモニック：subscribeの必須パラメーター：callingpartynumber通知の必須パラメーター：callingpartynumber、calkpartynumber
Origination Term Seized SPIRITS mnemonic: OTS Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
オリジネーション用語押収スピリッツニーモニック：subscribeの必須パラメーター：callingpartynumber通知の必須パラメーター：callingpartynumber、calkpartynumber
Origination No Answer SPIRITS mnemonic: ONA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination No nessn Spiritsニーモニック：subscribeの必須パラメーター：callingpartynumber通知の必須パラメーター：callingpartynumber、calkpartynumber
Origination Called Party Busy SPIRITS mnemonic: OCPB Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
パーティーと呼ばれる忙しいスピリッツニーモニック：ocpb subscribeの必須パラメーター：callingpartynumber notify：callingpartynumber、calkpartynumber
Route Select Failure SPIRITS mnemonic: ORSF Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber Origination Mid Call SPIRITS mnemonic: OMC Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
ルート選択障害スピリッツニーモニック：SubscribeのORSF必須パラメーター：CallingPartyNumber Notify：CallingPartynumber、CallingPartynumber、CallingPartynumber Mid Call Spirits Mnemonic：subscribeの必須パラメーター：notify：callingpartynumberの必須パラメーター
Origination Abandon SPIRITS mnemonic: OAB
オリジネーションはスピリットを放棄しましたニーモニック：OAB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
購読の必須パラメーター：CallingPartynumber Notify：CallingPartynumberの必須パラメーター
Origination Disconnect SPIRITS mnemonic: OD Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
オリジネーション切断スピリッツニーモニック：subscribeの必須パラメーター：callingpartynumber通知の必須パラメーター：callingpartynumber、calkpartynumber
Termination Answer SPIRITS mnemonic: TA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
終了回答スピリッツニーモニック：購読中の必須パラメーター：通話中の必須パラメーターNotify：CallingPartynumber、Callpartynumber
Termination No Answer SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
終了回答なしスピリッツニーモニック：購読中のTNA必須パラメーター：通話済みの必須パラメーターNotify：CallingPartynumber、calkpartynumber
Termination Mid-Call SPIRITS mnemonic: TMC Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
終了ミッドコールスピリッツニーモニック：TMCサブスクライブの必須パラメーター：callpartynumber通知の必須パラメーター：callpartynumber
Termination Abandon SPIRITS mnemonic: TAB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
終了放棄スピリッツニーモニック：タブサブスクライブの必須パラメーター：callpartynumber通知の必須パラメーター：callpartynumber
Termination Disconnect SPIRITS mnemonic: TD Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
終了切断スピリッツニーモニック：subscribeのtd必須パラメーター：callpartynumber通知の必須パラメーター：callpartynumber、callingpartynumber
Termination Attempt Authorized SPIRITS mnemonic: TAA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber Termination Facility Selected and Available SPIRITS mnemonic: TFSA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
終了試行承認されたスピリッツニーモニック：購読中のTAA必須パラメーター：通話中の必須パラメーター通知の必須パラメーター：コールパルティナンバル、コールパルタヌンバル終了施設選択および利用可能なスピリッツニーモニック：TFSA義務パラメーターfunm
Termination Busy SPIRITS mnemonic: TB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber, Cause
終了忙しいスピリッツニーモニック：サブスクライブのTB必須パラメーター：callpartynumber通知の必須パラメーター：callpartynumber、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).
原因：このパラメーターには、「ビジー」または「到達不能」の文字列値が含まれています。これらの違いは、要件として翻訳されています（RFC3298：セクション5）。スピリッツの加入者が、呼び出された当事者が実際に忙しい（従事している）か、呼び出された当事者が利用できないかどうかを判断するのを支援します（セルラー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]は、EDPS火災にトリガーされた場合に活用するための便利な手段です（[4]のセクション3を参照）。[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イベントパッケージにより、IPエンドポイント（またはホスト）がPSTNで発生するイベントのその後の通知をサブスクライブし、受信できます。図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）を識別するサブスクライブリクエストを発行します。このセットには、少なくとも1つのDPが含まれている必要があります。複数のDPが含まれている場合があります。購読要求は、認証が成功しているため、通知者にルーティングされます。
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.
イベントのセットで識別されたDPSのいずれかが発射されると、NotifierはNotifyリクエストをフォーマットし、サブスクライバーに向けます。Notifyリクエストには、トリガーされたイベントに関連する情報が含まれます。その後、発見されていないDPSは、スピリッツ通知者および/またはSCFによって明らかにされなければなりません。
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リクエストを介してサブスクライバーに渡されます。サブスクライバーが同じイベントの将来の発生に関心がある場合、新しいサブスクライブリクエストを発行し、新しいダイアログを確立する必要があります。
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つのイベントパッケージを定義しています。これらの最初はこのセクションで定義されており、「スピリットインド」と呼ばれます。このパッケージは、セルラーまたは有線PSTNの検出点に対応するイベントに使用する必要があります。Spiritsプロトコルと検出ポイントにサポートを実装するすべてのエンティティは、「イベント」要求ヘッダー[3]を「Spirits-Indps」に設定する必要があります。エンティティがスピリッツプロトコルを実装し、検出ポイントでサポートする場合、「Allow-Ivents」一般ヘッダー[3]には、トークン「Spirits-Indps」を含める必要があります。
Event: spirits-INDPs Allow-Events: spirits-INDPs
イベント：Spirits-Indps Allow-Events：Spirits-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.
「Spirits-Indps」イベントパッケージは、イベントヘッダーへの追加のパラメーターをサポートしていません。
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:
サブスクリプションを終了するのに役立つサブスクライブリクエストには、空のボディが含まれている場合があります。ただし、ダイアログを確立するサブスクライブリクエストには、3つの情報をコードする本体が含まれている必要があります。
(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つのサブスクライブリクエストで複数のDPをサブスクライブすることも、通知を受信することに関心のある各DPに対して異なるサブスクライブリクエストを発行する場合があります。プロトコルは両方の形式の表現を許可しますが、サービスがトリガーされているDPSのいずれかに依存する場合、DPSにサブスクライブする以前の方法を推奨します。
(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]、検出ポイントがリクエストまたは通知として設定されているかどうかを通知することで、「Spirits-Indps」パッケージのすべてのイベント（ただし、「Spirits-User-Prof」パッケージでは必要ありません）が必要です。「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) イベント検出ポイントに関連付けられたパラメーターの値のリスト（注：「イベント」は、使用法を指します - 動的に武装した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.
スピリッツのサブスクライブのデフォルトのボディタイプは、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).
パッケージ「Spirits-Indps」の場合、購読要求の目的はDPを武装することです。DPは、静的に（たとえば、サービスプロビジョニングを介して）、または動的に（SCFによる）武装している可能性があります。静的に武装した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は、対象のイベントが通信器で発生すると自動的に武装解除されます。それが望むなら、コールのコンテキスト内でDPSを再装うのはサブスクライバー次第です。
Statically armed DPs are considered outside the scope of the SPIRITS protocol requirements [4] and thus will not be considered any further.
静的に武装したDPは、スピリッツプロトコル要件の範囲外[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:
「Spirits-Indps」パッケージの通知リクエストを通知するボディはオプションです。存在する場合、それらは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が生成されたイベント（通常、常にではありませんが、これは対応するサブスクライブリクエストに存在するのと同じイベントになります）。
(2) The "mode" parameter; it is simply reflected back from the corresponding SUBSCRIBE request.
(2) 「モード」パラメーター。対応するサブスクライブリクエストから単純に反映されます。
(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.
サブスクライバーが単一の購読要求の一部として複数のDPを武装した場合、同じサブスクライブダイアログの一部であったすべての発見されていないDPは、Spirits Notifierおよび/または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.
通知者がサブスクライブリクエストを受信した場合、リクエストを認証し、サブスクライバーが特定の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.
購読要求が認証され、承認されたら、監視機インターフェイスはインターフェイスDを介してSCFをインターフェースして、購読本体に含まれる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ミリ秒以上かかることを期待している場合、サブスクリプションを受け入れて、サブスクライブリクエストに202の応答をすぐに送信する必要があります。その後、空のボディを使用して通知リクエストを送信する必要があります。この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".
サブスクライブリクエストで特定された関心のあるイベントが発生した場合、Notifierはボディを含む必要がある新しいNotifyリクエストを送信します（セクション5.3.6を参照）。Notifyリクエストには「サブスクリプションステート」ヘッダーが必要であり、その値は「Fireed」の理由で「終了」するように設定する必要があります。
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.
通知要求を取得したときにサブスクライバーで実行された正確な手順は、実装されているサービスに依存します。一般性として、サブスクライバーに関連付けられている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リクエストに、「終了」の値と「fired」の理由を持つ「サブスクリプション状態」ヘッダーが含まれている場合、サブスクライバーに関連付けられた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.
既存のサブスクリプションが期限切れになったときに新しいサブスクリプションを開始するかどうかは、実装されているサービスのコンテキストにまで及びます。たとえば、ユーザーは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.
購読リクエストの要塞は禁止されています。購読要求はPSTNを対象とするため、要求がフォークを許可されている場合、非常に不規則な動作が発生します。通常のSIP DNSルールとルーティングルール[11]は、正確に1つの要素というターゲットセットになります。
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.
ネットワークトラフィック以上のセキュリティの理由により、notifierは2つまたは最大3つのサブスクリプションのリクエストを発行することをお勧めします。サブスクリプションが202の応答で受け入れられた場合、通知はすぐにサブスクライバーに送信されます。この通知は、リクエストが受け入れられ、行動されていることを加入者に通知するのに役立ちます。
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.
サブスクライブリクエストで識別されたリソース（検出ポイント）が初期化されたら、監視員は2番目の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.
購読要求で特定された検出ポイントに関連付けられたトリガーの発火につながる関心のあるイベントが発生すると、最終通知がサブスクライバーに送信されます。この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回の応答で受け入れられた場合、Notifierは2つのNotifyリクエストを送信します。1つはリソースの基本状態を含むもの、もう1つは検出ポイントの発火につながる情報を含む情報を含むものです。
State agents are not used in 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:
このセクションには、Internet Caller-ID配信（ICID）と呼ばれるスピリッツサービスのコールフローの例が含まれています。[1]のセクション2.2で説明されているように、ベンチマークスピリッツサービスの1つは、インターネット発信者-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.
このサービスにより、サブスクライバーは、インターネットに接続している間に発信者の番号または名前、またはその両方を確認できます。サブスクライバーが1つの電話回線しか持っておらず、インターネット接続にそのまさに行を使用している場合、サービスは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.
このサービスを実現するために、スピリットコールフローの例を提示します。これは、インターネットCaller-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に記載されているコールフローを参照してください。図3は、あらゆるスピリッツサービスの不可欠な部分である4つのエンティティを示しています（エンティティの見出しは、[1の図1に確立された名前を参照しています。]） - Spiritsの加入者、Spirits Notifier、およびSCF。Spirits Gatewayはこの図に含まれていないことに注意してください。論理的には、SpiritsメッセージがSpirits Serverと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からF8でキャプチャされます。ユーザーは（F1）DPに関連するゼロパラメーターとともに関心のあるDPを識別するSIPサブスクライブリクエストを送信します（この例、Termination_attempt_dpが採用されます）。Spirits Notifierは順番にSCFと対話して、サービスのTermination_attempt_dpを武装させます（F2）。現在の状態情報を備えた即時通知は、サブスクライバー（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はユーザー電話に電話をかけます。SSFは、このイベントが武装ターミネーション_AttEmpt_DPに遭遇したときにSCFに通知します（図3には示されていません）。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.
Spirits Notifierがこのイベントを受け取ると、SIP Notifyリクエストを形成し、Spiritsサブスクライバー（F7）に誘導します。この通知には、サブスクライバーに発信者を識別するために必要なすべての情報要素が含まれます。サブスクライバーは、通知（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 Gatewayがこの例の目的のために、通知者のデフォルトのアウトバウンドプロキシとして機能するSIPプロキシであると想定しています。サブスクライバーのMyProvider.comドメインのIngressホスト。サブスクライバーと通知者は、別々の管理ドメインにある場合があります。
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: ...
<?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>
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（この場合はTAA DP）とDPが武装している実際のライン（この場合、電話番号6302240216に関連付けられているライン）を識別するSIPサブスクライブリクエストを形成します。。このリクエストは、最終的にSiprits Notifier 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
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:
NotifierはSCFと対話してDPを武装させ、通知の現在の状態をサブスクライバーに通知するサブスクライバーに即座に通知を送信します。
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
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 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:
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/udpgateway.myprovider.com; branch = z9hg4bk-9 $ 0-1 via：sip/2.0/udp notifier.myprovider.com; branch = z9hg4bkqo--9 call-id：3329as77@host.example.com連絡先：<sip：vkg：vkg：<sip：vkg@host.example.com> cseq：3299通知承認：アプリケーション/スピリット - イベントXMLコンテンツレングス：0後の時点で（F1で確立されたサブスクリプションが通知者で期限切れになる前）、識別された番号に通話が届きますF1-6302240216のXMLエンコード本文で。SCFは通信因子（F6）に通知します。この通知には、PSTNからの関連情報、すなわち6302240216に電話しようとする当事者の電話番号が含まれています。通知者は、この情報を使用してSIP Notifyリクエストを作成し、サブスクライバーに送信します。SIP Notifyリクエストには、PSTNからの関連情報を含むXMLエンコードボディがあります。
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: ...
<?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>
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 Notifierに渡された情報が含まれています。この特定の例では、これは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を呼び出す別の試みの通知を取得したい場合、彼/彼女は新しいサブスクライブリクエストを通知者に送信する必要があります。
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で通知を受け取ったときに適切なアクションを実行できます。合理的な実装では、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
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.
「Spirits-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 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.
セクション5.1で、SSFとSCFの間に既存の制御関係がないため、コール処理中に発火する最初のトリガーは通常TDPであると述べました。一部のインターネットホストは、TDPSに基づいてサービスの実行に関心を示している可能性があります（この仕様の一部ではないA-Priori配置を通じて）。したがって、PSTNはそのようなホストに通知します。そのためには、インターネットホストにSIPリクエスト（通常は招待状）を送信します。SIPリクエストの本体には、2つのMIMEコンポーネントを備えたマルチパートMIMEを含める必要があります。リクエストの通常のペイロードに対応する最初の部分。また、2番目の部分には、スピリット固有の情報（たとえば、解雇されたDP）が含まれます。招待リクエストへの応答、または現在のコールコンテキスト内でインターネットホストからPSTNへのその後のサブスクライブメッセージは、EDPが武装する可能性があります。
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.
ベンチマークスピリッツサービスとしてのICWは、実際にスピリッツよりも前のものです。ICWのスピリット前の実装については、[10]で詳しく説明しています。ただし、ドキュメントが指摘しているように、実装の多様性が存在しますが、これらの実装は相互運用できません。当時[10]が公開されていたため、現在のように、業界はSIPの経験の深さを持っていませんでした。[10]でのSIPの使用は、[5]で説明されているように、SIPの規範的使用を構成するものではありません。たとえば、最初の招待でのSDP（もしあれば）については言及されていません（特に、これは「VoIPを使用してコールを受け入れる」ケースに関係しているため）。したがって、このセクションは、スピリッツにおける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ラインを介したコールを受け入れ、インターネット（モデム）接続を終了する
2. Accepting the call over the Internet using Voice over IP (VoIP)
2. Voice Over IP（VoIP）を使用してインターネット経由でコールを受け入れる
3. Rejecting the call
3. コールを拒否します
4. Playing a pre-recorded message to the calling party and disconnecting the call
4. 事前に録音されたメッセージを呼び出しパーティーに再生し、電話を切断する
5. Forwarding the call to voice mail 6. Forwarding the call to another number
5. コールをボイスメールに転送する6.通話を別の番号に転送する
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:
SCPがサブスクライバーラインがインターネットセッションに使用されているという事実をSCPに認識させない限り、ICWはスピリッツサービスとしてのICWが不可能であることを完全性のために指摘する必要があります。ただし、その認識は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サブスクライバーベースの方法：サブスクライバーのPC上のICWクライアントは、SIPレジスタリクエストを発行することにより、インターネットセッションの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）アクセス番号のリストを維持します。これらの数字の1つがダイヤルされて接続されると、IT（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はコールの処理を一時停止し、スピリッツ対応SCPにリクエストを送信します。SCPは、サブスクライバーラインがインターネットセッションに使用されていると判断します。SCPのSpirits Notifierに、SIP Inviteリクエストを作成し、サブスクライバーのIPホストで実行されている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でカタログされている可能性のあるコール処分結果の1つを返す必要があります。結果1および4〜7はすべて1つのケースに合体することができることに注意してください。つまり、代替SIP URIへの呼び出しをリダイレクト（SIP 3XX応答コードを使用して）。1の場合、リダイレクトコールのURIは、オンラインになるために顧客が使用しているまったく同じ数と一致する必要があります。コールを拒否することは、非2XXおよび非3XX最終応答を送信することを意味します。残りの結果は、コールが目的のサービスを提供する代替URIにリダイレクトされます（つまり、事前に記録されたアナウンスを再生するか、音声メッセージを記録します）。
Further processing of a SPIRITS notifier when it receives a final response can be summarized by the following steps:
最終的な応答を受け取ったときにスピリット通知者のさらなる処理は、次の手順で要約できます。
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.
1. 応答が4xx、5xx、または6xxクラスの応答である場合、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.
2a。比較が一致を示した場合、SSPにスピリッツのサブスクライバーがモデムを切断できるように十分な時間を費やすように指示し、ラインを解放します。次に、通常のコール処理を続行し、サブスクライバーの電話が鳴ります。
2b. If the comparison fails, instruct the SSP to route the call to the redirected URI.
2b。比較が失敗した場合は、SSPにリダイレクトURIへのコールをルーティングするよう指示します。
3. Else, for a 2xx response, follow the steps in section 5.4.3.
3. それ以外の場合、2xx応答の場合、セクション5.4.3の手順に従ってください。
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の1つの通話処理オプションは、「VOIPを使用して着信コールを受け入れる」ことです。Spirits Notifierには、加入者（Callee）がこのオプションを選択する場合、A-Prioriを知る方法はありません。それにもかかわらず、Inviteリクエストの本文にSDPを追加することにより、そのような選択を考慮する必要があります。これを達成する可能性のある方法は、Spirits NotifierにPSTNゲートウェイを制御し、適切なリソースを割り当てることです。これが完了すると、Spirits Notifierはネットワーク情報（メディアが受信されるゲートウェイ番号のIPアドレスとポート番号）と、招待リクエストのボディのSDP部分としてコーデック情報を追加します。スピリッツでは、DP情報をリクエスト本体にも携帯する必要があります。その程度まで、Spirits Notifierは、サービスをトリガーしたTDPに関連付けられた情報も追加する必要があります。したがって、招待の本体には、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:
Spirits Notifierは、招待リクエストをサブスクライバーに送信し、最終的な応答を待ちます。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を受信すると、Spirits NotifierはSSPにゲートウェイの事前に割り当てられたポートでコールを終了するように指示します。このポートは、以前の招待で送信されたSDPへのゲートウェイによって相関する必要があります。
The end result is that the caller and callee hold a voice session with part of the session occurring over VoIP.
最終的な結果は、発信者とCalleeが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)):
音声通話のセットアップ、維持、または取り外しに関連しないネットワークイベントがあります。このようなイベントは、Cellular Wireless Networkで発生し、Spiritsがサービスを提供するために使用できます。Spirits Protocol要件には、Spirits通知が必要な以下のイベントが明示的に含まれています（RFC3298：セクション5（b））：
1. Location update in the same Visitor Location Register (VLR) service area
1. 同じVisitor Location Register（VLR）サービスエリアでの場所の更新
2. Location update in another VLR service area
2. 別のVLRサービスエリアでの場所の更新
3. International Mobile Subscriber Identity (IMSI) attach
3. 国際的なモバイル加入者ID（IMSI）添付
4. Mobile Subscriber (MS) initiated IMSI detach
4. モバイルサブスクライバー（MS）はIMSIデタッチを開始しました
5. Network initiated IMSI detach
5. ネットワークはIMSIデタッチを開始しました
Each of the five non-call related event is given a SPIRITS-specific mnemonic for use in subscriptions and notifications.
5つの非コール関連のイベントには、サブスクリプションと通知で使用するためのスピリッツ固有のニーモニックが与えられます。
Location update in the same VLR area SPIRITS mnemonic: LUSV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
同じVLRエリアでのロケーション更新スピリッツニーモニック：rusv subscribeの必須パラメーター：callpartynumber通知の必須パラメーター：callpartynumber、cell-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.
Cell-ID：サービングセルIDを識別するために使用される文字列。このパラメーターの実際の長さと表現は、セルラープロバイダーのネットワークの詳細に依存します。
Location update in different VLR area SPIRITS mnemonic: LUDV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
さまざまなVLRエリアスピリッツニーモニックのロケーション更新：subscribeのludv必須パラメーター：callpartynumber通知の必須パラメーター：Callpartynumber、cell-id
IMSI attach SPIRITS mnemonic: REG Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID MS initiated IMSI detach SPIRITS mnemonic: UNREGMS Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
IMSIアタッチスピリッツニーモニック：サブスクライブのregantorationパラメーター：callpartynumber notify：callpartynumber、call-id ms開始IMSIデタッチスピリッツMnemonic：subscribeの必須パラメーター：callpartynumber必須パラメーター：通知
Network initiated IMSI detach SPIRITS mnemonic: UNREGNTWK Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
ネットワークが開始されたIMSI DETACH SPIRITS MNEMONIN：UNREGNTWK SUNTORATION PARAMETER in SUBSCRIBE：CallPartYnumber Notify：CallpartYnumberの必須パラメーター
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イベントのセットを識別するサブスクライブリクエストを発行します。このセットには、正確に1つのイベントが含まれる場合があります。または、複数のイベントが含まれている場合があります。購読要求は、認証が成功しているため、受け入れられる通知者にルーティングされます。
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.
セットで識別されたイベントが発生すると、NotifierはNotifyリクエストをフォーマットし、サブスクライバーに向けます。Notifyリクエストには、通知が要求されたイベントの1つに関連する情報が含まれます。
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.
購読によって確立されたダイアログは、正常に期限切れになるまで持続するか、サブスクライバーによって明示的に期限切れになります。この動作は、「Spirits-Indps」パッケージに関連するサブスクリプションの動作とは異なります。セルラーネットワークでは、サブスクライブされるイベントは、Wirelineネットワークと比較して、それよりもはるかに大きな頻度で発生する可能性があります（セルラーユーザーが動き回るときの場所の更新を検討してください）。したがって、サブスクリプションが正常に期限切れになるようにすることは、はるかに適切です。
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で定義されました。このセクションで定義されている2番目のパッケージは、「Spirits-User-Prof」と呼ばれます。このパッケージは、セルラーネットワーク内の非コール関連イベントに対応するイベントに使用する必要があります。Spiritsプロトコルを実装し、Spiritsプロトコル要件（RFC3298：セクション5（b））で概説されている非コール関連のイベントをサポートするすべてのエンティティは、「イベント」ヘッダー要求ヘッダー[3]を「Spirits-User-Prof」に設定する必要があります。「「Allow-Events」一般ヘッダー[3]には、トークン「スピリットユーザープロフ」も含める必要があります。
Example:
例：
Event: spirits-user-prof Allow-Events: spirits-user-prof, spirits-INDPs
イベント：Spirits-User-Prof Allow-Events：Spirits-User-Prof、Spirits-Indps
The "spirits-user-prof" event package does not support any additional parameters to the Event header
「Spirits-User-Prof」イベントパッケージは、イベントヘッダーへの追加のパラメーターをサポートしていません
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:
サブスクリプションを終了するのに役立つサブスクライブリクエストには、空のボディが含まれている場合があります。ただし、ダイアログを確立するサブスクライブリクエストには、2つの情報をコードする本体が含まれている必要があります。
(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つのサブスクライブリクエストで複数のイベントを購読することも、通知を受信することに関心のある各イベントの異なるサブスクライブリクエストを発行する場合があります。プロトコルは、両方の形式の表現を許可します。ただし、複数のイベントを購読するために1つのサブスクライブを使用している場合、そのサブスクリプションに関連付けられたダイアログの有効期限は、そのようなすべてのイベントに影響することに注意してください。
(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.
スピリッツのサブスクライブのデフォルトのボディタイプは、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].
サブスクライブリクエストによって確立されたダイアログの期間は、ダイアログが確立されたときにサブスクライバーと通知者の間で交渉された有効期限に限定されます。サブスクライバーは、ダイアログを生き続けることに興味がある場合は、新しいサブスクライブを送信する必要があります。[3]で概説されているように、「有効期限が0の「有効」ヘッダー値がある新しいサブスクライブリクエストを送信することにより、ダイアログを終了できます。
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:
「Spirits-User-Prof」パッケージの通知リクエストの団体はオプションです。存在する場合、それらは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が生成されたイベント（通常、常にではありませんが、これは対応するサブスクライブリクエストに存在するのと同じイベントになります）。
(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.
通知者が購読要求を受信した場合、リクエストを認証し、サブスクライバーが携帯電話のためにサブスクライブされているリソースにアクセスすることを許可されていることを確認する必要があります。
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.
購読要求が認証され、承認されたら、監視機インターフェイスはインターフェイスDを介してSCFをインターフェースし、サブスクライブ本体に含まれる携帯電話番号に対応する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ミリ秒以上かかると予想している場合、サブスクリプションを受け入れて、サブスクライブリクエストに202の応答をすぐに送信する必要があります。その後、空のボディを使用して通知リクエストを送信する必要があります。この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." 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.
通知者がSCFとのインターフェースに正常に形成されると、空のボディと「アクティブ」の値を持つ「サブスクリプション状態」ヘッダーを使用して後続のNotifyリクエストを送信する必要があります。サブスクライブリクエストで特定された関心のあるイベントが発生した場合、通知者はセクション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.
通知要求を受信したときにサブスクライバーで実行された正確な手順は、実装されているサービスの性質に依存します。一般性として、サブスクライバーに関連付けられている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.
購読リクエストの要塞は禁止されています。購読要求はPSTNを対象とするため、要求がフォークを許可されている場合、非常に不規則な動作が発生します。通常のSIP DNSルールとルーティングルール[11]は、正確に1つの要素というターゲットセットになります。
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.
混雑制御の理由により、通知率が過剰にならないことが重要です。たとえば、サブスクライバーが、十分な速度でセルラーネットワークを通過する通知者のロケーション更新イベントを購読している場合、通知者が小さな時間枠で多くの通知要求を生成する可能性があることは完全に考えられます。したがって、このパッケージ内では、ロケーションアップデートイベントには適切なスロットリングメカニズムが必要です。
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 NotifierがロケーションアップデートNotifyを送信するたびに、15秒の値でタイマー（TN）を起動する必要があります。後続の場所の更新で、タイマーが切れる前に通知リクエストを送信する必要がある場合は、破棄する必要があります。将来のロケーション更新通知リクエストは、TNの有効期限が切れた場合にのみ送信する必要があります（つまり、最後のNotifyリクエストが送信されてから15秒が通過しました）。場所の更新通知が送信された場合、15秒で再びオフにするためにTNをリセットする必要があります。
State agents are not used in 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.
このセクションには、モバイルユーザーの存在状態を更新するために使用できるスピリッツサービスの例が含まれています。コールフローを以下の図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: ...
<?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>
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
The notifier also sends out a NOTIFY request confirming the subscription:
また、notifierは、サブスクリプションを確認する通知リクエストを送信します。
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
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
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
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通知リクエストはサブスクライバーに送信されます。
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: ...
<?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>
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
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」に関連付けられたユーザーの存在状態を「オン」に変えるサブスクライバーで構成されている場合があります。また、F7では、通知者に通知にセルIDが含まれていることに注意してください。
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.
「Spirits-User-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 [3]ごとに2つの新しいSIPイベントパッケージを登録します。
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
パッケージ名：Spirits-Indps
Type: package
タイプ：パッケージ
Contact: Vijay K. Gurbani, vkg@lucent.com
連絡先：Vijay K. Gurbani、vkg@lucent.com
Reference: RFC 3910
参照：RFC 3910
Package Name: spirits-user-prof
パッケージ名：Spirits-User-Prof
Type: package
タイプ：パッケージ
Contact: Vijay K. Gurbani, vkg@lucent.com
連絡先：Vijay K. Gurbani、vkg@lucent.com
Reference: RFC 3910
参照：RFC 3910
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: spirits-event+xml
MIMEサブタイプ名：Spirits-Event XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset (same semantics of charset parameter in application/xml [9])
オプションのパラメーター：charset（アプリケーション/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.
このメディアタイプを使用するアプリケーション：このドキュメントを順守するスピリット認識エンティティ。
Additional information:
追加情報：
Magic number(s): none.
マジックナンバー：なし。
File extension(s): none.
ファイル拡張子：なし。
Macintosh file type code(s): none.
Macintoshファイルタイプコード：なし。
Object Identifier(s) or OID(s): none.
オブジェクト識別子またはoid（s）：なし。
Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com>
Intended usage: Common
意図された使用法：共通
Author/Change controller: The IETF
著者/変更コントローラー：IETF
URI
urn:ietf:params:xml:ns:spirits-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」コンテンツタイプのスピリット情報を説明しています。
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>
<h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
</body>
</html>
END
URI
urn:ietf:params:xml:schema:spirits-1.0
Description XML base schema for SPIRITS entities.
説明スピリッツエンティティ用の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.
このセクションでは、スピリットに固有のセキュリティに関する考慮事項に焦点を当てています。SIPセキュリティメカニズムについては、コアSIP仕様[5]で詳細に説明し、このドキュメントの範囲外です。スピリッツのセキュリティメカニズムは、SIPセキュリティに基づいて強化されています[5]。たとえば、Spiritsは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 [4]の第9章（セキュリティ検討）で概説されているように、次のセキュリティの側面は、スピリッツプロトコルに適用されます。
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のスピリッツアーキテクチャには、A、B、C、D、およびEの5つのインターフェイスが含まれています。これらのうち、2つのBとCのみがスピリッツにとって興味深いものです。インターフェイスAとEはパイントインターフェイスであるため、パイントRFC [8]によって保護されていると想定されています。インターフェイスDのセキュリティは、主にPSTNインフラストラクチャを扱っているため、このドキュメントでは範囲外です。特定の仮定に基づいたインターフェイス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 Securityの運転の仮定は、Spirits GatewayがSpirits Notifierを所有する同じPSTNオペレーターが所有していることです。したがって、インターフェイスCのセキュリティをPSTN演算子に単純に委ねることは魅力的であり、実際、インターフェイスCがIPネットワークとPSTN境界を越えているため、まさにそれを行うメリットがあります。ただし、詳細な検査により、両方のインターフェイスBとCがスピリッツプロトコルを送信することが明らかになりました。したがって、インターフェイスBに到達したセキュリティの取り決めは、インターフェイスCにも適切に適用できます。これにより、Spirits GatewayがSpirits Notifierを所有する同じ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 Notifier（および逆）に直接通信していることを前提としており、この取り決めのセキュリティ装置を指定しています。ただし、同じ装置を使用して、Spiritsの加入者と仲介者（Spirits Gatewayなど）と同じ仲介者とSpirits Notifierの間のコミュニケーションを確保することができます。
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プロトコルの機密性は不可欠です。プロトコルデータユニットに掲載されている情報は繊細な性質であり、非許可当事者に明らかにされた場合、プライバシーの懸念につながる可能性があります。Spirits NotifierとSpiritsサブスクライバーの間の通信パスは、S/Mime [18]を通じて確保する必要があります。
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は、オープンネットワークを介したトランジットのためにスピリット体を暗号化するエンドツーエンドのセキュリティメカニズムです。仲介者は、メッセージをルーティングするために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は、このセクションの冒頭で概説されているスピリットのすべてのセキュリティ側面を提供します：認証、メッセージの整合性、機密性、および非控除。S/MIMEが提供する認証プロパティは、スピリッツメッセージの受信者に、スピリットペイロードが認定エンティティによって生成されるようにすることができます。暗号化は、特定の復号化キーを所有するスピリットエンティティのみが、SIPリクエストでカプセル化されたスピリット体を検査できることを保証します。
All SPIRITS endpoints MUST support S/MIME signatures (CMS SignedData) and MUST support encryption (CMS EnvelopedData).
すべてのスピリッツエンドポイントは、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オペレーターが所有している場合、スピリッツエンドポイントにパブリックキーがインストールされる可能性があります。
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.
S/MIMEは、署名を検証するために必要な公開鍵を命名するという2つの方法の2つの方法をサポートしています。これらの間では、subjectKeyidentifierはx.509証明書やその他のスキームでも動作しますが、発行者はX.509証明書のみで動作します。管理者が必要なパブリックキーを構成し、手続き的な手順を通じて整合性を提供する場合、X.509証明書なしでS/MIMEを使用できます。
All requests (and responses) between SPIRITS entities MUST be encrypted.
スピリッツエンティティ間のすべての要求（および応答）は暗号化する必要があります。
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 Notifierはリクエストを認証する必要があります。Spiritsサブスクライバーからのサブスクリプション（または登録）は、認証が失敗した場合に拒否する必要があります。SpiritsのサブスクライバーがSpirits Notifierに正常に認証された場合、Spirits Notifierは少なくとも、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 Notifierがこれをどのように達成するかを禁止していないことに注意してください。実際には、PSTNのサービス管理システムによって入力されるアクセス制御リスト（ACL）、またはある種のWebインターフェイスを介して可能です。
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 Notifierから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で指定されています。このセクションでは、スピリッツペイロードを構成するドキュメントのベースXMLスキーマを定義します。MIMEタイプ「アプリケーション/スピリットイベントXML」によって特徴付けられるペイロードを輸送するすべてのスピリッツエンティティは、以下の基本スキーマに対応するドキュメントをサポートする必要があります。
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.
ベーススキーマの複数のバージョンは予想されていません。むしろ、新しいXMLネームスペースと対応するスキーマの定義を通じて、追加の機能（たとえば、新しいPSTNイベントを伝える）を実現する必要があります。新しい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">
<!-- 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:element name="spirits-event" type="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 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: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: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:simpleType name="ModeType">
<!-- One of two values: "N"otification or "R"equest -->
<xs:restriction base="xs:string">
<xs:enumeration value="N"/>
<xs:enumeration value="R"/>
</xs:restriction>
</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>
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が含まれます。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、およびW. Zeuch。著者はまた、セキュリティセクションで提供された助けを求めて、Steve Bellovin、Allison Mankin、Jon Petersonを認めています。
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
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
[1] Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The SPIRITS Architecture", RFC 3136, June 2001.
[1] Slutsman、L.、Faynberg、I.、Lu、H。、およびM. Weissman、「The Spirits Architecture」、RFC 3136、2001年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach、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.、Gato、J.、Lu、H。、およびL. Slutsman、「公開された電話ネットワーク/インテリジェントネットワーク（PSTN/IN）のインターネットサービス（SPIRITS）プロトコル要件の要求」、RFC 3298、8月2002年。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、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。Zaki、F。Haerens、J-L。Bakker、B。Chatras、およびJ. Dobrowolskiは、「Spirits Protocolによって運ばれるパラメーターの選択について」、2003年1月の進行中の作業。
[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] Petrack、S。and L. Conroy、「The Pint Service Protocol：SIPおよびSDPへの拡張電話への電話サービスへのアクセスのためのSDP」、RFC 2848、2000年6月。
[9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[9] Murata、M.、St.Laurent、S。、およびD. Kohn、「XML Media Types」、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] Lu、H.、Faynberg、I.、Voelker、J.、Weissman、M.、Zhang、W.、Rhim、S.、Hwang、J.、Ago、S.、Moeenuddin、S.、Hadvani、S.、Nyckelgard、S.、Yoakum、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] Rosenberg、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-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] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[15] Moats、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-Names、1999年1月14日、<http://www.w3.org/ tr/rec-xml-names>。
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[18] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（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。Kaplan、およびN.shah、「インテリジェントネットワーク標準：サービスへの適用」、McGraw-Hill、1997。
[20] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[20] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCII以外のテキストのメッセージヘッダー拡張機能」、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.
Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、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.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
Kumar Vemuri Lucent Technologies, Inc. 2000 Naperville Rd. Naperville, IL 60566 USA
Kumar Vemuri Lucent Technologies、Inc。2000 Naperville Rd。イリノイ州ネーパービル60566 USA
EMail: vvkumar@lucent.com
Vijay K. Gurbani, Editor 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA
Vijay K. Gurbani、編集者2000 Lucent Lane RM 6G-440 Naperville、IL 60566 USA
EMail: vkg@lucent.com
Alec Brusilovsky 2601 Lucent Lane Lisle, IL 60532-3640 USA
ALEC BRUSILOVSKY 2601 LUCENT LANE LIRLE、IL 60532-3640 USA
EMail: abrusilovsky@lucent.com
Igor Faynberg
Lucent Technologies, Inc.
101 Crawfords Corner Rd.
Holmdel, NJ 07733
USA
EMail: faynberg@lucent.com
Jorge Gato Vodafone Espana Isabel Colbrand, 22 28050 Madrid Spain
ホルヘ・ガト・ボーダフォン・エスパナ・イザベル・コルブランド、22 28050マドリードスペイン
EMail: jorge.gato@vodafone.com
Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A、101 Crawfords Corner Road Holmdel、ニュージャージー、07733
Phone: (732) 949-0321 EMail: huilanlu@lucent.com
電話：（732）949-0321メール：huilanlu@lucent.com
Musa Unmehopa Lucent Technologies, Inc. Larenseweg 50, Postbus 1168 1200 BD, Hilversum, The Netherlands
Musa Unmehopa Lucent Technologies、Inc。Larenseweg 50、Postbus 1168 1200 BD、Hilversum、オランダ
EMail: unmehopa@lucent.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。