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
Network Working Group V. Gurbani, Ed.
Request for Comments: 3910 A. Brusilovsky
Category: Standards Track I. Faynberg
Lucent Technologies, Inc.
J. Gato
Vodafone Espana
H. Lu
Bell Labs/Lucent Technologies
M. Unmehopa
Lucent Technologies, Inc.
October 2004
The SPIRITS (Services in PSTN requesting Internet Services) Protocol
SPRITS（PSTN中请求Internet服务的服务）协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built.
本文档描述了PSTN（公共交换电话网）中请求Internet服务（SPIRITS）协议的服务。SPIRITS协议的目的是支持源自蜂窝或有线PSTN的服务，并且需要PSTN和Internet之间的交互。在PSTN端，服务通常由智能网络（IN）实体发起。因特网呼叫等待和因特网呼叫者ID递送是SPIRITS服务的示例，蜂窝网络上的基于位置的服务也是如此。该协议定义了可用于构建许多其他服务的构建块。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document. . . . . . . . . . . 3
2. Overview of operations. . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . 6
3. Using XML for subscription and notification . . . . . . . . . 7
4. XML format definition . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document. . . . . . . . . . . 3
2. Overview of operations. . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . 6
3. Using XML for subscription and notification . . . . . . . . . 7
4. XML format definition . . . . . . . . . . . . . . . . . . . . 8
5. Call-related events . . . . . . . . . . . . . . . . . . . . . 10
5.1. IN-specific requirements . . . . . . . . . . . . . . . 11
5.2. Detection points and required parameters . . . . . . . 12
5.2.1. Originating-side DPs. . . . . . . . . . . . . 12
5.2.2. Terminating-side DPs. . . . . . . . . . . . . 14
5.3. Services through dynamic DPs . . . . . . . . . . . . . 15
5.3.1. Normative usage . . . . . . . . . . . . . . . 15
5.3.2. Event package name. . . . . . . . . . . . . . 16
5.3.3. Event package parameters. . . . . . . . . . . 16
5.3.4. SUBSCRIBE bodies. . . . . . . . . . . . . . . 16
5.3.5. Subscription duration . . . . . . . . . . . . 17
5.3.6. NOTIFY bodies . . . . . . . . . . . . . . . . 17
5.3.7. Notifier processing of SUBSCRIBE requests . . 18
5.3.8. Notifier generation of NOTIFY requests. . . . 18
5.3.9. Subscriber processing of NOTIFY requests. . . 19
5.3.10. Handling of forked requests . . . . . . . . . 19
5.3.11. Rate of notifications . . . . . . . . . . . . 19
5.3.12. State Agents. . . . . . . . . . . . . . . . . 20
5.3.13. Examples. . . . . . . . . . . . . . . . . . . 20
5.3.14. Use of URIs to retrieve state . . . . . . . . 25
5.4. Services through static DPs. . . . . . . . . . . . . . 25
5.4.1. Internet Call Waiting . . . . . . . . . . . . 26
5.4.2. Call disposition choices. . . . . . . . . . . 26
5.4.3. Accepting an ICW session using VoIP . . . . . 28
6. Non-call related events . . . . . . . . . . . . . . . . . . . 29
6.1. Non-call events and their required parameters. . . . . 29
6.2. Normative usage. . . . . . . . . . . . . . . . . . . . 30
6.3. Event package name . . . . . . . . . . . . . . . . . . 30
6.4. Event package parameters . . . . . . . . . . . . . . . 31
6.5. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . 31
6.6. Subscription duration. . . . . . . . . . . . . . . . . 31
6.7. NOTIFY bodies. . . . . . . . . . . . . . . . . . . . . 32
6.8. Notifier processing of SUBSCRIBE requests. . . . . . . 32
6.9. Notifier generation of NOTIFY requests . . . . . . . . 32
6.10. Subscriber processing of NOTIFY requests . . . . . . . 33
6.11. Handling of forked requests. . . . . . . . . . . . . . 33
6.12. Rate of notifications. . . . . . . . . . . . . . . . . 33
6.13. State Agents . . . . . . . . . . . . . . . . . . . . . 33
6.14. Examples . . . . . . . . . . . . . . . . . . . . . . . 33
6.15. Use of URIs to retrieve state. . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Registering event packages . . . . . . . . . . . . . . 38
7.2. Registering MIME type. . . . . . . . . . . . . . . . . 38
7.3. Registering URN. . . . . . . . . . . . . . . . . . . . 39
7.4. Registering XML schema . . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. XML schema definition . . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 45
5. Call-related events . . . . . . . . . . . . . . . . . . . . . 10
5.1. IN-specific requirements . . . . . . . . . . . . . . . 11
5.2. Detection points and required parameters . . . . . . . 12
5.2.1. Originating-side DPs. . . . . . . . . . . . . 12
5.2.2. Terminating-side DPs. . . . . . . . . . . . . 14
5.3. Services through dynamic DPs . . . . . . . . . . . . . 15
5.3.1. Normative usage . . . . . . . . . . . . . . . 15
5.3.2. Event package name. . . . . . . . . . . . . . 16
5.3.3. Event package parameters. . . . . . . . . . . 16
5.3.4. SUBSCRIBE bodies. . . . . . . . . . . . . . . 16
5.3.5. Subscription duration . . . . . . . . . . . . 17
5.3.6. NOTIFY bodies . . . . . . . . . . . . . . . . 17
5.3.7. Notifier processing of SUBSCRIBE requests . . 18
5.3.8. Notifier generation of NOTIFY requests. . . . 18
5.3.9. Subscriber processing of NOTIFY requests. . . 19
5.3.10. Handling of forked requests . . . . . . . . . 19
5.3.11. Rate of notifications . . . . . . . . . . . . 19
5.3.12. State Agents. . . . . . . . . . . . . . . . . 20
5.3.13. Examples. . . . . . . . . . . . . . . . . . . 20
5.3.14. Use of URIs to retrieve state . . . . . . . . 25
5.4. Services through static DPs. . . . . . . . . . . . . . 25
5.4.1. Internet Call Waiting . . . . . . . . . . . . 26
5.4.2. Call disposition choices. . . . . . . . . . . 26
5.4.3. Accepting an ICW session using VoIP . . . . . 28
6. Non-call related events . . . . . . . . . . . . . . . . . . . 29
6.1. Non-call events and their required parameters. . . . . 29
6.2. Normative usage. . . . . . . . . . . . . . . . . . . . 30
6.3. Event package name . . . . . . . . . . . . . . . . . . 30
6.4. Event package parameters . . . . . . . . . . . . . . . 31
6.5. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . 31
6.6. Subscription duration. . . . . . . . . . . . . . . . . 31
6.7. NOTIFY bodies. . . . . . . . . . . . . . . . . . . . . 32
6.8. Notifier processing of SUBSCRIBE requests. . . . . . . 32
6.9. Notifier generation of NOTIFY requests . . . . . . . . 32
6.10. Subscriber processing of NOTIFY requests . . . . . . . 33
6.11. Handling of forked requests. . . . . . . . . . . . . . 33
6.12. Rate of notifications. . . . . . . . . . . . . . . . . 33
6.13. State Agents . . . . . . . . . . . . . . . . . . . . . 33
6.14. Examples . . . . . . . . . . . . . . . . . . . . . . . 33
6.15. Use of URIs to retrieve state. . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Registering event packages . . . . . . . . . . . . . . 38
7.2. Registering MIME type. . . . . . . . . . . . . . . . . 38
7.3. Registering URN. . . . . . . . . . . . . . . . . . . . 39
7.4. Registering XML schema . . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. XML schema definition . . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 45
11. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 48
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50
11. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 48
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50
SPIRITS (Services in the PSTN Requesting Internet Services) is an IETF architecture and an associated protocol that enables call processing elements in the telephone network to make service requests that are then processed on Internet hosted servers. The term Public Switched Telephone Network (PSTN) is used here to include the wireline circuit-switched network, as well as the wireless circuit-switched network.
SPIRITS（PSTN中的服务请求Internet服务）是一种IETF体系结构和相关协议，使电话网络中的呼叫处理元件能够发出服务请求，然后在Internet托管服务器上处理这些请求。这里使用术语公共交换电话网（PSTN）来包括有线电路交换网络以及无线电路交换网络。
The earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated in the reverse direction - from the Internet to PSTN.
早期IETF关于PSTN/互联网互通（PINT）的工作产生了协议（RFC 2848），以支持从互联网到PSTN的反向启动的服务。
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协议提案的呼吁而编写的。除其他贡献外，本文件基于：
o Informational "Pre-SPIRITS implementations" [10] o Informational "The SPIRITS Architecture" [1] o Informational "SPIRITS Protocol Requirements" [4]
o 信息性“SPIRITS前实现”[10]o信息性“SPIRITS架构”[1]o信息性“SPIRITS协议要求”[4]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
The purpose of the SPIRITS protocol is to enable the execution of services in the Internet based on certain events occurring in the PSTN. The term PSTN is used here to include all manner of switching; i.e. wireline circuit-switched network, as well as the wireless circuit-switched network.
SPIRITS协议的目的是基于PSTN中发生的某些事件在Internet上执行服务。这里使用术语PSTN来包括所有方式的交换；i、 e.有线电路交换网络以及无线电路交换网络。
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.
一般来说，Internet主机对获取PSTN中发生的某些事件的通知感兴趣。当感兴趣的事件发生时，PSTN通知Internet主机。Internet主机可以基于这些通知执行适当的服务。
+------+
| PSTN |
|Events|
+------+
/ \
/ \
+-------+ +--------+
|Call | |Non-Call|
|Related| |Related |
+-------+ +--+-----+
/ \ |
/ \ |
+---/--+ +---\---+ +--+-----------------+
|Static| |Dynamic| |Mobility Management/|
| | | | |Registration/De- |
+------+ +-------+ |registration |
+--------------------+
+------+
| PSTN |
|Events|
+------+
/ \
/ \
+-------+ +--------+
|Call | |Non-Call|
|Related| |Related |
+-------+ +--+-----+
/ \ |
/ \ |
+---/--+ +---\---+ +--+-----------------+
|Static| |Dynamic| |Mobility Management/|
| | | | |Registration/De- |
+------+ +-------+ |registration |
+--------------------+
Figure 1: The SPIRITS Hierarchy.
图1:SPIRITS层次结构。
Figure 1 contains the SPIRITS events hierarchy, including their subdivision in two discrete classes for service execution: events related to the setup, teardown and maintenance of a call and events un-related to call setup, teardown or maintenance. Example of the latter class of events are geo-location mobility events that are tracked by the cellular PSTN. SPIRITS will specify the framework to provide services for both of these types of events.
图1包含SPIRITS事件层次结构，包括在服务执行的两个离散类中的细分：与调用的设置、拆卸和维护相关的事件，以及与调用的设置、拆卸或维护无关的事件。后一类事件的示例是由蜂窝PSTN跟踪的地理位置移动事件。SPIRITS将指定为这两种类型的事件提供服务的框架。
Call-related events, its further subdivisions, and how they enable services in the Internet is contained in Section 5. Services enabled from events not related to call setup, teardown, or maintenance are covered in detail in Section 6.
与呼叫相关的事件、其进一步的细分以及它们如何在互联网上提供服务，见第5节。第6节详细介绍了通过与呼叫设置、拆卸或维护无关的事件启用的服务。
For reference, the SPIRITS architecture from [1] is reproduced below. This document is focused on interfaces B and C only. Interface D is a matter of local policy; the PSTN operator may have a functional interface between the SPIRITS client or a message passing interface. This document does not discuss interface D in any detail.
以下复制了[1]中的SPIRITS架构以供参考。本文档仅关注接口B和C。接口D是当地政策的问题；PSTN运营商可以在客户端或消息传递接口之间具有功能接口。本文件未详细讨论接口D。
+--------------+
| Subscriber's |
| IP Host | +--------------+
| | | |
| +----------+ | | +----------+ |
| | PINT | | A | | PINT | |
| | Client +<-------/-------->+ Gateway +<-----+
| +----------+ | | +----------+ | |
| | | | |
| +----------+ | | +----------+ | |
| | SPIRITS | | B | | SPIRITS | | |
| | Server +<-------/-------->+ Gateway | | |
| +----------+ | | +--------+-+ | |
| | | ^ | |
+--------------+ +----------|---+ |
| |
IP Network | |
------------------------------------------|--------|---
PSTN / C / E
| |
v |
+----+------+ |
| SPIRITS | |
| Client | v
+-------------------+ +---+-----D-----+-++
| Service Switching |INAP/SS7 | Service Control |
| Function +---------+ Function |
+----+--------------+ +------------------+
|
|line
+-+
[0] Subscriber's telephone
+--------------+
| Subscriber's |
| IP Host | +--------------+
| | | |
| +----------+ | | +----------+ |
| | PINT | | A | | PINT | |
| | Client +<-------/-------->+ Gateway +<-----+
| +----------+ | | +----------+ | |
| | | | |
| +----------+ | | +----------+ | |
| | SPIRITS | | B | | SPIRITS | | |
| | Server +<-------/-------->+ Gateway | | |
| +----------+ | | +--------+-+ | |
| | | ^ | |
+--------------+ +----------|---+ |
| |
IP Network | |
------------------------------------------|--------|---
PSTN / C / E
| |
v |
+----+------+ |
| SPIRITS | |
| Client | v
+-------------------+ +---+-----D-----+-++
| Service Switching |INAP/SS7 | Service Control |
| Function +---------+ Function |
+----+--------------+ +------------------+
|
|line
+-+
[0] Subscriber's telephone
Figure 2: The SPIRITS Architecture.
图2:SPIRITS架构。
(Note: The interfaces A-E are described in detail in the SPIRITS Architecture document [1].)
（注：接口A-E在SPIRITS架构文件[1]中有详细描述。）
The PSTN today supports service models such as the Intelligent Network (IN), whereby some features are executed locally on switching elements called Service Switching Points (SSPs). Other features are executed on service elements called Service Control Points (SCPs). The SPIRITS architecture [1] permits these SCP elements to act as intelligent entities to leverage and use Internet hosts and capabilities to further enhance the telephone end-user's experience.
如今，PSTN支持智能网（IN）等服务模式，其中一些功能在称为服务交换点（SSP）的交换元件上本地执行。其他特性在称为服务控制点（SCP）的服务元素上执行。SPIRITS架构[1]允许这些SCP元素充当智能实体，以利用和使用互联网主机和功能，进一步增强电话终端用户的体验。
The protocol used on interfaces B and C consists of the SPIRITS protocol, and is based on SIP and SIP event notification [3]. The requirements of a SPIRITS protocol and the choice of using SIP as an enabler are detailed in [4].
接口B和C上使用的协议由SPIRITS协议组成，基于SIP和SIP事件通知[3]。SPIRITS协议的要求以及使用SIP作为启用码的选择在[4]中有详细说明。
The SPIRITS protocol is a set of two "event packages" [3]. It contains the procedural rules and semantic context that must be applied to these rules for processing SIP transactions. The SPIRITS protocol has to carry subscriptions for events from the SPIRITS server to the SPIRITS client and notifications of these events from the SPIRITS client to the SPIRITS server. Extensible Markup Language (XML) [12] is used to codify the subscriptions and notifications.
SPIRITS协议由两个“事件包”组成[3]。它包含处理SIP事务时必须应用于这些规则的过程规则和语义上下文。SPIRITS协议必须将事件的订阅从SPIRITS服务器传送到SPIRITS客户端，并将这些事件的通知从SPIRITS客户端传送到SPIRITS服务器。可扩展标记语言（XML）[12]用于对订阅和通知进行编码。
Finally, in the context of ensuing discussion, the terms "SPIRITS server" and "SPIRITS client" are somewhat confusing since the roles appear reversed; to wit, the "SPIRITS server" issues a subscription which is accepted by a "SPIRITS client". To mitigate such ambiguity, from now on, we will refer to the "SPIRITS server" as a "SPIRITS subscriber" and to the "SPIRITS client" as a "SPIRITS notifier". This convention adheres to the nomenclature outlined in [3]; the SPIRITS server in Figure 2 is a subscriber (issues subscriptions to events), and the SPIRITS client in Figure 2 is a notifier (issues notifications whenever the event of interest occurs).
最后，在接下来的讨论中，“SPIRITS服务器”和“SPIRITS客户端”这两个术语有些混淆，因为角色似乎颠倒了；也就是说，“SPIRITS服务器”发布一个被“SPIRITS客户端”接受的订阅。为了减轻这种模糊性，从现在开始，我们将“SPIRITS服务器”称为“SPIRITS订户”，将“SPIRITS客户端”称为“SPIRITS通知程序”。本公约遵循[3]中概述的术语；图2中的SPIRITS服务器是订阅者（向事件发出订阅），图2中的SPIRITS客户端是通知者（每当感兴趣的事件发生时发出通知）。
For ease of reference, we provide a terminology of the SPIRITS actors discussed in the preceding above:
为便于参考，我们提供了上文讨论的演员术语：
Service Control Function (SCF): A PSTN entity that executes service logic. It provides capabilities to influence the call processing occurring in the Service Switching Function (SSF). For more information on how a SCF participates in the SPIRITS architecture, please see Sections 5 and 5.1.
服务控制功能（SCF）：执行服务逻辑的PSTN实体。它提供了影响服务交换功能（SSF）中发生的呼叫处理的能力。有关SCF如何参与SPIRITS架构的更多信息，请参阅第5节和第5.1节。
SPIRITS client: see SPIRITS notifier.
SPIRITS客户端：请参阅SPIRITS通知程序。
SPIRITS server: see SPIRITS subscriber.
SPIRITS服务器：请参阅SPIRITS订阅服务器。
SPIRITS notifier: A User Agent (UA) in the PSTN that accepts subscriptions from SPIRITS subscribers. These subscriptions contain events that the SPIRITS subscribers are interested in receiving a notification for. The SPIRITS notifier interfaces with the Service Control Function such that when the said event occurs, a notification will be sent to the relevant SPIRITS subscriber.
SPIRITS通知程序：PSTN中接受SPIRITS订户订阅的用户代理（UA）。这些订阅包含SPIRITS订阅服务器有兴趣接收通知的事件。SPIRITS通知程序与服务控制功能接口，以便当所述事件发生时，将向相关SPIRITS订户发送通知。
SPIRITS subscriber: A UA in the Internet that issues a subscription containing events in the PSTN that it is interested in receiving a notification for.
SPIRITS subscriber：Internet上的一种UA，它发布一个订阅，其中包含PSTN中它有兴趣接收通知的事件。
The SPIRITS protocol requirements mandate that "SPIRITS-related parameters be carried in a manner consistent with SIP practices" (RFC3298:Section 3). SIP already provides payload description capabilities through the use of headers (Content-Type, Content-Length). This document defines a new MIME type -- "application/spirits-event+xml" -- and registers it with IANA (Section 7). This MIME type MUST be present in the "Content-Type" header of SPIRITS requests and responses, and it describes an XML document that contains SPIRITS-related information.
SPIRITS协议要求“SPIRITS相关参数应以符合SIP实践的方式进行”（RFC3298：第3节）。SIP已经通过使用头（内容类型、内容长度）提供了负载描述功能。本文档定义了一个新的MIME类型--“application/spirits event+xml”--并将其注册到IANA（第7节）。此MIME类型必须出现在SPIRITS请求和响应的“Content type”头中，它描述了包含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订阅者（任何能够发出订阅、注册或邀请请求的SPIRITS实体）都必须支持此模式。所有SPIRITS通知程序（任何能够接收和处理订阅、注册或邀请请求的SPIRITS实体）都必须支持此模式。模式在第9节中定义。
The support for the SIP REGISTER request is included for PINT compatibility (RFC3298:Section 6).
包括对SIP注册请求的支持，以实现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.
对SIP INVITE请求的支持是强制性的，因为预先存在的SPIRITS实现没有使用SIP事件通知方案。相反，初始PSTN检测点始终通过SIP INVITE请求到达。
This document also defines a base XML schema for notifications of events (Section 9). All SPIRITS notifiers MUST generate XML documents that correspond to the base notification schema. All SPIRITS subscribers MUST support XML documents that correspond to this schema.
本文档还定义了事件通知的基本XML模式（第9节）。所有SPIRITS通知程序都必须生成与基本通知模式对应的XML文档。所有订阅服务器都必须支持与此架构对应的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节中），它必须用于订阅和通知原始事件集。为了支持更丰富的事件集
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.
在订阅和通知中，实现可以使用与XML文档中的备用模式相对应的其他XML命名空间。但是，所有实现都必须支持本文档第9节中定义的基本XML模式。基本模式的使用确保了实现之间的互操作性，并且包含额外的XML名称空间允许定制。
A logical flow of the SPIRITS protocol is depicted below (note: this example shows a temporal flow; XML documents and related SPIRITS protocol syntax is specified in later sections of this document). In the flow below, S is the SPIRITS subscriber and N is the SPIRITS notifier. The SPIRIT Gateway is presumed to have a pure proxying functionality and thus is omitted for simplicity:
下面描述了SPIRITS协议的逻辑流（注意：这个示例显示了一个时间流；XML文档和相关的SPIRITS协议语法在本文档后面的部分中指定）。在下面的流程中，S是SPIRITS订户，N是SPIRITS通知程序。SPIRIT网关被认为具有纯代理功能，因此为了简单起见，省略了该功能：
1 S->N Subscribe (events of interest in an XML document instance using base subscription schema) 2 N->S 200 OK (Subscribe) 3 N->S Notify 4 S->N 200 OK (Notify communicating current resource state) 5 ... 6 N->S Notify (Notify communicating change in resource state; payload is an XML document instance using XML extensions to the base notification schema) 7 S->N 200 OK (Notify)
1 S->N Subscribe（使用基本订阅模式的XML文档实例中感兴趣的事件）2 N->S 200确定（订阅）3 N->S Notify 4 S->N 200确定（通知当前资源状态）5。。。6 N->S Notify（通知通信资源状态的更改；有效负载是使用基本通知模式的XML扩展的XML文档实例）7 S->N 200 OK（通知）
In line 1, the SPIRITS subscriber subscribes to certain events using an XML document based on the base schema defined in this document. In line 6, the SPIRITS notifier notifies the SPIRITS subscriber of the occurrence of the event using extensions to the base notification schema. Note that this document defines a base schema for event notification as well; the SPIRITS notifier could have availed itself of these. Instead, it chooses to pass to the SPIRITS subscriber an XML document composed of extensions to the base notification schema. The SPIRITS subscriber, if it understands the extensions, can interpret the XML document accordingly. However, in the event that the SPIRITS subscriber is not programmed to understand the extensions, it MUST search the XML document for the mandatory elements. These elements MUST be present in all notification schemas and are detailed in Section 9.
在第1行中，SPIRITS订阅者使用基于此文档中定义的基本模式的XML文档订阅某些事件。在第6行中，SPIRITS通知程序使用基本通知模式的扩展通知SPIRITS订户事件的发生。注意，本文档还定义了事件通知的基本模式；精灵通知者本可以利用这些。相反，它选择向订阅服务器传递一个由基本通知模式的扩展组成的XML文档。如果用户理解扩展，则可以相应地解释XML文档。但是，如果SPIRITS订阅者没有被编程为理解扩展，那么它必须在XML文档中搜索强制元素。这些元素必须出现在所有通知模式中，并在第9节中详细介绍。
This section defines the XML-encoded SPIRITS payload format. Such a payload is a well formed XML document and is produced by SPIRITS notifiers and SPIRITS subscribers.
本节定义了XML编码的有效负载格式。这样的有效负载是一个格式良好的XML文档，由SPIRITS通知程序和SPIRITS订阅者生成。
The namespace URI for elements defined in this document is a Uniform Resource Name (URN) [14], using the namespace identifier 'ietf' defined in [15] and extended by [16]:
本文档中定义的元素的名称空间URI是统一资源名（URN）[14]，使用[15]中定义的名称空间标识符“ietf”，并由[16]扩展：
urn:ietf:params:xml:ns:spirits-1.0
urn:ietf:params:xml:ns:spirits-1.0
SPIRITS XML documents may have a default namespace, or they may be associated with a namespace prefix following the convention established in XML namespaces [17]. Regardless, the elements and attributes of SPIRITS XML documents MUST conform to the SPIRITS XML schema specified in Section 9.
SPIRITS XML文档可能有一个默认名称空间，或者它们可能与遵循XML名称空间中建立的约定的名称空间前缀相关联[17]。无论如何，SPIRITS XML文档的元素和属性必须符合第9节中指定的SPIRITS XML模式。
The <spirits-event> element The root of a SPIRITS XML document (characterized by a Content-Type header of "application/spirits-event+xml">) is the <spirits-event> element. This element MUST contain a namespace declaration ('xmlns') to indicate the namespace on which the XML document is based. XML documents compliant to the SPIRITS protocol MUST contain the URN "urn:ietf:params:xml:ns:spirits-1.0" in the namespace declaration. Other namespaces may be specified as needed.
作为spirits XML文档根的<spirits event>元素（以“application/spirits event+XML”的内容类型头为特征）是<spirits event>元素。此元素必须包含名称空间声明（“xmlns”），以指示XML文档所基于的名称空间。符合SPIRITS协议的XML文档必须在名称空间声明中包含URN“URN:ietf:params:XML:ns:SPIRITS-1.0”。可以根据需要指定其他名称空间。
<spirits-event> element MUST contain at least one <Event> element, and MAY contain more than one.
<event>元素必须至少包含一个<event>元素，并且可以包含多个。
The <Event> element The <Event> element contains three attributes, two of which are mandatory. The first mandatory attribute is a 'type' attribute whose value is either "INDPs" or "userprof".
<Event>元素<Event>元素包含三个属性，其中两个是必需的。第一个强制属性是“type”属性，其值为“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.
第二个必需属性是“name”属性。此属性的值必须限于第5.2.1节、第5.2.2节和第6.1节中定义的精神助记符。
The third attribute, which is optional, is a 'mode' attribute. The value of 'mode' is either "N" or "R", corresponding respectively to (N)otification or (R)equest (RFC3298:Section 4). The default value of this attribute is "N".
第三个属性（可选）是“模式”属性。“模式”的值为“N”或“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
If the 'type' attribute of the <Event> element is "INDPs", then it
MUST contain at least one or more of the following elements
(unknown elements MAY be ignored): <CallingPartyNumber>,
<CalledPartyNumber>, <DialledDigits>, or <Cause>. These elements
are defined in Section 5.2; they MUST not contain any attributes and MUST not be used further as parent elements. These elements contain a string value as described in Section 5.2.1 and 5.2.2.
在第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>元素的“type”属性是“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 version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="OD" mode="N">
<CallingPartyNumber>5551212</CallingPartyNumber>
</Event>
<Event type="INDPs" name="OAB" mode="N">
<CallingPartyNumber>5551212</CallingPartyNumber>
</Event>
</spirits-event>
For readers who may not be familiar with the service execution aspects of PSTN/IN, we provide a brief tutorial next. Interested readers are urged to consult [19] for a detailed treatment of this subject.
对于可能不熟悉PSTN/IN的服务执行方面的读者，我们接下来将提供一个简短的教程。有兴趣的读者请查阅[19]，以了解有关此主题的详细信息。
Services in the PSTN/IN are executed based on a call model. A call model is a finite state machine used in SSPs and other call processing elements that accurately and concisely reflects the current state of a call at any given point in time. Call models consist of states called PICs (Points In Call) and transitions between states. Inter-state transitions pass through elements called Detection Points or DPs. DPs house one or more triggers. Every trigger has a firing criteria associated with it. When a trigger is armed (made active), and its associated firing criteria are satisfied, it fires. The particulars of firing criteria may vary based on the call model being supported.
PSTN/in中的服务基于呼叫模型执行。呼叫模型是一种有限状态机，用于SSP和其他呼叫处理元素，准确、简洁地反映任何给定时间点呼叫的当前状态。呼叫模型由称为PIC（呼叫点）的状态和状态之间的转换组成。状态间转换通过称为检测点或DPs的元素。DPs包含一个或多个触发器。每个触发器都有一个与之关联的触发标准。当触发器处于待命状态（激活）且满足其相关的触发条件时，它将触发。根据所支持的呼叫模型，触发标准的细节可能会有所不同。
When a trigger fires, a message is formatted with call state information and transmitted by the SSP to the SCP. The SCP then reads this call related data and generates a response which the SSP then uses in further call processing.
触发触发器时，将使用呼叫状态信息格式化消息，并由SSP传输到SCP。然后，SCP读取该呼叫相关数据并生成响应，然后SSP在进一步的呼叫处理中使用该响应。
Detection Points are of two types: TDPs (or Trigger Detection Points), and EDPs (or Event Detection Points). TDPs are provisioned with statically armed triggers (armed through Service Management Tools). EDPs are dynamically armed triggers (armed by the SCP as call processing proceeds). DPs may also be classified as "Request" or "Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and EDP-N's.
检测点有两种类型：TDP（或触发检测点）和EDP（或事件检测点）。TDP配备有静态防护触发器（通过服务管理工具防护）。EDP是动态防护触发器（在呼叫处理过程中由SCP防护）。DPs也可分类为“请求”或“通知”DPs。因此，可以有TDP-R、TDP-N、EDP-R和EDP-N。
The "-R" type of DPs require the SSP to suspend call processing when communication with the SCP is initiated. Call processing resumes when a response is received. The "-N" type of DPs enable the SSP to continue with call processing when the trigger fires, after it sends out the message to the SCP, notifying it that a certain event has occurred.
“-R”型DPs要求SSP在启动与SCP的通信时暂停呼叫处理。收到响应后，呼叫处理将恢复。“-N”类型的DPs使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]调用模型作为示例，并且为了便于解释，其他调用模型具有类似的属性。例如，无线智能网络（WIN）呼叫模型也支持触发器的动态报警。因此，本讨论的实质不仅适用于有线领域，也同样适用于无线领域。
When the SCP receives the INAP formatted message from the SSP, if the SCP supports the SPIRITS architecture, it can encode the INAP message contents into a SPIRITS protocol message which is then transmitted to SPIRITS-capable elements in the IP network. Similarly, when it receives responses back from said SPIRITS capable elements, it can reformat the response content into the INAP format and forward these messages back to SSPs. Thus the process of inter-conversion and/or encoding between the INAP parameters and the SPIRITS protocol is of primary interest.
当SCP从SSP接收到INAP格式的消息时，如果SCP支持SPIRITS体系结构，它可以将INAP消息内容编码为SPIRITS协议消息，然后将其传输到IP网络中支持SPIRITS的元件。类似地，当它接收到来自所述支持SPIRITS的元素的响应时，它可以将响应内容重新格式化为INAP格式，并将这些消息转发回ssp。因此，INAP参数和SPIRITS协议之间的相互转换和/或编码过程是主要关注的。
An SCP is a physical manifestation of the Service Control Function. An SSP is a physical manifestation of the Service Switching Function (and the Call Control Function). To support uniformity of nomenclature between the various SPIRITS drafts, we shall use the terms SCP and SCF, and SSP and SSF interchangeably in this document.
SCP是服务控制功能的物理表现形式。SSP是业务交换功能（和呼叫控制功能）的物理表现形式。为了支持各种烈性酒草案之间的统一命名，我们将在本文件中互换使用术语SCP和SCF以及SSP和SSF。
Section 4 of [4] outlines the IN-related requirements on the SPIRITS protocol. The SUBSCRIBE request arriving at the SPIRITS notifier MUST contain the events to be monitored (in the form of a DP list), the mode (request or a notification, the difference being that for a
[4]第4节概述了SPIRITS协议的相关要求。到达SPIRITS通知程序的订阅请求必须包含要监视的事件（以DP列表的形式）、模式（请求或通知，区别在于
request, the SPIRITS subscriber can influence subsequent call processing and for a notification, no further influence is needed), and any DP-related parameters.
请求时，用户可影响后续呼叫处理，对于通知，无需进一步影响），以及任何DP相关参数。
Section 4 of [4] also enumerates a list of Capability Set 3 (CS-3) DPs for SPIRITS services. It is a requirement (RFC3298:Section 4) that the SPIRITS protocol specify the relevant parameters of the DPs. These DPs and their relevant parameters to be carried in a SUBSCRIBE request are codified in an XML schema. All SPIRITS subscribers MUST understand this schema for subscribing to the DPs in the PSTN. The schema is defined in Section 9.
[4]的第4节还列举了服务的能力集3（CS-3）DPs列表。SPIRITS协议规定DPs的相关参数是一项要求（RFC3298：第4节）。这些DPs及其在订阅请求中携带的相关参数编码在XML模式中。所有用户必须了解此模式才能在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通知程序传输到SPIRITS订户。NOTIFY请求包含一个XML文档，该文档描述触发的DP和任何相关参数。要在NOTIFY请求中携带的DPs及其相关参数编码在XML模式中。所有SPIRITS通知程序必须理解此模式；此模式可以扩展。模式在第9节中定义。
In addition, Appendices A and B of [6] contain a select subset of CS-2 DPs that may be of interest to the reader. However, this document will only refer to CS-3 DPs outlined in [4].
此外，[6]的附录A和B包含读者可能感兴趣的CS-2 DPs的部分子集。但是，本文件仅参考[4]中概述的CS-3 DPs。
The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4) are described next. IN DPs are characterized by many parameters, however, not all such parameters are required -- or even needed -- by SPIRITS. This section, thus, serves to list the mandatory parameters for each DP that MUST be specified in subscriptions and notifications. Implementations can specify additional parameters as XML extensions associated with a private (or public and standardized) namespace.
接下来将介绍为SPIRITS服务设想的CS-3 DPs（RFC3298：第4节）。在DPs中，具有许多参数的特征，然而，并非所有这些参数都是白酒所必需的，甚至不是白酒所必需的。因此，本节将列出订阅和通知中必须指定的每个DP的强制参数。实现可以将附加参数指定为与私有（或公共和标准化）命名空间关联的XML扩展。
The exhaustive list of IN CS-3 DPs and their parameters can be found in reference [13].
参考文献[13]中列出了CS-3 DPs中的所有参数及其参数。
Each DP is given a SPIRITS-specific mnemonic for use in the subscriptions and notifications.
每个DP都有一个特定的助记符，用于订阅和通知。
Origination Attempt Authorized SPIRITS mnemonic: OAA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
发起尝试授权烈酒助记符：订阅中的OAA强制参数：通知中的CallingPartyNumber强制参数：CallingPartyNumber，调用PartyNumber
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
收集的信息助记符：订阅中的OCI必填参数：通知中的CallingPartyNumber必填参数：CallingPartyNumber，DialledDigits
DialledDigits: This parameter contains non-translated address
information collected/received from the originating user/line/trunk
DialledDigits: This parameter contains non-translated address
information collected/received from the originating user/line/trunk
Analyzed Information SPIRITS mnemonic: OAI Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
已分析信息助记符：订阅中的OAI必填参数：通知中的CallingPartyNumber必填参数：CallingPartyNumber，DialledDigits
Origination Answer SPIRITS mnemonic: OA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
发端应答精神助记符：订阅中的OA强制参数：通知中的CallingPartyNumber强制参数：CallingPartyNumber，CalledPartyNumber
Origination Term Seized SPIRITS mnemonic: OTS Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
发起术语助记符：订阅中的OTS必填参数：通知中的CallingPartyNumber必填参数：CallingPartyNumber，调用PartyNumber
Origination No Answer SPIRITS mnemonic: ONA Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
发端无应答精神助记符：订阅中的ONA必填参数：通知中的CallingPartyNumber必填参数：CallingPartyNumber，调用PartyNumber
Origination Called Party Busy SPIRITS mnemonic: OCPB Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
发起方呼叫方占线助记符：订阅中的OCPB强制参数：通知中的CallingPartyNumber强制参数：CallingPartyNumber，CalledPartyNumber
Route Select Failure SPIRITS mnemonic: ORSF Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
路由选择失败：订阅中的助记符：ORSF强制参数：通知中的CallingPartyNumber强制参数：CallingPartyNumber，CalledPartyNumber
Origination Mid Call SPIRITS mnemonic: OMC Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
发起呼叫中间状态助记符：订阅中的OMC必填参数：通知中的CallingPartyNumber必填参数：CallingPartyNumber
Origination Abandon SPIRITS mnemonic: OAB
起源记忆法：OAB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber
订阅中的必填参数：CallingPartyNumber通知中的必填参数：CallingPartyNumber
Origination Disconnect SPIRITS mnemonic: OD Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
发端助记符：订阅中的OD必填参数：通知中的CallingPartyNumber必填参数：CallingPartyNumber，调用PartyNumber
Termination Answer SPIRITS mnemonic: TA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
终止应答助记符：订阅中的TA必填参数：通知中的CalledPartyNumber必填参数：CallingPartyNumber，CalledPartyNumber
Termination No Answer SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
终止无应答精神助记符：订阅中的TNA强制参数：通知中的CalledPartyNumber强制参数：CallingPartyNumber，CalledPartyNumber
Termination Mid-Call SPIRITS mnemonic: TMC Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
终止通话中精神助记符：订阅中的TMC强制参数：通知中的CalledPartyNumber强制参数：CalledPartyNumber
Termination Abandon SPIRITS mnemonic: TAB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
终止助记符：订阅中的制表符必填参数：通知中的CalledPartyNumber必填参数：CalledPartyNumber
Termination Disconnect SPIRITS mnemonic: TD Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
终止助记符：订阅中的TD必填参数：通知中的CalledPartyNumber必填参数：CalledPartyNumber，CallingPartyNumber
Termination Attempt Authorized SPIRITS mnemonic: TAA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
终止尝试助记符：订阅中的TAA强制参数：通知中的CalledPartyNumber强制参数：CalledPartyNumber，CallingPartyNumber
Termination Facility Selected and Available SPIRITS mnemonic: TFSA Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
已选择并可用的终止设施助记符：订阅中的TFSA必填参数：通知中的CalledPartyNumber必填参数：CalledPartyNumber
Termination Busy SPIRITS mnemonic: TB Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber, Cause
终止忙状态助记符：订阅中的TB强制参数：通知中的CalledPartyNumber强制参数：CalledPartyNumber，CallingPartyNumber，原因
Cause: This parameter contains a string value of either "Busy" or "Unreachable". The difference between these is translated as a requirement (RFC3298:Section 5) to aid in the SPIRITS subscriber in determining if the called party is indeed busy (engaged), or if the called party is unavailable (as it would be if it were on the cellular PSTN and the mobile subscriber was not registered with the network).
原因：此参数包含一个字符串值“Busy”或“Unreachable”。这两者之间的差异被转化为一项要求（RFC3298：第5节），以帮助用户确定被叫方是否确实忙（接通），或者被叫方是否不可用（如果被叫方在蜂窝PSTN上，并且移动用户未在网络中注册，则情况会如此）。
Triggers in the PSTN can be armed dynamically, often outside the context of a call. The SIP event notification mechanism [3] is, therefore, a convenient means to exploit in those cases where triggers housed in EDPs fire (see section 3 of [4]). Note that [4] uses the term "persistent" to refer to call-related DP arming and associated interactions.
PSTN中的触发器可以动态防护，通常在呼叫上下文之外。因此，SIP事件通知机制[3]是在EDPs中包含触发器的情况下利用的一种方便方法（见[4]第3节）。请注意，[4]使用术语“持久性”来指与呼叫相关的DP防护和相关交互。
The SIP Events Package enables IP endpoints (or hosts) to subscribe to and receive subsequent notification of events occurring in the PSTN. With reference to Figure 2, this includes communication on the interfaces marked "B" and "C".
SIP事件包使IP端点（或主机）能够订阅和接收PSTN中发生的事件的后续通知。参考图2，这包括标记为“B”和“C”的接口上的通信。
A subscriber will issue a SUBSCRIBE request which identifies a set of events (DPs) it is interested in getting the notification of. This set MUST contain at least one DP, it MAY contain more than one. The SUBSCRIBE request is routed to the notifier, where it is accepted, pending a successful authentication.
订阅者将发出一个SUBSCRIBE请求，该请求标识了它感兴趣的一组事件（DPs），以获取通知。此集合必须至少包含一个DP，它可能包含多个DP。订阅请求被路由到通知程序，在那里它被接受，等待成功的身份验证。
When any of the DPs identified in the set of events fires, the notifier will format a NOTIFY request and direct it towards the subscriber. The NOTIFY request will contain information pertinent to the event that was triggered. The un-encountered DPs MUST be subsequently dis-armed by the SPIRITS notifier and/or the SCF.
当事件集中标识的任何DPs触发时，通知程序将格式化NOTIFY请求并将其指向订阅服务器。NOTIFY请求将包含与触发的事件相关的信息。未遇到的DPs随后必须由SPIRITS通知程序和/或SCF解除武装。
The dialog established by the SUBSCRIBE terminates when the event of interest occurs and this notification is passed to the subscriber through a NOTIFY request. If the subscriber is interested in the future occurrence of the same event, it MUST issue a new SUBSCRIBE request, establishing a new dialog.
当感兴趣的事件发生时，SUBSCRIBE建立的对话框终止，并且通过NOTIFY请求将此通知传递给订阅服务器。如果订户对同一事件的未来发生感兴趣，则必须发出新的订阅请求，建立新的对话框。
When the subscriber receives a NOTIFY request, it can subsequently choose to act in a manner appropriate to the notification.
当订户收到通知请求时，它可以随后选择以适合于通知的方式行事。
The remaining sections fill in the specific package responsibilities raised in RFC3265 [3], Section 4.4.
其余章节填写RFC3265[3]第4.4节中提出的具体包责任。
This document defines two event packages; the first of these is defined in this section and is called "spirits-INDPs". This package MUST be used for events corresponding to IN detection points in the cellular or wireline PSTN. All entities that implement the SPIRITS protocol and support IN detection points MUST set the "Event" request header [3] to "spirits-INDPs." The "Allow-Events" general header [3] MUST include the token "spirits-INDPs" if the entity implements the SPIRITS protocol and supports IN detection points.
本文件定义了两个事件包；第一个在本节中定义，称为“精神INDP”。此软件包必须用于与蜂窝或有线PSTN中的IN检测点相对应的事件。所有实施SPIRITS协议并支持检测点的实体必须将“事件”请求头[3]设置为“SPIRITS INDPs”。如果实体实施SPIRITS协议并支持检测点，“允许事件”一般头[3]必须包括令牌“SPIRITS INDPs”。
Event: spirits-INDPs Allow-Events: spirits-INDPs
事件：烈酒INDP允许事件：烈酒INDP
The second event package is defined and discussed in Section 6.
第6节定义并讨论了第二个事件包。
The "spirits-INDPs" event package does not support any additional parameters to the Event header.
“INDPs”事件包不支持事件头的任何附加参数。
SUBSCRIBE requests that serve to terminate the subscription MAY contain an empty body; however, SUBSCRIBE requests that establish a dialog MUST contain a body which encodes three pieces of information:
用于终止订阅的订阅请求可能包含空正文；但是，建立对话框的订阅请求必须包含一个对三条信息进行编码的正文：
(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）。订阅者可以在一个订阅请求中订阅多个DP，或者可以对其感兴趣的每个DP发出不同的订阅请求以接收通知。该协议允许两种形式的表示，但是，如果服务依赖于被触发的任何DPs，它建议使用前一种订阅DPs的方式。
(2) Because of the requirement [4] that IN be informed whether the detection point is set as the request or notification, all events in the "spirits-INDPs" package (but not in the "spirits-user-prof" package) are required to provide a "mode" parameter, whose values are "R" (for Request) and "N" for notification.
(2) 由于[4]的要求，即无论检测点设置为请求还是通知，都需要通知“spirits INDPs”包（但不在“spirits user prof”包中）中的所有事件提供一个“mode”参数，其值为“R”（用于请求）和“N”用于通知。
(3) A list of the values of the parameters associated with the event detection point (Note: the term "event" here refers to the IN usage -- a dynamically armed DP is called an Event Detection Point). Please see Section 5.2.1 and Section 5.2.2 for a list of parameters associated with each DP.
(3) 与事件检测点相关的参数值列表（注意：术语“事件”在这里指的是正在使用的——动态防护的DP称为事件检测点）。请参见第5.2.1节和第5.2.2节，了解与每个DP相关的参数列表。
The default body type for SUBSCRIBEs in SPIRITS is denoted by the MIME type "application/spirits-event+xml". The "Accept" header, if present, MUST include this MIME type.
SPIRITS中订阅的默认主体类型由MIME类型“application/SPIRITS event+xml”表示。“Accept”标头（如果存在）必须包含此MIME类型。
For package "spirits-INDPs", the purpose of the SUBSCRIBE request is to arm the DP, since as far as IN is concerned, being armed is the first essential pre-requisite. A DP maybe armed either statically (for instance, through service provisioning), or dynamically (by the SCF). A statically armed DP remains armed until it is disarmed proactively. A dynamically armed DP remains armed for the duration of a call (or more appropriately, no longer than the duration of a particular SSF-SCF relationship).
对于包“INDP”，订阅请求的目的是武装DP，因为就IN而言，武装是第一个基本先决条件。DP可以静态（例如，通过服务供应）或动态（通过SCF）武装。静态防护DP保持防护状态，直到主动解除防护。动态防护DP在呼叫期间保持防护状态（或者更恰当地说，不超过特定SSF-SCF关系的持续时间）。
Dynamically armed DPs are automatically disarmed when the event of interest occurs in the notifier. It is up to the subscriber to re-arm the DPs within the context of a call, if it so desires.
当通知程序中发生相关事件时，动态防护的DPs将自动解除防护。如果用户愿意，则由其在呼叫上下文中重新武装DPs。
Statically armed DPs are considered outside the scope of the SPIRITS protocol requirements [4] and thus will not be considered any further.
静态防护DPs被认为不在SPIRITS协议要求[4]的范围内，因此将不再考虑。
Bodies in NOTIFY requests for the "spirits-INDPs" package are optional. If present, they MUST be of the MIME type "application/spirits-event+xml". The body in a NOTIFY request encapsulates the following pieces of information which can be used by the subscriber:
“spirits INDPs”包的NOTIFY请求中的主体是可选的。如果存在，它们必须是MIME类型“应用程序/事件+xml”。NOTIFY请求中的正文封装了订阅者可以使用的以下信息：
(1) The event that resulted in the NOTIFY being generated (typically, but not always, this will be the same event present in the corresponding SUBSCRIBE request).
(1) 导致生成通知的事件（通常，但不总是，这将是相应订阅请求中存在的相同事件）。
(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) 与为其生成通知的事件关联的参数值列表。根据实际事件，参数列表将有所不同。
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.
如果订户将多个DPs作为单个订阅请求的一部分进行防护，则作为同一订阅对话框一部分的所有未遇到的DPs必须由SPIRITS通知程序和/或SCF/SCP解除防护。
When the notifier receives a SUBSCRIBE request, it MUST authenticate the request and ensure that the subscriber is authorized to access the resource being subscribed to, in this case, PSTN/IN events on a certain PSTN line.
当通知程序接收到订阅请求时，它必须对请求进行身份验证，并确保订阅者有权访问正在订阅的资源，在这种情况下，访问特定PSTN线路上的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.
一旦订阅请求已被认证和授权，通知器通过接口D与SCF接口，以装备与包含在订阅主体中的PSTN线路相对应的检测点。关于接口D的详细信息超出了本文件的范围；在这里，我们将简单地假设通知程序可以通过接口D影响PSTN中触发器的防护（和解除防护）。
If the notifier expects the arming of triggers to take more than 200 ms, it MUST send a 202 response to the SUBSCRIBE request immediately, accepting the subscription. It should then send a NOTIFY request with an empty body. This NOTIFY request MUST have a "Subscription-State" header with a value of "pending".
如果通知程序预计触发的待命时间超过200 ms，则必须立即向订阅请求发送202响应，并接受订阅。然后，它应该发送一个带有空正文的NOTIFY请求。此通知请求必须具有值为“待定”的“订阅状态”标头。
This immediate NOTIFY with an empty body is needed since the resource identified in the SUBSCRIBE request does not have as yet a meaningful state.
由于订阅请求中标识的资源尚未处于有意义的状态，因此需要具有空正文的立即通知。
Once the notifier has successfully interfaced with the SCF, it MUST send a subsequent NOTIFY request with an empty body and a "Subscription-State" header with a value of "active."
一旦通知程序成功地与SCF交互，它必须发送一个带有空正文和一个值为“active”的“Subscription State”标头的后续通知请求
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".
当订阅请求中确定的关注事件发生时，通知者发送一个新的通知请求，该请求必须包含正文（见第5.3.6节）。NOTIFY请求必须具有“Subscription State”标头，并且其值必须设置为“terminated”，且原因参数为“fired”。
The exact steps executed at the subscriber when it gets a NOTIFY request will depend on the service being implemented. As a generality, the UA associated with the subscriber should somehow impart this information to the user by visual or auditory means, if at all possible.
订阅服务器收到通知请求时执行的确切步骤将取决于所实现的服务。作为一般性，与用户相关联的UA应当以某种方式通过视觉或听觉方式（如果可能的话）将该信息传递给用户。
If the NOTIFY request contained a "Subscription-State" header with a value of "terminated" and a reason parameter of "fired", the UA associated with the subscriber MAY initiate a new subscription for the event that was just reported through the NOTIFY request.
如果NOTIFY请求包含值为“terminated”且原因参数为“fired”的“Subscription State”报头，则与订阅者相关联的UA可针对刚刚通过NOTIFY请求报告的事件发起新订阅。
Whether or not to initiate a new subscription when an existing one expires is up to the context of the service that is being implemented. For instance, a user may configure her UA to always re-subscribe to the same event when it fires, but this is not necessarily the normative case.
现有订阅过期时是否启动新订阅取决于正在实现的服务的上下文。例如，用户可以将其UA配置为在触发同一事件时始终重新订阅该事件，但这不一定是标准情况。
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE request is targeted towards the PSTN, highly irregular behaviors occur if the request is allowed to fork. The normal SIP DNS lookup and routing rules [11] should result in a target set with exactly one element: the notifier.
禁止分叉订阅请求。由于订阅请求是针对PSTN的，如果允许请求分叉，则会发生高度不规则的行为。正常的SIP DNS查找和路由规则[11]应产生一个目标集，其中只有一个元素：通知程序。
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.
出于安全而非网络流量的原因，建议通知程序发出两个或最多三个订阅通知请求。如果订阅被202响应接受，将立即向订阅方发送通知。此通知用于通知订户该请求已被接受并正在执行。
Once the resource (detection points) identified in the SUBSCRIBE request have been initialized, the notifier MUST send a second NOTIFY request. This request contains the base state of the resource.
一旦订阅请求中标识的资源（检测点）被初始化，通知程序必须发送第二个NOTIFY请求。此请求包含资源的基本状态。
When an event of interest occurs which leads to the firing of the trigger associated with the detection points identified in the SUBSCRIBE request, a final NOTIFY is sent to the subscriber. This NOTIFY request contains more information about the event of interest.
当发生导致触发与订阅请求中标识的检测点相关联的触发器的关注事件时，将向订阅方发送最终通知。此通知请求包含有关感兴趣事件的更多信息。
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响应接受，通知程序只发送两个通知请求：一个包含资源的基本状态，另一个包含导致触发检测点的信息。
State agents are not used in SPIRITS.
国家代理人不用于烈性酒。
This section contains example call flows for a SPIRITS service called Internet Caller-ID Delivery (ICID). One of the benchmark SPIRITS service, as described in section 2.2 of [1] is Internet Caller-ID delivery:
本节包含名为Internet呼叫者ID传递（ICID）的SPIRITS服务的示例调用流。[1]第2.2节所述的基准服务之一是互联网来电显示交付：
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.
此服务允许用户在连接到Internet时查看呼叫者的号码或姓名或两者。如果用户只有一条电话线，并且正在使用该电话线进行互联网连接，则该服务是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.
我们给出了一个实现此服务的调用流示例。请注意，这只是一个示例，不是对Internet呼叫者ID服务的规范性描述。
Further text and details of SIP messages below refer to the call flow provided in Figure 3. Figure 3 depicts the 4 entities that are an integral part of any SPIRITS service (the headings of the entities refer to the names established in Figure 1 in [1]) -- the SPIRITS subscriber, the SPIRITS notifier and the SCF. Note that the SPIRITS gateway is not included in this figure; logically, SPIRITS messages flow between the SPIRITS server and the SPIRITS client. A gateway, if present, may act as a proxy.
下面SIP消息的更多文本和细节参见图3中提供的调用流。图3描述了作为任何SPIRITS服务组成部分的4个实体（实体标题指[1]中图1中确定的名称）——SPIRITS订阅者、SPIRITS通知者和SCF。请注意，此图中不包括SPIRITS网关；从逻辑上讲，SPIRITS消息在SPIRITS服务器和SPIRITS客户端之间流动。网关（如果存在）可以充当代理。
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Arm DP |
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Arm DP |
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 3: Sample call flow
图3：示例调用流
This call flow depicts an overall operation of a "subscriber" successfully subscribing to the IN Termination_Attempt_Authorized DP (the "subscriber" is assumed to be a user, possibly at work, who is interested in knowing when he/she gets a phone call to his/her home phone number) -- this interaction is captured in messages F1 through F8 in Figure 3. The user sends (F1) a SIP SUBSCRIBE request identifying the DP it is interested in along with zero or more parameters relevant to that DP (in this example, the Termination_Attempt_DP will be employed). The SPIRITS notifier in turns interacts with the SCF to arm the Termination_Attempt_DP for the service (F2). An immediate NOTIFY with the current state information is send to the subscriber (F4, F5).
此呼叫流描述了成功订阅终止尝试授权DP的“订户”的总体操作（假定“订户”是一个用户，可能在工作中，他/她有兴趣知道何时收到他/她的家庭电话号码的电话）--此交互在图3中的消息F1到F8中捕获。用户发送（F1）标识其感兴趣的DP的SIP SUBSCRIBE请求以及与该DP相关的零个或多个参数（在本例中，将采用终止尝试DP）。SPIRITS通知程序依次与SCF交互，为服务（F2）配置终止尝试DP。向订户（F4、F5）发送带有当前状态信息的即时通知。
At some point after the above sequence of events has transpired, the PSTN gets a call to the users phone. The SSF informs the SCF of this event when it encounters an armed Termination_Attempt_DP (not shown in Figure 3). The SCF informs the SPIRITS notifier of this event (F6).
在上述一系列事件发生后的某个时刻，PSTN会接到用户电话的呼叫。SSF在遇到武装终止尝试DP时通知SCF此事件（图3中未显示）。SCF将此事件通知SPIRITS通知程序（F6）。
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通知程序收到此事件时，它将形成SIP NOTIFY请求并将其定向到SPIRITS订户（F7）。此通知将包含向订户标识呼叫者所需的所有信息元素。订户在收到通知（F8）后，可以弹出一个窗口，显示日期/时间和呼叫者的号码。
The rest of this section contains the details of the SIP messages in Figure 3. The call flow details below assume that the SPIRITS gateway is, for the purpose of this example, a SIP proxy that serves as the default outbound proxy for the notifier and an ingress host of the myprovider.com domain for the subscriber. The subscriber and notifier may be in separate administrative domains.
本节的其余部分包含图3中SIP消息的详细信息。下面的呼叫流详细信息假设，就本例而言，SPIRITS网关是一个SIP代理，充当通知程序的默认出站代理和订阅者的myprovider.com域的入口主机。订阅者和通知者可能位于不同的管理域中。
F1: S->N
F1:S->N
SUBSCRIBE sip:myprovider.com SIP/2.0 From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com> CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds Expires: 3600 Event: spirits-INDPs Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
订阅sip:myprovider.com sip/2.0发件人：<sip:vkg@example.com>;标签=8177-afd-991至：<sip:16302240216@myprovider.com>CSeq:18992订阅呼叫ID:3329as77@host.example.com联系人：<sip:vkg@host.example.com>Via:SIP/2.0/UDP host.example.com；branch=z9hG4bK776asdhds过期：3600事件：烈酒INDPs允许事件：烈酒INDPs，烈酒用户prof接受：应用程序/烈酒事件+xml内容类型：应用程序/烈酒事件+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
The subscriber forms a SIP SUBSCRIBE request which identifies the DP that it wants to subscribe to (in this case, the TAA DP) and the actual line it wants that DP armed for (in this case, the line
订阅者形成一个SIP SUBSCRIBE请求，该请求标识它想要订阅的DP（在本例中为TAA DP）和它想要为其配置DP的实际线路（在本例中为线路）
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:
与电话号码630224216关联）。该请求最终到达SIPRITS通知程序N，该通知程序对其进行身份验证（未显示），并向订户发送成功响应：
F3: N->S
F3:N->S
SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
Expires: 3600
Accept: application/spirits-event+xml
Content-Length: 0
SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
Expires: 3600
Accept: application/spirits-event+xml
Content-Length: 0
The notifier interacts with the SCF to arm the DP and also sends an immediate NOTIFY towards the subscriber informing the subscriber of the current state of the notification:
通知程序与SCF交互以保护DP，并向订阅者发送即时通知，通知订阅者通知的当前状态：
F4: N->S
F4:N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
NOTIFY sip:vkg@host.example.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
F5: S->N
F5:S->N
SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
At some later point in time (before the subscription established in F1 expires at the notifier), a call arrives at the number identified in XML-encoded body of F1 -- 6302240216. The SCF notifies the notifier (F6). Included in this notification is the relevant information from the PSTN, namely, the phone number of the party attempting to call 6302240216. The notifier uses this information to create a SIP NOTIFY request and sends it to the subscriber. The SIP NOTIFY request has a XML-encoded body with the relevant information from the PSTN:
在稍后的某个时间点（在F1中建立的订阅在通知程序中过期之前），一个调用到达F1-630224216的XML编码体中标识的号码。SCF通知通知程序（F6）。本通知中包括来自PSTN的相关信息，即试图拨打630224216的一方的电话号码。通知程序使用此信息创建SIP NOTIFY请求并将其发送给订阅服务器。SIP NOTIFY请求有一个XML编码的正文，其中包含来自PSTN的相关信息：
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: ...
通知sip：vkg@host.example.comSIP/2.0发件人：<SIP:16302240216@myprovider.com>;标签=烈酒-TAA-630224216至：<sip:vkg@example.com>;tag=8177-afd-991，通过：SIP/2.0/UDP notifier.myprovider.com；branch=z9hG4bK9inn-=u7呼叫ID:3329as77@host.example.com联系人：<sip:notifier.myprovider.com>CSeq:3300通知订阅状态：已终止；原因=激发接受：应用程序/精灵事件+xml事件：精灵INDPs允许事件：精灵INDPs，精灵用户教授内容类型：应用程序/精灵事件+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<CallingPartyNumber>3125551212</CallingPartyNumber>
</Event>
</spirits-event>
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<CallingPartyNumber>3125551212</CallingPartyNumber>
</Event>
</spirits-event>
There are two important issues to note in the call flows for F7:
F7调用流中有两个重要问题需要注意：
(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通知程序的信息。在此特定示例中，这是试图拨打630224216的一方（312551212）的电话号码。
(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中建立的订阅终止（从订阅状态标头可以明显看出）。由于与TAA触发相关的DP，订阅正常终止（因此订阅状态标头中的原因代码为“已触发”）。如果订户
wants to get notified of another attempt to call the number 6302240216, he/she should send a new SUBSCRIBE request to the notifier.
如果要获得另一次尝试拨打630224216的通知，他/她应向通知者发送新的订阅请求。
The subscriber can take any appropriate action upon the receipt of the NOTIFY in F7. A reasonable implementation may pop up a window populated with the information contained in the body of F12, along with a button asking the subscriber if they would like to re-subscribe to the same event. Alternatively, a re-subscription could be generated automatically by the subscriber's UA based on his/her preferences.
订户可在收到F7中的通知后采取任何适当的行动。一个合理的实现可能会弹出一个窗口，其中包含F12正文中包含的信息，以及一个按钮，询问订阅者是否愿意重新订阅同一事件。或者，可以由订户的UA根据其偏好自动生成重新订阅。
To complete the protocol, the subscriber also sends a 200 OK message towards the notifier:
为了完成协议，订户还向通知程序发送200 OK消息：
F8: S->N
F8:S->N
200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
Call-ID: 3329as77@host.example.com
CSeq: 3300 NOTIFY
Content-Length: 0
200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
Call-ID: 3329as77@host.example.com
CSeq: 3300 NOTIFY
Content-Length: 0
The "spirits-INDPs" package MUST NOT use URIs to retrieve state. It is expected that most state information for this package is compact enough to fit in a SIP message. However, to err on the side of caution, implementations MUST follow the convention outlined in Section 18.1.1 of [5] and use a congestion controlled transport if the size of the request is within 200 bytes of the path MTU if known, or if the request size is larger than 1300 bytes and the path MTU is unknown.
“INDPs”包不得使用URI检索状态。预计此包的大多数状态信息都足够紧凑，可以放入SIP消息中。然而，为了谨慎起见，如果请求大小在路径MTU的200字节以内（如果已知），或者如果请求大小大于1300字节且路径MTU未知，则实现必须遵循[5]第18.1.1节中概述的约定，并使用拥塞控制传输。
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节中提到，在呼叫处理期间触发的第一个触发器通常是TDP，因为SSF和SCF之间没有任何预先存在的控制关系。一些Internet主机可能表示有兴趣执行基于TDP的服务（通过先验安排，这不是本规范的一部分）。因此，PSTN将通知这些主机。为此，它将向Internet主机发送SIP请求（通常为INVITE）。SIP请求的主体必须包含多部分MIME，其中包含两个MIME组件：第一部分对应于请求的正常有效负载（如果有）；第二部分将包含
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.
特定信息（例如，发射的DP）。对INVITE请求的响应，或在当前呼叫上下文中从Internet主机向PSTN发送的后续订阅消息，可能会导致EDP处于待命状态。
ICW as a benchmark SPIRITS service actually predates SPIRITS itself. Pre-SPIRITS implementations of ICW are detailed in [10]. However, as the document notes, while a diversity of implementations exists, these implementations are not interoperable. At the time [10] was published, the industry did not have the depth of experience with SIP as is the case now. The use of SIP in [10] does not constitute normative usage of SIP as described in [5]; for instance, no mention is made of the SDP (if any) in the initial INVITE (especially since this pertains to "accept the call using VoIP" case). Thus this section serves to provide a normative description of ICW in SPIRITS.
ICW作为基准烈酒服务实际上早于烈酒本身。[10]中详细介绍了ICW的预处理实现。然而，正如文档所指出的，虽然存在多种实现，但这些实现不可互操作。在[10]发表时，行业没有像现在这样对SIP有深入的经验。[10]中使用的SIP不构成[5]中所述的SIP规范用法；例如，在初始邀请中没有提到SDP（如果有）（特别是因为这涉及到“使用VoIP接受呼叫”案例）。因此，本节旨在提供ICW精神方面的规范性描述。
The description of ICW is deceptively simple: it is a service most useful for single line phone subscribers that use the line to establish an Internet session. In a nutshell, the service enables a subscriber engaged in an Internet dial-up session to
ICW的描述似乎很简单：它是一种对使用该线路建立Internet会话的单线电话用户最有用的服务。简而言之，该服务使参与Internet拨号会话的用户能够
o be notified of an incoming call to the very same telephone line that is being used for the Internet connection,
o 接到与互联网连接使用的电话线相同的来电通知，
o specify the desirable treatment of the call, and
o 指定呼叫的理想处理方式，以及
o have the call handled as specified.
o 按规定处理呼叫。
Section 2 of [10] details the call disposition outcome of a ICW session. They are reproduced here as a numbered list for further discussion:
[10]的第2节详细介绍了ICW会话的呼叫处理结果。此处将其复制为编号列表，以供进一步讨论：
1. Accepting the call over the PSTN line, thus terminating the Internet (modem) connection
1. 通过PSTN线路接受呼叫，从而终止Internet（调制解调器）连接
2. Accepting the call over the Internet using Voice over IP (VoIP)
2. 使用IP语音（VoIP）通过Internet接受呼叫
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. 将呼叫转发到语音邮件
6. Forwarding the call to another number
6. 将呼叫转接到其他号码
7. Rejecting (or Forwarding) on no Response - If the subscriber fails to respond within a certain period of time after the dialog box has been displayed, the incoming call can be either rejected or handled based on the treatment pre-defined by the subscriber.
7. 拒绝（或转发）无响应-如果用户在显示对话框后的某段时间内没有响应，则可以拒绝来电或根据用户预定义的处理方式处理来电。
It should be pointed out for the sake of completeness that ICW as a SPIRITS service is not possible without making the SCP aware of the fact that the subscriber line is being used for an Internet session. That awareness, however, is not a part of the ICW service, but solely a pre-requisite. One of the following three methods MUST be utilized to impart this information to the SCP:
为了完整性起见，应该指出，如果不让SCP意识到用户线路正在用于Internet会话，ICW作为一种服务是不可能的。然而，这种意识不是ICW服务的一部分，而仅仅是一个先决条件。必须使用以下三种方法之一将此信息告知SCP：
A. ICW subscriber based method: the ICW client on the subscriber's PC notifies the SCP of the Internet session by issuing a SIP REGISTER request.
A.基于ICW订户的方法：订户PC上的ICW客户端通过发出SIP注册请求通知SCP Internet会话。
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）接入号码列表；当拨打并连接其中一个号码时，它（SCP）假定主叫方正在进行Internet会话。
C. Any combination of methods A and B.
C.方法A和B的任何组合。
ICW depends on a TDP to be provisioned in the SSP. When the said TDP is encountered, the SSP suspends processing of the call and sends a request to the SPIRITS-capable SCP. The SCP determines that the subscriber line is being used for an Internet session. It instructs the SPIRITS notifier on the SCP to create a SIP INVITE request and send it to the SPIRITS subscriber running on the subscriber's IP host.
ICW取决于要在SSP中提供的TDP。当遇到所述TDP时，SSP暂停对呼叫的处理，并向SCP发送请求。SCP确定用户线路正用于Internet会话。它指示SCP上的SPIRITS通知程序创建SIP INVITE请求，并将其发送给在订阅者的IP主机上运行的SPIRITS订阅者。
The SPIRITS subscriber MUST return one of the possible call disposition outcomes catalogued in Section 5.4.2. Note that outcomes 1 and 4 through 7 can all be coalesced into one case, namely redirecting (using the SIP 3xx response code) the call to an alternative SIP URI. In case of 1, the URI of the redirected call MUST match the very same number being used by the customer to get online. Rejecting the call implies sending a non-2xx and non-3xx final response; the remaining outcomes result in the call being redirected to an alternate URI which provides the desired service (i.e., play a pre-recorded announcement, or record a voice message).
用户必须返回第5.4.2节中列出的一个可能的呼叫处理结果。请注意，结果1和4到7都可以合并到一个案例中，即重定向（使用SIP 3xx响应代码）对替代SIP URI的调用。在1的情况下，重定向呼叫的URI必须与客户用于联机的相同号码匹配。拒绝呼叫意味着发送非2xx和非3xx最终响应；其余结果导致呼叫被重定向到提供所需服务的备用URI（即，播放预先录制的公告或录制语音消息）。
Further processing of a SPIRITS notifier when it receives a final response can be summarized by the following steps:
当收到最终响应时，SPIRITS通知程序的进一步处理可通过以下步骤进行总结：
1. If the response is a 4xx, 5xx, or 6xx class of response, generate and transmit an ACK request and instruct the SSP to play a busy tone to the caller.
1. 如果响应为4xx、5xx或6xx类响应，则生成并发送ACK请求，并指示SSP向呼叫者播放忙音。
2. Else, for all 3xx responses, generate and transmit an ACK request, and compare the redirected URI to the subscriber's line number:
2. 否则，对于所有3xx响应，生成并发送ACK请求，并将重定向的URI与订户的线路号进行比较：
2a. If the comparison indicates a match, instruct the SSP to hold onto the call for just enough time to allow the SPIRITS subscriber to disconnect the modem, thus freeing up the line; and then continue with normal call processing, which will result in the subscriber's phone to ring.
2a。如果比较结果显示匹配，则指示SSP保持呼叫时间刚好足够，以允许用户断开调制解调器，从而释放线路；然后继续正常的呼叫处理，这将导致用户的电话响。
2b. If the comparison fails, instruct the SSP to route the call to the redirected URI.
2b。如果比较失败，则指示SSP将调用路由到重定向的URI。
3. Else, for a 2xx response, follow the steps in section 5.4.3.
3. 否则，对于2xx响应，请遵循第5.4.3节中的步骤。
One call handling option in ICW is to "accept an incoming call using VoIP". The SPIRITS notifier has no way of knowing a-priori if the subscriber (callee) will be choosing this option; nonetheless, it has to account for such a choice by adding a SDP in the body of the INVITE request. A possible way of accomplishing this is to have the SPIRITS notifier control a PSTN gateway and allocate appropriate resources on it. Once this is done, the SPIRITS notifier adds network information (IP address of the gateway and port numbers where media will be received) and codec information as the SDP portion of the body in the INVITE request. SPIRITS requires the DP information to be carried in the request body as well. To that extent, the SPIRITS notifier MUST also add the information associated with the TDP that triggered the service. Thus, the body of the INVITE MUST contain multi-part MIME, with two components.
ICW中的一个呼叫处理选项是“使用VoIP接受来电”。SPIRITS通知程序无法事先知道订户（被叫方）是否将选择此选项；尽管如此，它必须通过在INVITE请求主体中添加SDP来考虑这种选择。实现这一点的一种可能方法是让SPIRITS通知程序控制PSTN网关并在其上分配适当的资源。完成后，SPIRITS通知程序将网络信息（网关的IP地址和接收媒体的端口号）和编解码器信息添加为INVITE请求中正文的SDP部分。SPIRITS还要求在请求正文中携带DP信息。因此，SPIRITS通知程序还必须添加与触发服务的TDP相关的信息。因此，INVITE的主体必须包含多部分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通知程序将INVITE请求发送给订户，现在等待最终响应。当SPIRITS订户返回200 OK时的进一步处理必须按如下方式处理：
On the receipt of a 200 OK containing the SDP of the subscriber's UA, the SPIRITS notifier will instruct the SSP to terminate the call on a pre-allocated port on the gateway. This port MUST be correlated by the gateway to the SDP that was sent in the earlier INVITE.
收到包含用户UA SDP的200 OK后，SPIRITS通知程序将指示SSP在网关上的预分配端口上终止呼叫。网关必须将此端口与先前INVITE中发送的SDP关联。
The end result is that the caller and callee hold a voice session with part of the session occurring over VoIP.
最终结果是呼叫者和被呼叫者通过VoIP进行语音会话，会话的一部分通过VoIP进行。
There are network events that are not related to setting up, maintaining, or tearing down voice calls. Such events occur on the cellular wireless network and can be used by SPIRITS to provide services. The SPIRITS protocol requirement explicitly includes the following events for which SPIRITS notification is needed (RFC3298:Section 5(b)):
有些网络事件与设置、维护或中断语音通话无关。此类事件发生在蜂窝无线网络上，可由SPIRITS提供服务。SPIRITS协议要求明确包括以下需要SPIRITS通知的事件（RFC3298：第5（b）节）：
1. Location update in the same Visitor Location Register (VLR) service area
1. 同一访客位置登记（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. 移动用户（MS）启动IMSI分离
5. Network initiated IMSI detach
5. 网络启动的IMSI分离
Each of the five non-call related event is given a SPIRITS-specific mnemonic for use in subscriptions and notifications.
五个与呼叫无关的事件中的每一个都有一个特定于SPIRITS的助记符，用于订阅和通知。
Location update in the same VLR area SPIRITS mnemonic: LUSV Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
同一VLR区域中的位置更新：SUBSCRIBE中的助记符：LUSV强制参数：NOTIFY中的CalledPartyNumber强制参数：CalledPartyNumber，单元格ID
Cell-ID: A string used to identify the serving Cell-ID. The actual length and representation of this parameter depend on the particulars of the cellular provider's network.
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区域中的位置更新：SUBSCRIBE中的助记符：LUDV强制参数：NOTIFY中的CalledPartyNumber强制参数：CalledPartyNumber，单元格ID
IMSI attach SPIRITS mnemonic: REG Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
IMSI附加精神助记符：订阅中的REG必填参数：通知中的CalledPartyNumber必填参数：CalledPartyNumber，单元格ID
MS initiated IMSI detach SPIRITS mnemonic: UNREGMS Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
MS启动的IMSI分离指令助记符：SUBSCRIBE中的UNREMS强制参数：NOTIFY中的CalledPartyNumber强制参数：CalledPartyNumber
Network initiated IMSI detach SPIRITS mnemonic: UNREGNTWK Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
网络启动的IMSI指令助记符：SUBSCRIBE中的UNTRNTWK强制参数：NOTIFY中的CalledPartyNumber强制参数：CalledPartyNumber
A subscriber will issue a SUBSCRIBE request which identifies a set of non-call related PSTN events it is interested in getting the notification of. This set MAY contain exactly one event, or it MAY contain multiple events. The SUBSCRIBE request is routed to the notifier where it is accepted, pending a successful authentication.
订阅者将发出一个订阅请求，该请求识别一组它感兴趣的与呼叫无关的PSTN事件，以获取通知。此集合可能只包含一个事件，也可能包含多个事件。订阅请求被路由到接受它的通知程序，等待成功的身份验证。
When any of the events identified in the set occurs, the notifier will format a NOTIFY request and direct it towards the subscriber. The NOTIFY request will contain information pertinent to the one of the event whose notification was requested.
当集合中标识的任何事件发生时，通知程序将格式化通知请求，并将其指向订阅服务器。NOTIFY请求将包含与请求其通知的事件之一相关的信息。
The dialog established by the SUBSCRIBE persists until it expires normally, or is explicitly expired by the subscriber. This behavior is different than the behavior for subscriptions associated with the "spirits-INDPs" package. In the cellular network, the events subscribed for may occur at a far greater frequency than those compared to the wireline network (consider location updates as a cellular user moves around). Thus it is far more expedient to allow the subscription to expire normally.
SUBSCRIBE建立的对话框将一直保持，直到它正常过期，或者由订阅服务器显式过期。此行为不同于与“INDPs”包关联的订阅的行为。在蜂窝网络中，订阅的事件发生的频率可能远远高于有线网络（考虑蜂窝用户移动时的位置更新）。因此，允许订阅正常过期要方便得多。
When a subscriber receives a NOTIFY request, it can subsequently choose to act in a manner appropriate to the notification.
当订户收到通知请求时，它可以随后选择以适合通知的方式行事。
The remaining sections fill in the specific package responsibilities raised in RFC3265 [3], Section 4.4.
其余章节填写RFC3265[3]第4.4节中提出的具体包责任。
This document defines two event packages; the first was defined in Section 5.3. The second package, defined in this section is called "spirits-user-prof". This package MUST be used for events corresponding to non-call related events in the cellular network. All entities that implement the SPIRITS protocol and support the non-call related events outlined in the SPIRITS protocol requirements
本文件定义了两个事件包；第一个定义见第5.3节。本节中定义的第二个包称为“spirits user prof”。此软件包必须用于与蜂窝网络中的非呼叫相关事件相对应的事件。实施SPIRITS协议并支持SPIRITS协议要求中概述的非呼叫相关事件的所有实体
(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]设置为“spirits-user-prof”。“允许事件”一般标头[3]还必须包括令牌“spirits user prof”。
Example:
例子：
Event: spirits-user-prof Allow-Events: spirits-user-prof, spirits-INDPs
事件：精灵用户教授允许事件：精灵用户教授，精灵INDP
The "spirits-user-prof" event package does not support any additional parameters to the Event header
“spirits user prof”事件包不支持事件头的任何附加参数
SUBSCRIBE requests that serve to terminate the subscriptions MAY contain an empty body; however, SUBSCRIBE requests that establish a dialog MUST contain a body which encodes two pieces of information:
用于终止订阅的订阅请求可能包含空正文；但是，建立对话框的订阅请求必须包含编码两条信息的正文：
(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) 正在订阅的事件集。订阅者可以在一个订阅请求中订阅多个事件，或者可以针对其有兴趣接收通知的每个事件发出不同的订阅请求。协议允许两种形式的表示。但是，请注意，如果使用一个订阅订阅多个事件，则与该订阅关联的对话框的过期将影响所有此类事件。
(2) A list of values of the parameters associated with the event. Please see Section 6.1 for a list of parameters associated with each event.
(2) 与事件关联的参数值列表。请参阅第6.1节，了解与每个事件相关的参数列表。
The default body type for SUBSCRIBEs in SPIRITS is denoted by the MIME type "application/spirits-event+xml". The "Accept" header, if present, MUST include this MIME type.
SPIRITS中订阅的默认主体类型由MIME类型“application/SPIRITS event+xml”表示。“Accept”标头（如果存在）必须包含此MIME类型。
The duration of a dialog established by a SUBSCRIBE request is limited to the expiration time negotiated between the subscriber and notifier when the dialog was established. The subscriber MUST send a new SUBSCRIBE to refresh the dialog if it is interested in keeping it alive. A dialog can be terminated by sending a new SUBSCRIBE request with an "Expires" header value of 0, as outlined in [3].
由订阅请求建立的对话框的持续时间限制为建立对话框时订阅者和通知者之间协商的过期时间。订阅者必须发送一个新的订阅来刷新对话框，如果它想让对话框保持活动状态的话。如[3]所述，可以通过发送“Expires”头值为0的新订阅请求来终止对话框。
Bodies in NOTIFY requests for the "spirits-user-prof" package are optional. If present, they MUST be of the MIME type "application/spirits-event+xml". The body in a NOTIFY request encapsulates the following pieces of information which can be used by the subscriber:
“spirits user prof”包的NOTIFY请求中的主体是可选的。如果存在，它们必须是MIME类型“应用程序/事件+xml”。NOTIFY请求中的正文封装了订阅者可以使用的以下信息：
(1) The event that resulted in the NOTIFY being generated (typically, but not always, this will be the same event present in the corresponding SUBSCRIBE request).
(1) 导致生成通知的事件（通常，但不总是，这将是相应订阅请求中存在的相同事件）。
(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) 与为其生成通知的事件关联的参数值列表。根据实际事件，参数列表将有所不同。
When the notifier receives a SUBSCRIBE request, it MUST authenticate the request and ensure that the subscriber is authorized to access the resource being subscribed to, in this case, non-call related cellular events for a mobile phone.
当通知程序接收到订阅请求时，它必须对请求进行身份验证，并确保订户有权访问正在订阅的资源，在这种情况下，移动电话的非呼叫相关蜂窝事件。
Once the SUBSCRIBE request has been authenticated and authorized, the notifier interfaces with the SCF over interface D to set marks in the HLR corresponding to the mobile phone number contained in the SUBSCRIBE body. The particulars of interface D are outside the scope of this document; here we simply assume that the notifier is able to set the appropriate marks in the HLR.
一旦订阅请求已被认证和授权，通知者通过接口D与SCF接口，以在HLR中设置与订阅主体中包含的移动电话号码相对应的标记。接口D的细节不在本文件范围内；这里，我们只是假设通知程序能够在HLR中设置适当的标记。
If the notifier expects the setting of marks in the HLR to take more than 200 ms, it MUST send a 202 response to the SUBSCRIBE request immediately, accepting the subscription. It should then send a NOTIFY request with an empty body. This NOTIFY request MUST have a "Subscription-State" header with a value of "pending".
如果通知程序预计HLR中的标记设置需要200毫秒以上，则必须立即向订阅请求发送202响应，并接受订阅。然后，它应该发送一个带有空正文的NOTIFY请求。此通知请求必须具有值为“待定”的“订阅状态”标头。
This immediate NOTIFY with an empty body is needed since the resource identified in the SUBSCRIBE request does not have as yet a meaningful state.
由于订阅请求中标识的资源尚未处于有意义的状态，因此需要具有空正文的立即通知。
Once the notifier has successfully interfaced with the SCF, it MUST send a subsequent NOTIFY request with an empty body and a "Subscription-State" header with a value of "active."
一旦通知程序成功地与SCF交互，它必须发送一个带有空正文和一个值为“active”的“Subscription State”标头的后续通知请求
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.
当订阅请求中确定的关注事件发生时，通知者发送一个新的通知请求，该请求必须包含第6.7节所述的正文。
The exact steps executed at the subscriber when it receives a NOTIFY request depend on the nature of the service that is being implemented. As a generality, the UA associated with the subscriber should somehow impart this information to the user by visual or auditory means, if at all possible.
订阅服务器接收到通知请求时执行的确切步骤取决于正在实现的服务的性质。作为一般性，与用户相关联的UA应当以某种方式通过视觉或听觉方式（如果可能的话）将该信息传递给用户。
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE request is targeted towards the PSTN, highly irregular behaviors occur if the request is allowed to fork. The normal SIP DNS lookup and routing rules [11] should result in a target set with exactly one element: the notifier.
禁止分叉订阅请求。由于订阅请求是针对PSTN的，如果允许请求分叉，则会发生高度不规则的行为。正常的SIP DNS查找和路由规则[11]应产生一个目标集，其中只有一个元素：通知程序。
For reasons of congestion control, it is important that the rate of notifications not become excessive. For instance, if a subscriber subscribes to the location update event for a notifier moving through the cellular network at a high enough velocity, it is entirely conceivable that the notifier may generate many NOTIFY requests in a small time frame. Thus, within this package, the location update event needs an appropriate throttling mechanism.
出于拥塞控制的原因，重要的是通知速率不要过高。例如，如果订户为以足够高的速度在蜂窝网络中移动的通知者订阅位置更新事件，则完全可以想象通知者可以在小时间帧内生成许多通知请求。因此，在此包中，位置更新事件需要适当的限制机制。
Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST start a timer (Tn) with a value of 15 seconds. If a subsequent location update NOTIFY request needs to be sent out before the timer has expired, it MUST be discarded. Any future location update NOTIFY requests MUST be transmitted only if Tn has expired (i.e. 15 seconds have passed since the last NOTIFY request was send out). If a location update NOTIFY is send out, Tn should be reset to go off again in 15 seconds.
每当SPIRITS通知程序发送位置更新通知时，它必须启动一个值为15秒的计时器（Tn）。如果需要在计时器过期之前发送后续位置更新通知请求，则必须放弃该请求。任何未来位置更新通知请求必须仅在Tn已过期（即，自上次通知请求发出后已过15秒）的情况下发送。如果发出位置更新通知，则应在15秒内将Tn重置为再次关闭。
State agents are not used in SPIRITS.
国家代理人不用于烈性酒。
This section contains an example of a SPIRITS service that may be used to update the presence status of a mobile user. The call flow is depicted in Figure 4 below.
本节包含可用于更新移动用户的存在状态的SPIRITS服务的示例。调用流如下图4所示。
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Set HLR mark|
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Set HLR mark|
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 4: Sample call flow
图4：示例调用流
In F1 of Figure 4, the subscriber indicates an interest in receiving a notification when a mobile user registers with the cellular network. The cellular network notes this event (F2) and confirms the subscription (F3-F5). When the mobile user turns on her cell phone and registers with the network, this event is detected (F6). The cellular network then sends out a notification to the subscriber informing it of this event (F7-F8).
在图4的F1中，当移动用户向蜂窝网络注册时，订户表示有兴趣接收通知。蜂窝网络记录此事件（F2）并确认订阅（F3-F5）。当移动用户打开手机并向网络注册时，会检测到此事件（F6）。然后，蜂窝网络向用户发送通知，通知其该事件（F7-F8）。
We present the details of the call flow next.
接下来我们将介绍调用流的详细信息。
In F1, the subscriber subscribes to the registration event (REG) of a cellular phone number.
在F1中，用户订阅手机号码的注册事件（REG）。
F1: S->N SUBSCRIBE sip:myprovider.com SIP/2.0 From: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:16302240216@myprovider.com> CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.example.com Contact: <sip:vkg@host.example.com> Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8 Expires: 3600 Event: spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof Accept: application/spirits-event+xml Content-Type: application/spirits-event+xml Content-Length: ...
F1:S->N订阅sip:myprovider.com sip/2.0发件人：<sip:vkg@example.com>;标签=8177-afd-991至：<sip:16302240216@myprovider.com>CSeq:18992订阅呼叫ID:3329as77@host.example.com联系人：<sip:vkg@host.example.com>Via:SIP/2.0/UDP host.example.com；branch=z9hG4bK776asdhdsa8过期：3600事件：精灵用户教授允许事件：精灵INDP，精灵用户教授接受：应用程序/精灵事件+xml内容类型：应用程序/精灵事件+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
The subscription reaches the notifier which authenticates the request (not shown) and interacts with the SCF to update the subscribers database for this event. The notifier sends out a successful response to the subscription:
订阅到达通知程序，通知程序验证请求（未显示），并与SCF交互以更新此事件的订阅服务器数据库。通知程序向订阅发送成功响应：
F3: N->S
SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
Expires: 3600
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0
F3: N->S
SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
Expires: 3600
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0
The notifier also sends out a NOTIFY request confirming the subscription:
通知程序还发送一个确认订阅的通知请求：
F4: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
F4: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0
The subscriber confirms the receipt of the NOTIFY request:
订户确认收到通知请求：
F5: S->N
SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Content-Length: 0
F5: S->N
SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Content-Length: 0
In F6, the mobile user identified by the PSTN number "6302240216" turns the mobile phone on, thus causing it to register with the cellular network. The cellular network detects this event, and since a subscriber has indicated an interest in receiving a notification of this event, a SIP NOTIFY request is transmitted towards the subscriber:
在F6中，由PSTN号码“630224216”标识的移动用户打开移动电话，从而使其向蜂窝网络注册。蜂窝网络检测到该事件，并且由于订户已表示有兴趣接收该事件的通知，因此向订户发送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通知sip:vkg@host.example.comSIP/2.0至：<SIP:vkg@example.com>;标签=8177-afd-991发件人：<sip:16302240216@myprovider.com>;tag=SPRITS-REG-16302240216 CSeq:9122通知呼叫ID:3329as77@host.example.com联系人：<sip:notifier.myprovider.com>订阅状态：已终止；原因=通过以下方式触发：SIP/2.0/UDP notifier.myprovider.com；branch=z9hG4bK7yi-p12事件：精灵用户教授允许事件：精灵INDP，精灵用户教授接受：应用程序/精灵事件+xml内容类型：应用程序/精灵事件+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<Cell-ID>45987</Cell-ID>
</Event>
</spirits-event>
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<Cell-ID>45987</Cell-ID>
</Event>
</spirits-event>
The subscriber receives the notification and acknowledges it by sending a response:
订户收到通知并通过发送响应进行确认：
F8: S->N
F8:S->N
SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.example.com
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Content-Length: 0
SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.example.com
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Content-Length: 0
Note that once the subscriber has received this notification, it can execute appropriate services. In this particular instance, an appropriate service may consist of the subscriber acting as a composer of a presence service and turning the presence status of the user associated with the phone number "6302240216" to "on". Also note in F7 that the notifier included a Cell ID in the notification.
请注意，一旦订阅服务器收到此通知，它就可以执行适当的服务。在该特定实例中，适当的服务可包括充当存在服务的构造器的订户，并将与电话号码“630224216”相关联的用户的存在状态转换为“开”。还要注意，在F7中，通知程序在通知中包含一个单元格ID。
The Cell ID can be used as a basis for location specific services; however, a discussion of such services is out of the scope of this document.
小区ID可以用作位置特定服务的基础；但是，对此类服务的讨论超出了本文件的范围。
The "spirits-user-prof" package MUST NOT use URIs to retrieve state. It is expected that most state information for this package is compact enough to fit in a SIP message. However, to err on the side of caution, implementations MUST follow the convention outlined in Section 18.1.1 of [5] and use a congestion controlled transport if the size of the request is within 200 bytes of the path MTU if known, or if the request size is larger than 1300 bytes and the path MTU is unknown.
“spirits user prof”包不得使用URI检索状态。预计此包的大多数状态信息都足够紧凑，可以放入SIP消息中。然而，为了谨慎起见，如果请求大小在路径MTU的200字节以内（如果已知），或者如果请求大小大于1300字节且路径MTU未知，则实现必须遵循[5]第18.1.1节中概述的约定，并使用拥塞控制传输。
This document calls for IANA to:
本文件要求IANA：
o register two new SIP Event Packages per [3].
o 根据[3]注册两个新的SIP事件包。
o register a new MIME type per [20].
o 根据[20]注册新的MIME类型。
o register a new namespace URN per [16].
o 根据[16]注册一个新的命名空间URN。
o register a new XML schema per [16].
o 根据[16]注册新的XML架构。
Package Name: spirits-INDPs
包装名称：烈酒INDPs
Type: package
类型：包装
Contact: Vijay K. Gurbani, vkg@lucent.com
联系人：Vijay K.Gurbani，vkg@lucent.com
Reference: RFC 3910
参考：RFC3910
Package Name: spirits-user-prof
软件包名称：spirits user prof
Type: package
类型：包装
Contact: Vijay K. Gurbani, vkg@lucent.com
联系人：Vijay K.Gurbani，vkg@lucent.com
Reference: RFC 3910
参考：RFC3910
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（与application/xml[9]中的charset参数语义相同）
Encoding considerations: same as considerations outlined for application/xml in [9].
编码注意事项：与[9]中为application/xml概述的注意事项相同。
Security considerations: Section 10 of [9] and Section 8 of this document.
安全注意事项：本文件[9]第10节和第8节。
Interoperability considerations: none.
互操作性考虑：无。
Published specifications: this document.
已发布规范：本文档。
Applications which use this media type: SPIRITS aware entities which adhere to this document.
使用此媒体类型的应用程序：遵循此文档的SPIRITS感知实体。
Additional information:
其他信息：
Magic number(s): none.
幻数：无。
File extension(s): none.
文件扩展名：无。
Macintosh file type code(s): none.
Macintosh文件类型代码：无。
Object Identifier(s) or OID(s): none.
对象标识符或OID：无。
Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com>
Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com>
Intended usage: Common
预期用途：普通
Author/Change controller: The IETF
作者/变更控制者：IETF
URI
urn:ietf:params:xml:ns:spirits-1.0
URI
urn:ietf:params:xml:ns:spirits-1.0
Description This is the XML namespace URI for XML elements defined by this document. Such elements describe the SPIRITS information in the "application/ spirits-event+xml" content type.
描述这是此文档定义的XML元素的XML命名空间URI。这些元素描述“application/SPIRITS event+xml”内容类型中的SPIRITS信息。
Registrant Contact IESG.
注册人联系IESG。
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for SPIRITS-related information</title>
</head>
<body>
<h1>Namespace for SPIRITS-related information</h1>
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for SPIRITS-related information</title>
</head>
<body>
<h1>Namespace for SPIRITS-related information</h1>
<h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
</body>
</html>
END
<h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
</body>
</html>
END
URI
urn:ietf:params:xml:schema:spirits-1.0
URI
urn:ietf:params:xml:schema:spirits-1.0
Description XML base schema for SPIRITS entities.
描述实体的XML基本架构。
Registrant Contact IESG.
注册人联系IESG。
XML Please see XML schema definition in Section 9 of this document.
XML请参阅本文档第9节中的XML模式定义。
This section focuses on security considerations which are unique to SPIRITS. SIP security mechanisms are discussed in detail in the core SIP specification [5] and are outside the scope of this document. SPIRITS security mechanisms are based on and strengthen SIP security [5], for example, SPIRITS mandates the support of S/MIME. Beyond that, any other security solutions specified in [5], i.e., TLS or HTTP Digest authentication, may be utilized by SPIRITS operators.
本节重点介绍SPIRITS独有的安全注意事项。SIP安全机制在核心SIP规范[5]中进行了详细讨论，超出了本文档的范围。SPIRITS安全机制基于并加强SIP安全[5]，例如，SPIRITS要求支持S/MIME。除此之外，[5]中规定的任何其他安全解决方案，即TLS或HTTP摘要身份验证，都可以由SPIRITS运营商使用。
As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the following security aspects are applicable to the SPIRITS protocol:
如RFC3298[4]第9章（安全考虑）所述，以下安全方面适用于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。其中只有两个——B和C——是SPIRITS感兴趣的。接口A和E是PINT接口，因此假定由PINT RFC保护[8]。接口D的安全性超出了本文档的范围，因为它主要涉及PSTN基础设施。我们将在某些假设的基础上讨论接口B和C的安全方面。
A driving assumption for SPIRITS security is that the SPIRITS gateway is owned by the same PSTN operator that owns the SPIRITS notifier. Thus, it is attractive to simply relegate security of interface C to the PSTN operator, and in fact, there are merits to doing just that since interface C crosses the IP Network and PSTN boundaries. However, a closer inspection reveals that both interfaces B and C transmit the SPIRITS protocol; thus, any security arrangement we arrive at for interface B can be suitably applied to interface C as well. This makes it possible to secure interface C in case the SPIRITS gateway is not owned by the same PSTN operator that owns the SPIRITS notifier.
SPIRITS安全的驱动假设是SPIRITS网关由拥有SPIRITS通知程序的同一PSTN运营商拥有。因此，将接口C的安全性简单地交给PSTN运营商是有吸引力的，事实上，这样做是有好处的，因为接口C跨越了IP网络和PSTN边界。然而，仔细检查发现，接口B和C都传输协议；因此，我们为接口B达成的任何安全安排也可以适用于接口C。这使得在SPIRITS网关不属于拥有SPIRITS通知程序的同一PSTN运营商的情况下保护接口C成为可能。
The ensuing security discussion assumes that the SPIRITS subscriber is communicating directly to the SPIRITS notifier (and vice-versa) and specifies a security apparatus for this arrangement. However, the same apparatus can be used to secure the communication between a SPIRITS subscriber and an intermediary (like the SPIRITS gateway), and the same intermediary and the SPIRITS notifier.
接下来的安全性讨论假设SPIRITS订户直接与SPIRITS通知器通信（反之亦然），并为此安排指定安全装置。然而，相同的设备可用于保护SPIRITS订户和中介（如SPIRITS网关）以及相同中介和SPIRITS通知器之间的通信。
Confidentiality of the SPIRITS protocol is essential since the information carried in the protocol data units is of a sensitive nature and may lead to privacy concerns if revealed to non-authorized parties. The communication path between the SPIRITS notifier and the SPIRITS subscriber should be secured through S/MIME [18] to alleviate privacy concerns, as is described in the Security Consideration section of the core SIP specification [5].
SPIRITS协议的保密性至关重要，因为协议数据单元中携带的信息具有敏感性质，如果泄露给非授权方，可能会导致隐私问题。SPIRITS通知程序和SPIRITS订户之间的通信路径应通过S/MIME[18]进行保护，以缓解隐私问题，如核心SIP规范[5]的安全考虑部分所述。
S/MIME is an end-to-end security mechanism which encrypts the SPIRITS bodies for transit across an open network. Intermediaries need not be cognizant of S/MIME in order to route the messages (routing headers travel in the clear).
S/MIME是一种端到端的安全机制，它对服务器进行加密，以便在开放网络中传输。中间人不需要知道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负载由授权实体生成。加密将确保只有那些拥有特定解密密钥的精灵实体能够在SIP请求中检查封装的精灵体。
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运营商，则可能会在端点中安装公钥。
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支持两种方法——issuerAndSerialNumber和subjectKeyIdentifier——来命名验证签名所需的公钥。在这两者之间，subjectKeyIdentifier也适用于X.509证书和其他方案，而issuerAndSerialNumber仅适用于X.509证书。如果管理员配置了必要的公钥，通过过程方式提供完整性，则可以在没有X.509证书的情况下使用S/MIME。
All requests (and responses) between SPIRITS entities MUST be encrypted.
实体之间的所有请求（和响应）都必须加密。
When a request arrives at a SPIRITS notifier from a SPIRITS subscriber, the SPIRITS notifier MUST authenticate the request. The subscription (or registration) from a SPIRITS subscriber MUST be rejected if the authentication fails. If the SPIRITS subscriber successfully authenticated itself to the SPIRITS notifier, the SPIRITS notifier MUST, at the very least, ensure that the SPIRITS subscriber is indeed allowed to receive notifications of the events it is subscribing to.
当来自SPIRITS订户的请求到达SPIRITS通知程序时，SPIRITS通知程序必须验证该请求。如果身份验证失败，则必须拒绝来自用户的订阅（或注册）。如果SPIRITS订阅者成功地向SPIRITS通知者进行了身份验证，那么SPIRITS通知者至少必须确保SPIRITS订阅者确实被允许接收其订阅的事件的通知。
Note that this document does not proscribe how the SPIRITS notifier achieves this. In practice, it could be through access control lists (ACL) that are populated by a service management system in the PSTN, or through a web interface of some sort.
请注意，本文档并未禁止SPIRITS通知程序如何实现这一点。实际上，它可以通过PSTN中的服务管理系统填充的访问控制列表（ACL），或者通过某种web界面。
Requests from the SPIRITS notifier to the SPIRITS subscribers MUST also be authenticated, lest a malicious party attempts to fraudulently pose as a SPIRITS notifier to hijack a session.
从SPIRITS通知程序到SPIRITS订户的请求也必须经过身份验证，以免恶意方试图欺诈性地冒充SPIRITS通知程序劫持会话。
The SPIRITS payload is specified in XML; this section defines the base XML schema for documents that make up the SPIRITS payload. All SPIRITS entities that transport a payload characterized by the MIME type "application/spirits-event+xml" MUST support documents corresponding to the base schema below.
有效负载是用XML指定的；本节为构成有效负载的文档定义基本XML模式。传输以MIME类型“application/SPIRITS event+xml”为特征的有效负载的所有SPIRITS实体都必须支持与下面的基本架构对应的文档。
Multiple versions of the base schema are not expected; rather, any additional functionality (e.g., conveying new PSTN events) must be accomplished through the definition of a new XML namespace and a corresponding schema. Elements from the new XML namespace will then co-exist with elements from the base schema in a document.
基本架构不应有多个版本；相反，任何附加功能（例如，传送新的PSTN事件）都必须通过定义新的XML名称空间和相应的模式来实现。然后，新XML命名空间中的元素将与文档中基本模式中的元素共存。
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
Describes SPIRITS events.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation xml:lang="en">
Describes SPIRITS events.
</xs:documentation>
</xs:annotation>
<xs:element name="spirits-event" type="tns:SpiritsEventType"/>
<xs:element name="spirits-event" type="tns:SpiritsEventType"/>
<xs:complexType name="SpiritsEventType">
<xs:sequence>
<xs:element name="Event" type="tns:EventType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SpiritsEventType">
<xs:sequence>
<xs:element name="Event" type="tns:EventType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EventType">
<xs:sequence>
<xs:element name="CalledPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="CallingPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="DialledDigits" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cell-ID" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cause" type="tns:CauseType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="type" type="tns:PayloadType"
use="required"/>
<xs:attribute name="name" type="tns:EventNameType"
use="required"/>
<xs:attribute name="mode" type="tns:ModeType"
use="optional" default="N"/>
</xs:complexType>
<xs:complexType name="EventType">
<xs:sequence>
<xs:element name="CalledPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="CallingPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="DialledDigits" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cell-ID" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cause" type="tns:CauseType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="type" type="tns:PayloadType"
use="required"/>
<xs:attribute name="name" type="tns:EventNameType"
use="required"/>
<xs:attribute name="mode" type="tns:ModeType"
use="optional" default="N"/>
</xs:complexType>
<xs:simpleType name="PayloadType">
<!-- The <spirits-event> will contain either a list of -->
<!-- INDPs events or a list of userprof events -->
<xs:restriction base="xs:string">
<xs:enumeration value="INDPs"/>
<xs:enumeration value="userprof"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="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">
<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>
The authors are grateful to participants in the SPIRITS WG for the discussion that contributed to this work. These include J-L. Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B. Chatras, O. Cleuziou, L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W. Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg, H. Sinnreich, L. Slutsman, D. Varney, and W. Zeuch. The authors also acknowledge Steve Bellovin, Allison Mankin and Jon Peterson for help provided on the Security section.
作者感谢SPIRITS工作组的与会者对这项工作所做的讨论。这些人包括J-L.巴克、J.比约克纳、J.布勒、J-E.查普伦、B.查特拉斯、O.克鲁乔、L.康罗伊、R.福布斯、F.海伦斯、J.汉弗莱、J.科齐克、W.蒙哥马利、S.尼克尔加德、M.O'Doherty、A.罗奇、J.罗森博格、H.辛里奇、L.斯勒特曼、D.瓦尼和W.泽克。作者还感谢Steve Bellovin、Allison Mankin和Jon Peterson在安全部分提供的帮助。
ACL Access Control List CS Capability Set DP Detection Point DTD Document Type Definition EDP Event Detection Point EDP-N Event Detection Point "Notification" EDP-R Event Detection Point "Request" IANA Internet Assigned Numbers Authority ICW Internet Call Waiting IMSI International Mobile Subscriber Identity IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol ISP Internet Service Provider ITU International Telecommunications Union MIME Multipurpose Internet Mail Extensions MS Mobile Station (or Mobile Subscriber) OBCSM Originating Basic Call State Model PIC Point In Call PINT PSTN/Internet Interworking PSTN Public Switched Telephone Network SCF Service Control Function
ACL访问控制列表CS能力集DP检测点DTD文档类型定义EDP事件检测点EDP-N事件检测点“通知”EDP-R事件检测点“请求”IANA互联网分配号码管理局ICW互联网呼叫等待IMSI国际移动用户智能网身份INAP智能网应用协议IP互联网协议ISP互联网服务提供商ITU国际电信联盟MIME多用途互联网邮件扩展MS移动台（或移动用户）OBCSM发起基本呼叫状态模型PIC呼叫点PINT PSTN/互联网互通PSTN公共交换电话网SCF服务控制功能
SCP Service Control Point SDP Session Description Protocol SIP Session Initiation Protocol SIP-T SIP for Telephones SPIRITS Services in the PSTN/IN Requesting InTernet Services SSF Service Switching Function SSP Service Switching Point STD State Transition Diagram TBCSM Terminating Basic Call State Model TDP Trigger Detection Point TDP-N Trigger Detection Point "Notification" TDP-R Trigger Detection Point "Request" TLS Transport Layer Security UA User Agent VLR Visitor Location Register WIN Wireless Intelligent Network XML Extensible Markup Language
SCP服务控制点SDP会话描述协议SIP会话启动协议SIP-T电话SIP-PSTN/in请求InTernet服务SSF服务切换功能SSP服务切换点STD状态转换图TBCSM终止基本呼叫状态模型TDP触发器检测点TDP-N触发器检测点“通知”TDP-R触发检测点“请求”TLS传输层安全UA用户代理VLR访客位置寄存器WIN无线智能网XML可扩展标记语言
[1] Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The SPIRITS Architecture", RFC 3136, June 2001.
[1] Slutsman，L.，Faynberg，I.，Lu，H.，和M.Weissman，“精神建筑”，RFC 31362001年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[4] Faynberg, I., Gato, J., Lu, H., and L. Slutsman, "Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements", RFC 3298, August 2002.
[4] Faynberg，I.，Gato，J.，Lu，H.，和L.Slutsman，“公共交换电话网/智能网（PSTN/in）中的服务请求互联网服务（SPIRITS）协议要求”，RFC 3298，2002年8月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F. Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection of IN parameters to be carried by the SPIRITS Protocol", Work In Progress, January 2003.
[6] M.埃莫霍帕、K.Vemuri、A.Brusilovsky、E.Dacloush、A.Zaki、F.Haerens、J-L.Bakker、B.Chatras和J.Dobrowolski，“关于烈性酒协议中待执行的IN参数选择”，正在进行的工作，2003年1月。
[7] Intelligent Network Capability Set 2. ITU-T, Recommendation Q.1228.
[7] 智能网络能力集2。ITU-T，建议Q.1228。
[8] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[8] Petrack，S.和L.Conroy，“PINT服务协议：电话呼叫服务IP接入的SIP和SDP扩展”，RFC 28482000年6月。
[9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[9] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[10] Lu, H., Faynberg, I., Voelker, J., Weissman, M., Zhang, W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., Nyckelgard, S., Yoakum, J., and L. Robart, "Pre-Spirits Implementations of PSTN-initiated Services", RFC 2995, November 2000.
[10] Lu，H.，Faynberg，I.，Voelker，J.，Weissman，M.，Zhang，W.，Rhim，S.，Hwang，J.，Ago，S.，Moeenddin，S.，Hadvani，S.，Nycellgard，S.，Yoakum，J.，和L.Robart，“PSTN启动服务的前精神实现”，RFC 29952000年11月。
[11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[11] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001. <http://www.w3c.org/XML/>.
[12] Thompson，H.，Beech，D.，Maloney，M.和N.Mendelsohn，“XML模式第1部分：结构”，W3C REC-xmlschema-1-20010502，2001年5月<http://www.w3c.org/XML/>.
[13] "Interface recommendations for intelligent network capability set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June 2000.
[13] “智能网络能力集3的接口建议：SCF-SSF接口”，ITU-T建议Q.1238.2，2000年6月。
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[15] Moats，R.，“IETF文档的URN名称空间”，RFC 2648，1999年8月。
[16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[16] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in XML", W3C recommendation: xml-names, 14th January 1999, <http://www.w3.org/ TR/REC-xml-names>.
[17] Tim Bray、Dave Hollander和Andrew Layman，“XML中的名称空间”，W3C推荐：XML名称，1999年1月14日<http://www.w3.org/ TR/REC xml名称>。
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[18] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services", McGraw-Hill, 1997.
[19] Faynberg，I.，L.Gabuzda，M.Kaplan和N.Shah，“智能网络标准：它们在服务中的应用”，McGraw-Hill，1997年。
[20] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[20] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
Kumar Vemuri Lucent Technologies, Inc. 2000 Naperville Rd. Naperville, IL 60566 USA
Kumar Vemuri-Lucent Technologies，Inc.美国伊利诺伊州纳珀维尔路2000号，邮编：60566
EMail: vvkumar@lucent.com
EMail: vvkumar@lucent.com
Vijay K. Gurbani, Editor 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA
Vijay K.Gurbani，美国伊利诺伊州纳珀维尔市朗讯巷2000室编辑，邮编：60566
EMail: vkg@lucent.com
EMail: vkg@lucent.com
Alec Brusilovsky 2601 Lucent Lane Lisle, IL 60532-3640 USA
美国伊利诺伊州利斯勒市朗讯巷2601号亚历克·布鲁斯洛夫斯基60532-3640
EMail: abrusilovsky@lucent.com
EMail: abrusilovsky@lucent.com
Igor Faynberg Lucent Technologies, Inc. 101 Crawfords Corner Rd. Holmdel, NJ 07733 USA
Igor Faynberg-Lucent Technologies，Inc.美国新泽西州霍姆德尔克劳福德角路101号，邮编：07733
EMail: faynberg@lucent.com
EMail: faynberg@lucent.com
Jorge Gato Vodafone Espana Isabel Colbrand, 22 28050 Madrid Spain
豪尔赫·加托·沃达丰西班牙伊莎贝尔·科尔布兰德，22 28050西班牙马德里
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
许兰路贝尔实验室/朗讯科技公司，新泽西州霍姆德尔克劳福德角路101号4C-607A室，邮编：07733
Phone: (732) 949-0321 EMail: huilanlu@lucent.com
电话：（732）949-0321电子邮件：huilanlu@lucent.com
Musa Unmehopa Lucent Technologies, Inc. Larenseweg 50, Postbus 1168 1200 BD, Hilversum, The Netherlands
Musa Emohopa Lucent Technologies，Inc.Larenseweg 50，Postbus 1168 1200 BD，荷兰Hilversum
EMail: unmehopa@lucent.com
EMail: unmehopa@lucent.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。