RFC3910 日本語訳
3910 The SPIRITS (Services in PSTN requesting Internet Services)Protocol. V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H.Lu, M. Unmehopa. October 2004. (Format: TXT=110515 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループV.Gurbani、エドをネットワークでつないでください。コメントのために以下を要求してください。 3910年のA.Brusilovskyカテゴリ: 標準化過程I.FaynbergルーセントテクノロジーズInc.J.GatoボーダフォンエスパニアH.Luベル研究所/ルーセントテクノロジーズM.UnmehopaルーセントテクノロジーズInc.2004年10月
The SPIRITS (Services in PSTN requesting Internet Services) Protocol
SPIRITS(インターネットのサービスを要求するPSTNでのサービス)プロトコル
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built.
インターネットのサービス(SPIRITS)が議定書を作るよう要求しながら、このドキュメントはPSTN(公共のSwitched Telephone Network)でServicesについて説明します。 SPIRITSプロトコルの目的はセルかワイヤーラインPSTNで起こって、PSTNとインターネットとの相互作用を必要とするサービスをサポートすることです。 PSTN側では、SPIRITSサービスがIntelligent Network(IN)実体からたいてい開始されます。 インターネットCall Waitingとインターネット発信番号表示Deliveryはセルラー・ネットワークにおけるロケーションベースのサービスのようなSPIRITSサービスの例です。 プロトコルは他の多くのサービスを組み込むことができるブロックを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document. . . . . . . . . . . 3
2. Overview of operations. . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . 6
3. Using XML for subscription and notification . . . . . . . . . 7
4. XML format definition . . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 本書では使用されるコンベンション。 . . . . . . . . . . 3 2. 操作の概要。 . . . . . . . . . . . . . . . . . . . 3 2.1. 用語。 . . . . . . . . . . . . . . . . . . . . . 6 3. 購読と通知. . . . . . . . . 7 4にXMLを使用します。 XML形式定義. . . . . . . . . . . . . . . . . . . . 8
Gurbani, et al. Standards Track [Page 1] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[1ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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
5. 呼び出し関連のイベント. . . . . . . . . . . . . . . . . . . . . 10 5.1。 IN-決められた一定の要求.115.2。 検出ポイントと必要なパラメタ. . . . . . . 12 5.2.1。 起因するサイド毎秒壊変数。 . . . . . . . . . . . . 12 5.2.2. 終わりサイド毎秒壊変数。 . . . . . . . . . . . . 14 5.3. ダイナミックなDPs. . . . . . . . . . . . . 15 5.3.1を通したサービス。 標準の用法. . . . . . . . . . . . . . . 15 5.3.2。 イベントパッケージ名。 . . . . . . . . . . . . . 16 5.3.3. イベントパッケージパラメタ。 . . . . . . . . . . 16 5.3.4. 登録、ボディー。 . . . . . . . . . . . . . . 16 5.3.5. 購読持続時間. . . . . . . . . . . . 17 5.3.6。 NOTIFYボディー. . . . . . . . . . . . . . . . 17 5.3.7。 より多くのNotifierに処理する、登録、要求. . 18 5.3.8 NOTIFY要求のNotifier世代。 . . . 18 5.3.9. NOTIFY要求の加入者処理。 . . 19 5.3.10. 股状の要求. . . . . . . . . 19 5.3.11の取り扱い。 通知. . . . . . . . . . . . 19 5.3.12のレート。 エージェントを述べてください。 . . . . . . . . . . . . . . . . 20 5.3.13. 例。 . . . . . . . . . . . . . . . . . . 20 5.3.14. 検索するURIの使用は.255.4を述べます。 静的なDPsを通したサービス。 . . . . . . . . . . . . . 25 5.4.1. インターネットキャッチホン. . . . . . . . . . . . 26 5.4.2。 気質選択に電話をしてください。 . . . . . . . . . . 26 5.4.3. VoIP. . . . . 28 6を使用することでICWセッションを受け入れます。 非呼び出しはイベント. . . . . . . . . . . . . . . . . . . 29 6.1を関係づけました。 非呼び出しイベントとそれらの必要なパラメタ。 . . . . 29 6.2. 標準の用法。 . . . . . . . . . . . . . . . . . . . 30 6.3. イベントパッケージ名. . . . . . . . . . . . . . . . . . 30 6.4。 イベントパッケージパラメタ. . . . . . . . . . . . . . . 31 6.5。 登録、ボディー. . . . . . . . . . . . . . . . . . . 31 6.6 購読持続時間。 . . . . . . . . . . . . . . . . 31 6.7. NOTIFYボディー。 . . . . . . . . . . . . . . . . . . . . 32 6.8. より多くのNotifierに処理する、登録、要求。 . . . . . . 32 6.9. NOTIFYのNotifier世代は.32 6.10を要求します。 NOTIFYの加入者処理は.33 6.11を要求します。 股状の要求の取り扱い。 . . . . . . . . . . . . . 33 6.12. 通知の速度。 . . . . . . . . . . . . . . . . 33 6.13. エージェント. . . . . . . . . . . . . . . . . . . . . 33 6.14を述べてください。 例. . . . . . . . . . . . . . . . . . . . . . . 33 6.15。 状態を検索するURIの使用。 . . . . . . . . . . . . 37 7. IANA問題. . . . . . . . . . . . . . . . . . . . . 38 7.1。 イベントパッケージ. . . . . . . . . . . . . . 38 7.2を登録します。 MIMEの種類を登録します。 . . . . . . . . . . . . . . . . 38 7.3. つぼを登録します。 . . . . . . . . . . . . . . . . . . . 39 7.4. XML図式. . . . . . . . . . . . . . . . 40 8を登録します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 40 9。 XML図式定義. . . . . . . . . . . . . . . . . . . . 42 10。 承認。 . . . . . . . . . . . . . . . . . . . . . . 45
Gurbani, et al. Standards Track [Page 2] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[2ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
11. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 48 15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50
11. 頭文字語45 12………………………。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . 48 14. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 48 15. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 50
1. Introduction
1. 序論
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 Requestingインターネットのサービスにおけるサービス)はIETFアーキテクチャと電話の要素がネットワークでつなぐ呼び出し処理が次にインターネットで処理されるサービスのリクエストを接待されたサーバにするのを可能にする関連プロトコルです。 用語Public Switched Telephone Network(PSTN)はワイヤーライン回路交換ネットワークを含むのにここで使用されます、ワイヤレスの回路交換網と同様に。
The earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated in the reverse direction - from the Internet to PSTN.
PSTN/インターネットInterworking(PINT)への以前のIETF作業はインターネットからPSTNまで反対の方向に開始されたサービスを支持してプロトコル(RFC2848)をもたらしました。
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:
このドキュメントはいすがSPIRITSプロトコル提案のために呼ぶSPIRITS WGに対応して書かれています。 他の貢献の中では、このドキュメントは以下に基づいています。
o Informational "Pre-SPIRITS implementations" [10]
o Informational "The SPIRITS Architecture" [1]
o Informational "SPIRITS Protocol Requirements" [4]
o 情報の「スピリッツアーキテクチャ」「プレSPIRITS実装」[10]o Informational[1]o Informationalは「プロトコル要件に生気を与えます」。[4]
1.1. Conventions used in this document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. Overview of operations
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はインターネット・ホストに通知します。 インターネット・ホストはこれらの通知に基づく適切なサービスを実行できます。
Gurbani, et al. Standards Track [Page 3] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[3ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
+------+
| PSTN |
|Events|
+------+
/ \
/ \
+-------+ +--------+
|Call | |Non-Call|
|Related| |Related |
+-------+ +--+-----+
/ \ |
/ \ |
+---/--+ +---\---+ +--+-----------------+
|Static| |Dynamic| |Mobility Management/|
| | | | |Registration/De- |
+------+ +-------+ |registration |
+--------------------+
+------+ | PSTN| |イベント| +------+ / \ / \ +-------+ +--------+ |呼び出し| |非呼び出し| |関係します。| |関係します。| +-------+ +--+-----+ / \ | / \ | +---/--+ +---\---+ +--+-----------------+ |静電気| |動力| |移動性管理/| | | | | |登録/、反-| +------+ +-------+ |登録| +--------------------+
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によって追跡されるgeo-位置の移動性イベントです。 SPIRITSは、これらのタイプのイベントの両方のためのサービスを提供するためにフレームワークを指定するでしょう。
Call-related events, its further subdivisions, and how they enable services in the Internet is contained in Section 5. Services enabled from events not related to call setup, teardown, or maintenance are covered in detail in Section 6.
呼び出し関連のイベントと、一層の区画分譲地と、それらがインターネットでどうサービスを可能にするかはセクション5に含まれています。 セットアップ、分解、またはメインテナンスと呼ぶために関係づけられなかったイベントから可能にされたサービスはセクション6で詳細にカバーされています。
For reference, the SPIRITS architecture from [1] is reproduced below. This document is focused on interfaces B and C only. Interface D is a matter of local policy; the PSTN operator may have a functional interface between the SPIRITS client or a message passing interface. This document does not discuss interface D in any detail.
参照において、[1]からのSPIRITSアーキテクチャは以下で再生します。 このドキュメントはインタフェースBとCだけに焦点を合わせられます。 インタフェースDはローカルの方針の問題です。 PSTNオペレータには、SPIRITSクライアントかメッセージ・パッシングインタフェースの間の機能的なインタフェースがあるかもしれません。 このドキュメントはどんな詳細にもインタフェースDについて議論しません。
Gurbani, et al. Standards Track [Page 4] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[4ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
+--------------+
| 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
+--------------+ | 加入者のもの| | IPホスト| +--------------+ | | | | | +----------+ | | +----------+ | | | パイント| | A| | パイント| | | | クライアント+<。-------/-------->+ゲートウェイ+<。-----+ | +----------+ | | +----------+ | | | | | | | | +----------+ | | +----------+ | | | | スピリッツ| | B| | スピリッツ| | | | | サーバ+<。-------/-------->+ゲートウェイ| | | | +----------+ | | +--------+-+ | | | | | ^ | | +--------------+ +----------|---+ | | | IPネットワーク| | ------------------------------------------|--------|--- PSTN/C/E| | v| +----+------+ | | スピリッツ| | | クライアント| +に対して-------------------+ +---+-----D-----+-++ | サービスの切り換え|INAP/SS7| サービス制御| | 機能+---------+ 機能| +----+--------------+ +------------------+ | |系列++[0]加入者の電話
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ドキュメント[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は今日、Intelligent Network(IN)などのサービスモデルをサポートします。(いくつかの特徴がスイッチング素子で上Service Switching Points(SSPs)と呼ばれるIntelligent Networkによって局所的に実行されます)。 他の特徴はService Control Points(SCPs)と呼ばれるサービス要素の上で実行されます。 SPIRITSアーキテクチャ[1]は、これらのSCP要素がインターネット・ホストとさらに電話エンドユーザの経験を機能アップする能力を利用して、使用するために知的な実体として作用することを許可します。
Gurbani, et al. Standards Track [Page 5] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[5ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
The protocol used on interfaces B and C consists of the SPIRITS protocol, and is based on SIP and SIP event notification [3]. The requirements of a SPIRITS protocol and the choice of using SIP as an enabler are detailed in [4].
インタフェースBとCで使用されるプロトコルは、SPIRITSプロトコルから成って、SIPとSIPイベント通知[3]に基づいています。 SPIRITSプロトコルの要件とイネーブラとしてSIPを使用することの選択は[4]で詳細です。
The SPIRITS protocol is a set of two "event packages" [3]. It contains the procedural rules and semantic context that must be applied to these rules for processing SIP transactions. The SPIRITS protocol has to carry subscriptions for events from the SPIRITS server to the SPIRITS client and notifications of these events from the SPIRITS client to the SPIRITS server. Extensible Markup Language (XML) [12] is used to codify the subscriptions and notifications.
SPIRITSは2人のセットが「イベントパッケージ」であるという[3]について議定書の中で述べます。 それは処理SIPトランザクションのためにこれらの規則に適用しなければならない手続き上の規則と意味文脈を含んでいます。 SPIRITSプロトコルはこれらのイベントのSPIRITSクライアントからSPIRITSサーバまでのSPIRITSサーバからSPIRITSクライアントと通知までイベントのための購読を運ばなければなりません。拡張マークアップ言語(XML)[12]は、購読と通知を成文化するのに使用されます。
Finally, in the context of ensuing discussion, the terms "SPIRITS server" and "SPIRITS client" are somewhat confusing since the roles appear reversed; to wit, the "SPIRITS server" issues a subscription which is accepted by a "SPIRITS client". To mitigate such ambiguity, from now on, we will refer to the "SPIRITS server" as a "SPIRITS subscriber" and to the "SPIRITS client" as a "SPIRITS notifier". This convention adheres to the nomenclature outlined in [3]; the SPIRITS server in Figure 2 is a subscriber (issues subscriptions to events), and the SPIRITS client in Figure 2 is a notifier (issues notifications whenever the event of interest occurs).
最終的に、役割が逆にされるように見えるので、続く議論の文脈では、用語「SPIRITSサーバ」と「SPIRITSクライアント」はいくらか紛らわしいです。 すなわち、「SPIRITSサーバ」は「SPIRITSクライアント」によって受け入れられる購読を発行します。 これから先そのようなあいまいさを緩和するために、私たちは"SPIRITS notifier"として「SPIRITS加入者」と「SPIRITSクライアント」に「SPIRITSサーバ」について言及するつもりです。 このコンベンションは[3]に概説された用語体系を固く守ります。 図2のSPIRITSサーバは加入者(イベントの購読を発行する)です、そして、図2のSPIRITSクライアントはnotifier(興味があるイベントが起こるときはいつも、通知を発行する)です。
2.1. Terminology
2.1. 用語
For ease of reference, we provide a terminology of the SPIRITS actors discussed in the preceding above:
参照する場合に便利なように、私たちは先行で議論したSPIRITS俳優の用語を以下の上に提供します。
Service Control Function (SCF): A PSTN entity that executes service logic. It provides capabilities to influence the call processing occurring in the Service Switching Function (SSF). For more information on how a SCF participates in the SPIRITS architecture, please see Sections 5 and 5.1.
コントロール機能(SCF)を修理してください: サービス論理を実行するPSTN実体。 それはService Switching Function(SSF)に起こる呼び出し処理に影響を及ぼす能力を提供します。 SCFがどうSPIRITSアーキテクチャに参加するかに関する詳しい情報に関しては、セクション5と5.1を見てください。
SPIRITS client: see SPIRITS notifier.
SPIRITSクライアント: SPIRITS notifierを見てください。
SPIRITS server: see SPIRITS subscriber.
SPIRITSサーバ: SPIRITS加入者を見てください。
SPIRITS notifier: A User Agent (UA) in the PSTN that accepts subscriptions from SPIRITS subscribers. These subscriptions contain events that the SPIRITS subscribers are interested in receiving a notification for. The SPIRITS notifier interfaces with the Service Control Function such that when the said event occurs, a notification will be sent to the relevant SPIRITS subscriber.
SPIRITS notifier: SPIRITS加入者から購読を受け入れるPSTNのUserエージェント(UA)。 これらの購読は受け取るSPIRITS加入者が通知を関心があるイベントを含んでいます。 SPIRITS notifierは、前述のイベントが起こるとき、関連SPIRITS加入者に通知を送るようにService Control Functionに連結します。
Gurbani, et al. Standards Track [Page 6] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[6ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
SPIRITS subscriber: A UA in the Internet that issues a subscription containing events in the PSTN that it is interested in receiving a notification for.
SPIRITS加入者: 受け取るそれは通知を関心があるPSTNにイベントを含む購読を発行するインターネットのUA。
3. Using XML for subscription and notification
3. 購読と通知にXMLを使用します。
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プロトコル要件がそれを強制する、「SPIRITS関連のパラメタ、運ばれたコネがaであったなら、SIPと一致した方法は」 (RFC3298: セクション3)を練習します。 SIPはヘッダー(コンテントタイプ、Contentの長さ)の使用で既にペイロード記述能力を提供します。 このドキュメントは、「イベント+xmlにアプリケーション/生気を与えている」新しいMIMEの種類を定義して、IANA(セクション7)にそれを登録します。 このMIMEの種類はSPIRITS要求と応答の「コンテントタイプ」ヘッダーに存在していなければなりません、そして、それはSPIRITS関連の情報を含むXMLドキュメントについて説明します。
This document defines a base XML schema for subscriptions to PSTN events. The list of events that can be subscribed to is defined in the SPIRITS protocol requirements document [4] and this document provides an XML schema for it. All SPIRITS subscribers (any SPIRITS entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request) MUST support this schema. All SPIRITS notifiers (any SPIRITS entity capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE request) MUST support this schema. The schema is defined in Section 9.
このドキュメントはPSTNイベントの購読のためにベースXML図式を定義します。 加入できるイベントのリストはSPIRITSで定義されて、プロトコル要件が[4]を記録して、このドキュメントがXML図式をそれに提供するということです。 すべてのSPIRITS加入者(発行できる登録、REGISTER、またはINVITEが要求するどんなSPIRITS実体も)がこの図式をサポートしなければなりません。 すべてのSPIRITS notifiers(受信できるどんなSPIRITS実体と登録、REGISTER、またはINVITEが要求する処理)がこの図式をサポートしなければなりません。 図式はセクション9で定義されます。
The support for the SIP REGISTER request is included for PINT
compatibility (RFC3298:Section 6).
SIP REGISTER要求のサポートはPINTの互換性(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.
プレ既存のSPIRITS実装がSIPイベント通知体系を使用しなかったので、SIP INVITE要求のサポートは強制されます。 代わりに、初期のPSTN検出ポイントはSIP INVITE要求でいつも到着しました。
This document also defines a base XML schema for notifications of events (Section 9). All SPIRITS notifiers MUST generate XML documents that correspond to the base notification schema. All SPIRITS subscribers MUST support XML documents that correspond to this schema.
また、このドキュメントはイベント(セクション9)の通知のためにベースXML図式を定義します。 すべてのSPIRITS 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
加入できるイベントのセットとPSTN実体によって返される通知の量は異なったPSTNオペレータの中で異なるかもしれません。 何人かのPSTNオペレータには、加入できる豊かなセットのイベントがあるかもしれなくて、プロトコル要件は他のものがSPIRITSに原始のセットのイベントだけについて概説させる間、[4]を記録します。 このドキュメントは原始のセットのイベントの購読と通知に使用しなければならないベースXML図式(セクション9における)を定義します。 より豊かな状態でaをサポートするには、イベントをセットしてください。
Gurbani, et al. Standards Track [Page 7] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[7ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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.
購読と通知、実装はSPIRITS XMLドキュメントでschemasを交替するために対応する追加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です。 聖霊ゲートウェイは、純粋なproxyingの機能性があえて持たれて、その結果、簡単さのために省略されます:
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秒間の>N登録、200が承認する(ベース購読図式を使用するXMLドキュメントインスタンスにおける興味があるイベント)2N>S(登録)3N>SのNotifyの4秒間の>N200は5を承認します(現在のリソース状態を伝えて、通知します)… 6N>Sは7秒間の>N200OKに通知します(リソース状態の変化を伝えて、通知してください; ペイロードはベース通知図式にXML拡張子を使用するXMLドキュメントインスタンスです)。(通知します)
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ドキュメントを捜さなければなりません。 これらの要素は、すべての通知schemasに存在していなければならなくて、セクション9で詳細です。
4. XML format definition
4. XML形式定義
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によってコード化されたSPIRITSペイロード書式を定義します。 そのようなペイロードは、整形式のXMLドキュメントであり、SPIRITS notifiersとSPIRITS加入者によって生産されます。
Gurbani, et al. Standards Track [Page 8] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[8ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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はUniform Resource Name(URN)[14]です、[15]で定義されて、[16]によって広げられた名前空間識別子'ietf'を使用して:
urn:ietf:params:xml:ns:spirits-1.0
つぼ:ietf:params:xml:ナノ秒: スピリッツ-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 XMLドキュメントの根のイベントに生気を与えさせている<>要素、(Contentタイプヘッダーによって特徴付けられる、「アプリケーション/スピリッツイベント+xml、「>) イベントに生気を与えさせている<>要素はそうです」 この要素はXMLドキュメントが基づいている名前空間を示す名前空間宣言('xmlns')を含まなければなりません。 SPIRITSプロトコルへの対応することのXMLドキュメントがURNを含まなければならない、「つぼ:ietf:params:xml:ナノ秒: 1インチに生気を与えさせているコネ、名前空間宣言、」 他の名前空間は必要に応じて指定されるかもしれません。
<spirits-event> element MUST contain at least one <Event> element,
and MAY contain more than one.
イベントに生気を与えさせている<>要素は、少なくとも1つの<Event>要素を含まなければならなくて、1つ以上を含むかもしれません。
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>要素が3つの属性、2を含む義務的な<Event>要素。 最初の義務的な属性は値が「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で定義されたSPIRITSニーモニックに制限しなければなりません。
The third attribute, which is optional, is a 'mode' attribute.
The value of 'mode' is either "N" or "R", corresponding
respectively to (N)otification or (R)equest (RFC3298:Section 4).
The default value of this attribute is "N".
3番目の属性(任意である)は'モード'属性です。 'モード'の値は、それぞれ最もequestに(N)otificationか(R)に対応する「N」か「R」(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
<Event>要素の'タイプ'属性が「INDPs」であるなら、少なくとも以下の要素の1つ以上を含まなければなりません(未知の要素は無視されるかもしれません): <CallingPartyNumber>、<CalledPartyNumber>、<DialledDigits>、または<が>を引き起こします。 これらの要素
Gurbani, et al. Standards Track [Page 9] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[9ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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.
セクション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"であるなら<CalledPartyNumber>要素を含まなければなりません、そして、それは<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対応することのXMLドキュメントは以下の例に似るかもしれません:
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="OD" mode="N">
<CallingPartyNumber>5551212</CallingPartyNumber>
</Event>
<Event type="INDPs" name="OAB" mode="N">
<CallingPartyNumber>5551212</CallingPartyNumber>
</Event>
</spirits-event>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><スピリッツイベントxmlnsが等しい、「つぼ:ietf:params: <Eventタイプ=「INDPs」が命名するxml:ナノ秒:スピリッツの1インチの>が「過量」モード=と等しい、「N、「><CallingPartyNumber>5551212</CallingPartyNumber></イベント><Eventが=「INDPs」名前="OAB"モード=をタイプする、「N「><CallingPartyNumber>5551212</CallingPartyNumber>イベント></スピリッツ</イベント>」
5. Call-related events
5. 呼び出し関連の出来事
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で使用される有限状態機械と他の呼び出し処理要素であり、時間内にのポイントを考えて、いずれでも呼び出しの現状を簡潔に反映します。 呼び出しモデルは州の間のPICs(In Callを指す)と呼ばれる州と変遷から成ります。 相互状態遷移はDetection Pointsか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.
引き金が撃たれるとき、メッセージは、呼び出し状態情報でフォーマットされて、SCPへのSSPによって送られます。 SCPは次に、関連するデータをこの呼び出しに読み込んで、次にSSPがさらなる呼び出し処理に使用する応答を発生させます。
Gurbani, et al. Standards Track [Page 10] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[10ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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.
2つのタイプには検出Pointsがあります: TDPs(または、引き金の検出ポイント)、およびEDPs(または、イベント検出ポイント)。 TDPsは静的に武装している引き金(Service Management Toolsを通して軍備される)で食糧を供給されます。 EDPsはダイナミックに武装している引き金(呼び出し処理が続くので、SCPによって軍備される)です。 また、DPsは「要求」か「通知」DPsとして分類されるかもしれません。 したがって、1つはTDP-R、TDP-N、EDP-R、およびNのEDP-ものを持つことができます。
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.
SCPとのコミュニケーションが開始されるとき、毎秒壊変数のタイプが、SSPが中断するのを必要とする"-R"は、処理と呼びます。 応答が受け取られているときには履歴書に処理に電話をしてください。 引き金が撃たれると、毎秒壊変数の「-n」タイプは、SSPが呼び出し処理を続行するのを可能にします、SCPにメッセージを出した後に、ある出来事が起こったことをそれに通知して。
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 Capability Set(CS)-2[7]呼び出しモデルが本書では例、および説明の容易さに使用されている間他の呼び出しモデルには同様の特性があることに注意してください。 例えば、また、Wireless Intelligent Network(WIN)呼び出しモデルは引き金のダイナミックな軍備を支持します。 したがって、この議論の本質は単にワイヤーラインドメインに適用するのではなく、等しく上手にまた、無線のドメインに適用されます。
When the SCP receives the INAP formatted message from the SSP, if the SCP supports the SPIRITS architecture, it can encode the INAP message contents into a SPIRITS protocol message which is then transmitted to SPIRITS-capable elements in the IP network. Similarly, when it receives responses back from said SPIRITS capable elements, it can reformat the response content into the INAP format and forward these messages back to SSPs. Thus the process of inter-conversion and/or encoding between the INAP parameters and the SPIRITS protocol is of primary interest.
SCPが受信するとき、INAPはSSPからのメッセージをフォーマットしました、SCPがSPIRITS構造をサポートするならそれは次にIPネットワークでSPIRITSできる要素に送られるSPIRITSプロトコルメッセージにINAPメッセージ内容をコード化できます。 前述のSPIRITSできる要素から応答を受けるとき、同様に、それはINAP形式と前進のこれらへの応答内容がSSPsへ通信して戻させる再フォーマットを受けることができます。 したがって、INAPパラメタとSPIRITSプロトコルの間の相互交換、そして/または、コード化の過程は主要におもしろいです。
An SCP is a physical manifestation of the Service Control Function. An SSP is a physical manifestation of the Service Switching Function (and the Call Control Function). To support uniformity of nomenclature between the various SPIRITS drafts, we shall use the terms SCP and SCF, and SSP and SSF interchangeably in this document.
SCPはService Control Functionの物理的な顕現です。 SSPはService Switching Function(そして、Call Control Function)の物理的な顕現です。 様々なSPIRITS草稿の間の用語体系の一様性を支持するために、私たちは用語のSCP、SCF、SSP、およびSSFを互換性を持って本書では使用するつもりです。
5.1. IN-specific requirements
5.1. IN-決められた一定の要求
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
[4]のセクション4はSPIRITSプロトコルに関するIN関連の要件について概説します。 登録、SPIRITS notifierに到着するのが出来事を含まなければならないよう要求して、モニターされてください(DPリストの形で)、モード、(aのためのそれである要求か通知、違い
Gurbani, et al. Standards Track [Page 11] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[11ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
request, the SPIRITS subscriber can influence subsequent call processing and for a notification, no further influence is needed), and any DP-related parameters.
要求、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はSPIRITSサービスのためにCapability Set3(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 NOTIFY要求を使用する)はSPIRITS notifierからSPIRITS加入者まで伝えられます。 NOTIFY要求は発火したDPについて説明するXMLドキュメントとどんな関連パラメタも含んでいます。 NOTIFY要求で運ばれるべきDPsと彼らの関連パラメタはXML図式で成文化されます。 すべてのSPIRITS notifiersがこの図式を理解しなければなりません。 この図式は広げられるかもしれません。 図式はセクション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]のAppendices AとBは読者にとって、興味深いかもしれないCS-2 DPsの選んだ部分集合を含んでいます。 しかしながら、このドキュメントは[4]に概説されたCS-3 DPsについて言及するだけでしょう。
5.2. Detection points and required parameters
5.2. 検出ポイントと必要なパラメタ
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.
SPIRITSサービス(RFC3298: セクション4)のために思い描かれたIN CS-3 DPsは次に、説明されます。 パラメタが、必要である、または必要でさえあります--SPIRITSでどんなにすべてあれほどないIN DPsは多くのパラメタで特徴付けられるか。 その結果、このセクションは、購読と通知で指定しなければならない各DPに、義務的なパラメタをリストアップするのに役立ちます。 XML拡張子が個人的で(公共であって標準化される)の名前空間と交際したので、実現は追加パラメタを指定できます。
The exhaustive list of IN CS-3 DPs and their parameters can be found in reference [13].
参照[13]でIN CS-3 DPsと彼らのパラメタに関する完全なりストを見つけることができます。
Each DP is given a SPIRITS-specific mnemonic for use in the subscriptions and notifications.
購読と通知における使用のためのSPIRITS特有のニーモニックを各DPに与えます。
5.2.1. Originating-side DPs
5.2.1. 由来しているサイド毎秒壊変数
Origination Attempt Authorized SPIRITS mnemonic: OAA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
創作Attempt Authorized SPIRITSニーモニック: 中のOAA Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Gurbani, et al. Standards Track [Page 12] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[12ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
CallingPartyNumber: A string used to identify the calling party for the call. The actual length and encoding of this parameter depend on the particulars of the dialing plan used.
CallingPartyNumber: 五弦は呼び出しのために以前はよく起呼側を特定していました。 このパラメタの実際の長さとコード化は使用されるダイヤルするプランの子細に依存します。
CalledPartyNumber: A string containing the number (e.g., called directory number) used to identify the called party. The actual length and encoding of this parameter depend on the particulars of the dialing plan used.
CalledPartyNumber: 数(例えば、ディレクトリ番号と呼ばれる)を含む五弦が以前はよく被呼者を特定していました。 このパラメタの実際の長さとコード化は使用されるダイヤルするプランの子細に依存します。
Collected Information SPIRITS mnemonic: OCI Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
集まっている情報SPIRITSニーモニック: 中のOCI Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、DialledDigits
DialledDigits: This parameter contains non-translated address information collected/received from the originating user/line/trunk
DialledDigits: このパラメタは由来しているユーザ/線/トランクから集められるか、または受け取られた非変換されたアドレス情報を含んでいます。
Analyzed Information SPIRITS mnemonic: OAI Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
分析情報SPIRITSニーモニック: 中のOAI Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、DialledDigits
Origination Answer SPIRITS mnemonic: OA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
創作Answer SPIRITSニーモニック: 中のOA Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Origination Term Seized SPIRITS mnemonic: OTS Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
創作Term Seized SPIRITSニーモニック: 中のOTS Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Origination No Answer SPIRITS mnemonic: ONA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
創作いいえAnswer SPIRITSニーモニック: 中のONA Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Origination Called Party Busy SPIRITS mnemonic: OCPB Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
創作CalledパーティBusy SPIRITSニーモニック: 中のOCPB Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Route Select Failure SPIRITS mnemonic: ORSF Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Select Failure SPIRITSニーモニックを発送してください: 中のORSF Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Gurbani, et al. Standards Track [Page 13] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[13ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
Origination Mid Call SPIRITS mnemonic: OMC Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
創作Mid Call SPIRITSニーモニック: 中のOMC Mandatoryパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber
Origination Abandon SPIRITS mnemonic: OAB
創作Abandon SPIRITSニーモニック: OAB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
中の義務的なパラメタ、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber
Origination Disconnect SPIRITS mnemonic: OD Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
創作Disconnect SPIRITSニーモニック: Mandatoryパラメタを過量に与える、登録: NOTIFYのCallingPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
5.2.2. Terminating-side DPs
5.2.2. 終わりサイド毎秒壊変数
Termination Answer SPIRITS mnemonic: TA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
終了Answer SPIRITSニーモニック: 中のTA Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Termination No Answer SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
終了いいえAnswer SPIRITSニーモニック: 中のTNA Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CallingPartyNumber、CalledPartyNumber
Termination Mid-Call SPIRITS mnemonic: TMC Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
終了Mid-呼び出しSPIRITSニーモニック: 中のTMC Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber
Termination Abandon SPIRITS mnemonic: TAB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
終了Abandon SPIRITSニーモニック: 中のTAB Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber
Termination Disconnect SPIRITS mnemonic: TD Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
終了Disconnect SPIRITSニーモニック: 中のTD Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber、CallingPartyNumber
Termination Attempt Authorized SPIRITS mnemonic: TAA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
終了Attempt Authorized SPIRITSニーモニック: 中のTAA Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber、CallingPartyNumber
Gurbani, et al. Standards Track [Page 14] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[14ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
Termination Facility Selected and Available SPIRITS mnemonic: TFSA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
終了Facility SelectedとAvailable SPIRITSニーモニック: 中のTFSA Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber
Termination Busy SPIRITS mnemonic: TB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber, Cause
終了Busy SPIRITSニーモニック: 中のTB Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber、CallingPartyNumber、原因
Cause: This parameter contains a string value of either "Busy" or "Unreachable". The difference between these is translated as a requirement (RFC3298:Section 5) to aid in the SPIRITS subscriber in determining if the called party is indeed busy (engaged), or if the called party is unavailable (as it would be if it were on the cellular PSTN and the mobile subscriber was not registered with the network).
原因: このパラメタは「忙しい」か「手の届かないこと」のストリング値を含んでいます。 これらの違いは本当に、被呼者が忙しいかどうか(従事します)、または被呼者が入手できないかどうか(それがセルPSTNにあるならそうであり、携帯電話の契約者がネットワークに登録されなかったとき)決定する際にSPIRITS加入者で支援するという要件(RFC3298: セクション5)として翻訳されます。
5.3. Services through dynamic DPs
5.3. ダイナミックなDPsを通したサービス
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炎で収容したところでそれらの場合で利用する便利な手段です。(セクション3の[4])を見てください。 [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 Eventsパッケージは、IP終点(または、ホスト)がPSTNに起こる出来事のその後の通知に加入して、受け取るのを可能にします。 図2に関して、これは「B」と「C」であることが示されるインタフェースに関するコミュニケーションを含んでいます。
5.3.1. Normative usage
5.3.1. 標準の用法
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.
加入者は得るそれが通知を関心がある1セットの出来事(DPs)を特定する要求を登録に出すでしょう。 このセットは少なくとも1DPを含まなければならなくて、それは1つ以上を含むかもしれません。 登録、要求はそうです。notifierに発送されます。そこでは、それがうまくいっている認証まで受け入れられます。
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は次に、SPIRITS notifier、そして/または、SCFで武装を解除しなければなりません。
Gurbani, et al. Standards Track [Page 15] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[15ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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要求を通して加入者に渡されるとき、終わります。 加入者は同じ出来事の将来の発生に関心があるなら、新しい状態でaを発行しなければならない、登録、新しい対話を確立して、要求します。
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で上げられた特定のパッケージ責任に記入します。
5.3.2. Event package name
5.3.2. イベントパッケージ名
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個のイベントパッケージを定義します。 これらの1番目は、このセクションで定義されて、「スピリッツ-INDPs」と呼ばれます。 セルかワイヤーラインPSTNのIN検出ポイントに対応する出来事にこのパッケージを使用しなければなりません。 SPIRITSプロトコルを実行して、IN検出ポイントを支持するすべての実体が「出来事」要求ヘッダー[3]を「スピリッツ-INDPs」に設定しなければなりません。 「出来事を許容する、」 実体がSPIRITSプロトコルを実行して、IN検出ポイントを支持するなら、一般的なヘッダー[3]は象徴「スピリッツ-INDPs」を入れなければなりません。
Event: spirits-INDPs
Allow-Events: spirits-INDPs
出来事: スピリッツ-INDPs、出来事を許容します: スピリッツ-INDPs
The second event package is defined and discussed in Section 6.
セクション6で2番目のイベントパッケージについて、定義されて、議論します。
5.3.3. Event package parameters
5.3.3. イベントパッケージパラメタ
The "spirits-INDPs" event package does not support any additional parameters to the Event header.
「スピリッツ-INDPs」イベントパッケージはどんな追加パラメタもEventヘッダーに支持しません。
5.3.4. SUBSCRIBE bodies
5.3.4. 登録、ボディー
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:
登録、購読を終えるのに役立つ要求はそうするかもしれません。空のボディーを含んでください。 登録、しかしながら、対話を確立する要求はそうしなければなりません。スリーピースの情報をコード化するボディーを含んでください:
(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で登録、要求、または5月を複数のDPsに申し込むかもしれない、問題、a異なる、登録、各DPを求める受け取るそれは通知を関心がある要求。 プロトコルは両方の形式の表現を考慮して、しかしながら、それはサービスが引き起こされるDPsのどれかによるならDPsに加入する前の方法を推薦します。
Gurbani, et al. Standards Track [Page 16] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[16ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
(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] 検出ポイントが要求か通知として設定されるか否かに関係なく、INは知識があるという要件のために、「スピリッツ-INDPs」パッケージ(しかし、いずれの「スピリッツユーザ教授」パッケージの中にもそうしない)におけるすべての出来事が、「モード」パラメタを提供するのに必要です。(パラメタの値は、「R」(要求のための)と通知のための「N」です)。
(3) A list of the values of the parameters associated with the
event detection point (Note: the term "event" here refers to the
IN usage -- a dynamically armed DP is called an Event Detection
Point). Please see Section 5.2.1 and Section 5.2.2 for a list of
parameters associated with each DP.
(3) イベント検出ポイント(注意: ここの「出来事」という用語はIN用法を示します--ダイナミックに武装しているDPはEvent Detection Pointと呼ばれる)に関連しているパラメタの値のリスト。 各DPに関連しているパラメタのリストに関してセクション5.2.1とセクション5.2.2を見てください。
The default body type for SUBSCRIBEs in SPIRITS is denoted by the MIME type "application/spirits-event+xml". The "Accept" header, if present, MUST include this MIME type.
SPIRITSのSUBSCRIBEsのためのデフォルトボディータイプは「アプリケーション/スピリッツ出来事+はxmlする」MIMEの種類によって指示されます。 存在しているなら、「受け入れてください」というヘッダーはこのMIMEの種類を入れなければなりません。
5.3.5. Subscription duration
5.3.5. 購読持続時間
For package "spirits-INDPs", the purpose of the SUBSCRIBE request is to arm the DP, since as far as IN is concerned, being armed is the first essential pre-requisite. A DP maybe armed either statically (for instance, through service provisioning), or dynamically (by the SCF). A statically armed DP remains armed until it is disarmed proactively. A dynamically armed DP remains armed for the duration of a call (or more appropriately, no longer than the duration of a particular SSF-SCF relationship).
登録、要求はそうです。「スピリッツ-INDPs」、目的をパッケージする、軍備されるのが、INは関係があるのと同じくらい遠くに第一要素前提条件であるので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.
興味があるイベントがnotifierに起こるとき、ダイナミックに武装しているDPsは自動的に武装を解除します。 呼び出しの文脈の中でDPsを再軍備するのは、加入者次第です、そう望んでいるなら。
Statically armed DPs are considered outside the scope of the SPIRITS protocol requirements [4] and thus will not be considered any further.
静的に武装しているDPsはSPIRITSプロトコル要件[4]の範囲の外で考えられて、その結果、これ以上考えられないでしょう。
5.3.6. NOTIFY bodies
5.3.6. NOTIFYボディー
Bodies in NOTIFY requests for the "spirits-INDPs" package are optional. If present, they MUST be of the MIME type "application/spirits-event+xml". The body in a NOTIFY request encapsulates the following pieces of information which can be used by the subscriber:
「スピリッツ-INDPs」パッケージを求めるNOTIFY要求におけるボディーは任意です。 存在しているなら、それらは「アプリケーション/スピリッツ出来事+はxmlする」MIMEの種類のものであるに違いありません。 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をもたらした出来事、(これが対応における現在の同じいつもでない、しかし、通常、出来事になる、登録、要求)
Gurbani, et al. Standards Track [Page 17] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[17ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
(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.
加入者がaの一部として複数のDPsを軍備したなら、SPIRITS notifier、そして/または、SCF/SCPで、武装を解除された状態で登録、要求、登録、部分が同じくらいのものであったなら対話がそうであるに違いないすべての不-遭遇しているDPsを選抜してください。
5.3.7. Notifier processing of SUBSCRIBE requests
5.3.7. より多くのNotifierに処理する、登録、要求
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.
notifierが登録を受けたら要求を認証しなければならないよう要求してください、そして、加入者が加入されるリソースにアクセスするのに権限を与えられるのを確実にしてください、この場合、あるPSTN線におけるPSTN/IN出来事。
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.
一度、登録、認証されて、認可された要求、notifierが中に含まれたPSTN線に対応する検出ポイントを軍備するためにインタフェースDの上のSCFに連結する、登録、ボディー。 このドキュメントのための範囲の外にインタフェースDに関する子細があります。 ここで、私たちは、notifierがインタフェースDを通してPSTNでの引き金の軍備(そして、武装解除)に影響できると単に思うつもりです。
5.3.8. Notifier generation of NOTIFY requests
5.3.8. NOTIFY要求のNotifier世代
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".
notifierが撮影へのそれが200msより202応答を送らなければならない、引き金の軍備を予想する、登録、購読を受け入れて、すぐに、要求します。 そして、それは空のボディーのNOTIFY要求を送るべきです。 このNOTIFY要求には、「購読状態」ヘッダーが「未定」の値と共になければなりません。
This immediate NOTIFY with an empty body is needed since the
resource identified in the SUBSCRIBE request does not have as
yet a meaningful state.
登録、要求はそうしません。中で特定されたリソース以来空のボディーのこの即座のNOTIFYが必要である、まだ、重要な状態を持ってください。
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."
notifierがいったん首尾よく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要求には、「購読状態」ヘッダーがなければなりません、そして、「発火すること」の理由パラメタで「終えられること」に値を設定しなければなりません。
Gurbani, et al. Standards Track [Page 18] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[18ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
5.3.9. Subscriber processing of NOTIFY requests
5.3.9. NOTIFY要求の加入者処理
The exact steps executed at the subscriber when it gets a NOTIFY request will depend on the service being implemented. As a generality, the UA associated with the subscriber should somehow impart this information to the user by visual or auditory means, if at all possible.
NOTIFY要求を得るとき加入者で実行された正確なステップは実行されるサービスによるでしょう。 できれば、一般性として、加入者に関連しているUAは視覚の、または、聴力の手段でこの情報をユーザにどうにか伝えるはずです。
If the NOTIFY request contained a "Subscription-State" header with a value of "terminated" and a reason parameter of "fired", the UA associated with the subscriber MAY initiate a new subscription for the event that was just reported through the NOTIFY request.
NOTIFY要求が「終えられること」の値と「発火すること」の理由パラメタがある「購読状態」ヘッダーを含んだなら、加入者に関連しているUAはNOTIFY要求でただ報告された出来事のための新規申込みを開始するかもしれません。
Whether or not to initiate a new subscription when an existing
one expires is up to the context of the service that is being
implemented. For instance, a user may configure her UA to
always re-subscribe to the same event when it fires, but this
is not necessarily the normative case.
既存のものが期限が切れるときの新規申込みを開始するかどうかが実行されているサービスの文脈まで達しています。 例えば、発火しますが、これが必ず標準のそうであるというわけではないときに、ユーザは、いつも同じ出来事に再申し込むために彼女のUAを構成するかもしれません。
5.3.10. Handling of forked requests
5.3.10. 股状の要求の取り扱い
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つの要素で目標セットをもたらすべきです: notifier。
5.3.11. Rate of notifications
5.3.11. 通知の速度
For reasons of security more than network traffic, it is RECOMMENDED that the notifier issue two or, at most three NOTIFY requests for a subscription. If the subscription was accepted with a 202 response, a NOTIFY will be sent immediately towards the subscriber. This NOTIFY serves to inform the subscriber that the request has been accepted and is being acted on.
ネットワークトラフィックより多くのセキュリティの理由で、notifierが2を発行するのが、RECOMMENDEDであるか高々、3NOTIFYはaのために購読を要求します。 202応答で購読を受け入れたなら、加入者すぐに向かってNOTIFYを送るでしょう。 このNOTIFYは、要求が受け入れられて、影響されていることを加入者に知らせるのに役立ちます。
Once the resource (detection points) identified in the SUBSCRIBE request have been initialized, the notifier MUST send a second NOTIFY request. This request contains the base state of the resource.
登録、要求はそうです。かつての中で特定されたリソース(検出ポイント)、初期化されています、notifierはNOTIFYが要求する1秒を送らなければなりません。 この要求はリソースのベース州を含んでいます。
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を加入者に送ります。 このNOTIFY要求は興味があるイベントに関する詳しい情報を含んでいます。
Gurbani, et al. Standards Track [Page 19] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[19ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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つ、および検出の発火へのリードが指すという情報を含む他。
5.3.12. State agents
5.3.12. 州のエージェント
State agents are not used in SPIRITS.
州のエージェントはSPIRITSで使用されません。
5.3.13. Examples
5.3.13. 例
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:
このセクションはインターネット発信番号表示Delivery(ICID)と呼ばれるSPIRITSサービスのための例の呼び出し流れを含みます。 SPIRITSが[1]のセクション2.2で説明されるように修理するベンチマークの1つはインターネット発信番号表示配送です:
This service allows the subscriber to see the caller's number or
name or both while being connected to the Internet. If the
subscriber has only one telephone line and is using the very line
for the Internet connection, the service is a subset of the ICW
service and follows the relevant description in Section 2.1.
Otherwise, the subscriber's IP host serves as an auxiliary device
of the telephone to which the call is first sent.
このサービスで、加入者はインターネットに関連づけられている間、訪問者の番号、名前または両方を見ることができます。 加入者が、ある電話回線しか持たないで、インターネット接続にまさしくその線を使用しているなら、サービスは、ICWサービスの部分集合であり、セクション2.1で関連記述に続きます。 さもなければ、加入者のIPホストは呼び出しが最初に送られる電話の補助装置として勤めます。
We present an example of a SPIRITS call flow to realize this service. Note that this is an example only, not a normative description of the Internet Caller-ID service.
私たちは、このサービスがわかるためにSPIRITS呼び出し流動に関する例を提示します。 これが標準のインターネット発信番号表示サービスの記述ではなく、例専用であることに注意してください。
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はどんなSPIRITSサービスの不可欠の部分である4つの実体についても表現します。(実体に関する見出しは[1])の図1に確立された名前を示します--、SPIRITS加入者、SPIRITS notifier、およびSCF。 SPIRITSゲートウェイがこの図に含まれていないことに注意してください。 論理的に、SPIRITSメッセージはSPIRITSサーバとSPIRITSクライアントの間を流れます。 存在しているなら、ゲートウェイはプロキシとして務めるかもしれません。
Gurbani, et al. Standards Track [Page 20] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[20ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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
SPIRITSサーバSPIRITSクライアントSCF(「加入者」)("notifier")S N| | | | F1は申し込まれます。| | +--------------------->+| | | | | | F2アームDP| | F3 200は(代理をします)+を承認します。--------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| F4は通知します。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | F5 200OK(NOT)| | +--------------------->|、|、|、|、| ~ ~ ~ ~ ~ ~ | | F6 Evt。 . | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | F7は+に通知します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| F8 200OK(NOT)| | +--------------------->|、|、|、|、|、|、|、| \|/ \|/ \|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でF8を通してメッセージF1でこの相互作用を捕らえます。 ユーザはSIP SUBSCRIBE要求にそれがそのDPに関連しているゼロか、より多くのパラメタと共に興味を持っているDPを特定させます(F1)(この例では、Termination_Attempt_DPは使われるでしょう)。 回転におけるSPIRITS notifierは、サービス(F2)のためにTermination_Attempt_DPを軍備するためにSCFと対話します。 現状情報がある即座のNOTIFYは加入者(F4、F5)に発信することです。
Gurbani, et al. Standards Track [Page 21] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[21ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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は、それがいつ武装_Termination_Attempt DP(図3では、目立たない)に遭遇するかをこの出来事のSCFに知らせます。 SCFはこの出来事(F6)についてSPIRITS notifierに知らせます。
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がこの出来事を受けるとき、それは、SPIRITS加入者(F7)にSIP NOTIFY要求を形成して、それを向けます。 このNOTIFYは加入者に訪問者を特定するのに必要なすべての情報要素を含むでしょう。 加入者、受信のときに、通知(F8)は日付/時間と訪問者の数で窓をぽんと開けるかもしれません。
The rest of this section contains the details of the SIP messages in Figure 3. The call flow details below assume that the SPIRITS gateway is, for the purpose of this example, a SIP proxy that serves as the default outbound proxy for the notifier and an ingress host of the myprovider.com domain for the subscriber. The subscriber and notifier may be in separate administrative domains.
このセクションの残りは図3のSIPメッセージの詳細を含んでいます。 以下の呼び出し流れの詳細は、SPIRITSゲートウェイがこの例の目的のためのデフォルトとしてnotifierの外国行きのプロキシと加入者のためのmyprovider.comドメインのイングレスホストに役立つSIPプロキシであると仮定します。 加入者とnotifierが別々の管理ドメインにあるかもしれません。
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: ...
一口: 登録、myprovider.com SIP/2.0From: <一口: vkg@example.com 、gt;、;=8177-afd-991To:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、CSeq: 18992 呼び出しIDを申し込んでください: 3329as77@host.example.com 接触: <一口: vkg@host.example.com 、gt;、以下を通って 一口/2.0/UDP host.example.com; ブランチ=z9hG4bK776asdhdsは期限が切れます: 3600年の出来事: スピリッツ-INDPs、出来事を許容します: スピリッツ-INDPs、スピリッツユーザ教授Accept: アプリケーション/スピリッツ出来事+xmlコンテントタイプ: アプリケーション/スピリッツ出来事+xml Content-長さ: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><スピリッツイベントxmlnsが等しい、「つぼ:ietf:params: <Eventタイプ=「INDPs」が命名するxml:ナノ秒:スピリッツの1インチの>が"TAA"モード=と等しい、「N「><CalledPartyNumber>6302240216</CalledPartyNumber>イベント></スピリッツ</イベント>」
The subscriber forms a SIP SUBSCRIBE request which identifies the DP that it wants to subscribe to (in this case, the TAA DP) and the actual line it wants that DP armed for (in this case, the line
加入者がそれが加入したがっているDP(この場合TAA DP)とそれが欲しいDPが備えて武装した実際の線を特定するSIP SUBSCRIBE要求を形成する、(この場合線
Gurbani, et al. Standards Track [Page 22] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[22ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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:
電話番号6302240216)に関連しています。 この要求は、結局、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
一口/2.0 200OK From: <一口: vkg@example.com 、gt;、;=8177-afd-991To:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、; =スピリッツ-TAA-6302240216 CSeqにタグ付けをしてください: 18992 呼び出しIDを申し込んでください: 3329as77@host.example.com 接触: <一口: 以下を通ってnotifier.myprovider.com>。 一口/2.0/UDP host.example.com; ブランチ=z9hG4bK776asdhdsは期限が切れます: 3600は受け入れます: アプリケーション/スピリッツ出来事+xml Content-長さ: 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はDPを軍備するためにSCFと対話して、また、通知の現状について加入者に知らせる加入者に向かって即座のNOTIFYを送ります:
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
NOTIFY一口: vkg@host.example.com SIP/2.0From: <一口: 16302240216@myprovider.com 、gt;、;=スピリッツTAA-6302240216To:にタグ付けをしてください <一口: vkg@example.com 、gt;、;以下を通って=8177-afd-991にタグ付けをしてください 一口/2.0/UDP gateway.myprovider.com; ブランチは以下を通って0-1にz9hG4bK-9$と等しいです。 2.0/UDP notifier.myprovider.com; ブランチ=z9hG4bKqo--9呼び出し一口/ID: 3329as77@host.example.com 接触: <一口: notifier.myprovider.com>購読州: アクティブなCSeq: 3299に通知します。受け入れてください: アプリケーション/スピリッツ出来事+xml Content-長さ: 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
一口/2.0 200OK From: <一口: 16302240216@myprovider.com 、gt;、;=スピリッツTAA-6302240216To:にタグ付けをしてください <一口: vkg@example.com 、gt;、;以下を通って=8177-afd-991にタグ付けをしてください 一口/2.0/UDP gateway.myprovider.com; ブランチは以下を通って0-1にz9hG4bK-9$と等しいです。 2.0/UDP notifier.myprovider.com; ブランチ=z9hG4bKqo--9呼び出し一口/ID: 3329as77@host.example.com 接触: <一口: vkg@host.example.com 、gt;、CSeq: 3299に通知します。受け入れてください: アプリケーション/スピリッツ出来事+xml Content-長さ: 0
Gurbani, et al. Standards Track [Page 23] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[23ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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:
時間内に(F1に確立された購読がnotifierで期限が切れる前に)の何らかの後のポイントでは、呼び出しはF1のXMLによってコード化されたボディーで特定された数に達します--6302240216。 SCFはnotifier(F6)に通知します。 この通知に含まれているのは、PSTNからの関連情報、すなわち、6302240216に電話をするのを試みるパーティーの電話番号です。 notifierは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: ...
NOTIFY一口: vkg@host.example.com SIP/2.0From: <一口: 16302240216@myprovider.com 、gt;、;=スピリッツTAA-6302240216To:にタグ付けをしてください <一口: vkg@example.com 、gt;、;以下を通って=8177-afd-991にタグ付けをしてください 一口/2.0/UDP notifier.myprovider.com; ブランチはz9hG4bK9inn-=u7呼び出しIDと等しいです: 3329as77@host.example.com 接触: <一口: notifier.myprovider.com>CSeq: 3300は購読状態に通知します: 終わり、; 理由=はAcceptを首にしました: アプリケーション/スピリッツ出来事+xml Event: スピリッツ-INDPs、出来事を許容します: スピリッツ-INDPs、スピリッツユーザ教授コンテントタイプ: アプリケーション/スピリッツ出来事+xml Content-長さ: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<CallingPartyNumber>3125551212</CallingPartyNumber>
</Event>
</spirits-event>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><スピリッツイベントxmlnsが等しい、「つぼ:ietf:params: <Eventタイプ=「INDPs」が命名するxml:ナノ秒:スピリッツの1インチの>が"TAA"モード=と等しい、「N「><CalledPartyNumber>6302240216</CalledPartyNumber><CallingPartyNumber>3125551212</CallingPartyNumber>イベント></スピリッツ</イベント>」
There are two important issues to note in the call flows for F7:
F7によって呼び出し流れで注意する2つの切迫した課題があります:
(1) The body of the NOTIFY request contains the information passed
to the SPIRITS notifier from the SCF. In this particular
example, this is the phone number of the party (3125551212)
that attempted to call 6302240216.
(1) NOTIFY要求のボディーはSCFよりSPIRITS 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
(2) 通知が現れたので、F1に確立された購読は終わりました(Subscription-州のヘッダーで明白であるとして)。 通常、購読は発火するTAAに関連しているDP(したがって、Subscription-州のヘッダーで「発火すること」の理由コード)のため終わりました。 加入者です。
Gurbani, et al. Standards Track [Page 24] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[24ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
wants to get notified of another attempt to call the number
6302240216, he/she should send a new SUBSCRIBE request to the
notifier.
No.6302240216に電話をする別の試みについて通知させる必需品、その人が新しい状態でaを送るべきである、登録、notifierに要求します。
The subscriber can take any appropriate action upon the receipt of the NOTIFY in F7. A reasonable implementation may pop up a window populated with the information contained in the body of F12, along with a button asking the subscriber if they would like to re- subscribe to the same event. Alternatively, a re-subscription could be generated automatically by the subscriber's UA based on his/her preferences.
加入者はF7でNOTIFYの領収書にどんな適切な行動も持っていくことができます。 合理的な実現は情報がF12のボディーに含まれている状態で居住された窓を打ち上げするかもしれません、彼らが同じ出来事に再申し込みたがっているかどうか加入者に尋ねるボタンと共に。 あるいはまた、再購読はその人の好みに基づく加入者のUAによって自動的に発生できました。
To complete the protocol, the subscriber also sends a 200 OK message towards the notifier:
また、プロトコルを完成するために、加入者は200OKメッセージをnotifierに向かって送ります:
F8: S->N
F8: S>N
200 OK SIP/2.0 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 To: <sip:vkg@example.com>;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7 Call-ID: 3329as77@host.example.com CSeq: 3300 NOTIFY Content-Length: 0
200 OK一口/2.0From: <一口: 16302240216@myprovider.com 、gt;、;=スピリッツTAA-6302240216To:にタグ付けをしてください <一口: vkg@example.com 、gt;、;以下を通って=8177-afd-991にタグ付けをしてください 一口/2.0/UDP notifier.myprovider.com; z9hG4bK9inn-=u7呼び出しID: 3329as77@host.example.com CSeq: 3300はコンテンツの長さに通知します: 0
5.3.14. Use of URIs to retrieve state
5.3.14. 状態を検索するURIの使用
The "spirits-INDPs" package MUST NOT use URIs to retrieve state. It is expected that most state information for this package is compact enough to fit in a SIP message. However, to err on the side of caution, implementations MUST follow the convention outlined in Section 18.1.1 of [5] and use a congestion controlled transport if the size of the request is within 200 bytes of the path MTU if known, or if the request size is larger than 1300 bytes and the path MTU is unknown.
「スピリッツ-INDPs」パッケージは、状態を検索するのにURIを使用してはいけません。 このパッケージのためのほとんどの州の情報がSIPメッセージをうまくはめ込むことができるくらいコンパクトであると予想されます。 しかしながら、知られているなら経路MTUの200バイト以内で要求のサイズがあるか、または要求サイズが1300バイトより大きいなら、実現は、警告の側で間違えるのに、[5]についてセクション18.1.1に概説されたコンベンションに続いて、混雑の制御輸送を使用しなければなりません、そして、経路MTUは未知です。
5.4. Services through static DPs
5.4. 静的なDPsを通したサービス
We mentioned in Section 5.1 that the first trigger that fires during call processing is typically a TDP since there isn't any pre-existing control relationship between the SSF and the SCF. Some Internet hosts may have expressed an interest in executing services based on TDPs (through an a-priori arrangement, which is not a part of this specification). Thus, the PSTN will notify such hosts. To do so, it will send a SIP request (typically an INVITE) towards the Internet host. The body of the SIP request MUST contain multi-part MIME with two MIME components: the first part corresponding to the normal payload, if any, of the request; and the second part will contain
私たちは、セクション5.1でSSFとSCFとのコントロール関係を先在させるいずれもないので通常、呼び出し処理の間に撃たれる最初の引き金がTDPであると言及しました。 何人かのインターネット・ホストがTDPs(この仕様の一部でない先験的なアレンジメントによる)に基づくサービスを実行することへの関心を示したかもしれません。 したがって、PSTNはそのようなホストに通知するでしょう。 そうするために、それはSIP要求(通常INVITE)をインターネット・ホストに向かって送るでしょう。 SIP要求のボディーは2つのMIMEコンポーネントがある複合MIMEを含まなければなりません: もしあれば要求の標準のペイロードに対応する最初の部分。 そして、第二部は含むでしょう。
Gurbani, et al. Standards Track [Page 25] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[25ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
SPIRITS-specific information (e.g., the DP that fired). Responses to the INVITE request, or subsequent SUBSCRIBE messages from the Internet host to the PSTN within a current call context may result in EDPs being armed.
SPIRITS-特殊情報(例えば、発火したDP)。 登録、EDPsの結果があって、現在の呼び出し背景の中のインターネット・ホストからPSTNまでのメッセージはそうするかもしれません。INVITE要求、またはその後への応答、武装しています。
5.4.1. Internet Call Waiting (ICW)
5.4.1. インターネットキャッチホン(ICW)
ICW as a benchmark SPIRITS service actually predates SPIRITS itself. Pre-SPIRITS implementations of ICW are detailed in [10]. However, as the document notes, while a diversity of implementations exists, these implementations are not interoperable. At the time [10] was published, the industry did not have the depth of experience with SIP as is the case now. The use of SIP in [10] does not constitute normative usage of SIP as described in [5]; for instance, no mention is made of the SDP (if any) in the initial INVITE (especially since this pertains to "accept the call using VoIP" case). Thus this section serves to provide a normative description of ICW in SPIRITS.
ベンチマークSPIRITSサービスとしてのICWは実際にSPIRITS自身より前に起こります。 ICWのプレSPIRITS実現は[10]で詳細です。 しかしながら、ドキュメントが注意するように、実現の多様性は存在していますが、これらの実現は共同利用できません。 [10]が発行されたとき、産業には、現在そうであるようにSIPの経験の深さがありませんでした。 [10]におけるSIPの使用は[5]で説明されるようにSIPの標準の使用法を構成しません。 例えば、初期のINVITEでSDP(もしあれば)で言及を全くしません(特にこれが「VoIPを使用することで呼び出しを受け入れてください」ケースに関するので)。 したがって、このセクションは、SPIRITSの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 指定されるとして呼び出しを扱わせてください。
5.4.2. Call disposition choices
5.4.2. 気質選択に電話をしてください。
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. ボイス・オーバー 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
5. 呼び出しをボイスメールに送ります。
Gurbani, et al. Standards Track [Page 26] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[26ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
6. Forwarding the call to another number
6. もう1つの数に呼び出しを送ります。
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. Responseでないことでの拒絶(または、Forwarding)--ダイアログボックスを表示した後に加入者が、ある期間以内に応じないなら、加入者によって事前に定義された処理に基づいてかかってきた電話を拒絶するか、または扱うことができます。
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:
SPIRITSサービスとしてのICWがSCPを加入者線がインターネットセッションに使用されているという事実を知るようにしないで可能でないと完全を期すために指摘されるべきです。 しかしながら、その認識はICWサービスの一部ではなく、唯一前提条件です。 この情報をSCPに伝えるのに以下の3つの方法の1つを利用しなければなりません:
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加入者は方法を基礎づけました: SIP REGISTER要求を出すことによって、加入者のPCの上のICWクライアントはインターネットセッションについて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.INは方法を基礎づけました: SCPは地理的な領域のインターネットサービスプロバイダ(ISP)アクセス番号のリストを維持します。 これらの数の1つにダイヤルされて、接続されるとき、それ(SCP)は、起呼側がインターネットセッションに従事していると仮定します。
C. Any combination of methods A and B.
C. 方法AとBのどんな組み合わせ。
ICW depends on a TDP to be provisioned in the SSP. When the said TDP is encountered, the SSP suspends processing of the call and sends a request to the SPIRITS-capable SCP. The SCP determines that the subscriber line is being used for an Internet session. It instructs the SPIRITS notifier on the SCP to create a SIP INVITE request and send it to the SPIRITS subscriber running on the subscriber's IP host.
ICWは、SSPで食糧を供給されるためにTDPによります。 前述のTDPが遭遇するとき、SSPはSPIRITSできるSCPに呼び出しの処理を中断させて、要求を送ります。 SCPは、加入者線がインターネットセッションに使用されていることを決定します。 それは加入者のIPホストで走っているSPIRITS加入者にSIP INVITE要求を作成して、それを送るようSCPの上のSPIRITS notifierに命令します。
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に向け直される呼び出しをもたらします(すなわち、あらかじめ記録された発表をプレーするか、または音声メールを記録してください)。
Gurbani, et al. Standards Track [Page 27] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[27ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
Further processing of a SPIRITS notifier when it receives a final response can be summarized by the following steps:
最終的な応答を受けるとき、以下のステップでSPIRITS notifierのさらなる処理をまとめることができます:
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。 比較がマッチを示すなら、SPIRITS加入者がモデムを外すのをちょうど許容できるくらいの時間の呼び出しを頼りにするようSSPに命令してください、その結果、線を開けます。 そして、通常の呼び出し処理を続行してください。(それは、鳴らす加入者の電話をもたらすでしょう)。
2b. If the comparison fails, instruct the SSP to route the
call to the redirected URI.
2b。 比較が失敗するなら、向け直されたURIに呼び出しを発送するようSSPに命令してください。
3. Else, for a 2xx response, follow the steps in section 5.4.3.
3. 2xx応答のために、ほかに、セクション5.4.3における方法に従ってください。
5.4.3. Accepting an ICW session using VoIP
5.4.3. VoIPを使用することでICWセッションを受け入れます。
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は加入者(訪問される人)がこのオプションを選ぶなら知る方法を全く先験的にしません。 それにもかかわらず、それは、INVITE要求のボディーでSDPを加えることによって、そのような選択を説明しなければなりません。 これを達成する可能な方法はSPIRITS notifierがPSTNゲートウェイを制御して、それに関する適切なリソースを割り当てるのを持つことです。 これがいったん完了していると、SPIRITS notifierはボディーのSDP部分としてINVITE要求でネットワーク情報(メディアが受け取られるゲートウェイとポートナンバーのIPアドレス)とコーデック情報を加えます。 SPIRITSは、DP情報がまた、要求本体で運ばれるのを必要とします。 また、その程度まで、SPIRITS notifierはサービスの引き金となったTDPに関連している情報を加えなければなりません。 したがって、INVITE MUSTのボディーは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はINVITE要求を加入者に伝えて、現在、最終的な応答を待ちます。 SPIRITS加入者が200OKを返すとき、以下の通りさらなる処理を扱わなければなりません:
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を含む200OKの領収書の上では、SPIRITS notifierは、ゲートウェイの上のあらかじめ割り当てられたポートで呼び出しを終えるようSSPに命令するでしょう。 このポートは以前のINVITEで送られたSDPへのゲートウェイによって関連させられなければなりません。
Gurbani, et al. Standards Track [Page 28] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[28ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
The end result is that the caller and callee hold a voice session with part of the session occurring over VoIP.
結末は訪問者と訪問される人がVoIPの上に起こるセッションの一部との声のセッションを開催するということです。
6. Non-call related events
6. 非呼び出しの関連する出来事
There are network events that are not related to setting up, maintaining, or tearing down voice calls. Such events occur on the cellular wireless network and can be used by SPIRITS to provide services. The SPIRITS protocol requirement explicitly includes the following events for which SPIRITS notification is needed (RFC3298:Section 5(b)):
音声通話を維持するか、または取りこわして、セットアップすると関連しないネットワークイベントがあります。 そのような出来事を、セルワイヤレス・ネットワークに起こって、SPIRITSは、サービスを提供するのに使用できます。 SPIRITSプロトコル要件が明らかに、SPIRITS通知が必要である以下の出来事を含んでいる、(RFC3298: セクション5(b)):
1. Location update in the same Visitor Location Register (VLR)
service area
1. 同じVisitor Location Register(VLR)サービスエリアでの位置のアップデート
2. Location update in another VLR service area
2. 別のVLRサービスエリアでの位置のアップデート
3. International Mobile Subscriber Identity (IMSI) attach
3. 移動加入者識別番号(IMSI)は付きます。
4. Mobile Subscriber (MS) initiated IMSI detach
4. Subscriber(MS)の開始しているIMSIが取り外すモバイル
5. Network initiated IMSI detach
5. 開始しているIMSIが取り外すネットワーク
6.1. Non-call events and their required parameters
6.1. 非呼び出し出来事とそれらの必要なパラメタ
Each of the five non-call related event is given a SPIRITS-specific mnemonic for use in subscriptions and notifications.
購読と通知におけるSPIRITS特有のニーモニックが関連する出来事に与えられているそれぞれの5非呼び出し使用。
Location update in the same VLR area SPIRITS mnemonic: LUSV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
同じVLR領域SPIRITSニーモニックにおける位置のアップデート: 中のLUSV Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber、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: 五弦は以前はよく給仕Cell-IDを特定していました。 このパラメタの実際の長さと表現はセルプロバイダーのネットワークの子細に依存します。
Location update in different VLR area SPIRITS mnemonic: LUDV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
異なったVLR領域SPIRITSニーモニックにおける位置のアップデート: 中のLUDV Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber、Cell ID
IMSI attach SPIRITS mnemonic: REG Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
IMSIはSPIRITSニーモニックを付けます: 中のREG Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber、Cell ID
Gurbani, et al. Standards Track [Page 29] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[29ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
MS initiated IMSI detach SPIRITS mnemonic: UNREGMS Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
MSの開始しているIMSIはSPIRITSニーモニックを取り外します: 中のUNREGMS Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber
Network initiated IMSI detach SPIRITS mnemonic: UNREGNTWK Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
ネットワークの開始しているIMSIはSPIRITSニーモニックを取り外します: 中のUNREGNTWK Mandatoryパラメタ、登録: NOTIFYのCalledPartyNumber Mandatoryパラメタ: CalledPartyNumber
6.2. Normative usage
6.2. 標準の用法
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.
加入者は得るそれが通知を関心がある1セットの非呼び出しの関連するPSTN出来事を特定する要求を登録に出すでしょう。 このセットがちょうど1回の出来事を含むかもしれませんか、またはそれは複数の出来事を含むかもしれません。 登録、要求はそうです。notifierにそれがうまくいっている認証まで受け入れられるところに発送されます。
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.
対話が設立した、登録、通常、期限が切れるまで固執しているか、または加入者によって明らかに吐き出されます。 この振舞いは購読のための振舞いが「スピリッツ-INDPs」パッケージと交際したより異なっています。 セルラー・ネットワークでは、ワイヤーラインネットワークと比べて、予約された出来事はそれらよりはるかに大きい頻度で起こるかもしれません(携帯ユーザが動き回るとき、位置のアップデートを考えてください)。 したがって、通常、購読が期限が切れるのを許容するのははるかに好都合です。
When a subscriber receives a NOTIFY request, it can subsequently choose to act in a manner appropriate to the notification.
加入者がNOTIFY要求を受け取るとき、それは、次に、方法で通知に適切に行動するのを選ぶことができます。
The remaining sections fill in the specific package responsibilities raised in RFC3265 [3], Section 4.4.
残っているセクションはRFC3265[3]、セクション4.4で上げられた特定のパッケージ責任に記入します。
6.3. Event package name
6.3. イベントパッケージ名
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
このドキュメントは2個のイベントパッケージを定義します。 1番目はセクション5.3で定義されました。 パッケージであって、このセクションで定義された2番目は「スピリッツユーザ教授」と呼ばれます。 セルラー・ネットワークで非呼び出しの関連する出来事に対応する出来事にこのパッケージを使用しなければなりません。 SPIRITSプロトコルを実行して、非呼び出しを支持するすべての実体がSPIRITSプロトコル要件に概説された出来事を関係づけました。
Gurbani, et al. Standards Track [Page 30] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[30ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
(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.
(RFC3298: セクション5(b))が「出来事」ヘッダー要求ヘッダー[3]を「スピリッツユーザ教授」に設定しなければならない、「出来事を許容する、」 一般的なヘッダー[3]はまた、象徴「スピリッツユーザ教授」を入れなければなりません。
Example:
例:
Event: spirits-user-prof Allow-Events: spirits-user-prof, spirits-INDPs
出来事: スピリッツユーザ教授Allow-出来事: スピリッツユーザ教授、スピリッツ-INDPs
6.4. Event package parameters
6.4. イベントパッケージパラメタ
The "spirits-user-prof" event package does not support any additional parameters to the Event header
「スピリッツユーザ教授」イベントパッケージはどんな追加パラメタもEventヘッダーに支持しません。
6.5. SUBSCRIBE bodies
6.5. 登録、ボディー
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で登録、要求、または5月を複数の出来事に申し込むかもしれない、問題、a異なる、登録、受け取るそれは通知を関心がある各出来事のために、要求します。 プロトコルは両方の形式の表現を考慮します。 しかしながら、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.
SPIRITSのSUBSCRIBEsのためのデフォルトボディータイプは「アプリケーション/スピリッツ出来事+はxmlする」MIMEの種類によって指示されます。 存在しているなら、「受け入れてください」というヘッダーはこのMIMEの種類を入れなければなりません。
6.6. Subscription duration
6.6. 購読持続時間
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].
登録によって対話が確立された加入者とnotifierの間で交渉された満了時間要求が制限される確立された対話の持続時間。 加入者が新しい状態でaを送らなければならない、登録、リフレッシュするために、対話はそれであるならそれを生かしたがっています。 新しい状態でaを送ることによって対話を終えることができる、登録、「期限が切れること」で0のヘッダー値を要求してください、[3]に概説されているように。
Gurbani, et al. Standards Track [Page 31] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[31ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
6.7. NOTIFY bodies
6.7. NOTIFYボディー
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:
「スピリッツユーザ教授」パッケージを求めるNOTIFY要求におけるボディーは任意です。 存在しているなら、それらは「アプリケーション/スピリッツイベント+はxmlする」MIMEの種類のものであるに違いありません。 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が生成されているイベントに関連しているパラメタの値のリスト。 現実の出来事によって、パラメタのリストは異なるでしょう。
6.8. Notifier processing of SUBSCRIBE requests
6.8. より多くのNotifierに処理する、登録、要求
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.
notifierが登録を受けたら要求を認証しなければならないよう要求してください、そして、加入者が加入されるリソースにアクセスするのに権限を与えられるのを確実にしてください、この場合、携帯電話のための非呼び出しの関連するセルイベント。
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.
一度、登録、認証されて、認可された要求、携帯電話の番号に対応するHLRのセットマークへのインタフェースDの上のSCFとのインタフェースが中に含んだnotifier、登録、ボディー。 このドキュメントの範囲の外にインタフェースDの子細があります。 ここで、私たちは、notifierが適切なマークをHLRにはめ込むことができると単に思います。
6.9. Notifier generation of NOTIFY requests
6.9. NOTIFY要求のNotifier世代
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".
notifierが撮影へのそれが200msより202応答を送らなければならない、HLRでマークの設定を予想する、登録、購読を受け入れて、すぐに、要求します。 そして、それは空のボディーのNOTIFY要求を送るべきです。 このNOTIFY要求には、「購読状態」ヘッダーが「未定」の値と共になければなりません。
This immediate NOTIFY with an empty body is needed since the
resource identified in the SUBSCRIBE request does not have as yet
a meaningful state.
登録、要求はそうしません。中で特定されたリソース以来空のボディーのこの即座のNOTIFYが必要である、まだ、重要な状態を持ってください。
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."
notifierがいったん首尾よくSCFに連結すると、それは空のボディーと「アクティブ」の値がある「購読状態」ヘッダーと共にその後のNOTIFY要求を送らなければなりません。
Gurbani, et al. Standards Track [Page 32] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[32ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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.
興味があるイベントがコネを特定した、登録、要求は現れて、notifierはセクション6.7で説明されるようにボディーを含まなければならない新しいNOTIFY要求を出します。
6.10. Subscriber processing of NOTIFY requests
6.10. NOTIFY要求の加入者処理
The exact steps executed at the subscriber when it receives a NOTIFY request depend on the nature of the service that is being implemented. As a generality, the UA associated with the subscriber should somehow impart this information to the user by visual or auditory means, if at all possible.
NOTIFY要求を受け取るとき加入者で実行された正確なステップは実装されているサービスの本質によります。 できれば、一般性として、加入者に関連しているUAは視覚の、または、聴力の手段でこの情報をユーザにどうにか伝えるはずです。
6.11. Handling of forked requests
6.11. 股状の要求の取り扱い
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つの要素で目標セットをもたらすべきです: notifier。
6.12. Rate of notifications
6.12. 通知の速度
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.
輻輳制御の理由で、通知の速度が過度にならないのは、重要です。 例えば、加入者がセルラー・ネットワークを通して十分速い速度で移行するnotifierのために位置のアップデートイベントに加入するなら、notifierが小さい時間枠での多くのNOTIFY要求を生成するのが完全に想像できます。 したがって、このパッケージの中では、位置のアップデートイベントは適切な阻止メカニズムを必要とします。
Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST start a timer (Tn) with a value of 15 seconds. If a subsequent location update NOTIFY request needs to be sent out before the timer has expired, it MUST be discarded. Any future location update NOTIFY requests MUST be transmitted only if Tn has expired (i.e. 15 seconds have passed since the last NOTIFY request was send out). If a location update NOTIFY is send out, Tn should be reset to go off again in 15 seconds.
SPIRITS notifierが位置のアップデートNOTIFYを送るときはいつも、それは15秒の値からタイマ(Tn)を始動しなければなりません。 NOTIFYが要求するその後の位置のアップデートが、タイマが期限が切れる前に出される必要があるなら、それを捨てなければなりません。 Tnが期限が切れた場合にだけ(最後のNOTIFY要求が出すことであった時から、すなわち、15秒が経過しています)、どんな今後の位置のアップデートNOTIFY要求も伝えなければなりません。 位置であるならアップデートNOTIFYが出すことである、Tnは、15秒以降再び去るためにリセットされるべきです。
6.13. State agents
6.13. 州のエージェント
State agents are not used in SPIRITS.
州のエージェントはSPIRITSで使用されません。
6.14. Examples
6.14. 例
This section contains an example of a SPIRITS service that may be used to update the presence status of a mobile user. The call flow is depicted in Figure 4 below.
このセクションはモバイルユーザの存在状態をアップデートするのに利用されるかもしれないSPIRITSサービスの例を含みます。 呼び出し流動は以下の図4に表現されます。
Gurbani, et al. Standards Track [Page 33] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[33ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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
SPIRITSサーバSPIRITSクライアントSCF(「加入者」)("notifier")S N| | | | F1は申し込まれます。| | +--------------------->+| | | | | | F2セットHLRマーク| | F3 200は(代理をします)+を承認します。--------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| F4は通知します。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | F5 200OK(NOT)| | +--------------------->|、|、|、|、| ~ ~ ~ ~ ~ ~ | | F6 Evt。 . | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | F7は+に通知します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| F8 200OK(NOT)| | +--------------------->|、|、|、|、|、|、|、| \|/ \|/ \|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)に加入します。
Gurbani, et al. Standards Track [Page 34] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[34ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
F1: S->N SUBSCRIBE sip:myprovider.com SIP/2.0 From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com> CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8 Expires: 3600 Event: spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
F1: S>N、一口: 登録、myprovider.com SIP/2.0From: <一口: vkg@example.com 、gt;、;=8177-afd-991To:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、CSeq: 18992 呼び出しIDを申し込んでください: 3329as77@host.example.com 接触: <一口: vkg@host.example.com 、gt;、以下を通って 一口/2.0/UDP host.example.com; ブランチ=z9hG4bK776asdhdsa8は期限が切れます: 3600年のイベント: スピリッツユーザ教授Allow-イベント: スピリッツ-INDPs、スピリッツユーザ教授Accept: アプリケーション/スピリッツイベント+xmlコンテントタイプ: アプリケーション/スピリッツイベント+xml Content-長さ: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><スピリッツイベントxmlnsが等しい、「"userprof"つぼ:ietf:params: <Eventがタイプするxml:ナノ秒:スピリッツの1インチの>=名=、「REG「><CalledPartyNumber>6302240216</CalledPartyNumber>イベント></スピリッツ</イベント>」
The subscription reaches the notifier which authenticates the request (not shown) and interacts with the SCF to update the subscribers database for this event. The notifier sends out a successful response to the subscription:
購読は要求(目立たない)を認証して、このイベントのための加入者データベースをアップデートするためにSCFと対話するnotifierに達します。 notifierは購読へのうまくいっている応答を出します:
F3: N->S SIP/2.0 200 OK From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8 Expires: 3600 Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Length: 0
F3: N>S一口/2.0 200OK From: <一口: vkg@example.com 、gt;、;=8177-afd-991To:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、; =スピリッツ-REG-16302240216 CSeqにタグ付けをしてください: 18992 呼び出しIDを申し込んでください: 3329as77@host.example.com 接触: <一口: 以下を通ってnotifier.myprovider.com>。 一口/2.0/UDP host.example.com; ブランチ=z9hG4bK776asdhdsa8は期限が切れます: 3600 イベントを許容します: スピリッツ-INDPs、スピリッツユーザ教授Accept: アプリケーション/スピリッツイベント+xml Content-長さ: 0
The notifier also sends out a NOTIFY request confirming the subscription:
また、notifierは購読を確認しながら、NOTIFY要求を出します:
F4: N->S NOTIFY sip:vkg@host.example.com SIP/2.0 To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9121 NOTIFY
F4: N>SのNOTIFY一口: vkg@host.example.com SIP/2.0To: <一口: vkg@example.com 、gt;、;=8177-afd-991From:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、; =スピリッツ-REG-16302240216 CSeqにタグ付けをしてください: 9121に通知します。
Gurbani, et al. Standards Track [Page 35] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[35ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Subscription-State: active Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Length: 0
呼び出しID: 3329as77@host.example.com 接触: <一口: notifier.myprovider.com>購読州: アクティブなVia: 一口/2.0/UDP notifier.myprovider.com; ブランチはz9hG4bK7007-091aとイベントを許容して等しいです: スピリッツ-INDPs、スピリッツユーザ教授Accept: アプリケーション/スピリッツイベント+xml Content-長さ: 0
The subscriber confirms the receipt of the NOTIFY request:
加入者はNOTIFY要求の領収書を確認します:
F5: S->N SIP/2.0 200 OK To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9121 NOTIFY Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a Content-Length: 0
F5: S>N一口/2.0 200OK To: <一口: vkg@example.com 、gt;、;=8177-afd-991From:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、; =スピリッツ-REG-16302240216 CSeqにタグ付けをしてください: 9121は呼び出しIDに通知します: 3329as77@host.example.com 接触: <一口: vkg@host.example.com 、gt;、以下を通って 一口/2.0/UDP notifier.myprovider.com; ブランチはz9hG4bK7007-091aコンテンツの長さと等しいです: 0
In F6, the mobile user identified by the PSTN number "6302240216" turns the mobile phone on, thus causing it to register with the cellular network. The cellular network detects this event, and since a subscriber has indicated an interest in receiving a notification of this event, a SIP NOTIFY request is transmitted towards the subscriber:
F6では、PSTN番号「6302240216」によって特定されたモバイルユーザは携帯電話をつけます、その結果、セルラー・ネットワークとともに記名することを引き起こします。 セルラー・ネットワークはこのイベントを検出します、そして、加入者がこのイベントの通知を受け取ることへの関心を示したので、SIP NOTIFY要求は加入者に向かって伝えられます:
F7: N->S NOTIFY sip:vkg@host.example.com SIP/2.0 To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9122 NOTIFY Call-ID: 3329as77@host.example.com Contact: <sip:notifier.myprovider.com> Subscription-State: terminated;reason=fired Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12 Event: spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
F7: N>SのNOTIFY一口: vkg@host.example.com SIP/2.0To: <一口: vkg@example.com 、gt;、;=8177-afd-991From:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、; =スピリッツ-REG-16302240216 CSeqにタグ付けをしてください: 9122は呼び出しIDに通知します: 3329as77@host.example.com 接触: <一口: notifier.myprovider.com>購読州: 終わり、; 理由=はViaを首にしました: 一口/2.0/UDP notifier.myprovider.com; ブランチはz9hG4bK7yi-p12イベントと等しいです: スピリッツユーザ教授Allow-イベント: スピリッツ-INDPs、スピリッツユーザ教授Accept: アプリケーション/スピリッツイベント+xmlコンテントタイプ: アプリケーション/スピリッツイベント+xml Content-長さ: ...
Gurbani, et al. Standards Track [Page 36] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[36ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<Cell-ID>45987</Cell-ID>
</Event>
</spirits-event>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><スピリッツイベントxmlnsが等しい、「"userprof"つぼ:ietf:params: <Eventがタイプするxml:ナノ秒:スピリッツの1インチの>=名=、「REG「><CalledPartyNumber>6302240216CalledPartyNumber><Cell</ID>45987Cell</ID>イベント></スピリッツ</イベント>」
The subscriber receives the notification and acknowledges it by sending a response:
加入者は、通知を受け取って、応答を送ることによって、それを承認します:
F8: S->N
F8: S>N
SIP/2.0 200 OK To: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 CSeq: 9122 NOTIFY Call-ID: 3329as77@host.example.com Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12 Content-Length: 0
一口/2.0 200OK To: <一口: vkg@example.com 、gt;、;=8177-afd-991From:にタグ付けをしてください <一口: 16302240216@myprovider.com 、gt;、; =スピリッツ-REG-16302240216 CSeqにタグ付けをしてください: 9122は呼び出しIDに通知します: 以下を通って 3329as77@host.example.com 一口/2.0/UDP notifier.myprovider.com; ブランチはz9hG4bK7yi-p12コンテンツの長さと等しいです: 0
Note that once the subscriber has received this notification, it can execute appropriate services. In this particular instance, an appropriate service may consist of the subscriber acting as a composer of a presence service and turning the presence status of the user associated with the phone number "6302240216" to "on". Also note in F7 that the notifier included a Cell ID in the notification.
加入者がいったんこの通知を受け取る後、適切なサービスを実行できることに注意してください。 この特定のインスタンスでは、適切なサービスは“on"に存在サービスとユーザの存在状態を変える作曲家が電話番号「6302240216」と交際しながら行動している加入者から成るかもしれません。 また、F7でnotifierが通知にCell 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.
位置の特定のサービスの基礎としてCell IDを使用できます。 しかしながら、このドキュメントの範囲の外にそのようなサービスの議論があります。
6.15. Use of URIs to retrieve state
6.15. 状態を検索するURIの使用
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.
「スピリッツユーザ教授」パッケージは、状態を検索するのにURIを使用してはいけません。 このパッケージのためのほとんどの州の情報がSIPメッセージをうまくはめ込むことができるくらいコンパクトであると予想されます。 しかしながら、知られているなら経路MTUの200バイト以内で要求のサイズがあるか、または要求サイズが1300バイトより大きいなら、実装は、警告の側で間違えるのに、[5]についてセクション18.1.1に概説されたコンベンションに続いて、混雑の制御輸送を使用しなければなりません、そして、経路MTUは未知です。
Gurbani, et al. Standards Track [Page 37] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[37ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
7. IANA Considerations
7. IANA問題
This document calls for IANA to:
このドキュメントは、以下のことようにIANAは求めます。
o register two new SIP Event Packages per [3].
o 1[3]あたり2つの新しいSIP Eventパッケージを登録してください。
o register a new MIME type per [20].
o 1[20]あたり1つの新しいMIMEの種類を登録してください。
o register a new namespace URN per [16].
o 1[16]あたりのURNに新しい名前空間を登録してください。
o register a new XML schema per [16].
o 1[16]あたり1つの新しいXML図式を登録してください。
7.1. Registering event packages
7.1. イベントパッケージを登録します。
Package Name: spirits-INDPs
名前をパッケージしてください: スピリッツ-INDPs
Type: package
以下をタイプしてください。 パッケージ
Contact: Vijay K. Gurbani, vkg@lucent.com
接触: ビジェイK.Gurbani、 vkg@lucent.com
Reference: RFC 3910
参照: RFC3910
Package Name: spirits-user-prof
名前をパッケージしてください: スピリッツユーザ教授
Type: package
以下をタイプしてください。 パッケージ
Contact: Vijay K. Gurbani, vkg@lucent.com
接触: ビジェイK.Gurbani、 vkg@lucent.com
Reference: RFC 3910
参照: RFC3910
7.2. Registering MIME type
7.2. MIMEの種類を登録します。
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: spirits-event+xml
MIME「副-タイプ」は以下を命名します。 スピリッツイベント+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: charset (same semantics of charset parameter in application/xml [9])
任意のパラメタ: charset(アプリケーション/xml[9])のcharsetパラメタの同じ意味論
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.
相互運用性問題: なし。
Gurbani, et al. Standards Track [Page 38] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[38ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
Published specifications: this document.
広められた仕様: このドキュメント。
Applications which use this media type: SPIRITS aware entities which adhere to this document.
このメディアタイプを使用するアプリケーション: このドキュメントを固く守るSPIRITSの意識している実体。
Additional information:
追加情報:
Magic number(s): none.
マジックナンバー(s): なし。
File extension(s): none.
ファイル拡張子(s): なし。
Macintosh file type code(s): none.
マッキントッシュファイルタイプは(s)をコード化します: なし。
Object Identifier(s) or OID(s): none.
識別子かOID(s)が反対します: なし。
Person and email address for further information: Vijay K. Gurbani, <vkg@lucent.com>
詳細のための人とEメールアドレス: ビジェイK.Gurbani、 <vkg@lucent.com 、gt。
Intended usage: Common
意図している用法: 一般的
Author/Change controller: The IETF
コントローラを書くか、または変えてください: IETF
7.3. Registering URN
7.3. つぼを登録します。
URI
urn:ietf:params:xml:ns:spirits-1.0
URIつぼ:ietf:params:xml:ナノ秒: スピリッツ-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.
記述Thisはこのドキュメントによって定義されたXML要素のためのXML名前空間URIです。 そのような要素は「イベント+xmlにアプリケーション/生気を与えている」content typeにおけるSPIRITS情報について説明します。
Registrant Contact IESG.
記入者接触IESG。
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for SPIRITS-related information</title>
</head>
<body>
<h1>Namespace for SPIRITS-related information</h1>
XML BEGIN<?xmlバージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」><html xmlns=内容=「テキスト/html; スピリッツ関連の情報</h1>のためのスピリッツ関連の情報</タイトル></ヘッド><ボディー><h1>名前空間のためのcharset=utf-8インチの/><タイトル>名前空間」
Gurbani, et al. Standards Track [Page 39] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[39ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
<h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
</body>
</html>
END
「<h2>アプリケーション/スピリッツイベント+xml</h2><p>See<a href=」[[発行されたRFCのURL]]] 「>RFC3910</a></p></ボディー></html>END」
7.4. Registering XML schema
7.4. XML図式を登録します。
URI
urn:ietf:params:xml:schema:spirits-1.0
URIつぼ:ietf:params:xml:図式: スピリッツ-1.0
Description XML base schema for SPIRITS entities.
記述XMLはSPIRITS実体のための図式を基礎づけます。
Registrant Contact IESG.
記入者接触IESG。
XML Please see XML schema definition in Section 9 of this document.
XML Pleaseはこのドキュメントのセクション9とのXML図式定義を見ます。
8. Security Considerations
8. セキュリティ問題
This section focuses on security considerations which are unique to SPIRITS. SIP security mechanisms are discussed in detail in the core SIP specification [5] and are outside the scope of this document. SPIRITS security mechanisms are based on and strengthen SIP security [5], for example, SPIRITS mandates the support of S/MIME. Beyond that, any other security solutions specified in [5], i.e., TLS or HTTP Digest authentication, may be utilized by SPIRITS operators.
このセクションはSPIRITSにユニークなセキュリティ問題に焦点を合わせます。 SIPセキュリティー対策は、コアSIP仕様[5]で詳細に議論して、このドキュメントの範囲の外にあります。 SPIRITSセキュリティー対策は、SIPセキュリティ[5]をに基礎づけていて、強化します、例えば、SPIRITSはS/MIMEのサポートを強制します。 それを超えて、[5]で指定されたいかなる他のセキュリティソリューション(すなわち、TLSかHTTP Digest認証)も、SPIRITSオペレータによって利用されるかもしれません。
As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the following security aspects are applicable to the SPIRITS protocol:
RFC3298[4]の第9章(セキュリティConsideration)に概説されているように、以下のセキュリティ局面はSPIRITSプロトコルに適切です:
Authentication
認証
Integrity
保全
Confidentiality
秘密性
Non-repudiation
非拒否
The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B, C, D, and E. Of these, only two -- B and C -- are of interest to SPIRITS. Interfaces A and E are PINT interfaces and are thus assumed secured by the PINT RFC [8]. Security for interface D is out of scope in this document since it deals primarily with the PSTN infrastructure. We will discuss security aspects on interfaces B and C predicated on certain assumptions.
図1のSPIRITSアーキテクチャは5つのインタフェースを含んでいます--A、B、C、D、およびE.Of、これら(2(BとC)だけ)はSPIRITSに興味があります。 PINT RFC[8]によって機密保護されて、インタフェースAとEは、PINTインタフェースであり、このようにして想定されます。 本書では主としてPSTNインフラストラクチャに対処するので、範囲の外にインタフェースDへのセキュリティがあります。 私たちはある前提で叙述されたインタフェースBとCのセキュリティ局面について議論するつもりです。
Gurbani, et al. Standards Track [Page 40] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[40ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
A driving assumption for SPIRITS security is that the SPIRITS gateway is owned by the same PSTN operator that owns the SPIRITS notifier. Thus, it is attractive to simply relegate security of interface C to the PSTN operator, and in fact, there are merits to doing just that since interface C crosses the IP Network and PSTN boundaries. However, a closer inspection reveals that both interfaces B and C transmit the SPIRITS protocol; thus, any security arrangement we arrive at for interface B can be suitably applied to interface C as well. This makes it possible to secure interface C in case the SPIRITS gateway is not owned by the same PSTN operator that owns the SPIRITS notifier.
SPIRITSセキュリティのための運転する仮定はSPIRITSゲートウェイがSPIRITS notifierを所有しているのと同じPSTNオペレータによって所有されているということです。 したがって、単にインタフェースCのセキュリティをPSTNオペレータに左遷するのが魅力的であり、事実上、インタフェースCがIP NetworkとPSTN境界に交差しているのでまさしくそれをすることへの長所があります。 しかしながら、より厳密な点検は、インタフェースBとCの両方がSPIRITSプロトコルを伝えるのを明らかにします。 したがって、また、Cを連結するように適当に私たちがインタフェースBに到着するどんなセキュリティアレンジメントも適用できます。 これで、SPIRITSゲートウェイが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ゲートウェイのような)と、同じ仲介者とのコミュニケーションと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プロトコルの秘密性は、プロトコルデータ単位で運ばれた情報が敏感な本質のものであるので不可欠であり、非認可されたパーティーに明らかにされるなら、プライバシーの問題に通じるかもしれません。 プライバシーの問題を軽減するためにS/MIME[18]を通してSPIRITS notifierとSPIRITS加入者の間の通信路を保証するべきです、コアSIP仕様[5]のSecurity Consideration部で説明されるように。
S/MIME is an end-to-end security mechanism which encrypts the
SPIRITS bodies for transit across an open network. Intermediaries
need not be cognizant of S/MIME in order to route the messages
(routing headers travel in the clear).
S/MIMEは終わりから終わりへのトランジットのためにオープンネットワークの向こう側にSPIRITSボディーを暗号化するセキュリティー対策です。 仲介者は、メッセージを発送するためにS/MIMEを認識している必要はありません(ルーティングヘッダーは明確を旅行します)。
S/MIME provides all the security aspects for SPIRITS outlined at the beginning of this section: authentication, message integrity, confidentiality, and non-repudiation. Authentication properties provided by S/MIME would allow the recipient of a SPIRITS message to ensure that the SPIRITS payload was generated by an authorized entity. Encryption would ensure that only those SPIRITS entities possessing a particular decryption key are capable of inspecting encapsulated SPIRITS bodies in a SIP request.
S/MIMEはこのセクションの始めに概説されたSPIRITSにすべてのセキュリティ局面を供給します: 認証、メッセージの保全、秘密性、および非拒否。 S/MIMEによって提供された認証資産はSPIRITSペイロードが権限のある機関によって生成されたのを保証するSPIRITSメッセージの受取人を許容するでしょう。 暗号化は、特定の復号化キーを所有しているそれらのSPIRITS実体だけがSIP要求でSPIRITSボディーであるとカプセル化された点検できるのを確実にするでしょう。
All SPIRITS endpoints MUST support S/MIME signatures (CMS SignedData) and MUST support encryption (CMS EnvelopedData).
すべてのSPIRITS終点が、S/MIMEが署名(CMS SignedData)であるとサポートしなければならなくて、暗号化(CMS EnvelopedData)をサポートしなければなりません。
If the B and C interfaces are owned by the same PSTN operator, it is possible that public keys will be installed in the SPIRITS endpoints.
BとCインタフェースが同じPSTNオペレータによって所有されているなら、公開鍵がSPIRITS終点にインストールされるのは、可能です。
Gurbani, et al. Standards Track [Page 41] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[41ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
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つのメソッド(issuerAndSerialNumberとsubjectKeyIdentifier)をサポートします。 これらの間では、subjectKeyIdentifierはX.509証明書とまた、他の体系で働いていますが、issuerAndSerialNumberはX.509証明書だけで働いています。 手続き上の手段で保全を提供して、管理者が必要な公開鍵を構成するなら、X.509証明書なしでS/MIMEを使用できます。
All requests (and responses) between SPIRITS entities MUST be encrypted.
SPIRITS実体の間のすべての要求(そして、応答)を暗号化しなければなりません。
When a request arrives at a SPIRITS notifier from a SPIRITS subscriber, the SPIRITS notifier MUST authenticate the request. The subscription (or registration) from a SPIRITS subscriber MUST be rejected if the authentication fails. If the SPIRITS subscriber successfully authenticated itself to the SPIRITS notifier, the SPIRITS notifier MUST, at the very least, ensure that the SPIRITS subscriber is indeed allowed to receive notifications of the events it is subscribing to.
要求がSPIRITS加入者からSPIRITS notifierに到着すると、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)を通して、または、ある種のウェブインタフェースを通してそれはあるかもしれません。
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加入者までの要求を認証しなければなりません、悪意があるパーティーが、セッションをハイジャックするために不正にSPIRITS notifierのふりをするのを試みるといけないので。
9. XML schema definition
9. XML図式定義
The SPIRITS payload is specified in XML; this section defines the base XML schema for documents that make up the SPIRITS payload. All SPIRITS entities that transport a payload characterized by the MIME type "application/spirits-event+xml" MUST support documents corresponding to the base schema below.
SPIRITSペイロードはXMLで指定されます。 このセクションはSPIRITSペイロードを作るドキュメントのためにベースXML図式を定義します。 「アプリケーション/スピリッツイベント+はxmlする」MIMEの種類によって特徴付けられたペイロードを輸送するすべてのSPIRITS実体が以下のベース図式に対応するドキュメントを支えなければなりません。
Multiple versions of the base schema are not expected; rather, any additional functionality (e.g., conveying new PSTN events) must be accomplished through the definition of a new XML namespace and a corresponding schema. Elements from the new XML namespace will then co-exist with elements from the base schema in a document.
ベース図式の複数のバージョンは予想されません。 むしろ、新しいXML名前空間と対応する図式の定義でどんな追加機能性(例えば、新しいPSTNイベントを伝える)も達成しなければなりません。 そして、新しいXML名前空間からのElementsはドキュメントのベース図式から要素と共存するでしょう。
Gurbani, et al. Standards Track [Page 42] RFC 3910 SPIRITS Protocol October 2004
Gurbani、他 標準化過程[42ページ]RFC3910スピリッツは2004年10月に議定書を作ります。
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs: 図式targetNamespaceは「つぼ:ietf:params:xml:ナノ秒: 1インチに生気を与えさせているxmlns: tns=」つぼ:ietf:params:xml:ナノ秒: 1インチに生気を与えさせているxmlnsと等しいです: " http://www.w3.org/2001/XMLSchema "xs=elementFormDefaultが「適切な」attributeFormDefault=と等しい、「資格のない">"
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!--この輸入はXML言語属性xml: langを持って入ります--><xs: 輸入名前空間=" 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>
xml: <xs: 注釈><xs: ドキュメンテーションlangが等しい、「アン「>Describes SPIRITSイベント。」 </xs: ドキュメンテーション></xs: 注釈>。
<xs:element name="spirits-event" type="tns:SpiritsEventType"/>
<xs: 要素名前=「スピリッツイベント」タイプは「tns: SpiritsEventType」/>と等しいです。
<xs:complexType name="SpiritsEventType">
<xs:sequence>
<xs:element name="Event" type="tns:EventType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
「xs: complexTypeが命名する<=「SpiritsEventTypeの「><xs: 系列><xs: 要素名=の」 イベント」 タイプ=「tns: EventType」minOccurs=「1インチのmaxOccurs=」限りない」/><xs: どんな名前空間=も」##他」のprocessContents=maxOccurs=「限りない」「手緩い」/></xs: 系列></xs: complexType>。
<xs:complexType name="EventType">
<xs:sequence>
<xs:element name="CalledPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="CallingPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="DialledDigits" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cell-ID" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cause" type="tns:CauseType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="type" type="tns:PayloadType"
use="required"/>
<xs:attribute name="name" type="tns:EventNameType"
use="required"/>
<xs:attribute name="mode" type="tns:ModeType"
use="optional" default="N"/>
</xs:complexType>
<xs:complexType 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>
Gurbani, et al. Standards Track [Page 43] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 43] RFC 3910 SPIRITS Protocol October 2004
<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="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="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:simpleType name="ModeType"> <!-- One of two values: "N"otification or "R"equest --> <xs:restriction base="xs:string">
Gurbani, et al. Standards Track [Page 44] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 44] RFC 3910 SPIRITS Protocol October 2004
<xs:enumeration value="N"/>
<xs:enumeration value="R"/>
</xs:restriction>
</xs:simpleType>
<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>
<xs:simpleType name="CauseType"> <xs:restriction base="xs:string"> <xs:enumeration value="Busy"/> <xs:enumeration value="Unreachable"/> </xs:restriction> </xs:simpleType> </xs:schema>
10. Acknowledgements
10. Acknowledgements
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.
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.
11. Acronyms
11. Acronyms
ACL Access Control List CS Capability Set DP Detection Point DTD Document Type Definition EDP Event Detection Point EDP-N Event Detection Point "Notification" EDP-R Event Detection Point "Request" IANA Internet Assigned Numbers Authority ICW Internet Call Waiting IMSI International Mobile Subscriber Identity IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol ISP Internet Service Provider ITU International Telecommunications Union MIME Multipurpose Internet Mail Extensions MS Mobile Station (or Mobile Subscriber) OBCSM Originating Basic Call State Model PIC Point In Call PINT PSTN/Internet Interworking PSTN Public Switched Telephone Network SCF Service Control Function
ACL 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
Gurbani, et al. Standards Track [Page 45] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 45] RFC 3910 SPIRITS Protocol October 2004
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
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
12. References
12. References
12.1. Normative References
12.1. Normative References
[1] Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The
SPIRITS Architecture", RFC 3136, June 2001.
[1] Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The SPIRITS Architecture", RFC 3136, June 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[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., and L. Slutsman, "Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements", RFC 3298, August 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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
12.2. Informative References
12.2. Informative References
[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, and J. Dobrowolski, "On selection of IN parameters to be carried by the SPIRITS Protocol", Work In Progress, January 2003.
Gurbani, et al. Standards Track [Page 46] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 46] RFC 3910 SPIRITS Protocol October 2004
[7] Intelligent Network Capability Set 2. ITU-T, Recommendation
Q.1228.
[7] Intelligent Network Capability Set 2. ITU-T, Recommendation 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: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[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., and L. Robart, "Pre-Spirits Implementations of PSTN-initiated Services", RFC 2995, November 2000.
[11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[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] 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/>.
[13] "Interface recommendations for intelligent network capability
set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June
2000.
[13] "Interface recommendations for intelligent network capability set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June 2000.
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[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] 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>.
[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 Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[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, and N.Shah, "The Intelligent Network Standards: Their Application to Services", McGraw-Hill, 1997.
Gurbani, et al. Standards Track [Page 47] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 47] RFC 3910 SPIRITS Protocol October 2004
[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. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text ", RFC
2047, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
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., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
13. Contributors
13. Contributors
Kumar Vemuri Lucent Technologies, Inc. 2000 Naperville Rd. Naperville, IL 60566 USA
Kumar Vemuri Lucent Technologies, Inc. 2000 Naperville Rd. Naperville, IL 60566 USA
EMail: vvkumar@lucent.com
EMail: vvkumar@lucent.com
14. Authors' Addresses
14. Authors' Addresses
Vijay K. Gurbani, Editor 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA
Vijay K. Gurbani, Editor 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA
EMail: vkg@lucent.com
EMail: vkg@lucent.com
Alec Brusilovsky 2601 Lucent Lane Lisle, IL 60532-3640 USA
Alec Brusilovsky 2601 Lucent Lane Lisle, IL 60532-3640 USA
EMail: abrusilovsky@lucent.com
EMail: abrusilovsky@lucent.com
Gurbani, et al. Standards Track [Page 48] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 48] RFC 3910 SPIRITS Protocol October 2004
Igor Faynberg Lucent Technologies, Inc. 101 Crawfords Corner Rd. Holmdel, NJ 07733 USA
Igor Faynberg Lucent Technologies, Inc. 101 Crawfords Corner Rd. Holmdel, NJ 07733 USA
EMail: faynberg@lucent.com
EMail: faynberg@lucent.com
Jorge Gato Vodafone Espana Isabel Colbrand, 22 28050 Madrid Spain
Jorge Gato Vodafone Espana Isabel Colbrand, 22 28050 Madrid Spain
EMail: jorge.gato@vodafone.com
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, New Jersey, 07733
Phone: (732) 949-0321 EMail: huilanlu@lucent.com
Phone: (732) 949-0321 EMail: 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, The Netherlands
EMail: unmehopa@lucent.com
EMail: unmehopa@lucent.com
Gurbani, et al. Standards Track [Page 49] RFC 3910 SPIRITS Protocol October 2004
Gurbani, et al. Standards Track [Page 49] RFC 3910 SPIRITS Protocol October 2004
15. Full Copyright Statement
15. Full Copyright Statement
Copyright (C) The Internet Society (2004).
Copyright (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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Gurbani, et al. Standards Track [Page 50]
Gurbani, et al. Standards Track [Page 50]
一覧
スポンサーリンク
