[要約] RFC 4497は、SIPとQSIG間の相互運用性を向上させるためのガイドラインです。目的は、SIPとQSIGの相互運用性の問題を解決し、異なる通信プロトコル間のシームレスな通信を実現することです。
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).
Copyright（c）The Internet Society（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は、1人以上の参加者とセッションを作成、変更、終了するためのインターネットアプリケーション層制御（シグナリング）プロトコルです。これらのセッションには、特に電話が含まれます。QSIGは、プライベート統合サービスネットワーク（PISNS）内で（特に電話）のサーキットスイッチングコール（特に電話）を作成、変更、および終了するためのシグナリングプロトコルです。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
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は、サーキットを切り替えた基本サービスと補足サービスをユーザーに提供します。QSIGはECMA標準で指定されています。特に、[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基準点は、2つの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.
企業ネットワーク内でのテレフォニーのサポートが回路で縮小されたテクノロジーからインターネットテクノロジーに進化するにつれて、2つのテクノロジーは、おそらく数年、多くのネットワークに共存します。したがって、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.
このドキュメントは、QSIGを採用しているPISNとSIPを採用する企業IPネットワークの間で、音声、DTMF、ファクシミリ、およびモデムメディアの双方向転送能力を提供する基本サービスのSIP-QSIGシグナリングインターワーキングを指定します。たとえば、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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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ネットワーク（イントラネット）、または2つの組み合わせで構成できます。
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を使用して確立されたセッションに参加するゲートウェイとピアエンティティの間の単一の方向に、通常RTPを含むUDPパケットに送信されるオーディオまたはその他のユーザー情報。
NOTE: Normally a SIP session establishes a pair of media streams, one in each direction.
注：通常、SIPセッションは、各方向に1つのメディアストリームを確立します。
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].
[2]に従って、スイッチングおよびコール処理機能とQSIGシグナル伝達をサポートすることを含むPISNノーダルエンティティ。
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セッションエージェント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.
1980年代、企業の音声通信は、原則として統合サービスデジタルネットワーク（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は、上記のようにネットワークで使用するための国際的に標準化されたメッセージベースのシグナル伝達プロトコルです。2つのPINXの間のシグナリングチャネルで実行され、同じ2つの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の発生と終了を接続する単一のピンクス間リンク、またはTransit Pinxsとして知られる中間PINXでの切り替えと直列のいくつかのピンクス間リンクを介してルーティングできます。別のネットワークで呼び出しが発生または終了する可能性があります。この場合、ゲートウェイPINXを介してPISN環境に入るか、出発します。当事者は、[17]またはプライベート番号の計画に従って、数字で識別されます。この基本的な呼び出し機能は[2]で指定されています。基本的なコール機能に加えて、QSIGは、PISNSでの補足サービスの使用をサポートする多くのさらなる機能を指定しています。
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 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.
最近では、企業の通信ネットワークがさまざまな方法でIPを悪用し始めています。1つの方法は、SIPを使用してネットワークの一部をIPに移行することです。これは、たとえば、PINXの代わりにSIPプロキシとSIPエンドポイントを備えた新しい支店である可能性があります。または、SIP機器を使用して、既存のPINXまたはPINXを交換する場合があります。新しいSIP環境では、ある環境に由来し、もう1つの環境で終了するコールをサポートするために、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.
QSIGとGatewaysでのSIPの間のインターワーキングも使用することもできます。SIPネットワークがPISNの異なる部分を相互に接続し、さまざまな部品間の呼び出しを可能にします。通話は、あるゲートウェイで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の2つの部分を接続する別の方法は、2つの部分の間の呼び出しに対してSIPメッセージでQSIGシグナリングをカプセル化することです。これはこの仕様の範囲外ですが、将来の仕事の主題である可能性があります。
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 |
+------+ +------+
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
- 1つ以上のリンクをサポートするPISN側の1つ以上の物理インターフェイスは、QSIGを輸送するための信頼できるレイヤー2接続（例：固定レートの物理チャネルを介して）を提供する1つ以上のリンクを提供します。シグナリングメッセージ;と
- 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;
- レイヤー1およびレイヤー2プロトコル、ネットワークレイヤープロトコルとしてのIP [6]、およびTCP [5]を介して、輸送層プロトコルとしてのIPネットワーク側の1つ以上の物理インターフェイスが、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
- オプションでは、IPネットワーク側の追加の輸送層プロトコルとしてのTLS [7]および/またはSCTP [9]のサポートは、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]は、SIPメッセージの輸送についてUDPとTCPの両方のサポートを義務付け、この同じ目的で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 |
| | | |
+-----------------------+ +-----------------------+
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からSIPへの呼び出しは、QSIGセットアップメッセージがゲートウェイに到着したときに開始されます。QSIGセットアップメッセージはQSIGコールの確立を開始し、初期応答メッセージ（たとえば、コールフォーキング）がその呼び出しに使用されるベアラーチャネルのネゴシエーションを完了します。その後、ゲートウェイはSIP Invite Requestを送信し、QSIGと呼ばれるQSIGをRequest-URIに含めるのに適したURIに翻訳しました。SIP Inviteリクエストと結果のSIPダイアログは、正常に確立された場合、QSIGコールに関連付けられています。Inviteリクエストに対するSIP 2XX応答は、QSIG接続メッセージにマッピングされ、コールの回答を意味します。設立中、SIPとSDPによって確立されたメディアストリームは、Bearerチャネルに接続されています。
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からQSIGへの呼び出しは、SIP招待リクエストがゲートウェイに到着したときに開始されます。Gatewayは、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をサポートし、UAとして[10]に従ってSIPをサポートするものとします。特に、ゲートウェイは、[10]に従って、SIP構文とエンコード、SIP輸送層、およびSIPトランザクション層をサポートするものとします。さらに、ゲートウェイは、この仕様のセクション8、9、および10に別段の記載されている場合を除き、[10]に従ってUAのSIP TUの動作をサポートするものとします。
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エンティティがSIPメッセージの輸送層プロトコルとしてUDPとTCPの両方をサポートすることを義務付けています。他の輸送層プロトコルもサポートできます。
The gateway SHALL also support SIP reliable provisional responses in accordance with [11] as a UA.
ゲートウェイは、UAとして[11]に従って、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]および[12]のオファー/回答モデルに従って[8]に従って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]に従って、[13]および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メソッドは、この仕様の範囲外ですが、たとえば補足サービスをサポートするインターワーキングのための他の仕様の対象となる可能性があります。
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).
SIP Inviteリクエストを送信する場所を決定するために、ゲートウェイによるDNS検索の結果、多くの候補者の目的地を順番に試みることができます。これがゲートウェイによって処理される方法は、この仕様の範囲外です。ただし、SIP 4XXまたは5XXの招待リクエストに対する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メッセージはセットアップ以外のメッセージであり、ゲートウェイが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メッセージは、ヘッダーフィールドにタグパラメーターが含まれていない招待リクエストであり、進行中のトランザクションと一致しません（つまり、マージされたリクエストではありません。[10]のセクション8.2.2.2を参照）。ゲートウェイがインターワーキングを提供できるピスン。また
- 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メッセージは、ゲートウェイが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招待リクエスト。ゲートウェイはまた、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リクエスト-URI、およびSIP招待リクエストのフィールドから生成するものとします。ゲートウェイには、[11]のサポートを示すために、招待状リクエストにオプションタグ100RELを含むサポートヘッダーを含めるものとします。
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.
ゲートウェイには、セクション10で説明されているように、SIP InviteリクエストにSDP提供情報を含めるものとします。また、着信メディアストリームをInter-Pinxリンクのユーザー情報チャネルに接続して、発信者がインバンドのトーンまたはアナウンスを聞くことができるようにする必要があります回答の音声クリッピングを防ぎます。フォーキングのため、ゲートウェイは複数のメディアストリームを受信する場合があります。その場合、1つを選択する必要があります（最初に受信したものなど）。ゲートウェイが信頼できる暫定的な応答を使用して確立された特定の初期ダイアログと選択されていないメディアストリームを相関させることができる場合、更新方法[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メッセージをトリガーしてはなりません。招待状リクエストの再送信を抑制する目的のみに役立ちます。
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.
ゲートウェイは、QSIGの進捗状況または次の条件に基づいてメッセージの招待リクエストに受信したSIP 18倍の応答をマッピングするものとします。
- 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アラートメッセージを生成するものとします。ゲートウェイは、ピンクス間リンクのユーザー情報チャネルにリングバックトーンを提供する場合があります。この場合、ゲートウェイには、QSIGアラートメッセージに進行状況の説明番号を含めるものとします。それ以外の場合は、ゲートウェイが帯域内の情報（リングバックトーンなど）が送信されていることを認識していない限り、ゲートウェイにはQSIGアラートメッセージに進行状況の説明番号を含めてはなりません。
- 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を含むメッセージは送信されていません。
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を使用した要求ヘッダーが含まれている場合、ゲートウェイは[11]に従ってSIPプラックリクエストを送り返すものとします。
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 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.
GatewayがSIP Inviteリクエストに対する最初のSIP 2XX応答としてSIP 2XX応答を受信した場合、ゲートウェイはQSIG接続メッセージにSIP 2XX応答をマッピングするものとします。ゲートウェイは、2XX応答を確認するためにSIP ACKリクエストを送信するものとします。ゲートウェイには、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ネットワークで確立されます。その場合、ゲートウェイは、まだ行っていない場合は、メディアストリームを対応するユーザー情報チャネルに接続し、ピンクス間リンクに接続し、ローカルリングバックトーンを停止します。
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].
招待リクエストに対する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 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はENブロックシグナルを使用します。SIPネットワークでオーバーラップシグナル伝達を使用しないようにすることを強くお勧めします。オーバーラップシグナル伝達を扱うSIP/QSIGゲートウェイは、次のメカニズムの1つ以上を使用して、オーバーラップからENブロックシグナリング方法への変換を実行する必要があります。
- 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.
GatewayがSIPネットワークでオーバーラップからENブロックシグナルへの変換を実行する場合、セクション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招待リクエストを送信するものとします。リクエスト-URIとフィールド（セクション9を参照）は、受信したQSIGセットアップおよび情報メッセージの呼び出したパーティー番号情報要素の情報の連結から生成されるものとします。ゲートウェイはまた、QSIGコールの進行メッセージを送信するものとします。
SIP responses to INVITE requests SHALL be mapped as described in 8.2.1.
招待リクエストへの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招待リクエストを送信するものとします。それ以外の場合、ゲートウェイは、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タイマーを停止する必要があります。
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招待リクエストを送信しているかどうかによって異なります。Gatewayが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.
ゲートウェイがすでに1つ以上のSIP招待リクエストを送信している場合、それらのリクエストに対する最終的な応答が受信されたかどうかにかかわらず、[18]のセクション3.2に従って新しいSIP招待リクエストを送信するものとします。更新されたリクエスト-URIおよびフィールド（セクション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]は、以前の招待リクエストと同じように、ヘッダー（タグを含む）から同じコールアイドを持ち、同じコールアイドを持っているという新しいリクエストが必要です。[18]は、CSEQヘッダーに以前の招待リクエストの値よりも高い値を含めることを推奨しています。
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招待取引をキャンセルするものとします。
The requirements of Section 8.2.1.5 SHALL apply.
セクション8.2.1.5の要件が適用されます。
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.
SIP 4xx、5xx、または招待リクエストに対する6xxの最終応答を受け取った場合、GatewayはSIP ACKリクエストを返送するものとします。ゲートウェイが問題を回避するために招待リクエストを再試行することができない限り（たとえば、401または407の応答の場合に認証を提供することにより）、ゲートウェイはQSIG切断メッセージ（8.4.4）をそれ以上QSIG情報なしで送信するものとしますメッセージが予想され、最終的な応答が送信されたすべてのSIP招待リクエストに受信されました。
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.
他のすべてのケースでは、招待リクエストに対する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招待リクエストが送信され、そのうちの1つがコール確立が成功する可能性があります。たとえば、最初の招待リクエストは、不完全な数値から派生したリクエスト-urisをルーティングできないため、484（アドレス不完全）または404（発見されていない）応答を生成する可能性がありますが、ルーティング可能なリクエスト-URIを使用したその後の招待リクエストは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 InviteトランザクションをキャンセルするためにSIPキャンセルリクエストを送信しないでください。このSIPキャンセルリクエストは、新しいSIPがリクエストを招待し、早期コールクリアリングをトリガーする前に、出口ゲートウェイに到着する可能性があります。
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招待取引は、トランザクションを終了する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招待リクエストに対して4XX、5XX、または6XX応答を受け取った場合、ゲートウェイはQSIG切断メッセージを送信するものとします。T302が失効し、ゲートウェイが送信されたすべてのSIP招待リクエストに対して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.
注：QSIG切断要求は、すべての未払いのSIP招待リクエストが4xx、5xx、または6xxの応答を受け取ったときに送信されます。
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間リンクで適切なチャネルを使用できる場合、Gatewayは受信した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 Requestの情報がQSIGセットアップメッセージに必須の情報要素を生成するのに不適切な場合（たとえば、パーティー番号情報要素と呼ばれるQSIGをSIPリクエスト-URIフィールドから導出できない場合）、または適切なチャネルが利用できない場合ピンクス間リンクでは、ゲートウェイは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.
注：SDPがSIP招待リクエストに提供されていないことは、ゲートウェイがSDPの提供情報を暫定的な応答で送信し、SIPプラックリクエストでSDP回答情報を受け取る必要があることを意味します（[11]に従って）。PISNからのトーンとアナウンスは送信されます。SDPの応答情報はSIPプラックリクエストで返品する必要があるため、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.
注：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からQSIGに既に確立されているコールに関連するSIP招待リクエストを受け取ると、8.3.9の手順が適用されます。
The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any SIP message being sent.
QSIGコールの進行メッセージの受領は、SIPメッセージが送信されることはありません。
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 Progressメッセージに含まれています。
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進捗メッセージを招待リクエストへのSIP 183（セッションの進行状況）応答にマッピングするものとします。SIP Inviteリクエストに、必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーが含まれている場合、ゲートウェイにはSIP 183応答に、オプションタグ100RELを備えた要求ヘッダーが含まれます。
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を含めることで、PRACKリクエストを送信することにより暫定的な応答を認めるようUACに指示します。[11]また、プラックが受信されない場合は、オプションタグ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 Progressメッセージが進行状況の説明番号1または8の進行状況インジケーター情報要素を含んでいた場合、Gatewayは、SDPの回答を条件として、まだ完了していない場合は、メディアストリームをInter-Pinxリンクの対応するユーザー情報チャネルに接続するものとします。情報は、招待リクエストに対する送信された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キャンセルリクエストを待ちます。コールクリアリングが開始された場合、QSIG進捗メッセージの原因値を使用して、表1に従って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アラートメッセージをSIP 180（リンギング）応答に招待リクエストにマッピングするものとします。SIP Inviteリクエストに、必要なヘッダーまたはオプションタグ100RELを使用したサポートされているヘッダーのいずれかが含まれている場合、ゲートウェイにはSIP 180応答に、オプションタグ100RELを備えた要求ヘッダーを含めるものとします。
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を含めることで、PRACKリクエストを送信することにより暫定的な応答を認めるようUACに指示します。[11]また、プラックが受信されない場合は、オプションタグ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の進行状況インジケーター情報要素が含まれている場合、ゲートウェイは、SDPの回答を条件として、まだ行っていない場合は、メディアストリームをInter-Pinxリンクの対応するユーザー情報チャネルに接続するものとします。情報は送信されたSIP応答に含まれているか、すでに送信または受信されています。180の暫定的な対応にSDPの提供または回答情報を含めることは、セクション8.3.5に従うものとします。
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を備えた必要またはサポートされているヘッダーが含まれており、SDP提供情報がSIP招待リクエストで受信されたが、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招待リクエストでSDPオファー情報が受信されておらず、SDPオファー情報が既に送信されていない場合、SDPオファー情報はSIP 18X Prisisalに含まれます。応答。
NOTE: In this case, SDP answer information can be expected in the SIP PRACK.
注：この場合、SIPプラックで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を使用したサポートされているヘッダーも含まれていない場合、SDP回答情報はSIP 18Xの仮の応答に含まれます。
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接続メッセージをSIP招待リクエストのSIP 200（OK）最終応答にマッピングするものとします。ゲートウェイは、QSIG Connect Aumponededメッセージも送信するものとします。
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を備えた必要またはサポートされているヘッダーが含まれており、SDP提供情報がSIP招待リクエストで受信されたが、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招待リクエストで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を使用して必要なヘッダーもサポートされているヘッダーも含まれていない場合、SDP回答情報はSIP 200応答に含まれます。
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.
Gatewayは、SDP回答情報が送信されたSIP応答に含まれているか、すでに送信または受信されている場合、メディアストリームをInter-Pinxリンクの対応するユーザー情報チャネルに接続するものとします。
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プラックリクエストの受領は、QSIGメッセージが送信されることはありません。ゲートウェイは、SIPプラックリクエストに対する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プラックにSDPの回答情報が含まれており、進行状況の説明番号1または8を備えた進行状況インジケーター情報要素を含むQSIGメッセージが含まれている場合、ゲートウェイはメディアストリームを対応するユーザー情報チャネルのインターピンクスリンクに接続するものとします。
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の回答情報が含まれている場合、ゲートウェイは、まだ行っていない場合は、メディアストリームを対応するユーザー情報チャネルに接続するものとします。
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から呼び出しを受信できます。これは、招待要求の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とフィールドに異なる複数のSIP招待リクエストを受け取ります。各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;
- 同じCall-IDヘッダー。 - ヘッダーから同じ（タグを含む）; - ヘッダーにタグはありません。
- 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は、以前に受け取ったSIP Invite Requestから派生した数字のスーパーセットを使用して、呼ばれるパーティー番号を導き出すことができます。
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.
GatewayがSIPの送信を目的としたSIP Inviteリクエストを受信した場合、新しいQSIGセットアップメッセージの代わりに既存のQSIGコールのコールリファレンスを使用してQSIG情報メッセージを生成し、呼び出されたパーティー番号情報に追加の数字のみを含むものとします。エレメント。また、SIP 484アドレスの不完全な応答で以前に受け取ったSIP招待リクエストにも応答するものとします。
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.
ゲートウェイが、リクエスト-URIに関する条件を除き、オーバーラップ送信を目的としたSIP招待リクエストのすべての条件を満たすSIP招待リクエストを受信した場合、ゲートウェイはSIP 485（あいまいな）応答で新しいリクエストに応答するものとします。
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) GatewayがSIP 200（OK）応答をSIP Inviteリクエストに送信し、SIP ACKリクエストを受け取った場合、またはSIP Inviteリクエストに対するSIP 200（OK）応答を受け取ってSIP ACKリクエストを送信した場合、ゲートウェイはゲートウェイを送信した場合通話をクリアするために、SIPバイのリクエストを送信するものとします。
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) GatewayがSIP 200（OK）応答をSIP招待リクエストに送信した場合（コール確立が完了したことを示しています）、SIP ACKリクエストを受信していない場合、Gatewayは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) GatewayがSIP Inviteリクエストを送信し、SIPの暫定応答を受け取ったが、SIP最終応答ではない場合、Gatewayは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招待リクエストにSIP 2XX応答が受信された場合、Gatewayは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招待リクエストを送信したが、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招待リクエストを受信したが、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、「要求された回路またはチャネルが利用できない」です。これは、送信されたQSIGセットアップメッセージのチャネル番号がピアPINXには受け入れられないことを意味します。この場合の適切な動作は、ゲートウェイが異なるチャネル番号を示す別のセットアップメッセージを送信することです。これが不可能な場合、ゲートウェイはそれを混雑の状況（利用可能なチャネルなし、セクション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.
すべての場合において、ゲートウェイは、確立されている場合、メディアストリームを切断し、それぞれ[2]および[10]に従ってQSIGとSIPの信号を完了させることを許可します。
Table 1: Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an INVITE request
表1：QSIGのマッピングは、招待状リクエストに4xx-6xx応答をSIPする値に値を引き起こします
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）利用可能な情報
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 Requestの送信になります。ただし、SIP応答をInviteリクエストに送信する場合、デフォルトの応答コードを使用する必要があります。
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リクエストを受け取ったとき、Gatewayは原因値16（通常のコールクリアリング）のQSIG切断メッセージを送信するものとします。また、ゲートウェイは、確立されている場合、メディアストリームを切断し、それぞれ[2]および[10]に従ってQSIGとSIPシグナルを完了させることを許可します。
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リクエストに応答する場合、Gatewayは、たとえばSIP 487（リクエスト終了）応答など、他の未解決のトランザクションに応答するためにも必要です。これは、特にGatewayが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キャンセルリクエストを受け取ったときに、Gatewayが受信したSIP InviteリクエストにSIP最終応答を送信していないコールをクリアするために、Gatewayは原因値16（通常のコールクリアリング）のQSIG切断メッセージを送信します。また、ゲートウェイは、確立されている場合、メディアストリームを切断し、それぞれ[2]および[10]に従ってQSIGとSIPシグナルを完了させることを許可します。
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 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.
オーバーラップ送信のコンテキスト（8.2.2.2）のコンテキストで特に指定されている場合を除き、SIP最終応答（4xx-6xx）をSIP招待リクエストに受信します。、401または407の応答の場合に認証を提供することにより）、ゲートウェイはQSIG切断メッセージを送信するものとします。QSIG切断メッセージの原因値は、表2に従ってSIP 4XX-6XX応答から導き出されます。原因値31（通常、不特定）は、表2に示されていないSIP応答のデフォルトとして使用するものとします。確立されている場合、メディアストリームを切断し、[2]および[10]に従ってQSIGとSIPシグナルをそれぞれ完了させることができます。
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を生成する場合、情報要素を引き起こす場合、位置フィールドには、SIP応答コード6xxの結果として生成された場合、または他の状況で「リモートユーザーにサービスを提供するプライベートネットワーク」の結果を「ユーザー」に含める必要があります。
Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to QSIG Cause values
表2：QSIG原因値への招待リクエストに対するSIP 4XX-6XX応答のマッピング
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)
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：一部の応答コードの場合、ゲートウェイは問題を回避するために招待リクエストを再試行できる場合があります。特に、これは、プロトコルエラーを示す応答コードの場合に当てはまります。ゲートウェイは、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 different content in the Bearer capability information element will avoid the problem. In other circumstances, the default cause value should be used.
注8：警告ヘッダーがSIP 606または488メッセージに存在する場合、警告コードを調べて、原因値65を生成するのが妥当かどうかを判断する必要があります。この原因値は、新しい原因値を生成する必要があります。Bearer Cabability情報要素の異なるコンテンツを使用してコールしてください。問題は回避されます。他の状況では、デフォルトの原因値を使用する必要があります。
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（一時的に利用できません）を使用します。）、 適切に。
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.
ゲートウェイがSIPコールのクリアを開始した場合、[10]に従ってSIPタイマーの有効期限またはSIPプロトコルエラーに応じて、ゲートウェイは原因値102を使用して[2]に従ってQSIGコールのクリアを開始するものとします（タイマーの有効期限の回復）または41（一時的な障害）、必要に応じて。
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.
通話が正常に確立された後、ゲートウェイは、PISN内で使用されているベアラー機能と互換性のない方法でコールのメディア特性を変更するためのSIP招待リクエストを受信した場合、ゲートウェイは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では、ユーザーは、[10]で指定されたFromとHeaderを含むリクエスト-URIおよびさまざまなヘッダー内および[14]で指定されたP-Asserted-Identityヘッダーを含むさまざまなヘッダー内で伝達されるユニバーサルリソース識別子（URI）によって識別されます。さらに、プライバシーは[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）フィールドのタイプ（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ノードと同じ信頼ドメイン（[14]で定義されている）にあるかどうか（つまり、招待リクエストが送信されるプロキシまたはUAにあるか、招待リクエストが受信されるかどうかに依存します。）プライバシーヘッダーのIDプライバシーの要求を尊重する。これはネットワーク依存であり、P-Asserted-Identityヘッダーをサポートするゲートウェイが、この点で信頼される次のホップノードの構成可能なリストを保持することをお勧めします。
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リクエストにマッピングする場合、GatewayはQSIGの番号をパーティー番号情報に変換し、SIPリクエスト-URIおよびヘッダーにそのURIを含めます。
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派生はなく、プレゼンテーションインジケーターには「プレゼンテーションが制限されている」値がありません
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.
この場合（通話党番号の情報要素がない場合を含む）、ゲートウェイには、Headerのゲートウェイを識別するURIを含めるものとします。また、ゲートウェイが[14]で定義されているメカニズムをサポートしている場合、ゲートウェイはPアサート付きアイデンティティヘッダーを生成してはなりません。
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値パラメーターの追加値を含めることは、この仕様の範囲外です。
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ヘッダーを生成するものとします。「ID」、およびヘッダーから匿名を生成するものとします。プライバシーヘッダーにPRIV値パラメーターの追加値を含めることは、この仕様の範囲外です。
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アサート付きアイデンティティヘッダーを生成し、派生URIをFrom Headerに含めるものとします。さらに、[10]のセクション23で説明されているように、ゲートウェイはS/MIMEを使用して、[20]に記載されているように、招待要求のメッセージ/SIPFRAGボディに含まれるHeaderのコピーに署名することができます。
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をマッピングすると、メッセージを接続すると、招待リクエストへの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派生はなく、プレゼンテーションインジケーターには「プレゼンテーションが制限されている」値がありません
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値パラメーターの追加値を含めることは、この仕様の範囲外です。
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値パラメーターの追加値を含めることは、この仕様の範囲外です。
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].
この場合、ゲートウェイがこのヘッダーをサポートし、プライバシーヘッダーを生成しない場合、ゲートウェイは導出されたURIを含むPアサート付きアイデンティティヘッダーを生成するものとします。さらに、ゲートウェイは、[10]のセクション23で説明されているように、S/MIMEを使用して、派生URIを含むヘッダーに署名します。20]。
NOTE: The To header in the message/sipfrag body may differ from the to header in the response's headers.
注：メッセージ/sipfragボディのヘッダーへは、応答のヘッダーのヘッダーまで異なる場合があります。
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ノード（つまり、招待リクエストが送信されるプロキシまたはUA）を信頼するかどうかによって異なります。これはネットワーク依存であり、ゲートウェイは、この点で信頼される次のホップノードの構成可能なリストを保持することをお勧めします。
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を使用して、呼び出しパーティー番号情報要素の数字を導出する準備ができているかどうかによって異なります。原則として情報は信頼できないソース（リモートUA）からのものであるため、デフォルトの動作は、この目的のためにヘッダーから符号なしまたは未検証を使用しないでください。ただし、一部のネットワーク管理者は、誤った情報を提供するリスクを上回る、発信者番号を提供することから得られる利益が得られると信じているかもしれないことが認識されています。したがって、ゲートウェイは、この目的のためにヘッダーから符号なしまたは未検証を使用するように構成可能である場合があります。
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の招待リクエストをQSIGセットアップメッセージにマッピングする場合、ゲートウェイはSIPリクエスト-URIのURIを数値に変換し、QSIGと呼ばれる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.
注：ヘッダーからこの目的のために使用しないでください。これは、SIPネットワークでのリクエストの再ターゲティングがリクエスト-URIを変更する可能性があるが、ヘッダーを変更せずに放置する可能性があるためです。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のマッピングを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]がヘッダーからAを含む場合、およびゲートウェイがこの機能をサポートし、この情報の信頼性と信頼性を検証できる場合、ゲートウェイはそのヘッダーのURI。メッセージ/sipfrag本体から派生した数字がない場合、SIP招待リクエストに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 HeaderのURIからの数を導出しようとします。数値がFrom Headerから派生している場合、ゲートウェイには、Calling Party番号情報要素にそれを含め、スクリーニングインジケーターに「スクリーニングされていない」値「ユーザー」を含めるものとします。
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リクエストには、パラメーターPriv-Valueに値「ID」を備えたプライバシーヘッダーが含まれ、ゲートウェイはこのヘッダーをサポートします。。ローカルポリシーに基づいて、ゲートウェイは他の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.
QSIG接続メッセージへの招待リクエストへのSIP 2XX応答をマッピングする場合、ゲートウェイは次のように接続された番号情報要素を生成するものとします。
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]ボディがヘッダーを含み、ゲートウェイがこの機能をサポートし、この情報の信頼性と信頼性を検証できる場合、ゲートウェイは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」を備えたプライバシーヘッダーが含まれ、ゲートウェイがこのヘッダーをサポートする場合、ゲートウェイにはプレゼンテーションインジケーターに値「プレゼンテーション制限」を含めるものとします。ローカルポリシーに基づいて、ゲートウェイは他の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.
このドキュメントは、2つのネットワーク間で音声、ファクシミリ、およびモデムメディアに双方向転送能力を提供する基本サービスのシグナリングインターワーキングを指定します。
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オファー情報に基づいて、QSIGセットアップメッセージにBearer Cabability情報要素を生成するものとします。SIP InviteリクエストにはSDPの提供情報が含まれていない場合、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.
さらに、ゲートウェイには、Gatewayが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)
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 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セットアップメッセージの情報に基づいて、SIP Inviteリクエストに含めるSDPオファー情報を生成するものとします。ゲートウェイでは、QSIGの低レイヤー互換性および/または高層互換情報要素を考慮に入れることができます。QSIGセットアップメッセージに存在する場合、SDPが提供する場合、この仕様の範囲外である場合、SDPが提供されます。それ以外の場合、ゲートウェイは、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
Normal considerations apply for UA use of SIP security measures, including digest authentication, TLS, and S/MIME as described in [10].
[10]に記載されているように、Digest認証、TLS、S/MIMEなど、SIPセキュリティ対策のUA使用には通常の考慮事項が適用されます。
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ヘッダーに翻訳すると、プライバシーとセキュリティの懸念が導入されます。たとえば、発信者番号情報要素がHeaderに公然とマッピングされている場合、ユーザーにプレゼンテーション制限を要求するユーザーに適切なプライバシーを提供するように注意する必要があります。この特定の状況に対処するための手順は、セクション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.
ただし、次の段落に列挙されているQSIG情報要素へのSIPヘッダーのマッピング、マッピングの他の方向から生じるいくつかの懸念があります。
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 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.
エンドユーザーがPISNで番号をダイヤルすると、彼らの選択はQSIGセットアップメッセージに呼ばれるパーティー番号情報要素に入力されます。同様に、SIP URIまたはTel URLと、SIP Inviteリクエストのリクエスト-URIにおけるそのオプションパラメーターは、SIPデバイスのエンドユーザーが直接作成でき、ゲートウェイの情報要素にマッピングできます。ただし、PISNでは、ポリシーはユーザーが特定の（無効または制限された）数字をダイヤルできないようにすることができます。したがって、Gatewayの実装者は、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.
QSIG原因値へのSIP応答コードのマッピングにより、いくつかの追加のリスクが生じる場合があります。SIPユーザーエージェントは、任意のSIP応答コードを備えたゲートウェイからの招待リクエストに応答する可能性があります。したがって、ゲートウェイで送信されるQ.850原因コードを（ゲートウェイでサポートするマッピングの境界内）指示することができます。結果のQSIGでは、クリアリングメッセージを呼び出します。一般的に、電話が拒否される方法は、詐欺やサービスの拒否の手段を提供する可能性は低い（たとえば、電話を請求すべきではないこと、またはネットワークが重要なリソースをオフラインにするべきであることを合図することにより）。ただし、Gatewayの実装者は、ゲートウェイ管理者が応答コードを変更して、セクション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.
この仕様では、QSIGセットアップメッセージのSIP Inviteリクエストではなく、SIP招待状のリクエストをヘッダーにマッピングするためのゲートウェイが必要です。SIP UAは、同じURIをヘッダーからリクエスト-URIに置くことが期待されていますが、これは他のSIPエンティティによって警察されていません。したがって、ゲートウェイで受け取ったリクエストURIとは異なるヘッダーURIは、コールがSIPネットワークで再ターゲットされているか、元のターゲットの信頼できる兆候として、信頼できる兆候として使用することはできません。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 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ユーザーエージェントによるリクエストのヘッダーの任意の母集団は、元のアイデンティティの正確な表現としてHeaderに依存するデバイスに十分に理解されているセキュリティの影響を持っています。ヘッダーから署名されていないまたは未確認を使用してQSIGセットアップメッセージの呼び出しパーティー番号情報要素を使用することを意図したゲートウェイは、リクエストのオリジネーターを認証し、通話番号（または一部を使用することが許可されていることを確認する必要があります。発信者の身元を確認するためのより安全な方法）。Gatewaysは、他のすべてのSIPユーザーエージェントと同様に、[10]で説明されているように、消化認証をサポートする必要があることに注意してください。同様の考慮事項は、QSIG呼び出しパーティー番号または接続された番号情報要素にマッピングするためのSIP Pアサート付きアイデンティティヘッダーの使用にも当てはまります。つまり、この情報のソースを認証する必要があります。署名済みのメッセージ/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.
コールに応答する前に、後方メディアパスのカットスルーに関連する別のクラスの潜在的なリスクがあります。このドキュメントで説明されているいくつかのプラクティスでは、メディアストリームとピンクス間リンク上のユーザー情報チャネルに接続し、後方QSIGメッセージで進行状況の説明番号1または8の送信が含まれます。これにより、メディアがエンドツーエンドでカットされる可能性があり、呼び出されたユーザーエージェントが最終的な応答を送信する前に（2XXまたはの形式で）無期限に発信者に任意のオーディオを再生する可能性があります。招待リクエストに対する高い応答コード）。また、2xx応答を送信することで充電をトリガーすることなく、コールの障害を示すためにトーンとアナウンスをプレイして、トーンとアナウンスをプレイして、トーンとアナウンスをプレイすることができます。また、早期のカットスルーは、通話に応答したときに初期メディアの切り抜きを防ぐのに役立ちます。呼び出されたユーザーエージェントがこの機能を不正に使用して、通話に応答せずにarbitrary意的な情報を送信するか、電話に出る前に、この能力を不正に使用できると考えられる敬意があります。ただし、企業ネットワークでは、充電は問題ではないことが多く、キャリアネットワークからコーポレートネットワークに到着する場合、キャリアネットワークは通常、詐欺を防ぐための措置を講じます。
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環境よりも大きくない場合があります。ただし、Gatewayの実装者は、ゲートウェイ管理者がカットスルーをオフにするか、問題が発生する可能性のある状況で展開されたときにその影響を最小限に抑える（例えば、時間制限を課すことによって）提供することをお勧めします。
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, 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.
従来のPISN電話とは異なり、SIPユーザーエージェントは、特定のリソースに到達するために複数の同時リクエストを起動できます。SIPユーザーエージェントが100ポートゲートウェイで100個のSIP招待リクエストを起動し、それによりすべてのポートを縛ることは些細なことです。悪意のあるユーザーは、回答しないことが知られている電話番号へのリクエストを起動することを選択できます。これにより、ゲートウェイのリソースが無期限に飽和する可能性があり、潜在的に料金が発生することはありません。したがって、ゲートウェイの実装者は、ポリシーに従って、同じ認証されたソースまたは同様のメカニズムに由来する同時リクエストの数をポリシーに従って制限する手段を提供したい場合があります。
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.
このドキュメントは、IPネットワークを使用したQSIGの相互運用性に関するECMA（www.ecma-international.org）での著者の活動の製品です。以前のバージョンは、標準のECMA-339として公開されています。ECMAは、この作業をRFCを公開するための基礎としてIETFで利用できるようにしました。
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.
著者は、この文書の準備とコメントの準備において、フランソワ・オーデット、アダム・ローチ、ジャン・フランソワ・レイ、トーマス・スタッハ、およびECMA TC32-TG17のメンバーの支援を認めたいと考えています。
[1] International Standard ISO/IEC 11571 "Private Integrated Services Networks (PISN) - Addressing" (also published by Ecma as Standard ECMA-155).
[1] International Standard ISO/IEC 11571 "Private Integrated Services Networks（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] International Standard 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] International Standard 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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 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。and 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 2960、2000年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：SESSION INIATIATION Protocol"、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] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、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 3325、2002年11月。
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[15] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[16] Deering、S。and 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、「Integrated Services Digital Network（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）更新方法」、RFC 3311、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の間にメッセージマッピングはありません。また、2つのメッセージを接続する点線がない場合、これは、これらが発生する時点で互いに独立していることを意味します。
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 |
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の両方でENブロック手順を使用して、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ゲートウェイは、QSIGコールの進行メッセージをPISNに送信します。これ以上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 Gatewayは、最初のSIP Inviteリクエストに必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーを含めることに基づいて、SIPプラックリクエストをIPネットワークに送り返すことができます。7 IPネットワークはゲートウェイへのSIP 200（OK）応答を送信して、SIPプラックリクエストを確認します8ゲートウェイは、このSIP 180（リンギング）応答をQSIGアラートメッセージにマップし、PISNに送信します。9 IPネットワークは、通話に応答するとSIP 200（OK）応答を送信します。10ゲートウェイは、SIP 200（OK）応答を確認するためにSIP ACKリクエストを送信します。11ゲートウェイは、QSIG接続メッセージに対するこのSIP 200（OK）応答をマッピングし、PISNに送信します。12 PISNは、QSIG Connectメッセージに応じてQSIG Connect Aumponededメッセージを送信します。
+------------------------+
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からQSIGへのオーバーラップを使用して、QSIGからSIPへの成功したコール確立のための典型的なメッセージシーケンスと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ゲートウェイは、QSIGセットアップの確認メッセージをPISNに送信します。より多くの数字が予想されます。QSIG情報メッセージ内でPISNからさらに3桁が送信されます。3a 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 Gatewayは、SIP Inviteリクエストを生成し、呼び出された番号に基づいて、IPネットワークの適切なSIPエンティティに送信します。5ゲートウェイは、QSIGコールの進行メッセージをPISNに送信します。これ以上QSIG情報メッセージは受け入れられません。6 IPネットワークは、ゲートウェイにSIP 100（試行）応答を送信します。7 IPネットワークは、SIP 180（リンギング）応答を送信します。8 Gatewayは、最初のSIP Inviteリクエストに必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーを含めることに基づいて、SIPプラックリクエストをIPネットワークに送り返すことができます。9 IPネットワークは、GatewayにSIP 200（OK）応答を送信して、SIP Prackリクエストを確認します。10ゲートウェイは、このSIP 180（リンギング）QSIGアラートメッセージに対する応答をマッピングし、PINXに送信します。11 IPネットワークは、通話に応答するとSIP 200（OK）応答を送信します。12ゲートウェイは、SIP 200（OK）応答を確認するためにSIP ACKリクエストを送信します。13ゲートウェイは、QSIG接続メッセージに対するこのSIP 200（OK）応答をマッピングし、PINXに送信します。14 PISNは、QSIG Connectメッセージに応じてQSIG Connect Aumponededメッセージを送信します。
+----------------------+
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ゲートウェイは、QSIGセットアップの確認メッセージをPISNに送信します。より多くの数字が予想されます。QSIG情報メッセージ内でPISNからさらに3桁が送信されます。4ゲートウェイがコールのルーティングに必要な最小数字を受信すると、SIP招待リクエストが生成され、桁数が不足しているため、呼び出された番号5に基づいてIPネットワークの適切なSIPエンティティに送信します。ネットワークは、SIP 484（アドレス不完全）応答を返します。6 SIP 484（アドレス不完全）応答が認められています。QSIG情報メッセージでPISNからさらに7桁が受信されます。新しい招待状は、同じcall-idと値から更新されたリクエスト-uriから送信されます。QSIG情報メッセージでPISNからさらに8桁が受信されます。QSIG情報メッセージには、完全な情報要素の送信が含まれています。9ゲートウェイは、QSIGコールの進行メッセージをPISNに送信します。これ以上の情報は受け入れられません。10 Gatewayは、更新されたRequest-URIフィールドを使用して新しいSIP Invite Requestを送信します。11 IPネットワークは、ゲートウェイにSIP 100（試行）応答を送信します。12 IPネットワークは、SIP 180（リンギング）応答を送信します。13 Gatewayは、最初のSIP Inviteリクエストに必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーを含めることに基づいて、SIPプラックリクエストをIPネットワークに送り返すことができます。14 IPネットワークは、GatewayにSIP 200（OK）応答を送信して、SIP Prackリクエストを確認します。15ゲートウェイは、このSIP 180（リンギング）応答をQSIGアラートメッセージにマッピングし、PISNに送信します。16 IPネットワークは、通話に応答するとSIP 200（OK）応答を送信します。17ゲートウェイは、SIP 200（OK）応答を確認するためにSIP ACKリクエストを送信します。18ゲートウェイは、QSIG接続メッセージに対するこのSIP 200（OK）応答をマッピングします。19 PISNは、QSIG Connectメッセージに応じてQSIG Connect Aumponededメッセージを送信します。
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 |
|<========================>| |<=======================>|
| | | |
Figure 6: Typical message sequence for successful call establishment from SIP to QSIG, using en bloc procedures
図6：ENブロック手順を使用して、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ネットワークは、GatewayにSIP Inviteリクエストを送信します。2ゲートウェイは、IPネットワークにSIP 100（試行）応答を送信します。3 SIP Inviteリクエストを受け取ったとき、Gatewayは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リクエストに必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーを含めることに基づいて、SIPプラックリクエストをIPネットワークに送信できます。8ゲートウェイは、SIP 200（OK）の応答を送信して、SIPプラックリクエストを確認します。9 PISNは、通話が応答されたときにQSIG接続メッセージをゲートウェイに送信します。10ゲートウェイは、QSIG接続メッセージを確認するQSIG Connectの確認メッセージを送信します。11 QSIG接続メッセージは、SIP 200（OK）応答にマッピングされます。12 IPネットワークは、SIP招待状の最終応答（200）を受信すると、SIP ACKリクエストを送信して領収書を確認します。
+----------------------+
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およびENブロックでのオーバーラップを使用して、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ネットワークは、Gatewayに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ネットワークは、同じCall-IDと更新されたRequest-URIで新しいSIP Inviteリクエストを送信します。5ゲートウェイには、PISNへの呼び出しをルーティングするために必要なすべての数字があります。ゲートウェイは、SIP 100（試行）応答を送り返します。6ゲートウェイはQSIGセットアップメッセージを送信します。7 PISNは、QSIGコールの進行メッセージをゲートウェイに送信します。8 QSIGアラートメッセージが返され、PISNのエンドユーザーが警告されていることを示します。9ゲートウェイは、QSIGアラートメッセージをSIP 180（リンギング）応答にマッピングします。10 IPネットワークは、最初のSIP Inviteリクエストに必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーを含めることに基づいて、SIPプラックリクエストをIPネットワークに送信できます。11ゲートウェイは、SIP 200（OK）の応答を送信して、SIPプラックリクエストを確認します。12 PISNは、通話が応答されたときにQSIG接続メッセージをゲートウェイに送信します。13 Gatewayは、QSIG Connectの確認メッセージを送信して、Connectメッセージを確認します。14 QSIG接続メッセージは、SIP 200（OK）応答にマッピングされます。15 IPネットワークは、SIP招待状の最終応答（200）を受信すると、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 |
|<========================>| |<=======================>|
| | | |
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ネットワークは、Gatewayに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ネットワークは、同じCall-IDと更新されたRequest-URIで新しいSIP Inviteリクエストを送信します。5ゲートウェイには、PISNへの呼び出しをルーティングするために必要なすべての数字があります。ゲートウェイは、IPネットワークへのSIP 100（試行）応答を送り返します。6ゲートウェイはQSIGセットアップメッセージを送信します。7 PISNは、コールをルーティングするためにさらに数字を必要とし、QSIGセットアップの確認メッセージをゲートウェイに送信します。8 IPネットワークは、同じCall-IDを使用して、値と更新されたRequest-URIを使用して、新しいSIP Inviteリクエストを送信します。9ゲートウェイは、IPネットワークへのSIP 100（試行）応答を送り返します。10ゲートウェイは、QSIG情報メッセージへの新しいSIP Inviteリクエストをマップします。11 PISNには必要なすべての数字があり、QSIGコールの進行メッセージをゲートウェイに送り返します。12 QSIGアラートメッセージが返され、PISNのエンドユーザーが警告されていることを示します。13ゲートウェイは、QSIGアラートメッセージをSIP 180（リンギング）応答にマッピングします。14ゲートウェイは、以前のSIP Inviteリクエストに対してSIP 484（アドレス不完全）応答を送信します。15 IPネットワークは、SIP 484（アドレス不完全）応答を確認します。16 IPネットワークは、最初のSIP Inviteリクエストに必要なヘッダーまたはオプションタグ100RELを備えたサポートされているヘッダーを含めることに基づいて、SIPプラックリクエストをIPネットワークに送信できます。17ゲートウェイは、SIP 200（OK）の応答を送信して、SIPプラックリクエストを確認します。18 PISNは、通話が応答されたときにQSIG接続メッセージをゲートウェイに送信します。19ゲートウェイは、QSIG接続メッセージを確認するQSIG Connectの確認メッセージを送信します。20 QSIG接続メッセージは、SIP 200（OK）応答にマッピングされます。21 IPネットワークは、SIP招待状の最終応答（200）を受信すると、領収書を確認するために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|----------------------->| | |
| | | |
| | | |
| | | |
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ゲートウェイは、QSIG切断メッセージに応じてQSIGリリースメッセージをPISNに送り返します。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|----------------------->| | |
| | | |
| | | |
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へのコールクリアリングの典型的なメッセージシーケンス（Gatewayは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に送信します。ゲートウェイは、QSIG切断メッセージに応じてQSIGリリースメッセージをPISNに送り返します3 PISNはQSIGリリース完全メッセージを送信します。すべてのPISNリソースがリリースされました。4ゲートウェイマップQSIGは、メッセージをSIP 4XX-6XX応答に切断することをマップします5 IPネットワークは、SIP 4XX-6XX応答に応じてSIP ACK要求を送り返します。すべての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
| | | |
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からQSIGからSIPへの呼び出しの確立中に、QSIGからSIPへのコールクリアリングの典型的なメッセージシーケンス（Gatewayは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ゲートウェイは、QSIG切断メッセージに応じてQSIGリリースメッセージをPISNに送り返します。3 PISNは、それに応じてQSIGリリースの完全なメッセージを送信します。すべてのPISNリソースがリリースされました。4ゲートウェイは、QSIGをSIPキャンセルリクエストに切断するメッセージをマップします（暫定的な応答の受信の対象ですが、最終的な応答ではありません）。5 IPネットワークは、SIP InviteリクエストへのSIP 487（要求終了）応答を送り返します。6 Gatewayは、SIP招待リクエストに対する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
| | | |
| | | |
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ネットワークは、GatewayにSIP Byeリクエストを送信します。2ゲートウェイは、SIP Byeリクエストに対するSIP 200（OK）応答を送り返します。すべてのIPリソースがリリースされました。3ゲートウェイは、QSIG切断メッセージへのSIPバイ要求をマップします。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
| | | |
| | | |
| | | |
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へのコールクリアリングの典型的なメッセージシーケンス（Gatewayは以前に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 4XX-6XX応答に応じてSIP ACKリクエストを送り返します。すべてのIPリソースがリリースされました。3ゲートウェイは、QSIG切断メッセージに対するSIP 4XX-6XX応答をマップします。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|<-----------------------| | |
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へのコールクリアリングの典型的なメッセージシーケンス（Gatewayは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招待リクエストへのSIP 487（要求終了）応答を送り返します。3 IPネットワークは、SIP Inviteリクエストに対するSIP最終応答（487）を受信する際に、領収書を確認するためにSIP ACKリクエストを送り返します。4ゲートウェイは、SIPキャンセル要求に対するSIP 200（OK）応答を送り返します。すべてのIPリソースがリリースされました。5ゲートウェイは、QSIG切断メッセージに対するSIP 4XX-6XX応答をマップします。6 PISNは、QSIG切断メッセージに応じてQSIGリリースメッセージをゲートウェイに送り返します。7ゲートウェイは、それに応じてQSIGリリース完全メッセージを送信します。すべてのPISNリソースがリリースされました。
Authors' Addresses
著者のアドレス
John Elwell Siemens plc Technology Drive Beeston Nottingham, UK, NG9 1LA
ジョンエルウェルシーメンスPLCテクノロジードライブビストンノッティンガム、イギリス、NG9 1LA
EMail: john.elwell@siemens.com
Frank Derks NEC Philips Unified Solutions Anton Philipsweg 1 1223 KZ Hilversum The Netherlands
フランクはNECフィリップス統一ソリューションアントンフィリップスウェグ1 1223 kz Hilversumザオランダ
EMail: frank.derks@nec-philips.com
Olivier Rousseau Alcatel Business Systems 32,Avenue Kleber 92700 Colombes France
Olivier Rousseau Alcatel Business Systems 32、Avenue Kleber 92700 Colombes France
EMail: Olivier.Rousseau@alcatel.fr
Patrick Mourot Alcatel Business Systems 1,Rue Dr A. Schweitzer 67400 Illkirch France
Patrick Mourot Alcatel Business Systems 1、Rue Dr A. Schweitzer 67400 Illkirch France
EMail: Patrick.Mourot@alcatel.fr
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。