Network Working Group J. Elwell
Request for Comments: 4497 Siemens
BCP: 117 F. Derks
Category: Best Current Practice NEC Philips
P. Mourot
O. Rousseau
Alcatel
May 2006
Network Working Group J. Elwell
Request for Comments: 4497 Siemens
BCP: 117 F. Derks
Category: Best Current Practice NEC Philips
P. Mourot
O. Rousseau
Alcatel
May 2006
Interworking between the Session Initiation Protocol (SIP) and QSIG
会话启动协议（SIP）和QSIG之间的互通
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.
本文件规定了企业电信网络（也称为企业网络）内会话发起协议（SIP）和QSIG之间的互通。SIP是一种Internet应用层控制（信令）协议，用于创建、修改和终止与一个或多个参与者的会话。这些会议特别包括电话会议。QSIG是一种信令协议，用于在专用综合业务网（PISN）内创建、修改和终止电路交换呼叫（特别是电话呼叫）。QSIG在许多Ecma标准中有规定，并作为ISO/IEC标准发布。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Definitions .....................................................5
3.1. External Definitions .......................................5
3.2. Other definitions ..........................................5
3.2.1. Corporate Telecommunication Network (CN) ............5
3.2.2. Gateway .............................................6
3.2.3. IP Network ..........................................6
3.2.4. Media Stream ........................................6
3.2.5. Private Integrated Services Network (PISN) ..........6
3.2.6. Private Integrated Services Network Exchange
(PINX) ..............................................6
4. Acronyms ........................................................6
5. Background and Architecture .....................................7
6. Overview .......................................................10
7. General Requirements ...........................................11
8. Message Mapping Requirements ...................................12
8.1. Message Validation and Handling of Protocol Errors ........12
8.2. Call Establishment from QSIG to SIP .......................14
8.2.1. Call Establishment from QSIG to SIP Using
En Bloc Procedures .................................14
8.2.2. Call Establishment from QSIG to SIP Using
Overlap Procedures .................................16
8.3. Call Establishment from SIP to QSIG .......................20
8.3.1. Receipt of SIP INVITE Request for a New Call .......20
8.3.2. Receipt of QSIG CALL PROCEEDING Message ............21
8.3.3. Receipt of QSIG PROGRESS Message ...................22
8.3.4. Receipt of QSIG ALERTING Message ...................22
8.3.5. Inclusion of SDP Information in a SIP 18x
Provisional Response ...............................23
8.3.6. Receipt of QSIG CONNECT Message ....................24
8.3.7. Receipt of SIP PRACK Request .......................25
8.3.8. Receipt of SIP ACK Request .........................25
8.3.9. Receipt of a SIP INVITE Request for a Call
Already Being ......................................25
8.4. Call Clearing and Call Failure ............................26
8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or
RELEASE COMPLETE ...................................26
8.4.2. Receipt of a SIP BYE Request .......................29
8.4.3. Receipt of a SIP CANCEL Request ....................29
8.4.4. Receipt of a SIP 4xx-6xx Response to an
INVITE Request .....................................29
8.4.5. Gateway-Initiated Call Clearing ....................32
8.5. Request to Change Media Characteristics ...................32
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Definitions .....................................................5
3.1. External Definitions .......................................5
3.2. Other definitions ..........................................5
3.2.1. Corporate Telecommunication Network (CN) ............5
3.2.2. Gateway .............................................6
3.2.3. IP Network ..........................................6
3.2.4. Media Stream ........................................6
3.2.5. Private Integrated Services Network (PISN) ..........6
3.2.6. Private Integrated Services Network Exchange
(PINX) ..............................................6
4. Acronyms ........................................................6
5. Background and Architecture .....................................7
6. Overview .......................................................10
7. General Requirements ...........................................11
8. Message Mapping Requirements ...................................12
8.1. Message Validation and Handling of Protocol Errors ........12
8.2. Call Establishment from QSIG to SIP .......................14
8.2.1. Call Establishment from QSIG to SIP Using
En Bloc Procedures .................................14
8.2.2. Call Establishment from QSIG to SIP Using
Overlap Procedures .................................16
8.3. Call Establishment from SIP to QSIG .......................20
8.3.1. Receipt of SIP INVITE Request for a New Call .......20
8.3.2. Receipt of QSIG CALL PROCEEDING Message ............21
8.3.3. Receipt of QSIG PROGRESS Message ...................22
8.3.4. Receipt of QSIG ALERTING Message ...................22
8.3.5. Inclusion of SDP Information in a SIP 18x
Provisional Response ...............................23
8.3.6. Receipt of QSIG CONNECT Message ....................24
8.3.7. Receipt of SIP PRACK Request .......................25
8.3.8. Receipt of SIP ACK Request .........................25
8.3.9. Receipt of a SIP INVITE Request for a Call
Already Being ......................................25
8.4. Call Clearing and Call Failure ............................26
8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or
RELEASE COMPLETE ...................................26
8.4.2. Receipt of a SIP BYE Request .......................29
8.4.3. Receipt of a SIP CANCEL Request ....................29
8.4.4. Receipt of a SIP 4xx-6xx Response to an
INVITE Request .....................................29
8.4.5. Gateway-Initiated Call Clearing ....................32
8.5. Request to Change Media Characteristics ...................32
9. Number Mapping .................................................32
9.1. Mapping from QSIG to SIP ..................................33
9.1.1. Using Information from the QSIG Called
Party Number Information Element ...................33
9.1.2. Using Information from the QSIG Calling
Party Number Information Element ...................33
9.1.3. Using Information from the QSIG Connected
Number Information Element .........................35
9.2. Mapping from SIP to QSIG ..................................36
9.2.1. Generating the QSIG Called Party Number
Information Element ................................36
9.2.2. Generating the QSIG Calling Party Number
Information Element ................................37
9.2.3. Generating the QSIG Connected Number
Information Element ................................38
10. Requirements for Support of Basic Services ....................39
10.1. Derivation of QSIG Bearer Capability Information
Element ..................................................39
10.2. Derivation of Media Type in SDP ..........................39
11. Security Considerations .......................................40
11.1. General ..................................................40
11.2. Calls from QSIG to Invalid or Restricted Numbers .........40
11.3. Abuse of SIP Response Code ...............................41
11.4. Use of the To Header URI .................................41
11.5. Use of the From Header URI ...............................41
11.6. Abuse of Early Media .....................................42
11.7. Protection from Denial-of-Service Attacks ................42
12. Acknowledgements ..............................................43
13. Normative References ..........................................43
Appendix A. Example Message Sequences .............................45
9. Number Mapping .................................................32
9.1. Mapping from QSIG to SIP ..................................33
9.1.1. Using Information from the QSIG Called
Party Number Information Element ...................33
9.1.2. Using Information from the QSIG Calling
Party Number Information Element ...................33
9.1.3. Using Information from the QSIG Connected
Number Information Element .........................35
9.2. Mapping from SIP to QSIG ..................................36
9.2.1. Generating the QSIG Called Party Number
Information Element ................................36
9.2.2. Generating the QSIG Calling Party Number
Information Element ................................37
9.2.3. Generating the QSIG Connected Number
Information Element ................................38
10. Requirements for Support of Basic Services ....................39
10.1. Derivation of QSIG Bearer Capability Information
Element ..................................................39
10.2. Derivation of Media Type in SDP ..........................39
11. Security Considerations .......................................40
11.1. General ..................................................40
11.2. Calls from QSIG to Invalid or Restricted Numbers .........40
11.3. Abuse of SIP Response Code ...............................41
11.4. Use of the To Header URI .................................41
11.5. Use of the From Header URI ...............................41
11.6. Abuse of Early Media .....................................42
11.7. Protection from Denial-of-Service Attacks ................42
12. Acknowledgements ..............................................43
13. Normative References ..........................................43
Appendix A. Example Message Sequences .............................45
This document specifies signalling interworking between QSIG and the Session Initiation Protocol (SIP) in support of basic services within a corporate telecommunication network (CN) (also known as enterprise network).
本文件规定了QSIG和会话启动协议（SIP）之间的信令互通，以支持企业电信网络（CN）（也称为企业网络）内的基本服务。
QSIG is a signalling protocol that operates between Private Integrated Services eXchanges (PINX) within a Private Integrated Services Network (PISN). A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in Ecma Standards; in particular, [2] (call control in support of basic services), [3] (generic functional protocol for the support of supplementary services), and a number of standards specifying individual supplementary services.
QSIG是一种信令协议，在专用综合业务网（PISN）内的专用综合业务交换机（PINX）之间运行。PISN为用户提供电路交换基本业务和补充业务。Ecma标准中规定了QSIG；具体而言，[2]（支持基本业务的呼叫控制）、[3]（支持补充业务的通用功能协议）以及规定单个补充业务的若干标准。
NOTE: The name QSIG was derived from the fact that it is used for signalling at the Q reference point. The Q reference point is a point of demarcation between two PINXs.
注：QSIG的名称来源于它用于Q参考点的信令。Q参考点是两个pinx之间的分界点。
SIP is an application-layer protocol for establishing, terminating, and modifying multimedia sessions. It is typically carried over IP [15], [16]. Telephone calls are considered a type of multimedia session where just audio is exchanged. SIP is defined in [10].
SIP是用于建立、终止和修改多媒体会话的应用层协议。它通常通过IP[15]、[16]进行传输。电话通话被认为是一种仅交换音频的多媒体会话。SIP在[10]中有定义。
As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will coexist in many networks for a period, perhaps several years. Therefore, there is a need to be able to establish, modify, and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG.
随着公司网络中对电话技术的支持从电路交换技术发展到互联网技术，这两种技术将在许多网络中共存一段时间，也许几年。因此，需要能够建立、修改和终止涉及SIP网络中的参与者和QSIG网络中的参与者的会话。此类呼叫由在SIP和QSIG之间执行互通的网关支持。
This document specifies SIP-QSIG signalling interworking for basic services that provide a bi-directional transfer capability for speech, DTMF, facsimile, and modem media between a PISN employing QSIG and a corporate IP network employing SIP. Other aspects of interworking, e.g., the use of RTP and SDP, will differ according to the type of media concerned and are outside the scope of this specification.
本文件规定了基本服务的SIP-QSIG信令互通，这些服务为采用QSIG的PISN和采用SIP的企业IP网络之间的语音、DTMF、传真和调制解调器媒体提供双向传输能力。互通的其他方面，例如RTP和SDP的使用，将根据相关媒体的类型而有所不同，不在本规范的范围内。
Call-related and call-independent signalling in support of supplementary services is outside the scope of this specification, but support for certain supplementary services (e.g., call transfer, call diversion) could be the subject of future work.
支持补充业务的呼叫相关和呼叫独立信令不在本规范的范围内，但支持某些补充业务（例如，呼叫转移、呼叫转移）可能是未来工作的主题。
Interworking between QSIG and SIP permits a call originating at a user of a PISN to terminate at a user of a corporate IP network, or a call originating at a user of a corporate IP network to terminate at a user of a PISN.
QSIG和SIP之间的互通允许在PISN用户处发起的呼叫在公司IP网络的用户处终止，或者在公司IP网络的用户处发起的呼叫在PISN的用户处终止。
Interworking between a PISN employing QSIG and a public IP network employing SIP is outside the scope of this specification. However, the functionality specified in this specification is in principle applicable to such a scenario when deployed in conjunction with other relevant functionality (e.g., number translation, security functions, etc.).
采用QSIG的PISN和采用SIP的公共IP网络之间的互通不在本规范的范围内。然而，当与其他相关功能（例如，数字翻译、安全功能等）一起部署时，本规范中规定的功能原则上适用于此类场景。
This specification is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and a corporate IP network employing SIP.
本规范适用于可作为采用QSIG的PISN和采用SIP的企业IP网络之间网关的任何互通单元。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[4]中的描述进行解释，并表示符合SIP实施的要求级别。
For the purposes of this specification, the following definitions apply.
在本规范中，以下定义适用。
The definitions in [2] and [10] apply as appropriate.
[2]和[10]中的定义适用。
Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users.
位于地理位置分散的私人拥有或运营商提供的设备集，这些设备相互连接以向定义的用户组提供电信服务。
NOTE: A CN can comprise a PISN, a private IP network (intranet), or a combination of the two.
注：CN可以包括PISN、专用IP网络（intranet）或两者的组合。
An entity that performs interworking between a PISN using QSIG and an IP network using SIP.
在使用QSIG的PISN和使用SIP的IP网络之间执行互通的实体。
A network (unless otherwise stated, a corporate network) offering connectionless packet-mode services based on the Internet Protocol (IP) as the network-layer protocol.
基于作为网络层协议的互联网协议（IP），提供无连接分组模式服务的网络（除非另有说明，公司网络）。
Audio or other user information transmitted in UDP packets, typically containing RTP, in a single direction between the gateway and a peer entity participating in a session established using SIP.
在网关和参与使用SIP建立的会话的对等实体之间，以UDP数据包（通常包含RTP）在单个方向上传输的音频或其他用户信息。
NOTE: Normally a SIP session establishes a pair of media streams, one in each direction.
注意：通常SIP会话建立一对媒体流，每个方向一个。
A CN or part of a CN that employs circuit-switched technology.
采用电路交换技术的CN或CN的一部分。
A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance with [2].
一种PISN节点实体，包括交换和呼叫处理功能，并根据[2]支持QSIG信令。
DNS Domain Name Service IP Internet Protocol PINX Private Integrated services Network eXchange PISN Private Integrated Services Network RTP Real-time Transport Protocol SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol TLS Transport Layer Security TU Transaction User UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol
DNS域名服务IP互联网协议PINX专用综合业务网交换PISN专用综合业务网RTP实时传输协议SCTP流控制传输协议SDP会话描述协议SIP会话发起协议TCP传输控制协议TLS传输层安全协议事务用户UA用户代理UAC用户代理客户端UAS用户代理服务器UDP用户数据报协议
During the 1980s, corporate voice telecommunications adopted technology similar in principle to Integrated Services Digital Networks (ISDN). Digital circuit switches, commonly known as Private Branch eXchanges (PBX) or more formally as Private Integrated services Network eXchanges (PINX) have been interconnected by digital transmission systems to form Private Integrated Services Networks (PISN). These digital transmission systems carry voice or other payload in fixed-rate channels, typically 64 Kbit/s, and signalling in a separate channel. A technique known as common channel signalling is employed, whereby a single signalling channel potentially controls a number of payload channels or bearer channels. A typical arrangement is a point-to-point transmission facility at T1 or E1 rate providing a 64 Kbit/s signalling channel and 23 or 30 bearer channels, respectively. Other arrangements are possible and have been deployed, including the use of multiple transmission facilities for a signalling channel and its logically associated bearer channels. Also, arrangements involving bearer channels at sub-64 Kbit/s have been deployed, where voice payload requires the use of codecs that perform compression.
20世纪80年代，公司语音电信采用了原则上类似于综合业务数字网（ISDN）的技术。数字电路交换机（通常称为专用分支交换机（PBX）或更正式的专用综合业务网络交换机（PINX））已通过数字传输系统互连，形成专用综合业务网络（PISN）。这些数字传输系统在固定速率信道（通常为64 Kbit/s）中承载语音或其他有效载荷，并在单独的信道中承载信令。采用一种称为公共信道信令的技术，其中单个信令信道潜在地控制多个有效负载信道或承载信道。典型的配置是T1或E1速率的点对点传输设施，分别提供64 Kbit/s信令信道和23或30个承载信道。其他安排是可能的，并且已经部署，包括对信令信道及其逻辑关联的承载信道使用多个传输设施。此外，还部署了以低于64 Kbit/s的速率涉及承载信道的安排，其中语音有效载荷要求使用执行压缩的编解码器。
QSIG is the internationally-standardized message-based signalling protocol for use in networks as described above. It runs in a signalling channel between two PINXs and controls calls on a number of logically associated bearer channels between the same two PINXs. The signalling channel and its logically associated bearer channels are collectively known as an inter-PINX link. QSIG is independent of the type of transmission capabilities over which the signalling channel and bearer channels are provided. QSIG is also independent of the transport protocol used to transport QSIG messages reliably over the signalling channel.
QSIG是国际标准化的基于消息的信令协议，用于上述网络。它在两个PINX之间的信令信道中运行，并控制相同两个PINX之间的多个逻辑关联承载信道上的呼叫。信令信道及其逻辑关联的承载信道统称为PINX间链路。QSIG独立于提供信令信道和承载信道的传输能力类型。QSIG还独立于用于通过信令信道可靠传输QSIG消息的传输协议。
QSIG provides a means for establishing and clearing calls that originate and terminate on different PINXs. A call can be routed over a single inter-PINX link connecting the originating and terminating PINX, or over several inter-PINX links in series with switching at intermediate PINXs known as transit PINXs. A call can originate or terminate in another network, in which case it enters or leaves the PISN environment through a gateway PINX. Parties are identified by numbers, in accordance with either [17] or a private numbering plan. This basic call capability is specified in [2]. In addition to basic call capability, QSIG specifies a number of further capabilities supporting the use of supplementary services in PISNs.
QSIG提供了一种建立和清除在不同PINX上发起和终止的调用的方法。呼叫可以通过连接始发和终止PINX的单个PINX间链路路由，也可以通过多个串联的PINX间链路路由，并在中间PINX（称为传输PINX）处切换。呼叫可以在另一个网络中发起或终止，在这种情况下，它通过网关PINX进入或离开PISN环境。根据[17]或私人编号计划，各方通过编号进行识别。[2]中规定了此基本呼叫功能。除了基本呼叫能力外，QSIG还规定了一些支持PISN中使用补充业务的进一步能力。
More recently, corporate telecommunications networks have started to exploit IP in various ways. One way is to migrate part of the network to IP using SIP. This might, for example, be a new branch
最近，企业电信网络开始以各种方式利用IP。一种方法是使用SIP将部分网络迁移到IP。例如，这可能是一个新分支
office with a SIP proxy and SIP endpoints instead of a PINX. Alternatively, SIP equipment might be used to replace an existing PINX or PINXs. The new SIP environment needs to interwork with the QSIG-based PISN in order to support calls originating in one environment and terminating in the other. Interworking is achieved through a gateway.
使用SIP代理和SIP端点而不是PINX的office。或者，可以使用SIP设备替换现有的PINX或PINX。新的SIP环境需要与基于QSIG的PISN互通，以便支持在一个环境中发起并在另一个环境中终止的呼叫。互通是通过网关实现的。
Interworking between QSIG and SIP at gateways can also be used where a SIP network interconnects different parts of a PISN, thereby allowing calls between the different parts. A call can enter the SIP network at one gateway and leave at another. Each gateway would behave in accordance with this specification.
当SIP网络互连PISN的不同部分时，也可以在网关上使用QSIG和SIP之间的互通，从而允许在不同部分之间进行呼叫。呼叫可以在一个网关进入SIP网络，然后在另一个网关离开。每个网关将按照本规范运行。
Another way of connecting two parts of a PISN would be to encapsulate QSIG signalling in SIP messages for calls between the two parts. This is outside the scope of this specification but could be the subject of future work.
连接PISN两部分的另一种方法是将QSIG信令封装在SIP消息中，用于两部分之间的呼叫。这超出了本规范的范围，但可能是未来工作的主题。
This document specifies signalling protocol interworking aspects of a gateway between a PISN employing QSIG signalling and an IP network employing SIP signalling. The gateway appears as a PINX to other PINXs in the PISN. The gateway appears as a SIP endpoint to other SIP entities in the IP network. The environment is shown in Figure 1.
本文件规定了采用QSIG信令的PISN和采用SIP信令的IP网络之间网关的信令协议互通方面。网关显示为PISN中其他PINX的PINX。网关显示为IP网络中其他SIP实体的SIP端点。环境如图1所示。
+------+ IP network PISN
| |
|SIP | +------+
|Proxy | /| |
| | / |PINX |
+---+--+ *-----------+ / | |
| | | +-----+/ +------+
| | | | |
| | | |PINX |
---+-----+-------+--------+ Gateway +--------| |
| | | | | |\
| | | | +-----+ \
| | | | \ +------+
| | | | \| |
+--+---+ +--+---+ *-----------+ |PINX |
|SIP | |SIP | | |
|End- | |End- | +------+
|point | |point |
+------+ +------+
+------+ IP network PISN
| |
|SIP | +------+
|Proxy | /| |
| | / |PINX |
+---+--+ *-----------+ / | |
| | | +-----+/ +------+
| | | | |
| | | |PINX |
---+-----+-------+--------+ Gateway +--------| |
| | | | | |\
| | | | +-----+ \
| | | | \ +------+
| | | | \| |
+--+---+ +--+---+ *-----------+ |PINX |
|SIP | |SIP | | |
|End- | |End- | +------+
|point | |point |
+------+ +------+
Figure 1: Environment
图1：环境
In addition to the signalling interworking functionality specified in this specification, it is assumed that the gateway also includes the following functionality:
除了本规范中规定的信令互通功能外，假定网关还包括以下功能：
- one or more physical interfaces on the PISN side supporting one or more inter-PINX links, each link providing one or more constant bit rate channels for media streams and a reliable layer 2 connection (e.g., over a fixed rate physical channel) for transporting QSIG signalling messages; and
- PISN侧上的一个或多个物理接口支持一个或多个PINX链路，每个链路为媒体流提供一个或多个恒定比特率信道，以及用于传输QSIG信令消息的可靠第2层连接（例如，通过固定速率物理信道）；和
- one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2 protocols, IP as the network layer protocol and UDP [6] and TCP [5] as transport layer protocols, these being used for the transport of SIP signalling messages and, in the case of UDP, also for media streams;
- IP网络侧的一个或多个物理接口，通过第1层和第2层协议，支持IP作为网络层协议，UDP[6]和TCP[5]作为传输层协议，用于传输SIP信令消息，在UDP的情况下，还支持媒体流；
- optionally the support of TLS [7] and/or SCTP [9] as additional transport layer protocols on the IP network side, these being used for the transport of SIP signalling messages; and
- 可选地，支持TLS[7]和/或SCTP[9]作为IP网络侧的附加传输层协议，这些协议用于传输SIP信令消息；和
- a means of transferring media streams in each direction between the PISN and the IP network, including as a minimum packetization of media streams sent to the IP network and de-packetization of media streams received from the IP network.
- 一种在PISN和IP网络之间沿每个方向传输媒体流的装置，包括发送到IP网络的媒体流的最小分组和从IP网络接收的媒体流的去分组。
NOTE: [10] mandates support for both UDP and TCP for the transport of SIP messages and allows optional support for TLS and/or SCTP for this same purpose.
注意：[10]强制要求支持UDP和TCP传输SIP消息，并允许出于相同目的可选支持TLS和/或SCTP。
The protocol model relevant to signalling interworking functionality of a gateway is shown in Figure 2.
与网关的信令互通功能相关的协议模型如图2所示。
+---------------------------------------------------------+
| Interworking function |
| |
+-----------------------+---------+-----------------------+
| | | |
| SIP | | |
| | | |
+-----------------------+ | |
| | | |
| UDP/TCP/TLS/SCTP | | QSIG |
| | | |
+-----------------------+ | |
| | | |
| IP | | |
| | | |
+-----------------------+ +-----------------------+
| IP network | | PISN |
| lower layers | | lower layers |
| | | |
+-----------------------+ +-----------------------+
+---------------------------------------------------------+
| Interworking function |
| |
+-----------------------+---------+-----------------------+
| | | |
| SIP | | |
| | | |
+-----------------------+ | |
| | | |
| UDP/TCP/TLS/SCTP | | QSIG |
| | | |
+-----------------------+ | |
| | | |
| IP | | |
| | | |
+-----------------------+ +-----------------------+
| IP network | | PISN |
| lower layers | | lower layers |
| | | |
+-----------------------+ +-----------------------+
Figure 2: Protocol model
图2：协议模型
In Figure 2, the SIP box represents SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer. The Interworking function includes SIP Transaction User (TU) functionality.
在图2中，SIP框表示SIP语法和编码、SIP传输层和SIP事务层。互通功能包括SIP事务用户（TU）功能。
The gateway maps received QSIG messages, where appropriate, to SIP messages and vice versa and maintains an association between a QSIG call and a SIP dialog.
网关将接收到的QSIG消息适当地映射到SIP消息，反之亦然，并维护QSIG呼叫和SIP对话之间的关联。
A call from QSIG to SIP is initiated when a QSIG SETUP message arrives at the gateway. The QSIG SETUP message initiates QSIG call establishment, and an initial response message (e.g., CALL PROCEEDING) completes negotiation of the bearer channel to be used for that call. The gateway then sends a SIP INVITE request, having translated the QSIG called party number to a URI suitable for inclusion in the Request-URI. The SIP INVITE request and the resulting SIP dialog, if successfully established, are associated with the QSIG call. The SIP 2xx response to the INVITE request is mapped to a QSIG CONNECT message, signifying answer of the call. During establishment, media streams established by SIP and SDP are connected to the bearer channel.
当QSIG设置消息到达网关时，启动从QSIG到SIP的呼叫。QSIG设置消息发起QSIG呼叫建立，并且初始响应消息（例如，呼叫进行）完成用于该呼叫的承载信道的协商。网关然后发送SIP INVITE请求，将QSIG被叫方号码转换为适合包含在请求URI中的URI。SIP INVITE请求和生成的SIP对话框（如果成功建立）与QSIG调用相关联。对INVITE请求的SIP 2xx响应映射到QSIG CONNECT消息，表示呼叫应答。在建立期间，由SIP和SDP建立的媒体流连接到承载信道。
A call from SIP to QSIG is initiated when a SIP INVITE request arrives at the gateway. The gateway sends a QSIG SETUP message to initiate QSIG call establishment, having translated the SIP Request-URI to a number suitable for use as the QSIG called party number. The resulting QSIG call is associated with the SIP INVITE request and with the eventual SIP dialog. Receipt of an initial QSIG response message completes negotiation of the bearer channel to be used, allowing media streams established by SIP and SDP to be connected to that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 OK response to the INVITE request.
当SIP INVITE请求到达网关时，启动从SIP到QSIG的呼叫。网关发送QSIG设置消息以启动QSIG呼叫建立，并将SIP请求URI转换为适合用作QSIG被叫方号码的号码。产生的QSIG调用与SIP INVITE请求和最终的SIP对话框相关联。初始QSIG响应消息的接收完成了要使用的承载信道的协商，允许SIP和SDP建立的媒体流连接到该承载信道。QSIG CONNECT消息映射到对INVITE请求的SIP 200 OK响应。
Appendix A gives examples of typical message sequences that can arise.
附录A给出了可能出现的典型消息序列的示例。
In order to conform to this specification, a gateway SHALL support QSIG in accordance with [2] as a gateway and SHALL support SIP in accordance with [10] as a UA. In particular, the gateway SHALL support SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer in accordance with [10]. In addition, the gateway SHALL support SIP TU behaviour for a UA in accordance with [10] except where stated otherwise in Sections 8, 9, and 10 of this specification.
为了符合本规范，网关应按照[2]支持QSIG作为网关，并按照[10]支持SIP作为UA。特别是，网关应根据[10]支持SIP语法和编码、SIP传输层和SIP事务层。此外，根据[10]，网关应支持UA的SIP TU行为，除非本规范第8、9和10节另有规定。
NOTE: [10] mandates that a SIP entity support both UDP and TCP as transport layer protocols for SIP messages. Other transport layer protocols can also be supported.
注意：[10]要求SIP实体同时支持UDP和TCP作为SIP消息的传输层协议。还可以支持其他传输层协议。
The gateway SHALL also support SIP reliable provisional responses in accordance with [11] as a UA.
网关还应根据[11]作为UA支持SIP可靠的临时响应。
NOTE: [11] makes provision for recovering from loss of provisional responses (other than 100) to INVITE requests when using unreliable transport services in the IP network. This is important for ensuring delivery of responses that map to essential QSIG messages.
注：[11]规定在IP网络中使用不可靠传输服务时，从临时响应（100除外）的丢失中恢复邀请请求。这对于确保提供映射到基本QSIG消息的响应非常重要。
The gateway SHALL support SDP in accordance with [8] and its use in accordance with the offer/answer model in [12].
网关应根据[8]支持SDP，并根据[12]中的提供/应答模型支持SDP的使用。
Section 9 also specifies optional use of the Privacy header in accordance with [13] and the P-Asserted-Identity header in accordance with [14].
第9节还规定了根据[13]的隐私报头和根据[14]的P-Asserted-Identity报头的可选使用。
The gateway SHALL support calls from QSIG to SIP and calls from SIP to QSIG.
网关应支持从QSIG到SIP的呼叫以及从SIP到QSIG的呼叫。
SIP methods not defined in [10] or [11] are outside the scope of this specification but could be the subject of other specifications for interworking with QSIG, e.g., for interworking in support of supplementary services.
[10]或[11]中未定义的SIP方法不在本规范范围内，但可能是与QSIG互通的其他规范的主题，例如，用于支持补充业务的互通。
As a result of DNS lookup by the gateway in order to determine where to send a SIP INVITE request, a number of candidate destinations can be attempted in sequence. The way in which this is handled by the gateway is outside the scope of this specification. However, any behaviour specified in this document on receipt of a SIP 4xx or 5xx final response to an INVITE request SHOULD apply only when there are no more candidate destinations to try or when overlap signalling applies in the SIP network (see 8.2.2.2).
作为网关进行DNS查找以确定向何处发送SIP INVITE请求的结果，可以按顺序尝试多个候选目的地。网关处理此问题的方式不在本规范的范围内。然而，本文件中规定的在收到对INVITE请求的SIP 4xx或5xx最终响应时的任何行为，应仅在没有更多候选目的地可供尝试或SIP网络中应用重叠信令时适用（见8.2.2.2）。
The gateway SHALL validate received QSIG messages in accordance with the requirements of [2] and SHALL act in accordance with [2] on detection of a QSIG protocol error. The requirements of this section for acting on a received QSIG message apply only to a received QSIG message that has been successfully validated and that satisfies one of the following conditions:
网关应根据[2]的要求验证收到的QSIG消息，并在检测到QSIG协议错误时按照[2]采取行动。本节对接收到的QSIG报文采取行动的要求仅适用于已成功验证且满足以下条件之一的接收到的QSIG报文：
-the QSIG message is a SETUP message and indicates a destination in the IP network and a bearer capability for which the gateway is able to provide interworking; or
-QSIG消息是设置消息，并且指示IP网络中的目的地和网关能够为其提供互通的承载能力；或
-the QSIG message is a message other than SETUP and contains a call reference that identifies an existing call for which the gateway is providing interworking between QSIG and SIP.
-QSIG消息不是SETUP消息，它包含一个呼叫引用，用于标识网关正在QSIG和SIP之间为其提供互通的现有呼叫。
The processing of any valid QSIG message that does not satisfy any of these conditions is outside the scope of this specification. Also, the processing of any QSIG message relating to call-independent signalling connections or connectionless transport, as specified in [3], is outside the scope of this specification.
不满足这些条件的任何有效QSIG消息的处理不在本规范的范围内。此外，如[3]所述，与呼叫独立信令连接或无连接传输相关的任何QSIG消息的处理不在本规范的范围内。
If segmented QSIG messages are received, the gateway SHALL await receipt of all segments of a message and SHALL validate and act on the complete reassembled message.
如果收到分段QSIG消息，网关应等待收到消息的所有分段，并应对完整的重新组装消息进行验证和操作。
The gateway SHALL validate received SIP messages (requests and responses) in accordance with the requirements of [10] and SHALL act in accordance with [10] on detection of a SIP protocol error.
网关应根据[10]的要求验证收到的SIP消息（请求和响应），并在检测到SIP协议错误时根据[10]采取行动。
Requirements of this section for acting on a received SIP message apply only to a received message that has been successfully validated and that satisfies one of the following conditions:
本节对接收到的SIP消息采取行动的要求仅适用于已成功验证且满足以下条件之一的接收到的消息：
- the SIP message is an INVITE request that contains no tag parameter in the To header field, does not match an ongoing transaction (i.e., is not a merged request; see Section 8.2.2.2 of [10]), and indicates a destination in the PISN for which the gateway is able to provide interworking; or
- SIP消息是一个INVITE请求，在To报头字段中不包含标记参数，与正在进行的事务不匹配（即，不是合并请求；参见[10]第8.2.2.2节），并指示PISN中网关能够提供互通的目的地；或
- the SIP message is a request that relates to an existing dialog representing a call for which the gateway is providing interworking between QSIG and SIP; or
- SIP消息是与表示网关正在为其提供QSIG和SIP之间的互通的呼叫的现有对话相关的请求；或
- the SIP message is a CANCEL request that relates to a received INVITE request for which the gateway is providing interworking with QSIG but for which the only response sent is informational (1xx), no dialog having been confirmed; or
- SIP消息是一个取消请求，该请求与所接收到的INVITE请求有关，网关正在为该请求提供与QSIG的互通，但发送的唯一响应是信息性的（1xx），尚未确认对话；或
- the SIP message is a response to a request sent by the gateway in accordance with this section.
- SIP消息是对网关根据本节发送的请求的响应。
The processing of any valid SIP message that does not satisfy any of these conditions is outside the scope of this specification.
不满足这些条件的任何有效SIP消息的处理不在本规范的范围内。
NOTE: These rules mean that an error detected in a received message will not be propagated to the other side of the gateway. However, there can be an indirect impact on the other side of the gateway, e.g., the initiation of call clearing procedures.
注意：这些规则意味着在接收到的消息中检测到的错误不会传播到网关的另一端。但是，可能会对网关的另一端产生间接影响，例如，启动呼叫清除程序。
The gateway SHALL run QSIG protocol timers as specified in [2] and SHALL act in accordance with [2] if a QSIG protocol timer expires. Any other action on expiry of a QSIG protocol timer is outside the scope of this specification, except that if it results in the clearing of the QSIG call, the gateway SHALL also clear the SIP call in accordance with Section 8.4.5.
网关应按照[2]中的规定运行QSIG协议计时器，并在QSIG协议计时器过期时按照[2]进行操作。QSIG协议计时器到期时的任何其他操作不在本规范的范围内，除非其导致QSIG呼叫被清除，网关还应根据第8.4.5节清除SIP呼叫。
The gateway SHALL run SIP protocol timers as specified in [10] and SHALL act in accordance with [10] if a SIP protocol timer expires. Any other action on expiry of a SIP protocol timer is outside the scope of this specification, except that if it results in the clearing of the SIP call, the gateway SHALL also clear the QSIG call in accordance with Section 8.4.5.
网关应按照[10]中的规定运行SIP协议计时器，并且如果SIP协议计时器过期，则应按照[10]进行操作。SIP协议计时器到期时的任何其他操作不在本规范的范围内，除非其导致SIP呼叫被清除，网关还应根据第8.4.5节清除QSIG呼叫。
The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending Complete information element or the gateway receives a QSIG SETUP message and is able to determine that the number in the Called party number information element is complete.
当网关接收到包含发送完整信息元素的QSIG设置消息或网关接收到QSIG设置消息并且能够确定被叫方号码信息元素中的号码完整时，以下步骤适用。
NOTE: In the absence of a Sending Complete information element, the means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or use of inter-digit timer expiry.
注意：在没有发送完整信息元素的情况下，网关确定要完成的号码的方法是一个实现问题。它可能涉及编号计划的知识和/或数字间计时器的使用。
On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in the Called party number information element, or containing a Sending complete information element and a number that could potentially be complete, the gateway SHALL map the QSIG SETUP message to a SIP INVITE request. The gateway SHALL also send a QSIG CALL PROCEEDING message.
收到QSIG设置消息后，网关应将QSIG设置消息映射到SIP INVITE请求，该消息包含网关确定在被叫方号码信息元素中完整的号码，或包含发送完整信息元素和可能完整的号码。网关还应发送QSIG呼叫继续消息。
The gateway SHALL generate the SIP Request-URI, To, and From fields in the SIP INVITE request in accordance with Section 9. The gateway SHALL include in the INVITE request a Supported header containing option tag 100rel, to indicate support for [11].
网关应根据第9节生成SIP INVITE请求中的SIP请求URI、To和From字段。网关应在INVITE请求中包含一个支持的标题，其中包含选项标记100rel，以表示对[11]的支持。
The gateway SHALL include SDP offer information in the SIP INVITE request as described in Section 10. It SHOULD also connect the incoming media stream to the user information channel of the inter-PINX link, to allow the caller to hear in-band tones or announcements and prevent speech clipping on answer. Because of forking, the gateway may receive more than one media stream, in which case it SHOULD select one (e.g., the first received). If the gateway is able to correlate an unselected media stream with a particular early dialog established using a reliable provisional response, it MAY use the UPDATE method [19] to stop that stream and then use the UPDATE method to start that stream again if a 2xx response is received on that dialog.
网关应在SIP INVITE请求中包含SDP提供信息，如第10节所述。它还应将传入的媒体流连接到PINX间链路的用户信息通道，以允许呼叫者听到带内铃声或公告，并防止应答时出现语音剪辑。由于分叉，网关可以接收多个媒体流，在这种情况下，它应该选择一个（例如，第一个接收的媒体流）。如果网关能够将未选择的媒体流与使用可靠临时响应建立的特定早期对话相关联，则它可以使用更新方法[19]停止该流，然后如果在该对话上接收到2xx响应，则使用更新方法再次启动该流。
On receipt of a QSIG SETUP message containing a Sending complete information element and a number that the gateway determines to be incomplete in the Called party number information element, the gateway SHALL initiate QSIG call clearing procedures using cause value 28, "invalid number format (address incomplete)".
在收到包含发送完整信息元素和网关确定被叫方号码信息元素中不完整的号码的QSIG设置消息后，网关应使用原因值28“无效号码格式（地址不完整）”，启动QSIG呼叫清除程序。
If information in the QSIG SETUP message is unsuitable for generating any of the mandatory fields in a SIP INVITE request (e.g., if a Request-URI cannot be derived from the QSIG Called party number information element) or for generating SDP information, the gateway SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call clearing procedures in accordance with [2].
如果QSIG设置消息中的信息不适合生成SIP INVITE请求中的任何必填字段（例如，如果请求URI无法从QSIG被叫方号码信息元素派生），或者不适合生成SDP信息，网关不得发出SIP INVITE请求，并应根据[2]启动QSIG呼叫清除程序。
A SIP 100 response SHALL NOT trigger any QSIG messages. It only serves the purpose of suppressing INVITE request retransmissions.
SIP 100响应不应触发任何QSIG消息。它仅用于抑制INVITE请求重传。
The gateway SHALL map a received SIP 18x response to an INVITE request to a QSIG PROGRESS or ALERTING message based on the following conditions.
网关应根据以下条件将接收到的SIP 18x响应与INVITE请求映射到QSIG进度或警报消息。
- If a SIP 180 response is received and no QSIG ALERTING message has been sent, the gateway SHALL generate a QSIG ALERTING message. The gateway MAY supply ring-back tone on the user information channel of the inter-PINX link, in which case the gateway SHALL include progress description number 8 in the QSIG ALERTING message. Otherwise the gateway SHALL NOT include progress description number 8 in the QSIG ALERTING message unless the gateway is aware that in-band information (e.g., ring-back tone) is being transmitted.
- 如果收到SIP 180响应且未发送QSIG警报消息，则网关应生成QSIG警报消息。网关可在PINX间链路的用户信息通道上提供回铃音，在这种情况下，网关应在QSIG警报消息中包含进度描述编号8。否则，网关不应在QSIG警报消息中包含进度描述编号8，除非网关知道正在传输带内信息（例如，回铃音）。
- If a SIP 181/182/183 response is received, no QSIG ALERTING message has been sent, and no message containing progress description number 1 has been sent, the gateway SHALL generate a QSIG PROGRESS message containing progress description number 1.
- 如果收到SIP 181/182/183响应，未发送QSIG警报消息，且未发送包含进度描述编号1的消息，则网关应生成包含进度描述编号1的QSIG进度消息。
NOTE: This will ensure that QSIG timer T310 is stopped if running at the Originating PINX.
注：这将确保QSIG定时器T310在初始PINX下运行时停止。
In all other scenarios, the gateway SHALL NOT map the SIP 18x response to a QSIG message.
在所有其他情况下，网关不得将SIP 18x响应映射到QSIG消息。
If the SIP 18x response contains a Require header with option tag 100rel, the gateway SHALL send back a SIP PRACK request in accordance with [11].
如果SIP 18x响应包含带有选项标签100rel的Require报头，则网关应根据[11]发回SIP PRACK请求。
If the gateway receives a SIP 2xx response as the first SIP 2xx response to a SIP INVITE request, the gateway SHALL map the SIP 2xx response to a QSIG CONNECT message. The gateway SHALL also send a SIP ACK request to acknowledge the 2xx response. The gateway SHALL
如果网关接收到SIP 2xx响应作为对SIP INVITE请求的第一个SIP 2xx响应，则网关应将SIP 2xx响应映射到QSIG CONNECT消息。网关还应发送SIP ACK请求，以确认2xx响应。网关应
NOT include any SDP information in the SIP ACK request. If the gateway receives further 2xx responses, it SHALL respond to each in accordance with [10], SHOULD issue a BYE request for each, and SHALL NOT generate any further QSIG messages.
在SIP ACK请求中不包括任何SDP信息。如果网关收到进一步的2xx响应，则应根据[10]对每个响应进行响应，并应为每个响应发出BYE请求，且不得生成任何进一步的QSIG消息。
Media streams will normally have been established in the IP network in each direction. If so, the gateway SHALL connect the media streams to the corresponding user-information channel on the inter-PINX link if it has not already done so and stop any local ring-back tone.
媒体流通常已在IP网络的每个方向上建立。如果是这样，网关应将媒体流连接到PINX间链路上的相应用户信息通道（如果尚未连接），并停止任何本地回铃音。
If the SIP 2xx response is received in response to the SIP PRACK request, the gateway SHALL NOT map this message to any QSIG message.
如果收到SIP 2xx响应以响应SIP PRACK请求，则网关不得将此消息映射到任何QSIG消息。
NOTE: A SIP 2xx response to the INVITE request can be received later on a different dialog as a result of a forking proxy.
注意：对于INVITE请求的SIP 2xx响应可以稍后在另一个对话框上接收，这是分叉代理的结果。
On receipt of a SIP 3xx response to an INVITE request, the gateway SHALL act in accordance with [10].
在收到对INVITE请求的SIP 3xx响应后，网关应按照[10]进行操作。
NOTE: This will normally result in sending a new SIP INVITE request.
注意：这通常会导致发送新的SIP INVITE请求。
Unless the gateway supports the QSIG Call Diversion Supplementary Service, no QSIG message SHALL be sent. The definition of Call Diversion Supplementary Service for QSIG to SIP interworking is beyond the scope of this specification.
除非网关支持QSIG呼叫转移补充业务，否则不应发送QSIG消息。QSIG到SIP互通的呼叫转移补充业务的定义超出了本规范的范围。
SIP uses en bloc signalling, and it is strongly RECOMMENDED to avoid using overlap signalling in a SIP network. A SIP/QSIG gateway dealing with overlap signalling SHOULD perform a conversion from overlap to en bloc signalling method using one or more of the following mechanisms:
SIP使用整体信令，强烈建议避免在SIP网络中使用重叠信令。处理重叠信令的SIP/QSIG网关应使用以下一种或多种机制执行从重叠到整体信令方法的转换：
- timers;
- 计时器；
- numbering plan information;
- 编号计划信息；
- the presence of a Sending complete information element in a received QSIG INFORMATION message.
- 接收到的QSIG信息报文中存在发送完整信息元素。
If the gateway performs a conversion from overlap to en bloc signalling in the SIP network, then the procedures defined in Section 8.2.2.1 SHALL apply.
如果网关在SIP网络中执行从重叠到整体信令的转换，则第8.2.2.1节中定义的程序应适用。
However, for some applications it might be impossible to avoid using overlap signalling in the SIP network. In this case, the procedures defined in Section 8.2.2.2 SHALL apply.
然而，对于某些应用程序，可能无法避免在SIP网络中使用重叠信令。在这种情况下，应适用第8.2.2.2节中规定的程序。
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in the Called party number information element that the gateway cannot determine to be complete, the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start QSIG timer T302, and await further number digits.
在收到不包含发送完整信息元素和被叫方号码信息元素中网关无法确定是否完整的号码的QSIG设置消息后，网关应发送回QSIG设置确认消息，启动QSIG定时器T302，并等待更多数字。
On receipt of each QSIG INFORMATION message containing no Sending complete information element and containing a number that the gateway cannot determine to be complete, QSIG timer T302 SHALL be restarted. When QSIG timer T302 expires or a QSIG INFORMATION message containing a Sending complete information element is received, the gateway SHALL send a SIP INVITE request as described in Section 8.2.1.1. The Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages. The gateway SHALL also send a QSIG CALL PROCEEDING message.
在收到不包含发送完整信息元素且包含网关无法确定为完整的数字的每个QSIG信息消息后，应重新启动QSIG定时器T302。当QSIG定时器T302到期或收到包含发送完整信息元素的QSIG信息消息时，网关应发送第8.2.1.1节所述的SIP INVITE请求。请求URI和To字段（见第9节）应通过接收的QSIG设置和信息消息中被叫方号码信息元素中的信息串联生成。网关还应发送QSIG呼叫继续消息。
SIP responses to INVITE requests SHALL be mapped as described in 8.2.1.
INVITE请求的SIP响应应按照8.2.1所述进行映射。
The procedures below for using overlap signalling in the SIP network are in accordance with the principles described in [18] for using overlap sending when interworking with ISDN User Part (ISUP). In [18], there is discussion of some potential problems arising from the use of overlap sending in the SIP network. These potential problems are applicable also in the context of QSIG-SIP interworking and can be avoided if overlap sending in the QSIG network is terminated at the gateway, in accordance with Section 8.2.2.1. The procedures below should be used only where it is not feasible to use the procedures of Section 8.2.2.1.
以下在SIP网络中使用重叠信令的过程符合[18]中描述的与ISDN用户部分（ISUP）互通时使用重叠发送的原则。在[18]中，讨论了由于在SIP网络中使用重叠发送而产生的一些潜在问题。这些潜在问题也适用于QSIG-SIP互通，如果按照第8.2.2.1节，QSIG网络中的重叠发送在网关处终止，则可以避免这些潜在问题。仅当使用第8.2.2.1节中的程序不可行时，才应使用以下程序。
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in the Called party number information element that the gateway cannot determine to be complete, the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and start QSIG timer T302. If the QSIG SETUP message contains the minimum number of digits required to route the call in the IP network, the gateway SHALL send a SIP INVITE request as specified in Section 8.2.1.1. Otherwise, the gateway SHALL wait for more digits to arrive in QSIG INFORMATION messages.
在收到不包含发送完整信息元素和被叫方号码信息元素中网关无法确定是否完整的号码的QSIG设置消息后，网关应发送回QSIG设置确认消息，并启动QSIG定时器T302。如果QSIG设置消息包含IP网络中路由呼叫所需的最小位数，则网关应按照第8.2.1.1节的规定发送SIP INVITE请求。否则，网关应等待更多数字到达QSIG信息消息。
On receipt of a QSIG INFORMATION message, the gateway SHALL handle the QSIG timer T302 in accordance with [2].
收到QSIG信息消息后，网关应按照[2]处理QSIG定时器T302。
NOTE: [2] requires the QSIG timer to be stopped if the INFORMATION message contains a Sending complete information element or to be restarted otherwise.
注：[2]要求在信息消息包含发送完整信息元素时停止QSIG计时器，否则重新启动QSIG计时器。
Further behaviour of the gateway SHALL depend on whether or not it has already sent a SIP INVITE request. If the gateway has not sent a SIP INVITE request and it now has the minimum number of digits required to route the call, it SHALL send a SIP INVITE request as specified in Section 8.2.2.1.2. If the gateway still does not have the minimum number of digits required, it SHALL wait for more QSIG INFORMATION messages to arrive.
网关的进一步行为应取决于其是否已发送SIP INVITE请求。如果网关尚未发送SIP INVITE请求，且其现在具有路由呼叫所需的最小位数，则应按照第8.2.2.1.2节的规定发送SIP INVITE请求。如果网关仍然没有所需的最小位数，则应等待更多QSIG信息消息到达。
If the gateway has already sent one or more SIP INVITE requests, whether or not final responses to those requests have been received, it SHALL send a new SIP INVITE request in accordance with Section 3.2 of [18]. The updated Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages.
如果网关已经发送了一个或多个SIP INVITE请求，无论是否收到对这些请求的最终响应，它都应根据[18]第3.2节发送新的SIP INVITE请求。更新的请求URI和To字段（见第9节）应通过接收的QSIG设置和信息消息中被叫方号码信息元素中的信息连接生成。
NOTE: [18] requires the new request to have the same Call-ID and the same From header (including tag) as in the previous INVITE request. [18] recommends that the CSeq header should contain a value higher than that in the previous INVITE request.
注意：[18]要求新请求具有与上一个INVITE请求相同的调用ID和From头（包括标记）。[18] 建议CSeq标头包含的值应高于上一个INVITE请求中的值。
The requirements of Section 8.2.1.2 SHALL apply.
第8.2.1.2节的要求应适用。
The requirements of Section 8.2.1.3 SHALL apply.
第8.2.1.3节的要求应适用。
The requirements of Section 8.2.1.4 SHALL apply. In addition, the gateway SHALL send a SIP CANCEL request in accordance with Section 3.4 of [18] to cancel any SIP INVITE transactions for which no final response has been received.
第8.2.1.4节的要求应适用。此外，网关应根据[18]第3.4节发送SIP取消请求，以取消尚未收到最终响应的任何SIP INVITE交易。
The requirements of Section 8.2.1.5 SHALL apply.
第8.2.1.5节的要求应适用。
8.2.2.2.7. Receipt of a SIP 4xx, 5xx, or 6xx Final Response to an INVITE Request
8.2.2.2.7. 收到对INVITE请求的SIP 4xx、5xx或6xx最终响应
On receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request, the gateway SHALL send back a SIP ACK request. Unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL also send a QSIG DISCONNECT message (8.4.4) if no further QSIG INFORMATION messages are expected and final responses have been received to all transmitted SIP INVITE requests.
在收到对INVITE请求的SIP 4xx、5xx或6xx最终响应后，网关应发回SIP ACK请求。除非网关能够重试INVITE请求以避免问题（例如，在401或407响应的情况下通过提供身份验证），否则，如果预期没有进一步的QSIG信息消息，并且已收到对所有传输的SIP INVITE请求的最终响应，则网关还应发送QSIG断开连接消息（8.4.4）。
NOTE: Further QSIG INFORMATION messages will not be expected after QSIG timer T302 has expired or after a Sending complete information element has been received.
注：在QSIG定时器T302过期或接收到发送完整信息元素后，预计不会出现更多QSIG信息消息。
In all other cases, the receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request SHALL NOT trigger the sending of any QSIG message.
在所有其他情况下，收到对INVITE请求的SIP 4xx、5xx或6xx最终响应不应触发任何QSIG消息的发送。
NOTE: If further QSIG INFORMATION messages arrive, these will result in further SIP INVITE requests being sent, one of which might result in successful call establishment. For example, initial INVITE requests might produce 484 (Address Incomplete) or 404 (Not Found) responses because the Request-URIs derived from incomplete numbers cannot be routed, yet a subsequent INVITE request with a routable Request-URI might produce a 2xx final response or a more meaningful 4xx, 5xx, or 6xx final response.
注意：如果更多的QSIG信息消息到达，这些消息将导致发送更多的SIP INVITE请求，其中一个请求可能会导致成功建立呼叫。例如，初始INVITE请求可能会生成484（地址不完整）或404（未找到）响应，因为无法路由由不完整数字派生的请求URI，但具有可路由请求URI的后续INVITE请求可能会生成2xx最终响应或更有意义的4xx、5xx或6xx最终响应。
Section 3.3 of [18] applies.
[18]第3.3节适用。
As stated in Section 3.4 of [18], when a gateway sends a new SIP INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL request to cancel a previous SIP INVITE transaction that has not had a final response. This SIP CANCEL request could arrive at an egress gateway before the new SIP INVITE request and trigger premature call clearing.
如[18]第3.4节所述，当网关发送包含新数字的新SIP INVITE请求时，它不应发送SIP CANCEL请求以取消之前没有最终响应的SIP INVITE事务。此SIP取消请求可能在新SIP INVITE请求之前到达出口网关，并触发过早的呼叫清除。
NOTE: Previous SIP INVITE transactions can be expected to result in SIP 4xx class responses, which terminate the transaction. In Section 8.2.2.2.5, there is provision for cancelling any transactions still in progress after a SIP 2xx response has been received.
注意：以前的SIP INVITE事务可能会导致SIP 4xx类响应，从而终止事务。在第8.2.2.2.5节中，规定了在收到SIP 2xx响应后取消仍在进行中的任何交易。
If QSIG timer T302 expires and the gateway has received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway has not received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL ignore any further QSIG INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at this stage.
如果QSIG定时器T302过期，并且网关已收到对所有传输的SIP INVITE请求的4xx、5xx或6xx响应，则网关应发送QSIG DISCONTECT消息。如果T302过期，并且网关尚未收到对所有传输的SIP INVITE请求的4xx、5xx或6xx响应，则网关应忽略任何进一步的QSIG信息消息，但在此阶段不应发送QSIG断开连接消息。
NOTE: A QSIG DISCONNECT request will be sent when all outstanding SIP INVITE requests have received 4xx, 5xx, or 6xx responses.
注意：当所有未完成的SIP INVITE请求收到4xx、5xx或6xx响应时，将发送QSIG断开连接请求。
On receipt of a SIP INVITE request for a new call, if a suitable channel is available on the inter-PINX link, the gateway SHALL generate a QSIG SETUP message from the received SIP INVITE request. The gateway SHALL generate the Called party number and Calling party number information elements in accordance with Section 9 and SHALL generate the Bearer capability information element in accordance with Section 10. If the gateway can determine that the number placed in the Called party number information element is complete, the gateway MAY include the Sending complete information element.
在收到新呼叫的SIP INVITE请求时，如果PINX间链路上有合适的信道可用，网关应根据收到的SIP INVITE请求生成QSIG设置消息。网关应根据第9节生成被叫方号码和主叫方号码信息元素，并根据第10节生成承载能力信息元素。如果网关可以确定放置在被叫方号码信息元素中的号码是完整的，则网关可以包括发送完整信息元素。
NOTE: The means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or use of the inter-digit timer.
注意：网关确定要完成的数量的方法是一个实现问题。它可能涉及编号计划的知识和/或数字间计时器的使用。
The gateway SHOULD send a SIP 100 (Trying) response.
网关应发送SIP 100（尝试）响应。
If information in the SIP INVITE request is unsuitable for generating any of the mandatory information elements in a QSIG SETUP message (e.g., if a QSIG Called party number information element cannot be derived from SIP Request-URI field) or if no suitable channel is available on the inter-PINX link, the gateway SHALL NOT issue a QSIG SETUP message and SHALL send a SIP 4xx, 5xx, or 6xx response. If no suitable channel is available, the gateway should use response code 503 (Service Unavailable).
如果SIP INVITE请求中的信息不适合生成QSIG设置消息中的任何强制信息元素（例如，如果QSIG被叫方号码信息元素无法从SIP请求URI字段中导出），或者如果PINX间链路上没有合适的信道可用，网关不得发出QSIG设置消息，并应发送SIP 4xx、5xx或6xx响应。如果没有合适的通道可用，网关应使用响应代码503（服务不可用）。
If the SIP INVITE request does not contain SDP information and does not contain either a Required header or a Supported header with option tag 100rel, the gateway SHOULD still proceed as above, although an implementation can instead send a SIP 488 (Not Acceptable Here) response, in which case it SHALL NOT issue a QSIG SETUP message.
如果SIP INVITE请求不包含SDP信息，也不包含所需的报头或带有选项标记100rel的受支持报头，则网关仍应如上所述进行，尽管实现可以改为发送SIP 488（此处不可接受）响应，在这种情况下，它不应发出QSIG设置消息。
NOTE: The absence of SDP offer information in the SIP INVITE request means that the gateway might need to send SDP offer information in a provisional response and receive SDP answer information in a SIP PRACK request (in accordance with [11]) in order to ensure that tones and announcements from the PISN are transmitted. SDP offer information cannot be sent in an unreliable provisional response because SDP answer information would need to be returned in a SIP PRACK request. The recommendation above still to proceed with call establishment in this situation reflects the desire to maximise the chances of a successful call. However, if important in-band information is likely to be denied in this situation, a gateway can choose not to proceed.
注意：SIP INVITE请求中缺少SDP offer信息意味着网关可能需要在临时响应中发送SDP offer信息，并在SIP PRACK请求中接收SDP应答信息（根据[11]），以确保来自PISN的音调和通知被传输。无法以不可靠的临时响应发送SDP提供信息，因为需要在SIP PRACK请求中返回SDP应答信息。在这种情况下，仍建议继续建立呼叫，这反映了最大化呼叫成功机会的愿望。但是，如果在这种情况下重要的带内信息可能被拒绝，网关可以选择不继续。
NOTE: If SDP offer information is present in the INVITE request, the issuing of a QSIG SETUP message is not dependent on the presence of a Required header or a Supported header with option tag 100rel.
注意：如果INVITE请求中存在SDP报价信息，则QSIG设置消息的发出不取决于是否存在所需的标题或带有选项标记100rel的受支持标题。
On receipt of a SIP INVITE request relating to a call that has already been established from SIP to QSIG, the procedures of 8.3.9 SHALL apply.
收到SIP INVITE请求后，应适用8.3.9中的程序，该请求与SIP与QSIG之间已建立的呼叫有关。
The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any SIP message being sent.
发送的任何QSIG消息不得导致正在进行的任何QSIG消息的接收。
A QSIG PROGRESS message can be received in the event of interworking on the remote side of the PISN or if the PISN is unable to complete the call and generates an in-band tone or announcement. In the latter case, a Cause information element is included in the QSIG PROGRESS message.
在PISN远程侧互通的情况下，或者PISN无法完成呼叫并生成带内音调或公告的情况下，可以接收QSIG进度消息。在后一种情况下，原因信息元素包含在QSIG进度消息中。
The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 (Session Progress) response to the INVITE request. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the gateway SHALL include in the SIP 183 response a Require header with option tag 100rel.
网关应将收到的QSIG进度消息映射到对INVITE请求的SIP 183（会话进度）响应。如果SIP INVITE请求包含Require报头或带有选项标记100rel的受支持报头，则网关应在SIP 183响应中包含带有选项标记100rel的Require报头。
NOTE: In accordance with [11], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [11] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received.
注：根据[11]，在临时响应中包含选项标签100rel指示UAC通过发送PRACK请求确认临时响应。[11] 还指定了在未收到PRACK时，使用选项标记100rel重复临时响应的程序。
If the QSIG PROGRESS message contained a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response to the INVITE request or has already been sent or received. Inclusion of SDP offer or answer information in the 183 provisional response SHALL be in accordance with Section 8.3.5.
如果QSIG进度消息包含进度说明编号为1或8的进度指示器信息元素，则网关应将媒体流连接至PINX间链路的相应用户信息通道（如果尚未连接），前提是SDP应答信息包括在对INVITE请求的传输SIP响应中，或者已经发送或接收。183临时回复中的SDP报价或应答信息应符合第8.3.5节的规定。
If the QSIG PROGRESS message is received with a Cause information element, the gateway SHALL either wait until the tone/announcement is complete or has been applied for sufficient time before initiating call clearing, or wait for a SIP CANCEL request. If call clearing is initiated, the cause value in the QSIG PROGRESS message SHALL be used to derive the response to the SIP INVITE request in accordance with Table 1.
如果接收到带有原因信息元素的QSIG进度消息，则网关应在启动呼叫清除之前等待，直到音调/公告完成或应用了足够的时间，或者等待SIP取消请求。如果启动呼叫清除，应根据表1使用QSIG进度消息中的原因值来推导对SIP INVITE请求的响应。
The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) response to the INVITE request. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the gateway SHALL include in the SIP 180 response a Require header with option tag 100rel.
网关应将QSIG警报消息映射到对INVITE请求的SIP 180（振铃）响应。如果SIP INVITE请求包含Require报头或带有选项标记100rel的受支持报头，则网关应在SIP 180响应中包含带有选项标记100rel的Require报头。
NOTE: In accordance with [11], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [11] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received.
注：根据[11]，在临时响应中包含选项标签100rel指示UAC通过发送PRACK请求确认临时响应。[11] 还指定了在未收到PRACK时，使用选项标记100rel重复临时响应的程序。
If the QSIG ALERTING message contained a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response or has already been sent or received. Inclusion of SDP offer or answer information in the 180 provisional response SHALL be in accordance with Section 8.3.5.
如果QSIG警报消息包含进度说明编号为1或8的进度指示器信息元素，则网关应将媒体流连接至PINX链路的相应用户信息通道（如果尚未连接），前提是SDP应答信息包括在发送的SIP响应中，或者已经发送或接收。应根据第8.3.5节的规定，在180份临时回复中包含SDP报价或应答信息。
When sending a SIP 18x provisional response to the INVITE request, if a QSIG message containing a Progress indicator information element with progress description number 1 or 8 has been received the gateway SHALL include SDP information. Otherwise, the gateway MAY include SDP information. If SDP information is included, it shall be in accordance with the following rules.
当向INVITE请求发送SIP 18x临时响应时，如果收到包含进度指示器信息元素（进度描述编号为1或8）的QSIG消息，则网关应包括SDP信息。否则，网关可以包括SDP信息。如果包含SDP信息，则应符合以下规则。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 18x provisional response.
如果SIP INVITE请求包含带有选项标签100rel的必需或支持的标头，并且如果SDP提供和应答信息已经交换，则SIP 18x临时响应中不应包含SDP信息。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer information was received in the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 18x provisional response.
如果SIP INVITE请求包含一个带有选项标签100rel的必需或支持的报头，并且如果在SIP INVITE请求中收到SDP offer信息，但没有发送SDP应答信息，则SDP应答信息应包含在SIP 18x临时响应中。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if no SDP offer information was received in the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 18x provisional response.
如果SIP INVITE请求包含带有选项标签100rel的必需或受支持的标头，并且如果SIP INVITE请求中未收到SDP要约信息，且未发送SDP要约信息，则SDP要约信息应包含在SIP 18x临时响应中。
NOTE: In this case, SDP answer information can be expected in the SIP PRACK.
注意：在这种情况下，可以在SIP PRACK中预期SDP应答信息。
If the SIP INVITE request contained neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 18x provisional response.
如果SIP INVITE请求既不包含必需的标头，也不包含带有选项标记100rel的受支持标头，则应在SIP 18x临时响应中包含SDP应答信息。
NOTE: Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final SIP 2xx response.
注意：由于临时响应不可靠，SDP应答信息需要在每个临时响应和最终SIP 2xx响应中重复。
NOTE: If the SIP INVITE request contained no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it should have been rejected in accordance with Section 8.3.1.
注：如果SIP INVITE请求不包含SDP报价信息，也不包含带有选项标签100rel的必需或支持的标题，则应根据第8.3.1节的规定拒绝该请求。
The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final response for the SIP INVITE request. The gateway SHALL also send a QSIG CONNECT ACKNOWLEDGE message.
网关应将QSIG CONNECT消息映射到SIP INVITE请求的SIP 200（OK）最终响应。网关还应发送QSIG CONNECT确认消息。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 200 response.
如果SIP INVITE请求包含带有选项标签100rel的必需或支持的报头，并且如果SDP提供和应答信息已经交换，则SIP 200响应中不应包含SDP信息。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer information was received in the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 200 response.
如果SIP INVITE请求包含带有选项标签100rel的必需或支持的报头，并且如果在SIP INVITE请求中接收到SDP offer信息，但没有发送SDP应答信息，则SDP应答信息应包含在SIP 200应答中。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if no SDP offer information was received in the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 200 response.
如果SIP INVITE请求包含带有选项标签100rel的所需或支持的报头，并且如果SIP INVITE请求中未收到SDP要约信息，且未发送SDP要约信息，则SDP要约信息应包含在SIP 200响应中。
NOTE: In this case, SDP answer information can be expected in the SIP ACK.
注意：在这种情况下，可以在SIP ACK中预期SDP应答信息。
If the SIP INVITE request contained neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 200 response.
如果SIP INVITE请求既不包含必需的标头，也不包含带有选项标记100rel的受支持标头，则应在SIP 200响应中包含SDP应答信息。
NOTE: Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final 2xx response.
注：由于临时响应不可靠，SDP应答信息需要在每个临时响应和最终2xx响应中重复。
NOTE: If the SIP INVITE request contained no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it may have been rejected in accordance with Section 8.3.1.
注：如果SIP INVITE请求不包含SDP报价信息，也不包含带有选项标签100rel的必需或支持的标题，则根据第8.3.1节，该请求可能已被拒绝。
The gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response or has already been sent or received.
网关应将媒体流连接至PINX间链路的相应用户信息通道（如果尚未连接），前提是SDP应答信息包含在传输的SIP响应中或已发送或接收。
The receipt of a SIP PRACK request acknowledging a reliable provisional response SHALL NOT result in any QSIG message being sent. The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK request.
收到确认可靠临时响应的SIP PRACK请求不得导致发送任何QSIG消息。网关应向SIP PRACK请求发回SIP 200（OK）响应。
If the SIP PRACK contains SDP answer information and a QSIG message containing a Progress indicator information element with progress description number 1 or 8 has been received, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link.
如果SIP PRACK包含SDP应答信息，并且已接收到包含进度指示器信息元素（进度描述编号为1或8）的QSIG消息，则网关应将媒体流连接到PINX间链路的相应用户信息通道。
The receipt of a SIP ACK request SHALL NOT result in any QSIG message being sent.
收到SIP ACK请求不得导致发送任何QSIG消息。
If the SIP ACK contains SDP answer information, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so.
如果SIP ACK包含SDP应答信息，则网关应将媒体流连接至PINX间链路的相应用户信息通道（如果尚未连接）。
8.3.9. Receipt of a SIP INVITE Request for a Call Already Being Established
8.3.9. 接收已建立呼叫的SIP INVITE请求
A gateway can receive a call from SIP using overlap procedures. This should occur when the UAC for the INVITE request is a gateway from a network that employs overlap procedures (e.g., an ISUP gateway or another QSIG gateway) and the gateway has not absorbed overlap.
网关可以使用重叠过程接收来自SIP的呼叫。当INVITE请求的UAC是来自采用重叠过程的网络的网关（例如，ISUP网关或另一个QSIG网关）且网关未吸收重叠时，应发生这种情况。
For a call from SIP using overlap procedures, the gateway will receive multiple SIP INVITE requests that belong to the same call but have different Request-URI and To fields. Each SIP INVITE request belongs to a different dialog.
对于使用重叠过程的SIP呼叫，网关将接收属于同一呼叫但具有不同请求URI和to字段的多个SIP INVITE请求。每个SIP INVITE请求属于不同的对话框。
A SIP INVITE request is considered to be for the purpose of overlap sending if, compared to a previously received SIP INVITE request, it has:
如果与先前接收的SIP INVITE请求相比，SIP INVITE请求具有以下特征，则视为用于重叠发送：
- the same Call-ID header; - the same From header (including the tag); - no tag in the To header;
- 相同的呼叫ID头；-与标题相同（包括标签）；-To标题中没有标签；
- an updated Request-URI from which can be derived a called party number with a superset of the digits derived from the previously received SIP INVITE request;
- 更新的请求URI，从该URI可以派生被叫方号码，该被叫方号码具有从先前接收的SIP INVITE请求派生的数字超集；
and if
如果
- the gateway has not yet sent a final response other than 484 to the previously received SIP INVITE request.
- 网关尚未向先前接收的SIP INVITE请求发送除484之外的最终响应。
If a gateway receives a SIP INVITE request for the purpose of overlap sending, it SHALL generate a QSIG INFORMATION message using the call reference of the existing QSIG call instead of a new QSIG SETUP message and containing only the additional digits in the Called party number information element. It SHALL also respond to the SIP INVITE request received previously with a SIP 484 Address Incomplete response.
如果网关出于重叠发送的目的接收到SIP INVITE请求，则其应使用现有QSIG呼叫的呼叫参考而不是新的QSIG设置消息生成QSIG信息消息，并且仅包含被叫方号码信息元素中的附加数字。它还应使用SIP 484地址不完整响应响应先前接收到的SIP INVITE请求。
If a gateway receives a SIP INVITE request that meets all of the conditions for a SIP INVITE request for the purpose of overlap sending except the condition concerning the Request-URI, the gateway SHALL respond to the new request with a SIP 485 (Ambiguous) response.
如果网关接收到满足SIP INVITE请求的所有条件的SIP INVITE请求，用于重叠发送，但与请求URI有关的条件除外，则网关应使用SIP 485（不明确）响应来响应新请求。
8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE Message
8.4.1. 收到QSIG断开、释放或释放完成消息
On receipt of QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE message as the first QSIG call clearing message, gateway behaviour SHALL depend on the state of call establishment.
在收到QSIG断开、释放或释放完成消息作为第一条QSIG呼叫清除消息时，网关行为应取决于呼叫建立的状态。
1) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE request and received a SIP ACK request, or if it has received a SIP 200 (OK) response to a SIP INVITE request and sent a SIP ACK request, the gateway SHALL send a SIP BYE request to clear the call.
1) 如果网关已向SIP INVITE请求发送SIP 200（OK）响应并收到SIP ACK请求，或者如果网关已收到SIP INVITE请求的SIP 200（OK）响应并发送SIP ACK请求，则网关应发送SIP BYE请求以清除呼叫。
2) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE request (indicating that call establishment is complete) but has not received a SIP ACK request, the gateway SHALL wait until a SIP ACK is received and then send a SIP BYE request to clear the call.
2) 如果网关已向SIP INVITE请求发送SIP 200（OK）响应（指示呼叫建立已完成），但尚未收到SIP ACK请求，则网关应等待收到SIP ACK，然后发送SIP BYE请求以清除呼叫。
3) If the gateway has sent a SIP INVITE request and received a SIP provisional response but not a SIP final response, the gateway SHALL send a SIP CANCEL request to clear the call.
3) 如果网关已发送SIP INVITE请求并收到SIP临时响应，但未收到SIP最终响应，则网关应发送SIP取消请求以清除呼叫。
NOTE 1: In accordance with [10], if after sending a SIP CANCEL request a SIP 2xx response is received to the SIP INVITE request, the gateway will need to send a SIP BYE request.
注1：根据[10]，如果在发送SIP取消请求后，收到SIP INVITE请求的SIP 2xx响应，网关将需要发送SIP BYE请求。
4) If the gateway has sent a SIP INVITE request but received no SIP response, the gateway SHALL NOT send a SIP message. If a SIP final or provisional response is subsequently received, the gateway SHALL then act in accordance with 1, 2, or 3 above, respectively.
4) 如果网关已发送SIP INVITE请求但未收到SIP响应，则网关不应发送SIP消息。如果随后接收到SIP最终或临时响应，则网关应分别按照上述1、2或3进行操作。
5) If the gateway has received a SIP INVITE request but not sent a SIP final response, the gateway SHALL send a SIP final response chosen according to the cause value in the received QSIG message as specified in Table 1. SIP response 500 (Server internal error) SHALL be used as the default for cause values not shown in Table 1.
5) 如果网关已收到SIP INVITE请求，但未发送SIP最终响应，则网关应发送根据表1中规定的接收QSIG消息中的原因值选择的SIP最终响应。SIP响应500（服务器内部错误）应作为表1中未显示的原因值的默认值。
NOTE 2: It is not necessarily appropriate to map some QSIG cause values to SIP messages because these cause values are meaningful only at the gateway. A good example of this is cause value 44, "Requested circuit or channel not available", which signifies that the channel number in the transmitted QSIG SETUP message was not acceptable to the peer PINX. The appropriate behavior in this case is for the gateway to send another SETUP message indicating a different channel number. If this is not possible, the gateway should treat it either as a congestion situation (no channels available; see Section 8.3.1) or as a gateway failure situation (in which case the default SIP response code applies).
注2：将某些QSIG原因值映射到SIP消息并不一定合适，因为这些原因值仅在网关上有意义。原因值44是一个很好的例子，“请求的电路或通道不可用”，这表示对等PINX不接受传输的QSIG设置消息中的通道号。在这种情况下，网关的适当行为是发送另一条指示不同通道号的设置消息。如果这是不可能的，网关应将其视为拥塞情况（没有可用通道；请参阅第8.3.1节）或网关故障情况（在这种情况下，默认SIP响应代码适用）。
In all cases, the gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.
在所有情况下，网关还应断开媒体流（如果建立），并允许QSIG和SIP信令分别按照[2]和[10]完成。
Table 1: Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an INVITE request
表1:QSIG原因值到SIP 4xx-6xx对INVITE请求的响应的映射
QSIG Cause value SIP response
----------------------------------------------------------------
1 Unallocated number 404 Not found
2 No route to specified 404 Not found
transit network
3 No route to destination 404 Not found
16 Normal call clearing (NOTE 3)
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 603 Decline, if location field
in Cause information element
indicates user. Otherwise:
403 Forbidden
22 Number changed 301 Moved permanently, if
information in diagnostic field
of Cause information element is
suitable for generating a SIP
Contact header. Otherwise:
410 Gone
23 Redirection to new 410 Gone
destination
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
34 No circuit/channel 503 Service unavailable
available
38 Network out of order 503 Service unavailable
41 Temporary failure 503 Service unavailable
42 Switching equipment 503 Service unavailable
congestion
47 Resource unavailable, 503 Service unavailable
unspecified
55 Incoming calls barred 403 Forbidden
within CUG
57 Bearer capability not 403 Forbidden
authorized
58 Bearer capability not 503 Service unavailable
presently available
65 Bearer capability not 488 Not acceptable here (NOTE 4)
implemented
69 Requested facility not 501 Not implemented
implemented
QSIG Cause value SIP response
----------------------------------------------------------------
1 Unallocated number 404 Not found
2 No route to specified 404 Not found
transit network
3 No route to destination 404 Not found
16 Normal call clearing (NOTE 3)
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 603 Decline, if location field
in Cause information element
indicates user. Otherwise:
403 Forbidden
22 Number changed 301 Moved permanently, if
information in diagnostic field
of Cause information element is
suitable for generating a SIP
Contact header. Otherwise:
410 Gone
23 Redirection to new 410 Gone
destination
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
34 No circuit/channel 503 Service unavailable
available
38 Network out of order 503 Service unavailable
41 Temporary failure 503 Service unavailable
42 Switching equipment 503 Service unavailable
congestion
47 Resource unavailable, 503 Service unavailable
unspecified
55 Incoming calls barred 403 Forbidden
within CUG
57 Bearer capability not 403 Forbidden
authorized
58 Bearer capability not 503 Service unavailable
presently available
65 Bearer capability not 488 Not acceptable here (NOTE 4)
implemented
69 Requested facility not 501 Not implemented
implemented
70 Only restricted digital 488 Not acceptable here (NOTE 4) information available 79 Service or option not 501 Not implemented implemented, unspecified 87 User not member of CUG 403 Forbidden 88 Incompatible destination 503 Service unavailable 102 Recovery on timer expiry 504 Server time-out
70此处仅限用数字488不可接受（注4）信息可用79服务或选项未501未实施，未指定87用户非CUG 403成员禁止88不兼容目标503服务不可用102计时器到期时恢复504服务器超时
NOTE 3: A QSIG call clearing message containing cause value 16 will normally result in the sending of a SIP BYE or CANCEL request. However, if a SIP response is to be sent to the INVITE request, the default response code should be used.
注3：包含原因值16的QSIG呼叫清除消息通常会导致发送SIP BYE或CANCEL请求。但是，如果要向INVITE请求发送SIP响应，则应使用默认响应代码。
NOTE 4: The gateway may include a SIP Warning header if diagnostic information in the QSIG Cause information element allows a suitable warning code to be selected.
注4：如果QSIG原因信息元素中的诊断信息允许选择合适的警告代码，则网关可能包括SIP警告标头。
On receipt of a SIP BYE request, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing). The gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.
在收到SIP BYE请求时，网关应发送原因值为16（正常呼叫清除）的QSIG断开消息。网关还应断开媒体流（如果建立），并允许QSIG和SIP信令分别按照[2]和[10]完成。
NOTE: When responding to a SIP BYE request, in accordance with [10], the gateway is also required to respond to any other outstanding transactions, e.g., with a SIP 487 (Request Terminated) response. This applies in particular if the gateway has not yet returned a final response to the SIP INVITE request.
注：根据[10]响应SIP BYE请求时，网关还需要响应任何其他未完成的事务，例如，使用SIP 487（请求终止）响应。这尤其适用于网关尚未返回对SIP INVITE请求的最终响应的情况。
On receipt of a SIP CANCEL request to clear a call for which the gateway has not sent a SIP final response to the received SIP INVITE request, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing). The gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.
在收到SIP取消请求以清除网关尚未向接收到的SIP INVITE请求发送SIP最终响应的呼叫时，网关应发送原因值为16的QSIG DISCONNECT消息（正常呼叫清除）。网关还应断开媒体流（如果建立），并允许QSIG和SIP信令分别按照[2]和[10]完成。
Except where otherwise specified in the context of overlap sending (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP INVITE request, unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL transmit a QSIG DISCONNECT message. The cause value in the QSIG DISCONNECT message
除非在重叠发送（8.2.2.2）上下文中另有规定，否则在收到SIP INVITE请求的SIP最终响应（4xx-6xx）时，除非网关能够重试INVITE请求以避免问题（例如，在401或407响应的情况下通过提供身份验证），网关应发送QSIG断开消息。QSIG断开消息中的原因值
SHALL be derived from the SIP 4xx-6xx response according to Table 2. Cause value 31 (Normal, unspecified) SHALL be used as the default for SIP responses not shown in Table 2. The gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.
应根据表2从SIP 4xx-6xx响应中得出。原因值31（正常，未指定）应作为表2中未显示的SIP响应的默认值。网关还应断开媒体流（如果建立），并允许QSIG和SIP信令分别按照[2]和[10]完成。
When generating a QSIG Cause information element, the location field SHOULD contain the value "user", if generated as a result of a SIP response code 6xx, or the value "Private network serving the remote user" in other circumstances.
当生成QSIG原因信息元素时，位置字段应包含值“user”（如果由SIP响应代码6xx生成），或在其他情况下包含值“Private network Service the remote user”（为远程用户服务的专用网络）。
Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to QSIG Cause values
表2:INVITE请求的SIP 4xx-6xx响应与QSIG原因值的映射
SIP response QSIG Cause value (NOTE 6)
------------------------------------------------------------------
400 Bad request 41 Temporary failure
401 Unauthorized 21 Call rejected (NOTE 5)
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, unspecified
406 Not acceptable 79 Service or option not
implemented, unspecified
407 Proxy Authentication required 21 Call rejected (NOTE 5)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
413 Request entity too large 127 Interworking, unspecified
(NOTE 6)
414 Request-URI too long 127 Interworking, unspecified
(NOTE 6)
415 Unsupported media type 79 Service or option not
implemented, unspecified
(NOTE 6)
416 Unsupported URI scheme 127 Interworking, unspecified
(NOTE 6)
420 Bad extension 127 Interworking, unspecified
(NOTE 6)
421 Extension required 127 Interworking, unspecified
(NOTE 6)
423 Interval too brief 127 Interworking, unspecified
(NOTE 6)
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
SIP response QSIG Cause value (NOTE 6)
------------------------------------------------------------------
400 Bad request 41 Temporary failure
401 Unauthorized 21 Call rejected (NOTE 5)
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, unspecified
406 Not acceptable 79 Service or option not
implemented, unspecified
407 Proxy Authentication required 21 Call rejected (NOTE 5)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
413 Request entity too large 127 Interworking, unspecified
(NOTE 6)
414 Request-URI too long 127 Interworking, unspecified
(NOTE 6)
415 Unsupported media type 79 Service or option not
implemented, unspecified
(NOTE 6)
416 Unsupported URI scheme 127 Interworking, unspecified
(NOTE 6)
420 Bad extension 127 Interworking, unspecified
(NOTE 6)
421 Extension required 127 Interworking, unspecified
(NOTE 6)
423 Interval too brief 127 Interworking, unspecified
(NOTE 6)
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 (NOTE 6) 485 Ambiguous 1 Unallocated Number 486 Busy here 17 User busy 487 Request terminated (NOTE 7) 488 Not Acceptable Here 65 Bearer capability not implemented or 31 Normal, unspecified (NOTE 8) 500 Server internal error 41 Temporary failure 501 Not implemented 79 Service or option not implemented, unspecified 502 Bad gateway 38 Network out of order 503 Service unavailable 41 Temporary failure 504 Gateway time-out 102 Recovery on timer expiry 505 Version not supported 127 Interworking, unspecified (NOTE 6) 513 Message too large 127 Interworking, unspecified (NOTE 6) 600 Busy everywhere 17 User busy 603 Decline 21 Call rejected 604 Does not exist anywhere 1 Unallocated number 606 Not acceptable 65 Bearer capability not implemented or 31 Normal, unspecified (NOTE 8)
484地址不完整28无效数字格式（注6）485不明确1未分配数字486忙此处17用户忙487请求终止（注7）488不可接受此处65承载能力未实现或31正常，未指定（注8）500服务器内部错误41临时故障501未执行79服务或选项未执行，未指定502坏网关38网络故障503服务不可用41临时故障504网关超时102计时器到期时恢复505版本不支持127互通，未指定（注6）513消息太大127互通，未指定（注6）600忙无处不在17用户忙603拒绝21呼叫被拒绝604不存在任何位置1未分配号码606不可接受65承载能力未实现或31正常，未指定（注8）
NOTE 5: In some cases, it may be possible for the 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 authorize itself should the gateway clear the call in the QSIG network with this cause value.
注5：在某些情况下，网关可能会向由于授权失败而拒绝邀请的SIP UAS提供凭据。如果网关可以对自己进行身份验证，那么显然它应该这样做并继续调用。只有当网关无法自行授权时，网关才应使用此原因值清除QSIG网络中的呼叫。
NOTE 6: For some response codes, the gateway may be able to retry the INVITE request in order to work around the problem. In particular, this may be the case with response codes indicating a protocol error. The gateway SHOULD clear the call in the QSIG network with the indicated cause value only if retry is not possible or fails.
注意6：对于某些响应代码，网关可能能够重试INVITE请求以解决问题。具体而言，这可能是响应代码指示协议错误的情况。只有在无法重试或重试失败时，网关才应使用指示的原因值清除QSIG网络中的呼叫。
NOTE 7: The circumstances in which SIP response code 487 can be expected to arise do not require it to be mapped to a QSIG cause code, since the QSIG call will normally already be cleared or in the process of clearing. If QSIG call clearing does, however, need to be initiated, the default cause value should be used.
注7：预计会出现SIP响应代码487的情况不需要将其映射到QSIG原因代码，因为QSIG呼叫通常已经被清除或正在清除过程中。但是，如果确实需要启动QSIG呼叫清除，则应使用默认的原因值。
NOTE 8: When the Warning header is present in a SIP 606 or 488 message, the warning code should be examined to determine whether it is reasonable to generate cause value 65. This cause value should be generated only if there is a chance that a new call attempt with
注8：当SIP 606或488消息中存在警告标头时，应检查警告代码以确定生成原因值65是否合理。仅当有可能发生新呼叫尝试时，才应生成此原因值
different content in the Bearer capability information element will avoid the problem. In other circumstances, the default cause value should be used.
承载能力信息元素中的不同内容将避免该问题。在其他情况下，应使用默认的原因值。
If the gateway initiates clearing of the QSIG call owing to QSIG timer expiry, QSIG protocol error, or use of the QSIG RESTART message in accordance with [2], the gateway SHALL also initiate clearing of the SIP call in accordance with Section 8.4.1. If this involves the sending of a final response to a SIP INVITE request, the gateway SHALL use response code 480 (Temporarily Unavailable) if optional QSIG timer T301 has expired or, otherwise, response code 408 (Request timeout) or 500 (Server internal error), as appropriate.
如果网关因QSIG定时器到期、QSIG协议错误或根据[2]使用QSIG重启消息而启动QSIG呼叫的清除，则网关还应根据第8.4.1节启动SIP呼叫的清除。如果这涉及发送对SIP INVITE请求的最终响应，则如果可选QSIG定时器T301已过期，网关应使用响应代码480（暂时不可用），否则，响应代码408（请求超时）或500（服务器内部错误），视情况而定。
If the gateway initiates clearing of the SIP call owing to SIP timer expiry or SIP protocol error in accordance with [10], the gateway SHALL also initiate clearing of the QSIG call in accordance with [2] using cause value 102 (Recovery on timer expiry) or 41 (Temporary failure), as appropriate.
如果网关根据[10]由于SIP定时器到期或SIP协议错误而启动SIP呼叫的清除，则网关还应根据[2]使用原因值102（定时器到期时恢复）或41（临时故障）（视情况而定）启动QSIG呼叫的清除。
If after a call has been successfully established the gateway receives a SIP INVITE request to change the media characteristics of the call in a way that would be incompatible with the bearer capability in use within the PISN, the gateway SHALL send back a SIP 488 (Not Acceptable Here) response and SHALL NOT change the media characteristics of the existing call.
如果在呼叫成功建立后，网关接收到SIP INVITE请求，以与PISN内使用的承载能力不兼容的方式更改呼叫的媒体特征，则网关应发回SIP 488（此处不接受）响应，且不得改变现有通话的媒体特征。
In QSIG, users are identified by numbers, as defined in [1]. Numbers are conveyed within the Called party number, Calling party number, and Connected number information elements. The Calling party number and Connected number information elements also contain a presentation indicator, which can indicate that privacy is required (presentation restricted), and a screening indicator, which indicates the source and authentication status of the number.
在QSIG中，用户由数字标识，如[1]中所定义。号码在被叫方号码、主叫方号码和连接号码信息元素内传送。主叫方号码和连接号码信息元素还包含一个表示指示符，该指示符可指示需要隐私（表示受限），以及一个屏蔽指示符，该指示符指示号码的来源和认证状态。
In SIP, users are identified by Universal Resource Identifiers (URIs) conveyed within the Request-URI and various headers, including the From and To headers specified in [10] and optionally the P-Asserted-Identity header specified in [14]. In addition, privacy is indicated by the Privacy header specified in [13].
在SIP中，用户通过在请求URI和各种报头中传送的通用资源标识符（URI）来识别，包括[10]中指定的From和To报头以及[14]中指定的可选P-Asserted-Identity报头。此外，隐私由[13]中指定的隐私标头表示。
This clause specifies the mapping between QSIG Called party number, Calling party number, and Connected number information elements and corresponding elements in SIP.
本条款规定QSIG被叫方号码、主叫方号码、连接号码信息元素与SIP中相应元素之间的映射。
A gateway MAY implement the P-Asserted-Identity header in accordance with [14]. If a gateway implements the P-Asserted-Identity header, it SHALL also implement the Privacy header in accordance with [13]. If a gateway does not implement the P-Asserted-Identity header, it MAY implement the Privacy header.
网关可以根据[14]实现P-Asserted-Identity报头。如果网关实现了P-Asserted-Identity报头，它还应根据[13]实现隐私报头。如果网关没有实现P-Asserted-Identity报头，那么它可以实现隐私报头。
The method used to convert a number to a URI is outside the scope of this specification. However, the gateway SHOULD take account of the Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG information element concerned when interpreting a number.
用于将数字转换为URI的方法不在本规范的范围内。但是，在解释数字时，网关应考虑相关QSIG信息元素中的编号计划（NPI）和编号类型（TON）字段。
Some aspects of mapping depend on whether the gateway is in the same trust domain (as defined in [14]) as the next hop SIP node (i.e., the proxy or UA to which the INVITE request is sent or from which INVITE request is received) to honour requests for identity privacy in the Privacy header. This will be network-dependent, and it is RECOMMENDED that gateways supporting the P-Asserted-Identity header hold a configurable list of next hop nodes that are to be trusted in this respect.
映射的一些方面取决于网关是否与下一跳SIP节点（即，向其发送INVITE请求或从其接收INVITE请求的代理或UA）位于相同的信任域（如[14]中定义的），以在隐私报头中尊重身份隐私请求。这将取决于网络，建议支持P-Asserted-Identity报头的网关持有在这方面受信任的下一跳节点的可配置列表。
9.1.1. Using Information from the QSIG Called Party Number Information Element
9.1.1. 使用来自被称为参与方编号信息元素的QSIG的信息
When mapping a QSIG SETUP message to a SIP INVITE request, the gateway SHALL convert the number in the QSIG Called party number information to a URI and include that URI in the SIP Request-URI and in the To header.
当将QSIG设置消息映射到SIP INVITE请求时，网关应将QSIG被叫方号码信息中的号码转换为URI，并将该URI包括在SIP请求URI和to报头中。
9.1.2. Using Information from the QSIG Calling Party Number Information Element
9.1.2. 使用来自QSIG主叫方号码信息元素的信息
When mapping a QSIG SETUP message to a SIP INVITE request, the gateway SHALL use the Calling party number information element, if present, as follows.
当将QSIG设置消息映射到SIP INVITE请求时，网关应使用主叫方号码信息元素（如果存在），如下所示。
If the information element contains a number, the gateway SHALL attempt to derive a URI from that number. Further behaviour depends on whether a URI has been derived and the value of the presentation indication.
如果信息元素包含数字，网关应尝试从该数字派生URI。进一步的行为取决于是否已派生URI以及表示指示的值。
9.1.2.1. No URI derived, and presentation indicator does not have value "presentation restricted"
9.1.2.1. 没有派生URI，并且表示指示符没有值“presentation restricted”
In this case (including the case where the Calling party number information element is absent), the gateway SHALL include a URI identifying the gateway in the From header. Also, if the gateway supports the mechanism defined in [14], the gateway SHALL NOT generate a P-Asserted-Identity header.
在这种情况下（包括缺少主叫方号码信息元素的情况），网关应包括在From报头中标识网关的URI。此外，如果网关支持[14]中定义的机制，则网关不应生成P-Asserted-Identity报头。
9.1.2.2. No URI derived, and presentation indicator has value "presentation restricted"
9.1.2.2. 没有派生URI，并且表示指示符的值为“表示受限”
In this case, the gateway SHALL generate an anonymous From header. Also, if the gateway supports the mechanism defined in [14], the gateway SHALL generate a Privacy header field with parameter priv-value = "id" and SHALL NOT generate a P-Asserted-Identity header. The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
在这种情况下，网关将从报头生成匿名消息。此外，如果网关支持[14]中定义的机制，则网关应生成带有参数priv value=“id”的隐私标头字段，且不应生成P-Asserted-Identity标头。隐私标头中包含priv value参数的附加值不在本规范的范围内。
9.1.2.3. URI derived, and presentation indicator has value "presentation restricted"
9.1.2.3. URI派生，并且表示指示符的值为“表示受限”
If the gateway supports the P-Asserted-Identity header and trusts the next hop proxy to honour the Privacy header, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI, SHALL generate a Privacy header with parameter priv-value = "id", and SHALL generate an anonymous From header. The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
如果网关支持P-Asserted-Identity报头并信任下一跳代理遵守隐私报头，则网关应生成包含派生URI的P-Asserted-Identity报头，应生成带有参数priv value=“id”的隐私报头，并应生成匿名From报头。隐私标头中包含priv value参数的附加值不在本规范的范围内。
If the gateway does not support the P-Asserted-Identity header or does not trust the proxy to honour the Privacy header, the gateway SHALL behave as in Section 9.1.2.2.
如果网关不支持P-Asserted-Identity报头或不信任代理遵守隐私报头，则网关的行为应符合第9.1.2.2节的规定。
9.1.2.4. URI derived, and presentation indicator does not have value "presentation restricted"
9.1.2.4. URI派生，并且表示指示符没有值“表示受限”
In this case, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI if the gateway supports this header, SHALL NOT generate a Privacy header, and SHALL include the derived URI in the From header. In addition, the gateway MAY use S/MIME, as described in Section 23 of [10], to sign a copy of the From header included in a message/sipfrag body of the INVITE request as described in [20].
在这种情况下，网关应生成包含派生URI的P-Asserted-Identity报头（如果网关支持该报头），不应生成隐私报头，并应在From报头中包含派生URI。此外，网关可使用S/MIME（如[10]第23节所述）对包含在[20]所述邀请请求的消息/sipfrag正文中的From头的副本进行签名。
9.1.3. Using Information from the QSIG Connected Number Information Element
9.1.3. 使用来自QSIG连接编号信息元素的信息
When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an INVITE request, the gateway SHALL use the Connected number information element, if present, as follows.
当将QSIG CONNECT消息映射到针对INVITE请求的SIP 200（OK）响应时，网关应使用连接号码信息元素（如果存在），如下所示。
If the information element contains a number, the gateway SHALL attempt to derive a URI from that number. Further behaviour depends on whether a URI has been derived and the value of the presentation indication.
如果信息元素包含数字，网关应尝试从该数字派生URI。进一步的行为取决于是否已派生URI以及表示指示的值。
9.1.3.1. No URI derived, and presentation indicator does not have value "presentation restricted"
9.1.3.1. 没有派生URI，并且表示指示符没有值“presentation restricted”
In this case (including the case where the Connected number information element is absent), the gateway SHALL NOT generate a P-Asserted-Identity header and SHALL NOT generate a Privacy header.
在这种情况下（包括不存在连接号码信息元素的情况），网关不应生成P-Asserted-Identity报头，也不应生成隐私报头。
9.1.3.2. No URI derived, and presentation indicator has value "presentation restricted"
9.1.3.2. 没有派生URI，并且表示指示符的值为“表示受限”
In this case, if the gateway supports the mechanism defined in [14], the gateway SHALL generate a Privacy header field with parameter priv-value = "id" and SHALL NOT generate a P-Asserted-Identity header. The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
在这种情况下，如果网关支持[14]中定义的机制，则网关应生成带有参数priv value=“id”的隐私标头字段，且不应生成P-Asserted-Identity标头。隐私标头中包含priv value参数的附加值不在本规范的范围内。
9.1.3.3. URI derived, and presentation indicator has value "presentation restricted"
9.1.3.3. URI派生，并且表示指示符的值为“表示受限”
If the gateway supports the P-Asserted-Identity header and trusts the next hop proxy to honour the Privacy header, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI and SHALL generate a Privacy header with parameter priv-value = "id". The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
如果网关支持P-Asserted-Identity报头并信任下一跳代理遵守隐私报头，则网关应生成包含派生URI的P-Asserted-Identity报头，并应生成带有参数priv value=“id”的隐私报头。隐私标头中包含priv value参数的附加值不在本规范的范围内。
If the gateway does not support the P-Asserted-Identity header or does not trust the proxy to honour the Privacy header, the gateway SHALL behave as in Section 9.1.3.2.
如果网关不支持P-Asserted-Identity报头或不信任代理遵守隐私报头，则网关的行为应符合第9.1.3.2节的规定。
9.1.3.4. URI derived, and presentation indicator does not have value "presentation restricted"
9.1.3.4. URI派生，并且表示指示符没有值“表示受限”
In this case, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI if the gateway supports this header and SHALL NOT generate a Privacy header. In addition, the gateway MAY use S/MIME, as described in Section 23 of [10], to sign a To header containing the derived URI, the To header being included in a message/sipfrag body of the INVITE response as described in [20].
在这种情况下，如果网关支持P-Asserted-Identity报头，则网关应生成包含派生URI的P-Asserted-Identity报头，并且不应生成隐私报头。此外，如[10]第23节所述，网关可使用S/MIME对包含派生URI的to报头进行签名，to报头包括在INVITE响应的消息/sipfrag正文中，如[20]所述。
NOTE: The To header in the message/sipfrag body may differ from the to header in the response's headers.
注意：消息/sipfrag正文中的To标头可能与响应标头中的To标头不同。
The method used to convert a URI to a number is outside the scope of this specification. However, NPI and TON fields in the QSIG information element concerned SHALL be set to appropriate values in accordance with [1].
用于将URI转换为数字的方法不在本规范的范围内。但是，相关QSIG信息元素中的NPI和TON字段应根据[1]设置为适当的值。
Some aspects of mapping depend on whether the gateway trusts the next hop SIP node (i.e., the proxy or UA to which the INVITE request is sent or from which INVITE request is received) to provide accurate information in the P-Asserted-Identity header. This will be network-dependent, and it is RECOMMENDED that gateways hold a configurable list of next hop nodes that are to be trusted in this respect.
映射的一些方面取决于网关是否信任下一跳SIP节点（即，向其发送INVITE请求或从其接收INVITE请求的代理或UA）以在P-Asserted-Identity报头中提供准确信息。这将取决于网络，建议网关包含一个可配置的下一跳节点列表，这些节点在这方面值得信任。
Some aspects of mapping depend on whether the gateway is prepared to use a URI in the From header to derive a number for the Calling party number information element. The default behaviour SHOULD be not to use an unsigned or unvalidated From header for this purpose, since in principle the information comes from an untrusted source (the remote UA). However, it is recognised that some network administrations may believe that the benefits to be derived from supplying a calling party number outweigh any risks of supplying false information. Therefore, a gateway MAY be configurable to use an unsigned or unvalidated From header for this purpose.
映射的某些方面取决于网关是否准备使用From报头中的URI来派生主叫方号码信息元素的号码。默认行为不应为此目的使用未签名或未验证的From头，因为原则上信息来自不受信任的来源（远程UA）。然而，人们认识到，一些网络管理部门可能认为，提供主叫方号码的好处大于提供虚假信息的风险。因此，网关可以配置为为此目的使用未签名或未验证的From报头。
When mapping a SIP INVITE request to a QSIG SETUP message, the gateway SHALL convert the URI in the SIP Request-URI to a number and include that number in the QSIG Called party number information element.
将SIP INVITE请求映射到QSIG设置消息时，网关应将SIP请求URI中的URI转换为一个数字，并将该数字包含在QSIG被叫方号码信息元素中。
NOTE: The To header should not be used for this purpose. This is because re-targeting of the request in the SIP network can change the Request-URI but leave the To header unchanged. It is important that routing in the QSIG network be based on the final target from the SIP network.
注意：To标题不应用于此目的。这是因为在SIP网络中重新确定请求的目标可以更改请求URI，但保留To头不变。QSIG网络中的路由必须基于SIP网络的最终目标，这一点很重要。
When mapping a SIP INVITE request to a QSIG SETUP message, the gateway SHALL generate a Calling party number information element as follows.
当将SIP INVITE请求映射到QSIG设置消息时，网关应生成主叫方号码信息元素，如下所示。
If the SIP INVITE request contains an S/MIME signed message/sipfrag body [20] containing a From header, and if the gateway supports this capability and can verify the authenticity and trustworthiness of this information, the gateway SHALL attempt to derive a number from the URI in that header. If no number is derived from a message/sipfrag body, if the SIP INVITE request contains a P-Asserted-Identity header, and if the gateway supports that header and trusts the information therein, the gateway SHALL attempt to derive a number from the URI in that header. If a number is derived from one of these headers, the gateway SHALL include it in the Calling party number information element and include value "network provided" in the screening indicator.
如果SIP INVITE请求包含S/MIME签名消息/sipfrag正文[20]，其中包含From标头，并且如果网关支持此功能并且可以验证此信息的真实性和可信度，则网关应尝试从该标头中的URI派生一个数字。如果没有从消息/sipfrag主体派生出数字，如果SIP INVITE请求包含P-Asserted-Identity头，并且如果网关支持该头并信任其中的信息，则网关应尝试从该头中的URI派生数字。如果一个号码来自其中一个报头，网关应将其包含在主叫方号码信息元素中，并在筛选指示符中包含值“网络提供”。
If no number is derivable as described above and if the gateway is prepared to use the unsigned or unvalidated From header, the gateway SHALL attempt to derive a number from the URI in the From header. If a number is derived from the From header, the gateway SHALL include it in the Calling party number information element and include value "user provided, not screened" in the screening indicator.
如果没有如上所述可派生的数字，并且如果网关准备使用未签名或未验证的From标头，则网关应尝试从From标头中的URI派生数字。如果号码来自from报头，则网关应将其包含在主叫方号码信息元素中，并在筛选指示符中包含值“用户提供，未筛选”。
If no number is derivable, the gateway SHALL NOT include a number in the Calling party number information element.
如果没有可派生的号码，网关不应在主叫方号码信息元素中包含号码。
If the SIP INVITE request contains a Privacy header with value "id" in parameter priv-value and the gateway supports this header, or if the value in the From header indicates anonymous, the gateway SHALL include value "presentation restricted" in the presentation indicator. Based on local policy, the gateway MAY use the presence of other priv-values to set the presentation indicator to "presentation restricted". Otherwise the gateway SHALL include value "presentation allowed" if a number is present or "not available due to interworking" if no number is present.
如果SIP INVITE请求包含参数PRIVE value中值为“id”的隐私标头，并且网关支持该标头，或者如果From标头中的值表示匿名，则网关应在表示指示器中包含值“表示受限”。基于本地策略，网关可以使用其他priv值的存在来将表示指示符设置为“表示受限”。否则，如果有号码，网关应包含“允许显示”值；如果没有号码，网关应包含“由于互通而不可用”值。
If the resulting Calling party number information element contains no number and contains value "not available due to interworking" in the presentation indicator, the gateway MAY omit the information element from the QSIG SETUP message.
如果生成的主叫方号码信息元素不包含号码，并且在表示指示符中包含值“由于互通而不可用”，则网关可以从QSIG设置消息中省略该信息元素。
When mapping a SIP 2xx response to an INVITE request to a QSIG CONNECT message, the gateway SHALL generate a Connected number information element as follows.
当将对INVITE请求的SIP 2xx响应映射到QSIG CONNECT消息时，网关应生成连接号码信息元素，如下所示。
If the SIP 2xx response contains an S/MIME signed message/sipfrag [20] body containing a To header and the gateway supports this capability and can verify the authenticity and trustworthiness of this information, the gateway SHALL attempt to derive a number from the URI in that header. If no number is derived from a message/sipfrag body, if the SIP 2xx response contains a P-Asserted-Identity header, and if the gateway supports that header and trusts the information therein, the gateway SHALL attempt to derive a number from the URI in that header. If a number is derived from one of these headers, the gateway SHALL include it in the Connected number information element and include value "network provided" in the screening indicator.
如果SIP 2xx响应包含S/MIME签名消息/sipfrag[20]正文，其中包含To报头，并且网关支持此功能，并且可以验证此信息的真实性和可信度，则网关应尝试从该报头中的URI派生一个数字。如果没有从消息/sipfrag主体派生出数字，如果SIP 2xx响应包含P-Asserted-Identity报头，并且如果网关支持该报头并信任其中的信息，则网关应尝试从该报头中的URI派生数字。如果一个数字是从这些标题中的一个导出的，则网关应将其包含在连接的数字信息元素中，并在筛选指示器中包含值“网络提供”。
If no number is derivable as described above, the gateway SHOULD NOT include a number in the Connected number information element.
如果没有如上所述可派生的号码，则网关不应在连接的号码信息元素中包含号码。
If the SIP 2xx response contains a Privacy header with value "id" in parameter priv-value and the gateway supports this header, the gateway SHALL include value "presentation restricted" in the presentation indicator. Based on local policy, the gateway MAY use the presence of other priv-values to set the presentation indicator to "presentation restricted". Otherwise, the gateway SHALL include value "presentation allowed" if a number is present or "not available due to interworking" if no number is present.
如果SIP 2xx响应包含参数priv value中带有值“id”的隐私标头，并且网关支持该标头，则网关应在显示指示器中包含值“presentation restricted”。基于本地策略，网关可以使用其他priv值的存在来将表示指示符设置为“表示受限”。否则，如果有号码，网关应包含值“允许显示”，如果没有号码，则应包含值“由于互通而不可用”。
If the resulting Connected number information element contains no number and value "not available due to interworking" in the presentation indicator, the gateway MAY omit the information element from the QSIG CONNECT message.
如果生成的已连接号码信息元素在显示指示器中不包含任何号码和值“由于互通而不可用”，则网关可能会从QSIG CONNECT消息中忽略该信息元素。
This document specifies signalling interworking for basic services that provide a bi-directional transfer capability for speech, facsimile, and modem media between the two networks.
本文件规定了基本服务的信令互通，这些服务为两个网络之间的语音、传真和调制解调器媒体提供双向传输能力。
The gateway SHALL generate the Bearer Capability Information Element in the QSIG SETUP message based on SDP offer information received along with the SIP INVITE request. If the SIP INVITE request does not contain SDP offer information or the media type in the SDP offer information is only 'audio', then the Bearer capability information element SHALL BE generated according to Table 3. Coding of the Bearer capability information element for other media types is outside the scope of this specification.
网关应根据随SIP INVITE请求一起接收的SDP PROFER信息，在QSIG设置消息中生成承载能力信息元素。如果SIP INVITE请求不包含SDP提供信息或SDP提供信息中的媒体类型仅为“音频”，则应根据表3生成承载能力信息元素。其他媒体类型的承载能力信息元素的编码不在本规范的范围内。
In addition, the gateway MAY include a Low layer compatibility information element and/or High layer compatibility information in the QSIG SETUP message if the gateway is able to derive relevant information from the SDP offer information. Specific mappings are outside the scope of this specification.
此外，如果网关能够从SDP提供信息导出相关信息，则网关可以在QSIG设置消息中包括低层兼容性信息元素和/或高层兼容性信息。特定映射不在本规范的范围内。
Table 3: Bearer capability encoding for 'audio' transfer
表3：“音频”传输的承载能力编码
Field Value
-----------------------------------------------------------------
Coding Standard "CCITT standardized coding" (00)
Information transfer "3,1 kHz audio" (10000)
capability
Transfer mode "circuit mode" (00)
Information transfer rate "64 Kbits/s" (10000)
Multiplier Octet omitted
User information layer 1 Generated by gateway based on
protocol Information of the PISN. Supported
values are
"CCITT recommendation G.711 mu-law"
(00010)
"CCITT recommendation G.711 A-law"
(00011)
Field Value
-----------------------------------------------------------------
Coding Standard "CCITT standardized coding" (00)
Information transfer "3,1 kHz audio" (10000)
capability
Transfer mode "circuit mode" (00)
Information transfer rate "64 Kbits/s" (10000)
Multiplier Octet omitted
User information layer 1 Generated by gateway based on
protocol Information of the PISN. Supported
values are
"CCITT recommendation G.711 mu-law"
(00010)
"CCITT recommendation G.711 A-law"
(00011)
The gateway SHALL generate SDP offer information to include in the SIP INVITE request based on information in the QSIG SETUP message. The gateway MAY take account of QSIG Low layer compatibility and/or High layer compatibility information elements, if present in the QSIG SETUP message, when deriving SDP offer information, in which case
网关应根据QSIG设置消息中的信息生成SDP提供信息，以包括在SIP INVITE请求中。在导出SDP报价信息时，网关可考虑QSIG低层兼容性和/或高层兼容性信息元素（如果存在于QSIG设置消息中），在这种情况下
specific mappings are outside the scope of this specification. Otherwise, the gateway shall generate SDP offer information based only on the Bearer capability information element in the QSIG SETUP message, in which case the media type SHALL be derived according to Table 4.
特定映射不在本规范的范围内。否则，网关应仅基于QSIG设置消息中的承载能力信息元素生成SDP提供信息，在这种情况下，应根据表4导出媒体类型。
Table 4: Media type setting in SDP based on Bearer capability information element
表4:SDP中基于承载能力信息元素的媒体类型设置
Information transfer capability in Media type in SDP
Bearer capability information element
---------------------------------------------------------------
"speech" (00000) audio
"3,1 kHz audio" (10000) audio
Information transfer capability in Media type in SDP
Bearer capability information element
---------------------------------------------------------------
"speech" (00000) audio
"3,1 kHz audio" (10000) audio
Normal considerations apply for UA use of SIP security measures, including digest authentication, TLS, and S/MIME as described in [10].
正常考虑适用于UA使用SIP安全措施，包括[10]中所述的摘要认证、TLS和S/MIME。
The translation of QSIG information elements into SIP headers can introduce some privacy and security concerns. For example, care needs to be taken to provide adequate privacy for a user requesting presentation restriction if the Calling party number information element is openly mapped to the From header. Procedures for dealing with this particular situation are specified in Section 9.1.2. However, since the mapping specified in this document is mainly concerned with translating information elements into the headers and fields used to route SIP requests, gateways consequently reveal (through this translation process) the minimum possible amount of information.
将QSIG信息元素转换为SIP头可能会带来一些隐私和安全问题。例如，如果主叫方号码信息元素公开映射到From报头，则需要注意为请求呈现限制的用户提供足够的隐私。第9.1.2节规定了处理这种特殊情况的程序。然而，由于本文档中指定的映射主要涉及将信息元素转换为用于路由SIP请求的报头和字段，因此网关（通过此转换过程）会显示尽可能少的信息量。
There are some concerns, however, that arise from the other direction of mapping, the mapping of SIP headers to QSIG information elements, which are enumerated in the following paragraphs.
然而，在映射的另一个方向，即SIP头到QSIG信息元素的映射中，会产生一些问题，这些问题将在下面的段落中列举。
When end users dial numbers in a PISN, their selections populate the Called party number information element in the QSIG SETUP message. Similarly, the SIP URI or tel URL and its optional parameters in the Request-URI of a SIP INVITE request, which can be created directly by end users of a SIP device, map to that information element at a gateway. However, in a PISN, policy can prevent the user from dialing certain (invalid or restricted) numbers. Thus, gateway
当最终用户拨打PISN中的号码时，他们的选择将填充QSIG设置消息中的被叫方号码信息元素。类似地，SIP-INVITE请求的请求URI中的SIP-URI或tel-URL及其可选参数（可由SIP设备的最终用户直接创建）映射到网关处的该信息元素。但是，在PISN中，策略可以防止用户拨打某些（无效或受限）号码。因此，网关
implementers may wish to provide a means for gateway administrators to apply policies restricting the use of certain SIP URIs or tel URLs, or SIP URI or tel URL parameters, when authorizing a call from SIP to QSIG.
实现者可能希望为网关管理员提供一种方法，以便在授权从SIP到QSIG的呼叫时，应用限制使用某些SIP URI或tel URL或SIP URI或tel URL参数的策略。
Some additional risks may result from the mapping of SIP response codes to QSIG cause values. SIP user agents could conceivably respond to an INVITE request 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 QSIG call clearing message. Generally speaking, the manner in which a call is rejected is unlikely to provide any avenue for fraud or denial of service (e.g., by signalling that a call should not be billed, or that the network should take critical resources off-line). However, gateway implementers may wish to make provision for gateway administrators to modify the response code to cause value mappings to avoid any undesirable network-specific behaviour resulting from the mappings recommended in Section 8.4.4.
SIP响应代码与QSIG原因值的映射可能会导致一些额外的风险。SIP用户代理可以用任意SIP响应代码响应来自网关的INVITE请求，因此它们可以（在网关支持的映射的边界内）指示将由网关在产生的QSIG呼叫清除消息中发送的Q.850原因代码。一般来说，拒绝呼叫的方式不太可能为欺诈或拒绝服务提供任何途径（例如，通过发出呼叫不应计费的信号，或网络应使关键资源离线）。但是，网关实施者可能希望为网关管理员提供修改响应代码的规定，以引起值映射，从而避免因第8.4.4节中建议的映射而导致的任何不良网络特定行为。
This specification requires the gateway to map the Request-URI rather than the To header in a SIP INVITE request to the Called party number information element in a QSIG SETUP message. Although a SIP UA is expected to put the same URI in the To header and in the Request-URI, this is not policed by other SIP entities. Therefore, a To header URI that differs from the Request-URI received at the gateway cannot be used as a reliable indication that the call has been re-targeted in the SIP network or as a reliable indication of the original target. Gateway implementers making use of the To header for mapping to QSIG elements (e.g., as part of QSIG call diversion signalling) may wish to make provision for disabling this mapping when deployed in situations where the reliability of the QSIG elements concerned is important.
该规范要求网关将SIP INVITE请求中的请求URI而不是to头映射到QSIG设置消息中的被叫方号码信息元素。尽管SIP UA希望将相同的URI放在to头和请求URI中，但其他SIP实体并不对此采取策略。因此，与在网关处接收的请求URI不同的To报头URI不能用作SIP网络中呼叫已被重新定位的可靠指示或原始目标的可靠指示。使用To报头映射到QSIG元素（例如，作为QSIG呼叫转移信令的一部分）的网关实现者可能希望在相关QSIG元素的可靠性非常重要的情况下部署时禁用该映射。
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 an unsigned or unverified From header to populate the Calling party number information element of a QSIG SETUP message should authenticate the originator of the request and make sure that it is authorized to assert that calling number (or make use of some more
SIP用户代理对请求的From报头的任意填充对于依赖From报头作为发起者身份的准确表示的设备具有一些众所周知的安全含义。任何打算使用unsigned或unverified-From报头来填充QSIG设置消息的主叫方号码信息元素的网关都应该对请求的发起人进行身份验证，并确保其有权断言该主叫号码（或使用其他号码）
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 [10]. Similar considerations apply to the use of the SIP P-Asserted-Identity header for mapping to the QSIG Calling party number or Connected number information element, i.e., the source of this information should be authenticated. Use of a signed message/sipfrag body to derive a QSIG Calling party number or Connected number information element is another secure alternative.
确定调用方身份的安全方法）。请注意，网关与所有其他SIP用户代理一样，必须支持[10]中所述的摘要身份验证。类似的考虑也适用于使用SIP P-Asserted-Identity报头来映射到QSIG主叫方号码或连接号码信息元素，即，该信息的来源应经过身份验证。使用签名消息/sipfrag正文来派生QSIG呼叫方号码或连接号码信息元素是另一种安全的替代方案。
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 involve the connection of media streams to user information channels on inter-PINX links and the sending of progress description number 1 or 8 in a backward QSIG message. This can result in media being cut through end-to-end, 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) to an INVITE request. This is useful since it also permits network entities (particularly legacy networks that are incapable of transmitting Q.850 cause values) to play tones and announcements to indicate call failure or call progress, without triggering charging by transmitting a 2xx response. Also, early cut-through can help prevent clipping of the initial media when the call is answered. There are conceivable respects in which this capability could be used fraudulently by the called user agent for transmitting arbitrary information without answering the call or before answering the call. However, in corporate networks, charging is often not an issue, and for calls arriving at a corporate network from a carrier network, the carrier network normally takes steps to prevent fraud.
还有另一类潜在风险，与接听电话前切断反向媒体路径有关。本文档中描述的几个实践涉及将媒体流连接到PINX间链路上的用户信息通道，以及在反向QSIG消息中发送进度描述编号1或8。这可能导致媒体端到端被切断，并且被调用的用户代理在向INVITE请求发送最终响应（以2xx或更高响应代码的形式）之前，可能会无限期地向调用者播放任意音频。这是有用的，因为它还允许网络实体（特别是不能传输Q.850原因值的传统网络）播放音调和公告，以指示呼叫失败或呼叫进度，而无需通过传输2xx响应触发充电。此外，在接听电话时，提前切断有助于防止初始媒体被剪切。在一些可想象的方面，被呼叫的用户代理可以欺诈地使用该能力来传输任意信息，而无需应答呼叫或在应答呼叫之前。然而，在公司网络中，收费通常不是问题，对于从运营商网络到达公司网络的呼叫，运营商网络通常采取措施防止欺诈。
The usefulness of this capability appears to outweigh any risks involved, which may in practice be no greater than in existing PISN/ISDN environments. However, gateway implementers may wish to make provision for gateway administrators to turn off cut-through or minimise its impact (e.g., by imposing a time limit) when deployed in situations where problems can arise.
这种能力的有用性似乎超过了所涉及的任何风险，而实际上，这种风险可能不会比现有PISN/ISDN环境中的风险更大。但是，网关实施者可能希望为网关管理员在可能出现问题的情况下部署时关闭直通或最小化其影响（例如，通过施加时间限制）做出规定。
Unlike a traditional PISN 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 INVITE 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, or, where overlap signalling is used,
与传统的PISN电话不同，SIP用户代理可以同时启动多个请求以到达特定资源。对于SIP用户代理来说，在一个100端口的网关上启动100个SIP INVITE请求，从而占用其所有端口是很简单的。恶意用户可以选择向已知从未应答的电话号码发出请求，或者在使用重叠信令的情况下，
to incomplete addresses. This could saturate resources at the gateway indefinitely, potentially without incurring any charges. Gateway implementers may therefore wish to provide means of restricting according to policy the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack.
不完整的地址。这可能会无限期地使网关上的资源饱和，而不会产生任何费用。因此，网关实现者可能希望提供根据策略限制来自同一认证源的同时请求的数量的方法，或类似的机制，以应对这种可能的拒绝服务攻击。
This document is a product of the authors' activities in Ecma (www.ecma-international.org) on interoperability of QSIG with IP networks. An earlier version is published as Standard ECMA-339. Ecma has made this work available to the IETF as the basis for publishing an RFC.
本文件是作者在Ecma（www.Ecma-international.org）中关于QSIG与IP网络互操作性活动的成果。早期版本发布为标准ECMA-339。Ecma已将此工作提供给IETF，作为发布RFC的基础。
The authors wish to acknowledge the assistance of Francois Audet, Adam Roach, Jean-Francois Rey, Thomas Stach, and members of Ecma TC32-TG17 in preparing and commenting on this document.
作者希望感谢Francois Audet、Adam Roach、Jean-Francois Rey、Thomas Stach和Ecma TC32-TG17成员在编写和评论本文件方面提供的帮助。
[1] International Standard ISO/IEC 11571 "Private Integrated Services Networks (PISN) - Addressing" (also published by Ecma as Standard ECMA-155).
[1] 国际标准ISO/IEC 11571“专用综合业务网（PISN）-寻址”（也由Ecma作为标准Ecma-155发布）。
[2] International Standard ISO/IEC 11572 "Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (also published by Ecma as Standard ECMA-143).
[2] 国际标准ISO/IEC 11572“专用综合业务网-电路模式承载业务-交换间信令程序和协议”（也由Ecma发布为标准Ecma-143）。
[3] International Standard ISO/IEC 11582 "Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol" (also published by Ecma as Standard ECMA-165).
[3] 国际标准ISO/IEC 11582“专用综合业务网-支持补充业务的通用功能协议-交换间信令程序和协议”（也由Ecma发布为标准Ecma-165）。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] 《传输控制协议》，标准7，RFC 793，1981年9月。
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[6] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[7] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[9] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[10] 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.
[10] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[11] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[13] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[13] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[14] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[14] Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中用于断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[15] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[16] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[17] ITU-T Recommendation E.164, "The International Public Telecommunication Numbering Plan", (1997-05).
[17] ITU-T建议E.164，“国际公共电信编号计划”（1997-05）。
[18] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)", RFC 3578, August 2003.
[18] Camarillo，G.，Roach，A.，Peterson，J.，和L.Ong，“综合业务数字网（ISDN）用户部分（ISUP）重叠信令到会话发起协议（SIP）的映射”，RFC 3578，2003年8月。
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[19] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[20] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[20] Sparks，R.，“互联网媒体类型信息/sipfrag”，RFC 3420，2002年11月。
This appendix shows some typical message sequences that can occur for an interworking between QSIG and SIP. It is informative.
本附录显示了QSIG和SIP之间互通时可能出现的一些典型消息序列。它提供了信息。
NOTE: For all message sequence diagrams, there is no message mapping between QSIG and SIP unless explicitly indicated by dotted lines. Also, if there are no dotted lines connecting two messages, this means that these are independent of each other in terms of the time when they occur.
注意：对于所有消息序列图，除非用虚线明确表示，否则QSIG和SIP之间没有消息映射。此外，如果没有虚线连接两条消息，这意味着它们在发生的时间上彼此独立。
NOTE: Numbers prefixing SIP method names and response codes in the diagrams represent sequence numbers. Messages bearing the same number will have the same value in the CSeq header.
注：图中以SIP方法名称和响应代码为前缀的数字表示序列号。具有相同编号的消息在CSeq标头中具有相同的值。
NOTE: In these examples, SIP provisional responses (other than 100) are shown as being sent reliably, using the PRACK method for acknowledgement.
注意：在这些示例中，SIP临时响应（100除外）显示为使用PRACK方法进行确认而可靠发送。
Below are typical message sequences for successful call establishment from QSIG to SIP
下面是从QSIG到SIP成功建立呼叫的典型消息序列
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG SETUP | | 1-INVITE |
1|----------------------->|......|----------------------->| 2
| | | |
| | | |
| QSIG CALL PROCEEDING | | 1-100 TRYING |
3|<-----------------------| |<-----------------------+ 4
| | | |
| | | |
| QSIG ALERTING | | 1-180 RINGING |
8|<-----------------------|......|<-----------------------+ 5
| | | |
| | | 2-PRACK |
| | |----------------------->| 6
| | | 2-200 OK |
| | |<-----------------------+ 7
| | | |
| QSIG CONNECT | | 1-200 OK |
11|<-----------------------|......|<-----------------------+ 9
| | | |
| QSIG CONNECT ACK | | 1-ACK |
12|----------------------->| |----------------------->| 10
| | | |
|<======================>| |<======================>|
| AUDIO | | AUDIO |
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG SETUP | | 1-INVITE |
1|----------------------->|......|----------------------->| 2
| | | |
| | | |
| QSIG CALL PROCEEDING | | 1-100 TRYING |
3|<-----------------------| |<-----------------------+ 4
| | | |
| | | |
| QSIG ALERTING | | 1-180 RINGING |
8|<-----------------------|......|<-----------------------+ 5
| | | |
| | | 2-PRACK |
| | |----------------------->| 6
| | | 2-200 OK |
| | |<-----------------------+ 7
| | | |
| QSIG CONNECT | | 1-200 OK |
11|<-----------------------|......|<-----------------------+ 9
| | | |
| QSIG CONNECT ACK | | 1-ACK |
12|----------------------->| |----------------------->| 10
| | | |
|<======================>| |<======================>|
| AUDIO | | AUDIO |
Figure 3: Typical message sequence for successful call establishment from QSIG to SIP, using en bloc procedures on both QSIG and SIP
图3：在QSIG和SIP上使用整体过程，成功建立从QSIG到SIP的呼叫的典型消息序列
1 The PISN sends a QSIG SETUP message to the gateway to begin a session with a SIP UA. 2 On receipt of the QSIG SETUP message, the gateway generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network based on the called number. 3 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more QSIG INFORMATION messages will be accepted. 4 The IP network sends a SIP 100 (Trying) response to the gateway. 5 The IP network sends a SIP 180 (Ringing) response.
1 PISN向网关发送QSIG设置消息，以开始与SIP UA的会话。2在收到QSIG设置消息时，网关生成SIP INVITE请求，并基于被叫号码将其发送到IP网络中的适当SIP实体。3网关向PISN发送QSIG呼叫进行消息；不再接受QSIG信息消息。4 IP网络向网关发送SIP 100（尝试）响应。5 IP网络发送SIP 180（振铃）响应。
6 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 7 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request 8 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PISN. 9 The IP network sends a SIP 200 (OK) response when the call is answered. 10 The gateway sends a SIP ACK request to acknowledge the SIP 200 (OK) response. 11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message and sends it to the PISN. 12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message.
6网关可基于在初始SIP INVITE请求中包含Require报头或带有选项标签100rel的受支持报头，将SIP PRACK请求发回IP网络。7 IP网络向网关发送SIP 200（OK）响应以确认SIP PRACK请求8网关将该SIP 180（振铃）响应映射到QSIG警报消息并将其发送到PISN。9当呼叫被应答时，IP网络发送SIP 200（OK）响应。10网关发送SIP ACK请求以确认SIP 200（OK）响应。11网关将该SIP 200（OK）响应映射到QSIG CONNECT消息，并将其发送到PISN。12 PISN发送QSIG CONNECT确认消息以响应QSIG CONNECT消息。
A.2.2. QSIG to SIP, using overlap receiving on QSIG and en bloc sending on SIP
A.2.2. QSIG到SIP，使用QSIG上的重叠接收和SIP上的整体发送
+------------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +--------+-------+-------+ |
1|-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2|<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3|-------------------------->| | |
| | | |
| QSIG INFORMATION | | 1-INVITE |
3a|-------------------------->|.......|----------------------->|4
| QSIG CALL PROCEEDING | | 1-100 TRYING |
5|<--------------------------| |<-----------------------|6
| | | |
| QSIG ALERTING | | 1-180 RINGING |
10|<--------------------------|.......|<-----------------------|7
| | | 2-PRACK |
| | |----------------------->|8
| | | 2-200 OK |
| | |<-----------------------|9
| QSIG CONNECT | | 1-200 OK |
13|<--------------------------|.......|<-----------------------|11
| | | |
| QSIG CONNECT ACK | | 1-ACK |
14|-------------------------->| |----------------------->|12
| AUDIO | | AUDIO |
|<=========================>| |<======================>|
+------------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +--------+-------+-------+ |
1|-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2|<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3|-------------------------->| | |
| | | |
| QSIG INFORMATION | | 1-INVITE |
3a|-------------------------->|.......|----------------------->|4
| QSIG CALL PROCEEDING | | 1-100 TRYING |
5|<--------------------------| |<-----------------------|6
| | | |
| QSIG ALERTING | | 1-180 RINGING |
10|<--------------------------|.......|<-----------------------|7
| | | 2-PRACK |
| | |----------------------->|8
| | | 2-200 OK |
| | |<-----------------------|9
| QSIG CONNECT | | 1-200 OK |
13|<--------------------------|.......|<-----------------------|11
| | | |
| QSIG CONNECT ACK | | 1-ACK |
14|-------------------------->| |----------------------->|12
| AUDIO | | AUDIO |
|<=========================>| |<======================>|
Figure 4: Typical message sequence for successful call establishment from QSIG to SIP, using overlap receiving on QSIG and en bloc sending on SIP
图4：使用QSIG上的重叠接收和SIP上的整体发送，成功建立从QSIG到SIP的呼叫的典型消息序列
1 The PISN sends a QSIG SETUP message to the gateway to begin a session with a SIP UA. The QSIG SETUP message does not contain a Sending Complete information element. 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. More digits are expected. 3 More digits are sent from the PISN within a QSIG INFORMATION message. 3a More digits are sent from the PISN within a QSIG INFORMATION message. The QSIG INFORMATION message contains a Sending Complete information element.
1 PISN向网关发送QSIG设置消息，以开始与SIP UA的会话。QSIG设置消息不包含发送完整信息元素。2网关向PISN发送QSIG设置确认消息。需要更多的数字。在QSIG信息消息中，PISN会再发送3位数字。3在QSIG信息报文中，PISN会发送更多的数字。QSIG信息消息包含发送完整信息元素。
4 The Gateway generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network, based on the called number. 5 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more QSIG INFORMATION messages will be accepted. 6 The IP network sends a SIP 100 (Trying) response to the gateway. 7 The IP network sends a SIP 180 (Ringing) response. 8 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 9 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request. 10 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PINX. 11 The IP network sends a SIP 200 (OK) response when the call is answered. 12 The gateway sends an SIP ACK request to acknowledge the SIP 200 (OK) response. 13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message and sends it to the PINX. 14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message.
4网关根据被叫号码生成SIP INVITE请求并将其发送到IP网络中的适当SIP实体。5网关向PISN发送QSIG呼叫进行消息；不再接受QSIG信息消息。6 IP网络向网关发送SIP 100（尝试）响应。7 IP网络发送SIP 180（振铃）响应。8网关可基于在初始SIP INVITE请求中包含Require报头或带有选项标签100rel的受支持报头，将SIP PRACK请求发回IP网络。9 IP网络向网关发送SIP 200（OK）响应以确认SIP PRACK请求。10网关将此SIP 180（振铃）响应映射到QSIG警报消息，并将其发送到PINX。11当呼叫被应答时，IP网络发送SIP 200（OK）响应。12网关发送SIP ACK请求以确认SIP 200（OK）响应。13网关将此SIP 200（OK）响应映射到QSIG CONNECT消息，并将其发送到PINX。14 PISN发送QSIG CONNECT确认消息以响应QSIG CONNECT消息。
+----------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +-------+-------+------+ |
1 |------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2 |<-------------------------| | |
| | | |
| QSIG INFORMATION | | |
3 |------------------------->| | |
| QSIG INFORMATION | | 1-INVITE |
3 |------------------------->|.......|------------------------>|4
| | | 1-484 |
| | |<------------------------|5
| | | 1-ACK |
| | |------------------------>|6
| QSIG INFORMATION | | 2-INVITE |
7 |------------------------->|.......|------------------------>|4
| | | 2-484 |
| | |<------------------------|5
| | | 2-ACK |
| | |------------------------>|6
| | | |
| QSIG INFORMATION | | |
| Sending Complete IE | | 3-INVITE |
8 |------------------------->|.......|------------------------>|10
| QSIG CALL PROCEEDING | | 3-100 TRYING |
9 |<-------------------------| |<------------------------|11
| | | |
| QSIG ALERTING | | 3-180 RINGING |
15|<-------------------------|.......|<------------------------|12
| | | 4-PRACK |
| | |------------------------>|13
| | | 4-200 OK |
| | |<------------------------|14
| QSIG CONNECT | | 3-200 OK |
18|<-------------------------|.......|<------------------------|16
| | | |
| QSIG CONNECT ACK | | 3-ACK |
19|------------------------->| |------------------------>|17
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
+----------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +-------+-------+------+ |
1 |------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2 |<-------------------------| | |
| | | |
| QSIG INFORMATION | | |
3 |------------------------->| | |
| QSIG INFORMATION | | 1-INVITE |
3 |------------------------->|.......|------------------------>|4
| | | 1-484 |
| | |<------------------------|5
| | | 1-ACK |
| | |------------------------>|6
| QSIG INFORMATION | | 2-INVITE |
7 |------------------------->|.......|------------------------>|4
| | | 2-484 |
| | |<------------------------|5
| | | 2-ACK |
| | |------------------------>|6
| | | |
| QSIG INFORMATION | | |
| Sending Complete IE | | 3-INVITE |
8 |------------------------->|.......|------------------------>|10
| QSIG CALL PROCEEDING | | 3-100 TRYING |
9 |<-------------------------| |<------------------------|11
| | | |
| QSIG ALERTING | | 3-180 RINGING |
15|<-------------------------|.......|<------------------------|12
| | | 4-PRACK |
| | |------------------------>|13
| | | 4-200 OK |
| | |<------------------------|14
| QSIG CONNECT | | 3-200 OK |
18|<-------------------------|.......|<------------------------|16
| | | |
| QSIG CONNECT ACK | | 3-ACK |
19|------------------------->| |------------------------>|17
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
Figure 5: Typical message sequence for successful call establishment from QSIG to SIP, using overlap procedures on both QSIG and SIP
图5：成功建立从QSIG到SIP的呼叫的典型消息序列，在QSIG和SIP上使用重叠过程
1 The PISN sends a QSIG SETUP message to the gateway to begin a session with a SIP UA. The QSIG SETUP message does not contain a Sending complete information element. 2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. More digits are expected. 3 More digits are sent from the PISN within a QSIG INFORMATION message. 4 When the gateway receives the minimum number of digits required to route the call, it generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network based on the called number 5 Due to an insufficient number of digits, the IP network will return a SIP 484 (Address Incomplete) response. 6 The SIP 484 (Address Incomplete) response is acknowledged. 7 More digits are received from the PISN in a QSIG INFORMATION message. A new INVITE is sent with the same Call-ID and From values but an updated Request-URI. 8 More digits are received from the PISN in a QSIG INFORMATION message. The QSIG INFORMATION message contains a Sending Complete information element. 9 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more information will be accepted. 10 The gateway sends a new SIP INVITE request with an updated Request-URI field. 11 The IP network sends a SIP 100 (Trying) response to the gateway. 12 The IP network sends a SIP 180 (Ringing) response. 13 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 14 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request. 15 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PISN. 16 The IP network sends a SIP 200 (OK) response when the call is answered. 17 The gateway sends a SIP ACK request to acknowledge the SIP 200 (OK) response. 18 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message. 19 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message.
1 PISN向网关发送QSIG设置消息，以开始与SIP UA的会话。QSIG设置消息不包含发送完整信息元素。2网关向PISN发送QSIG设置确认消息。需要更多的数字。在QSIG信息消息中，PISN会再发送3位数字。4当网关接收到路由呼叫所需的最小位数时，由于位数不足，它生成SIP INVITE请求并基于被叫号码5将其发送到IP网络中的适当SIP实体，IP网络将返回SIP 484（地址不完整）响应。6确认SIP 484（地址不完整）响应。在QSIG信息消息中，从PISN接收到7个以上的数字。新的INVITE将使用相同的调用ID和From值发送，但请求URI已更新。在QSIG信息消息中，从PISN接收到8位以上的数字。QSIG信息消息包含发送完整信息元素。9网关向PISN发送QSIG呼叫进行消息；不会接受更多信息。10网关发送带有更新请求URI字段的新SIP INVITE请求。11 IP网络向网关发送SIP 100（尝试）响应。12 IP网络发送SIP 180（振铃）响应。13网关可基于在初始SIP INVITE请求中包含Require报头或带有选项标签100rel的受支持报头，将SIP PRACK请求发回IP网络。14 IP网络向网关发送SIP 200（OK）响应以确认SIP PRACK请求。15网关将此SIP 180（振铃）响应映射到QSIG警报消息，并将其发送到PISN。16当呼叫被应答时，IP网络发送SIP 200（OK）响应。17网关发送SIP ACK请求以确认SIP 200（OK）响应。18网关将此SIP 200（OK）响应映射到QSIG CONNECT消息。19 PISN发送QSIG CONNECT确认消息以响应QSIG CONNECT消息。
Below are typical message sequences for successful call establishment from SIP to QSIG
下面是从SIP到QSIG成功建立呼叫的典型消息序列
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| +-------+-------+------+ |
| | | |
| | | |
| 1-INVITE | | QSIG SETUP |
1 |------------------------->|.......|------------------------>|3
| 1-100 TRYING | | QSIG CALL PROCEEDING |
2 |<-------------------------| |<------------------------|4
| 1-180 RINGING | | QSIG ALERTING |
6 |<-------------------------|.......|<------------------------|5
| | | |
| | | |
| 2-PRACK | | |
7 |------------------------->| | |
| 2-200 OK | | |
8 |<-------------------------| | |
| 1-200 OK | | QSIG CONNECT |
11|<-------------------------|.......|<------------------------|9
| | | |
| 1-ACK | | QSIG CONNECT ACK |
12|------------------------->| |------------------------>|10
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| +-------+-------+------+ |
| | | |
| | | |
| 1-INVITE | | QSIG SETUP |
1 |------------------------->|.......|------------------------>|3
| 1-100 TRYING | | QSIG CALL PROCEEDING |
2 |<-------------------------| |<------------------------|4
| 1-180 RINGING | | QSIG ALERTING |
6 |<-------------------------|.......|<------------------------|5
| | | |
| | | |
| 2-PRACK | | |
7 |------------------------->| | |
| 2-200 OK | | |
8 |<-------------------------| | |
| 1-200 OK | | QSIG CONNECT |
11|<-------------------------|.......|<------------------------|9
| | | |
| 1-ACK | | QSIG CONNECT ACK |
12|------------------------->| |------------------------>|10
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
Figure 6: Typical message sequence for successful call establishment from SIP to QSIG, using en bloc procedures
图6：使用整体过程成功建立从SIP到QSIG的呼叫的典型消息序列
1 The IP network sends a SIP INVITE request to the gateway. 2 The gateway sends a SIP 100 (Trying) response to the IP network. 3 On receipt of the SIP INVITE request, the gateway sends a QSIG SETUP message. 4 The PISN sends a QSIG CALL PROCEEDING message to the gateway. 5 A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted. 6 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response.
1 IP网络向网关发送SIP INVITE请求。2网关向IP网络发送SIP 100（尝试）响应。3在收到SIP INVITE请求时，网关发送QSIG设置消息。4 PISN向网关发送QSIG呼叫继续消息。5返回QSIG警报消息，指示PISN中的最终用户正在收到警报。6网关将QSIG警报消息映射到SIP 180（振铃）响应。
7 The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 8 The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request. 9 The PISN sends a QSIG CONNECT message to the gateway when the call is answered. 10 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the QSIG CONNECT message. 11 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 12 The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
7 IP网络可以基于在初始SIP INVITE请求中包含Require报头或带有选项标签100rel的受支持报头，将SIP PRACK请求发送回IP网络。8网关发送SIP 200（OK）响应以确认SIP PRACK请求。9当呼叫应答时，PISN向网关发送QSIG CONNECT消息。10网关发送QSIG CONNECT确认消息以确认QSIG CONNECT消息。11 QSIG CONNECT消息映射到SIP 200（OK）响应。12在接收到SIP INVITE final响应（200）时，IP网络将发送SIP ACK请求以确认接收。
A.3.2. SIP to QSIG, using overlap receiving on SIP and en bloc sending on QSIG
A.3.2. SIP到QSIG，使用SIP上的重叠接收和QSIG上的整体发送
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |------------------------->| | |
| 1-484 | | |
2 |<-------------------------| | |
| 1-ACK | | |
3 |------------------------->| | |
| 2-INVITE | | |
1 |------------------------->| | |
| 2-484 | | |
2 |<-------------------------| | |
| 2- ACK | | |
3 |------------------------->| | |
| 3-INVITE | | QSIG SETUP |
4 |------------------------->|.......|------------------------>|6
| 3-100 TRYING | | QSIG CALL PROCEEDING |
5 |<-------------------------| |<------------------------|7
| 3-180 RINGING | | QSIG ALERTING |
9 |<-------------------------|.......|<------------------------|8
| | | |
| | | |
| 4-PRACK | | |
10|------------------------->| | |
| 4-200 OK | | |
11|<-------------------------| | |
| 3-200 OK | | QSIG CONNECT |
14|<-------------------------|.......|<------------------------|12
| | | |
| 3-ACK | | QSIG CONNECT ACK |
15|------------------------->| |------------------------>|13
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |------------------------->| | |
| 1-484 | | |
2 |<-------------------------| | |
| 1-ACK | | |
3 |------------------------->| | |
| 2-INVITE | | |
1 |------------------------->| | |
| 2-484 | | |
2 |<-------------------------| | |
| 2- ACK | | |
3 |------------------------->| | |
| 3-INVITE | | QSIG SETUP |
4 |------------------------->|.......|------------------------>|6
| 3-100 TRYING | | QSIG CALL PROCEEDING |
5 |<-------------------------| |<------------------------|7
| 3-180 RINGING | | QSIG ALERTING |
9 |<-------------------------|.......|<------------------------|8
| | | |
| | | |
| 4-PRACK | | |
10|------------------------->| | |
| 4-200 OK | | |
11|<-------------------------| | |
| 3-200 OK | | QSIG CONNECT |
14|<-------------------------|.......|<------------------------|12
| | | |
| 3-ACK | | QSIG CONNECT ACK |
15|------------------------->| |------------------------>|13
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
Figure 7: Typical message sequence for successful call establishment from SIP to QSIG, using overlap receiving on SIP and en bloc sending on QSIG
图7：使用SIP上的重叠接收和QSIG上的整体发送，成功建立从SIP到QSIG的呼叫的典型消息序列
1 The IP network sends a SIP INVITE request to the gateway. 2 Due to an insufficient number of digits, the gateway returns a SIP 484 (Address Incomplete) response. 3 The IP network acknowledges the SIP 484 (Address Incomplete) response.
1 IP网络向网关发送SIP INVITE请求。2由于位数不足，网关返回SIP 484（地址不完整）响应。3 IP网络确认SIP 484（地址不完整）响应。
4 The IP network sends a new SIP INVITE request with the same Call-ID and updated Request-URI. 5 The gateway now has all the digits required to route the call to the PISN. The gateway sends back a SIP 100 (Trying) response. 6 The gateway sends a QSIG SETUP message. 7 The PISN sends a QSIG CALL PROCEEDING message to the gateway. 8 A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted. 9 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response. 10 The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 11 The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request. 12 The PISN sends a QSIG CONNECT message to the gateway when the call is answered. 13 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the CONNECT message. 14 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 15 The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
4 IP网络发送具有相同呼叫ID和更新请求URI的新SIP INVITE请求。5网关现在拥有将呼叫路由到PISN所需的所有数字。网关发回SIP 100（尝试）响应。6网关发送QSIG设置消息。7 PISN向网关发送QSIG呼叫继续消息。8返回QSIG警报消息，指示PISN中的最终用户正在收到警报。9网关将QSIG警报消息映射到SIP 180（振铃）响应。10 IP网络可以基于在初始SIP INVITE请求中包含Require报头或带有选项标签100rel的受支持报头，将SIP PRACK请求发送回IP网络。11网关发送SIP 200（OK）响应以确认SIP PRACK请求。12当呼叫应答时，PISN向网关发送QSIG CONNECT消息。13网关发送QSIG CONNECT确认消息以确认连接消息。14 QSIG CONNECT消息映射到SIP 200（OK）响应。15在接收到SIP INVITE final响应（200）时，IP网络将发送SIP ACK请求以确认接收。
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |------------------------->| | |
| 1-484 | | |
2 |<-------------------------| | |
| 1-ACK | | |
3 |------------------------->| | |
| 2-INVITE | | QSIG SETUP |
4 |------------------------->|.......|------------------------>|6
| 2-100 TRYING | | QSIG SETUP ACK |
5 |<-------------------------| |<------------------------|7
| 3- INVITE | | QSIG INFORMATION |
8 |------------------------->|.......|------------------------>|10
| 3-100 TRYING | | |
9 |<-------------------------| | QSIG CALL PROCEEDING |
| | |<------------------------|11
13| 3-180 RINGING | | QSIG ALERTING |
|<-------------------------|.......|<------------------------|12
| 2-484 | | |
14|<-------------------------| | |
| 2-ACK | | |
15|------------------------->| | |
| 4-PRACK | | |
16|------------------------->| | |
| 4-200 OK | | |
17|<-------------------------| | |
| 3-200 OK | | QSIG CONNECT |
20|<-------------------------|.......|<------------------------|18
| | | |
| 3-ACK | | QSIG CONNECT ACK |
21|------------------------->| |------------------------>|19
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |------------------------->| | |
| 1-484 | | |
2 |<-------------------------| | |
| 1-ACK | | |
3 |------------------------->| | |
| 2-INVITE | | QSIG SETUP |
4 |------------------------->|.......|------------------------>|6
| 2-100 TRYING | | QSIG SETUP ACK |
5 |<-------------------------| |<------------------------|7
| 3- INVITE | | QSIG INFORMATION |
8 |------------------------->|.......|------------------------>|10
| 3-100 TRYING | | |
9 |<-------------------------| | QSIG CALL PROCEEDING |
| | |<------------------------|11
13| 3-180 RINGING | | QSIG ALERTING |
|<-------------------------|.......|<------------------------|12
| 2-484 | | |
14|<-------------------------| | |
| 2-ACK | | |
15|------------------------->| | |
| 4-PRACK | | |
16|------------------------->| | |
| 4-200 OK | | |
17|<-------------------------| | |
| 3-200 OK | | QSIG CONNECT |
20|<-------------------------|.......|<------------------------|18
| | | |
| 3-ACK | | QSIG CONNECT ACK |
21|------------------------->| |------------------------>|19
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
Figure 8: Typical message sequence for successful call establishment from SIP to QSIG, using overlap procedures on both SIP and QSIG
图8：成功建立从SIP到QSIG的呼叫的典型消息序列，在SIP和QSIG上使用重叠过程
1 The IP network sends a SIP INVITE request to the gateway. 2 Due to an insufficient number of digits, the gateway returns a SIP 484 (Address Incomplete) response. 3 The IP network acknowledges the SIP 484 (Address Incomplete) response.
1 IP网络向网关发送SIP INVITE请求。2由于位数不足，网关返回SIP 484（地址不完整）响应。3 IP网络确认SIP 484（地址不完整）响应。
4 The IP network sends a new SIP INVITE request with the same Call-ID and updated Request-URI. 5 The gateway now has all the digits required to route the call to the PISN. The gateway sends back a SIP 100 (Trying) response to the IP network. 6 The gateway sends a QSIG SETUP message. 7 The PISN needs more digits to route the call and sends a QSIG SETUP ACKNOWLEDGE message to the gateway. 8 The IP network sends a new SIP INVITE request with the same Call-ID and From values and updated Request-URI. 9 The gateway sends back a SIP 100 (Trying) response to the IP network. 10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION message. 11 The PISN has all the digits required and sends back a QSIG CALL PROCEEDING message to the gateway. 12 A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted. 13 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response. 14 The gateway sends a SIP 484 (Address Incomplete) response for the previous SIP INVITE request. 15 The IP network acknowledges the SIP 484 (Address Incomplete) response. 16 The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request. 18 The PISN sends a QSIG CONNECT message to the gateway when the call is answered. 19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the QSIG CONNECT message. 20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 21 The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
4 IP网络发送具有相同呼叫ID和更新请求URI的新SIP INVITE请求。5网关现在拥有将呼叫路由到PISN所需的所有数字。网关向IP网络发回SIP 100（尝试）响应。6网关发送QSIG设置消息。7 PISN需要更多的数字来路由呼叫，并向网关发送QSIG设置确认消息。8 IP网络发送一个新的SIP INVITE请求，该请求具有相同的呼叫ID，并且来自值和更新的请求URI。9网关向IP网络发回SIP 100（尝试）响应。10网关将新的SIP INVITE请求映射到QSIG信息消息。11 PISN具有所需的所有数字，并向网关发回QSIG呼叫继续消息。12返回QSIG警报消息，指示PISN中的最终用户正在收到警报。13网关将QSIG警报消息映射到SIP 180（振铃）响应。14网关针对先前的SIP INVITE请求发送SIP 484（地址不完整）响应。15 IP网络确认SIP 484（地址不完整）响应。16 IP网络可以基于在初始SIP INVITE请求中包含Require报头或带有选项标签100rel的受支持报头，将SIP PRACK请求发送回IP网络。17网关发送SIP 200（OK）响应以确认SIP PRACK请求。18当呼叫应答时，PISN向网关发送QSIG CONNECT消息。19网关发送QSIG CONNECT确认消息以确认QSIG CONNECT消息。20 QSIG CONNECT消息被映射到SIP 200（OK）响应。21在接收到SIP INVITE final响应（200）时，IP网络将发送SIP ACK请求以确认接收。
Below are typical message sequences for Call Clearing from QSIG to SIP
下面是从QSIG到SIP的典型呼叫清除消息序列
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 2- BYE |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | | 2-200 OK |
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
| | | |
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 2- BYE |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | | 2-200 OK |
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
| | | |
Figure 9: Typical message sequence for call clearing from QSIG to SIP, subsequent to call establishment
图9：呼叫建立后，从QSIG到SIP的呼叫清除的典型消息序列
1 The PISN sends a QSIG DISCONNECT message to the gateway. 2 The gateway sends back a QSIG RELEASE message to the PISN in response to the QSIG DISCONNECT message. 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 4 The gateway maps the QSIG DISCONNECT message to a SIP BYE request. 5 The IP network sends back a SIP 200 (OK) response to the SIP BYE request. All IP resources are now released.
1 PISN向网关发送QSIG断开消息。2网关向PISN发回QSIG释放消息，以响应QSIG断开消息。3 PISN发送QSIG发布完成消息作为响应。所有PISN资源现在都已发布。4网关将QSIG断开连接消息映射到SIP BYE请求。5 IP网络向SIP BYE请求发回SIP 200（OK）响应。所有IP资源现在都已释放。
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- 4XX / 6XX |
1|----------------------->|......|---------------------->|4
| QSIG RELEASE | | 1- ACK |
2|<-----------------------| |<----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- 4XX / 6XX |
1|----------------------->|......|---------------------->|4
| QSIG RELEASE | | 1- ACK |
2|<-----------------------| |<----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
Figure 10: Typical message sequence for call clearing from QSIG to SIP, during establishment of a call from SIP to QSIG (gateway has not sent a final response to the SIP INVITE request)
图10：在建立从SIP到QSIG的呼叫期间，从QSIG到SIP的呼叫清除的典型消息序列（网关尚未发送对SIP INVITE请求的最终响应）
1 The PISN sends a QSIG DISCONNECT message to the gateway 2 The gateway sends back a QSIG RELEASE message to the PISN in response to the QSIG DISCONNECT message 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 4 The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx response 5 The IP network sends back a SIP ACK request in response to the SIP 4xx-6xx response. All IP resources are now released
1 PISN向网关发送QSIG断开消息2网关向PISN发回QSIG释放消息以响应QSIG断开消息3 PISN发送QSIG释放完成消息以响应。所有PISN资源现在都已发布。4网关将QSIG断开连接消息映射到SIP 4xx-6xx响应5 IP网络发送回SIP ACK请求以响应SIP 4xx-6xx响应。所有IP资源现在都已释放
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- CANCEL |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | |1-487 Request Terminated|
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | 1- ACK |
| | |----------------------->|6
| | | |
| | | 1- 200 OK |
| | |<-----------------------|7
| | | |
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- CANCEL |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | |1-487 Request Terminated|
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | 1- ACK |
| | |----------------------->|6
| | | |
| | | 1- 200 OK |
| | |<-----------------------|7
| | | |
Figure 11: Typical message sequence for call clearing from QSIG to SIP, during establishment of a call from QSIG to SIP (gateway has received a provisional response to the SIP INVITE request but not a final response)
图11：在建立从QSIG到SIP的呼叫期间，从QSIG到SIP的呼叫清除的典型消息序列（网关已收到对SIP INVITE请求的临时响应，但不是最终响应）
1 The PISN sends a QSIG DISCONNECT message to the gateway. 2 The gateway sends back a QSIG RELEASE message to the PISN in response to the QSIG DISCONNECT message. 3 The PISN sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 4 The gateway maps the QSIG DISCONNECT message to a SIP CANCEL request (subject to receipt of a provisional response, but not of a final response). 5 The IP network sends back a SIP 487 (Request Terminated) response to the SIP INVITE request. 6 The gateway, on receiving a SIP final response (487) to the SIP INVITE request, sends back a SIP ACK request to acknowledge receipt. 7 The IP network sends back a SIP 200 (OK) response to the SIP CANCEL request. All IP resources are now released.
1 PISN向网关发送QSIG断开消息。2网关向PISN发回QSIG释放消息，以响应QSIG断开消息。3 PISN发送QSIG发布完成消息作为响应。所有PISN资源现在都已发布。4网关将QSIG断开连接消息映射到SIP取消请求（取决于收到临时响应，但不是最终响应）。5 IP网络向SIP INVITE请求发回SIP 487（请求终止）响应。6网关在接收到对SIP INVITE请求的SIP最终响应（487）时，发回SIP ACK请求以确认接收。7 IP网络向SIP取消请求发回SIP 200（OK）响应。所有IP资源现在都已释放。
Below are typical message sequences for Call Clearing from SIP to QSIG
下面是从SIP到QSIG的典型呼叫清除消息序列
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 2- BYE | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 2-200 OK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 2- BYE | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 2-200 OK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
Figure 12: Typical message sequence for call clearing from SIP to QSIG, subsequent to call establishment
图12：呼叫建立后，从SIP到QSIG的呼叫清除的典型消息序列
1 The IP network sends a SIP BYE request to the gateway. 2 The gateway sends back a SIP 200 (OK) response to the SIP BYE request. All IP resources are now released. 3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message. 4 The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
1 IP网络向网关发送SIP BYE请求。2网关向SIP BYE请求发回SIP 200（OK）响应。所有IP资源现在都已释放。3网关将SIP BYE请求映射到QSIG断开连接消息。4 PISN向网关发回QSIG释放消息，以响应QSIG断开连接消息。5网关发送QSIG释放完成消息作为响应。所有PISN资源现在都已发布。
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- 4XX / 6XX | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 1- ACK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
| | | |
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- 4XX / 6XX | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 1- ACK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
| | | |
Figure 13: Typical message sequence for call clearing from SIP to QSIG, during establishment of a call from QSIG to SIP (gateway has not previously received a final response to the SIP INVITE request)
图13：在建立从QSIG到SIP的呼叫期间，从SIP到QSIG的呼叫清除的典型消息序列（网关以前没有收到SIP INVITE请求的最终响应）
1 The IP network sends a SIP 4xx-6xx response to the gateway. 2 The gateway sends back a SIP ACK request in response to the SIP 4xx-6xx response. All IP resources are now released. 3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT message. 4 The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
1 IP网络向网关发送SIP 4xx-6xx响应。2网关发回SIP ACK请求以响应SIP 4xx-6xx响应。所有IP资源现在都已释放。3网关将SIP 4xx-6xx响应映射到QSIG断开连接消息。4 PISN向网关发回QSIG释放消息，以响应QSIG断开连接消息。5网关发送QSIG释放完成消息作为响应。所有PISN资源现在都已发布。
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- CANCEL | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|4
| | | QSIG RELEASE |
| | |<-----------------------|5
|1-487 Request Terminated| | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|6
| | | |
| 1- ACK | | |
3|----------------------->| | |
| | | |
| 1- 200 OK | | |
4|<-----------------------| | |
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- CANCEL | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|4
| | | QSIG RELEASE |
| | |<-----------------------|5
|1-487 Request Terminated| | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|6
| | | |
| 1- ACK | | |
3|----------------------->| | |
| | | |
| 1- 200 OK | | |
4|<-----------------------| | |
Figure 14: Typical message sequence for call clearing from SIP to QSIG, during establishment of a call from SIP to QSIG (gateway has sent a provisional response to the SIP INVITE request but not a final response)
图14：在建立从SIP到QSIG的呼叫期间，从SIP到QSIG的呼叫清除的典型消息序列（网关已向SIP INVITE请求发送临时响应，但未发送最终响应）
1 The IP network sends a SIP CANCEL request to the gateway. 2 The gateway sends back a SIP 487 (Request Terminated) response to the SIP INVITE request. 3 The IP network, on receiving a SIP final response (487) to the SIP INVITE request, sends back a SIP ACK request to acknowledge receipt. 4 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL request. All IP resources are now released. 5 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT message. 6 The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 7 The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
1 IP网络向网关发送SIP取消请求。2网关向SIP INVITE请求发回SIP 487（请求终止）响应。3 IP网络在接收到对SIP INVITE请求的SIP最终响应（487）时，发回SIP ACK请求以确认接收。4网关向SIP取消请求发回SIP 200（OK）响应。所有IP资源现在都已释放。5网关将SIP 4xx-6xx响应映射到QSIG断开连接消息。6 PISN向网关发回QSIG释放消息，以响应QSIG断开连接消息。7网关发送QSIG释放完成消息作为响应。所有PISN资源现在都已发布。
Authors' Addresses
作者地址
John Elwell Siemens plc Technology Drive Beeston Nottingham, UK, NG9 1LA
John Elwell西门子plc技术驱动英国诺丁汉比斯顿，NG9 1LA
EMail: john.elwell@siemens.com
EMail: john.elwell@siemens.com
Frank Derks NEC Philips Unified Solutions Anton Philipsweg 1 1223 KZ Hilversum The Netherlands
Frank Derks NEC Philips统一解决方案安东Philipsweg 1 1223 KZ Hilversum荷兰
EMail: frank.derks@nec-philips.com
EMail: frank.derks@nec-philips.com
Olivier Rousseau Alcatel Business Systems 32,Avenue Kleber 92700 Colombes France
奥利维尔·卢梭·阿尔卡特商业系统法国科伦坡克莱伯大道32号92700
EMail: Olivier.Rousseau@alcatel.fr
EMail: Olivier.Rousseau@alcatel.fr
Patrick Mourot Alcatel Business Systems 1,Rue Dr A. Schweitzer 67400 Illkirch France
Patrick Mourot Alcatel Business Systems 1，法国伊尔基奇A.Schweitzer街67400号
EMail: Patrick.Mourot@alcatel.fr
EMail: Patrick.Mourot@alcatel.fr
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。