Network Working Group G. Camarillo
Request for Comments: 3398 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
December 2002
Network Working Group G. Camarillo
Request for Comments: 3398 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
December 2002
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
综合业务数字网（ISDN）用户部分（ISUP）到会话发起协议（SIP）的映射
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
本文档描述了执行两个信令协议之间映射的方法：会话发起协议（SIP）和7号信令系统（SS7）的综合业务数字网（ISDN）用户部分（ISUP）。在部分呼叫涉及与公共交换电话网（PSTN）互通的环境中使用SIP时，可以实现此机制。
Table of Contents
目录
1. Introduction............................................ 3
2. Scope................................................... 4
3. Terminology............................................. 5
4. Scenarios............................................... 5
5. SIP Mechanisms Required................................. 7
5.1 'Transparent' Transit of ISUP Messages.................. 7
5.2 Understanding MIME Multipart Bodies..................... 7
5.3 Transmission of DTMF Information........................ 8
5.4 Reliable Transmission of Provisional Responses.......... 8
5.5 Early Media............................................. 8
5.6 Mid-Call Transactions which do not change SIP state..... 9
1. Introduction............................................ 3
2. Scope................................................... 4
3. Terminology............................................. 5
4. Scenarios............................................... 5
5. SIP Mechanisms Required................................. 7
5.1 'Transparent' Transit of ISUP Messages.................. 7
5.2 Understanding MIME Multipart Bodies..................... 7
5.3 Transmission of DTMF Information........................ 8
5.4 Reliable Transmission of Provisional Responses.......... 8
5.5 Early Media............................................. 8
5.6 Mid-Call Transactions which do not change SIP state..... 9
5.7 Privacy Protection...................................... 9
5.8 CANCEL causes........................................... 10
6. Mapping................................................. 10
7. SIP to ISUP Mapping..................................... 11
7.1 SIP to ISUP Call flows.................................. 11
7.1.1 En-bloc Call Setup (no auto-answer)..................... 11
7.1.2 Auto-answer call setup.................................. 12
7.1.3 ISUP T7 Expires......................................... 13
7.1.4 SIP Timeout............................................. 14
7.1.5 ISUP Setup Failure...................................... 15
7.1.6 Cause Present in ACM Message............................ 16
7.1.7 Call Canceled by SIP.................................... 17
7.2 State Machine........................................... 18
7.2.1 INVITE received......................................... 19
7.2.1.1 INVITE to IAM procedures................................ 19
7.2.2 ISUP T7 expires......................................... 23
7.2.3 CANCEL or BYE received.................................. 23
7.2.4 REL received............................................ 24
7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24
7.2.5 Early ACM received...................................... 27
7.2.6 ACM received............................................ 27
7.2.7 CON or ANM Received..................................... 28
7.2.8 Timer T9 Expires........................................ 29
7.2.9 CPG Received............................................ 29
7.3 ACK received............................................ 30
8. ISUP to SIP Mapping..................................... 30
8.1 ISUP to SIP Call Flows.................................. 30
8.1.1 En-bloc call setup (non auto-answer).................... 31
8.1.2 Auto-answer call setup.................................. 32
8.1.3 SIP Timeout............................................. 33
8.1.4 ISUP T9 Expires......................................... 34
8.1.5 SIP Error Response...................................... 35
8.1.6 SIP Redirection......................................... 36
8.1.7 Call Canceled by ISUP................................... 37
8.2 State Machine........................................... 39
8.2.1 Initial Address Message received........................ 39
8.2.1.1 IAM to INVITE procedures................................ 40
8.2.2 100 received............................................ 41
8.2.3 18x received............................................ 41
8.2.4 2xx received............................................ 43
8.2.5 3xx Received............................................ 44
8.2.6 4xx-6xx Received........................................ 44
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45
8.2.7 REL Received............................................ 47
8.2.8 ISUP T11 Expires........................................ 47
9. Suspend/Resume and Hold................................. 48
9.1 SUS and RES............................................. 48
9.2 Hold (re-INVITE)........................................ 50
5.7 Privacy Protection...................................... 9
5.8 CANCEL causes........................................... 10
6. Mapping................................................. 10
7. SIP to ISUP Mapping..................................... 11
7.1 SIP to ISUP Call flows.................................. 11
7.1.1 En-bloc Call Setup (no auto-answer)..................... 11
7.1.2 Auto-answer call setup.................................. 12
7.1.3 ISUP T7 Expires......................................... 13
7.1.4 SIP Timeout............................................. 14
7.1.5 ISUP Setup Failure...................................... 15
7.1.6 Cause Present in ACM Message............................ 16
7.1.7 Call Canceled by SIP.................................... 17
7.2 State Machine........................................... 18
7.2.1 INVITE received......................................... 19
7.2.1.1 INVITE to IAM procedures................................ 19
7.2.2 ISUP T7 expires......................................... 23
7.2.3 CANCEL or BYE received.................................. 23
7.2.4 REL received............................................ 24
7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24
7.2.5 Early ACM received...................................... 27
7.2.6 ACM received............................................ 27
7.2.7 CON or ANM Received..................................... 28
7.2.8 Timer T9 Expires........................................ 29
7.2.9 CPG Received............................................ 29
7.3 ACK received............................................ 30
8. ISUP to SIP Mapping..................................... 30
8.1 ISUP to SIP Call Flows.................................. 30
8.1.1 En-bloc call setup (non auto-answer).................... 31
8.1.2 Auto-answer call setup.................................. 32
8.1.3 SIP Timeout............................................. 33
8.1.4 ISUP T9 Expires......................................... 34
8.1.5 SIP Error Response...................................... 35
8.1.6 SIP Redirection......................................... 36
8.1.7 Call Canceled by ISUP................................... 37
8.2 State Machine........................................... 39
8.2.1 Initial Address Message received........................ 39
8.2.1.1 IAM to INVITE procedures................................ 40
8.2.2 100 received............................................ 41
8.2.3 18x received............................................ 41
8.2.4 2xx received............................................ 43
8.2.5 3xx Received............................................ 44
8.2.6 4xx-6xx Received........................................ 44
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45
8.2.7 REL Received............................................ 47
8.2.8 ISUP T11 Expires........................................ 47
9. Suspend/Resume and Hold................................. 48
9.1 SUS and RES............................................. 48
9.2 Hold (re-INVITE)........................................ 50
10. Normal Release of the Connection........................ 50
10.1 SIP initiated release................................... 50
10.2 ISUP initiated release.................................. 51
10.2.1 Caller hangs up......................................... 51
10.2.2 Callee hangs up (SUS)................................... 52
11. ISUP Maintenance Messages............................... 52
11.1 Reset messages.......................................... 52
11.2 Blocking messages....................................... 53
11.3 Continuity Checks....................................... 53
12. Construction of Telephony URIs.......................... 54
12.1 ISUP format to tel URL mapping.......................... 56
12.2 tel URL to ISUP format mapping.......................... 57
13. Other ISUP flavors...................................... 58
13.1 Guidelines for sending other ISUP messages.............. 58
14. Acronyms................................................ 60
15. Security Considerations................................. 60
16. IANA Considerations..................................... 64
17. Acknowledgments......................................... 64
18. Normative References.................................... 64
19. Non-Normative References................................ 65
Authors' Addresses...................................... 67
Full Copyright Statement................................ 68
10. Normal Release of the Connection........................ 50
10.1 SIP initiated release................................... 50
10.2 ISUP initiated release.................................. 51
10.2.1 Caller hangs up......................................... 51
10.2.2 Callee hangs up (SUS)................................... 52
11. ISUP Maintenance Messages............................... 52
11.1 Reset messages.......................................... 52
11.2 Blocking messages....................................... 53
11.3 Continuity Checks....................................... 53
12. Construction of Telephony URIs.......................... 54
12.1 ISUP format to tel URL mapping.......................... 56
12.2 tel URL to ISUP format mapping.......................... 57
13. Other ISUP flavors...................................... 58
13.1 Guidelines for sending other ISUP messages.............. 58
14. Acronyms................................................ 60
15. Security Considerations................................. 60
16. IANA Considerations..................................... 64
17. Acknowledgments......................................... 64
18. Normative References.................................... 64
19. Non-Normative References................................ 65
Authors' Addresses...................................... 67
Full Copyright Statement................................ 68
SIP [1] is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP. Telephone calls are considered a type of multimedia sessions where just audio is exchanged.
SIP[1]是用于建立、终止和修改多媒体会话的应用层协议。它通常通过IP进行传输。电话通话被认为是一种仅交换音频的多媒体会话。
Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a level 4 protocol used in Signaling System No. 7 (SS7) networks. It typically runs over Message Transfer Part (MTP) although it can also run over IP (see SCTP [19]). ISUP is used for controlling telephone calls and for maintenance of the network (blocking circuits, resetting circuits etc.).
综合业务数字网（ISDN）用户部分（ISUP）[12]是7号信令系统（SS7）网络中使用的4级协议。它通常通过消息传输部分（MTP）运行，但也可以通过IP运行（参见SCTP[19]）。ISUP用于控制电话呼叫和维护网络（阻塞电路、复位电路等）。
A module performing the mapping between these two protocols is usually referred to as Media Gateway Controller (MGC), although the terms 'softswitch' or 'call agent' are also sometimes used. An MGC has logical interfaces facing both networks, the network carrying ISUP and the network carrying SIP. The MGC also has some capabilities for controlling the voice path; there is typically a Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public Switched Telephone Network - PSTN) and with IP interfaces (Voice over IP - VoIP). The MGC and the MG can be merged together in one physical box or kept separate.
执行这两个协议之间映射的模块通常称为媒体网关控制器（MGC），尽管有时也使用术语“软交换”或“呼叫代理”。MGC具有面向两个网络的逻辑接口，即承载ISUP的网络和承载SIP的网络。MGC还具有一些控制语音路径的能力；通常有一个媒体网关（MG），带有E1/T1中继接口（来自公共交换电话网-PSTN的语音）和IP接口（IP语音-VoIP）。MGC和MG可以合并在一个物理框中或保持分离。
These MGCs are frequently used to bridge SIP and ISUP networks so that calls originating in the PSTN can reach IP telephone endpoints and vice versa. This is useful for cases in which PSTN calls need to take advantage of services in IP world, in which IP networks are used as transit networks for PSTN-PSTN calls, architectures in which calls originate on desktop 'softphones' but terminate at PSTN terminals, and many other similar next-generation telephone architectures.
这些MGC经常用于连接SIP和ISUP网络，以便PSTN中发起的呼叫可以到达IP电话端点，反之亦然。这对于PSTN呼叫需要利用IP世界中的服务的情况非常有用，其中IP网络用作PSTN-PSTN呼叫的中转网络，呼叫在桌面“软电话”上发起但在PSTN终端终止的架构，以及许多其他类似的下一代电话架构。
This document describes logic and procedures which an MGC might use to implement the mapping between SIP and ISUP by illustrating the correspondences, at the message level and parameter level, between the protocols. It also describes the interplay between parallel state machines for these two protocols as a recommendation for implementers to synchronize protocol events in interworking architectures.
本文档通过说明协议之间在消息级和参数级的对应关系，描述了MGC可能用于实现SIP和ISUP之间映射的逻辑和过程。它还描述了这两个协议的并行状态机之间的相互作用，作为实现者在互通架构中同步协议事件的建议。
This document focuses on the translation of ISUP messages into SIP messages, and the mapping of ISUP parameters into SIP headers. For ISUP calls that traverse a SIP network, the purpose of translation is to allow SIP elements such as proxy servers (which do not typically understand ISUP) to make routing decisions based on ISUP criteria such as the called party number. This document consequently provides a SIP mapping only for those ISUP parameters which might be used by intermediaries in the routing of SIP requests. As a side effect of this approach, translation also increases the overall interoperability by providing critical information about the call to SIP endpoints that cannot understand encapsulated ISUP, or perhaps which merely cannot understand the particular ISUP variant encapsulated in a message.
本文档重点介绍ISUP消息到SIP消息的转换，以及ISUP参数到SIP头的映射。对于穿越SIP网络的ISUP呼叫，转换的目的是允许代理服务器（通常不理解ISUP）等SIP元素根据ISUP标准（如被叫方号码）做出路由决策。因此，本文档仅为中介机构在SIP请求路由中可能使用的那些ISUP参数提供SIP映射。作为这种方法的一个副作用，翻译还通过提供有关对SIP端点的调用的关键信息来提高总体互操作性，这些端点无法理解封装的ISUP，或者可能仅仅无法理解封装在消息中的特定ISUP变体。
This document also only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these messages neither have nor require any analog in SIP.
本文档还仅考虑了ISUP的调用功能。处理PSTN中继的维护消息仅在其影响对正在进行的呼叫的控制时进行处理；否则，这些消息在SIP中既没有也不需要任何模拟。
Messages indicating error or congestion situations in the PSTN (MTP-3) and the recovery mechanisms used such as User Part Available and User Part Test ISUP messages are outside the scope of this document
指示PSTN（MTP-3）中的错误或拥塞情况的消息以及所使用的恢复机制（如可用用户部件和用户部件测试ISUP消息）不在本文档的范围内
There are several flavors of ISUP. International Telecommunication Union Telecommunication Standardization Sector (ITU-T) International ISUP [12] is used through this document; some differences with the American National Standards Institute (ANSI) [11] ISUP and the Telecommunication Technology Committee (TTC) ISUP are also outlined. ITU-T ISUP is used in this document because it is the most widely known of all the ISUP flavors. Due to the small number of fields
ISUP有几种口味。本文件使用国际电信联盟电信标准化部门（ITU-T）国际ISUP[12]；还概述了与美国国家标准协会（ANSI）[11]ISUP和电信技术委员会（TTC）ISUP的一些差异。本文档中使用了ITU-T ISUP，因为它是所有ISUP风格中最广为人知的。由于字段数量较少
that map directly from ISUP to SIP, the signaling differences between ITU-T ISUP and specific national variants of ISUP will generally have little to no impact on the mapping. Note, however, that the ITU-T has not substantially standardized practices for Local Number Portability (LNP) since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. The number portability practices described in this document are presented as an optional mechanism.
从ISUP直接映射到SIP，ITU-T ISUP和ISUP的特定国家变体之间的信令差异通常对映射几乎没有影响。然而，请注意，ITU-T并未对本地号码可移植性（LNP）进行实质性的标准化实践，因为可移植性往往以国家编号计划实践为基础，因此LNP必须在几乎每个国家的基础上进行描述。本文档中描述的号码可移植性实践作为可选机制提供。
Mapping of SIP headers to ISUP parameters in this document focuses largely on the mapping between the parameters found in the ISUP Initial Address Message (IAM) and the headers associated with the SIP INVITE message; both of these messages are used in their respective protocols to request the establishment of a call. Once an INVITE has been sent for a particular session, such headers as the To and From field become essentially fixed, and no further translation will be required during subsequent signaling, which is routed in accordance with Via and Route headers. Hence, the problem of parameter-to-header mapping in SIP-T is confined more or less to the IAM and the INVITE. Some additional detail is given in the population of parameters in the ISUP messages Address Complete Message (ACM) and Release Message (REL) based on SIP status codes.
本文档中SIP头与ISUP参数的映射主要关注ISUP初始地址消息（IAM）中的参数与SIP INVITE消息相关头之间的映射；这两条消息在各自的协议中用于请求建立呼叫。一旦针对特定会话发送了INVITE，诸如To和From字段之类的报头基本上是固定的，并且在后续信令期间不需要进一步的转换，后续信令根据Via和Route报头进行路由。因此，SIP-T中的参数到报头映射问题或多或少局限于IAM和INVITE。在基于SIP状态代码的ISUP消息地址完整消息（ACM）和发布消息（REL）中的参数填充中给出了一些额外的细节。
This document describes when the media path associated with a SIP call is to be initialized, terminated, modified, etc., but it does not go into details such as how the initialization is performed or which protocols are used for that purpose.
本文档描述了与SIP呼叫相关联的媒体路径何时被初始化、终止、修改等，但没有详细说明如何执行初始化或为此目的使用了哪些协议。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照RFC2119[2]中的描述进行解释，并表示符合SIP实施的要求级别。
There are several scenarios where ISUP-SIP mapping takes place. The way the messages are generated is different depending on the scenario.
有几种情况下会发生ISUP-SIP映射。生成消息的方式因场景而异。
When there is a single MGC and the call is from a SIP phone to a PSTN phone, or vice versa, the MGC generates the ISUP messages based on the methods described in this document.
当存在单个MGC且呼叫从SIP电话到PSTN电话，或反之亦然时，MGC根据本文档中描述的方法生成ISUP消息。
+-------------+ +-----+ +-------------+
| PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
+-------------+ +-----+ +-------------+
+-------------+ +-----+ +-------------+
| PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
+-------------+ +-----+ +-------------+
The scenario where a call originates in the PSTN, goes into a SIP network and terminates in the PSTN again is known as "SIP bridging". SIP bridging should provide ISUP transparency between the PSTN switches handling the call. This is achieved by encapsulating the incoming ISUP messages in the body of the SIP messages (see [3]). In this case, the ISUP messages generated by the egress MGC are the ones present in the SIP body (possibly with some modifications; for example, if the called number in the request Uniform Resource Identifier - URI - is different from the one present in the ISUP due to SIP redirection, the ISUP message will need to be adjusted).
呼叫起源于PSTN、进入SIP网络并再次终止于PSTN的场景称为“SIP桥接”。SIP桥接应在处理呼叫的PSTN交换机之间提供ISUP透明度。这是通过将传入的ISUP消息封装在SIP消息体中实现的（请参见[3]）。在这种情况下，出口MGC生成的ISUP消息是SIP主体中存在的消息（可能经过一些修改；例如，如果由于SIP重定向，请求统一资源标识符URI中的被叫号码与ISUP中存在的号码不同，则需要调整ISUP消息）。
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+
SIP is used in the middle of both MGCs because the voice path has to be established through the IP network between both MGs; this structure also allows the call to take advantage of certain SIP services. ISUP messages in the SIP bodies provide further information (such as cause values and optional parameters) to the peer MGC.
SIP用于两个MGCs的中间，因为必须通过两个MGS之间的IP网络建立语音路径；此结构还允许调用利用某些SIP服务。SIP主体中的ISUP消息向对等MGC提供进一步的信息（例如原因值和可选参数）。
In both scenarios, the ingress MGC places the incoming ISUP messages in the SIP body by default. Note that this has security implications; see Section 15. If the recipient of these messages (typically a SIP User Agent Client/User Agent Server - UAC/UAS) does not understand them, a negotiation using the SIP 'Accept' and 'Require' headers will take place and they will not be included in the next SIP message exchange.
在这两种情况下，默认情况下，入口MGC将传入的ISUP消息放在SIP正文中。请注意，这具有安全影响；见第15节。如果这些消息的接收者（通常是SIP用户代理客户端/用户代理服务器-UAC/UAS）不理解它们，则将使用SIP“接受”和“要求”头进行协商，并且它们将不包括在下一次SIP消息交换中。
There can be a Signaling Gateway (SG) between the PSTN and the MGC. It encapsulates the ISUP messages over IP in a manner such as the one described in [19]. The mapping described in this document is not affected by the underlying transport protocol of ISUP.
PSTN和MGC之间可以有信令网关（SG）。它以[19]中所述的方式通过IP封装ISUP消息。本文档中描述的映射不受ISUP的底层传输协议的影响。
Note that overlap dialing mechanisms (use of the Subsequent Address Message - SAM) are outside the scope of this document. This document assumes that gateways facing ISUP networks in which overlap dialing is used will implement timers to insure that all digits have been collected before an INVITE is transmitted to a SIP network.
请注意，重叠拨号机制（使用后续地址消息-SAM）不在本文档的范围内。本文档假设面向使用重叠拨号的ISUP网络的网关将实现计时器，以确保在将INVITE传输到SIP网络之前已收集所有数字。
In some instances, gateways may receive incomplete ISUP messages which indicate message segmentation due to excessive message length. Commonly these messages will be followed by a Segmentation Message (SGM) containing the remainder of the original ISUP message. An incomplete message may not contain sufficient parameters to allow for a proper mapping to SIP; similarly, encapsulating (see below) an incomplete ISUP message may be confusing to terminating gateways. Consequently, a gateway MUST wait until a complete ISUP message is received (which may involve waiting until one or more SGMs arrive) before sending any corresponding INVITE.
在某些情况下，网关可能会接收不完整的ISUP消息，这些消息表示由于消息长度过长而导致的消息分段。通常，这些消息后面会有一条分段消息（SGM），其中包含原始ISUP消息的其余部分。不完整的消息可能不包含允许正确映射到SIP的足够参数；类似地，封装（见下文）不完整的ISUP消息可能会使终止网关感到困惑。因此，在发送任何相应的INVITE之前，网关必须等待直到收到完整的ISUP消息（可能需要等待一个或多个SGM到达）。
For a correct mapping between ISUP and SIP, some SIP mechanisms above and beyond those available in the base SIP specification are needed. These mechanisms are discussed below. If the SIP UAC/UAS involved in the call does not support them, it is still possible to proceed, but the behavior in the establishment of the call may be slightly different than that expected by the user (e.g., other party answers before receiving the ringback tone, user is not informed about the call being forwarded, etc.).
对于ISUP和SIP之间的正确映射，需要一些SIP机制，这些机制高于基本SIP规范中可用的机制。下文将讨论这些机制。如果呼叫中涉及的SIP UAC/UAS不支持它们，则仍然可以继续，但是呼叫建立中的行为可能与用户预期的行为略有不同（例如，在接收回铃音之前另一方应答，用户没有被告知正在转发呼叫等）。
To allow gateways to take advantage of the full range of services afforded by the existing telephone network when placing calls from PSTN to PSTN across a SIP network, SIP messages MUST be capable of transporting ISUP payloads from gateway to gateway. The format for encapsulating these ISUP messages is defined in [3].
为了允许网关在通过SIP网络从PSTN呼叫PSTN时利用现有电话网络提供的全部服务，SIP消息必须能够将ISUP有效负载从网关传输到网关。[3]中定义了封装这些ISUP消息的格式。
SIP user agents which do not understand ISUP are permitted to ignore these optional MIME bodies.
不理解ISUP的SIP用户代理可以忽略这些可选的MIME主体。
In most PSTN interworking situations, SIP message bodies will be required to carry session information (Session Description Protocol - SDP) in addition to ISUP and/or billing information.
在大多数PSTN互通情况下，除了ISUP和/或计费信息外，SIP消息体还需要携带会话信息（会话描述协议-SDP）。
PSTN interworking nodes MUST understand the MIME type of "multipart/mixed" as defined in RFC2046 [4]. Clients express support for this by including "multipart/mixed" in an "Accept" header.
PSTN互通节点必须理解RFC2046[4]中定义的“多部分/混合”MIME类型。客户端通过在“Accept”头中包含“multipart/mixed”来表示对此的支持。
How DTMF tones played by the user are transmitted by a gateway is completely orthogonal to how SIP and ISUP are interworked; however, as DTMF carriage is a component of a complete gatewaying solution some guidance is offered here.
用户播放的DTMF音调如何通过网关传输与SIP和ISUP的交互方式完全正交；然而，由于DTMF传输是完整网关解决方案的一个组成部分，因此这里提供了一些指导。
Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is desirable (since out-of-band transmission alone would provide many challenges for synchronization of the media stream for tone re-insertion). This transmission MAY be performed as described in RFC2833 [5].
由于选择用于语音传输的编解码器可能并不理想地适合于承载DTMF信息，因此需要在频带内传输该信息的符号方法（因为单独的带外传输将为用于音调重新插入的媒体流的同步提供许多挑战）。可以按照RFC2833[5]中的描述执行此传输。
Provisional responses (in the 1xx class) are used in the transmission of call progress information. PSTN interworking in particular relies on these messages for control of the media channel and timing of call events.
临时响应（1xx类）用于传输呼叫进度信息。PSTN互通尤其依赖于这些消息来控制媒体频道和呼叫事件的定时。
When interworking with the PSTN, SIP messages MUST be sent reliably end-to-end; reliability of requests is guaranteed by the base protocol. One application-layer provisional reliability mechanism for responses is described in [18].
当与PSTN互通时，SIP消息必须可靠地端到端发送；请求的可靠性由基本协议保证。[18]中描述了响应的一种应用层临时可靠性机制。
Early media denotes the capability to play media (audio for telephony) before a SIP session has been established (before a 2xx response code has been sent). For telephony, establishment of media in the backwards direction is desirable so that tones and announcements can be played, especially when interworking with a network that cannot signal call status out of band (such as a legacy MF network). In cases where interworking has not been encountered, use of early media is almost always undesirable since it consumes inter-machine trunk recourses to play media for which no revenue is collected. Note that since an INVITE almost always contains the SDP required to send media in the backwards direction, and requires that user agents prepare themselves to receive backwards media as soon as an INVITE transmitted, the baseline SIP protocol has enough support to enable rudimentary unidirectional early media systems. However, this mechanism has a number of limitations - for example, media streams offered in the SDP of the INVITE cannot be modified or declined, and bidirectional RTCP required for session maintenance cannot be established.
早期媒体表示在建立SIP会话之前（在发送2xx响应代码之前）播放媒体（电话音频）的能力。对于电话，需要在向后方向上建立媒体，以便可以播放铃声和公告，尤其是在与不能在带外发出呼叫状态信号的网络（如传统MF网络）互通时。在未遇到互通的情况下，使用早期媒体几乎总是不可取的，因为它会消耗机器间中继资源来播放没有收入的媒体。请注意，由于INVITE几乎总是包含向后发送媒体所需的SDP，并且要求用户代理在INVITE发送后立即准备接收向后的媒体，因此基线SIP协议具有足够的支持来支持基本的单向早期媒体系统。但是，该机制有许多限制-例如，无法修改或拒绝INVITE的SDP中提供的媒体流，并且无法建立会话维护所需的双向RTCP。
Therefore gateways MAY support more sophisticated early media systems as they come to be better understood. One mechanism that provides a way of initiating a fully-featured early media system is described in [20].
因此，网关可能支持更复杂的早期媒体系统，因为它们得到了更好的理解。[20]中描述了一种提供启动全功能早期媒体系统方法的机制。
Note that in SIP networks not just switches but also user agents can generate the 18x response codes and initiate early backwards media, and that therefore some gateways may wish to enforce policies that restrict the use of backwards media from arbitrary user agents (see Section 15).
请注意，在SIP网络中，不仅交换机，而且用户代理都可以生成18x响应码并启动早期向后介质，因此一些网关可能希望强制执行限制任意用户代理使用向后介质的策略（请参阅第15节）。
When interworking with the PSTN, there are situations when gateways will need to send messages to each other over SIP that do not correspond to any SIP operations.
当与PSTN互通时，存在网关需要通过SIP相互发送消息的情况，这些消息与任何SIP操作都不对应。
In support of mid-call transactions and other ISUP events that do not correspond to existing SIP methods, SIP gateways MUST support the INFO method, defined in RFC2976 [6]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits.
为了支持与现有SIP方法不对应的中间呼叫事务和其他ISUP事件，SIP网关必须支持RFC2976[6]中定义的INFO方法。请注意，本文件未规定或认可使用信息来携带DTMF数字。
Gateways MUST accept "405 Method Not Allowed" and "501 Not Implemented" as non-fatal responses to INFO requests - that is, any call in progress MUST NOT be torn down if a destination so rejects an INFO request sent by a gateway.
网关必须接受“405方法不允许”和“501未实现”作为对信息请求的非致命响应，也就是说，如果目的地拒绝网关发送的信息请求，则任何正在进行的调用都不得被中断。
ISUP has a concept of presentation restriction - a mechanism by which a user can specify that they would not like their telephone number to be displayed to the person they are calling (presumably someone with Caller ID). When a gateway receives an ISUP request that requires presentation restriction, it must therefore shield the identity of the caller in some fashion.
ISUP有一个表示限制的概念——一种机制，用户可以通过该机制指定他们不希望自己的电话号码显示给正在呼叫的人（可能是有来电ID的人）。当网关接收到需要表示限制的ISUP请求时，它必须以某种方式屏蔽调用者的身份。
The base SIP protocol supports a method of specifying that a user is anonymous. However, this system has a number of limitations - for example, it reveals the identity of the gateway itself, which could be a privacy-impacting disclosure. Therefore gateways MAY support more sophisticated privacy systems. One mechanism that provides a way of supporting fully-featured privacy negotiation (which interacts well with identity management systems) is described in [9B].
基本SIP协议支持指定用户匿名的方法。但是，该系统有一些限制-例如，它会显示网关本身的身份，这可能会影响隐私披露。因此，网关可能支持更复杂的隐私系统。[9B]中描述了一种机制，该机制提供了一种支持全功能隐私协商（与身份管理系统良好交互）的方法。
There is a way in ISUP to signal that you would like to discontinue an attempt to set up a call - the general-purpose REL is sent in the forwards direction. There is a similar concept in SIP - that of a CANCEL request that is sent in order to discontinue the establishment of a SIP dialog. For various reasons, however, CANCEL requests cannot contain message bodies, and therefore in order to carry the important information in the REL (the cause code) end-to-end in sip bridging cases, ISUP encapsulation cannot be used.
ISUP中有一种方法可以发出信号，表示您希望停止建立呼叫的尝试-通用REL以转发方向发送。SIP中有一个类似的概念，即发送取消请求以中断SIP对话的建立。然而，由于各种原因，取消请求不能包含消息体，因此，为了在sip桥接情况下端到端地传输REL（原因代码）中的重要信息，不能使用ISUP封装。
Ordinarily, this is not a big problem, because for practical purposes the only reason that a REL is ever issued to cancel a call setup attempt is that a user hangs up the phone while it is still ringing (which results in a "Normal clearing" cause code). However, under exceptional conditions, like catastrophic network failure, a REL may be sent with a different cause code, and it would be handy if a SIP network could carry the cause code end-to-end. Therefore gateways MAY support a mechanism for end-to-end delivery of such failure reasons. One mechanism that provides this capability is described in [9].
通常情况下，这不是一个大问题，因为出于实际目的，发出REL以取消呼叫设置尝试的唯一原因是用户在手机仍在响铃时挂断电话（这会导致“正常清除”原因代码）。然而，在异常情况下，如灾难性网络故障，可能会发送带有不同原因代码的REL，如果SIP网络可以端到端携带原因代码，则会很方便。因此，网关可能支持一种机制，用于端到端传递此类故障原因。[9]中描述了一种提供这种能力的机制。
The mapping between ISUP and SIP is described using call flow diagrams and state machines. One state machine handles calls from SIP to ISUP and the second from ISUP to SIP. There are details, such as some retransmissions and some states (waiting for the Release Complete Message - RLC, waiting for SIP ACK etc.), that are not shown in the figures in order to make them easier to follow.
ISUP和SIP之间的映射是使用调用流图和状态机描述的。一个状态机处理从SIP到ISUP的调用，第二个状态机处理从ISUP到SIP的调用。图中未显示一些细节，例如一些重传和一些状态（等待释放完成消息-RLC、等待SIP ACK等），以便更容易理解。
The boxes represent the different states of the gateway, and the arrows show changes in the state. The event that triggers the change in the state and the actions to take appear on the arrow: event / section describing the actions to take.
这些框表示网关的不同状态，箭头显示状态的变化。触发状态变化的事件和要采取的行动出现在描述要采取的行动的箭头：事件/部分上。
For example, 'INVITE / 7.2.1' indicates that an INVITE request has been received by the gateway, and the procedure upon reception is described in the section 7.2.1 of this document.
例如，“INVITE/7.2.1”表示网关已收到INVITE请求，本文件第7.2.1节描述了接收时的程序。
It is RECOMMENDED that gateways implement functional equivalence with the call flows detailed in Section 7.1 and Section 8.1. Deviations from these flows are permissible in support of national ISUP variants, or any of the conservative policies recommended in Section 15.
建议网关实现与第7.1节和第8.1节详述的调用流的功能等效。允许偏离这些流量，以支持国家ISUP变体或第15节中建议的任何保守政策。
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the SIP network. "100 Trying" acknowledgements to INVITE requests are not displayed below although they are required in many architectures.
以下调用流说明了在设置从SIP网络发起的调用时，在典型的成功和错误情况下的消息顺序。下面不显示邀请请求的“100次尝试”确认，尽管在许多体系结构中需要它们。
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG."
在这些图中，所有呼叫信令（SIP、ISUP）都将进出MGC；媒体处理（例如，音频直通、中继释放）由MG在MGC的控制下执行。为了简单起见，这些节点显示为单个节点，标记为“MGC/MG”
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。
3. The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message.
3. 远程ISUP节点通过发回ACM消息指示该地址足以建立呼叫。
4. The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 7.2.5 and Section 7.2.6) and returned to the SIP node. This response may contain SDP to establish an early media stream (as shown in the diagram). If no SDP is present, the audio will be established in both directions after step 8.
4. ACM消息中的“被叫方状态”代码映射到SIP临时响应（如第7.2.5节和第7.2.6节所述），并返回到SIP节点。此响应可能包含SDP以建立早期媒体流（如图所示）。如果不存在SDP，则在步骤8后将在两个方向上建立音频。
5. If the ISUP variant permits, the remote ISUP node may issue a variety of Call Progress (CPG) messages to indicate, for example, that the call is being forwarded.
5. 如果ISUP变体允许，远程ISUP节点可以发出各种呼叫进度（CPG）消息，以指示呼叫正在转发。
6. Upon receipt of a CPG message, the gateway will map the event code to a SIP provisional response (see Section 7.2.9) and send it to the SIP node.
6. 收到CPG消息后，网关将事件代码映射到SIP临时响应（参见第7.2.9节），并将其发送到SIP节点。
7. Once the PSTN user answers, an Answer (ANM) message will be sent to the gateway.
7. PSTN用户应答后，将向网关发送应答（ANM）消息。
8. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node.
8. 在接收到ANM后，网关将向SIP节点发送200消息。
9. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt.
9. SIP节点在接收到邀请最终响应（200）时，将发送ACK以确认接收。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
Note that this flow is not supported in ANSI networks.
请注意，ANSI网络不支持此流。
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。
3. Since the remote node is configured for automatic answering, it will send a Connect Message (CON) upon receipt of the IAM. (For ANSI, this message will be an ANM).
3. 由于远程节点配置为自动应答，因此它将在收到IAM后发送连接消息（CON）。（对于ANSI，此消息将是ANM）。
4. Upon receipt of the CON, the gateway will send a 200 message to the SIP node.
4. 在收到CON后，网关将向SIP节点发送200消息。
5. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt.
5. SIP节点在接收到邀请最终响应（200）时，将发送ACK以确认接收。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. The ISUP timer T7 is started at this point.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。此时启动ISUP定时器T7。
3. The ISUP timer T7 expires before receipt of an ACM or CON message, so a REL message is sent to cancel the call.
3. ISUP定时器T7在收到ACM或CON消息之前过期，因此发送REL消息以取消呼叫。
4. A gateway timeout message is sent back to the SIP node.
4. 网关超时消息被发送回SIP节点。
5. The SIP node, upon receiving an INVITE final response (504), will send an ACK to acknowledge receipt.
5. SIP节点在接收到邀请最终响应（504）时，将发送ACK以确认接收。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。
3. Since the remote node is configured for automatic answering, it will send a CON message upon receipt of the IAM. In ANSI flows, rather than a CON, an ANM (without ACM) would be sent.
3. 由于远程节点配置为自动应答，它将在收到IAM时发送CON消息。在ANSI流中，将发送ANM（不带ACM），而不是CON。
4. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node and set SIP timer T1.
4. 一旦接收到ANM，网关将向SIP节点发送200消息并设置SIP定时器T1。
5. The response is retransmitted every time the SIP timer T1 expires.
5. 每次SIP计时器T1过期时，都会重新传输响应。
6. After seven retransmissions, the call is torn down by sending a REL to the ISUP node, with a cause code of 102 (recover on timer expiry).
6. 在七次重传之后，通过向ISUP节点发送REL（原因代码为102）（计时器到期时恢复），取消呼叫。
7. A BYE is transmitted to the SIP node in an attempt to close the call. Further handling for this clean up is not shown, since the SIP node's state is not easily known in this scenario.
7. BYE被传输到SIP节点以尝试关闭呼叫。由于在此场景中不容易知道SIP节点的状态，因此未显示此清理的进一步处理。
8. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message.
8. 收到REL消息后，远程ISUP节点将用RLC消息进行回复。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。
3. Since the remote ISUP node is unable to complete the call, it will send a REL.
3. 由于远程ISUP节点无法完成呼叫，它将发送REL。
4. The gateway releases the circuit and confirms that it is available for reuse by sending an RLC.
4. 网关释放电路，并通过发送RLC确认其可重复使用。
5. The gateway translates the cause code in the REL to a SIP error response (see Section 7.2.4) and sends it to the SIP node.
5. 网关将REL中的原因代码转换为SIP错误响应（参见第7.2.4节），并将其发送到SIP节点。
6. The SIP node sends an ACK to acknowledge receipt of the INVITE final response.
6. SIP节点发送ACK以确认收到INVITE最终响应。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。
3. Since the ISUP node is unable to complete the call and wants to generate the error tone/announcement itself, it sends an ACM with a cause code. The gateway starts an interwork timer.
3. 由于ISUP节点无法完成呼叫，并且希望自己生成错误提示音/通告，因此它会发送一个带有原因代码的ACM。网关启动一个互通计时器。
4. Upon receipt of an ACM with cause (presence of the CAI parameter), the gateway will generate a 183 message towards the SIP node; this contains SDP to establish early media cut-through.
4. 在接收到带有原因的ACM（存在CAI参数）时，网关将生成朝向SIP节点的183消息；这包含用于建立早期介质直通的SDP。
5. A final INVITE response, based on the cause code received in the earlier ACM message, is generated and sent to the SIP node to terminate the call. See Section 7.2.4.1 for the table which contains the mapping from cause code to SIP response.
5. 根据先前ACM消息中接收到的原因码生成最终INVITE响应，并将其发送到SIP节点以终止呼叫。有关包含从原因代码到SIP响应的映射的表格，请参见第7.2.4.1节。
6. Upon expiration of the interwork timer, a REL is sent towards the PSTN node to terminate the call. Note that the SIP node can also terminate the call by sending a CANCEL before the interwork timer expires. In this case, the signaling progresses as in Section 7.1.7.
6. 在互通计时器到期时，向PSTN节点发送REL以终止呼叫。请注意，SIP节点还可以通过在互通计时器到期之前发送取消来终止呼叫。在这种情况下，信号发送按照第7.1.7节进行。
7. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message.
7. 收到REL消息后，远程ISUP节点将用RLC消息进行回复。
8. The SIP node sends an ACK to acknowledge receipt of the INVITE final response.
8. SIP节点发送ACK以确认收到INVITE最终响应。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. 当SIP用户希望开始与PSTN用户的会话时，SIP节点发出INVITE请求。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. 收到INVITE请求后，网关将其映射到IAM消息，并将其发送到ISUP网络。
3. The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message.
3. 远程ISUP节点通过发回ACM消息指示该地址足以建立呼叫。
4. The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 7.2.5 and Section 7.2.6) and returned to the SIP node. This response may contain SDP to establish an early media stream.
4. ACM消息中的“被叫方状态”代码映射到SIP临时响应（如第7.2.5节和第7.2.6节所述），并返回到SIP节点。该响应可以包含用于建立早期媒体流的SDP。
5. To cancel the call before it is answered, the SIP node sends a CANCEL request.
5. 为了在应答之前取消呼叫，SIP节点发送一个取消请求。
6. The CANCEL request is confirmed with a 200 response.
6. 取消请求得到200响应的确认。
7. Upon receipt of the CANCEL request, the gateway sends a REL message to terminate the ISUP call.
7. 收到取消请求后，网关发送REL消息以终止ISUP呼叫。
8. The gateway sends a "487 Call Cancelled" message to the SIP node to complete the INVITE transaction.
8. 网关向SIP节点发送“487呼叫取消”消息以完成INVITE事务。
9. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message.
9. 收到REL消息后，远程ISUP节点将用RLC消息进行回复。
10. Upon receipt of the 487, the SIP node will confirm reception with an ACK.
10. 在接收到487之后，SIP节点将使用ACK确认接收。
Note that REL can be received in any state; the handling is the same for each case (see Section 10).
注意，REL可以在任何状态下接收；每种情况的处理方法相同（见第10节）。
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
When an INVITE request is received by the gateway, a "100 Trying" response MAY be sent back to the SIP network indicating that the gateway is handling the call.
当网关接收到INVITE请求时，可以将“100尝试”响应发送回SIP网络，指示网关正在处理呼叫。
The necessary hardware resources for the media stream MUST be reserved in the gateway when the INVITE is received, since an IAM message cannot be sent before the resource reservation (especially TCIC selection) takes place. Typically the resources consist of a time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources might also include any quality-of-service provisions (although no such practices are recommended in this document).
接收到邀请时，必须在网关中保留媒体流所需的硬件资源，因为在资源保留（特别是TCIC选择）发生之前无法发送IAM消息。通常，资源包括E1/T1中的时隙和IP端的RTP/UDP端口。资源还可能包括任何服务质量规定（尽管本文件不建议采用此类做法）。
After sending the IAM the timer T7 is started. The default value of T7 is between 20 and 30 seconds. The gateway goes to the 'Trying' state.
发送IAM后，计时器T7启动。T7的默认值在20到30秒之间。网关进入“正在尝试”状态。
This section details the mapping of the SIP headers in an INVITE message to the ISUP parameters in an Initial Address Message (IAM). A PSTN-SIP gateway is responsible for creating an IAM when it receives an INVITE.
本节详细介绍INVITE消息中SIP头与初始地址消息（IAM）中ISUP参数的映射。PSTN-SIP网关负责在收到邀请时创建IAM。
Five mandatory parameters appear within the IAM message: the Called Party Number (CPN), the Nature of Connection Indicator (NCI), the Forward Call Indicators (FCI), the Calling Party's Category (CPC), and finally a parameter that indicates the desired bearer characteristics of the call - in some ISUP variants the Transmission Medium Requirement (TMR) is required, in others the User Service Information (USI) (or both). All IAM messages MUST contain these five parameters at a minimum. Thus, every gateway must have a means of populating each of those five parameters when an INVITE is received. Many of the values that will appear in these parameters (such as the NCI or USI) will most likely be the same for each IAM created by the gateway. Others (such as the CPN) will vary on a call-by-call basis; the gateway extracts information from the INVITE in order to properly populate these parameters.
IAM消息中出现五个强制性参数：被叫方号码（CPN）、连接指示器（NCI）的性质、前向呼叫指示器（FCI）、主叫方类别（CPC），最后是一个表示呼叫所需承载特征的参数——在某些ISUP变体中，是指传输介质要求（TMR）是必需的，在其他情况下，则需要用户服务信息（USI）（或两者都需要）。所有IAM消息必须至少包含这五个参数。因此，每个网关必须有一种在收到邀请时填充这五个参数中每一个参数的方法。这些参数中显示的许多值（如NCI或USI）对于网关创建的每个IAM，很可能是相同的。其他IAM（如CPN）将根据呼叫的不同而不同；网关从INVITE中提取信息，以便正确填充这些参数。
There are also quite a few optional parameters that can appear in an IAM message; Q.763 [17] lists 29 in all. However, each of these parameters need not to be translated in order to achieve the goals of SIP-ISUP mapping. As is stated above, translation allows SIP network elements to understand the basic PSTN context of the session (who it is for, and so on) if they are not capable of deciphering any encapsulated ISUP. Parameters that are only meaningful to the PSTN will be carried through PSTN-SIP- PSTN networks via encapsulation -
IAM消息中还可以显示许多可选参数；Q.763[17]共列出29项。然而，为了实现SIP-ISUP映射的目标，这些参数中的每一个都不需要转换。如上所述，如果SIP网元不能破译任何封装的ISUP，则转换允许SIP网元理解会话的基本PSTN上下文（为谁等）。仅对PSTN有意义的参数将通过封装通过PSTN-SIP-PSTN网络传输-
translation is not necessary for these parameters. Of the aforementioned 29 optional parameters, only the following are immediately useful for translation: the Calling Party's Number (CIN, which is commonly present), Transit Network Selection (TNS), Carrier Identification Parameter (CIP, present in ANSI networks), Original Called Number (OCN), and the Generic Digits (known in some variants as the Generic Address Parameter (GAP)).
这些参数不需要转换。在上述29个可选参数中，只有以下参数可立即用于翻译：主叫方号码（CIN，通常存在）、公交网络选择（TNS）、载波识别参数（CIP，在ANSI网络中存在）、原始被叫号码（OCN）和通用数字（在某些变体中称为通用地址参数（GAP））。
When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD attempt to make use of encapsulated ISUP (see [3]), if any, within the INVITE to assist in the formulation of outbound PSTN signaling, but SHOULD also heed the security considerations in Section 15. If possible, the gateway SHOULD reuse the values of each of the ISUP parameters of the encapsulated IAM as it formulates an IAM that it will send across its PSTN interface. In some cases, the gateway will be unable to make use of that ISUP - for example, if the gateway cannot understand the ISUP variant and must therefore ignore the encapsulated body. Even when there is comprehensible encapsulated ISUP, the relevant values of SIP header fields MUST 'overwrite' through the process of translation the parameter values that would have been set based on encapsulated ISUP. In other words, the updates to the critical session context parameters that are created in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases, over the encapsulated ISUP. This allows many basic services, including various sorts of call forwarding and redirection, to be implemented in the SIP network.
当SIP INVITE到达PSTN网关时，网关应尝试在INVITE内使用封装的ISUP（见[3]），如果有的话，以帮助制定出站PSTN信令，但也应注意第15节中的安全考虑。如有可能，网关在制定将通过其PSTN接口发送的IAM时，应重用封装IAM的每个ISUP参数的值。在某些情况下，网关将无法使用该ISUP—例如，如果网关无法理解ISUP变体，因此必须忽略封装体。即使存在可理解的封装ISUP，SIP头字段的相关值也必须通过转换过程“覆盖”基于封装ISUP设置的参数值。换句话说，在ISUP-SIP-ISUP桥接情况下，在SIP网络中创建的关键会话上下文参数的更新优先于封装的ISUP。这允许在SIP网络中实现许多基本服务，包括各种呼叫转发和重定向。
For example, if an INVITE arrives at a gateway with an encapsulated IAM with a CPN field indicating the telephone number +12025332699, but the Request-URI of the INVITE indicates 'tel:+15105550110', the gateway MUST use the telephone number in the Request-URI, rather than the one in the encapsulated IAM, when creating the IAM that the gateway will send to the PSTN. Further details of how SIP header fields are translated into ISUP parameters follow.
例如，如果INVITE到达带有封装IAM的网关，其中CPN字段指示电话号码+12025332699，但INVITE的请求URI指示“电话：+15105550110”，则网关必须使用请求URI中的电话号码，而不是封装IAM中的电话号码，创建网关将发送到PSTN的IAM时。下面将进一步详细介绍如何将SIP头字段转换为ISUP参数。
Gateways MUST be provisioned with default values for mandatory ISUP parameters that cannot be derived from translation(such as the NCI or TMR parameters) for those cases in which no encapsulated ISUP is present. The FCI parameter MUST also have a default, as only the 'M' bit of the default may be overwritten during the process of translation if the optional number portability translation mechanisms described below are used.
对于不存在封装ISUP的情况，必须为网关提供无法从转换中派生的强制ISUP参数（如NCI或TMR参数）的默认值。FCI参数还必须具有默认值，因为如果使用下面描述的可选数字可移植性转换机制，则在转换过程中，只有默认值的“M”位可能会被覆盖。
The first step in the translation of the fields of an INVITE message to the parameters of an IAM is the inspection of the Request-URI.
将INVITE消息的字段转换为IAM参数的第一步是检查请求URI。
If the optional number portability practices are supported by the gateway, then the following steps related to handling of the 'npdi' and 'rn' parameters of the Request-URI should be followed.
如果网关支持可选的号码可移植性实践，则应遵循以下与处理请求URI的“npdi”和“rn”参数相关的步骤。
If there is no 'npdi=yes' field within the Request-URI, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
如果请求URI中没有“npdi=yes”字段，则必须按照第12节中描述的步骤将tel URL中的主要电话号码（紧跟在“tel:”之后的数字）转换为ISUP格式，并用于填充CPN参数。
If the 'npdi=yes' field exists in the Request-URI, then the FCI parameter bit for 'number translated' within the IAM MUST reflect that a number portability dip has been performed.
如果请求URI中存在“npdi=yes”字段，则IAM中“数字转换”的FCI参数位必须反映已执行数字可移植性dip。
If in addition to the 'npdi=yes' field there is no 'rn=' field present, then the main telephone number in the tel URL MUST be converted to ISUP format (see Section 12) and used to populate the CPN parameter. This indicates that a portability dip took place, but that the called party's number was not ported.
如果除“npdi=yes”字段外，没有“rn=”字段，则必须将电话URL中的主电话号码转换为ISUP格式（参见第12节），并用于填充CPN参数。这表明发生了可移植性下降，但被叫方的号码未被移植。
If in addition to the 'npdi=yes' field an 'rn=' field is present, then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format and used to populate the CPN. The main telephone number in the tel URL MUST be converted to ISUP format and used to populate the Generic Digits Parameter (or GAP in ANSI). In some other ISUP variants, the number given in the 'rn=' field would instead be prepended to the main telephone number (with or without a prefix or separator) and the combined result MUST be used to populate the CPN. Once the 'rn=' and 'npdi=' parameters have been translation, the number portability translation practices are complete.
如果除“npdi=yes”字段外，还存在“rn=”字段，则在ANSI ISUP中，“rn=”字段必须转换为ISUP格式，并用于填充CPN。电话URL中的主电话号码必须转换为ISUP格式，并用于填充通用数字参数（或ANSI中的GAP）。在其他一些ISUP变体中，“rn=”字段中给出的号码将改为在主电话号码前加前缀（带或不带前缀或分隔符），组合结果必须用于填充CPN。一旦完成了“rn=”和“npdi=”参数的转换，号码可移植性转换实践就完成了。
The following mandatory translation practices are performed after number portability translations, if any.
以下强制翻译实践在可携带号码翻译（如有）后执行。
If number portability practices are not supported by the gateway, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
如果网关不支持号码可移植性实践，则必须按照第12节中描述的步骤将电话URL中的主要电话号码（紧跟在“tel:”之后的数字）转换为ISUP格式，并用于填充CPN参数。
If the primary telephone number in the Request-URI and that of the To header are at variance, then the To header SHOULD be used to populate an OCN parameter. Otherwise the To header SHOULD be ignored.
如果请求URI中的主电话号码与To标头中的主电话号码不一致，则应使用To标头填充OCN参数。否则，应忽略To标头。
Some optional translation procedures are provided for carrier-based routing. If the 'cic=' parameter is present in the Request-URI, the gateway SHOULD consult local policy to make sure that it is appropriate to transmit this Carrier Identification Code (CIC, not to
为基于载波的路由提供了一些可选的转换过程。如果请求URI中存在“cic=”参数，则网关应咨询本地策略，以确保适合传输此载波标识码（cic，而不是
be confused with the MTP3 'circuit identification code') in the IAM; if the gateway supports many independent trunks, it may need to choose a particular trunk that points to the carrier identified by the CIC, or a tandem through which that carrier is reachable. Policies for such trunks (based on the preferences of the carriers with which the trunks are associated and the ISUP variant in use) SHOULD dictate whether the CIP or TNS parameter is used to carry the CIC. In the absence of any pre-arranged policies, the TNS should be used when the CPN parameter is in an international format (i.e., the tel URL portion of the Request-URI is preceded by a '+', which will generate a CPN in international format), and (where supported) the CIP should be used in other cases.
与IAM中的MTP3“电路识别码”）混淆；如果网关支持多个独立的中继，则可能需要选择指向CIC标识的载波的特定中继，或者选择可通过其到达该载波的中继。此类中继的策略（基于与中继关联的运营商的偏好和使用中的ISUP变体）应规定是否使用CIP或TNS参数来承载CIC。在没有任何预先安排的策略的情况下，当CPN参数采用国际格式时，应使用TNS（即，请求URI的tel URL部分前面带有“+”，这将生成国际格式的CPN），并且（在支持的情况下）应在其他情况下使用CIP。
When a SIP call has been routed to a gateway, then the Request-URI will most likely contain a tel URL (or a SIP URI with a tel URL user portion) - SIP-ISUP gateways that receive Request-URIs that do not contain valid telephone numbers SHOULD reject such requests with an appropriate response code. Gateways SHOULD however continue to process requests with a From header field that does not contain a telephone number, as will sometimes be the case if a call originated at a SIP phone that employs a SIP URI user@host convention. The CIN parameter SHOULD be omitted from the outbound IAM if the From field is unusable. Note that as an alternative, gateway implementers MAY consider some non-standard way of mapping particular SIP URIs to telephone numbers.
当SIP呼叫被路由到网关时，请求URI很可能包含tel URL（或包含tel URL用户部分的SIP URI）-接收不包含有效电话号码的请求URI的SIP-ISUP网关应使用适当的响应代码拒绝此类请求。然而，网关应该继续处理带有From报头字段的请求，该字段不包含电话号码，如果呼叫是在使用SIP URI的SIP电话上发起的，则有时会出现这种情况user@host习俗如果from字段不可用，则应在出站IAM中省略CIN参数。注意，作为另一种选择，网关实现者可以考虑将特定SIP URI映射到电话号码的一些非标准方式。
When a gateway receives a message with (comprehensible) encapsulated ISUP, it MUST set the FCI indicator in the generated IAM so that all interworking-related bits have the same values as their counterparts in the encapsulated ISUP. In most cases, these indicators will state that no interworking was encountered, unless interworking has been encountered somewhere else in the call path. If usable encapsulated ISUP is not present in an INVITE received by the gateway, it is STRONGLY RECOMMENDED that the gateway set the Interworking Indicator bit of the FCI to 'no interworking' and the ISDN User Part Indicator to 'ISUP used all the way'; the gateway MAY also set the Originating Access indicator to 'Originating access non-ISDN' (generally, it is not safe to assume that SIP phones will support ISDN endpoint services, and the procedures in this document do not detail mappings to translate all such services).
当网关接收到带有（可理解的）封装ISUP的消息时，它必须在生成的IAM中设置FCI指示器，以便所有互通相关位与封装ISUP中的对应位具有相同的值。在大多数情况下，这些指示器将表明未遇到互通，除非在呼叫路径的其他地方遇到互通。如果网关接收到的INVITE中不存在可用的封装ISUP，强烈建议网关将FCI的互通指示符位设置为“无互通”，将ISDN用户部分指示符设置为“ISUP一直使用”；网关还可以将发起接入指示符设置为“发起接入非ISDN”（通常，假设SIP电话将支持ISDN端点服务是不安全的，并且本文档中的过程没有详细说明转换所有此类服务的映射）。
Note that when 'interworking encountered' is set in the FCI parameter of the IAM, this indicates that ISUP is interworking with a network which is not capable of providing as many services as ISUP does. ISUP networks will therefore not employ certain features they otherwise normally would, including potentially the use of ISDN cause codes in failure conditions (as opposed to sending ACMs followed by audible announcements). If desired, gateway vendors MAY provide a
请注意，如果在IAM的FCI参数中设置了“遇到互通”，则表示ISUP正在与一个网络互通，而该网络无法提供ISUP所能提供的服务数量。因此，ISUP网络不会采用某些通常会采用的功能，包括在故障情况下可能使用ISDN原因码（而不是在发出ACM后发出声音通知）。如果需要，网关供应商可以提供
configurable option, usable at the discretion of service providers, that will signal in the FCI that interworking has been encountered (and that ISUP is not used all the way) when encapsulated ISUP is not present; however, doing so may significantly limit the efficiency and transparency of SIP-ISUP translation.
可配置选项，可由服务提供商自行决定使用，当封装的ISUP不存在时，该选项将在FCI中发出信号，表示遇到了互通（并且ISUP没有一直使用）；然而，这样做可能会大大限制SIP-ISUP翻译的效率和透明度。
Claiming to be an ISDN node might make the callee request ISDN user to user services. Since user to user services 1 and 2 must be requested by the caller, they do not represent a problem (see [14]). User to user service 3 can be requested by the callee also. In non-SIP bridging situations, the MGC should be capable of rejecting this service request.
声称是ISDN节点可能会使被叫方请求ISDN用户对用户服务。由于用户对用户服务1和2必须由调用方请求，因此它们并不代表问题（请参见[14]）。被叫方也可以请求用户对用户服务3。在非SIP桥接情况下，MGC应该能够拒绝此服务请求。
Since no response was received from the PSTN all the resources in the MG are released. A '504 Server Timeout' SHOULD be sent back to the SIP network. A REL message with cause value 102 (protocol error, recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can expect the PSTN to respond with RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
由于没有收到来自PSTN的响应，MG中的所有资源都被释放。“504服务器超时”应发送回SIP网络。应向PSTN发送原因值为102（协议错误、计时器到期时恢复）的REL消息。网关可以期望PSTN使用RLC进行响应，而SIP网络使用ACK进行响应，ACK指示释放序列已经完成。
If a CANCEL or BYE request is received before a final SIP response has been sent, a '200 OK' MUST be sent to the SIP network to confirm the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE transaction. All the resources are released and a REL message SHOULD be sent to the PSTN with cause value 16 (normal clearing). Gateways can expect an RLC from the PSTN to be received indicating that the release sequence is complete.
如果在发送最终SIP响应之前收到取消或BYE请求，则必须向SIP网络发送“200 OK”以确认取消或BYE；还必须发送487以终止INVITE事务。释放所有资源，并向PSTN发送原因值为16（正常清除）的REL消息。网关可以期望从PSTN接收RLC，指示释放序列已完成。
In SIP bridging situations, a REL might be encapsulated in the body of a BYE request. Although BYE is usually mapped to cause code 16 (normal clearing), under exceptional circumstances the cause code in the REL message might be different. Therefore the Cause Indicator parameter of the encapsulated REL should be re-used in the REL sent to the PSTN.
在SIP桥接情况下，REL可能封装在BYE请求的主体中。虽然BYE通常映射到原因代码16（正常清除），但在特殊情况下，REL消息中的原因代码可能不同。因此，封装的REL的原因指示器参数应在发送到PSTN的REL中重新使用。
Note that a BYE or CANCEL request may contain a Reason header that SHOULD be mapped to the Cause Indicator parameter (see Section 5.8). If a BYE contains both a Reason header and encapsulated ISUP, the value in the Reason header MUST be preferred.
请注意，BYE或CANCEL请求可能包含应映射到原因指示器参数的原因标头（请参阅第5.8节）。如果BYE同时包含原因标头和封装的ISUP，则必须首选原因标头中的值。
All the resources in the gateway SHOULD be released before the gateway sends any REL message.
在网关发送任何REL消息之前，应释放网关中的所有资源。
This section applies when a REL is received before a final SIP response has been sent. Typically, this condition arises when a call has been rejected by the PSTN.
当在发送最终SIP响应之前收到REL时，本节适用。通常，当PSTN拒绝呼叫时，会出现这种情况。
Any gateway resources SHOULD be released immediately and an RLC MUST be sent to the ISUP network to indicate that the circuit is available for reuse.
应立即释放任何网关资源，并且必须向ISUP网络发送RLC，以表明电路可重复使用。
If the INVITE that originated this transaction contained a legitimate and comprehensible encapsulated ISUP message (i.e., an IAM using a variant supported by the gateway, preferably with a digital signature), then encapsulated ISUP SHOULD be sent in the response to the INVITE when possible (since this suggests an ISUP-SIP-ISUP bridging case) - therefore, the REL message just received SHOULD be included in the body of the SIP response. The gateway SHOULD NOT return a response with encapsulated ISUP if the originator of the INVITE did not enclose ISUP itself.
如果发起此事务的INVITE包含合法且可理解的封装ISUP消息（即，使用网关支持的变体的IAM，最好带有数字签名），则应尽可能在对INVITE的响应中发送封装ISUP（因为这表明ISUP-SIP-ISUP桥接情况）-因此，刚刚收到的REL消息应包含在SIP响应的主体中。如果邀请的发起人没有将ISUP本身封装起来，则网关不应返回带有封装ISUP的响应。
Note that the receipt of certain maintenance messages in response to IAM such as Blocking Message (BLO) or Reset Message (RSC) (or their circuit group message equivalents) may also result in the teardown of calls in this phase of the state machine. Behavior for maintenance messages is given below in Section 11.
请注意，接收到响应IAM的某些维护消息，如阻塞消息（BLO）或重置消息（RSC）（或其电路组消息等效项）也可能导致在状态机的此阶段中取消调用。第11节给出了维护消息的行为。
The use of the REL message in the SS7 network is very general, whereas SIP has a number of specific tools that, collectively, play the same role as REL - namely BYE, CANCEL, and the various status/response codes. An REL can be sent to tear down a call that is already in progress (BYE), to cancel a previously sent call setup request that has not yet been completed (CANCEL), or to reject a call setup request (IAM) that has just been received (corresponding to a SIP status code).
在SS7网络中，REL消息的使用非常普遍，而SIP有许多特定的工具，它们共同发挥与REL相同的作用，即BYE、CANCEL和各种状态/响应代码。可以发送REL来中断正在进行的呼叫（BYE），取消之前发送的尚未完成的呼叫设置请求（cancel），或拒绝刚刚收到的呼叫设置请求（IAM）（对应于SIP状态码）。
Note that it is not necessarily appropriate to map some ISDN cause codes to SIP messages because these cause codes are only meaningful to the ISUP interface of a gateway. A good example of this is cause code 44 "Request circuit or channel not available." 44 signifies that the CIC for which an IAM had been sent was believed by the receiving equipment to be in a state incompatible with a new call request - however, the appropriate behavior in this case is for the originating switch to re-send the IAM for a different CIC, not for the call to be torn down. Clearly, there is not (nor should there be) an SIP status code indicating that a new CIC should be selected - this matter is internal to the originating gateway. Hence receipt of cause code 44
请注意，将某些ISDN原因代码映射到SIP消息并不一定合适，因为这些原因代码仅对网关的ISUP接口有意义。一个很好的例子是原因代码44“请求电路或信道不可用”。44表示接收设备认为已为其发送IAM的CIC处于与新呼叫请求不兼容的状态-但是，在这种情况下，适当的行为是发起交换机为不同的CIC重新发送IAM，而不是中断呼叫。显然，没有（也不应该有）SIP状态代码指示应选择新的CIC——这是发起网关的内部问题。因此收到原因代码44
should not result in any SIP status code being sent; effectively, the cause code is untranslatable.
不应导致发送任何SIP状态代码；实际上，原因代码是不可翻译的。
If a cause value other than those listed below is received, the default response '500 Server internal error' SHOULD be used.
如果收到的原因值不是下面列出的，则应使用默认响应“500服务器内部错误”。
Finally, in addition to the ISDN Cause Code, the CAI parameter also contains a cause 'location' that gives some sense of which entity in the network was responsible for terminating the call (the most important distinction being between the user and the network). In most cases, the cause location does not affect the mapping to a SIP status code; some exceptions are noted below. A diagnostic field may also be present for some ISDN causes; this diagnostic will contain additional data pertaining to the termination of the call.
最后，除了ISDN原因代码外，CAI参数还包含一个原因“位置”，它给出了网络中哪个实体负责终止呼叫的某种意义（最重要的区别在于用户和网络之间）。在大多数情况下，原因位置不影响到SIP状态代码的映射；下文指出了一些例外情况。对于某些ISDN原因，也可能存在诊断字段；此诊断将包含与呼叫终止相关的附加数据。
The following mapping values are RECOMMENDED:
建议使用以下映射值：
Normal event
正常事件
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing --- (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing --- (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable
(*) ISDN Cause 16 will usually result in a BYE or CANCEL
（*）ISDN原因16通常会导致BYE或CANCEL
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603)
（+）如果原因位置为“用户”，则可以给出6xx代码而不是4xx代码（即403变为603）
(=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 'misrouted ported number'. Presumably, a number portability dip should have been performed by a prior network. Otherwise cause 26 is usually not used in ISUP procedures.
（=）ANSI过程-在ANSI网络中，26被重载以表示“错误路由的端口号”。据推测，号码可移植性dip应该由先前的网络执行。否则，ISUP程序中通常不使用原因26。
A REL with ISDN cause 22 (number changed) might contain information about a new number where the callee might be reachable in the diagnostic field. If the MGC is able to process this information it SHOULD be added to the SIP response (301) in a Contact header.
ISDN原因为22（号码已更改）的REL可能包含有关新号码的信息，在诊断字段中可以联系到被叫方。如果MGC能够处理此信息，则应将其添加到联系人报头中的SIP响应（301）。
Resource unavailable
资源不可用
This kind of cause value indicates a temporary failure. A 'Retry-After' header MAY be added to the response if appropriate.
此类原因值表示临时故障。如果合适，可以在响应中添加“重试后”标题。
ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
47 resource unavailable 503 Service unavailable
ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
47 resource unavailable 503 Service unavailable
Service or option not available
服务或选项不可用
This kind of cause value indicates that there is a problem with the request, rather than something that will resolve itself over time.
这种原因值表示请求存在问题，而不是随着时间的推移自行解决的问题。
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
available
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
available
Service or option not available
服务或选项不可用
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 488 Not Acceptable Here
70 only restricted digital avail 488 Not Acceptable Here
79 service or option not implemented 501 Not implemented
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 488 Not Acceptable Here
70 only restricted digital avail 488 Not Acceptable Here
79 service or option not implemented 501 Not implemented
Invalid message
无效消息
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 403 Forbidden
88 incompatible destination 503 Service unavailable
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 403 Forbidden
88 incompatible destination 503 Service unavailable
Protocol error
协议错误
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 504 Gateway timeout
111 protocol error 500 Server internal error
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 504 Gateway timeout
111 protocol error 500 Server internal error
Interworking
互通
ISUP Cause value SIP response
---------------- ------------
127 interworking unspecified 500 Server internal error
ISUP Cause value SIP response
---------------- ------------
127 interworking unspecified 500 Server internal error
An ACM message is sent in certain situations to indicate that the call is in progress in order to satisfy ISUP timers, rather than to signify that the callee is being alerted. This occurs for example in mobile networks, where roaming can delay call setup significantly. The early ACM is sent before the user is alerted to reset T7 and start T9. An ACM is considered an 'early ACM' if the Called Party's Status Indicator is set to 00 (no indication).
在某些情况下会发送ACM消息，以指示呼叫正在进行，以满足ISUP计时器的要求，而不是表示被呼叫方正在收到警报。例如，在移动网络中，漫游会显著延迟呼叫设置。在提醒用户重置T7和启动T9之前，发送早期ACM。如果被叫方的状态指示器设置为00（无指示），则ACM被视为“早期ACM”。
After sending an early ACM, the ISUP network can be expected to indicate the further progress of the call by sending CPGs.
在发送早期ACM后，ISUP网络可以通过发送CPG指示呼叫的进一步进展。
When an early ACM is received the gateway SHOULD send a 183 Session Progress response (see [1]) to the SIP network. In SIP bridging situations (where encapsulated ISUP was contained in the INVITE that initiated this call) the early ACM SHOULD also be included in the response body.
当收到早期ACM时，网关应向SIP网络发送183会话进度响应（参见[1]）。在SIP桥接情况下（启动此调用的INVITE中包含封装的ISUP），早期ACM也应包含在响应主体中。
Note that sending 183 before a gateway has confirmation that the address is complete (ACM) creates known problems in SIP bridging cases, and it SHOULD NOT therefore be sent.
请注意，在网关确认地址完整（ACM）之前发送183会在SIP桥接情况下产生已知问题，因此不应发送183。
Most commonly, on receipt of an ACM a provisional response (in the 18x class) SHOULD be sent to the SIP network. If the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP, then the ACM received by the gateway SHOULD be encapsulated in the provisional response.
最常见的是，在收到ACM时，应向SIP网络发送临时响应（在18x类中）。如果发起此会话的INVITE包含合法且可理解的封装ISUP，则网关接收的ACM应封装在临时响应中。
If the ACM contains a Backward Call Indicators parameter with a value of 'subscriber free', the gateway SHOULD send a '180 Ringing' response. When a 180 is sent, it is assumed, in the absence of any early media extension, that any necessary ringback tones will be
如果ACM包含值为“用户空闲”的反向呼叫指示器参数，则网关应发送“180振铃”响应。当发送180时，假设在没有任何早期媒体分机的情况下，将发送任何必要的回铃音
generated locally by the SIP user agent to which the gateway is responding (which may in turn be a gateway).
由网关响应的SIP用户代理本地生成（可能是网关）。
If the Backward Call Indicators (BCI) parameter of the ACM indicates that interworking has been encountered (generally designating that the ISUP network sending the ACM is interworking with a less sophisticated network which cannot report its status via out-of-band signaling), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message, and if possible a backwards media transmission SHOULD be initiated. Backwards media SHOULD also be transmitted if the Optional Backward Call Indicators parameter field for in-band media is set. For more information on early media (before 200 OK/ANM) see Section 5.5. After early media transmission has been initiated, the gateway SHOULD send a 183 Session Progress response code.
如果ACM的反向呼叫指示灯（BCI）参数指示遇到了互通（通常表示发送ACM的ISUP网络正在与不太复杂的网络互通，该网络无法通过带外信令报告其状态），然后，可能会有呼叫状态的带内通知，如可听到的忙音或呼叫者截获消息，如果可能，应启动反向媒体传输。如果设置了带内介质的可选向后呼叫指示器参数字段，则也应传输向后介质。有关早期介质（200 OK/ANM之前）的更多信息，请参见第5.5节。在启动早期媒体传输后，网关应发送183会话进度响应代码。
Gateways MAY have some means of ascertaining the disposition of in-band audio media; for example, a way of determining by inspecting signaling in some ISUP variants, or by listening to the audio, that ringing, or a busy tone, is being played over the circuit. Such gateways MAY elect to discard the media and send the corresponding response code (such as 180 or 486) in its stead. However, the implementation of such a gateway would entail overcoming a number of known challenges that are outside the scope of this document.
网关可能有一些确定带内音频媒体配置的方法；例如，一种通过检查某些ISUP变体中的信令或通过收听音频来确定是否正在通过电路播放铃声或忙音的方法。这样的网关可以选择丢弃介质并发送相应的响应代码（例如180或486）来代替介质。然而，实施这样一个网关将需要克服本文件范围之外的一些已知挑战。
When they receive an ACM, switches in many ISUP networks start a timer known as "T9" which usually lasts between 90 seconds and 3 minutes (see [13]). When early media is being played, this timer permits the caller to hear backwards audio media (in the form ringback, tones or announcements) from a remote switch in the ISUP network for that period of time without incurring any charge for the connection. The nearest possible local ISUP exchange to the callee generates the ringback tone or voice announcements. If longer announcements have to be played, the network has to send an ANM, which initiates bidirectional media of indefinite duration. In common ISUP network practice, billing commences when the ANM is received. Some networks do not support timer T9.
当收到ACM时，许多ISUP网络中的交换机会启动一个称为“T9”的计时器，该计时器通常持续90秒到3分钟（参见[13]）。播放早期媒体时，此计时器允许呼叫者在该时间段内从ISUP网络中的远程交换机向后收听音频媒体（以振铃、铃声或公告的形式），而无需为此连接支付任何费用。离被叫方最近的本地ISUP交换机生成回铃音或语音通知。如果必须播放更长的广播，网络必须发送一个ANM，该ANM启动无限期的双向媒体。在常见的ISUP网络实践中，在收到ANM时开始计费。某些网络不支持计时器T9。
When an ANM or CON message is received, the call has been answered and thus '200 OK' response SHOULD be sent to the SIP network. This 200 OK SHOULD contain an answer to the media offered in the INVITE. In SIP bridging situations (when the INVITE that initiated this call contained legitimate and comprehensible encapsulated ISUP), the ISUP message is included in the body of the 200 OK response. If it has not done so already, the gateway MUST establish a bidirectional media stream at this time.
当收到ANM或CON消息时，呼叫已被应答，因此“200 OK”响应应发送到SIP网络。此200 OK应包含对邀请中提供的媒体的回答。在SIP桥接情况下（当发起此呼叫的INVITE包含合法且可理解的封装ISUP时），ISUP消息包含在200 OK响应的主体中。如果尚未这样做，网关此时必须建立双向媒体流。
When there is interworking with some legacy networks, it is possible for an ISUP switch to receive an ANM immediately after an early ACM (without CPG or any other backwards messaging), or without receiving any ACM at all (when an automaton answers the call). In this situation the SIP user will never have received a 18x provisional response, and consequently they will not hear any kind of ringtone before the callee answers. This may result in some clipping of the initial forward media from the caller (since forward media transmission cannot commence until SDP has been acquired from the destination). In ISDN (see [12]) this is solved by connecting the voice path backwards before sending the IAM.
当与某些传统网络互通时，ISUP交换机有可能在早期ACM之后立即接收ANM（无CPG或任何其他反向消息），或者根本不接收任何ACM（当自动机应答呼叫时）。在这种情况下，SIP用户永远不会收到18倍的临时响应，因此在被叫方应答之前，他们不会听到任何类型的铃声。这可能导致来自调用者的初始前向媒体的一些剪辑（因为在从目的地获取SDP之前，前向媒体传输无法开始）。在ISDN（见[12]）中，这是通过在发送IAM之前向后连接语音路径来解决的。
The expiry of this timer (which is not used in all networks) signifies that an ANM has not arrived a significant period of time after alerting began (with the transmission of an ACM) for this call. Usually, this means that the callee's terminal has been alerted for many rings but has not been answered. It may also occur in interworking cases when the network is playing a status announcement (such as one indicating that a number is not in service) that has cycled several times. Whatever the cause of the protracted incomplete call, when this timer expires the call MUST be released. All of the gateway resources related to the media path SHOULD be released. A '480 Temporarily Unavailable' response code SHOULD be sent to the SIP network, and an REL message with cause value 19 (no answer from the user) SHOULD be sent to the ISUP network. The PSTN can be expected to respond with an RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
此计时器的到期（并非在所有网络中都使用）表示ANM在开始（通过传输ACM）此呼叫发出警报后未到达有效时间段。通常情况下，这意味着被叫方的终端已收到许多铃声的警报，但尚未应答。当网络播放已循环多次的状态公告（如指示某个号码不在服务中的公告）时，在互通情况下也可能发生这种情况。无论长时间不完整调用的原因是什么，当计时器过期时，必须释放调用。应释放与媒体路径相关的所有网关资源。应向SIP网络发送“480暂时不可用”响应代码，并向ISUP网络发送原因值为19（用户无应答）的REL消息。可以期望PSTN使用RLC进行响应，并且SIP网络使用指示释放序列已经完成的ACK进行响应。
A CPG is a provisional message that can indicate progress, alerting or in-band information. If a CPG suggests that in-band information is available, the gateway SHOULD begin to transmit early media and cut through the unidirectional backwards media path.
CPG是一种临时消息，可以指示进度、警报或带内信息。如果CPG建议带内信息可用，网关应开始传输早期媒体，并切断单向向后媒体路径。
In SIP bridging situations (when the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP), the CPG SHOULD be sent in the body of a particular 18x response, determined from the CPG Event Code as follows:
在SIP桥接情况下（当发起此会话的INVITE包含合法且可理解的封装ISUP时），应在特定18x响应的正文中发送CPG，根据CPG事件代码确定，如下所示：
ISUP event code SIP response
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Session progress
3 In-band information 183 Session progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Session progress
ISUP event code SIP response
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Session progress
3 In-band information 183 Session progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Session progress
Note that if the CPG does not indicate "Alerting," the current state will not change.
请注意，如果CPG未指示“警报”，则当前状态不会改变。
At this stage, the call is fully connected and the conversation can take place. No ISUP message should be sent by the gateway when an ACK is received.
在此阶段，电话已完全连接，可以进行对话。收到ACK时，网关不应发送ISUP消息。
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the PSTN network. "100 Trying" acknowledgements to INVITE requests are not depicted, since their presence is optional.
以下呼叫流说明了在设置从PSTN网络发起的呼叫时，在典型的成功和错误情况下的消息顺序。没有描述邀请请求的“100次尝试”确认，因为它们的存在是可选的。
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG".
在这些图中，所有呼叫信令（SIP、ISUP）都将进出MGC；媒体处理（例如，音频直通、中继释放）由MG在MGC的控制下执行。为了简单起见，这些节点显示为单个节点，标记为“MGC/MG”。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------ACK------------| |
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node.
2. 收到IAM消息后，网关生成INVITE消息，并将其发送到适当的SIP节点。
3. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.
3. 当表示呼叫具有足够的寻址信息的事件发生时，SIP节点将生成180或更大的临时响应。
4. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message. If the response is not 180, the ACM will carry a "called party status" value of "no indication."
4. 在收到180或更大的临时响应后，网关将生成ACM消息。如果响应不是180，ACM将带有“被叫方状态”值“无指示”
5. The SIP node may use further provisional messages to indicate session progress.
5. SIP节点可以使用进一步的临时消息来指示会话进度。
6. After an ACM has been sent, all provisional responses will translate into ISUP CPG messages as indicated in Section 8.2.3.
6. 发送ACM后，所有临时响应将转换为ISUP CPG消息，如第8.2.3节所示。
7. When the SIP node answers the call, it will send a 200 OK message.
7. 当SIP节点应答呼叫时，它将发送200OK消息。
8. Upon receipt of the 200 OK message, the gateway will send an ANM message towards the ISUP node.
8. 收到200 OK消息后，网关将向ISUP节点发送一条ANM消息。
9. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
9. 网关将向SIP节点发送ACK，以确认收到INVITE最终响应。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message and sends it to an appropriate SIP node based on called number analysis.
2. 收到IAM消息后，网关生成INVITE消息，并基于被叫号码分析将其发送到适当的SIP节点。
3. Since the SIP node is set up to automatically answer the call, it will send a 200 OK message.
3. 由于SIP节点被设置为自动应答呼叫，因此它将发送200 OK消息。
4. Upon receipt of the 200 OK message, the gateway will send a CON message towards the ISUP node.
4. 收到200 OK消息后，网关将向ISUP节点发送CON消息。
5. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
5. 网关将向SIP节点发送ACK，以确认收到INVITE最终响应。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
6|<--------CANCEL-----------| |
| |<-----------RLC-----------|7
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
6|<--------CANCEL-----------| |
| |<-----------RLC-----------|7
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis. The ISUP timer T11 and SIP timer T1 are set at this time.
2. 收到IAM消息后，网关生成INVITE消息，并基于被叫号码分析将其发送到适当的SIP节点。此时设置ISUP定时器T11和SIP定时器T1。
3. The INVITE message will continue to be sent to the SIP node each time the timer T1 expires. The SIP standard specifies that INVITE transmission will be performed 7 times if no response is received.
3. 每次计时器T1过期时，INVITE消息将继续发送到SIP节点。SIP标准规定，如果没有收到响应，INVITE传输将执行7次。
4. When T11 expires, an ACM message will be sent to the ISUP node to prevent the call from being torn down by the remote node's ISUP T7. This ACM contains a 'Called Party Status' value of 'no indication.'
4. T11过期时，将向ISUP节点发送ACM消息，以防止远程节点的ISUP T7中断呼叫。此ACM包含“被叫方状态”值“无指示”
5. Once the maximum number of INVITE requests has been sent, the gateway will send a REL (cause code 18) to the ISUP node to terminate the call.
5. 一旦发送了最大数量的INVITE请求，网关将向ISUP节点发送REL（原因代码18）以终止呼叫。
6. The gateway also sends a CANCEL message to the SIP node to terminate any initiation attempts.
6. 网关还向SIP节点发送取消消息，以终止任何启动尝试。
7. Upon receipt of the REL, the remote ISUP node will send an RLC to acknowledge.
7. 收到REL后，远程ISUP节点将发送RLC进行确认。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis. The ISUP timer T11 and SIP timer T1 are set at this time.
2. 收到IAM消息后，网关生成INVITE消息，并基于被叫号码分析将其发送到适当的SIP节点。此时设置ISUP定时器T11和SIP定时器T1。
3. The INVITE message will continue to be sent to the SIP node each time the timer T1 expires. The SIP standard specifies that INVITE transmission will be performed 7 times if no response is received. Since SIP T1 starts at 1/2 second or more and doubles each time it is retransmitted, it will be at least a minute before SIP times out the INVITE request; since SIP T1 is allowed to be larger than 500 ms initially, it is possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP T9.
3. 每次计时器T1过期时，INVITE消息将继续发送到SIP节点。SIP标准规定，如果没有收到响应，INVITE传输将执行7次。由于SIP T1以1/2秒或更长时间开始，并且每次重新传输时加倍，因此在SIP超时INVITE请求之前至少需要一分钟；由于最初允许SIP T1大于500 ms，因此7 x SIP T1可能比ISUP T11+ISUP T9长。
4. When T11 expires, an ACM message will be sent to the ISUP node to prevent the call from being torn down by the remote node's ISUP T7. This ACM contains a 'Called Party Status' value of 'no indication.'
4. T11过期时，将向ISUP节点发送ACM消息，以防止远程节点的ISUP T7中断呼叫。此ACM包含“被叫方状态”值“无指示”
5. When ISUP T9 in the remote PSTN node expires, it will send a REL.
5. 当远程PSTN节点中的ISUP T9过期时，它将发送REL。
6. Upon receipt of the REL, the gateway will send an RLC to acknowledge.
6. 收到REL后，网关将发送RLC进行确认。
7. The REL will trigger a CANCEL request, which gets sent to the SIP node.
7. REL将触发一个取消请求，该请求将被发送到SIP节点。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.
2. 收到IAM消息后，网关生成INVITE消息，并基于被叫号码分析将其发送到适当的SIP节点。
3. The SIP node indicates an error condition by replying with a response with a code of 400 or greater.
3. SIP节点通过使用代码为400或更高的响应进行响应来指示错误状况。
4. The gateway sends an ACK message to acknowledge receipt of the INVITE final response.
4. 网关发送ACK消息以确认收到INVITE最终响应。
5. An ISUP REL message is generated from the SIP code, as specified in Section 8.2.6.1.
5. 根据第8.2.6.1节的规定，从SIP代码生成ISUP REL消息。
6. The remote ISUP node confirms receipt of the REL message with an RLC message.
6. 远程ISUP节点用RLC消息确认收到REL消息。
SIP node 1 MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP node 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------ACK------------| |
SIP node 1 MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP node 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.
2. 收到IAM消息后，网关生成INVITE消息，并基于被叫号码分析将其发送到适当的SIP节点。
3. The SIP node indicates that the resource which the user is attempting to contact is at a different location by sending a 3xx message. In this instance we assume the Contact URL specifies a valid URL reachable by a VoIP SIP call.
3. SIP节点通过发送3xx消息指示用户试图联系的资源位于不同的位置。在本例中，我们假设联系人URL指定了VoIP SIP呼叫可以访问的有效URL。
4. The gateway sends a CPG with event indication that the call is being forwarded upon receipt of the 3xx message. Note that this translation should be able to be disabled by configuration, as some ISUP nodes do not support receipt of CPG messages before ACM messages.
4. 网关发送一个CPG，带有事件指示，表明在收到3xx消息后呼叫正在转发。请注意，此转换应该能够通过配置禁用，因为某些ISUP节点不支持在ACM消息之前接收CPG消息。
5. The gateway acknowledges receipt of the INVITE final response by sending an ACK message to the SIP node.
5. 网关通过向SIP节点发送ACK消息来确认收到INVITE最终响应。
6. The gateway re-sends the INVITE message to the address indicated in the Contact: field of the 3xx message.
6. 网关将INVITE消息重新发送到3xx消息的联系人：字段中指示的地址。
7. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.
7. 当表示呼叫具有足够的寻址信息的事件发生时，SIP节点将生成180或更大的临时响应。
8. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message with an event code as indicated in Section 8.2.3.
8. 在收到180或更大的临时响应后，网关将生成一条ACM消息，其中包含第8.2.3节所述的事件代码。
9. When the SIP node answers the call, it will send a 200 OK message.
9. 当SIP节点应答呼叫时，它将发送200OK消息。
10. Upon receipt of the 200 OK message, the gateway will send an ANM message towards the ISUP node.
10. 收到200 OK消息后，网关将向ISUP节点发送一条ANM消息。
11. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
11. 网关将向SIP节点发送ACK，以确认收到INVITE最终响应。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. 当PSTN用户希望开始与SIP用户的会话时，PSTN网络生成朝向网关的IAM消息。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.
2. 收到IAM消息后，网关生成INVITE消息，并基于被叫号码分析将其发送到适当的SIP节点。
3. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.
3. 当表示呼叫具有足够的寻址信息的事件发生时，SIP节点将生成180或更大的临时响应。
4. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message with an event code as indicated in Section 8.2.3.
4. 在收到180或更大的临时响应后，网关将生成一条ACM消息，其中包含第8.2.3节所述的事件代码。
5. If the calling party hangs up before the SIP node answers the call, a REL message will be generated.
5. 如果呼叫方在SIP节点应答呼叫之前挂断，将生成REL消息。
6. The gateway frees the PSTN circuit and indicates that it is available for reuse by sending an RLC.
6. 网关释放PSTN电路，并通过发送RLC指示其可重复使用。
7. Upon receipt of a REL message before an INVITE final response, the gateway will send a CANCEL towards the SIP node.
7. 在INVITE最终响应之前收到REL消息后，网关将向SIP节点发送取消。
8. Upon receipt of the CANCEL, the SIP node will send a 200 response.
8. 收到取消后，SIP节点将发送200响应。
9. The remote SIP node will send a "487 Call Cancelled" to complete the INVITE transaction.
9. 远程SIP节点将发送“487呼叫取消”以完成INVITE事务。
10. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
10. 网关将向SIP节点发送ACK，以确认收到INVITE最终响应。
Note that REL may arrive in any state. Whenever this occurs, the actions in section Section 8.2.7. are taken. Not all of these transitions are shown in this diagram.
请注意，REL可以在任何状态下到达。每当发生这种情况时，应执行第8.2.7节中的操作。他们被带走了。并非所有这些转换都显示在此图中。
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | IAM/7.2.1 |
| V |
| REL/7.2.7 +-------------------------+ 400+/7.2.6 |
+<----------------+ Trying |------------>|
| +-+--------+------+-------+ |
| | | | |
| | T11/ | 18x/ | 200/ |
| | 7.2.8 |7.2.3 | 7.2.4 |
| V | | |
| REL/7.2.7 +--------------+ | | 400+/7.2.6 |
|<----------| Progressing |-|------|-------------------->|
| +--+----+------+ | | |
| | | | | |
| 200/ | | 18x/ | | |
| 7.2.4 | | 7.2.3 | | |
| | V V | |
| REL/7.2.7 | +---------------+ | 400+/7.2.6 |
|<-------------|--| Alerting |-|-------------------->|
| | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.2.4 | |
| V V V |
| BYE/9.1 +-----------------------------+ REL/9.2 |
+<------------+ Connected +------------>+
+-----------------------------+
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | IAM/7.2.1 |
| V |
| REL/7.2.7 +-------------------------+ 400+/7.2.6 |
+<----------------+ Trying |------------>|
| +-+--------+------+-------+ |
| | | | |
| | T11/ | 18x/ | 200/ |
| | 7.2.8 |7.2.3 | 7.2.4 |
| V | | |
| REL/7.2.7 +--------------+ | | 400+/7.2.6 |
|<----------| Progressing |-|------|-------------------->|
| +--+----+------+ | | |
| | | | | |
| 200/ | | 18x/ | | |
| 7.2.4 | | 7.2.3 | | |
| | V V | |
| REL/7.2.7 | +---------------+ | 400+/7.2.6 |
|<-------------|--| Alerting |-|-------------------->|
| | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.2.4 | |
| V V V |
| BYE/9.1 +-----------------------------+ REL/9.2 |
+<------------+ Connected +------------>+
+-----------------------------+
Upon receipt of an IAM, the gateway SHOULD reserve appropriate internal resources (Digital Signal Processors - DSPs - and the like) necessary for handling the IP side of the call. It MAY make any necessary preparations to connect audio in the backwards direction (towards the caller).
收到IAM后，网关应保留处理呼叫IP端所需的适当内部资源（数字信号处理器-DSP-等）。它可以做任何必要的准备，以向后（朝向呼叫者）连接音频。
When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message MUST be created for transmission to the SIP network. This section details the process by which a gateway populates the fields of the INVITE based on parameters found within the IAM.
当IAM到达PSTN-SIP网关时，必须创建SIP INVITE消息以传输到SIP网络。本节详细介绍网关根据IAM中的参数填充INVITE字段的过程。
The context of the call setup request read by the gateway in the IAM will be mapped primarily to two URIs in the INVITE, one representing the originator of the session and the other its destination. The former will always appear in the From header (after it has been converted from ISUP format by the procedure described in Section 12), and the latter is almost always used for both the To header and the Request-URI.
IAM中网关读取的呼叫设置请求的上下文将主要映射到INVITE中的两个URI，一个表示会话的发起人，另一个表示会话的目的地。前者将始终出现在From头中（通过第12节中描述的过程将其从ISUP格式转换后），而后者几乎总是用于To头和请求URI。
Once the address of the called party number has been read from the IAM, it SHOULD be translated into a destination tel URL that will serve as the Request-URI of the INVITE. Alternatively, a gateway MAY first attempt a Telephone Number Mapping (ENUM) [8] query to resolve the called party number to a URI. Some additional ISUP fields MAY be added to the tel URL after translation has been completed, namely:
从IAM读取被叫方号码的地址后，应将其转换为目标电话URL，该URL将用作邀请的请求URI。或者，网关可以首先尝试电话号码映射（ENUM）[8]查询，以将被叫方号码解析为URI。翻译完成后，一些额外的ISUP字段可能会添加到tel URL中，即：
o If the gateway supports carrier-based routing (which is optional in this specification), it SHOULD ascertain if either the CIP (in ANSI networks) or TNS parameter is present in the IAM. If a value is present, the CIC SHOULD be extracted from the given parameter and analyzed by the gateway. A 'cic=' field with the value of the CIC SHOULD be appended to the destination tel URL, if doing so is in keeping with local policy (i.e., provided that the CIC does not indicate the network which owns the gateway or some similar condition). Note that if it is created, the 'cic=' parameter MUST be prefixed with the country code used or implied in the called party number, so that CIC '5062' becomes, in the United States, '+1-5062'. For further information on the 'cic=' tel URL field see [21].
o 如果网关支持基于载波的路由（在本规范中是可选的），则应确定IAM中是否存在CIP（在ANSI网络中）或TNS参数。如果存在值，则应从给定参数中提取CIC，并由网关进行分析。如果符合本地政策（即，前提是cic不指示拥有网关的网络或某些类似条件），则应将带有cic值的“cic=”字段附加到目标tel URL。请注意，如果创建了“cic=”参数，则必须使用被叫方号码中使用或隐含的国家代码作为前缀，以便cic“5062”在美国变为“+1-5062”。有关“cic=”电话URL字段的更多信息，请参见[21]。
o If the gateway supports number portability-based routing (which is optional in this specification), then the gateway will need to look at a few other fields. To correctly map the FCI 'number translated' bit indicating that an LNP dip had been performed in the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL. If a GAP is present in the IAM, then the contents of the CPN (the Location Routing Number - LRN) SHOULD be translated from ISUP format (as described in Section 12) and copied into an 'rn=' field which must be appended to the tel URL, whereas the GAP itself should be translated to ISUP format and used to populate the primary telephone number field of the tel URL. Note that in some national numbering plans, both the LRN and the dialed number may
o 如果网关支持基于号码可移植性的路由（这在本规范中是可选的），那么网关将需要查看一些其他字段。要正确映射FCI“数字转换”位，指示PSTN中已执行LNP dip，应在tel URL后附加“npdi=yes”字段。如果IAM中存在间隙，则应将CPN（位置路由号码-LRN）的内容从ISUP格式（如第12节所述）转换为“rn=”字段，该字段必须附加到tel URL中，而GAP本身应转换为ISUP格式，并用于填充电话URL的主电话号码字段。请注意，在一些国家编号计划中，LRN和已拨号码都可能
be stored in the CPN parameter, in which case they must be separated out into different fields to be stored in the tel URL. Note that LRNs are necessarily national in scope, and consequently they MUST NOT be preceded by a '+' in the 'rn=' field. For further information on these tel URL fields see [21].
存储在CPN参数中，在这种情况下，必须将它们分隔为不同的字段以存储在tel URL中。请注意，LRN的范围必须是全国性的，因此在“rn=”字段中，LRN的前面不能有“+”。有关这些电话URL字段的更多信息，请参见[21]。
In most cases, the resulting destination tel URL SHOULD be used in both the To field and Request-URI sent by the gateway. However, if the OCN parameter is present in the IAM, the To field SHOULD be constructed from the translation (from ISUP format following Section 12 of the OCN parameter, and hence the Request-URI and To field MAY be different.
在大多数情况下，生成的目的地tel URL应同时用于To字段和网关发送的请求URI。但是，如果IAM中存在OCN参数，则To字段应根据OCN参数第12节之后的翻译（从ISUP格式）构造，因此请求URI和To字段可能不同。
The construction of the From header field is dependent on the presence of a CIN parameter. If the CIN is not present, then the gateway SHOULD create a dummy From header field containing a SIP URI without a user portion which communicates only the hostname of the gateway (e.g., 'sip:gw.sipcarrier.com). If the CIN is available, then it SHOULD be translated (in accordance with the procedure described above) into a tel URL which should populate the From header field. In either case, local policy or requests for presentation restriction (see Section 12.1) MAY result in a different value for the From header field.
From标头字段的构造取决于CIN参数的存在。如果CIN不存在，则网关应创建一个包含SIP URI的虚拟自报头字段，其中不包含仅通信网关主机名的用户部分（例如，“SIP:gw.sipcharrier.com”）。如果CIN可用，则应将其翻译（按照上述步骤）为tel URL，该URL应填充From标头字段。在任何一种情况下，本地策略或表示限制请求（请参阅第12.1节）都可能导致From标头字段的值不同。
A 100 response SHOULD NOT trigger any PSTN interworking messages; it only serves the purpose of suppressing INVITE retransmissions.
100响应不应触发任何PSTN互通消息；它仅用于抑制邀请重传的目的。
Upon receipt of a 18x provisional response, if no ACM has been sent and no legitimate and comprehensible ISUP is present in the 18x message body, then the ISUP message SHOULD be generated according to the following table. Note that if an early ACM is sent, the call MUST enter state "Progressing" instead of state "Alerting."
收到18x临时响应后，如果未发送ACM，且18x消息正文中不存在合法且可理解的ISUP，则应根据下表生成ISUP消息。请注意，如果发送了早期ACM，则呼叫必须进入“进行中”状态，而不是“警报”状态
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing ACM (BCI = subscriber free)
181 Call is being forwarded Early ACM and CPG, event=6
182 Queued ACM (BCI = no indication)
183 Session progress message ACM (BCI = no indication)
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing ACM (BCI = subscriber free)
181 Call is being forwarded Early ACM and CPG, event=6
182 Queued ACM (BCI = no indication)
183 Session progress message ACM (BCI = no indication)
If an ACM has already been sent and no ISUP is present in the 18x message body, an ISUP message SHOULD be generated according to the following table.
如果已发送ACM，但18x消息正文中不存在ISUP，则应根据下表生成ISUP消息。
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing CPG, event = 1 (Alerting)
181 Call is being forwarded CPG, event = 6 (Forwarding)
182 Queued CPG, event = 2 (Progress)
183 Session progress message CPG, event = 2 (Progress)
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing CPG, event = 1 (Alerting)
181 Call is being forwarded CPG, event = 6 (Forwarding)
182 Queued CPG, event = 2 (Progress)
183 Session progress message CPG, event = 2 (Progress)
Upon receipt of a 180 response, the gateway SHOULD generate the ringback tone to be heard by the caller on the PSTN side (unless the gateway knows that ringback will be provided by the network on the PSTN side).
收到180响应后，网关应生成PSTN侧呼叫者可听到的回铃音（除非网关知道PSTN侧网络将提供回铃）。
Note however that a gateway might receive media at any time after it has transmitted an SDP offer that it has sent in an INVITE, even before a 18x provisional response is received. Therefore the gateway MUST be prepared to play this media to the caller on the PSTN side (if necessary, ceasing any ringback tone that it may have begun to generate and then playing media). Note that the gateway may also receive SDP offers in responses for an early media session using some SIP extension, see Section 5.5. If a gateway receives a 183 response while it is playing backwards media, then when it generates a mapping for this response, if no encapsulated ISUP is present, the gateway SHOULD indicate that in-band information is available (for example, with the Event Information parameter of the CPG message or the Optional Backward Call Indicators parameter of the ACM).
但是请注意，网关可能在发送了在INVITE中发送的SDP要约后的任何时间接收媒体，甚至在接收到18倍的临时响应之前。因此，网关必须准备好向PSTN侧的呼叫者播放该媒体（如有必要，停止其可能已开始生成的任何回铃音，然后播放媒体）。请注意，网关还可以使用一些SIP扩展接收SDP提供，以响应早期媒体会话，请参阅第5.5节。如果网关在向后播放媒体时收到183响应，则当它生成此响应的映射时，如果不存在封装的ISUP，则网关应指示带内信息可用（例如，使用CPG消息的事件信息参数或ACM的可选向后调用指示器参数）。
When an ACM is sent, the mandatory Backward Call Indicators parameter must be set, as well as any optional parameters as gateway policy dictates. If legitimate and comprehensible ISUP is present in the 18x response, the gateway SHOULD re-use the appropriate parameters of the ISUP message contained in the response body, including the value of the Backward Call Indicator parameter, as it formulates a message that it will send across its PSTN interface. In the absence of a usable encapsulated ACM, the BCI parameter SHOULD be set as follows:
发送ACM时，必须设置强制向后呼叫指示器参数，以及网关策略规定的任何可选参数。如果18x响应中存在合法且可理解的ISUP，则网关应重新使用响应正文中包含的ISUP消息的适当参数，包括反向呼叫指示符参数的值，因为它制定了将通过其PSTN接口发送的消息。如果没有可用的封装ACM，BCI参数应设置如下：
Message type: ACM
消息类型：ACM
Backward Call Indicators Charge indicator: 10 charge Called party's status indicator: 01 subscriber free or 00 no indication Called party's category indicator: 01 ordinary subscriber End-to-end method indicator: 00 no end-to-end method Interworking indicator: 0 no interworking End-to-end information indicator: 0 no end-to-end info ISDN user part indicator: 1 ISUP used all the way Holding indicator: 0 no holding ISDN access indicator: 0 No ISDN access Echo control device indicator: It depends on the call SCCP method indicator: 00 no indication
反向呼叫指示符计费指示符：10计费被叫方状态指示符：01用户空闲或00无指示被叫方类别指示符：01普通用户端到端方式指示符：00无端到端方式互通指示符：0无互通端到端信息指示符：0无端到端信息ISDN用户部分指示器：1 ISUP一直使用保持指示器：0无保持ISDN接入指示器：0无ISDN接入回声控制设备指示器：取决于呼叫SCCP方法指示器：00无指示
Note that when the ISUP Backward Call Indicator parameter Interworking indicator field is set to 'interworking encountered', this indicates that ISDN is interworking with a network which is not capable of providing as many services as ISDN does. ISUP therefore may not employ certain features it otherwise normally uses. Gateway vendors MAY however provide a configurable option, usable at the discretion of service providers when they require additional ISUP services, that in the absence of encapsulated ISUP will signal in the BCI that interworking has been encountered, and that ISUP is not used all the way, for those operators that as a matter of policy would rather operate in this mode. For more information on the effects of interworking see Section 7.2.1.1.
请注意，当ISUP向后呼叫指示符参数Interworking Indicator字段设置为“Interworking Incometed”时，这表示ISDN正在与一个不能提供ISDN所能提供的服务数量的网络互通。因此，ISUP可能不会采用它通常使用的某些功能。然而，网关供应商可提供一个可配置选项，当服务供应商需要额外的ISUP服务时，可由其自行决定使用该选项，在没有封装ISUP的情况下，该选项将在BCI中发出信号，表示遇到了互通，并且ISUP不会一直使用，对于政策上更愿意以这种模式运营的运营商。有关互通影响的更多信息，请参见第7.2.1.1节。
Response received Message sent by the MGC
----------------- -----------------------
200 OK ANM, ACK
Response received Message sent by the MGC
----------------- -----------------------
200 OK ANM, ACK
After receiving a 200 OK response the gateway MUST establish a directional media path in the gateway and send an ANM to the PSTN as well as an ACK to the SIP network.
在收到200 OK响应后，网关必须在网关中建立定向媒体路径，并向PSTN发送ANM以及向SIP网络发送ACK。
If the 200 OK response arrives before the gateway has sent an ACM, a CON is sent instead of the ANM, in those ISUP variants that support the CON message.
如果200 OK响应在网关发送ACM之前到达，则在支持CON消息的ISUP变体中，会发送CON而不是ANM。
When a legitimate and comprehensible ANM is encapsulated in the 200 OK response, the gateway SHOULD re-use any relevant ISUP parameters in the ANM it sends to the PSTN.
当合法且可理解的ANM封装在200 OK响应中时，网关应重新使用其发送到PSTN的ANM中的任何相关ISUP参数。
Note that gateways may sometimes receive 200 OK responses for requests other than INVITE (for example, those used in managing provisional responses, or the INFO method). The procedures described in this section apply only to 200 OK responses received as a result of sending an INVITE. The gateway SHOULD NOT send any PSTN messages if it receives a 200 OK in response to non-INVITE requests it has sent.
请注意，网关有时可能会收到200个OK响应，用于除INVITE之外的请求（例如，用于管理临时响应或INFO方法的请求）。本节中描述的过程仅适用于发送邀请后收到的200个OK响应。如果网关收到200 OK以响应其发送的非邀请请求，则不应发送任何PSTN消息。
When any 3xx response (a redirection) is received, the gateway SHOULD try to reach the destination by sending one or more new call setup requests using URIs found in any Contact header field(s) present in the response, as is mandated in the base SIP specification. Such 3xx responses are typically sent by a redirect server, and can be thought of as similar to a location register in mobile PSTN networks.
当收到任何3xx响应（重定向）时，网关应按照基本SIP规范的规定，使用响应中存在的任何联系人标头字段中的URI发送一个或多个新呼叫设置请求，尝试到达目的地。这种3xx响应通常由重定向服务器发送，可以认为类似于移动PSTN网络中的位置寄存器。
If a particular URI presented in the Contact header of a 3xx is best reachable (according to the gateway's routing policies) via the PSTN, the gateway SHOULD send a new IAM and from that moment on act as a normal PSTN switch (no SIP involved) - usually this will be the case when the URI in the Contact header is a tel URL, one that the gateway cannot reach locally and one for which there is no ENUM mapping.
如果通过PSTN（根据网关的路由策略）可以最好地访问3xx的联系人报头中显示的特定URI，则网关应发送一个新IAM，并从那时起充当正常PSTN交换机（不涉及SIP）-通常情况下，联系人报头中的URI是tel URL，网关无法在本地访问的一个和没有枚举映射的一个。
Alternatively, the gateway MAY send a REL message to the PSTN with a redirection indicator (23) and a diagnostic field corresponding to the telephone number in the URI. If, however, the new location is best reachable using SIP (if the URI in the Contact header contains no telephone number at all), the MGC SHOULD send a new INVITE with a Request-URI possibly a new IAM generated by the MGC in the message body.
或者，网关可以向PSTN发送具有重定向指示符（23）和与URI中的电话号码对应的诊断字段的REL消息。但是，如果使用SIP可以最好地访问新位置（如果联系人标头中的URI根本不包含电话号码），则MGC应发送一个新的INVITE，其中包含一个请求URI，可能是消息正文中MGC生成的新IAM。
While it is exploring a long list of Contact header fields with SIP requests, a gateway MAY send a CPG message with an event code of 6 (Forwarding) to the PSTN in order to indicate that the call is proceeding (where permitted by the ISUP variant in question).
当网关正在使用SIP请求浏览一长串联系人报头字段时，它可以向PSTN发送事件代码为6（转发）的CPG消息，以指示呼叫正在进行（在所讨论的ISUP变体允许的情况下）。
All redirection situations have to be treated very carefully because they involved special charging situations. In PSTN the caller typically pays for the first leg (to the gateway) and the callee pays the second (from the forwarding switch to the destination).
必须非常小心地处理所有重定向情况，因为它们涉及特殊充电情况。在PSTN中，呼叫者通常支付第一段（到网关），被呼叫者支付第二段（从转发交换机到目的地）。
When a response code of 400 or greater is received by the gateway, then the INVITE previously sent by the gateway has been rejected. Under most circumstances the gateway SHOULD release the resources in the gateway, send a REL to the PSTN with a cause value and send an
当网关接收到400或更高的响应代码时，网关先前发送的INVITE已被拒绝。在大多数情况下，网关应释放网关中的资源，向PSTN发送带有原因值的REL，并发送
ACK to the SIP network. Some specific circumstances are identified below in which a gateway MAY attempt to rectify a SIP-specific problem communicated by a status code without releasing the call by retrying the request. When a REL is sent to the PSTN, the gateway expects the arrival of an RLC indicating that the release sequence is complete.
确认SIP网络。下面确定了一些特定情况，其中网关可以尝试纠正由状态代码通信的SIP特定问题，而不通过重试请求来释放呼叫。当向PSTN发送REL时，网关期望RLC的到来，指示释放序列已完成。
When a REL message is generated due to a SIP rejection response that contains an encapsulated REL message, the Cause Indicator (CAI) parameter in the generated REL SHOULD be set to the value of the CAI parameter received in the encapsulated REL. If no encapsulated ISUP is present, the mapping below between status code and cause codes are RECOMMENDED.
当由于包含封装的REL消息的SIP拒绝响应而生成REL消息时，生成的REL中的原因指示器（CAI）参数应设置为封装的REL中接收的CAI参数的值。如果不存在封装的ISUP，建议使用以下状态代码和原因代码之间的映射。
Any SIP status codes not listed below (associated with SIP extensions, versions of SIP subsequent to the issue of this document, or simply omitted) should be mapping to cause code 31 "Normal, unspecified". These mappings cover only responses; note that the BYE and CANCEL requests, which are also used to tear down a dialog, SHOULD be mapped to 16 "Normal clearing" under most circumstances (although see Section 5.8).
下面未列出的任何SIP状态代码（与SIP扩展、本文件发布后的SIP版本相关，或仅略去）应映射为代码31“正常，未指定”。这些映射只包括响应；请注意，BYE和CANCEL请求（也用于中断对话框）在大多数情况下应映射为16“正常清除”（尽管参见第5.8节）。
By default, the cause location associated with the CAI parameter should be encoded such that 6xx codes are given the location 'user', whereas 4xx and 5xx codes are given a 'network' location. Exceptions are marked below.
默认情况下，应编码与CAI参数相关的原因位置，以便6xx代码被指定为位置“用户”，而4xx和5xx代码被指定为“网络”位置。例外情况如下所示。
Just as there are certain ISDN cause codes that are ISUP-specific and have no corollary SIP action, so there are SIP status codes that should not simply be translated to ISUP - some SIP-specific action should be attempted first. See the note on the (+) tag below.
正如某些ISDN原因代码是特定于ISUP的，并且没有必然的SIP操作一样，也有一些SIP状态代码不应该简单地转换为ISUP-应该首先尝试一些特定于SIP的操作。请参见下面（+）标记上的注释。
Response received Cause value in the REL
----------------- ----------------------
400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented (+)
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
(w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
423 Interval Too Brief 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
481 Call/Transaction Does not Exist 41 Temporary Failure
482 Loop Detected 25 Exchange - routing error
483 Too many hops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
487 Request Terminated --- (no mapping)
488 Not Acceptable here --- by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 79 Not implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header
Response received Cause value in the REL
----------------- ----------------------
400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented (+)
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
(w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
423 Interval Too Brief 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
481 Call/Transaction Does not Exist 41 Temporary Failure
482 Loop Detected 25 Exchange - routing error
483 Too many hops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
487 Request Terminated --- (no mapping)
488 Not Acceptable here --- by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 79 Not implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header
(*) In some cases, it may be possible for a SIP gateway to provide credentials to the SIP UAS that is rejecting an INVITE due to authorization failure. If the gateway can authenticate itself, then obviously it SHOULD do so and proceed with the call; only if the gateway cannot authenticate itself should cause code 21 be sent.
（*）在某些情况下，SIP网关可能会向因授权失败而拒绝邀请的SIP UAS提供凭据。如果网关可以自我验证，那么显然它应该这样做并继续调用；只有在网关自身无法进行身份验证时，才会发送代码21。
(+) If at all possible, a SIP gateway SHOULD respond to these protocol errors by remedying unacceptable behavior and attempting to re-originate the session. Only if this proves impossible should the SIP gateway fail the ISUP half of the call.
（+）如果可能，SIP网关应通过纠正不可接受的行为并尝试重新发起会话来响应这些协议错误。只有当这被证明是不可能的时候，SIP网关才会使呼叫的一半失败。
When the Warning header is present in a SIP 606 or 488 message, there may be specific ISDN cause code mappings appropriate to the Warning code. This document recommends that '31 Normal, unspecified' SHOULD by default be used for most currently assigned Warning codes. If the Warning code speaks to an unavailable bearer capability, cause code '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping.
当SIP 606或488消息中存在警告报头时，可能存在适用于警告代码的特定ISDN原因代码映射。本文件建议，对于大多数当前指定的警告代码，默认情况下应使用“31正常，未指定”。如果警告代码表示承载能力不可用，则建议映射代码“65承载能力未实现”。
This circumstance generally arises when the user on the PSTN side hangs up before the call has been answered; the gateway therefore aborts the establishment of the session. A CANCEL request MUST be issued (a BYE is not used, since no final response has arrived from the SIP side). A 200 OK for the CANCEL can be expected by the gateway, and finally a 487 for the INVITE arrives (which the gateway ACKs in turn).
这种情况通常发生在PSTN侧的用户在呼叫应答之前挂断电话时；因此，网关中止会话的建立。必须发出取消请求（不使用BYE，因为SIP端没有最终响应）。网关可以预期取消为200 OK，最后INVITE为487（网关依次确认）。
The gateway SHOULD store state information related to this dialog for a certain period of time, since a 200 final response for the INVITE originally sent might arrive (even after the reception of the 200 OK for the CANCEL). In this situation, the gateway MUST send an ACK followed by an appropriate BYE request.
网关应在一定时间内存储与此对话框相关的状态信息，因为最初发送的邀请的200最终响应可能会到达（即使在接收到取消的200 OK之后）。在这种情况下，网关必须发送ACK，然后发送相应的BYE请求。
In SIP bridging situations, the REL message cannot be encapsulated in a CANCEL message (since CANCEL cannot have a message body). Usually, the REL message will contain a CAI value of 16 "Normal clearing". If the value is other than a 16, the gateway MAY wish to use some other means of communicating the cause value (see Section 5.8).
在SIP桥接情况下，REL消息不能封装在CANCEL消息中（因为CANCEL不能有消息正文）。通常，REL消息将包含16“正常清除”的CAI值。如果该值不是16，则网关可能希望使用一些其他方式传达原因值（见第5.8节）。
In order to prevent the remote ISUP node's timer T7 from expiring, the gateway MAY keep its own supervisory timer; ISUP defines this timer as T11. T11's duration is carefully chosen so that it will always be shorter than the T7 of any node to which the gateway is communicating.
为了防止远程ISUP节点的计时器T7过期，网关可以保持其自己的监控计时器；ISUP将此计时器定义为T11。仔细选择T11的持续时间，使其始终短于网关与之通信的任何节点的T7。
To clarify timer T11's relevance with respect to SIP interworking, Q.764 [12] explains its use as: "If in normal operation, a delay in the receipt of an address complete signal from the succeeding network is expected, the last common channel signaling exchange will originate and send an address complete message 15 to 20 seconds [timer (T11)] after receiving the latest address message." Since SIP nodes have no obligation to respond to an INVITE request within 20 seconds, SIP interworking inarguably qualifies as such a situation.
为了澄清计时器T11与SIP互通的相关性，Q.764[12]将其使用解释为：“如果在正常操作中，预期从后续网络接收到地址完整信号的延迟，则最后一次公共信道信令交换将发起并发送地址完整消息15至20秒[计时器（T11）]由于SIP节点没有义务在20秒内响应INVITE请求，因此SIP互通无可辩驳地符合这种情况。
If the gateway supports this optional mechanism, then if its T11 expires, it SHOULD send an early ACM (i.e., called party status set to "no indication") to prevent the expiration of the remote node's T7 (where permitted by the ISUP variant). See Section 8.2.3 for the value of the ACM parameters.
如果网关支持此可选机制，则如果其T11过期，则应发送早期ACM（即被叫方状态设置为“无指示”），以防止远程节点的T7过期（ISUP变体允许的情况下）。有关ACM参数的值，请参见第8.2.3节。
If a "180 Ringing" message arrives subsequently, it SHOULD be sent in a CPG, as shown in Section 8.2.3.
如果“180振铃”信息随后到达，则应在CPG中发送，如第8.2.3节所示。
See Section 8.1.3 for an example callflow that includes the expiration of T11.
参见第8.1.3节，了解包含T11到期的调用流示例。
In ISDN networks, a user can generate a SUS (timer T2, user initiated) in order to unplug the terminal from the socket and plug it in another one. A RES is sent once the terminal has been reconnected and the T2 timer has not expired. SUS is also frequently used to signaling an on-hook state for a remote terminal before timers leading to the transmission of a REL message are sent (this is the more common case by far). While a call is suspended, no audio media is passed end-to-end.
在ISDN网络中，用户可以生成一个SUS（定时器T2，用户启动），以便将终端从插座上拔下并插入另一个插座。一旦终端重新连接且T2定时器未过期，就会发送RES。在发送导致REL消息传输的计时器之前，SUS还经常用于向远程终端发送挂机状态的信号（这是到目前为止更常见的情况）。呼叫挂起时，不会端到端传递音频媒体。
When a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received. Putting the media on hold insures that bandwidth is conserved when no audio traffic needs to be transmitted.
当为具有SIP分支的呼叫发送SUS时，网关可暂停IP媒体传输，直到接收到RES。将媒体置于保留状态可确保在无需传输音频流量时节省带宽。
If media suspension is appropriate, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to request that the far-end's transmission of the media stream be placed on hold. The subsequent reception of a RES from the PSTN SHOULD then trigger a re-INVITE that requests the resumption of the media stream. Note that the MGC may or may not elect to stop transmitting any media itself when it requests the cessation of far-end transmission.
如果媒体暂停是适当的，那么当SUS从PSTN到达时，MGC可以发送INVITE以请求将远端的媒体流传输置于等待状态。随后从PSTN接收RES应触发请求恢复媒体流的重新邀请。注意，当MGC请求停止远端传输时，它可以选择也可以不选择停止传输任何媒体本身。
If media suspension is not required by the MGC receiving the SUS from the PSTN, the SIP INFO [6] method MAY be used to transmit an encapsulated SUS rather than a re-INVITE. Note that the recipient of such an INFO request may be a simple SIP phone that does not understand ISUP (and would therefore take no action on receipt of this message); if a prospective destination for an INFO-encapsulated SUS has not used encapsulated ISUP in any messages it has previously sent, the gateway SHOULD NOT relay the INFO method, but rather should handle the SUS and the corresponding RES without signaling their arrival to the SIP network.
如果从PSTN接收su的MGC不需要媒体暂停，则SIP INFO[6]方法可用于发送封装的su，而不是重新邀请。请注意，此类信息请求的接收者可能是不理解ISUP的简单SIP电话（因此在收到此消息时不会采取任何行动）；如果信息封装的SU的预期目的地没有在其先前发送的任何消息中使用封装的ISUP，则网关不应中继信息方法，而是应在不向SIP网络发送到达信号的情况下处理SU和相应的RES。
In any case, subsequent RES messages MUST be transmitted in the same method that was used for the corresponding SUS (i.e., if an INFO is used for a SUS, INFO should also be used for the subsequent RES).
在任何情况下，后续RES消息必须以用于相应SUS的相同方法传输（即，如果信息用于SUS，则信息也应用于后续RES）。
Regardless of whether the INFO or re-INVITE mechanism is used to carry a SUS message, neither has any implication that the originating side will cease sending IP media. The recipient of an encapsulated SUS message MAY therefore elect to send a re-INVITE themselves to suspend media transmission from the MGC side if desired.
无论是使用INFO还是REINVITE机制来传输SUS消息，都不意味着发起方将停止发送IP媒体。因此，如果需要，封装的SUS消息的接收者可以选择发送重新邀请以暂停来自MGC侧的媒体传输。
The following example uses the INVITE mechanism. Note that this flow is informative, not proscriptive; compliant gateways are free to implement functionally equivalent flows, as described in the preceding paragraphs.
下面的示例使用INVITE机制。请注意，此流是信息流，而不是禁止流；如前几段所述，兼容网关可以自由实现功能等效的流。
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
The handling of a network-initiated SUS immediately prior to call teardown is handled in Section 10.2.2.
第10.2.2节处理在呼叫断开之前立即启动的网络SUS。
After a call has been connected, a re-INVITE could be sent to a gateway from the SIP side in order to place the call on hold. This re-INVITE will have an SDP offer indicating that the originator of the re-INVITE no longer wishes to receive media.
连接呼叫后，可以从SIP端向网关发送重新邀请，以便将呼叫挂起。此重新邀请将具有SDP报价，表明重新邀请的发起人不再希望接收媒体。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |
When such a re-INVITE is received, the gateway SHOULD send a CPG in order to express that the call has been placed on hold. The CPG SHOULD contain a Generic Notification Indicator (or, in ANSI networks, a Notification Indicator) with a value of 'remote hold'.
当收到此类重新邀请时，网关应发送CPG，以表示呼叫已被挂起。CPG应包含一个值为“远程保持”的通用通知指示器（或在ANSI网络中为通知指示器）。
If, subsequent to the sending of the re-INVITE, the SIP side wishes to take the remote end off hold and begin receiving media again, it SHOULD repeat the flow above with an INVITE that contains an SDP offer with an appropriate media destination. The Generic Notification Indicator would in this instance have a value of 'remote retrieval' (or in some variants 'remote hold released').
如果在发送重新邀请之后，SIP方希望使远程端停止等待并再次开始接收媒体，则应使用包含具有适当媒体目的地的SDP提供的邀请重复上述流程。在这种情况下，通用通知指示器的值为“远程检索”（或在某些变体中为“远程保持已释放”）。
Finally, note that a CPG with hold indicators may be received by a gateway from the PSTN. In the interests of conserving bandwidth, the gateway SHOULD stop sending media until the call is resumed and SHOULD send a re-INVITE to the SIP leg of the call requesting that the remote side stop sending media.
最后，注意，网关可以从PSTN接收具有保持指示符的CPG。为了节省带宽，网关应停止发送媒体，直到呼叫恢复，并应向呼叫的SIP分支发送重新邀请，请求远程端停止发送媒体。
From the perspective of a gateway, either the SIP side or the ISUP side can release a call, regardless of which side initiated the call. Note that cancellation of a call setup request (either from the ISUP or SIP side) is discussed elsewhere in this document (in Section 8.2.7 and Section 7.2.3, respectively).
从网关的角度来看，无论是SIP端还是ISUP端都可以释放呼叫，而不管是哪一方发起了呼叫。请注意，取消呼叫设置请求（来自ISUP或SIP端）将在本文件的其他部分（分别在第8.2.7节和第7.2.3节）进行讨论。
Gateways SHOULD implement functional equivalence with the flows in this section.
网关应该与本节中的流实现功能等价。
For a normal termination of the dialog (receipt of a BYE request), the gateway MUST immediately send a 200 response. The gateway then MUST release any media resources in the gateway (DSPs, TCIC locks, and so on) and send an REL with a cause code of 16 (normal call
对于对话框的正常终止（收到BYE请求），网关必须立即发送200响应。然后，网关必须释放网关中的所有媒体资源（DSP、TCIC锁等），并发送原因代码为16的REL（正常呼叫）
clearing) to the PSTN. Release of resources is confirmed by the PSTN side with an RLC message.
正在清除）到PSTN。PSTN侧通过RLC消息确认资源的释放。
In SIP bridging situations, the cause code of any REL encapsulated in the BYE request SHOULD be re-used in any REL that the gateway sends to the PSTN.
在SIP桥接情况下，封装在BYE请求中的任何REL的原因码应在网关发送到PSTN的任何REL中重新使用。
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
If the release of the connection was caused by the reception of a REL, the REL SHOULD be encapsulated in the BYE sent by the gateway. Whether the caller or callee hangs up first, the gateway SHOULD release any internal resources used in support of the call and then MUST confirm that the circuit is ready for re-use by sending an RLC.
如果连接的释放是由接收到REL引起的，则REL应封装在网关发送的BYE中。无论是呼叫者还是被呼叫者先挂断，网关都应释放用于支持呼叫的任何内部资源，然后必须通过发送RLC确认电路已准备好重新使用。
When the caller hangs up, the SIP dialog MUST be terminated by sending a BYE request (which is confirmed with a 200).
当调用者挂断时，必须通过发送BYE请求来终止SIP对话（该请求由200确认）。
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
In some PSTN scenarios, if the callee hangs up in the middle of a call, the local exchange sends a SUS instead of a REL and starts a timer (T6, SUS is network initiated). When the timer expires, the REL is sent. This necessitates a slightly different SIP flow; see Section 9 for more information on handling suspension. It is RECOMMENDED that gateways implement functional equivalence with the following flow for this case:
在一些PSTN场景中，如果被叫者在呼叫中间挂起，本地交换机发送一个SUS而不是一个RID，并启动一个定时器（T6，SUS是网络发起的）。计时器到期时，发送REL。这需要稍微不同的SIP流；有关处理悬架的更多信息，请参见第9节。在这种情况下，建议网关采用以下流程实现功能等效：
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
ISUP contains a set of messages used for maintenance purposes. They can be received during any ongoing call. There are basically two kinds of maintenance messages (apart from the continuity check): messages for blocking circuits and messages for resetting circuits.
ISUP包含一组用于维护目的的消息。他们可以在任何正在进行的通话中收到。基本上有两种维护信息（除了连续性检查）：阻塞电路信息和复位电路信息。
Upon reception of an RSC message for a circuit currently being used by the gateway for a call, the call MUST be released immediately (this typically results from a serious maintenance condition). RSC MUST be answered with an RLC after resetting the circuit in the gateway. Group reset (GRS) messages which target a range of circuits are answered with a Circuit Group Reset ACK Message (GRA) after resetting all the circuits affected by the message.
在收到网关当前用于呼叫的电路的RSC消息后，必须立即释放呼叫（这通常是由于严重的维护状况造成的）。重置网关中的电路后，必须用RLC应答RSC。在重置所有受消息影响的电路后，针对一系列电路的组重置（GRS）消息将使用电路组重置确认消息（GRA）进行应答。
The gateways SHOULD behave as if a REL had been received in order to release the dialog on the SIP side. A BYE or a CANCEL are sent depending of the status of the call. See the procedures in Section 10.
为了在SIP端释放对话框，网关的行为应该像接收到REL一样。根据通话状态发送“再见”或“取消”。参见第10节中的程序。
There are two kinds of blocking messages: maintenance messages or hardware-failure messages. Maintenance blocking messages indicate that the circuit is to be blocked for any subsequent calls, but these messages do not affect any ongoing call. This allows circuits to be gradually quiesced and taken out of service for maintenance.
有两种阻塞消息：维护消息或硬件故障消息。维护阻塞消息表示任何后续呼叫都将阻塞电路，但这些消息不会影响任何正在进行的呼叫。这允许电路逐渐停止工作并停止使用以进行维护。
Hardware-oriented blocking messages have to be treated as reset messages. They generally are sent only when a hardware failure has occurred. Media transmission for all calls in progress on these circuits would be affected by this hardware condition, and therefore all calls must be released immediately.
面向硬件的阻塞消息必须视为重置消息。它们通常仅在发生硬件故障时发送。这些电路上正在进行的所有呼叫的媒体传输都会受到此硬件条件的影响，因此必须立即释放所有呼叫。
BLO is always maintenance oriented and it is answered by the gateway with a Blocking ACK Message (BLA) when the circuit is blocked - this requires no corresponding SIP actions. Circuit Group Blocking (CGB) messages have a "type indicator" inside the Circuit Group Supervision Message Type Indicator. It indicates if the CGB is maintenance or hardware failure oriented. If the CGB results from a hardware failure, then each call in progress in the affected range of circuits MUST be terminated immediately as if a REL had been received, following the procedures in Section 10. CGBs MUST be answered with CGBAs.
BLO始终是面向维护的，当电路被阻塞时，网关会用阻塞确认消息（BLA）对其进行应答-这不需要相应的SIP操作。电路组阻塞（CGB）消息在电路组监控消息类型指示器内有一个“类型指示器”。它指示CGB是面向维护还是面向硬件故障。如果CGB是由硬件故障引起的，则必须按照第10节中的程序，立即终止受影响电路范围内正在进行的每个呼叫，如同已收到REL一样。CGB必须由CGBA回答。
A continuity check is a test performed on a circuit that involves the reflection of a tone generated at the originating switch by a loopback at the destination switch. Two variants of the continuity check appear in ISUP: the implicit continuity check request within an IAM (in which case the continuity check takes place as a precondition before call setup begins), and the explicit continuity check signaled by a Continuity Check Request (CCR) message. PSTN gateways in regions that support continuity checking generally SHOULD have some way of accommodating these tests (if they hope to be fielded by providers that interconnect with any major carrier).
导通性检查是在电路上执行的一种测试，涉及通过目标交换机上的环回反射在始发交换机上生成的音调。ISUP中出现两种连续性检查变体：IAM中的隐式连续性检查请求（在这种情况下，连续性检查作为呼叫设置开始前的先决条件进行），以及由连续性检查请求（CCR）消息发出信号的显式连续性检查。支持连续性检查的地区的PSTN网关通常应该有某种方式来适应这些测试（如果它们希望由与任何主要运营商互连的提供商部署）。
When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT send any corresponding SIP messages; the scope of the continuity check applies only to the PSTN trunks, not to any IP media paths beyond the gateway. CCR messages also do not designate any called party number, or any other way to determine what SIP user agent server should be reached.
当PSTN-SIP网关接收到CCR时，网关不应发送任何相应的SIP消息；连续性检查的范围仅适用于PSTN中继，不适用于网关以外的任何IP媒体路径。CCR消息也不指定任何被叫方号码，也不指定任何其他方式来确定应该访问哪个SIP用户代理服务器。
When an IAM with the Continuity Check Indicator flag set within the NCI parameter is received, the gateway MUST process the continuity check before sending an INVITE message (and proceeding normally with
当接收到NCI参数内设置了连续性检查指示器标志的IAM时，网关必须在发送INVITE消息之前处理连续性检查（并正常继续）
call setup); if the continuity check fails (a COT with Continuity Indicator of 'failed' is received), then an INVITE MUST NOT be sent.
呼叫设置）；如果连续性检查失败（收到连续性指示器为“失败”的COT），则不得发送邀请。
SIP proxy servers MAY route SIP messages on any signaling criteria desired by network administrators, but generally the Request-URI is the foremost routing criterion. The To and From headers are also frequently of interest in making routing decisions. SIP-ISUP mapping assumes that proxy servers are interested in at least these three fields of SIP messages, all of which contain URIs.
SIP代理服务器可以根据网络管理员所需的任何信令标准路由SIP消息，但通常请求URI是最重要的路由标准。在做出路由决策时，To和From头通常也很重要。SIP-ISUP映射假定代理服务器至少对SIP消息的这三个字段感兴趣，所有这些字段都包含URI。
SIP-ISUP mapping frequently requires the representation of telephone numbers in these URIs. In some instances these numbers will be presented first in ISUP messages, and SS7-SIP gateways will need to translate the ISUP formats of these numbers into SIP URIs. In other cases the reverse transformation will be required.
SIP-ISUP映射通常需要在这些URI中表示电话号码。在某些情况下，这些数字将首先出现在ISUP消息中，SS7-SIP网关将需要将这些数字的ISUP格式转换为SIPURI。在其他情况下，需要进行反向转换。
The most common format used in SIP for the representation of telephone numbers is the tel URL [7]. When converting between formats, the tel URL MAY constitute the entirety of a URI field in a SIP message, or it MAY appear as the user portion of a SIP URI. For example, a To field might appear as:
SIP中用于表示电话号码的最常见格式是电话URL[7]。当在格式之间转换时，tel URL可以构成SIP消息中URI字段的整体，或者它可以显示为SIP URI的用户部分。例如，“收件人”字段可能显示为：
To: tel:+17208881000
To: tel:+17208881000
Or
或
To: sip:+17208881000@level3.com
To: sip:+17208881000@level3.com
Whether or not a particular gateway or endpoint should formulate URIs in the tel or SIP format is a matter of local administrative policy - if the presence of a host portion would aid the surrounding network in routing calls, the SIP format should be used. A gateway MUST accept either tel or SIP URIs from its peers.
特定网关或端点是否应制定tel或SIP格式的URI是本地管理策略的问题-如果主机部分的存在有助于周围网络路由呼叫，则应使用SIP格式。网关必须接受来自其对等方的tel或SIP URI。
The '+' sign preceding the number in tel URLs indicates that the digits which follow constitute a fully-qualified E.164 [16] number; essentially, this means that a country code is provided before any national-specific area codes, exchange/city codes, or address codes. The absence of a '+' sign MAY signify that the number is merely nationally significant, or perhaps that a private dialing plan is in use. When the '+' sign is not present, but a telephone number is represented by the user portion of the URI, the SIP URI SHOULD contain the optional ';user=phone' parameter; e.g.,
tel URL中数字前面的“+”符号表示后面的数字构成完全限定的E.164[16]数字；本质上，这意味着在任何国家特定区号、交易所/城市代码或地址代码之前提供国家代码。没有“+”符号可能意味着该号码仅在全国范围内具有重要意义，或者可能正在使用私人拨号计划。当“+”符号不存在，但电话号码由URI的用户部分表示时，SIPURI应包含可选的“；用户=电话参数；例如。，
To: sip:83000@sip.example.net;user=phone
To: sip:83000@sip.example.net;user=phone
However, it is strongly RECOMMENDED that only internationally significant E.164 numbers be passed between SIP-T gateways, especially when such gateways are in different regions or different administrative domains. In many if not most SIP-T networks, gateways are not responsible for end-to-end routing of SIP calls; practically speaking, gateways have no way of knowing if the call will terminate in a local or remote administrative domain and/or region, and hence gateways SHOULD always assume that calls require an international numbering plan. There is no guarantee that recipients of SIP signaling will be capable of understanding national dialing plans used by the originators of calls - if the originating gateway does not internationalize the signaling, the context in which the digits were dialed cannot be extrapolated by far-end network elements.
但是，强烈建议在SIP-T网关之间只传递具有国际意义的E.164号，特别是当此类网关位于不同的区域或不同的管理域时。在许多（如果不是大多数的话）SIP-T网络中，网关不负责SIP呼叫的端到端路由；实际上，网关无法知道呼叫是否将在本地或远程管理域和/或区域终止，因此网关应始终假定呼叫需要国际编号计划。无法保证SIP信令的接收者能够理解呼叫发起人使用的国家拨号计划-如果发起网关不将信令国际化，则远端网络元件无法推断拨出数字的上下文。
In ISUP signaling, a telephone number appears in a common format that is used in several parameters, including the CPN and CIN; when it represents a calling party number it sports some additional information (detailed below). For the purposes of this document, we will refer to this format as 'ISUP format' - if the additional calling party information is present, the format shall be referred to as 'ISUP- calling format'. The format consists of a byte called the Nature of Address (NoA) indicator, followed by another byte which contains the Numbering Plan Indicator (NPI), both of which are prefixed to a variable-length series of bytes that contains the digits of the telephone number in Binary Coded Decimal (BCD) format. In the calling party number case, the NPI's byte also contains bit fields which represent the caller's presentation preferences and the status of any call screening checks performed up until this point in the call.
在ISUP信令中，电话号码以通用格式出现，用于多个参数，包括CPN和CIN；当它代表主叫方号码时，它会显示一些附加信息（详情如下）。在本文件中，我们将此格式称为“ISUP格式”-如果存在其他呼叫方信息，则此格式应称为“ISUP-呼叫格式”。该格式由一个称为地址性质（NoA）指示符的字节组成，然后是另一个包含编号计划指示符（NPI）的字节，这两个字节的前缀都是可变长度的字节序列，其中包含二进制编码十进制（BCD）格式的电话号码数字。在主叫方号码的情况下，NPI的字节还包含位字段，这些位字段表示主叫方的表示首选项以及在呼叫中直到此时为止执行的任何呼叫筛选检查的状态。
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ISUP format ISUP calling format
ISUP格式ISUP调用格式
ISUP numbering formats
ISUP编号格式
The NPI field is generally set to the value 'ISDN (Telephony) numbering plan (Recommendation E.164)', but this does not mean that the digits which follow necessarily contain a country code; the NoA
NPI字段通常设置为值“ISDN（电话）编号计划（建议E.164）”，但这并不意味着后面的数字必然包含国家代码；诺亚号
field dictates whether the telephone number is in a national or international format. When the represented number is not designated to be in an international format, the NoA generally provides information specific to the national dialing plan - based on this information one can usually determine how to convert the number in question into an international format. Note that if the NPI contains a value other than 'ISDN numbering plan', then the tel URL may not be suitable for carrying the address digits, and the handling for such calls is outside the scope of this document.
字段指示电话号码是国家格式还是国际格式。当所代表的号码未指定为国际格式时，NoA通常会提供特定于国家拨号计划的信息——根据这些信息，人们通常可以确定如何将所述号码转换为国际格式。请注意，如果NPI包含“ISDN编号计划”以外的值，则tel URL可能不适合承载地址数字，并且此类呼叫的处理不在本文档的范围内。
Based on the above, conversion from ISUP format to a tel URL is as follows. First, provided that the NPI field indicates that the telephone number format uses E.164, the NoA is consulted. If the NoA indicates that the number is an international number, then the telephone number digits SHOULD be appended unmodified to a 'tel:+' string. If the NoA has the value 'national (significant) number', then a country code MUST be prefixed to the telephone number digits before they are committed to a tel URL; if the gateway performing this conversion interconnects with switches homed to several different country codes, presumably the appropriate country code SHOULD be chosen based on the originating switch or trunk group. If the NoA has the value 'subscriber number', both a country code and any other numbering components necessary for the numbering plan in question (such as area codes or city codes) MAY need to be added in order for the number to be internationally significant - however, such procedures vary greatly from country to country, and hence they cannot be specified in detail here. Only if a country or network-specific value is used for the NoA SHOULD a tel URL not include a '+' sign; in these cases, gateways SHOULD simply copy the provided digits into the tel URL and append a 'user=phone' parameter if a SIP URI format is used. Any non-standard or proprietary mechanisms used to communicate further context for the call in ISUP are outside the scope of this document.
基于上述内容，从ISUP格式到tel URL的转换如下所示。首先，如果NPI字段表明电话号码格式使用E.164，则应咨询NoA。如果NoA表明该号码是国际号码，则电话号码数字应不加修改地附加到“tel:+”字符串中。如果NoA的值为“国家（重要）号码”，则在将电话号码数字提交到电话URL之前，必须在电话号码数字前添加国家代码；如果执行此转换的网关与驻留在多个不同国家/地区代码的交换机互连，则应根据原始交换机或中继组选择适当的国家/地区代码。如果NoA的值为“订户编号”，则可能需要添加国家代码和相关编号计划所需的任何其他编号组件（如区号或城市代码），以使编号具有国际意义-但是，这些程序因国家而异，因此，在这里无法详细说明。仅当国家或网络特定值用于NoA时，tel URL不应包含“+”符号；在这些情况下，网关只需将提供的数字复制到tel URL中，并在使用SIP URI格式时附加“user=phone”参数。用于在ISUP中进一步传达调用上下文的任何非标准或专有机制均不在本文档范围内。
If a nationally-specific parameter is present that allows for the transmission of the calling party's name (such as the Generic Name Parameter in ANSI), then generally, if presentation is not restricted, this information SHOULD be used to populate the display-name portion of the From field.
如果存在允许传输呼叫方名称的国家特定参数（如ANSI中的通用名称参数），则通常，如果表示不受限制，则应使用此信息填充From字段的显示名称部分。
If ISUP calling format is being converted rather than ISUP format, then two additional pieces of information must be taken into account: presentation indicators and screening indicators. If the presentation indicators are set to 'presentation restricted', then a special URI is created by the gateway which communicates to the far end that the caller's identity has been omitted. This URI SHOULD be a SIP URI with a display-name and username of 'Anonymous', e.g.:
如果正在转换ISUP调用格式而不是ISUP格式，则必须考虑另外两条信息：表示指标和筛选指标。如果表示指示符设置为“表示受限”，则网关将创建一个特殊URI，该URI将与远端通信，表明调用方的身份已被忽略。此URI应为SIP URI，显示名称和用户名为“匿名”，例如：
From: Anonymous <sip:anonymous@anonymous.invalid>
From: Anonymous <sip:anonymous@anonymous.invalid>
For further information about privacy in SIP, see Section 5.7.
有关SIP中隐私的更多信息，请参见第5.7节。
If presentation is set to 'address unavailable', then gateways should treat the IAM as if the CIN parameter was omitted. Screening indicators should not be translated, as they are only meaningful end-to-end.
如果表示设置为“地址不可用”，则网关应将IAM视为忽略了CIN参数。筛选指标不应翻译，因为它们只是有意义的端到端。
Conversion from tel URLs to ISUP format is simpler. If the URI is in international format, then the gateway SHOULD consult the leading country code of the URI. If the country code is local to the gateway (the gateway has one or more trunks that point to switches which are homed to the country code in question), the gateway SHOULD set the NoA to reflect 'national (significant) number' and strip the country code from the URI before populating the digits field. If the country code is not local to the gateway, the gateway SHOULD set the NoA to 'international number' and retain the country code. In either case the NPI MUST be set to 'ISDN numbering plan'.
从tel URL到ISUP格式的转换更简单。如果URI为国际格式，则网关应参考URI的主要国家代码。如果国家/地区代码是网关的本地代码（网关有一个或多个指向交换机的中继，这些交换机位于相关国家/地区代码所在地），则网关应将NoA设置为反映“国家（重要）编号”，并在填充数字字段之前从URI中删除国家/地区代码。如果国家代码不是网关的本地代码，网关应将NoA设置为“国际编号”，并保留国家代码。无论哪种情况，NPI都必须设置为“ISDN编号计划”。
If the URI is not in international format, the gateway MAY attempt to treat the telephone number within the URI as if it were appropriate to its national or network-specific dialing plan; if doing so gives rise to internal gateway errors or the gateway does not support such procedures, then the gateway SHOULD respond with appropriate SIP status codes to express that the URI could not be understood (if the URI in question is the Request-URI, a 484).
如果URI不是国际格式，网关可以尝试将URI内的电话号码视为适合其国家或网络特定拨号计划；如果这样做会导致内部网关错误或网关不支持此类过程，则网关应使用适当的SIP状态代码进行响应，以表示无法理解URI（如果所讨论的URI是请求URI，则为484）。
When converting from a tel URL to ISUP calling format, the procedure is identical to that described in the preceding paragraphs, but additionally, the presentation indicator SHOULD be set to 'presentation allowed' and the screening indicator to 'network provided', unless some service provider policy or user profile specifically disallows presentation.
当从tel URL转换为ISUP呼叫格式时，过程与前面段落中描述的过程相同，但另外，演示指示器应设置为“允许演示”，筛选指示器应设置为“提供网络”，除非某些服务提供商策略或用户配置文件明确禁止演示。
Other flavors of ISUP different than ITU-T ISUP have different parameters and more features. Some of the parameters have more possible values and provide more information about the status of the call.
与ITU-T ISUP不同的其他版本的ISUP具有不同的参数和更多的功能。某些参数具有更多可能的值，并提供有关调用状态的更多信息。
The Circuit Query Message (CQM) and Circuit Query Response (CQR) are used in many ISUP variants. These messages have no analog in SIP, although receipt of a CQR may cause state reconciliation if the originating and destination switches have become desynchronized; as states are reconciled some calls may be terminated, which may cause SIP or ISUP messages to be sent (as described in Section 10).
电路查询消息（CQM）和电路查询响应（CQR）用于许多ISUP变体。这些消息在SIP中没有模拟，尽管如果始发和目的地交换机已失步，则接收CQR可能导致状态协调；当状态被协调时，一些呼叫可能被终止，这可能导致发送SIP或ISUP消息（如第10节所述）。
However, differences in the message flows are more important. In ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent instead (when no ACM has been sent before the call is answered). In call forwarding situations, CPGs MAY be sent before the ACM is sent. SAMs MUST NOT be sent; 'en-bloc' signaling is always used. The ANSI Exit Message (EXM) SHOULD NOT result in any SIP signaling in gateways. ANSI also uses the Circuit Reservation Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of its interworking procedures - in the event that an MGC does receive a CRM, a CRA SHOULD be sent in return (in some implementations, transmissions of a CRA could conceivably be based on a resource reservation system); after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and process it normally. Any further circuit reservation mechanism is outside the scope of this document.
然而，消息流中的差异更为重要。在ANSI[11]ISUP中，不得发送CON消息；而是发送一个ANM（当在应答呼叫之前没有发送ACM时）。在呼叫转移情况下，可以在发送ACM之前发送CPG。不得发送SAM；'始终使用“整体”信号。ANSI退出消息（EXM）不应在网关中产生任何SIP信令。ANSI还使用电路保留消息（CRM）和电路保留确认（CRA）作为其互通过程的一部分-如果MGC确实接收到CRM，则应发送CRA作为回报（在一些实现中，CRA的传输可能基于资源保留系统）；发送CRA后，MGC应等待后续IAM并正常处理。任何进一步的线路预留机制不在本文件范围内。
Although receipt of a Confusion (CFN) message is an indication of a protocol error, corresponding SIP messages SHOULD NOT be sent on receipt of a CFN - the CFN should be handled with ISUP-specific procedures by the gateway (usually by retransmission of the packet to which the CFN responded). Only if ISUP procedures fails repeatedly should this cause a SIP error condition (and call failure) to arise.
尽管收到混淆（CFN）消息表示协议错误，但在收到CFN时不应发送相应的SIP消息-网关应使用ISUP特定程序处理CFN（通常通过重新传输CFN响应的数据包）。只有当ISUP过程反复失败时，才会导致SIP错误情况（和呼叫失败）。
In TTC ISUP CPGs MAY be sent before the ACM is sent. Messages such as a Charging Information Message (CHG) MAY be sent between ACM and ANM. 'En-bloc' signaling is always used and there is no T9 timer.
在TTC中，可以在发送ACM之前发送ISUP CPG。诸如充电信息消息（CHG）之类的消息可以在ACM和ANM之间发送始终使用“整体”信号，并且没有T9定时器。
Some ISUP variants send more messages than the ones described in this document. Therefore, some guidelines are provided here with regard to transport and mapping of these ISUP message.
某些ISUP变体发送的消息比本文档中描述的消息多。因此，这里提供了一些关于这些ISUP消息的传输和映射的指南。
From the caller to the callee, other ISUP messages SHOULD be encapsulated (see [3]) inside INFO messages, even if the INVITE transaction is still not finished. Note that SIP does not ensure that INFO requests are delivered in order, and therefore in adverse network conditions an egress gateway might process INFOs out of order. This issue, however, does not represent an important problem since it is not likely to happen and its effects are negligible in most of the situations. The Information (INF) message and Information Response (INR) are examples of messages that should be encapsulated within an INFO. Gateway implementers might also consider building systems that wait for each INFO transaction to complete before initiating a new INFO transaction.
从调用者到被调用者，其他ISUP消息应该封装在信息消息中（参见[3]），即使INVITE事务仍未完成。请注意，SIP不能确保信息请求按顺序传递，因此在不利的网络条件下，出口网关可能会无序处理信息。然而，这个问题并不代表一个重要的问题，因为它不太可能发生，而且在大多数情况下其影响可以忽略不计。信息（INF）消息和信息响应（INR）是应封装在信息中的消息示例。网关实现者还可以考虑在开始新信息交易之前建立等待每个信息事务完成的系统。
From the callee to the caller, if a message is received by a gateway before the call has been answered (i.e., ANM is received) it SHOULD be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it SHOULD be encapsulated in a provisional 1xx response). Similarly a message which is received on the originating side (probably in response to an INR) before a 200 OK has been received by the gateway should be carried within an INFO. In order for this mechanism to function properly in the forward direction, any necessary Contact or To-tag must have appeared in a previous provisional response or the message might not be correctly routed to its destination. As such all SIP-T gateways MUST send all provisional responses with a Contact header and any necessary tags in order to enable proper routing of new requests issued before a final response has been received. When the INVITE transaction is finished INFO requests SHOULD also be used in this direction.
从被呼叫者到呼叫者，如果网关在应答呼叫（即，接收到ANM）之前接收到消息，则应将其封装在信息中，前提是这不是第一条反向发送的SIP消息（在这种情况下，应将其封装在临时1xx响应中）。类似地，在网关接收到200ok之前在发起侧接收到的消息（可能是响应INR的）应在INFO中携带。为了使该机制在前进方向上正常工作，任何必要的联系人或to标记必须出现在先前的临时响应中，否则消息可能无法正确路由到其目的地。因此，所有SIP-T网关必须发送带有联系人标头和任何必要标记的所有临时响应，以便在收到最终响应之前正确路由发出的新请求。当INVITE事务完成时，也应在此方向使用INFO请求。
ACK Acknowledgment ACM Address Complete Message ANM Answer Message ANSI American National Standards Institute BLA Blocking ACK message BLO Blocking Message CGB Circuit Group Blocking Message CGBA Circuit Group Blocking ACK Message CHG Charging Information Message CON Connect Message CPG Call Progress Message CUG Closed User Group GRA Circuit Group Reset ACK Message GRS Circuit Group Reset Message HLR Home Location Register IAM Initial Address Message IETF Internet Engineering Task Force IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part ITU-T International Telecommunication Union Telecommunication Standardization Sector MG Media Gateway MGC Media Gateway Controller MTP Message Transfer Part REL Release Message RES Resume Message RLC Release Complete Message RTP Real-time Transport Protocol SCCP Signaling Connection Control Part SG Signaling Gateway SIP Session Initiation Protocol SS7 Signaling System No. 7 SUS Suspend Message TTC Telecommunication Technology Committee UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol VoIP Voice over IP
确认ACM地址完成消息ANM应答消息ANSI美国国家标准协会BLA阻塞确认消息BLO阻塞消息CGB电路组阻塞消息CGBA电路组阻塞确认消息CHG充电信息消息CON Connect消息CPG呼叫进度消息CUG关闭用户组GRA电路组重置确认报文GRS电路组重置报文HLR归属位置寄存器IAM初始地址报文IETF Internet工程任务组IP Internet协议ISDN综合业务数字网ISUP ISDN用户部分ITU-T国际电信联盟电信标准化部门MG媒体网关MGC媒体网关控制器MTP消息传输部分REL Release消息RES Resume消息RLC Release Complete消息RTP实时传输协议SCCP信令连接控制部分SG信令网关SIP会话启动协议SS7信令系统7号SUS挂起消息TTC电信技术委员会UAC用户代理客户端UAS用户代理服务器UDP用户数据报协议IP语音
The translation of ISUP parameters into SIP headers may introduce some privacy and security concerns above and beyond those that have been identified for other functions of SIP-T [9A]. Merely securing encapsulated ISUP, for example, would not provide adequate privacy
将ISUP参数转换为SIP报头可能会带来一些隐私和安全问题，这些问题超出了为SIP-T的其他功能所确定的隐私和安全问题[9A]。例如，仅仅保护封装的ISUP不会提供足够的隐私
for a user requesting presentation restriction if the Calling Party Number parameter is openly mapped to the From header. Section 12.2 shows how SIP Privacy [9B] should be used for this function. Since the scope of SIP-ISUP mapping has been restricted to only those parameters that will be translated into the headers and fields used to route SIP requests, gateways consequently reveal through translation the minimum possible amount of information.
如果主叫方号码参数公开映射到From标头，则用于请求表示限制的用户。第12.2节说明了SIP隐私[9B]应如何用于此功能。由于SIP-ISUP映射的范围仅限于那些将被转换为用于路由SIP请求的报头和字段的参数，因此网关通过转换显示尽可能少的信息量。
A security analysis of ISUP is beyond the scope of this document. ISUP bridging across SIP is discussed more fully in [9A], but Section 7.2.1.1 discusses processing the translated ISUP values in relation to any embedded ISUP in a request arriving at PSTN gateway. Lack of ISUP security analysis may pose some risks if embedded ISUP is blindly interpreted. Accordingly, gateways SHOULD NOT blindly trust embedded ISUP unless the request was strongly authenticated [9A], and the sender is trusted, e.g., is another MGC that is authorized to use ISUP over SIP in bridge mode. When requests are received from arbitrary end points, gateways SHOULD filter any received ISUP. In particular, only known-safe commands and parameters should be accepted or passed through. Filtering by deleting believed-to-be dangerous entries does not work well.
ISUP的安全性分析超出了本文档的范围。[9A]中更全面地讨论了跨SIP的ISUP桥接，但第7.2.1.1节讨论了与到达PSTN网关的请求中的任何嵌入式ISUP相关的转换ISUP值的处理。如果盲目解读嵌入式ISUP，缺乏ISUP安全分析可能会带来一些风险。因此，网关不应盲目信任嵌入式ISUP，除非请求经过强身份验证[9A]，并且发送方是受信任的，例如，是另一个被授权在网桥模式下通过SIP使用ISUP的MGC。当从任意端点接收到请求时，网关应过滤任何接收到的ISUP。特别是，只接受或传递已知的安全命令和参数。通过删除被认为是危险的条目进行过滤效果不佳。
In most respects, the information that is translated from ISUP to SIP has no special security requirements. In order for translated parameters to be used to route requests, they should be legible to intermediaries; end-to-end confidentiality of this data would be unnecessary and most likely detrimental. There are also numerous circumstances under which intermediaries can legitimately overwrite the values that have been provided by translation, and hence integrity over these headers is similarly not desirable.
在大多数方面，从ISUP转换到SIP的信息没有特殊的安全要求。为了将翻译后的参数用于路由请求，中间人应能清楚地看到这些参数；这种数据的端到端保密是不必要的，而且很可能是有害的。在许多情况下，中介机构可以合法地覆盖翻译提供的值，因此这些头上的完整性同样是不可取的。
There are some concerns however that arise from the other direction of mapping, the mapping of SIP headers to ISUP parameters, which are enumerated in the following paragraphs. When end users dial numbers in the PSTN today, their selections populate the telephone number portion of the Called Party Number parameter, as well as the digit portions of the Carrier Identification Code and Transit Network Selection parameters of an ISUP IAM. Similarly, the tel URL and its optional parameters in the Request-URI of a SIP, which can be created directly by end users of a SIP device, map to those parameters at a gateway. However, in the PSTN, policy can prevent the user from dialing certain (invalid or restricted) numbers, or selecting certain carrier identification codes. Thus, gateway operators MAY wish to use corresponding policies to restrict the use of certain tel URLs, or tel URL parameters, when authorizing a call.
然而，在映射的另一个方向，即SIP头到ISUP参数的映射中，会出现一些问题，这些问题将在下面的段落中列举。当终端用户今天在PSTN中拨打号码时，他们的选择会填充被叫方号码参数的电话号码部分，以及ISUP IAM的载波识别码和传输网络选择参数的数字部分。类似地，SIP的请求URI中的telurl及其可选参数（可由SIP设备的最终用户直接创建）映射到网关处的那些参数。然而，在PSTN中，策略可以防止用户拨打某些（无效或受限）号码，或选择某些载波识别码。因此，网关运营商可能希望在授权呼叫时使用相应的策略来限制某些tel-URL或tel-URL参数的使用。
The fields relevant to number portability, which include in ANSI ISUP the LRN portion of the Generic Address Parameter and the 'M' bit of the Forward Call Indicators, are used to route calls in the PSTN. Since these fields are rendered as tel URL parameters in the SIP-ISUP mapping, users can set the value of these fields arbitrarily. Consequently, an end-user could change the end office to which a call would be routed (though if LRN value were chosen at random, it is more likely that it would prevent the call from being delivered altogether). The PSTN is relatively resilient to calls that have been misrouted on account of local number portability, however. In some networks, a REL message with some sort of "misrouted ported number" cause code is sent in the backwards direction when such a condition arises. Alternatively, the PSTN switch to which a call was misrouted can forward the call along to the proper switch after making its own number portability query - this is an interim number portability practice that is still common in most segments of the PSTN that support portability. It is not anticipated that end users will typically set these SIP fields, and the risks associated with allowing an adventurous or malicious user to set the LRN do not seem to be grave, but they should be noted by network operators. The limited degree to which SIP signaling contributes to the interworking indicators of the Forward Call Indicators and Backward Call Indicator parameters incurs no foreseeable risks.
与号码可移植性相关的字段，包括ANSI ISUP中通用地址参数的LRN部分和前向呼叫指示符的“M”位，用于在PSTN中路由呼叫。由于这些字段在SIP-ISUP映射中呈现为tel URL参数，因此用户可以任意设置这些字段的值。因此，最终用户可以更改呼叫将被路由到的终端办公室（尽管如果随机选择LRN值，则更有可能会阻止呼叫被完全传送）。然而，PSTN对由于本地号码可携性而被错误路由的呼叫具有相对的弹性。在某些网络中，当出现这种情况时，带有某种“错误路由的端口号”原因代码的REL消息会向后发送。或者，呼叫被错误路由到的PSTN交换机可以在进行自己的号码可移植性查询后将呼叫转发到适当的交换机-这是一种临时的号码可移植性做法，在支持可移植性的PSTN的大多数网段中仍然很常见。预计最终用户通常不会设置这些SIP字段，并且与允许冒险或恶意用户设置LRN相关的风险似乎并不严重，但网络运营商应注意这些风险。SIP信令对前向呼叫指示符和后向呼叫指示符参数的互通指示符的贡献程度有限，不会产生可预见的风险。
Some additional risks may result from the SIP response code to ISUP Cause Code parameter mapping. SIP user agents could conceivably respond to an INVITE from a gateway with any arbitrary SIP response code, and thus they can dictate (within the boundaries of the mappings supported by the gateway) the Q.850 cause code that will be sent by the gateway in the resulting REL message. Generally speaking, the manner in which a call is rejected is unlikely to provide any avenue for fraud or denial of service - to the best knowledge of the authors there is no cause code identified in this document that would signal that some call should not be billed, or that the network should take critical resources off-line. However, operators may want to scrutinize the set of cause codes that could be mapped from SIP response codes (listed in 7.2.6.1) to make sure that no undesirable network-specific behavior could result from operating a gateway supporting the recommended mappings. In some cases, operators MAY wish to implement gateway policies that use alternative mappings, perhaps selectively based on authorization data.
SIP响应代码到ISUP原因代码参数映射可能会导致一些额外的风险。SIP用户代理可以用任意SIP响应代码响应来自网关的邀请，因此它们可以（在网关支持的映射的边界内）指示将由网关在结果REL消息中发送的Q.850原因代码。一般来说，拒绝呼叫的方式不太可能为欺诈或拒绝服务提供任何途径——据作者所知，本文档中没有识别出任何原因代码，表明某些呼叫不应计费，或者网络应将关键资源离线。但是，运营商可能希望仔细检查可从SIP响应代码（在7.2.6.1中列出）映射的一组原因代码，以确保操作支持建议映射的网关不会导致不良的网络特定行为。在某些情况下，运营商可能希望实施使用替代映射的网关策略，可能有选择地基于授权数据。
If the Request-URI and the To header field of a request received at a gateway differ, Section 7.2.1.1 recommends that the To header (if it is a telephone number) should map to the Original Called Number parameter, and the Request-URI to the Called Party Number parameter. However, the user can, at the outset of a request, select a To header field value that differs from the Request-URI; these two field values
如果在网关接收到的请求的请求URI和To报头字段不同，第7.2.1.1节建议To报头（如果是电话号码）应映射到原始被叫号码参数，请求URI映射到被叫方号码参数。然而，用户可以在请求开始时选择与请求URI不同的To报头字段值；这两个字段值
are not required to be the same. This essentially allows a user to set the ISUP Original Called Number parameter arbitrarily. Any applications that rely on the Original Called Number for settlement purposes could be affected by this mapping recommendation. It is anticipated that future SIP work in this space will arrive at a better general account of the re-targeting of SIP requests that may be applicable to the OCN mapping.
不要求是相同的。这本质上允许用户任意设置ISUP原始名为Number的参数。任何依赖原始被叫号码进行结算的应用程序都可能受到此映射建议的影响。预计该领域的未来SIP工作将更好地概括SIP请求的重新定位，这可能适用于OCN映射。
The arbitrary population of the From header of requests by SIP user agents has some well-understood security implications for devices that rely on the From header as an accurate representation of the identity of the originator. Any gateway that intends to use the From header to populate the called party's number parameter of an ISUP IAM message should authenticate the originator of the request and make sure that they are authorized to assert that calling number (or make use of some more secure method to ascertain the identity of the caller). Note that gateways, like all other SIP user agents, MUST support Digest authentication as described in [1].
SIP用户代理对请求的From报头的任意填充对于依赖From报头作为发起者身份的准确表示的设备具有一些众所周知的安全含义。任何打算使用From头来填充ISUP IAM消息的被叫方号码参数的网关都应该对请求的发起人进行身份验证，并确保他们有权断言该主叫号码（或使用一些更安全的方法来确定呼叫者的身份）。请注意，网关与所有其他SIP用户代理一样，必须支持[1]中所述的摘要身份验证。
There is another class of potential risk that is related to the cut-through of the backwards media path before the call is answered. Several practices described in this document recommend that a gateway signal an ACM when a called user agent returns a 18x provisional response code. At that time, backwards media will be cut through end-to-end in the ISUP network, and it is possible for the called user agent then to play arbitrary audio to the caller for an indefinite period of time before transmitting a final response (in the form of a 2xx or higher response code). There are conceivable respects in which this capability could be used illegitimately by the called user agent. It is also however a useful feature to allow progress tones and announcements to be played in the backwards direction in the 'ACM sent' state (so that the caller won't be billed for calls that don't actually complete but for which failure conditions must be rendered to the user as in-band audio). In fact, ISUP commonly uses this backwards cut-through capability in order to pass tones and announcements relating to the status of a call when an ISUP network interworks with legacy networks that are not capable of expressing Q.850 cause codes.
还有另一类潜在风险，与接听电话前切断反向媒体路径有关。本文档中描述的几种实践建议，当被调用的用户代理返回18倍的临时响应代码时，网关向ACM发送信号。此时，ISUP网络中的反向媒体将被端到端切断，被调用的用户代理可以在传输最终响应（以2xx或更高响应代码的形式）之前无限期地向调用者播放任意音频。在一些可以想象的方面，被调用的用户代理可能非法使用此功能。然而，它也是一个有用的功能，允许在“ACM已发送”状态下向后播放进度音和通知（这样呼叫者就不会因为没有实际完成但故障条件必须作为带内音频呈现给用户的呼叫而付费）。事实上，当ISUP网络与不能表达Q.850原因码的传统网络互通时，ISUP通常使用这种向后直通功能来传递与呼叫状态相关的铃声和通知。
It is the contention of the authors that SIP introduces no risks with regard to backwards media that do not exist in Q.931-ISUP mapping, but gateways implementers MAY develop an optional mechanism (possibly something that could be configured by an operator) that would cut off such 'early media' on a brief timer - it is unlikely that more than 20 or 30 seconds of early media is necessary to convey status information about the call (see Section 7.2.6). A more conservative approach would be to never cut through backwards media in the gateway until a 2xx final response has been received, provided that the
作者认为，SIP不会对Q.931-ISUP映射中不存在的向后介质带来任何风险，但网关实现者可以开发一种可选机制（可能由操作员配置）这将在短时间内切断此类“早期媒体”-不太可能需要超过20秒或30秒的早期媒体来传达有关呼叫的状态信息（见第7.2.6节）。更为保守的方法是，在收到2xx最终响应之前，决不切断网关中的反向介质，前提是
gateway implements some way of prevent clipping of the initial media associated with the call.
网关实现了某种方式来防止剪切与呼叫相关的初始媒体。
Unlike a traditional PSTN phone, a SIP user agent can launch multiple simultaneous requests in order to reach a particular resource. It would be trivial for a SIP user agent to launch 100 SIP requests at a 100 port gateway, thereby tying up all of its ports. A malicious user could choose to launch requests to telephone numbers that are known never to answer, which would saturate these resources indefinitely and potentially without incurring any charges. Gateways therefore MAY support policies that restrict the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack.
与传统的PSTN电话不同，SIP用户代理可以同时启动多个请求以到达特定资源。SIP用户代理在一个100端口的网关上启动100个SIP请求，从而占用其所有端口，这对它来说是微不足道的。恶意用户可以选择向已知永远不会应答的电话号码发出请求，这将无限期地占用这些资源，并且可能不会产生任何费用。因此，网关可能支持限制来自同一认证源的同时请求数量的策略，或者支持类似的机制来应对这种可能的拒绝服务攻击。
This document introduces no new considerations for IANA.
本文档没有介绍IANA的新注意事项。
This document existed as an Internet-Draft for four years, and it received innumerable contributions from members of the various Transport Area IETF working groups that it called home (which included the MMUSIC, SIP and SIPPING WGs). In particular, the authors would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars Tovander, Al Varney and William T. Marshall for their help and feedback on this document. The authors would also like to thank ITU-T SG11 for their advice on ISUP procedures.
本文件作为一份互联网草案存在了四年，并从被称为home的各个传输区IETF工作组（包括MMUSIC、SIP和SIPING WGs）的成员那里收到了无数贡献。特别是，作者要感谢奥利·海诺宁、托马斯·梅克林、比尔·卡瓦达斯、乔纳森·罗森博格、亨宁·舒尔兹林内、塔库亚·萨瓦达、米格尔·加西亚、伊戈尔·斯莱普钦、道格拉斯·西克尔、萨姆·霍夫鲍尔、让·弗朗索瓦·穆勒、克里斯特·霍姆伯格、道格·赫蒂格、塔希尔·甘、扬·范吉尔、罗梅尔·汗、迈克·哈默、迈克·皮尔斯、罗兰·杰斯克、，杜莫特、约翰·埃尔维尔、史蒂夫·贝洛文、马克·沃森、丹尼斯·阿列克谢采夫、拉尔斯·托凡德、阿尔瓦尼和威廉·马歇尔感谢他们对本文件的帮助和反馈。作者还要感谢ITU-T SG11就ISUP程序提供的建议。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] 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.
[3] Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[5] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[7] Vaha Sipila，A.，“电话呼叫的URL”，RFC 2806，2000年4月。
[8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[8] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年9月。
[9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header Field for the Session Initiation Protocol", RFC 3326, December 2002.
[9] Schulzrinne，H.，Camarillo，G.和D.Oran，“会话启动协议的原因头字段”，RFC 3326，2002年12月。
[9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[9A]Vemuri，A.和J.Peterson，“电话会话启动协议（SIP-T）：上下文和体系结构”，BCP 63，RFC 3372，2002年9月。
[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[9B]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，2002年11月。
[10] International Telecommunications Union, "Application of the ISDN user part of CCITT Signaling System No. 7 for international ISDN interconnection", ITU-T Q.767, February 1991, <http://www.itu.int>.
[10] 国际电信联盟，“CCITT第7号信令系统的ISDN用户部分在国际ISDN互连中的应用”，ITU-T Q.767，1991年2月<http://www.itu.int>.
[11] American National Standards Institute, "Signaling System No. 7; ISDN User Part", ANSI T1.113, January 1995, <http://www.itu.int>.
[11] 美国国家标准协会，“第7号信号系统；ISDN用户部分”，ANSI T1.113，1995年1月<http://www.itu.int>.
[12] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 1999, <http://www.itu.int>.
[12] 国际电信联盟，“第7号信令系统；ISDN用户部分信令程序”，ITU-T Q.764，1999年12月<http://www.itu.int>.
[13] International Telecommunications Union, "Abnormal conditions - Special release", ITU-T Q.118, September 1997, <http://www.itu.int>.
[13] 国际电信联盟，“异常情况-特别发布”，ITU-T Q.1181997年9月<http://www.itu.int>.
[14] International Telecommunications Union, "Specifications of Signaling System No. 7 - ISDN supplementary services", ITU-T Q.737, June 1997, <http://www.itu.int>.
[14] 国际电信联盟，“第7号信令系统规范——ISDN补充业务”，ITU-T Q.737，1997年6月<http://www.itu.int>.
[15] International Telecommunications Union, "Usage of cause location in the Digital Subscriber Signaling System No. 1 and the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998, <http://www.itu.int>.
[15] 国际电信联盟，“数字用户信令系统1号和信令系统7号ISDN用户部分中原因位置的使用”，ITU-T Q.850，1998年5月<http://www.itu.int>.
[16] International Telecommunications Union, "The international public telecommunications numbering plan", ITU-T E.164, May 1997, <http://www.itu.int>.
[16] 国际电信联盟，“国际公共电信编号计划”，ITU-T E.164，1997年5月<http://www.itu.int>.
[17] International Telecommunications Union, "Formats and codes of the ISDN User Part of Signaling System No. 7", ITU-T Q.763, December 1999, <http://www.itu.int>.
[17] 国际电信联盟，“第7号信令系统的ISDN用户部分的格式和代码”，ITU-T Q.763，1999年12月<http://www.itu.int>.
[18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", RFC 3262, June 2002.
[18] Rosenberg，J.和H.Schulzrinne，“SIP中临时响应的可靠性”，RFC 3262，2002年6月。
[19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, October 2000.
[19] Stewart，R.，“流控制传输协议”，RFC 2960，2000年10月。
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[20] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of Number Portability and Freephone Service", Work in Progress.
[21] Yu，J.，“支持号码可携性和免费电话服务的“电话”和“传真”URL的扩展”，正在进行中。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson高级信号研究实验室FIN-02420 Jorvas芬兰
Phone: +358 9 299 3371
URI: http://www.ericsson.com/
EMail: Gonzalo.Camarillo@Ericsson.com
Phone: +358 9 299 3371
URI: http://www.ericsson.com/
EMail: Gonzalo.Camarillo@Ericsson.com
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
美国德克萨斯州普莱诺市坦尼森大道1200号亚当·罗奇动力软件5100套房，邮编75024
URI: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
URI: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA
美国加利福尼亚州库珀蒂诺市林登·翁·西纳10480里奇维尤法院，邮编95014
URI: http://www.ciena.com/
EMail: lyOng@ciena.com
URI: http://www.ciena.com/
EMail: lyOng@ciena.com
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编辑功能的资金目前由互联网协会提供。