Network Working Group I. Faynberg, Editor
Request for Comments: 3298 Lucent Technologies
Category: Informational J. Gato
Vodaphone
H. Lu
Lucent Technologies
L. Slutsman
AT&T
August 2002
Network Working Group I. Faynberg, Editor
Request for Comments: 3298 Lucent Technologies
Category: Informational J. Gato
Vodaphone
H. Lu
Lucent Technologies
L. Slutsman
AT&T
August 2002
Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
公共交换电话网/智能网（PSTN/in）中的服务请求InTernet服务（SPIRITS）协议要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
本文件描述了基于RFC 3136中提出的体系结构的SPIRITS协议要求。（SPIRITS代表“PSTN中的服务/请求InTernet服务”。）协议的目的是支持源自公共交换电话网（PSTN）的服务，并需要PSTN和InTernet之间的交互。类似地，此类服务称为服务。（Internet呼叫等待、Internet呼叫者ID传递和Internet呼叫转发是SPIRIT服务的示例，但协议将定义可用于构建许多其他服务的构建块。）在PSTN端，SPIRIT服务从智能网络（IN）实体启动；早期IETF关于PSTN/互联网互通（PINT）的工作产生了协议（RFC 2848），以支持以另一种方式启动的服务——从互联网到PSTN。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
为此，本文档列出了SPIRITS协议的一般要求以及与IN、Wireless IN和PINT构建块相关的要求。本文件还介绍了SPIRITS工作组关于选择SPIRITS信令协议的共识。
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 RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristics-- services being invoked from an IP network (vs. PSTN).
除非另有限定，这里使用的术语PINT不是指当前的PINT服务和协议，而是指通用PINT（vs.SPIRITS）服务特征的范围——从IP网络（vs.PSTN）调用的服务。
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service.") The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
本文件描述了基于RFC 3136中提出的体系结构的SPIRITS协议要求。（SPIRITS代表“PSTN中的服务/请求InTernet服务”。）协议的目的是支持源自公共交换电话网（PSTN）的服务，并需要PSTN和InTernet之间的交互。这种服务称为精神服务。（Internet呼叫等待、Internet呼叫者ID传递和Internet呼叫转发是SPIRIT服务的示例，但协议将定义可用于构建许多其他服务的构建块。）在PSTN端，SPIRIT服务从智能网络（IN）实体启动；早期IETF关于PSTN/互联网互通（PINT）的工作产生了协议（RFC 2848），以支持以另一种方式启动的服务——从互联网到PSTN。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. The joint PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.
为此，本文档列出了SPIRITS协议的一般要求以及与IN、Wireless IN和PINT构建块相关的要求。本文件还介绍了SPIRITS工作组关于选择SPIRITS信令协议的共识。联合品脱/烈酒体系结构（如[1]所述）如图1所示。
It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in [2].)
假设Spirits客户端与服务内控制功能（SCF）位于同一位置，或者以这样的方式（通过PSTN特定接口D）与其通信，以便代表PSTN/IN。（如[2]所述，目前的实施证实了这一假设。）
The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS gateway. The Spirits gateway processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or
当来自SPIRITS客户端（位于服务内控制点[SCP]或服务节点[SN]）的消息到达SPIRITS网关的接口C时，调用SPIRITS服务（随后，启动SPIRITS协议）。Spirits网关处理消息，然后通过接口B将消息传递给Spirits服务器。在大多数实际重要的情况下，来自SPIRITS客户端的请求最终是由中央办公室（即电话交换机）发送到SCP或SCP的请求引起的
SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. (Definitely, none of the SPIRITS benchmark services are initiated in such a way, so, for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Service Switching Function.)
SN，尽管理论上可以由这些未由中央办公室触发的元素启动基于Internet的服务。（毫无疑问，没有任何SPIRITS基准服务是以这种方式启动的，因此，为了SPIRITS协议开发的目的，应该假设服务调用是服务切换功能早期操作的直接结果。）
......................
+----------------+ . .
| +------------+ | . +------------+ .
| | | | A . | | .
| | PINT Client|********************|PINT Server/|********
| | | | . | Gateway | *
| +------------+ | . +------------+ . *
| | . . *
| Subscriber's | . . *
| | . . *
| IP Host | . . *
| | . +------------+ . *
| +------------+ | . | SPIRITS | . *
| | SPIRITS | | B . | Gateway | . *
| | Server |********************| | . * E
| | | | . +------------+ . *
| +------------+ | . * . *
+----------------+ . * . *
...........*.......... *
* *
* *
Subscriber's * C *
Telephone * *
* *
(---) * *
* * *
* * * *
++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++
* * *
* * *
* +------------------+ *
* Line | SPIRITS Client | *
* | | *
+--------------------+ +---+----- D ---------+-*+
| | INAP/SS7 | |
|Service Switching ************Service Control Function |
| Function | | |
| | +-------------------------+
| |
| |
+--------------------+
......................
+----------------+ . .
| +------------+ | . +------------+ .
| | | | A . | | .
| | PINT Client|********************|PINT Server/|********
| | | | . | Gateway | *
| +------------+ | . +------------+ . *
| | . . *
| Subscriber's | . . *
| | . . *
| IP Host | . . *
| | . +------------+ . *
| +------------+ | . | SPIRITS | . *
| | SPIRITS | | B . | Gateway | . *
| | Server |********************| | . * E
| | | | . +------------+ . *
| +------------+ | . * . *
+----------------+ . * . *
...........*.......... *
* *
* *
Subscriber's * C *
Telephone * *
* *
(---) * *
* * *
* * * *
++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++
* * *
* * *
* +------------------+ *
* Line | SPIRITS Client | *
* | | *
+--------------------+ +---+----- D ---------+-*+
| | INAP/SS7 | |
|Service Switching ************Service Control Function |
| Function | | |
| | +-------------------------+
| |
| |
+--------------------+
Figure 1. Joint PINT/SPIRITS Architecture
图1。联合品脱/烈酒建筑
With PINT (and that also applies to the PINT architecture and protocol as described in [3]), the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by [3]) or communicate with it over the PSTN-specific interface E.
对于PINT（也适用于[3]中所述的PINT体系结构和协议），PINT客户端始终通过接口A发起对PINT服务器的服务请求。PINT服务器可以与服务内控制或类似实体（由[3]称为“执行系统”）位于同一位置或者通过PSTN专用接口E与之通信。
As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co-located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Gateway or PINT Server and SPIRITS Client other than by listing the overall PINT-related requirements.
如图1所示，PINT客户端和SPIRITS服务器位于订户的IP主机中。事实上，两者都可以实现为作为一个进程运行。没有为PINT客户端和服务器之间的交互做任何准备。类似地，假定PINT服务器/PINT网关和SPIRITS网关也位于同一位置。这种假设是方便的，但不是必要的；PINT服务器也可以与SPIRITS客户端位于同一位置。在这两种情况下，除了列出与PINT相关的总体要求外，未对PINT服务器与Spirits网关或PINT服务器与Spirits客户端之间的互通进行具体规定。
Since the currently deployed worldwide wireless networks are based on circuit switching, they are considered PSTN networks for the SPIRITS purposes. Adding SPIRITS type of services to wireless networks can allow new services to be developed (for example geolocation information can be handled in the IP network).
由于目前部署的全球无线网络是基于电路交换的，因此它们被视为PSTN网络。向无线网络添加服务类型可以允许开发新的服务（例如，可以在IP网络中处理地理位置信息）。
Nevertheless, there are certain peculiarities of wireless networks, which force considerations to be made in the protocol requirements and in the SPIRITS architecture.
然而，无线网络具有某些特殊性，这迫使在协议要求和体系结构中进行考虑。
A particular Wireless IN standard development being considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The relevant service and architectural considerations and protocol requirements are presented later in this document. As far as the architecture is concerned, certain wireless events are generated by Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC) (a wireless equivalent of the SSP). These events are communicated to Service Control, at which point they use the same mechanism for invoking SPIRITS services that the IN would.
这里考虑的一个特定的无线标准开发是由第三代合作伙伴集团（3GPP）标准化的CAMEL第3阶段。本文档后面将介绍相关的服务和体系结构注意事项以及协议要求。就架构而言，某些无线事件由归属位置寄存器（HLR）生成，归属位置寄存器（HLR）可以但不必是移动交换中心（MSC）（SSP的无线等效物）的一部分。这些事件被传递给服务控制，在这一点上，它们使用与IN相同的机制来调用SPIRITS服务。
The rest of this document addresses the general requirements, IN Requirements, specific Wireless IN requirements, PINT Requirements, the protocol development methodology, and security issues, in that order.
本文档的其余部分按顺序介绍了一般要求、IN要求、特定无线IN要求、PINT要求、协议开发方法和安全问题。
Based on the success of extending SIP for PINT ([3]) and, especially, the results of pre-SPIRITS implementations reported in [2], the Session Initiation Protocol (SIP) [7] has been chosen as the signaling base protocol for SPIRITS.
基于PINT（[3]）扩展SIP的成功，特别是[2]中报告的pre-SPIRITS实现的结果，会话启动协议（SIP）[7]被选为SPIRITS的信令基础协议。
Thus, it is a requirement that specific SPIRITS-related parameters be carried in a manner consistent with SIP practices. In particular, either Session Description Protocol (SDP) [8] or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this purpose. Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and extensions already defined in PINT, no new SIP extensions are foreseen; instead the SPIRITS protocol is to rely on the above extension mechanisms.
因此，要求以与SIP实践一致的方式执行特定白酒相关参数。特别地，会话描述协议（SDP）[8]或多用途Internet邮件扩展MIME[5-6]可用于此目的。除了提议的新订阅/通知机制[4]和PINT中已经定义的扩展之外，没有预见到新的SIP扩展；相反，SPIRITS协议依赖于上述扩展机制。
It is by no means a requirement that any SPIRITS implementation automatically support PINT services. The SPIRITS protocol must be defined in a manner where, as the minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated [2] that combining PINT building blocks with those of SPIRITS is beneficial to building rich, enhanced PSTN/Internet services, so the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document.
这决不是要求任何SPIRITS实现自动支持PINT服务。SPIRITS协议的定义方式必须至少能够支持基本的通知机制，而不依赖PINT服务或以其他方式依赖与PSTN的持久交互。然而，已经证明[2]将PINT构建块与SPIRITS构建块相结合有利于构建丰富、增强的PSTN/互联网服务，因此SPIRITS协议必须满足本文件第7节中列出的PINT相关要求。
One specific example demonstrating the application of the latter requirement, which is elaborated on further in this document, is as follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method; however, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to obtain further notifications of the PSTN events. Subsequently, these events will be reported on by means of the NOTIFY method.
本文件将进一步阐述后一项要求的具体应用示例如下：就最低限度协议而言，订阅/通知的实施不是强制性的。因此，初始PSTN（检测点）通知将始终通过SIP INVITE方法到达；然而，为了实现与PSTN的持久交互，可以使用SUBSCRIBE方法来获取PSTN事件的进一步通知。随后，将通过NOTIFY方法报告这些事件。
The interface immediately relevant to IN is that between the SPIRITS Client and SPIRITS Gateway (interface C). A typical message (which starts a SPIRITS service) looks like this:
与IN直接相关的接口是SPIRITS客户端和SPIRITS网关之间的接口（接口C）。典型的消息（启动SPIRITS服务）如下所示：
C -> G: <Event Notification>, <Parameter-List (DP)>
C -> G: <Event Notification>, <Parameter-List (DP)>
The relevant events correspond to the detection points (DPs) of the IN Basic Call State Model (BCSM). The <Parameter-List> is a function of a specific DP; it contains the parameters relevant to it. The following requirements apply:
相关事件对应于基本呼叫状态模型（BCSM）中的检测点（DPs）。<Parameter List>是特定DP的函数；它包含与之相关的参数。以下要求适用：
1) The list of the DPs to be covered encompasses those defined in the IN Capability Set 3 BCSM as well as those which relate to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.
1) 要涵盖的DPs列表包括能力集3 BCSM中定义的DPs以及ITU-T中IMT 2000项目指定的无线in（WIN）相关DPs。
2) Not all parameters associated with such DPs are needed by the SPIRITS benchmark services, nor may all the parameters be needed in SPIRITS. The selection of the relevant parameters is part of the SPIRITS protocol definition.
2) SPIRITS基准测试服务并不需要与此类DPs关联的所有参数，SPIRITS中也可能不需要所有参数。相关参数的选择是协议定义的一部分。
3) It is desirable to avoid semantic overload of protocol messages. (One way to achieve that is to match each type of an event with a message that corresponds to it.) As the SPIRITS protocol is designed as a set of extensions to another (existing) protocol with the defined message set, the syntax and semantics of the extensions should be defined with this requirement in mind.
3) 人们希望避免协议消息的语义过载。（实现这一点的一种方法是将每种类型的事件与对应的消息相匹配。）由于SPIRITS协议被设计为具有已定义消息集的另一（现有）协议的一组扩展，因此应在考虑这一要求的情况下定义扩展的语法和语义。
4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) to specify the semantics of the IN Application Protocol (INAP) parameters, which are expected to be binary-encoded. Neither the use of the ASN.1, nor the requirement for binary encoding are the typical requirements for the IETF application protocols. Recognizing that, provisions must be made for careful specification of the conversion of the INAP parameters to text, which must preserve their original semantics. The actual conversion of the parameters is the function of the SPIRITS Client.
4) ITU-T建议使用抽象语法符号（ASN.1）来指定应用程序内协议（INAP）参数的语义，这些参数应为二进制编码。无论是ASN.1的使用，还是二进制编码的要求都不是IETF应用协议的典型要求。认识到这一点，必须作出规定，认真规范INAP参数到文本的转换，这必须保留其原始语义。参数的实际转换是SPIRITS客户端的功能。
In order to issue an initial query (or a notification) to service control, a switch must have such a DP set. This can be done statically via service management (this particular action should be left to implementation and thus is considered outside of the scope of SPIRITS Protocol) or dynamically--but only for the purpose of a particular call--from the service control. In the latter case, it is part of the SPIRITS (or PINT) protocol to request the event notification from the service control. The SIP specific event notification scheme [4] should be specifically considered. This function can be performed by either the Spirits Client or PINT Server, the distinction being further discussed in the next section. Assuming that it is performed by the SPIRITS Client, the relevant message should look like:
为了向服务控制发出初始查询（或通知），交换机必须设置这样的DP。这可以通过服务管理静态地完成（这个特定的操作应该留给实现，因此被认为不在SPIRITS协议的范围内），也可以通过服务控制动态地完成（但仅限于特定调用）。在后一种情况下，从服务控件请求事件通知是SPIRITS（或PINT）协议的一部分。应特别考虑SIP特定事件通知方案[4]。此功能可由Spirits客户端或PINT服务器执行，区别将在下一节中进一步讨论。假设由SPIRITS客户端执行，则相关消息应如下所示：
G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,
G->C：订阅<Event><Mode><DP特定参数>，
where <Event> refers to a particular DP; <Mode> determines whether
the Event Detection Point (EDP) is to be armed as EDP Request
(EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is
not foreseen because it would not provide any additional
capability for SPIRITS); and the <DP-specific parameters> is the
where <Event> refers to a particular DP; <Mode> determines whether
the Event Detection Point (EDP) is to be armed as EDP Request
(EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is
not foreseen because it would not provide any additional
capability for SPIRITS); and the <DP-specific parameters> is the
list of the values of the parameters associated with the EDP (for example, if the DP in question is O_No_Answer, then the value of the appropriate timer should be included in the list). Note that such a subscription may also originate at a) PINT Client or b) SPIRITS Gateway, either of which may (but does not have to) have a locally significant definition of the <Event>. In either case, it is the function of the SPIRITS Client to translate the definition of the Event into a particular DP (or set of DPs) when passing the message to Service Control. To summarize, for the case when PINT and SPIRITS events are defined in a way where they do not refer to the BCSM DPs, it is the function of the SPIRITS Client to define a mapping:
与EDP相关的参数值列表（例如，如果有问题的DP为O_No_Answer，则列表中应包括相应计时器的值）。请注意，这样的订阅也可能起源于a）PINT Client或b）SPIRITS Gateway，其中任何一个都可能（但不一定）具有<Event>的本地重要定义。在这两种情况下，当将消息传递给服务控制时，SPIRITS客户端的功能是将事件的定义转换为特定的DP（或一组DP）。总之，对于PINT和SPIRITS事件的定义方式不涉及BCSM DPs的情况，SPIRITS客户端的功能是定义映射：
Event -> DP List,
事件->DP列表，
for each event for which the PSTN notification is needed.
对于需要PSTN通知的每个事件。
The list of CS-3 DPs envisioned in SPIRITS is:
SPIRITS中设想的CS-3 DPs列表如下：
- origination_attempt_authorized (the SPIRITS service can control call attempts, (for example, to limit calls during specific time periods)
- 发起\尝试\授权（SPIRITS服务可以控制呼叫尝试（例如，限制特定时间段内的呼叫）
- collected_information and analyzed_information (for SPIRITS outgoing call screening)
- 收集的_信息和分析的_信息（用于呼出电话屏蔽）
- o_answer, o_term_seized, and t_answer (to release SPIRITS resources after the call is complete and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
- o_-answer、o_-term_-assessed和t_-answer（在通话结束后释放资源，并执行相关的OA&M操作，例如创建通过各种方式（如陆路电话、手机、短信或寻呼）联系对方的记录。）
- o_no_answer, route_select_failure, and t_no_answer (to re-route a call)
- o_no_应答、route_select_故障和t_no_应答（重新路由呼叫）
- o_called_party_busy (to re-route a call and for Internet Call Waiting)
- o_被叫方_忙（重新路由呼叫并等待Internet呼叫）
- o_mid_call and t_mid_call (to assist a midcall action)
- o_mid_call和t_mid_call（协助中间通话行动）
- o_abandon, o_disconnect, t_abandon, and t_disconnect (to terminate a SPIRITS service and release the resources and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
- o_放弃、o_断开、t_放弃和t_断开（终止SPIRITS服务并释放资源，并执行相关的OA&M操作，例如通过各种方式（如陆路电话、手机、短信或寻呼）创建试图联系一方的记录。）
In addition, the following DPs are relevant to the present SPIRITS milestone services:
此外，以下DPs与当前服务相关：
- termination_attempt_authorized
- 终止\尝试\授权
- facility_selected_and_available (could be used in SPIRITS Internet Caller-ID)
- 设施已选择且可用（可用于互联网来电显示）
- t_busy (for Internet Call Waiting and Call Forwarding).
- t_busy（用于Internet呼叫等待和呼叫转接）。
Wireless IN covers several types of "calls," which are neither circuit switched nor have an effect on circuit switched calls. For this reason, those are not considered in SPIRITS requirements. To further clarify this point, the types of "calls" not considered are:
无线IN涵盖了几种类型的“呼叫”，它们既不是电路切换的，也不会对电路切换的呼叫产生影响。出于这个原因，这些不在酒精要求中考虑。为了进一步澄清这一点，未考虑的“呼叫”类型包括：
- USSD (Unstructured Supplementary Service Data)
- USSD（非结构化补充业务数据）
- GPRS (General Packet Radio System)
- GPRS（通用分组无线系统）
- SMS (Short Message System)
- SMS（短消息系统）
The types of calls relevant to SPIRITS are as follows:
与烈酒相关的呼叫类型如下：
a) Voice Calls. In this case no new DP is needed since CAMEL DPs are included in CS2. The only special case is "Not Reachable" (when it is detected that the mobile user is out of coverage or has switched off), which is mapped as a special cause in the Busy DP. Since the Busy DP parameters would be received (if a SPIRITS service has subscribed to Busy), it would be possible to distinguish a "busy" from a "not reachable" situation.
a) 语音通话。在这种情况下，不需要新的DP，因为CAMEL DP包含在CS2中。唯一的特殊情况是“无法到达”（当检测到移动用户超出覆盖范围或已关闭时），这被映射为繁忙DP中的特殊原因。由于将接收到Busy DP参数（如果SPIRITS服务已订阅Busy），因此可以区分“Busy”和“不可到达”情况。
This translates into the requirement that one of the parameters in the Event Notification message (from SPIRITS Client to SPIRITS Gateway, over the interface C) denotes the "cause" for the Busy Detection Point.
这转化为事件通知消息（通过接口C从SPIRITS客户端到SPIRITS网关）中的一个参数表示繁忙检测点的“原因”的要求。
Another aspect of difference, when compared to PSTN, is setting of static DPs. In CAMEL networks, this is done in the Home Location Register (HLR) (and copied to the VLR during location update). It is important to note this difference, even though it has no effect on SPIRITS protocol.
与PSTN相比，差异的另一个方面是静态DPs的设置。在CAMEL网络中，这在归属位置寄存器（HLR）中完成（并在位置更新期间复制到VLR）。重要的是要注意这种差异，即使它对协议没有影响。
b) Mobility Management events. This allows a SPIRITS server to be notified of changes of location of a mobile user. The events would only be applicable to mobile users reachable through a Circuit-Switched network. To provide for this function, the subscription marks must be set in the subscriber's HLR. This is equivalent to setting TDPs in the SSP. In this case, the marks in the HLR (which are copied to the Visitor Location Register [VLR] on location update) are not mapped into Trigger Detection Points.
b) 移动性管理事件。这允许SPIRITS服务器收到移动用户位置更改的通知。这些事件只适用于通过电路交换网络可到达的移动用户。要提供此功能，必须在订阅服务器的HLR中设置订阅标记。这相当于在SSP中设置TDPs。在这种情况下，HLR中的标记（在位置更新时复制到访客位置寄存器[VLR]）不会映射到触发检测点。
As with TDP setting, this is outside of the scope of SPIRITS protocol.
与TDP设置一样，这超出了SPIRITS协议的范围。
In order to support this function in SPIRITS, the SPIRITS protocol should be able to map the CAMEL specific operations into events notification to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface. (This is just an extension of the DP notification mechanism from the SPIRITS client to the SPIRITS gateway).
为了在SPIRITS中支持此功能，SPIRITS协议应该能够将特定于骆驼的操作映射到事件通知到SPIRITS客户端。由于SCP接收关于移动性状态的信息，因此这涉及到C接口。（这只是从SPIRITS客户端到SPIRITS网关的DP通知机制的扩展）。
The events (which are not DP-related) which need notifications are:
需要通知的事件（与DP无关）包括：
- Location Update in the same VLR service area
- 同一VLR服务区中的位置更新
- Location Update in another VLR service area
- 另一个VLR服务区域中的位置更新
- IMSI attach
- IMSI附加
- MS initiated IMSI detach
- MS启动的IMSI分离
- Network initiated IMSI detach.
- 网络启动的IMSI分离。
With this mechanism, the SPIRITS services can use the user-profile-based location information. For example, the Internet Call Waiting service can re-direct the call to a mobile phone.
通过这种机制，SPIRITS服务可以使用基于用户配置文件的位置信息。例如，Internet呼叫等待服务可以将呼叫重新定向到移动电话。
c) Supplementary Services Notification.
c) 补充服务通知。
This mechanism makes a SPIRITS server aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber, or Multi-Party.
此机制使SPIRITS服务器知道某个用户调用了以下补充服务之一：显式呼叫转移、呼叫偏移、忙用户上的呼叫完成或多方。
Before a SPIRITS service can be invoked, the relevant IP Host must be registered. Thus, Registration is an essential service, which is initiated from the IP side. The registration information is ultimately used by the PSTN to authenticate the subscriber.
在调用SPIRITS服务之前，必须注册相关的IP主机。因此，注册是从IP端发起的一项基本服务。注册信息最终由PSTN用于对订户进行身份验证。
Depending on the model, this can be done in two ways with the present architecture:
根据模型的不同，在当前体系结构中，这可以通过两种方式实现：
1) The PINT Client issues the appropriate Register message over the interface A, which is then passed by the PINT server to the SPIRITS Gateway and SPIRITS Client:
1) PINT客户端通过接口A发出适当的注册消息，然后PINT服务器将该消息传递给SPIRITS网关和SPIRITS客户端：
PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS C.]. In this case the SPIRITS Client (co-located with the service control) is responsible for record keeping and the authentication.
品脱C.：--寄存器-->品脱S.[-->酒精网关-->酒精C.]。在这种情况下，SPIRITS客户端（与服务控制位于同一位置）负责记录保存和身份验证。
2) The PINT Client issues the appropriate Register message to the PINT Server, which then passes this information to the PSTN service control "by magic".
2) PINT客户端向PINT服务器发出适当的注册消息，然后PINT服务器“通过魔术”将此信息传递给PSTN服务控制。
The second model is much easier to handle, because it involves only one relevant interface ("A"); however it assumes no interworking between PINT and SPIRITS except that the SPIRITS Client finds "by magic" that a friendly and expecting IP Host is alive and well.
第二个模型更容易处理，因为它只涉及一个相关接口（“A”）；然而，它假设品脱和烈酒之间没有互通，除了烈酒客户端“神奇地”发现一个友好且期望的IP主机仍然存在。
Finally, in the event PINT is not implemented, the SIP SUBSCRIBE mechanism can be used.
最后，如果没有实现PINT，则可以使用SIP订阅机制。
As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT building blocks [3] must be extended for their use in SPIRITS for the purposes of setting DPs/getting DP event notifications. (A more general SIP mechanism for the same PINT-introduced block is described in [4]; it provides the necessary mechanism for specifying relevant events.) Conversely, the same building blocks for the functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP).
如前一节所述，必须扩展现有SUBSCRIBE/NOTIFY PINT构建块[3]，以便在Spirit中使用，以设置DPs/获取DP事件通知。（在[4]中描述了相同PINT引入块的更通用SIP机制；它提供了指定相关事件的必要机制。）相反，功能功能的相同构建块可用于PINT和SPIRITS协议。然而，请注意，PSTN通知可能在没有特定事件订阅的情况下到达（在静态设置DP的情况下）。
The requirements of this section are neither PINT-specific, nor IN-specific; their role is to outline the remaining element necessary for the delivery of the SPIRITS service, which is the reaction to the notification received.
本节的要求既不具体，也不具体；他们的职责是概述提供SPIRITS服务所需的其余要素，即对收到的通知的反应。
In a particular scenario where:
在以下特定场景中：
a) The IP subscriber registers a SPIRITS service;
a) IP订户注册服务；
b) A call triggering the SPIRITS service is received (and notification is sent); and
b) 接收到触发SPIRITS服务的呼叫（并发送通知）；和
c) The call disposition is performed by the end user, the signalling flow is demonstrated in Figure 2.
c) 呼叫处理由最终用户执行，信令流程如图2所示。
|----> Registration ----->|
SPIRITS |<-- Event Notification <-- | SPIRITS
Gateway |---> Call Disposition ---->| Client
| |
|
|
|
V
Service Control
|
|
V
SSP
|----> Registration ----->|
SPIRITS |<-- Event Notification <-- | SPIRITS
Gateway |---> Call Disposition ---->| Client
| |
|
|
|
V
Service Control
|
|
V
SSP
Figure 2: Sequence of SPIRITS actions
图2：操作的顺序
One of the following actions is required by benchmark services:
基准测试服务需要执行以下操作之一：
a) Accept the incoming call
a) 接听来电
b) Reject the incoming call
b) 拒绝来电
c) Redirect the incoming call
c) 重定向来电
d) Accept the call via VoIP (this particular item is outside of the scope of SPIRITS WG).
d) 通过VoIP接受呼叫（此特定项目不在工作组的范围内）。
Accordingly, the SPIRITS protocol should define the following message types:
因此，SPIRITS协议应定义以下消息类型：
a) S->G: <Accept Call>
a) S->G: <Accept Call>
b) S->G: <[Reject Call],[Cause]>
b) S->G: <[Reject Call],[Cause]>
c) S->G: <[Redirect Call],[Redirection Destination]>
c) S->G: <[Redirect Call],[Redirection Destination]>
To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set of messages), the PSTN events associated with each detection point of the Basic Call State Model should be examined. To date, the CS-3 BSCM has the richest set of DPs, although not all switching exchanges have implemented it.
为了确定最小协议词汇表（即消息集），应检查与基本呼叫状态模型的每个检测点相关联的PSTN事件。迄今为止，CS-3 BSCM拥有最丰富的DPs集，尽管并非所有交换交换机都实现了它。
To determine the MINIMUM information available to the SPIRITS client (this information is to be carried by the SPIRITS protocol from SPIRITS client to SPIRITS server), each DP-specific information elements needs to be examined.
为了确定SPIRITS客户端可用的最小信息（该信息由SPIRITS协议从SPIRITS客户端传送到SPIRITS服务器），需要检查每个DP特定信息元素。
Parameters should be event-specific, the following generic types of parameters are expected to be mandatory:
参数应是特定于事件的，以下通用类型的参数应为强制性参数：
- timer (for no answer)
- 计时器（用于无应答）
- midcall control info (for mid_call)
- 通话中控制信息（用于通话中）
- number of digits (for collected_information)
- 位数（用于收集的信息）
Overall, the basic aspects of security apply to SPIRITS protocol:
总的来说，安全性的基本方面适用于SPIRITS协议：
- Authentication: In the communications between the SPIRITS Client and SPIRITS Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is required that the information be sent between known and trusted partners.
- 身份验证：在SPIRITS客户端和SPIRITS网关以及SPIRITS网关和SPIRITS服务器之间的通信中，要求在已知和受信任的合作伙伴之间发送信息。
- Integrity: It is a requirement that no exchanged data be modified in transit.
- 完整性：要求在传输过程中不修改交换的数据。
- Confidentiality: It is a requirement that any private user information or confidential network data be protected by the protocol (typically through encryption, for which the protocol should allow a choice in the algorithm selection.
- 机密性：要求任何私人用户信息或机密网络数据受协议保护（通常通过加密，协议应允许在算法选择中进行选择）。
- Availability: It is a requirement that the communicating endpoints remain in service for authorized use only.
- 可用性：要求通信端点保持服务状态，仅用于授权使用。
In addition, the protocol should support non-repudiation for those control messages pertinent to charging the PSTN subscriber.
此外，该协议应支持与向PSTN用户收费相关的控制消息的不可否认性。
As Figure 1 demonstrates, there are two distinct communications interfaces, B and C. The B interface is, in general, across the public Internet and is thus most vulnerable to security attacks resulting in theft or denial of service. The C interface, on the other hand is likely to be implemented across a service providers intranet, where the security measures should be applied at the discretion of the service provider. Even then, because at least one IP host (the PINT gateway) is connected to the Internet, special measures (e.g., installation of firewalls, although this particular measure alone may be insufficient) need to be taken to protect the interface C and the rest of the network from security attacks.
如图1所示，有两个不同的通信接口，B和C。通常，B接口跨越公共互联网，因此最容易受到导致盗窃或拒绝服务的安全攻击。另一方面，C接口可能在服务提供商内部网中实现，安全措施应由服务提供商自行决定。即使如此，由于至少有一个IP主机（PINT网关）连接到Internet，因此需要采取特殊措施（例如安装防火墙，尽管仅此特定措施可能不够）来保护接口C和网络的其余部分免受安全攻击。
The assumption that the PINT Client and SPIRITS server are co-located, dictates that the security considerations for the A and B interfaces are exactly same. Detailed security requirements and solutions for interface A (and, consequently, B) can be found in RFC 2848 [3].
PINT客户端和SPIRITS服务器位于同一位置的假设表明，A和B接口的安全考虑因素完全相同。接口A（以及因此而产生的接口B）的详细安全要求和解决方案可在RFC 2848[3]中找到。
Possible security attacks can result in both theft and denial of services. In addition, such attacks may violate the privacy of a PSTN subscriber. For example, with Internet Call Waiting, a fraudulent registration (or a manipulation of integrity of a valid registration) may force a network operator to provide to an authorized party a full log of attempted telephone calls (accompanied by the identification of callers). Furthermore, the calls may be diverted to wrong recipients (who may further defraud the unsuspecting calling party). In this case, the calling party is using only the PSTN and thus expecting the security of communications that are typical of the PSTN. The PSTN service providers may be liable for the consequences of establishing wrong connections. In addition, the PSTN service providers may be liable for inadvertent divulging of the private information of the subscriber.
可能的安全攻击会导致盗窃和拒绝服务。此外，此类攻击可能侵犯PSTN用户的隐私。例如，在互联网呼叫等待的情况下，欺诈性注册（或操纵有效注册的完整性）可能会迫使网络运营商向授权方提供尝试的电话呼叫的完整日志（附带呼叫者身份）。此外，呼叫可能被转移到错误的接收者（这些接收者可能进一步欺骗毫无戒心的呼叫方）。在这种情况下，呼叫方仅使用PSTN，因此期望PSTN典型的通信安全。PSTN服务提供商可能对建立错误连接的后果负责。此外，PSTN服务提供商可能对用户的私人信息的无意泄露负责。
The service and network providers need to review the possibilities of the security attacks and prepare the means of protection from them. Some of this may be achieved by using the means outside of those provided by the protocol itself. For example, administrative information (such as statistics collected by PINT MIB or SPIRITS MIB) can help in determining violations and thwarting them. As far as the protocol is concerned, it must provide the means for authenticating a subscriber as well as a session. It must also provide a capability to carry encrypted information in its body.
服务和网络提供商需要审查安全攻击的可能性，并准备防范安全攻击的方法。其中一些可以通过使用协议本身提供的手段之外的手段来实现。例如，管理信息（如PINT MIB或SPIRITS MIB收集的统计数据）有助于确定违规行为并阻止违规行为。就协议而言，它必须提供认证订户和会话的方法。它还必须提供在体内携带加密信息的能力。
The authors are grateful to all participants in the SPIRITS group for the discussion that has been shaping this work. Many thanks go to Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren Nyckelgard, and John Voelker for their incisive comments. Special thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose careful, detailed reviews of several versions of this document have been particularly helpful in improving its quality.
作者非常感谢SPIRITS小组的所有参与者，感谢他们对这部作品的讨论。非常感谢Jorgen Bjorkner、Alec Brusilovsky、Jim Buller、Lawrence Conroy、Soren Nyckelgard和John Voelker的精辟评论。特别感谢Vijay Gurbani、Dave Hewins和Kumar Vemuri，他们对本文档的几个版本进行了仔细、详细的审查，这对提高其质量特别有帮助。
[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] Lu, H. (Editor), 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.
[2] 卢，H.（编辑），费恩伯格，I.，沃克尔，J.，魏斯曼，M.，张，W.，Rhim，S.，黄，J.，Ago，S.，Moeenddin，S.，Hadvani，S.，Nyckelgard，S.，Yoakum，J.和L.Robart，“PSTN启动服务的前精神实现”，RFC 29952000年11月。
[3] 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.
[3] Petrack，S.和L.Conroy，“PINT服务协议：电话呼叫服务IP接入的SIP和SDP扩展”，RFC 28482000年6月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[7] Handley，M.，Schooler，E.，Schulzrinne，H.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[8] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley，M.和V.Jacobsen，“SDP：会话描述协议”，RFC 2327，1998年4月。
Lev Slutsman AT&T Laboratories 200 Laurel Ave. Middletown, New Jersey, 07748
Lev Slutsman AT&T实验室，新泽西州米德尔顿劳雷尔大道200号，邮编：07748
Phone: (732) 420-3752 EMail: lslutsman@att.com
电话：（732）420-3752电子邮件：lslutsman@att.com
Igor Faynberg Bell Labs/Lucent Technologies Room 4D-601A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
Igor Faynberg Bell实验室/朗讯科技4D-601A室，新泽西州霍姆德尔克劳福德角路101号，邮编：07733
Phone: (732) 949-0137 EMail: faynberg@lucent.com
电话：（732）949-0137电子邮件：faynberg@lucent.com
Jorge Gato Vodaphone Avda de Europa, 1. 28108 Alcobendas (Madrid). Spain
豪尔赫·加托·沃达丰·阿夫达·德·欧罗巴，1。28108 Alcobendas（马德里）。西班牙
Phone: +34 607 13 31 10
Fax: +34 607 13 30 57
EMail: jgato@airtel.es
Phone: +34 607 13 31 10
Fax: +34 607 13 30 57
EMail: jgato@airtel.es
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
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。