Network Working Group A. Vemuri
Request for Comments: 3372 Qwest Communications
BCP: 63 J. Peterson
Category: Best Current Practice NeuStar
September 2002
Network Working Group A. Vemuri
Request for Comments: 3372 Qwest Communications
BCP: 63 J. Peterson
Category: Best Current Practice NeuStar
September 2002
Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
电话会话启动协议（SIP-T）：上下文和体系结构
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
The popularity of gateways that interwork between the PSTN (Public Switched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This document taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying).
PSTN（公共交换电话网络）和SIP网络之间互通的网关的普及促使发布了一套通用实践，以确保实现中的行为一致。本文档对PSTN-SIP网关的使用进行分类，提供用例，并确定互通所需的机制。这些机制详细说明了SIP如何提供“封装”（跨SIP网络桥接PSTN信令）和“转换”（网关）。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SIP-T for ISUP-SIP Interconnections . . . . . . . . . . . . . 4
3. SIP-T Flows . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 SIP Bridging (PSTN - IP - PSTN) . . . . . . . . . . . . . . . 8
3.2 PSTN origination - IP termination . . . . . . . . . . . . . . 9
3.3 IP origination - PSTN termination . . . . . . . . . . . . . . 11
4. SIP-T Roles and Behavior . . . . . . . . . . . . . . . . . . . 12
4.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Intermediary . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Behavioral Requirements Summary . . . . . . . . . . . . . . . 15
5. Components of the SIP-T Protocol . . . . . . . . . . . . . . . 16
5.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SIP-T for ISUP-SIP Interconnections . . . . . . . . . . . . . 4
3. SIP-T Flows . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 SIP Bridging (PSTN - IP - PSTN) . . . . . . . . . . . . . . . 8
3.2 PSTN origination - IP termination . . . . . . . . . . . . . . 9
3.3 IP origination - PSTN termination . . . . . . . . . . . . . . 11
4. SIP-T Roles and Behavior . . . . . . . . . . . . . . . . . . . 12
4.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Intermediary . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Behavioral Requirements Summary . . . . . . . . . . . . . . . 15
5. Components of the SIP-T Protocol . . . . . . . . . . . . . . . 16
5.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Support for mid-call signaling . . . . . . . . . . . . . . . . 17
6. SIP Content Negotiation . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
5.4 Support for mid-call signaling . . . . . . . . . . . . . . . . 17
6. SIP Content Negotiation . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
The Session Initiation Protocol (SIP [1]) is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. These multimedia sessions include multimedia conferences, Internet telephony and similar applications. SIP is one of the key protocols used to implement Voice over IP (VoIP). Although performing telephony call signaling and transporting the associated audio media over IP yields significant advantages over traditional telephony, a VoIP network cannot exist in isolation from traditional telephone networks. It is vital for a SIP telephony network to interwork with the PSTN.
会话启动协议（SIP[1]）是一种应用层控制协议，可以建立、修改和终止多媒体会话或呼叫。这些多媒体会议包括多媒体会议、互联网电话和类似的应用程序。SIP是用于实现IP语音（VoIP）的关键协议之一。尽管通过IP执行电话呼叫信令和传输相关音频媒体比传统电话具有显著优势，但VoIP网络不能与传统电话网络隔离存在。SIP电话网络与PSTN互通至关重要。
The popularity of gateways that interwork between the PSTN and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. The scarcity of SIP expertise outside the IETF suggests that the IETF is the best place to stage this work, especially since SIP is in a relative state of flux compared to the core protocols of the PSTN. Moreover, the IETF working groups that focus on SIP (SIP and SIPPING) are best positioned to ascertain whether or not any new extensions to SIP are justified for PSTN interworking. This framework addresses the overall context in which PSTN-SIP interworking gateways might be deployed, provides use cases and identifies the mechanisms necessary for interworking.
PSTN和SIP网络之间互通的网关的普及促使发布了一套通用实践，以确保实现中的行为一致。IETF之外SIP专业知识的缺乏表明IETF是开展这项工作的最佳场所，特别是因为与PSTN的核心协议相比，SIP处于相对的流量状态。此外，专注于SIP（SIP和SIP）的IETF工作组最适合确定SIP的任何新扩展是否适合PSTN互通。该框架解决了可能部署PSTN-SIP互通网关的总体环境，提供了用例，并确定了互通所需的机制。
An important characteristic of any SIP telephony network is feature transparency with respect to the PSTN. Traditional telecom services such as call waiting, freephone numbers, etc., implemented in PSTN protocols such as Signaling System No. 7 (SS7 [6]) should be offered by a SIP network in a manner that precludes any debilitating difference in user experience while not limiting the flexibility of SIP. On the one hand, it is necessary that SIP support the primitives for the delivery of such services where the terminating point is a regular SIP phone (see definition in Section 2 below) rather than a device that is fluent in SS7. However, it is also essential that SS7 information be available at gateways, the points
任何SIP电话网络的一个重要特征是PSTN的特性透明。在PSTN协议（如7号信令系统（SS7[6]）中实现的传统电信服务（如呼叫等待、免费电话号码等）应由SIP网络提供，其方式应避免用户体验中的任何不利差异，同时不限制SIP的灵活性。一方面，SIP必须支持用于提供此类服务的原语，其中终端是常规SIP电话（见下文第2节中的定义），而不是能够流利使用SS7的设备。然而，同样重要的是，七号信令信息必须在网关上可用，这些点
of SS7-SIP interconnection, to ensure transparency of features not otherwise supported in SIP. If possible, SS7 information should be available in its entirety and without any loss to trusted parties in the SIP network across the PSTN-IP interface; one compelling need to do so also arises from the fact that certain networks utilize proprietary SS7 parameters to transmit certain information through their networks.
SS7-SIP互连，以确保SIP中不支持的功能的透明度。如果可能，SS7信息应全部可用，且不会在PSTN-IP接口上对SIP网络中的受信任方造成任何损失；一个迫切需要这样做的原因是，某些网络利用专有的SS7参数通过其网络传输某些信息。
Another important characteristic of a SIP telephony network is routability of SIP requests - a SIP request that sets up a telephone call should contain sufficient information in its headers to enable it to be appropriately routed to its destination by proxy servers in the SIP network. Most commonly this entails that parameters of a call like the dialed number should be carried over from SS7 signaling to SIP requests. Routing in a SIP network may in turn be influenced by mechanisms such as TRIP [8] or ENUM [7].
SIP电话网络的另一个重要特征是SIP请求的可路由性——建立电话呼叫的SIP请求应在其报头中包含足够的信息，以使其能够通过SIP网络中的代理服务器适当地路由到其目的地。最常见的是，这意味着呼叫的参数（如已拨号码）应该从SS7信令转移到SIP请求。SIP网络中的路由又可能受到TRIP[8]或ENUM[7]等机制的影响。
The SIP-T (SIP for Telephones) effort provides a framework for the integration of legacy telephony signaling into SIP messages. SIP-T provides the above two characteristics through techniques known as 'encapsulation' and 'translation' respectively. At a SIP-ISUP gateway, SS7 ISUP messages are encapsulated within SIP in order that information necessary for services is not discarded in the SIP request. However, intermediaries like proxy servers that make routing decisions for SIP requests cannot be expected to understand ISUP, so simultaneously, some critical information is translated from an ISUP message into the corresponding SIP headers in order to determine how the SIP request will be routed.
SIP-T（电话SIP）工作为将传统电话信令集成到SIP消息中提供了一个框架。SIP-T通过分别称为“封装”和“翻译”的技术提供上述两个特性。在SIP-ISUP网关中，SS7 ISUP消息被封装在SIP中，以便服务所需的信息不会在SIP请求中被丢弃。但是，不能期望为SIP请求做出路由决定的代理服务器等中介机构理解ISUP，因此同时，一些关键信息会从ISUP消息转换为相应的SIP报头，以确定SIP请求的路由方式。
While pure SIP has all the requisite instruments for the establishment and termination of calls, it does not have any baseline mechanism to carry any mid-call information (such as the ISUP INF/INR query) along the SIP signaling path during the session. This mid-call information does not result in any change in the state of SIP calls or the parameters of the sessions that SIP initiates. A provision to transmit such optional application-layer information is also needed.
虽然纯SIP具有建立和终止呼叫的所有必要工具，但它没有任何基线机制来在会话期间沿SIP信令路径携带任何中间呼叫信息（如ISUP INF/INR查询）。此中间呼叫信息不会导致SIP呼叫的状态或SIP发起的会话的参数发生任何变化。还需要传输此类可选应用层信息的规定。
Problem definition: To provide ISUP transparency across SS7-SIP interworking
问题定义：在SS7-SIP互通中提供ISUP透明度
SS7-SIP Interworking Requirements SIP-T Functions
==================================================================
Transparency of ISUP Encapsulation of ISUP in the
Signaling SIP body
SS7-SIP Interworking Requirements SIP-T Functions
==================================================================
Transparency of ISUP Encapsulation of ISUP in the
Signaling SIP body
Routability of SIP messages with Translation of ISUP information dependencies on ISUP into the SIP header
SIP消息的可路由性，将ISUP上的ISUP信息依赖项转换为SIP报头
Transfer of mid-call ISUP signaling Use of the INFO Method for mid-messages call signaling
中间呼叫ISUP信令的传输中间消息呼叫信令使用INFO方法
Table 1: SIP-T features that fulfill PSTN-IP inter-connection Requirements
表1：满足PSTN-IP互连要求的SIP-T功能
While this document specifies the requirements above, it provide mechanisms to satisfy them - however, this document does serve as an framework for the documents that do provide these mechanisms, all of which are referenced in Section 5.
虽然本文件规定了上述要求，但提供了满足这些要求的机制——然而，本文件确实是提供这些机制的文件的框架，所有这些都在第5节中引用。
Note that many modes of signaling are used in telephony (SS7 ISUP, BTNUP, Q.931, MF etc.). This document focuses on SS7 ISUP and aims to specify the behavior across ISUP-SIP interfaces only. The scope of the SIP-T enterprise may, over time, come to encompass other signaling systems as well.
请注意，电话中使用了许多信令模式（SS7 ISUP、BTNUP、Q.931、MF等）。本文档重点介绍SS7 ISUP，旨在仅指定ISUP-SIP接口之间的行为。随着时间的推移，SIP-T企业的范围也可能包括其他信令系统。
SIP-T is not a new protocol - it is a set of mechanisms for interfacing traditional telephone signaling with SIP. The purpose of SIP-T is to provide protocol translation and feature transparency across points of PSTN-SIP interconnection. It intended for use where a VoIP network (a SIP network, for the purposes of this document) interfaces with the PSTN.
SIP-T并不是一个新的协议——它是一套将传统电话信令与SIP连接起来的机制。SIP-T的目的是跨PSTN-SIP互连点提供协议转换和功能透明。它用于VoIP网络（本文档中的SIP网络）与PSTN接口的情况。
Using SIP-T, there are three basic models for how calls interact with gateways. Calls that originate in the PSTN can traverse a gateway to terminate at a SIP endpoint, such as an IP phone. Conversely, an IP phone can make a call that traverses a gateway to terminate in the PSTN. Finally, an IP network using SIP may serve as a transit network between gateways - a call may originate and terminate in the PSTN, but cross a SIP-based network somewhere in the middle.
使用SIP-T，有三种基本的呼叫与网关交互模型。在PSTN中发起的呼叫可以通过网关在SIP端点（如IP电话）处终止。相反，IP电话可以通过网关进行呼叫，以在PSTN中终止。最后，使用SIP的IP网络可以作为网关之间的传输网络——呼叫可以在PSTN中发起和终止，但是在中间的某处交叉基于SIP的网络。
The SS7 interfaces of a particular gateway determine the ISUP variants that that gateway supports. Whether or nor a gateway supports a particular version of ISUP determines whether it can provide feature transparency while terminating a call.
特定网关的SS7接口决定了该网关支持的ISUP变体。网关是否支持特定版本的ISUP决定了它是否能够在终止呼叫时提供功能透明性。
The following are the primary agents in a SIP-T-enabled network.
以下是启用SIP-T的网络中的主要代理。
o PSTN (Public Switched Telephone Network): This refers to the entire interconnected collection of local, long-distance and international phone companies. In the examples below, the term Local Exchange Carrier (LEC) is used to denote a portion (usually, a regional division) of the PSTN.
o PSTN（公共交换电话网）：指本地、长途和国际电话公司的整个互联集合。在下面的示例中，术语本地交换载波（LEC）用于表示PSTN的一部分（通常是区域划分）。
o IP endpoints: Any SIP user agent that can act as an originator or recipient of calls. Thus, the following devices are classified as IP endpoints:
o IP端点：任何SIP用户代理，可以作为呼叫的发起人或接收人。因此，以下设备被分类为IP端点：
* Gateways: A telephony gateway provides a point of conversion between signaling protocols (such as ISUP and SIP) as well as circuit-switch and packet-switched audio media. The term Media Gateway Controller (MGC) is also used in the examples and diagrams in this document to denote large-scale clusters of decomposed gateways and control logic that are frequently deployed today. So for example, a SIP-ISUP gateway speaks ISUP to the PSTN and SIP to the Internet and is responsible for converting between the types of signaling, as well as interchanging any associated bearer audio media.
* 网关：电话网关提供信令协议（如ISUP和SIP）以及电路交换和分组交换音频媒体之间的转换点。本文档中的示例和图表中还使用了术语媒体网关控制器（MGC），以表示目前经常部署的大规模分解网关和控制逻辑集群。因此，例如，SIP-ISUP网关将ISUP与PSTN通话，将SIP与Internet通话，并负责在信令类型之间进行转换，以及交换任何相关的承载音频媒体。
* SIP phones: The term used to represent all end-user devices that originate or terminate SIP VoIP calls.
* SIP电话：用于表示发起或终止SIP VoIP呼叫的所有终端用户设备的术语。
* Interface points between networks where administrative policies are enforced (potentially middleboxes, proxy servers, or gateways).
* 实施管理策略的网络之间的接口点（可能是中间盒、代理服务器或网关）。
o Proxy Servers: A proxy server is a SIP intermediary that routes SIP requests to their destinations. For example, a proxy server might direct a SIP request to another proxy, a gateway or a SIP phone.
o 代理服务器：代理服务器是将SIP请求路由到其目的地的SIP中介。例如，代理服务器可以将SIP请求定向到另一个代理、网关或SIP电话。
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
Figure 1: Motivation for SIP-T in ISUP-SIP interconnection
图1:ISUP-SIP互连中SIP-T的动机
In Figure 2 a VoIP cloud serves as a transit network for telephone calls originating in a pair of LECs, where SIP is employed as the VoIP protocol used to set up and tear down these VoIP calls. At the edge of the depicted network, an MGC converts the ISUP signals to SIP requests, and sends them to a proxy server which in turn routes calls on other MGCs. Although this figure depicts only two MGCs, VoIP deployments would commonly have many such points of interconnection with the PSTN (usually to diversify among PSTN rate centers). For a call originating from LEC1 and be terminating in LEC2, the originator in SIP-T is the gateway that generates the SIP request for a VoIP call, and the terminator is the gateway that is the consumer of the SIP request; MGC1 would thus be the originator and MGC2, the terminator. Note that one or more proxies may be used to route the call from the originator to the terminator.
在图2中，VoIP云充当源自一对LEC的电话呼叫的中转网络，其中SIP用作VoIP协议，用于设置和中断这些VoIP呼叫。在所描绘的网络边缘，MGC将ISUP信号转换为SIP请求，并将其发送到代理服务器，代理服务器反过来路由其他MGC上的呼叫。尽管此图仅描述了两个MGC，但VoIP部署通常会有许多与PSTN的互连点（通常在PSTN速率中心之间实现多样化）。对于从LEC1发起并在LEC2中终止的呼叫，SIP-T中的发起者是为VoIP呼叫生成SIP请求的网关，而终止者是作为SIP请求消费者的网关；因此，MGC1将是发起者，MGC2将是终结者。请注意，可以使用一个或多个代理将呼叫从发起者路由到终止者。
In this flow, in order to seamlessly integrate the IP network with the PSTN, it is important to preserve the received SS7 information within SIP requests at the originating gateway and reuse this SS7 information when signaling to the PSTN at the terminating gateway. By encapsulating ISUP information in the SIP signaling, a SIP network can ensure that no SS7 information that is critical to the instantiation of features is lost when SIP bridges calls between two segments of the PSTN.
在该流程中，为了将IP网络与PSTN无缝集成，重要的是在发起网关的SIP请求中保留接收到的SS7信息，并在终端网关向PSTN发送信令时重用该SS7信息。通过将ISUP信息封装在SIP信令中，SIP网络可以确保当SIP桥接PSTN的两个段之间的呼叫时，对特征的实例化至关重要的SS7信息不会丢失。
That much said, if only the exchange of ISUP between gateways were relevant here, any protocol for the transport of signaling information may be used to achieve this, obviating the need for SIP and consequently that of SIP-T. SIP-T is employed in order to leverage the intrinsic benefits of utilizing SIP: request routing and call control leveraging proxy servers (including the use of forking),
话虽如此，如果网关之间的ISUP交换在这里是相关的，那么可以使用任何信令信息传输协议来实现这一点，无需SIP，因此无需SIP-T。采用SIP-T是为了利用SIP的固有优势：利用代理服务器（包括使用分叉）进行请求路由和呼叫控制，
ease of SIP service creation, SIP's capability negotiation systems, and so on. Translation of information from the received ISUP message parameters to SIP header fields enables SIP intermediaries to consider this information as they handle requests. SIP-T thus facilitates call establishment and the enabling of new telephony services over the IP network while simultaneously providing a method of feature-rich interconnection with the PSTN.
易于创建SIP服务、SIP的能力协商系统等。从接收的ISUP消息参数到SIP报头字段的信息转换使得SIP中介能够在处理请求时考虑这些信息。因此，SIP-T有助于通过IP网络建立呼叫和启用新的电话服务，同时提供与PSTN的功能丰富的互连方法。
Finally, the scenario in Figure 2 is just one of several flows in which SIP-T can be used - voice calls do not always both originate and terminate in the PSTN (via gateways); SIP phones can also be endpoints in a SIP-T session. In subsequent sections, the following possible flows will be further detailed:
最后，图2中的场景只是可以使用SIP-T的几个流中的一个——语音呼叫并不总是在PSTN中发起和终止（通过网关）；SIP电话也可以是SIP-T会话中的端点。在后续章节中，将进一步详细说明以下可能的流程：
1. PSTN origination - PSTN termination: The originating gateway receives ISUP from the PSTN and it preserves this information (via encapsulation and translation) in the SIP messages that it transmits towards the terminating gateway. The terminator extracts the ISUP content from the SIP message that it receives and it reuses this information in signaling sent to the PSTN.
1. PSTN发起-PSTN终止：发起网关从PSTN接收ISUP，并将此信息（通过封装和转换）保存在向终止网关传输的SIP消息中。终端从接收到的SIP消息中提取ISUP内容，并在发送到PSTN的信令中重用该信息。
2. PSTN origination - IP termination: The originating gateway receives ISUP from the PSTN and it preserves this ISUP information in the SIP messages (via encapsulation and translation) that it directs towards the terminating SIP user agent. The terminator has no use for the encapsulated ISUP and ignores it.
2. PSTN发起-IP终止：发起网关从PSTN接收ISUP，并将此ISUP信息保留在指向终止SIP用户代理的SIP消息中（通过封装和转换）。终止符不使用封装的ISUP并忽略它。
3. IP origination - PSTN termination: A SIP phone originates a VoIP call that is routed by one or more proxy servers to the appropriate terminating gateway. The terminating gateway converts to ISUP signaling and directs the call to an appropriate PSTN interface, based on information that is present in the received SIP header.
3. IP发起-PSTN终止：SIP电话发起VoIP呼叫，该呼叫由一个或多个代理服务器路由到相应的终止网关。终端网关转换为ISUP信令，并根据接收到的SIP报头中存在的信息将呼叫定向到适当的PSTN接口。
4. IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking.
4. IP起始-IP终止：这是纯SIP的情况。SIP-T（ISUP的封装或翻译）不起作用，因为没有PSTN互通。
The follow sections explore the essential SIP-T flows in detail. Note that because proxy servers are usually responsible for routing SIP requests (based on the Request-URI) the eventual endpoints at which a SIP request will terminate is generally not known to the originator. So the originator does not select from the flows
以下各节将详细探讨基本的SIP-T流程。请注意，由于代理服务器通常负责路由SIP请求（基于请求URI），因此SIP请求将终止的最终端点通常不为发起人所知。因此，发起人不从流中进行选择
described in this section, as a matter of static configuration or on a per-call basis - rather, each call is routed by the SIP network independently, and it may instantiate any of the flows below as the routing logic of the network dictates.
如本节所述，作为静态配置或基于每次呼叫的问题，每个呼叫由SIP网络独立路由，并且它可以根据网络的路由逻辑来实例化以下任何流。
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------
Figure 2: PSTN origination - PSTN termination (SIP Bridging)
图2:PSTN发起-PSTN终止（SIP桥接）
A scenario in which a SIP network connects two segments of the PSTN is referred to as 'SIP bridging'. When a call destined for the SIP network originates in the PSTN, an SS7 ISUP message will eventually be received by the gateway that is the point of interconnection with the PSTN network. This gateway is from the perspective of the SIP protocol the user agent client for this call setup request. Traditional SIP routing is used in the IP network to determine the appropriate point of termination (in this instance a gateway) and to establish a SIP dialog and begin negotiation of a media session between the origination and termination endpoints. The egress gateway then signals ISUP to the PSTN, reusing any encapsulated ISUP present in the SIP request it receives as appropriate.
SIP网络连接PSTN两个网段的场景称为“SIP桥接”。当以SIP网络为目的地的呼叫在PSTN中发起时，作为与PSTN网络互连点的网关将最终接收到SS7 ISUP消息。从SIP协议的角度来看，此网关是此呼叫设置请求的用户代理客户端。传统的SIP路由在IP网络中用于确定适当的终止点（在本例中为网关），建立SIP对话，并开始发起和终止端点之间的媒体会话协商。然后，出口网关向PSTN发送ISUP信号，并根据需要重用其接收的SIP请求中存在的任何封装ISUP。
A very elementary call-flow for SIP bridging is shown below.
SIP桥接的一个非常基本的调用流如下所示。
PSTN MGC#1 Proxy MGC#2 PSTN
|-------IAM------>| | | |
| |-----INVITE---->| |
| | | |-----IAM----->|
| |<--100 TRYING---| |
| | | |<----ACM------|
| |<-----18x-------| |
|<------ACM-------| | | |
| | | |<----ANM------|
| |<----200 OK-----| |
|<------ANM-------| | | |
| |------ACK------>| |
|====================Conversation=================|
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |
PSTN MGC#1 Proxy MGC#2 PSTN
|-------IAM------>| | | |
| |-----INVITE---->| |
| | | |-----IAM----->|
| |<--100 TRYING---| |
| | | |<----ACM------|
| |<-----18x-------| |
|<------ACM-------| | | |
| | | |<----ANM------|
| |<----200 OK-----| |
|<------ANM-------| | | |
| |------ACK------>| |
|====================Conversation=================|
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP phone |
-------- ********************* -------------
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP phone |
-------- ********************* -------------
Figure 3: PSTN origination - IP termination
图3:PSTN发起-IP终端
A call originates from the PSTN and terminates at a SIP phone. Note that in Figure 5, the proxy server acts as the registrar for the SIP phone in question.
呼叫从PSTN发起，并在SIP电话处终止。注意，在图5中，代理服务器充当所讨论的SIP电话的注册器。
A simple call-flow depicting the ISUP and SIP signaling for a PSTN-originated call terminating at a SIP endpoint follows:
描述在SIP端点终止的PSTN发起呼叫的ISUP和SIP信令的简单呼叫流如下所示：
PSTN MGC Proxy SIP phone
|----IAM----->| | |
| |--------INVITE------>| |
| | |-------INVITE------->|
| |<------100 TRYING----| |
| | |<-------18x----------|
| |<---------18x--------| |
|<----ACM-----| | |
| | |<-------200 OK-------|
| |<-------200 OK-------| |
|<----ANM-----| | |
| |---------ACK-------->| |
| | |---------ACK-------->|
|=====================Conversation========================|
|-----REL---->| | |
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |
PSTN MGC Proxy SIP phone
|----IAM----->| | |
| |--------INVITE------>| |
| | |-------INVITE------->|
| |<------100 TRYING----| |
| | |<-------18x----------|
| |<---------18x--------| |
|<----ACM-----| | |
| | |<-------200 OK-------|
| |<-------200 OK-------| |
|<----ANM-----| | |
| |---------ACK-------->| |
| | |---------ACK-------->|
|=====================Conversation========================|
|-----REL---->| | |
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP phone | ** ** | PSTN |
------------ ********************* ---------
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP phone | ** ** | PSTN |
------------ ********************* ---------
Figure 4: IP origination - PSTN termination
图4：IP发起-PSTN终端
A call originates from a SIP phone and terminates in the PSTN. Unlike the previous two flows, there is therefore no ISUP encapsulation in the request - the terminating gateway therefore only performs translation on the SIP headers to derive values for ISUP parameters.
呼叫从SIP电话发起，并在PSTN中终止。与前两个流不同，因此请求中没有ISUP封装-因此，终止网关仅对SIP头执行转换以导出ISUP参数的值。
A simple call-flow illustrating the different legs in the call is as shown below.
下面是一个简单的调用流程，演示了调用中的不同分支。
SIP phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|
SIP phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|
There are three distinct sorts of elements (from a functional point of view) in a SIP VoIP network that interconnects with the PSTN:
在与PSTN互连的SIP VoIP网络中，有三种不同类型的元素（从功能角度来看）：
1. The originators of SIP signaling
1. SIP信令的发起者
2. The terminators of SIP signaling
2. SIP信令的终端
3. The intermediaries that route SIP requests from the originator to the terminator
3. 将SIP请求从发起方路由到终止方的中介
Behavior for the Section 4.1, Section 4.2 and Section 4.3 intermediary roles in a SIP-T call are described in the following sections.
SIP-T呼叫中第4.1节、第4.2节和第4.3节中间角色的行为将在以下各节中描述。
The function of the originating user agent client is to generate the SIP Call setup requests (i.e., INVITEs). When a call originates in the PSTN, a gateway is the UAC; otherwise some native SIP endpoint is the UAC. In either case, note that the originator generally cannot anticipate what sort of entity the terminator will be, i.e., whether final destination of the request is in a SIP network or the PSTN.
发起用户代理客户端的功能是生成SIP呼叫设置请求（即邀请）。在PSTN发起呼叫时，网关为UAC；否则，一些本机SIP端点就是UAC。在这两种情况下，请注意，发起人通常无法预测终止者将是哪种类型的实体，即，请求的最终目的地是在SIP网络还是PSTN中。
In the case of calls originating in the PSTN (see Figure 3 and Figure 5), the originating gateway takes the necessary steps to preserve the ISUP information by encapsulating it in the SIP request it creates. The originating gateway is entrusted with the responsibility of identifying the version of the ISUP (ETSI, ANSI, etc.) that it has received and providing this information in the encapsulated ISUP (usually by adding a multipart MIME body with appropriate MIME headers). It then formulates the headers of the SIP INVITE request from the parameters of the ISUP that it has received from the PSTN as appropriate (see Section 5). This might, for instance, entail setting the 'To:' header field in the INVITE to the reflect dialed number (Called Party Number) of the received ISUP IAM.
在PSTN发起呼叫的情况下（见图3和图5），发起网关通过将ISUP信息封装在其创建的SIP请求中，采取必要的步骤来保留ISUP信息。发起网关负责识别其接收到的ISUP版本（ETSI、ANSI等），并在封装的ISUP中提供此信息（通常通过添加带有适当MIME头的多部分MIME正文）。然后，它根据从PSTN接收到的ISUP参数（视情况而定）制定SIP INVITE请求的报头（参见第5节）。例如，这可能需要将邀请中的“To:”标题字段设置为接收到的ISUP IAM的反映拨号号码（称为参与方号码）。
In other cases (like Figure 7), a SIP phone is the originator of a VoIP call. Usually, the SIP phone sends requests to a SIP proxy that is responsible for routing the request to an appropriate destination. There is no ISUP to encapsulate at the user agent client, as there is no PSTN interface. Although the call may terminate in the telephone network and need to signal ISUP in order for that to take place, the originator has no way to anticipate this and it would be foolhardy to require that all SIP VoIP user agents have the capability to generate ISUP. It is therefore not the responsibility of an IP endpoints like a SIP phone to generate encapsulated ISUP. Thus, an originator must generate the SIP signaling while performing ISUP encapsulation and translation when possible (meaning when the call has originated in the PSTN).
在其他情况下（如图7），SIP电话是VoIP呼叫的发起人。通常，SIP电话向SIP代理发送请求，该代理负责将请求路由到适当的目的地。由于没有PSTN接口，因此在用户代理客户端没有要封装的ISUP。尽管呼叫可能会在电话网络中终止，并且需要发出ISUP信号才能发生，但发起者无法预测这一点，因此要求所有SIP VoIP用户代理具有生成ISUP的能力将是鲁莽的。因此，像SIP电话这样的IP端点不负责生成封装的ISUP。因此，发起者必须在可能的情况下（意味着呼叫在PSTN中发起时）在执行ISUP封装和转换的同时生成SIP信令。
Originator requirements: encapsulate ISUP, translate information from ISUP to SIP, multipart MIME support (for gateways only)
发起人要求：封装ISUP，将信息从ISUP转换为SIP，支持多部分MIME（仅适用于网关）
The SIP-T terminator is a consumer of the SIP calls. The terminator is a standard SIP UA that can be either a gateway that interworks with the PSTN or a SIP phone.
SIP-T终端是SIP呼叫的消费者。终端是标准SIP UA，可以是与PSTN互通的网关，也可以是SIP电话。
In case of PSTN terminations (see Figure 3 and Figure 7) the egress gateway terminates the call to its PSTN interface. The terminator generates the ISUP appropriate for signaling to the PSTN from the incoming SIP message. Values for certain ISUP parameters may be gleaned from the SIP headers or extracted directly from an encapsulated ISUP body. Generally speaking, a gateway uses any encapsulated ISUP as a template for the message it will send, but it overwrites parameter values in the template as it translates SIP headers or adds any parameter values that reflect its local policies (see Appendix A item 1).
在PSTN终止的情况下（见图3和图7），出口网关终止对其PSTN接口的调用。终端器生成适用于从传入SIP消息向PSTN发送信令的ISUP。某些ISUP参数的值可以从SIP头中收集，也可以直接从封装的ISUP主体中提取。一般来说，网关使用任何封装的ISUP作为其将发送的消息的模板，但在转换SIP头或添加反映其本地策略的任何参数值时，它会覆盖模板中的参数值（请参见附录a第1项）。
In case of an IP termination (Figure 5), the SIP UAS that receives SIP messages with encapsulated ISUP typically disregards the ISUP message. This does introduce a general requirement, however, that devices like SIP phones handle multipart MIME messages and unknown MIME types gracefully (this is a baseline SIP requirement, but also a place where vendors have been known to make shortcuts).
在IP终止的情况下（图5），接收带有封装ISUP的SIP消息的SIP UAS通常会忽略ISUP消息。然而，这确实引入了一个一般性要求，即像SIP电话这样的设备能够优雅地处理多部分MIME消息和未知MIME类型（这是一个基本的SIP要求，但也是一个已知供应商可以制作快捷方式的地方）。
Terminator requirements: standard SIP processing, interpretation of encapsulated ISUP (for gateways only), support for multipart MIME, graceful handling of unknown MIME content (for non-gateways only)
终端要求：标准SIP处理、封装ISUP的解释（仅适用于网关）、支持多部分MIME、优雅地处理未知MIME内容（仅适用于非网关）
Intermediaries like proxy servers are entrusted with the task of routing messages to one another, as well as gateways and SIP phones. Each proxy server makes a forwarding decision for a SIP request based on values of various headers, or 'routable elements' (including the Request-URI, route headers, and potentially many other elements of a SIP request).
代理服务器等中介机构被委托负责将消息路由到彼此，以及网关和SIP电话。每个代理服务器根据各种头或“可路由元素”（包括请求URI、路由头和SIP请求的可能许多其他元素）的值为SIP请求做出转发决策。
SIP-T does introduce some additional considerations for forwarding a request that could lead to new features and requirements for intermediaries. Feature transparency of ISUP is central to the notion of SIP-T. Compatibility between the ISUP variants of the originating and terminating PSTN interfaces automatically leads to feature transparency. Thus, proxy servers might take an interest in the variants of ISUP that are encapsulated with requests - the variant itself could become a routable element. The termination of a call at a point that results in greater proximity to the final destination (rate considerations) is also an important consideration. The preference of one over the other results in a trade-off between simplicity of operation and cost. The requirement of procuring a reasonable rate may dictate that a SIP-T call spans dissimilar PSTN interfaces (SIP bridging across different gateways that don't support any ISUP variants in common). In order to optimize for maximum feature transparency and rate, some operators of intermediaries might want to consider practices along the following lines:
SIP-T确实为转发请求引入了一些额外的考虑因素，这些考虑因素可能会为中介带来新的特性和需求。ISUP的功能透明度是SIP-T概念的核心。发起和终止PSTN接口的ISUP变体之间的兼容性自动导致功能透明度。因此，代理服务器可能对用请求封装的ISUP变体感兴趣——该变体本身可能成为可路由元素。在更接近最终目的地的地点终止呼叫（费率考虑）也是一个重要考虑因素。一种方法优于另一种方法会在操作简单性和成本之间进行权衡。获取合理速率的要求可能要求SIP-T呼叫跨越不同的PSTN接口（SIP桥接跨越不支持任何常见ISUP变体的不同网关）。为了优化最大的特征透明度和速率，中间的一些操作员可能要考虑以下的实践：
a) The need for ISUP feature transparency may necessitate ISUP variant translation (conversion), i.e., conversion from one variant of ISUP to another in order to facilitate the termination of that call over a gateway interface that does not support the ISUP variant of the originating PSTN interface. (See Appendix A item 2.) Although in theory conversion may be performed at any point in the path of the request, it is optimal to perform it at a point that is at the greatest proximity to the terminating gateway. This could be accomplished by delivering the call to an application that might perform the conversion between variants. Feature transparency in this case is contingent on the availability of resources to perform ISUP conversion, and it incurs an increase in the call-set up time.
a) ISUP功能透明性的需要可能需要ISUP变体转换（转换），即从一个ISUP变体转换为另一个，以便于通过不支持原始PSTN接口的ISUP变体的网关接口终止该调用。（参见附录A第2项。）虽然理论上可以在请求路径中的任何点执行转换，但最好在最接近终端网关的点执行转换。这可以通过将调用传递给可能执行变体之间转换的应用程序来实现。在这种情况下，功能透明度取决于执行ISUP转换的资源的可用性，并且会增加呼叫设置时间。
b) An alternative would be to sacrifice ISUP transparency by handing the call off to a gateway that does not support the version of the originating ISUP. The terminating MGC would then just ignore the encapsulated ISUP and use the information in the SIP header to terminate the call.
b) 另一种选择是牺牲ISUP的透明度，将呼叫转交给不支持原始ISUP版本的网关。然后，终止MGC将忽略封装的ISUP，并使用SIP报头中的信息终止呼叫。
So, it may be desirable for proxy servers to have the intelligence to make a judicious choice given the options available to it.
因此，对于代理服务器来说，考虑到其可用的选项，它可能希望能够智能地做出明智的选择。
Proxy requirements: ability to route based on choice of routable elements
代理要求：基于可路由元素的选择进行路由的能力
If the SIP-T originator is a gateway that received an ISUP request, it must always perform both encapsulation and translation ISUP, regardless of where the originator might guess that the request will terminate.
如果SIP-T发起人是接收ISUP请求的网关，则它必须始终执行封装和转换ISUP，而不管发起人可能猜测请求将在何处终止。
If the terminator does not understand ISUP, it ignores it while performing standard SIP processing. If the terminator does understand ISUP, and needs to signal to the PSTN, it should reuse the encapsulated ISUP if it understands the variant. The terminator should perform the following steps:
如果终止符不理解ISUP，它将在执行标准SIP处理时忽略它。如果终端确实理解ISUP，并且需要向PSTN发送信号，则如果它理解该变体，则应重新使用封装的ISUP。终端应执行以下步骤：
o Extract the ISUP from the message body, and use this ISUP as a message template. Note that if there is no encapsulated ISUP in the message, the gateway should use a canonical template for the message type in question (a pre-populated ISUP message configured in the gateway) instead.
o 从消息正文中提取ISUP，并将此ISUP用作消息模板。请注意，如果消息中没有封装的ISUP，则网关应使用相关消息类型的规范模板（网关中配置的预填充ISUP消息）。
o Translate the headers of the SIP request into ISUP parameters, overwriting any values in the message template.
o 将SIP请求的头转换为ISUP参数，覆盖消息模板中的任何值。
o Apply any local policies in populating parameters.
o 在填充参数时应用任何本地策略。
An intermediary must be able to route a call based on the choice of routable elements in the SIP headers.
中介必须能够根据SIP头中可路由元素的选择来路由呼叫。
The mechanisms described in the following sections are the components of SIP-T that provide the protocol functions entailed by the requirements.
以下章节中描述的机制是SIP-T的组件，它们提供了需求所包含的协议功能。
SIP-T uses the methods and procedures of SIP as defined by RFC 3261.
SIP-T使用RFC 3261定义的SIP方法和程序。
Encapsulation of the PSTN signaling is one of the major requirements of SIP-T. SIP-T uses multipart MIME bodies to enable SIP messages to contain multiple payloads (Session Description Protocol or SDP [5], ISUP, etc.). Numerous ISUP variants are in existence today; the ISUP MIME type enable recipients too recognize the ISUP type (and thus determine whether or not they support the variant) in the most expeditious possible manner. One scheme for performing ISUP encapsulation using multi-part MIME has been described in [2].
PSTN信令的封装是SIP-T的主要要求之一。SIP-T使用多部分MIME体使SIP消息包含多个有效负载（会话描述协议或SDP[5]、ISUP等）。如今存在着许多ISUP变体；ISUP MIME类型使收件人能够以最快速的方式识别ISUP类型（从而确定他们是否支持该变体）。[2]中描述了使用多部分MIME执行ISUP封装的一种方案。
Translation encompasses all aspects of signaling protocol conversion between SIP and ISUP. There are essentially two components to the problem of translation:
转换包括SIP和ISUP之间信令协议转换的所有方面。翻译问题基本上有两个组成部分：
1. ISUP SIP message mapping: This describes a mapping between ISUP and SIP at the message level. In SIP-T deployments gateways are entrusted with the task of generating a specific ISUP message for each SIP message received and vice versa. It is necessary to specify the rules that govern the mapping between ISUP and SIP messages (i.e., what ISUP messages is sent when a particular SIP message is received: an IAM must be sent on receipt of an INVITE, a REL for BYE, and so on). A potential mapping between ISUP and SIP messages has been described in [10].
1. ISUP SIP消息映射：描述ISUP和SIP在消息级别的映射。在SIP-T部署中，网关负责为接收到的每个SIP消息生成特定的ISUP消息，反之亦然。有必要指定管理ISUP和SIP消息之间映射的规则（即，当接收到特定SIP消息时发送什么ISUP消息：在接收到INVITE时必须发送IAM，REL表示BYE，等等）。[10]中描述了ISUP和SIP消息之间的潜在映射。
2. ISUP parameter-SIP header mapping: A SIP request that is used to set up a telephone call should contain information that enables it to be appropriately routed to its destination by proxy servers in the SIP network - for example, the telephone number dialed by the originating user. It is important to standardize a set of practices that defines the procedure for translation of information from ISUP to SIP (for example, the Called Party Number in an ISUP IAM must be mapped onto the SIP 'To' header field and Request-URI, etc.). This issue becomes inherently more complicated by virtue of the fact that the headers of a SIP request (especially an INVITE) may be transformed by intermediaries, and that consequently, the SIP headers and encapsulated ISUP bodies come to express conflicting values - effectively, a part of the encapsulated ISUP may be rendered irrelevant and obsolete.
2. ISUP参数SIP头映射：用于设置电话呼叫的SIP请求应包含使其能够通过SIP网络中的代理服务器正确路由到其目的地的信息，例如，发起用户拨打的电话号码。标准化一组实践非常重要，这些实践定义了将信息从ISUP转换为SIP的过程（例如，ISUP IAM中的被叫方号码必须映射到SIP“to”头字段和请求URI等）。由于SIP请求（尤其是INVITE）的头可以通过中介进行转换，并且因此，SIP头和封装的ISUP实体能够有效地表达冲突的值，因此该问题本质上变得更加复杂，封装的ISUP的一部分可能会变得不相关和过时。
Pure SIP does not have any provision for carrying any mid-call control information that is generated during a session. The INFO [3] method should be used for this purpose. Note however that INFO is not suitable for managing overlap dialing (for one way of implementing overlap dialing see [11]). Also note that the use of INFO for signaling mid-call DTMF signals is not recommended (see RFC2833 [9] for a recommended mechanism).
Pure SIP没有任何用于承载会话期间生成的任何中间呼叫控制信息的规定。为此，应使用INFO[3]方法。但是请注意，INFO不适用于管理重叠拨号（关于实现重叠拨号的一种方法，请参见[11]）。还请注意，不建议使用INFO发送通话中DTMF信号（有关建议的机制，请参阅RFC2833[9]）。
The originator of a SIP-T request might package both SDP and ISUP elements into the same SIP message by using the MIME multipart format. Traditionally in SIP, if the terminating device does not support a multipart payload (multipart/mixed) and/or the ISUP MIME type, it would then reject the SIP request with a 415 Unsupported Media Type specifying the media types it supports (by default, 'application/SDP'). The originator would subsequently have to re-send the SIP request after stripping out the ISUP payload (i.e. with only the SDP payload) and this would then be accepted.
SIP-T请求的发起人可以使用MIME多部分格式将SDP和ISUP元素打包到同一个SIP消息中。传统上，在SIP中，如果终端设备不支持多部分有效负载（多部分/混合）和/或ISUP MIME类型，则它将使用415不支持的媒体类型拒绝SIP请求，并指定其支持的媒体类型（默认情况下为“应用程序/SDP”）。发端人随后必须在剥离ISUP有效负载（即，仅使用SDP有效负载）后重新发送SIP请求，然后这将被接受。
This is a rather cumbersome flow, and it is thus highly desirable to have a mechanism by which the originator could signify which bodies are required and which are optional so that the terminator can silently discard optional bodies that it does not understand (allowing a SIP phone to ignore an ISUP payload when processing ISUP is not critical). This is contingent upon the terminator having support for a Content-type of multipart/mixed and access to the Content-Disposition header to express criticality.
这是一个相当麻烦的流程，因此非常希望有一种机制，发起者可以通过该机制指出哪些实体是必需的，哪些是可选的，以便终止者可以默默地丢弃它不理解的可选实体（当处理ISUP不是关键时，允许SIP电话忽略ISUP有效负载）。这取决于终端是否支持多部分/混合的内容类型，以及是否可以访问内容处置头以表示关键性。
1. Support for ISUP is optional. Therefore, UA2 accepts the INVITE irrespective of whether it can process the ISUP.
1. 对ISUP的支持是可选的。因此，UA2接受邀请，而不管它是否能够处理ISUP。
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=optional;)
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=optional;)
<--18x
<--18x
2. Support for ISUP is preferred. UA2 does not support the ISUP and rejects the INVITE with a 415 Unsupported Media Type. UA1 strips off the ISUP and re-sends the INVITE with SDP only and this is the accepted.
2. 最好支持ISUP。UA2不支持ISUP，并拒绝使用415不支持的媒体类型的邀请。UA1剥离ISUP并仅使用SDP重新发送邀请，这是已接受的。
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
<--415
(Accept: application/sdp)
ACK-->
确认-->
INVITE-->
(Content-type: application/sdp)
INVITE-->
(Content-type: application/sdp)
<--18x
<--18x
3. Support for ISUP is mandatory for call establishment. UA2 does not support the ISUP and rejects the INVITE with a 415 Unsupported Media type. UA1 then directs its request to UA3.
3. 呼叫建立必须支持ISUP。UA2不支持ISUP，并拒绝使用415不支持的媒体类型的邀请。然后，UA1将其请求定向到UA3。
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
<--415
(Accept: application/sdp)
ACK-->
确认-->
UA1 UA3
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
UA1 UA3
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
Note that the exchanges of messages above are not complete; only the messages relevant to this discussion are shown. Specifics of the ISUP MIME type can be obtained from [2]. The 'version' and 'base' parameters are not shown here, but must be used in accordance with the rules of [2].
注意，上述信息交换不完整；仅显示与此讨论相关的消息。ISUP MIME类型的详细信息可从[2]获得。此处未显示“版本”和“基础”参数，但必须按照[2]的规则使用。
SIP-T can be employed as an interdomain signaling mechanism that may be subject to pre-existing trust relationships between administrative domains. In many legal environments, distribution of ISUP is restricted to licensed carriers; SIP-T introduces some challenges in so far as it bridges carrier signaling with end-user signaling. Any administrative domain implementing SIP-T should have an adequate security apparatus (including elements that manage any appropriate policies to manage fraud and billing in an interdomain environment) in place to ensure that the transmission of ISUP information does not result in any security violations.
SIP-T可以用作域间信令机制，该机制可能受制于管理域之间预先存在的信任关系。在许多法律环境中，ISUP的分发仅限于许可运营商；SIP-T在桥接载波信令和最终用户信令方面带来了一些挑战。任何实施SIP-T的管理域都应该有适当的安全装置（包括管理域间环境中欺诈和计费的任何适当策略的元件），以确保ISUP信息的传输不会导致任何安全违规。
Transporting ISUP in SIP bodies may provide opportunities for abuse, fraud, and privacy concerns, especially when SIP-T requests can be generated, inspected or modified by arbitrary SIP endpoints. ISUP MIME bodies should be secured (preferably with S/MIME [4]) to alleviate this concern, as is described in the Security Considerations of the core SIP specification [1]. Authentication properties provided by S/MIME would allow the recipient of a SIP-T message to ensure that the ISUP MIME body was generated by an
在SIP机构中传输ISUP可能会导致滥用、欺诈和隐私问题，特别是当任意SIP端点可以生成、检查或修改SIP-T请求时。应保护ISUP MIME主体（最好使用S/MIME[4]）以缓解此问题，如核心SIP规范[1]的安全注意事项所述。S/MIME提供的身份验证属性允许SIP-T消息的接收者确保ISUP MIME正文由
authorized entity. Encryption would ensure that only carriers possessing a particular decryption key are capable of inspecting encapsulated ISUP MIME bodies in a SIP request.
授权实体。加密将确保只有拥有特定解密密钥的运营商才能检查SIP请求中封装的ISUP MIME实体。
SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and SHOULD support encryption (CMS EnvelopedData).
SIP-T端点必须支持S/MIME签名（CMS SignedData），并且应该支持加密（CMS EnvelopedData）。
This document introduces no new considerations for IANA.
本文档没有介绍IANA的新注意事项。
Normative References
规范性引用文件
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年5月。
[2] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
[2] Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[4] Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
Non-Normative References
非规范性引用文件
[6] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, September 1997, <http://www.itu.int>.
[6] 国际电信联盟，“第7号信令系统；ISDN用户部分信令程序”，ITU-T Q.764，1997年9月<http://www.itu.int>.
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[7] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年9月。
[8] Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[8] Rosenberg，J.，Salama，H.和M.Squire，“IP电话路由（TRIP）”，RFC 3219，2002年1月。
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[10] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP Mapping", Work in Progress.
[10] Camarillo，G.，Roach，A.，Peterson，J.和L.Ong，“ISUP到SIP映射”，工作正在进行中。
[11] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of ISUP Overlap Signaling to SIP", Work in Progress.
[11] Camarillo，G.，Roach，A.，Peterson，J.和L.Ong，“ISUP重叠信令到SIP的映射”，工作正在进行中。
1. Some terminating MGCs may alter the encapsulated ISUP in order to remove any conditions specific to the originating circuit; for example, continuity test flags in the Nature of Connection Indicators, etc.
1. 一些端接MGC可以改变封装的ISUP，以消除特定于起始电路的任何条件；例如，连接指示器性质中的连续性测试标志等。
2. Even so, the relevance of ANSI-specific information in an ETSI network (or vice versa) is questionable. Clearly, the strength of SIP-T is realized when the encapsulated ISUP involves the usage of proprietary parameters.
2. 即便如此，在ETSI网络中ANSI特定信息的相关性（反之亦然）还是值得怀疑的。显然，当封装的ISUP涉及到专有参数的使用时，SIP-T的强度就实现了。
We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan, Allison Mankin, Scott Bradner and Steve Bellovin for their valuable comments.
我们感谢安德鲁·杜根、罗伯·迈德霍夫、戴夫·马丁、亚当·罗奇、乔纳森·罗森博格、迪安·威利斯、罗伯特·彭菲尔德、史蒂夫·多诺万、艾利森·曼金、斯科特·布拉德纳和史蒂夫·贝洛文提出的宝贵意见。
The original 'SIP+' proposal for interconnecting portions of the PSTN with SIP bridging was developed by Eric Zimmerer.
最初的“SIP+”方案是由Eric Zimmerer开发的，用于将PSTN的各个部分与SIP桥接互连。
Authors' Addresses
作者地址
Aparna Vemuri-Pattisam Qwest Communications 6000 Parkwood Pl Dublin, OH 43016 US EMail: Aparna.Vemuri@Qwest.com vaparna10@yahoo.com
Aparna Vemuri Pattisam Qwest Communications 6000美国俄亥俄州都柏林帕克伍德公司43016电子邮件：Aparna。Vemuri@Qwest.com vaparna10@yahoo.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520 US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520 US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。