Network Working Group V. K. Gurbani
Request for Comments: 3976 Lucent Technologies, Inc.
Category: Informational F. Haerens
Alcatel Bell
V. Rastogi
Wipro Technologies
January 2005
Network Working Group V. K. Gurbani
Request for Comments: 3976 Lucent Technologies, Inc.
Category: Informational F. Haerens
Alcatel Bell
V. Rastogi
Wipro Technologies
January 2005
Interworking SIP and Intelligent Network (IN) Applications
互通SIP和智能网（IN）应用
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 (2005).
版权所有（C）互联网协会（2005年）。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，并特别指出，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Abstract
摘要
Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP).
公共交换电话网（PSTN）服务，如800号码路由（免费电话）、时间和日路由、信用卡呼叫和虚拟专用网（将专用网络号码映射为公用号码）由智能网（IN）实现。本文档介绍了支持IP主机到电话呼叫的会话启动协议（SIP）端点的现有IN服务的方法。呼叫请求在SIP端点上发起，但呼叫服务由驻留在PSTN/in中的数据和过程提供。为了以透明的方式向SIP端点提供IN服务，本文档描述了SIP和智能网络应用程序部分（INAP）互通的机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4
3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7
3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7
3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7
3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8
3.4. Support of Announcements and Mid-Call Signaling. . . . . 8
4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IN Service Control Based on the SIN Approach . . . . . . 9
5. Mapping of the SIP State Machine to the IN State Model . . . . 10
5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11
5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16
6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4
3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7
3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7
3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7
3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8
3.4. Support of Announcements and Mid-Call Signaling. . . . . 8
4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IN Service Control Based on the SIN Approach . . . . . . 9
5. Mapping of the SIP State Machine to the IN State Model . . . . 10
5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11
5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16
6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
PSTN services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network. IN is an architectural concept for the real-time execution of network services and customer applications [1]. IN is, by design, de-coupled from the call processing component of the PSTN. In this document, we describe the means to leverage this decoupling to provide IN services from SIP-based entities.
PSTN业务，如800号码路由（免费电话）、时间和日期路由、信用卡呼叫和虚拟专用网（将专用网络号码映射为公用号码）由智能网实现。IN是一种用于实时执行网络服务和客户应用程序的体系结构概念[1]。在本发明中，通过设计，从PSTN的呼叫处理组件分离耦合。在本文档中，我们描述了利用这种解耦从基于SIP的实体提供In服务的方法。
First, we will explain the basics of IN. Figure 1 shows a simplified IN architecture, in which telephone switches called Service Switching Points (SSPs) are connected via a packet network called Signaling System No. 7 (SS7) to Service Control Points (SCPs), which are general purpose computers. At certain points in a call, a switch can interrupt a call and request instructions from an SCP on how to proceed with the call. The points at which a call can be interrupted are standardized within the Basic Call State Model (BCSM) [1, 2]. The BCSM models contain two processes, one each for the originating and terminating part of a call.
首先，我们将解释中的基本知识。图1显示了一个简化的IN架构，其中称为服务交换点（SSP）的电话交换机通过称为信令系统7号（SS7）的分组网络连接到服务控制点（SCP），后者是通用计算机。在呼叫的某些点，交换机可以中断呼叫，并请求SCP指示如何继续呼叫。呼叫可以中断的点在基本呼叫状态模型（BCSM）[1,2]中标准化。BCSM模型包含两个进程，分别用于呼叫的发起和终止部分。
When the SCP receives a request for instructions, it can reply with a single response, such as a simple number translation augmented by criteria like time of day or day of week, or, in turn, initiate a complex dialog with the switch. The situation is further complicated by the necessity to engage other specialized devices that collect digits, play recorded announcements, perform text-to-speech or speech-to-text conversions, etc. (These devices are not discussed here.) The related protocol, as well as the BCSM, is standardized by the ITU-T and known as the Intelligent Network Application Part protocol (INAP) [4]. Only the protocol, not an SCP API, has been standardized.
当SCP收到指令请求时，它可以用单个响应进行响应，例如简单的数字翻译，并通过诸如时间或星期几之类的标准进行扩充，或者反过来，启动与交换机的复杂对话。由于需要使用其他专门设备收集数字、播放录制的公告、执行文本到语音或语音到文本转换等（此处不讨论这些设备），相关协议以及BCSM，由ITU-T标准化，称为智能网络应用部分协议（INAP）[4]。只有协议，而不是SCP API已经标准化。
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
Figure 1. Simplified IN Architecture
图1。建筑上的简化
The overall objective is to ensure that IN control of Voice over IP (VoIP) services in networks can be readily specified and implemented by adapting standards and software used in the present networks. This approach leads to services that function the same when a user connects to present or future networks, simplifies service evolution from present to future, and leads to more rapid implementation.
总的目标是通过调整现有网络中使用的标准和软件，确保网络中的IP语音（VoIP）服务可以容易地指定和实现。当用户连接到当前或未来的网络时，这种方法会产生功能相同的服务，简化从当前到未来的服务演变，并导致更快速的实现。
The rest of this document is organized as follows: Section 2 contains the architectural model of an IN aware SIP entity. Section 3 provides some issues to be taken into account when performing SIP/IN interworking (SIN). Section 4 discusses the IN service control based on the SIN approach. The technique outlined in this document focuses on the call models of IN and the SIP protocol state machine; Section 5 thus establishes a complete mapping between the two state machines that allows access to IN services from SIP endpoints. Section 6 includes call flows of IN services executing on SIP endpoints. These services are readily enabled by the technique described in this document. Finally, Section 7 covers security aspects of SIN.
本文档的其余部分组织如下：第2节包含了感知内SIP实体的体系结构模型。第3节提供了在执行SIP/IN互通（SIN）时需要考虑的一些问题。第4节讨论了基于SIN方法的在役控制。本文概述的技术重点是in和SIP协议状态机的调用模型；因此，第5节在两个状态机之间建立了一个完整的映射，允许从SIP端点访问IN服务。第6节包括在SIP端点上执行的IN服务的调用流。这些服务可通过本文档中描述的技术轻松启用。最后，第7节介绍了SIN的安全方面。
List of Acronyms
缩略词清单
B2BUA Back-to-Back User Agent BCSM Basic Call State Model CCF Call Control Function DP Detection Point DTMF Dual Tone Multi-Frequency IN Intelligent Network INAP Intelligent Network Application Part IP Internet Protocol ITU-T International Telecommunications Union - Telecommunications Standardization Sector O_BCSM Originating Basic Call State Model PIC Point in Call PSTN Public Switched Telephone Network RTP Real Time Protocol R-URI Request URI SCF Service Control Function SCP Service Control Point SIGTRAN Signal Transport Working Group in IETF SIN SIP/IN Interworking SIP Session Initiation Protocol SS7 Signaling System No. 7 SSF Service Switching Function SSP Service Switching Point T_BCSM Terminating Basic Call State Model UA User Agent UAC User Agent Client UAS User Agent Server VoIP Voice over IP VPN Virtual Private Network
B2BUA背对背用户代理BCSM基本呼叫状态模型CCF呼叫控制功能DP检测点DTMF双音多频智能网INAP智能网应用部分IP互联网协议ITU-T国际电信联盟-电信标准化部门O_BCSM原始基本呼叫状态PIC型呼叫中点PSTN公共交换电话网RTP实时协议R-URI请求URI SCF服务控制功能SCP服务控制点SIGTRAN信号传输工作组IETF SIN SIP/in互通SIP会话发起协议SS7信令系统第7号SSF服务交换功能SSP服务交换点T_BCSM终止基本呼叫状态模型UA用户代理UAC用户代理客户端UAS用户代理服务器VoIP IP语音VPN虚拟专用网
The intent of this document is to provide the means to support existing IN-based applications in a SIP [3] environment. One way to gain access to IN services transparently from SIP (e.g., through the same detection points (DPs) and point-in-call (PIC) used by traditional switches) is to map the SIP protocol state machine to the IN call models [1].
本文档旨在提供支持SIP[3]环境中现有基于IN的应用程序的方法。从SIP（例如，通过传统交换机使用的相同检测点（DPs）和接入点（PIC））透明地访问接入服务的一种方法是将SIP协议状态机映射到接入模型[1]。
From the viewpoint of IN elements such as the SCP, the request's origin from a SIP entity rather than a call processing function on a traditional switch is immaterial. Thus, it is important that the SIP entity be able to provide the same features as the traditional switch, including operating as an SSP for IN features. The SIP entity should also maintain call state and trigger queries to IN-based services, as do traditional switches.
从诸如SCP之类的IN元素的观点来看，来自SIP实体而不是传统交换机上的呼叫处理功能的请求来源无关紧要。因此，SIP实体必须能够提供与传统交换机相同的功能，包括作为SSP操作IN功能。SIP实体还应该像传统交换机一样，维护呼叫状态并触发对基于IN的服务的查询。
This document does not intend to specify which SIP entity shall operate as an SSP; however, for the sake of completeness, it should be mentioned that this task should be performed by SIP entities at (or near) the core of the network rather than at the SIP end points themselves. To that extent, SIP entities such as proxy servers and Back-to-Back user agents (B2BUAs) may be employed. Generally speaking, proxy servers can be used for IN services that occur during a call setup and teardown. For IN services requiring specialized media handling (such as DTMF detection) or specialized call control (such as placing parties on hold) B2BUAs will be required.
本文件不打算指定哪个SIP实体应作为SSP运营；然而，为了完整性起见，应该提到的是，该任务应由网络核心（或附近）的SIP实体执行，而不是由SIP端点本身执行。在该程度上，可以采用诸如代理服务器和背靠背用户代理（b2bua）之类的SIP实体。一般来说，代理服务器可用于在呼叫设置和拆卸过程中发生的IN服务。对于需要专用媒体处理（如DTMF检测）或专用呼叫控制（如将各方置于等待状态）的IN服务，将需要B2BUA。
The most expeditious manner for providing existing IN services in the IP domain is to use the deployed IN infrastructure as often as possible. In SIP, the logical point to tap into for accessing existing IN services is either the user agents or one of the proxies physically closest to the user agent (and presumably in the same administrative domain). However, SIP entities do not run an IN call model; to access IN services transparently, the trick then is to overlay the state machine of the SIP entity with an IN layer so that call acceptance and routing is performed by the native state machine and so that services are accessed through the IN layer by using an IN call model. Such an IN-enabled SIP entity, operating in synchrony with the events occurring at the SIP transaction level and interacting with the IN elements (SCP), is depicted in Figure 2:
在IP域中提供现有IN服务的最快捷方式是尽可能经常地使用部署的IN基础设施。在SIP中，用于访问现有In服务的逻辑点是用户代理或物理上最接近用户代理的代理之一（可能在同一管理域中）。但是，SIP实体不运行内部调用模型；为了透明地访问IN服务，诀窍是用IN层覆盖SIP实体的状态机，以便由本机状态机执行呼叫接受和路由，并且通过使用IN呼叫模型通过IN层访问服务。图2描述了这样一个支持IN的SIP实体，它与SIP事务级别上发生的事件同步运行，并与IN元素（SCP）交互：
+-------+
| SCP |
+---+---+
|
| INAP
|
+--------+
| SIN |
+........+
| SIP |
---------->| Entity |--------->
Requests | | Requests out
in +--------+ (after applying IN
services)
+-------+
| SCP |
+---+---+
|
| INAP
|
+--------+
| SIN |
+........+
| SIP |
---------->| Entity |--------->
Requests | | Requests out
in +--------+ (after applying IN
services)
SIN: SIP/IN Interworking layer
SIN:SIP/IN互通层
Figure 2. SIP Entity Accessing IN Services
图2。服务中的SIP实体访问
Section 5 proposes this mapping between the IN layer and the SIP protocol state machine. Essentially, a SIP entity exhibiting this mapping becomes a SIN-enabled SIP entity.
第5节提出了IN层和SIP协议状态机之间的映射。本质上，显示此映射的SIP实体成为启用SIN的SIP实体。
This document does not propose any extensions to SIP.
本文件不建议对SIP进行任何扩展。
Figure 3 expands the SIP entity depicted in Figure 2 and further details the architecture model involving IN and SIP interworking. Events occurring at the SIP layer will be passed to the IN layer for service application. More specifically, since IN services deal with E.164 numbers, it is reasonable to assume that a SIN-enabled SIP entity that seeks to provide services on such a number will consult the IN layer for further processing, thus acting as a SIP-based SSP. The IN layer will proceed through its BCSM states and, at appropriate points in the call, will send queries to the SCP for call disposition. Once the disposition of the call has been determined, the SIP layer is informed and processes the transaction accordingly.
图3扩展了图2中所示的SIP实体，并进一步详细说明了涉及in和SIP互通的体系结构模型。在SIP层发生的事件将被传递到服务应用程序的IN层。更具体地说，由于IN-services处理E.164号码，因此可以合理地假设，寻求在该号码上提供服务的启用SIN的SIP实体将咨询IN层以进行进一步处理，从而充当基于SIP的SSP。IN层将继续执行其BCSM状态，并在调用的适当点向SCP发送查询以进行调用处理。一旦确定了呼叫的处理，SIP层将被通知并相应地处理事务。
Note that the single SIP entity as modeled in this figure can in fact represent several different physical instances in the network as, for example, when one SIP entity is in charge of the terminal or access network/domain, and another is in charge of the interface to the Switched Circuit Network (SCN).
注意，该图中建模的单个SIP实体实际上可以表示网络中的多个不同物理实例，例如，当一个SIP实体负责终端或接入网络/域，而另一个SIP实体负责到交换电路网络（SCN）的接口时。
+-------+
| SCP |
+---o---+
|
+-----+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | SIN-enabled *
* +-------o-------------------+ SIP *
* | SIP Layer | Entity *
* +---------------------------+ *
**********************************************
+-------+
| SCP |
+---o---+
|
+-----+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | SIN-enabled *
* +-------o-------------------+ SIP *
* | SIP Layer | Entity *
* +---------------------------+ *
**********************************************
Figure 3. Functional Architecture of a SIN-Enabled SIP Entity
图3。启用SIN的SIP实体的功能体系结构
The following architecture entities, used in Figure 3, are defined in the Intelligent Network standards:
图3中使用的以下体系结构实体在智能网络标准中定义：
Service Switching Function (SSF): IN functional entity that interacts with call control functions.
服务交换功能（SSF）：在与呼叫控制功能交互的功能实体中。
Call Control Function (CCF): IN functional entity that refers to call and connection handling in the classical sense (i.e., that of an exchange).
呼叫控制功能（CCF）：在功能实体中，指的是经典意义上的呼叫和连接处理（即交换）。
In working between Internet Telephony and IN-PSTN networks, the main issue is to translate between the states produced by the Internet Telephony signaling and those used in traditional IN environments. Such a translation entails attention to the considerations listed below.
在Internet电话和In-PSTN网络之间工作时，主要问题是在Internet电话信令产生的状态和传统In环境中使用的状态之间进行转换。这种翻译需要注意下面列出的注意事项。
IN services occur within the context of a call, i.e., during call setup, call teardown, or in the middle of a call. SIP entities such as proxies, with which some of these services may be realized, typically run in transaction-stateful (or stateless) mode. In this mode, a SIP proxy that proxied the initial INVITE is not guaranteed to receive a subsequent request, such as a BYE. Fortunately, SIP has primitives to force proxies to run in a call-stateful mode; namely, the Record-Route header. This header forces the user agent client (UAC) and user agent server (UAS) to create a "route set" that consists of all intervening proxies through which subsequent requests must traverse. Thus SIP proxies must run in call-stateful mode in order to provide IN services on behalf of the UAs.
在服务中发生在呼叫的上下文中，即在呼叫建立期间、呼叫拆开期间或呼叫中间。SIP实体（如代理）通常以事务状态（或无状态）模式运行，其中一些服务可以通过代理实现。在此模式下，代理初始邀请的SIP代理不保证接收后续请求，例如BYE。幸运的是，SIP有原语来强制代理以调用状态模式运行；即，记录路由头。此标头强制用户代理客户端（UAC）和用户代理服务器（UAS）创建“路由集”，该路由集由后续请求必须通过的所有中间代理组成。因此，为了代表UAs提供in服务，SIP代理必须以呼叫状态模式运行。
A B2BUA is another SIP element in which IN services can be realized. As a B2BUA is a true SIP UA, it maintains complete call state and is thus capable of providing IN services.
B2BUA是可以实现in服务的另一个SIP元素。由于B2BUA是真正的SIP UA，它保持完整的呼叫状态，因此能够提供IN服务。
In the architecture model proposed in this document, each SIN-enabled SIP entity is pre-configured to communicate with one logical SCP server, using whatever communication mechanism is appropriate. Different SIP servers (e.g., those in different administrative domains) may communicate with different SCP servers, so that there is no single SCP server responsible for all SIP servers.
在本文提出的体系结构模型中，每个启用SIN的SIP实体都预先配置为使用任何适当的通信机制与一个逻辑SCP服务器通信。不同的SIP服务器（例如，位于不同管理域中的服务器）可以与不同的SCP服务器通信，因此没有单个SCP服务器负责所有SIP服务器。
As Figures 1 and 2 depict, the IN-portion of the SIN-enabled SIP entity will communicate with the SCP. This interface between the IN call handling layer and the SCP is not specified by this document and, indeed, can be any one of the following, depending on the interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, or INAP over SS7.
如图1和图2所示，启用SIN的SIP实体的IN部分将与SCP通信。本文档未指定IN-call handling layer和SCP之间的接口，事实上，根据SCP支持的接口，该接口可以是以下任一接口：IP上的INAP、SIGTRAN上的INAP或SS7上的INAP。
This document is only applicable when SIP-controlled Internet telephony devices seek to operate with PSTN devices. The SIP UAs using this interface would typically appear together with a media gateway. This document is *not* applicable in an all-IP network and is not needed in cases where PSTN media gateways (not speaking SIP) need to communicate with SCPs.
本文件仅适用于SIP控制的互联网电话设备寻求与PSTN设备一起运行的情况。使用此接口的SIP UAs通常与媒体网关一起出现。本文件*不*适用于全IP网络，在PSTN媒体网关（不说SIP）需要与SCP通信的情况下不需要本文件。
SIP REGISTER provisions a SIP Proxy or SIP Registration server. The process is similar to the provisioning of an SCP/HLR in the switched circuit network. SCPs that provide VoIP based services can leverage this information directly. However, this document neither endorses nor prohibits such an architecture and, in fact, considers it an implementation decision.
SIP注册提供SIP代理或SIP注册服务器。该过程类似于在交换电路网络中提供SCP/HLR。提供基于VoIP的服务的SCP可以直接利用这些信息。然而，本文件既不认可也不禁止这种架构，事实上，它将其视为一项实施决策。
Services in the IN such as credit-card calling typically play announcements and collect digits from the caller before a call is set up. Playing announcements and collecting digits require the manipulation of media streams. In SIP, proxies do not have access to the media data path. Thus, such services should be executed in a B2BUA.
in中的服务（如信用卡呼叫）通常播放通知，并在建立呼叫之前从呼叫方收集数字。播放公告和收集数字需要操纵媒体流。在SIP中，代理无法访问媒体数据路径。因此，此类服务应在B2BUA中执行。
Although the SIP specification [3] allows for end points to be put on hold during a call or for a change of media streams to take place, it does not have any primitives to transport other than mid-call control information. This may include transporting DTMF digits, for example. Extensions to SIP, such as the INFO method [5] or the SIP event notification extension [6], can be considered for services requiring mid-call signaling. Alternatively, DTMF can be transported in RTP itself [7].
尽管SIP规范[3]允许在呼叫期间暂停端点，或者允许媒体流发生变化，但除了呼叫中控制信息之外，它没有任何原语来传输。例如，这可能包括传输DTMF数字。对于需要中间呼叫信令的服务，可以考虑SIP的扩展，例如INFO方法[5]或SIP事件通知扩展[6]。或者，DTMF可以在RTP本身中传输[7]。
The SIP architecture has the following functional elements defined in [3]:
SIP体系结构具有[3]中定义的以下功能元素：
- User agent client (UAC): The SIP functional entity that initiates a request.
- 用户代理客户端（UAC）：发起请求的SIP功能实体。
- User agent server (UAS): The SIP functional entity that terminates a request by sending 0 or more provisional SIP responses and one final SIP response.
- 用户代理服务器（UAS）：通过发送0个或多个临时SIP响应和一个最终SIP响应来终止请求的SIP功能实体。
- Proxy server: An intermediary SIP entity that can act as both a UAS and a UAC. Acting as a UAS, it accepts requests from UACs, rewrites the Request-URI (R-URI), and, acting as a UAC, proxies the request to a downstream UAS. Proxies may retain significant call control state by inserting themselves in future SIP transactions beyond the initial INVITE.
- 代理服务器：一个中间SIP实体，可以同时充当UAS和UAC。作为UAS，它接受来自UAC的请求，重写请求URI（R-URI），并作为UAC将请求代理给下游UAS。代理可以通过在初始INVITE之外的未来SIP事务中插入自身来保持重要的呼叫控制状态。
- Redirect server: An intermediary SIP entity that redirects callers to alternate locations, after possibly consulting a location server to determine the exact location of the callee (as specified in the R-URI).
- 重定向服务器：一个中间SIP实体，在可能咨询位置服务器以确定被叫方的确切位置（如R-URI中所指定）后，将被叫方重定向到备用位置。
- Registrar: A SIP entity that accepts SIP REGISTER requests and maintains a binding from a high-level URL to the exact location for a user. This information is saved in some data-store that is also accessible to a SIP Proxy and a SIP Redirect server. A Registrar is usually co-located with a SIP Proxy or a SIP Redirect server.
- 注册器：接受SIP注册请求并维护从高级URL到用户确切位置的绑定的SIP实体。此信息保存在一些数据存储中，SIP代理和SIP重定向服务器也可以访问这些数据存储。注册器通常与SIP代理或SIP重定向服务器位于同一位置。
- Outbound proxy: A SIP proxy located near the originator of requests. It receives all outgoing requests from a particular UAC, including those requests whose R-URIs identify a host other than the outbound proxy. The outbound proxy sends these requests, after any local processing, to the address indicated in the R-URI.
- 出站代理：位于请求发起方附近的SIP代理。它接收来自特定UAC的所有传出请求，包括其R-URI识别出站代理以外的主机的请求。出站代理在任何本地处理之后将这些请求发送到R-URI中指示的地址。
- Back-to-Back UA (B2BUA): A SIP entity that receives a request and processes it as a UAS. It also acts as a UAC and generates requests to determine how the incoming request is to be answered. A B2BUA maintains complete dialog state and must participate in all requests sent within the dialog.
- 背对背UA（B2BUA）：接收请求并将其作为UAS处理的SIP实体。它还充当UAC并生成请求，以确定如何响应传入请求。B2BUA保持完整的对话框状态，并且必须参与对话框内发送的所有请求。
Figure 4 depicts the possibility of IN service control based on the SIN approach. On both the originating and terminating ends, a SIN-capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O SIP" entity is required for outgoing calls that require support for existing IN services. Likewise, on the callee's side (or terminating side), an equally configured entity ("T SIP") will be required to provide terminating side services. Note that the "O SIP" and "T SIP" entities correspond, respectively, to the IN O_BCSM and T_BCSM halves of the IN call model.
图4描述了基于SIN方法的服务中控制的可能性。在始发端和终止端上，假定具有SIN能力的SIP实体（它可以是代理或B2BUA）。对于需要支持现有IN服务的传出呼叫，需要“O SIP”实体。同样，在被叫方一侧（或终端侧），将需要一个同等配置的实体（“tsip”）来提供终端侧服务。注意，“O SIP”和“T SIP”实体分别对应于IN-call模型的IN-O_-BCSM和T_-BCSM部分。
+---+ +---+
| S | (~~~~~~~~~~~~~) | S |
| C |<--+ ( ) +-->| C |
| P | | ( ) | | P |
+---+ | ( Switched ) | +---+
| ( Circuit ) |
V ( Network ) V
+-------+ ( ) +-------+
| SIN | +---------+ +---------+ | SIN |
+-------+----| Gateway | ... | Gateway |------+-------+
| O SIP | +---------+ +---------+ | T SIP |
+-------+ ( ) +-------+
( )
(.............)
+---+ +---+
| S | (~~~~~~~~~~~~~) | S |
| C |<--+ ( ) +-->| C |
| P | | ( ) | | P |
+---+ | ( Switched ) | +---+
| ( Circuit ) |
V ( Network ) V
+-------+ ( ) +-------+
| SIN | +---------+ +---------+ | SIN |
+-------+----| Gateway | ... | Gateway |------+-------+
| O SIP | +---------+ +---------+ | T SIP |
+-------+ ( ) +-------+
( )
(.............)
O SIP: Originating SIP entity T SIP: Terminating SIP entity
O SIP:发起SIP实体T SIP:终止SIP实体
Figure 4. Overall SIN Architecture
图4。整体SIN架构
This section establishes the mapping of the SIP protocol state machine to the IN generic basic call state model (BCSM) [2], independent of any capability sets [8, 9]. The BCSM is divided into two halves: an originating call model (O_BCSM) and a terminating call model (T_BCSM). There are a total of 19 PICs and 35 DPs between both the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for T_BCSM) [1]. The SSPs, SCPs, and other IN elements track a call's progress in terms of the basic call model. The basic call model provides a common context for communication about a call.
本节建立SIP协议状态机到通用基本呼叫状态模型（BCSM）[2]的映射，独立于任何功能集[8,9]。BCSM分为两部分：发起呼叫模型（O_BCSM）和终止呼叫模型（T_BCSM）。两半之间总共有19个图片和35个DPs（O_BCSM为11个图片和21个DPs；T_BCSM为8个图片和14个DPs）[1]。SSP、SCP和其他IN元素根据基本呼叫模型跟踪呼叫的进度。基本调用模型为有关调用的通信提供了公共上下文。
O_BCSM has 11 PICs:
O_BCSM有11张图片：
O_NULL: Starting state; call does not exist yet. AUTH_ORIG_ATTEMPT: Switch detects a call setup request. COLLECT_INFO: Switch collects the dial string from the calling party. ANALYZE_INFO: Complete dial string is translated into a routing address. SELECT_ROUTE: Physical route is selected, based on the routing address. AUTH_CALL_SETUP: Switch ensures the calling party is authorized to place the call. CALL_SENT: Control of call sent to terminating side. O_ALERTING: Switch waits for the called party to answer. O_ACTIVE: Connection established; communications ensue. O_DISCONNECT: Connection torn down. O_EXCEPTION: Switch detects an exceptional condition.
O_NULL：起始状态；呼叫尚未存在。验证初始尝试：开关检测到呼叫设置请求。收集信息：交换机从主叫方收集拨号字符串。分析信息：完整的拨号字符串被转换为路由地址。选择路由：根据路由地址选择物理路由。AUTH_CALL_SETUP：交换机确保呼叫方有权拨打电话。呼叫发送：控制发送到终端的呼叫。O_警报：交换机等待被叫方应答。O_ACTIVE：建立连接；随后进行了通信。O_断开连接：连接已断开。O_异常：开关检测到异常情况。
T_BCSM has 8 PICS:
T_BCSM有8张图片：
T_NULL: Starting state; call does not exist yet. AUTH_TERM_ATT: Switch verifies whether the call can be sent to terminating party. SELECT_FACILITY: Switch picks a terminating resource to send the call on. PRESENT_CALL: Call is being presented to the called party. T_ALERTING: Switch alerts the called party, e.g., by ringing the line. T_ACTIVE: Connection established; communications ensue. T_DISCONNECT: Connection torn down. T_EXCEPTION: Switch detects an exceptional condition.
T_NULL：起始状态；呼叫尚未存在。AUTH_TERM_ATT：交换机验证呼叫是否可以发送到终止方。SELECT_FACILITY：交换机选择要发送呼叫的终止资源。当前通话：通话正在呈现给被叫方。T_ALERTING：交换机通过拨打电话等方式向被叫方发出警报。T_ACTIVE：已建立连接；随后进行了通信。T\u断开连接：连接已断开。T_异常：开关检测到异常情况。
The state machine for O_BCSM and T_BCSM is provided in [1] on pages 98 and 103, respectively. This state machine will be used for subsequent discussion when the IN call states are mapped into SIP.
O_BCSM和T_BCSM的状态机分别在第98页和第103页的[1]中提供。当IN call状态映射到SIP时，此状态机将用于后续讨论。
The next two sections contain the mapping of the SIP protocol state machine to the IN BCSMs. Explaining all PICs and DPs in an IN call model is beyond the scope of this document. It is assumed that the reader has some familiarity with the PICs and DPs of the IN call model. More information can be found in [1]. For a quick reference, Appendix A contains a mapping of the DPs to the SIP response codes as discussed in the next two sections.
接下来的两部分包含SIP协议状态机到BCSMs中的映射。解释通话模式中的所有PIC和DP超出了本文档的范围。假设读者对通话模式的PICs和DPs有一定的了解。更多信息见[1]。为了快速参考，附录a包含了DPs到SIP响应代码的映射，如下两节所述。
The 11 PICs of O_BCSM come into play when a call request (SIP INVITE message) arrives from an upstream SIP client to an originating SIN-enabled SIP entity running the IN call model. This entity will create an O_BCSM object and initialize it in the O_NULL PIC. The next seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO, SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all be mapped to the SIP "Calling" state.
当呼叫请求（SIP INVITE消息）从上游SIP客户端到达运行IN call模型的支持SIN的SIP发起实体时，O_BCSM的11个PIC开始发挥作用。该实体将创建一个O_BCSM对象，并在O_NULL PIC中对其进行初始化。接下来的七个图片——O_NULL、AUTH_ORIG_ATT、COLLECT_INFO、Analysis_INFO、SELECT_ROUTE、AUTH_CALL_SETUP和CALL_SENT——都可以映射到SIP“Calling”状态。
Figure 5 provides a visual map from the SIP protocol state machine to the originating half of the IN call model. Note that control of the call shuttles between the SIP protocol machine and the IN O_BCSM call model while it is being serviced.
图5提供了从SIP协议状态机到IN-call模型发起端的可视映射。请注意，在SIP协议机器和IN O_BCSM呼叫模型进行服务时，对呼叫往返的控制。
SIP O_BCSM
SIP O_BCSM
| INVITE
V
+---------+ +---------------+
| Calling +=======================>+ O_NULL +<----+
+--+---/\-+ +-/\---+--------+ |
| | || +-------------+ | | |
| | ||<===+O_Exception +---------+ +--V-+ +--+-+
| | || +--/\---------+ |DP 1| |DP21|
| | || | +----+ +-----+----+------+ +--+-+
| | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 3| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 4|<-----+ Collect_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 5| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 6|<-----+ Analyze_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 7| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 8|<-----+ Select_Route +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 9| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP10|<-----+ Auth._Call_Setup+---->+
| | || +----+ +--------+--------+
+----+ | || |
| | || +--V-+
| | || |DP11|
| 1xx | || +-----+----+------+
| | ++========================+ Call_Sent |
| | +----/\----+------+
| | On 100,180,2xx process DP14 || |
| | On 3xx, process DP12 || |
| V On 486, process DP13 || |
| +--+-------+ On 5xx, 6xx and 4xx || |
| |Proceeding| (except 486) process DP21|| |
| INVITE
V
+---------+ +---------------+
| Calling +=======================>+ O_NULL +<----+
+--+---/\-+ +-/\---+--------+ |
| | || +-------------+ | | |
| | ||<===+O_Exception +---------+ +--V-+ +--+-+
| | || +--/\---------+ |DP 1| |DP21|
| | || | +----+ +-----+----+------+ +--+-+
| | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 3| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 4|<-----+ Collect_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 5| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 6|<-----+ Analyze_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 7| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 8|<-----+ Select_Route +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 9| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP10|<-----+ Auth._Call_Setup+---->+
| | || +----+ +--------+--------+
+----+ | || |
| | || +--V-+
| | || |DP11|
| 1xx | || +-----+----+------+
| | ++========================+ Call_Sent |
| | +----/\----+------+
| | On 100,180,2xx process DP14 || |
| | On 3xx, process DP12 || |
| V On 486, process DP13 || |
| +--+-------+ On 5xx, 6xx and 4xx || |
| |Proceeding| (except 486) process DP21|| |
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--200------------------+ |
| +----4xx to 6xx--------+ | |
| | | +--V-+
| On DPs 21, 2, 4, 6, 8, 10 | | |DP14|
| send 4xx-6xx final response | | +--------+----+--+
+-------+ | | | O_Alerting |
| | | +---------+------+
+--V-------+ | | |
|Completed |<------------+ | +--V-+
+--+-------+ | |DP16|
| | +------+----+----+
+--V-------+ | +-+ O_Active |
|Terminated|<---------------+ | +-------------+--+
+----------+ | |
+-----+ +--V-+
| |DP19|
+--V-+ +--------+----+
|DP17| | O_Disconnect|
+--+-+ +-------------+
|
V
To O_EXCEPTION
Legend:
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--200------------------+ |
| +----4xx to 6xx--------+ | |
| | | +--V-+
| On DPs 21, 2, 4, 6, 8, 10 | | |DP14|
| send 4xx-6xx final response | | +--------+----+--+
+-------+ | | | O_Alerting |
| | | +---------+------+
+--V-------+ | | |
|Completed |<------------+ | +--V-+
+--+-------+ | |DP16|
| | +------+----+----+
+--V-------+ | +-+ O_Active |
|Terminated|<---------------+ | +-------------+--+
+----------+ | |
+-----+ +--V-+
| |DP19|
+--V-+ +--------+----+
|DP17| | O_Disconnect|
+--+-+ +-------------+
|
V
To O_EXCEPTION
Legend:
| Communication between | states in the same V protocol
|同一V协议中的|状态之间的通信
======> Communication between IN Layer and SIP Protocol
State machine to transfer call state
======> Communication between IN Layer and SIP Protocol
State machine to transfer call state
Figure 5. Mapping from SIP to O_BCSM
图5。从SIP到O_BCSM的映射
The SIP "Calling" protocol state has enough functionality to absorb the seven PICs as described below:
SIP“呼叫”协议状态具有足够的功能来吸收七个PIC，如下所述：
O_NULL: This PIC is basically a fall through state to the next PIC, AUTHORIZE_ORIGINATION_ATTEMPT.
O_NULL：此PIC基本上是一个到下一个PIC的故障状态，授权\u发起\u尝试。
AUTHORIZE_ORIGINATION_ATTEMPT: In this PIC, the IN layer has detected that someone wishes to make a call. Under some circumstances (e.g., if the user is not allowed to make calls during certain hours), such a call cannot be placed. SIP can authorize the calling party by using a set of policy directives
授权\发起\尝试：在这张图片中，In层检测到有人想要打电话。在某些情况下（例如，如果不允许用户在特定时间拨打电话），则无法拨打此类电话。SIP可以使用一组策略指令对呼叫方进行授权
configured by the SIP administrator. If the called party is authorized to place the call, the IN layer is instructed to enter the next PIC, COLLECT_INFO through DP 3 (Origination_Attempt_Authorized). If for some reason the call cannot be authorized, DP 2 (Origination_Denied) is processed, and control transfers to the SIP state machine. The SIP state machine must format and send a non-2xx final response (possibly 403) to the upstream entity.
由SIP管理员配置。如果被叫方被授权拨打电话，则指示IN层进入下一个PIC，通过DP 3收集信息（发起尝试被授权）。如果由于某种原因无法授权呼叫，将处理DP 2（发起拒绝），并将控制转移到SIP状态机。SIP状态机必须格式化并向上游实体发送非2xx最终响应（可能是403）。
COLLECT_INFO: This PIC is responsible for collecting a dial string from the calling party and verifying the format of the string. If overlap dialing is being used, this PIC can invoke DP 4 (Collect_Timeout) and transfer control to the SIP state machine, which will format and send a non-2xx final response (possibly a 484). If the dial string is valid, DP 5 (Collected_Info) is processed, and the IN layer is instructed to enter the next PIC, ANALYZE_INFO.
收集信息：此PIC负责从主叫方收集拨号字符串并验证字符串的格式。如果使用重叠拨号，此PIC可以调用DP 4（收集超时）并将控制转移到SIP状态机，该状态机将格式化并发送非2xx最终响应（可能是484）。如果拨号字符串有效，将处理DP 5（收集的信息），并指示IN层输入下一个PIC，分析信息。
ANALYZE_INFO: This PIC is responsible for translating the dial string to a routing number. Many IN services, such as freephone, LNP (Local Number Portability), and OCS (Originating Call Screening) occur during this PIC. The IN layer can use the R-URI of the SIP INVITE request for analysis. If the analysis succeeds, the IN layer is instructed to enter the next PIC, SELECT_ROUTE. If the analysis fails, DP 6 (Invalid_Info) is processed, and the control transfers to the SIP state machine, which will generate a non-2xx final response (possibly 400, 401, 403, 404, 405, 406, 410, 414, 415, 416, 485, or 488) and send it to the upstream entity.
分析信息：此PIC负责将拨号字符串转换为路由号码。许多IN服务，如免费电话、LNP（本地号码可携性）和OCS（始发呼叫屏蔽）都发生在该PIC期间。IN层可以使用SIP INVITE请求的R-URI进行分析。如果分析成功，则指示IN层进入下一个PIC，选择_路线。如果分析失败，则处理DP 6（无效_信息），控制转移到SIP状态机，该状态机将生成非2xx最终响应（可能是400、401、403、404、405、406、410、414、415、416、485或488），并将其发送给上游实体。
SELECT_ROUTE: In the circuit-switched network, the actual physical route has to be selected at this point. The SIP analogue would be to determine the next hop SIP server. This could be chosen by a variety of means. For instance, if the Request URI in the incoming INVITE request is an E.164 number, the SIP entity can use a protocol like TRIP [10] to find the best gateway to egress the request onto the PSTN. If a successful route is selected, the IN call model moves to PIC AUTH_CALL_SETUP via DP 9 (Route_Selected). Otherwise, the control transfers to the SIP state machine via DP 8 (Route_Select_Failure), which will generate a non-2xx final response (possibly 488) and send it to the upstream entity.
选择路由：在电路交换网络中，此时必须选择实际的物理路由。SIP模拟将用于确定下一跳SIP服务器。这可以通过多种方式选择。例如，如果传入INVITE请求中的请求URI是E.164号，则SIP实体可以使用类似TRIP[10]的协议来找到将请求导出到PSTN上的最佳网关。如果选择了成功的路由，则呼叫内模型将通过DP 9（选择路由）移动到PIC AUTH_call_设置。否则，控制通过DP 8（路由选择失败）传输到SIP状态机，这将生成非2xx最终响应（可能是488）并将其发送到上游实体。
AUTH_CALL_SETUP: Certain service features restrict the type of call that may originate on a given line or trunk. This PIC is the point at which relevant restrictions are examined. If no such restrictions are encountered, the IN call model moves to PIC CALL_SENT via DP 11 (Origination_Authorized). If a restriction is encountered that prohibits further processing of the call, DP 10
授权呼叫设置：某些服务功能限制可能在给定线路或中继线上发起的呼叫类型。此PIC是检查相关限制的点。如果未遇到此类限制，呼叫内模型将移动到通过DP 11发送的PIC呼叫（授权发起）。如果遇到禁止进一步处理呼叫的限制，DP 10
(Authorization_Failure) is processed, and control is transferred to the SIP state machine, which will generate a non-2xx final response (possibly 404, 488, or 502). Otherwise, DP 11 (Origination_Authorized) is processed, and the IN layer is instructed to enter the next PIC, CALL_SENT.
（授权失败）被处理，控制权被转移到SIP状态机，该状态机将生成非2xx最终响应（可能是404、488或502）。否则，将处理DP 11（发起\授权），并指示IN层进入下一个PIC，调用\发送。
CALL_SENT: At this point, the request needs to be sent to the downstream entity. The IN layer waits for a signal confirming either that the call has been presented to the called party or that a called party cannot be reached for a particular reason. The control is transferred to the SIP state machine. The SIP state machine should now send the call to the next downstream server determined in PIC SELECT_ROUTE. The IN call model now blocks until unblocked by the SIP state machine.
CALL_SENT：此时，需要将请求发送到下游实体。IN层等待确认呼叫已呈现给被叫方或由于特定原因无法联系到被叫方的信号。控制权被转移到SIP状态机。SIP状态机现在应该将调用发送到PIC SELECT_路由中确定的下一个下游服务器。SIP机器现在处于解锁状态，直到呼叫被模型阻塞。
If the above seven PICs have been successfully negotiated, the SIN-enabled SIP entity now sends the SIP INVITE message to the next hop server. Further processing now depends on the provisional responses (if any) and the final response received by the SIP protocol state machine. The core SIP specification does not guarantee the delivery of 1xx responses; thus special processing is needed at the IN layer to transition to the next PIC (O_ALERTING) from the CALL_SENT PIC. The special processing needed for responses while the SIP state machine is in the "Proceeding" state and the IN layer is in the "CALL_SENT" state is described next.
如果已成功协商上述七个PIC，则启用SIN的SIP实体现在将SIP INVITE消息发送到下一个跃点服务器。进一步的处理现在取决于SIP协议状态机接收到的临时响应（如果有）和最终响应。核心SIP规范不保证1xx响应的交付；因此，需要在IN层进行特殊处理，以便从调用发送的PIC转换到下一个PIC（O_警报）。下面描述当SIP状态机处于“继续”状态且in层处于“CALL_SENT”状态时响应所需的特殊处理。
A 100 response received at the SIP state machine elicits no special behavior in the IN layer.
在SIP状态机上接收到的100响应在in层中不会引发任何特殊行为。
A 180 response received at the SIP entity enables the processing of DP 14 (O_Term_Seized), however, a state transition to O_ALERTING is not undertaken yet. Instead, the IN layer is instructed to remain in the CALL_SENT PIC until a final response is received.
SIP实体接收到的180响应允许处理DP 14（O_Term_扣押），但是，尚未进行O_警报的状态转换。相反，IN层被指示保持在CALL_SENT PIC中，直到收到最终响应。
A 2xx response received at the SIP entity enables the processing of DP 14 (O_Term_Seized), and the immediate transition to the next state, O_ALERTING (processing in O_ALERTING is described later).
SIP实体接收到的2xx响应允许处理DP 14（O_Term_Acquired），并立即转换到下一个状态O_ALERTING（O_ALERTING中的处理将在后面描述）。
A 3xx response received at the SIP entity enables the processing of DP 12 (Route_Failure). The IN call model from this point goes back to the SELECT_ROUTE PIC to select a new route for the contacts in the 3xx final response (not shown in Figure 5 for brevity).
SIP实体接收到的3xx响应允许处理DP 12（路由故障）。此时的IN call模型返回到SELECT_ROUTE PIC，为3xx最终响应中的联系人选择新的路由（为了简洁起见，图5中未显示）。
A 486 (Busy Here) response received at the SIP entity enables the processing of DP 13 (O_Called_Party_Busy) and resources for the call are released at the IN call model.
在SIP实体处接收的486（此处忙）响应启用DP 13（O_被叫方_忙）的处理，并且用于呼叫的资源在呼叫内模型处释放。
If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or 6xx final response, DP 21 (O_Calling_Party_Disconnect & O_Abandon) is processed and control passes to the SIP state machine. Since a call was not successfully established, both the IN layer and the SIP state machine can release resources for the call.
如果启用SIN的SIP实体获得4xx（486除外）、5xx或6xx最终响应，则处理DP 21（O_呼叫方\断开连接和O_放弃），并将控制传递到SIP状态机。由于呼叫未成功建立，IN层和SIP状态机都可以为呼叫释放资源。
O_ALERTING - This PIC will be entered as a result of receiving a 200-class response. Since a 200-class response to an INVITE indicates acceptance, this PIC is mostly a fall through to the next PIC, O_ACTIVE via DP 16 (O_Answer).
O_警报-收到200级响应后，将输入此PIC。由于对邀请的200级响应表示接受，因此此PIC主要是通过DP 16（O_答案）激活的下一个PIC的下降。
O_ACTIVE - At this point, the call is active. Once in this state, the call may get disconnected only when one of the following three events occur: (1) the network connection fails, (2) the called party disconnects the call, or (3) the calling party disconnects the call. If event (1) occurs, DP 17 (O_Connection_Failure) is processed and call control is transferred to the SIP protocol state machine. Since the network failed, there is not much sense in attempting to send a BYE request; thus, both the SIP protocol state machine and the IN call layer should release all resources associated with the call and initialize themselves to the null state. Event (2) results in the processing of DP 19 (O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event (3) occurs if the calling party deliberately terminated the call. In this case, DP 21 (O_Abandon & O_Calling_Party_Disconnect) will be processed, and control will be passed to the SIP protocol state machine. The SIP protocol state machine must send a BYE request and wait for a final response. The IN layer releases all of its resources and initializes itself to the null state.
O_ACTIVE-此时，呼叫处于活动状态。一旦处于这种状态，只有当以下三个事件之一发生时，呼叫才会断开：（1）网络连接失败，（2）被叫方断开呼叫，或（3）主叫方断开呼叫。如果发生事件（1），将处理DP 17（O_连接故障），并将呼叫控制转移到SIP协议状态机。由于网络故障，尝试发送BYE请求没有多大意义；因此，SIP协议状态机和IN-call层都应该释放与调用相关的所有资源，并将其自身初始化为空状态。事件（2）导致处理DP 19（O_断开）并移动到最后一个PIC，O_断开。如果主叫方故意终止呼叫，则发生事件（3）。在这种情况下，将处理DP 21（O_放弃和O_呼叫方_断开连接），并将控制权传递给SIP协议状态机。SIP协议状态机必须发送BYE请求并等待最终响应。IN层释放其所有资源并将自身初始化为null状态。
O_DISCONNECT: When the SIP entity receives a BYE request, the IN layer is instructed to move to the last PIC, O_DISCONNECT via DP 19. A final response for the BYE is generated and transmitted by the SIP entity, and the call resources are freed by both the SIP protocol state machine and the IN layer.
O_DISCONNECT：当SIP实体接收到BYE请求时，IN层被指示通过DP 19移动到最后一个PIC，O_DISCONNECT。BYE的最终响应由SIP实体生成和传输，呼叫资源由SIP协议状态机和IN层释放。
The T_BCSM object is created when a SIP INVITE message makes its way to the terminating SIN-enabled SIP entity. This entity creates the T_BCSM object and initializes it to the T_NULL PIC.
当SIP INVITE消息到达终止启用SIN的SIP实体时，将创建T_BCSM对象。此实体创建T_BCSM对象并将其初始化为T_NULL PIC。
Figure 6 provides a visual map from the SIP protocol state machine to the terminating half of the IN call model:
图6提供了从SIP协议状态机到IN call模型终止端的可视映射：
SIP T_BCSM
SIP T_BCSM
| INVITE
V
+----------+ +------------+
|Proceeding+=========================>+ T_Null +<-------+
+-+--+--/\-+ +/\----+-----+ |
| | || +-----------+ | | |
| | ||<=======+T_Exception+--------+ +--V-+ +--+-+
| | || +-/\--------+ |DP22| |DP35|
| | || | +----+ +---+----+------+ +--+-+
| | || +<---+DP23|<------+Auth._Term._Att+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP24| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP25|<------+Select_Facility+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP26| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP27|<------+ Present_Call +---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP28| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP29|<------+ T_Alerting +---->+
| | || | +----+ +-/\--+---------+ |
| | || +<--------------+ || | |
| | || | || | |
| | ++==========================|===++ | |
| | /\ +-------+ +--V-+ |
| | || | +DP30| |
| | || +-+--+ +---+----+------+ |
| | || |DP31+<-----| T_Active +---->+
| | || +----+ +-/\-----+------+
| | || || |
| | || || |
2xx | | ++==============================++ |
sent | | |
+----+ | 3xx - 6xx response +--V-+
| | sent |DP33|
| INVITE
V
+----------+ +------------+
|Proceeding+=========================>+ T_Null +<-------+
+-+--+--/\-+ +/\----+-----+ |
| | || +-----------+ | | |
| | ||<=======+T_Exception+--------+ +--V-+ +--+-+
| | || +-/\--------+ |DP22| |DP35|
| | || | +----+ +---+----+------+ +--+-+
| | || +<---+DP23|<------+Auth._Term._Att+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP24| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP25|<------+Select_Facility+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP26| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP27|<------+ Present_Call +---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP28| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP29|<------+ T_Alerting +---->+
| | || | +----+ +-/\--+---------+ |
| | || +<--------------+ || | |
| | || | || | |
| | ++==========================|===++ | |
| | /\ +-------+ +--V-+ |
| | || | +DP30| |
| | || +-+--+ +---+----+------+ |
| | || |DP31+<-----| T_Active +---->+
| | || +----+ +-/\-----+------+
| | || || |
| | || || |
2xx | | ++==============================++ |
sent | | |
+----+ | 3xx - 6xx response +--V-+
| | sent |DP33|
| +----V-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
+------>|
|
+----V-----+
|Terminated|
+----------+
| +----V-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
+------>|
|
+----V-----+
|Terminated|
+----------+
Legend:
图例：
| Communication between
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine to transfer call state
| Communication between
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine to transfer call state
Figure 6. Mapping from SIP to T_BCSM
图6。从SIP到T_BCSM的映射
The SIP "Proceeding" state has enough functionality to absorb the first five PICS -- T_Null, Authorize_Termination_Attempt, Select_Facility, Present_Call, T_Alerting -- as described below:
SIP“继续”状态具有足够的功能来吸收前五个PIC——T_Null、授权T_终止T_尝试、选择T_设施、当前T_呼叫、T_警报，如下所述：
T_NULL: At this PIC, the terminating end creates the call at the IN layer. The incoming call results in the processing of DP 22, Termination_Attempt, and a transition to the next PIC, AUTHORIZE_TERMINATION_ATTEMPT, takes place.
T_NULL：在这个PIC中，终止端在IN层创建调用。传入呼叫导致处理DP 22，终止尝试，并转换到下一个PIC，授权终止尝试。
AUTHORIZE_TERMINATION_ATTEMPT: At this PIC, it is ascertained that the called party wishes to receive the call and that the facilities of the called party are compatible with those of the calling party. If any of these conditions is not met, DP 23 (Termination_Denied) is invoked, and the call control is transferred to the SIP protocol state machine. The SIP protocol state machine can format and send a non-2xx final response (possibly 403, 405, 415, or 480). If the conditions of the PIC are met, processing of DP 24 (Termination_Authorized) is invoked, and a transition to the next PIC, SELECT_FACILITY, takes place.
授权\终止\尝试：在此PIC中，确定被叫方希望接收呼叫，并且被叫方的设施与主叫方的设施兼容。如果不满足这些条件中的任何一个，将调用DP 23（Termination_Denied），并将呼叫控制转移到SIP协议状态机。SIP协议状态机可以格式化并发送非2xx最终响应（可能是403、405、415或480）。如果满足PIC的条件，将调用DP 24（终止\u授权）的处理，并转换到下一个PIC，选择\u设施。
SELECT_FACILITY: In circuit switched networks, this PIC is intended to select a line or trunk to reach the called party. As lines or trunks are not applicable in an IP network, a SIN-enabled SIP entity can use this PIC to interface with a PSTN gateway and select a line/trunk to route the call. If the called party is busy, or if a line/trunk cannot be seized, the processing of DP 25 (T_Called_Party_Busy) is invoked, and the call goes to the SIP protocol state machine. The SIP protocol state machine must format and send a non-2xx final response (possibly 486 or 600). If a line/trunk was successfully seized, the processing of DP 26 (Terminating_Resource_Available) is invoked, and a transition to the next PIC, PRESENT_CALL, takes place.
选择设施：在电路交换网络中，此PIC旨在选择一条线路或中继线以到达被叫方。由于线路或中继线不适用于IP网络，启用SIN的SIP实体可以使用此PIC与PSTN网关接口，并选择线路/中继线来路由呼叫。如果被叫方忙，或者如果线路/中继线无法被占用，则调用DP 25（T_called_party_busy）的处理，并将呼叫转到SIP协议状态机。SIP协议状态机必须格式化并发送非2xx最终响应（可能是486或600）。如果线路/中继线被成功占用，将调用DP 26（终止资源可用）的处理，并转换到下一个PIC，即当前呼叫。
PRESENT_CALL: At this point, the call is being presented (via the ISUP ACM message, or Q.931 Alerting message, or simply by ringing a POTS phone). If there was an error presenting the call, the processing of DP 27 (Presentation_Failure) is invoked, and the call control is transferred to the SIP protocol state machine, which must format and send a non-2xx final response (possibly 480). If the call was successfully presented, the processing of DP 28 (T_Term_Seized) is invoked, and a transition to the next PIC, T_ALERTING, takes place.
PRESENT_CALL（当前通话）：此时，正在显示通话（通过ISUP ACM消息或Q.931警报消息，或只需拨打POTS电话）。如果呈现呼叫时出错，将调用DP 27（呈现失败）的处理，并将呼叫控制转移到SIP协议状态机，该状态机必须格式化并发送非2xx最终响应（可能480）。如果调用成功呈现，则调用DP 28（T_Term_tapped）的处理，并转换到下一个PIC，T_ALERTING。
T_ALERTING: At this point, the called party is being "alerted". Control now passes momentarily to the SIP protocol state machine so that it can generate and send a "180 Ringing" response to its peer. Furthermore, since network resources have been allocated for the call, timers are set to prevent indefinite holding of such resources. The expiration of the relevant timers results in the processing of DP 29 (T_No_Answer), and the call control is transferred to the SIP protocol state machine, which must format and send a non-2xx final response (possibly 408). If the called party answers, then DP 30 (T_Answer) is processed, followed by a transition to the next PIC, T_ACTIVE.
T_警报：此时，被叫方被“警报”。控制现在瞬间传递到SIP协议状态机，以便它可以生成并向其对等方发送“180振铃”响应。此外，由于已经为呼叫分配了网络资源，因此设置了定时器以防止无限期地占用此类资源。相关定时器的到期导致DP 29（T_No_应答）的处理，并且呼叫控制被转移到SIP协议状态机，该状态机必须格式化并发送非2xx最终响应（可能是408）。如果被叫方应答，则处理DP 30（T_应答），然后转换到下一个PIC，T_激活。
After the above five PICs have been negotiated, the rest are mapped as follows:
上述五个PIC协商完成后，其余的映射如下：
T_ACTIVE: The call is now active. Once this state is reached, the call may become inactive under one of the following three conditions: (1) The network fails the connection, (2) the called party disconnects the call, or (3) the calling party disconnects the call. Event (1) results in the processing of DP 31 (T_Connection_Failure), and call control is transferred to the SIP protocol state machine. Since the network failed, there is little sense in attempting to send a BYE request; thus, both the SIP protocol state machine and the IN call layer should release all resources associated with the call and initialize themselves to
T_ACTIVE：呼叫现在处于活动状态。一旦达到此状态，呼叫可能在以下三种情况之一下变为非活动状态：（1）网络连接失败，（2）被叫方断开呼叫，或（3）主叫方断开呼叫。事件（1）导致DP 31的处理（T_连接_失败），呼叫控制转移到SIP协议状态机。由于网络故障，尝试发送BYE请求没有什么意义；因此，SIP协议状态机和IN-call层都应该释放与调用相关的所有资源，并将其自身初始化为
the null state. Event (2) results in the processing of DP 33 (T_Disconnect) and a transition to the next PIC, T_DISCONNECT. Event (3) occurs at the receipt of a BYE request at the SIP protocol state machine (not shown in Figure 6). Resources for the call should be deallocated, and the SIP protocol state machine must send a 200 OK for the BYE request (not shown in Figure 6).
空状态。断开对下一个事件a（T）的处理（T）和处理结果的连接。事件（3）发生在SIP协议状态机接收到BYE请求时（图6中未显示）。调用的资源应该被释放，SIP协议状态机必须为BYE请求发送200OK（图6中未显示）。
T_DISCONNECT: In this PIC, the disconnect treatment associated with the called party's having disconnected the call is performed at the IN layer. The SIP protocol state machine sends out a BYE and awaits a final response for the BYE (not shown in Figure 6).
T_DISCONNECT：在这个PIC中，与被叫方断开呼叫相关的断开处理在In层执行。SIP协议状态机发送BYE并等待BYE的最终响应（图6中未显示）。
Two examples are provided here to show how SIP protocol state machine and the IN call model work synchronously with each other.
这里提供了两个示例来说明SIP协议状态机和IN-call模型是如何同步工作的。
In the first example, a SIP UAC originates a call request destined to an 800 freephone number:
在第一个示例中，SIP UAC发起以800免费电话号码为目的地的呼叫请求：
INVITE sip:18005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
INVITE sip:18005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
The request makes its way to the originating SIP network server running an IN call model. The SIP network server hands, at the very least, the To: field and the From: field to the IN layer for freephone number translation. The IN layer proceeds through its PICs and at the ANALYSE_INFO PIC consults the SCP for freephone translation. The translated number is returned to the SIP network server, which forwards the message to the next hop SIP proxy, with the freephone number replaced by the translated number:
请求到达运行IN-call模型的原始SIP网络服务器。SIP网络服务器至少将To:字段和From:字段交给IN层以进行免费电话号码转换。IN层继续通过其PIC，在分析信息时，PIC咨询SCP进行免费电话翻译。翻译后的号码返回给SIP网络服务器，该服务器将消息转发给下一跳SIP代理，免费电话号码替换为翻译后的号码：
INVITE sip:18475551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP ext-stn2.example.net
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
INVITE sip:18475551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP ext-stn2.example.net
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
In the next example, a SIP UAC originates a call request destined to a 900 number:
在下一示例中，SIP UAC发起以900号码为目的地的呼叫请求：
INVITE sip:19005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
INVITE sip:19005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
The request makes its way to the originating SIP network server running an IN call model. The SIP network server hands, at the very least, the To: field and the From: field to the IN layer for 900 number translation. The IN layer proceeds through its PICs and at the ANALYSE_INFO PIC consults the SCP for the translation. During the translation, the SCP detects that the originating party is not allowed to make 900 calls. It passes this information to the originating SIP network server, which informs the SIP UAC by using a SIP "403 Forbidden" response status code:
请求到达运行IN-call模型的原始SIP网络服务器。SIP网络服务器至少将To:字段和From:字段交给IN层进行900号转换。IN层继续通过其PIC，在分析信息时，PIC咨询SCP进行翻译。在转换过程中，SCP检测到发起方不允许进行900次呼叫。它将此信息传递给发起SIP网络服务器，该服务器通过使用SIP“403禁止”响应状态代码通知SIP UAC：
SIP/2.0 403 Forbidden
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com;tag=78K-909II
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
SIP/2.0 403 Forbidden
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com;tag=78K-909II
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
Security considerations for SIN services cover both networks being used, namely, the PSTN and the Internet. SIN uses the security measures in place for both the networks. With reference to Figure 2, the INAP messages between the SCP and the SIN-enabled SIP entity must be secured by the signaling transport used between the SCP and the SIN-enabled entity. Likewise, the requests coming into the SIN-enabled SIP entity must first be authenticated and, if need be, encrypted as well, using the means and procedures defined in [3] for SIP requests.
SIN服务的安全考虑包括正在使用的两个网络，即PSTN和Internet。SIN使用两个网络的安全措施。参考图2，SCP和启用SIN的SIP实体之间的INAP消息必须通过SCP和启用SIN的实体之间使用的信令传输进行保护。同样，进入启用SIN的SIP实体的请求必须首先进行身份验证，如果需要，还必须使用[3]中针对SIP请求定义的方法和过程进行加密。
[1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services," McGraw-Hill, 1997.
[1] I.Faynberg、L.Gabuzda、M.Kaplan和N.Shah，“智能网络标准：它们在服务中的应用”，McGraw-Hill，1997年。
[2] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network Distributed Functional Plane Architecture," International Telecommunications Union Standardization Section, Geneva.
[2] ITU-T Q.1204 1993：建议Q.1204，“智能网络分布式功能平面体系结构”，日内瓦国际电信联盟标准化科。
[3] 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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] ITU-T Q.1208: "General aspects of the Intelligent Network Application protocol"
[4] ITU-T Q.1208：“智能网络应用协议的一般方面”
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[5] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[7] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[8] ITU-T Q.1218: "Interface Recommendation for Intelligent Network Capability Set 1".
[8] ITU-T Q.1218：“智能网络能力集1的接口建议”。
[9] ITU-T Q.1228: "Interface Recommendation for Intelligent Network Capability Set 2".
[9] ITU-T Q.1228：“智能网络能力集2的接口建议”。
[10] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[10] Rosenberg，J.，Salama，H.，和M.Squire，“IP电话路由（TRIP）”，RFC 3219，2002年1月。
Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points
附录A：SIP中4xx-6xx响应到in检测点的映射
The mapping of error codes 4xx-6xx responses in SIP to the possible Detection Points in PIC Originating and Terminating Call Handling is indicated in the table below. The reason phrase in the 4xx-6xx response is reproduced from [3].
SIP中的错误代码4xx-6xx响应与PIC始发和终止呼叫处理中可能的检测点的映射如下表所示。4xx-6xx响应中的原因短语摘自[3]。
SIP response code DP mapping to IN
----------------- ----------------------
200 OK DP 14
3xx DP 12
403 Forbidden DP 2, DP 21
484 Address Incomplete DP 4, DP 21
400 Bad Request DP 6, DP 21
401 Unauthorized DP 6, DP 21
403 Forbidden DP 6, DP 21, DP 23
404 Not Found DP 6, DP 21
405 Method Not Allowed DP 6, DP 21, DP 23
406 Not Acceptable DP 6, DP 21
408 Request Timeout DP 29
410 Gone DP 6, DP 21
414 Request-URI Too Long DP 6, DP 21
415 Unsupported Media Type DP 6, DP 21, DP 23
416 Unsupported URI Scheme DP 6, DP 21
480 Temporarily Unavailable DP 23, DP 27
485 Ambiguous DP 6, DP 21
486 Busy Here DP 13, DP 21, DP 25
488 Not Acceptable Here DP 6, DP 21
SIP response code DP mapping to IN
----------------- ----------------------
200 OK DP 14
3xx DP 12
403 Forbidden DP 2, DP 21
484 Address Incomplete DP 4, DP 21
400 Bad Request DP 6, DP 21
401 Unauthorized DP 6, DP 21
403 Forbidden DP 6, DP 21, DP 23
404 Not Found DP 6, DP 21
405 Method Not Allowed DP 6, DP 21, DP 23
406 Not Acceptable DP 6, DP 21
408 Request Timeout DP 29
410 Gone DP 6, DP 21
414 Request-URI Too Long DP 6, DP 21
415 Unsupported Media Type DP 6, DP 21, DP 23
416 Unsupported URI Scheme DP 6, DP 21
480 Temporarily Unavailable DP 23, DP 27
485 Ambiguous DP 6, DP 21
486 Busy Here DP 13, DP 21, DP 25
488 Not Acceptable Here DP 6, DP 21
Acknowledgments
致谢
Special acknowledgment is due to Hui-Lan Lu for acting as the chair of the SIN DT and ensuring that the focus of the DT did not veer too far. The authors would also like to give special thanks to Mr. Ray C. Forbes from Marconi Communications Limited for his valuable contribution on the system and network architectural aspects as co-chair in the ETSI SPAN. Thanks also to Doris Lebovits, Kamlesh Tewani, Janusz Dobrowloski, Jack Kozik, Warren Montgomery, Lev Slutsman, Henning Schulzrinne, and Jonathan Rosenberg, who all contributed to the discussions on the relationship of IN and SIP call models.
特别感谢陆惠兰担任SIN DT的主席，并确保DT的重点不会偏离太远。作者还要特别感谢Marconi Communications Limited的Ray C.Forbes先生作为ETSI SPAN联合主席在系统和网络架构方面做出的宝贵贡献。还要感谢多丽丝·勒博维茨、卡姆莱什·特瓦尼、贾努斯·多布罗洛斯基、杰克·科齐克、沃伦·蒙哥马利、列夫·斯勒茨曼、亨宁·舒尔兹林内和乔纳森·罗森博格，他们都为IN和SIP通话模型关系的讨论做出了贡献。
Author's Addresses
作者地址
Vijay K. Gurbani Lucent Technologies, Inc. 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 USA Phone: +1 630 224 0216 EMail: vkg@lucent.com
Vijay K.Gurbani Lucent Technologies，Inc.美国伊利诺伊州纳珀维尔6G-440室Lucent Lane 2000室电话：+1 630 224 0216电子邮件：vkg@lucent.com
Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium Phone: +32 3 240 9034 EMail: frans.haerens@alcatel.be
Frans Haerens Alcatel Bell Francis Welles Plein，1比利时电话：+32 3 240 9034电子邮件：Frans。haerens@alcatel.be
Vidhi Rastogi Wipro Technologies Plot No.72, Keonics Electronics City, Hosur Main Road, Bangalore 226 560 100 Phone: +91 80 51381869 EMail: vidhi.rastogi@wipro.com
Vidhi Rastogi Wipro Technologies位于班加罗尔霍苏尔大道Keonics电子城72号地块226 560 100电话：+91 80 51381869电子邮件：Vidhi。rastogi@wipro.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见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编辑功能的资金目前由互联网协会提供。