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]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

speak-header 表の見出しを読むタイミングを指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る