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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.
この文書では（また企業ネットワークとしても知られる）、企業の通信ネットワーク内のセッション開始プロトコル（SIP）およびQSIG間のインターワーキングを指定します。 SIPは、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).
この文書は、企業通信ネットワーク（CN）（また企業ネットワークとして知られている）内QSIGと基本的なサービスをサポートするセッション開始プロトコル（SIP）との間のインターワーキングシグナリング指定します。
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の基準点は、二つのPINX間の境界点です。
SIP is an application-layer protocol for establishing, terminating, and modifying multimedia sessions. It is typically carried over IP [15], [16]. Telephone calls are considered a type of multimedia session where just audio is exchanged. SIP is defined in [10].
SIPは、確立終端、及びマルチメディアセッションを変更するためのアプリケーションレイヤプロトコルです。それは、典型的には、IP [15]、[16]を介して搬送されます。電話コールはオーディオだけが交換されたマルチメディアセッションのタイプと考えられています。 SIPは、[10]で定義されています。
As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will coexist in many networks for a period, perhaps several years. Therefore, there is a need to be able to establish, modify, and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG.
企業ネットワーク内の電話のサポートは、回線交換技術からインターネット技術に発展するにつれ、二つの技術は、おそらく数年、期間、多くのネットワークで共存します。したがって、確立、変更、およびSIPネットワークに参加し、QSIGネットワーク内の参加者が関与するセッションを終了することができるようにする必要があります。このようなコールは、SIPおよびQSIGの間のインターワーキングを行うゲートウェイによってサポートされています。
This document specifies SIP-QSIG signalling interworking for basic services that provide a bi-directional transfer capability for speech, DTMF, facsimile, and modem media between a PISN employing QSIG and a corporate IP network employing SIP. Other aspects of interworking, e.g., the use of RTP and SDP, will differ according to the type of media concerned and are outside the scope of this specification.
この文書では、PISN採用QSIGと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との間のインターワーキングは、企業IPネットワークのユーザ、またはPISNのユーザで終了する企業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.).
PISN用いQSIGと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.
この仕様はPISN用いQSIGと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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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ネットワーク（イントラネット）、または両者の組み合わせを含むことができます。
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.
オーディオまたはUDPパケットで送信された他のユーザ情報は、典型的にはRTPを含む、セッションに参加するゲートウェイとピアエンティティ間の単一方向にSIPを用いて確立しました。
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].
PISNノードエンティティは、スイッチングおよび処理関数を呼び出しに応じて、QSIGシグナリングをサポートすることを含む[2]。
DNS Domain Name Service IP Internet Protocol PINX Private Integrated services Network eXchange PISN Private Integrated Services Network RTP Real-time Transport Protocol SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol TLS Transport Layer Security TU Transaction User UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol
DNSドメインネームサービスIPインターネットプロトコルPINX私設総合サービス網エクスチェンジPISN私設総合サービス網RTPリアルタイムトランスポートプロトコルSCTPストリーム制御伝送プロトコルSDPセッション記述プロトコルSIPセッション開始プロトコルTCP伝送制御プロトコルTLSトランスポート層セキュリティTUトランザクションユーザUAユーザーエージェントUACユーザエージェントクライアントUASユーザエージェントサーバUDPユーザーデータグラムプロトコル
During the 1980s, corporate voice telecommunications adopted technology similar in principle to Integrated Services Digital Networks (ISDN). Digital circuit switches, commonly known as Private Branch eXchanges (PBX) or more formally as Private Integrated services Network eXchanges (PINX) have been interconnected by digital transmission systems to form Private Integrated Services Networks (PISN). These digital transmission systems carry voice or other payload in fixed-rate channels, typically 64 Kbit/s, and signalling in a separate channel. A technique known as common channel signalling is employed, whereby a single signalling channel potentially controls a number of payload channels or bearer channels. A typical arrangement is a point-to-point transmission facility at T1 or E1 rate providing a 64 Kbit/s signalling channel and 23 or 30 bearer channels, respectively. Other arrangements are possible and have been deployed, including the use of multiple transmission facilities for a signalling channel and its logically associated bearer channels. Also, arrangements involving bearer channels at sub-64 Kbit/s have been deployed, where voice payload requires the use of codecs that perform compression.
1980年代には、企業の音声通信は、統合サービスデジタル網（ISDN）と原理的に同様の技術を採用しました。一般的に私設総合サービス網の交換機（PINX）として正式に構内交換機（PBX）として知られている以上のデジタル回路のスイッチは、私設総合サービス網（PISN）を形成するために、デジタル伝送システムによって相互接続されています。これらのデジタル伝送システムは、典型的には、64キロビット/秒、固定レートのチャネルで音声又は他のペイロードを運び、そして別個のチャネルにおけるシグナリング。共通チャネルシグナリングとして知られている技術は、単一のシグナリングチャネルは、潜在的にペイロードチャネルまたはベアラチャネルの数を制御することにより、採用されています。典型的な構成は、T1またはそれぞれ64キロビット/シグナリングチャネルSおよび23個のまたは30のベアラチャネルを提供E1レートでのポイントツーポイント伝送設備です。他の構成も可能であり、シグナリングチャネルと論理的に関連するベアラ・チャネルのための複数の伝送設備の使用を含め、展開されています。また、サブ64キロビット/秒でベアラチャネルを含む構成が音声ペイロード圧縮を行うコーデックの使用を必要とする場合、展開されています。
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間の論理的に関連するベアラチャネルの数に電話を制御します。シグナリングチャネルと論理的に関連するベアラチャネルを総称間PINXリンクとして知られています。 QSIGは、シグナリングチャネルおよびベアラチャネルが設けられた上に伝送能力の種類とは無関係です。 QSIGはまた、確実に、シグナリングチャネルを介してQSIGメッセージを転送するために使用されるトランスポートプロトコルとは無関係です。
QSIG provides a means for establishing and clearing calls that originate and terminate on different PINXs. A call can be routed over a single inter-PINX link connecting the originating and terminating PINX, or over several inter-PINX links in series with switching at intermediate PINXs known as transit PINXs. A call can originate or terminate in another network, in which case it enters or leaves the PISN environment through a gateway PINX. Parties are identified by numbers, in accordance with either [17] or a private numbering plan. This basic call capability is specified in [2]. In addition to basic call capability, QSIG specifies a number of further capabilities supporting the use of supplementary services in PISNs.
QSIGは別のPINXに発信し、終了コールを確立してクリアするための手段を提供します。コールが発信を接続しPINXを終了する、または通過のPINXとして知られる中間体のPINXでスイッチングと直列のいくつかのインターPINXリンクを介して単一間PINXリンクを介してルーティングすることができます。コールは、ゲートウェイPINX介しPISN環境に入るまたは出る場合に、別のネットワークで発信または終了することができます。締約国は、[17]またはプライベート番号計画のいずれかに従って、番号で識別されています。この基本的なコール機能は、[2]で指定されています。基本的なコール機能に加えて、QSIGは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を利用し始めています。一つの方法は、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.
PISNのSIPネットワーク相互接続の異なる部分は、それによって異なる部品間でコールを可能にする場合、ゲートウェイにおけるQSIGとSIPとの間のインターワーキングを使用することもできます。コールは、一のゲートウェイでSIPネットワークに入り、別ので残すことができます。各ゲートウェイは、この仕様書に従って振る舞います。
Another way of connecting two parts of a PISN would be to encapsulate QSIG signalling in SIP messages for calls between the two parts. This is outside the scope of this specification but could be the subject of future work.
PISNの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シグナリングとSIPシグナリングを用いたIPネットワークを用いPISNとの間のゲートウェイのプロトコル相互動作態様をシグナリング指定します。ゲートウェイが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
- PISN側に1つ以上の物理インターフェイスを輸送するため、メディアストリームのための1つ以上の固定ビットレートチャネルを提供する各リンク及び信頼レイヤ2接続を（例えば、固定速度の物理チャネルを介して）は、1つまたは複数のインターPINXリンクをサポートQSIGはシグナリングメッセージ。そして
- 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ネットワーク側に1つ以上の物理インターフェイス、IPネットワーク層プロトコルとのようなUDP [6]、TCP [5]のトランスポート層プロトコルとして、これらは、SIPの輸送のために使用されていますシグナリングメッセージと、UDPの場合には、また、メディアストリームのための;
- optionally the support of TLS [7] and/or SCTP [9] as additional transport layer protocols on the IP network side, these being used for the transport of SIP signalling messages; and
- TLSのサポート必要に応じて[7]及び/又はSCTP [9] IPネットワーク側に追加のトランスポート層プロトコルは、これらがSIPシグナリングメッセージを搬送するために使用されるものとして、そして
- a means of transferring media streams in each direction between the PISN and the IP network, including as a minimum packetization of media streams sent to the IP network and de-packetization of media streams received from the IP network.
- 最小のIPネットワークに送信されたメディアストリームのパケットとメディアストリームのデパケットがIPネットワークから受信したものを含む、PISNと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.
ゲートウェイマップは、メッセージとその逆をSIPに、適切な場合、QSIGメッセージを受信し、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 SETUPメッセージがゲートウェイに到着するSIPへQSIGからの呼が開始されます。 QSIG SETUPメッセージは、QSIGコールの確立を開始し、最初の応答メッセージ（例えば、呼処理）がそのコールに使用するベアラチャネルのネゴシエーションを終了します。ゲートウェイは、次に、SIPがRequest-URIに含めるのに適したURIにQSIG被呼者番号を翻訳した、INVITEリクエストを送信します。 SIPは、INVITEリクエストを、そして得られたSIPダイアログが、正常に確立すれば、QSIGコールに関連付けられています。 INVITEリクエストにSIPの2xx応答が、コールの答えを意味する、QSIG CONNECTメッセージにマッピングされます。確立中に、SIP及びSDPによって確立されたメディアストリームはベアラチャネルに接続されています。
A call from SIP to QSIG is initiated when a SIP INVITE request arrives at the gateway. The gateway sends a QSIG SETUP message to initiate QSIG call establishment, having translated the SIP Request-URI to a number suitable for use as the QSIG called party number. The resulting QSIG call is associated with the SIP INVITE request and with the eventual SIP dialog. Receipt of an initial QSIG response message completes negotiation of the bearer channel to be used, allowing media streams established by SIP and SDP to be connected to that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 OK response to the INVITE request.
SIP要求がゲートウェイに到着INVITE場合QSIGへSIPの呼が開始されます。ゲートウェイは、QSIG被呼者番号として使用するのに適した番号にSIPリクエストURIを翻訳したQSIG呼確立を開始するQSIG SETUPメッセージを送信します。得られたQSIGコールは、SIP INVITE要求をとし、最終的なSIPダイアログに関連付けられています。初期QSIG応答メッセージの受信は、メディアストリームが、そのベアラチャネルに接続されるSIP及びSDPによって確立できるように、使用するベアラチャネルのネゴシエーションを終了します。 QSIG CONNECTメッセージがINVITE要求へのSIP 200 OK応答にマッピングされます。
Appendix A gives examples of typical message sequences that can arise.
付録Aが発生する可能性があり、典型的なメッセージシーケンスの例を示します。
In order to conform to this specification, a gateway SHALL support QSIG in accordance with [2] as a gateway and SHALL support SIP in accordance with [10] as a UA. In particular, the gateway SHALL support SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer in accordance with [10]. In addition, the gateway SHALL support SIP TU behaviour for a UA in accordance with [10] except where stated otherwise in Sections 8, 9, and 10 of this specification.
この仕様に準拠するために、ゲートウェイは、ゲートウェイとして[2]に従ってQSIGをサポートすると[10] UAなどに応じてSIPをサポートしなければなりません。特に、ゲートウェイは、SIP構文と符号化、SIP輸送層、及び[10]に従ってSIPトランザクションレイヤをサポートしなければなりません。また、ゲートウェイは、セクション8に特に明記する場合を除いて[10]、9、及び本明細書の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.
注：SIPメッセージのトランスポート層プロトコルとしてSIPエンティティをサポート[10]任務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ネットワークで信頼性の低いトランスポート・サービスを使用する際にINVITE要求する（100以外）の暫定応答の損失から回復するための準備を行います。これは、基本的なQSIGメッセージにマッピング応答の配信を確保するために重要です。
The gateway SHALL support SDP in accordance with [8] and its use in accordance with the offer/answer model in [12].
ゲートウェイは、[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]に従って、P-Asserted-Identityヘッダを指定します。
The gateway SHALL support calls from QSIG to SIP and calls from SIP to QSIG.
ゲートウェイは、QSIGからSIPへのコールとQSIGへSIPからのコールをサポートしなければなりません。
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.
SIPメソッドで定義されていない[10]または[11]本明細書の範囲外であるが、付加サービスのサポートにおけるインターワーキングのために、例えば、QSIGと相互作用するための他の仕様の対象とすることができます。
As a result of DNS lookup by the gateway in order to determine where to send a SIP INVITE request, a number of candidate destinations can be attempted in sequence. The way in which this is handled by the gateway is outside the scope of this specification. However, any behaviour specified in this document on receipt of a SIP 4xx or 5xx final response to an INVITE request SHOULD apply only when there are no more candidate destinations to try or when overlap signalling applies in the SIP network (see 8.2.2.2).
SIP INVITE要求の送信先を決定するためにゲートウェイによってDNSルックアップの結果として、候補宛先の数を順次試みることができます。これは、ゲートウェイによって処理される方法は、本明細書の範囲外です。試すかオーバーラップシグナリングはSIPネットワークに適用されたとき（8.2.2.2を参照）するにはこれ以上の候補地がある場合ただし、INVITEリクエストに対するSIPの4xxまたは5xxの最終的な応答を受信すると、この文書で指定されたすべての行動にのみ適用されるべきです。
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
-the QSIGメッセージは、SETUPメッセージであり、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.
-the QSIGメッセージは、SETUP以外のメッセージであり、ゲートウェイはQSIGとSIPとの間のインターワーキングを提供している既存の呼を識別する呼番号を含んでいます。
The processing of any valid QSIG message that does not satisfy any of these conditions is outside the scope of this specification. Also, the processing of any QSIG message relating to call-independent signalling connections or connectionless transport, as specified in [3], is outside the scope of this specification.
これらの条件のいずれかを満たしていない任意の有効なQSIGメッセージの処理は、本明細書の範囲外です。また、任意のQSIGメッセージの処理は、[3]、本明細書の範囲外であるに指定され、シグナリング接続またはコネクションレスのトランスポート非依存の呼に関する。
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を参照）は、Toヘッダーフィールドにはタグパラメータを含まないINVITEリクエストを、進行中のトランザクションと一致していないで、そして先を示しますゲートウェイは、インターワーキングを提供することができるされているPISN。または
- the SIP message is a request that relates to an existing dialog representing a call for which the gateway is providing interworking between QSIG and SIP; or
- SIPメッセージは、ゲートウェイがQSIGとSIPとの間のインターワーキングを提供されたコールを表す既存の対話に関する要求です。または
- the SIP message is a CANCEL request that relates to a received INVITE request for which the gateway is providing interworking with QSIG but for which the only response sent is informational (1xx), no dialog having been confirmed; or
- SIPメッセージは、ゲートウェイがQSIGとインターワーキングを提供するが、送信のみ応答は情報（1XX）、何もダイアログは確認されなかったされたされた受信したINVITE要求に関するCANCEL要求です。または
- 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]で指定し、[2] QSIGプロトコルタイマーが満了した場合に応じて行動するようにゲートウェイがQSIGプロトコルタイマーを実行するものとします。 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 SETUPメッセージを受信するか、またはゲートウェイがQSIG SETUPメッセージを受信し、被呼者番号情報要素内の番号が完全であることを決定することが可能である場合、以下の手順が適用されます。
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 SETUPメッセージを受信すると、ゲートウェイは、にQSIG SETUPメッセージをマッピングSHALL SIPは、INVITEリクエストを。ゲートウェイは、QSIGコールPROCEEDINGメッセージを送信しなければなりません。
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].
ゲートウェイは、ゲートウェイは、[11]のためのサポートを示すために、INVITE要求オプションタグ100relを含むSupportedヘッダに含めるものとセクション9に従ってINVITE要求をし、SIPのフィールドから、SIPリクエスト-URIを生成しなければなりません。
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.
ゲートウェイはまた、発信者がインバンドトーンやアナウンスを聞くことができるように、インターPINXリンクのユーザ情報チャネルに入ってくるメディアストリームを接続する必要があり、セクション10で説明したようにINVITE要求をSIPにSDPオファーの情報を含まなければなりませんそして、答えに音声クリッピングを防ぎます。なぜならフォークにより、ゲートウェイは、それがいずれかを選択する必要があり、その場合、複数のメディアストリームを受信することができる（例えば、最初に受信しました）。ゲートウェイは、信頼できる暫定的な応答を使用して、特定の初期ダイアログで選択されていないメディア・ストリームを相関することが確立されている場合は、そのストリームを停止してから2XX場合、再度そのストリームを開始するために、UPDATEメソッドを使用する[19] UPDATEメソッドを使用するかもしれ応答は、そのダイアログ上で受信されます。
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 SETUPメッセージを受信すると、ゲートウェイは原因値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 SETUPメッセージ内の情報は、SIP INVITEリクエストに必須フィールドのいずれかを生成するには適していない場合、またはSDP情報を生成する（リクエストURIがQSIG着番号情報要素に由来することができない場合など）、ゲートウェイはSHALL SIPのINVITEリクエストをし、[2]に従ってQSIGコールクリア手順を開始しなければならない問題ではありません。
A SIP 100 response SHALL NOT trigger any QSIG messages. It only serves the purpose of suppressing INVITE request retransmissions.
SIP 100応答は、任意のQSIGメッセージをトリガしないものとします。それだけで、要求の再送信をINVITE抑制する目的を果たします。
The gateway SHALL map a received SIP 18x response to an INVITE request to a QSIG PROGRESS or ALERTING message based on the following conditions.
ゲートウェイは、QSIG PROGRESS又は次の条件に基づいて、警報メッセージにINVITE要求を受信したSIP 18X応答をマッピングSHALL。
- 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のALERTINGメッセージを生成しなければなりません。ゲートウェイは、ゲートウェイはQSIG ALERTINGメッセージの進捗説明番号8を含むものとする場合にはインターPINXリンクのユーザ情報チャネル上でリングバックトーンを供給することができます。ゲートウェイは、帯域内情報（例えば、リングバックトーン）が送信されていることを認識していない限り、そうでなければ、ゲートウェイは、QSIGのALERTINGメッセージの進捗説明番号8を含めてはなりません。
- If a SIP 181/182/183 response is received, no QSIG ALERTING message has been sent, and no message containing progress description number 1 has been sent, the gateway SHALL generate a QSIG PROGRESS message containing progress description number 1.
- SIP 181/182/183応答を受信した場合は、QSIG警報メッセージが送信されていない、及び進行説明番号1を含むいかなるメッセージは、ゲートウェイが進行説明番号1を含むQSIG PROGRESSメッセージを生成するものと、送信されていません。
NOTE: This will ensure that QSIG timer T310 is stopped if running at the Originating PINX.
注：これは発信PINXで動作している場合QSIGタイマーT310を停止していることを確認します。
In all other scenarios, the gateway SHALL NOT map the SIP 18x response to a QSIG message.
他のすべてのシナリオでは、ゲートウェイはQSIGメッセージに対するSIP 18X応答をマッピングないもの。
If the SIP 18x response contains a Require header with option tag 100rel, the gateway SHALL send back a SIP PRACK request in accordance with [11].
SIP 18X応答がオプションタグ100relを持つRequireヘッダーが含まれている場合、ゲートウェイは、[11]に従ってSIP PRACK要求をバック送信しなければなりません。
If the gateway receives a SIP 2xx response as the first SIP 2xx response to a SIP INVITE request, the gateway SHALL map the SIP 2xx response to a QSIG CONNECT message. The gateway SHALL also send a SIP ACK request to acknowledge the 2xx response. The gateway SHALL
ゲートウェイは、SIP INVITE要求を第1のSIP 2xx応答としてSIPの2xx応答を受信した場合、ゲートウェイはQSIG CONNECTメッセージにSIPの2xx応答をマッピングSHALL。また、ゲートウェイは、2xx応答を確認するためにSIP ACKリクエストを送信しなければなりません。ゲートウェイ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.
SIP ACKリクエストに任意のSDP情報は含まれませ。ゲートウェイは、さらに2xx応答を受信した場合、それはそれぞれのBYE要求を発行する必要があり、[10]に従い、それぞれに応答しなければならない、そしてそれ以上のQSIGメッセージを生成しないものとします。
Media streams will normally have been established in the IP network in each direction. If so, the gateway SHALL connect the media streams to the corresponding user-information channel on the inter-PINX link if it has not already done so and stop any local ring-back tone.
メディアストリームは、通常、それぞれの方向にIPネットワークで確立されているでしょう。もしそうであれば、ゲートウェイは、それがまだ行っていない場合間PINXリンクに対応するユーザ情報チャネルにメディアストリームを接続し、ローカルリングバックトーンを停止しなければなりません。
If the SIP 2xx response is received in response to the SIP PRACK request, the gateway SHALL NOT map this message to any QSIG message.
SIPの2xx応答が、SIP PRACK要求に応答して受信された場合、ゲートウェイは、任意のQSIGメッセージにこのメッセージをマップしないもの。
NOTE: A SIP 2xx response to the INVITE request can be received later on a different dialog as a result of a forking proxy.
注：INVITE要求へのSIP 2xx応答は、フォーキングプロキシの結果として、異なるダイアログ上で、後で受信することができます。
On receipt of a SIP 3xx response to an INVITE request, the gateway SHALL act in accordance with [10].
INVITE要求へのSIP 3xx応答を受信すると、ゲートウェイは、[10]に応じて行動するものとします。
NOTE: This will normally result in sending a new SIP INVITE request.
注：これは、通常、新しいSIP INVITEリクエストを送信するになります。
Unless the gateway supports the QSIG Call Diversion Supplementary Service, no QSIG message SHALL be sent. The definition of Call Diversion Supplementary Service for QSIG to SIP interworking is beyond the scope of this specification.
ゲートウェイはQSIGコール転用付加サービスをサポートしていない限り、何のQSIGメッセージが送信されてはなりません。 SIPインターワーキング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は、ブロックシグナリングエン使用し、強くSIPネットワークにおけるオーバーラップシグナリングの使用を避けることが推奨されます。オーバーラップシグナリングを扱うSIP / QSIGゲートウェイは、次のメカニズムの一つ以上を用いる方法シグナリング一括にオーバーラップからの変換を実行する必要があります。
- timers;
- タイマー;
- numbering plan information;
- 番号計画情報。
- the presence of a Sending complete information element in a received QSIG INFORMATION message.
- 受信されたQSIG情報メッセージで送信する完全な情報要素が存在します。
If the gateway performs a conversion from overlap to en bloc signalling in the SIP network, then the procedures defined in Section 8.2.2.1 SHALL apply.
ゲートウェイは、オーバーラップからSIPネットワーク内のブロックシグナリング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 SETUPメッセージを受信すると、ゲートウェイは、メッセージをACKNOWLEDGE QSIGのSETUPを送り返すQSIGタイマT302を開始し、待つものとさらに数桁。
On receipt of each QSIG INFORMATION message containing no Sending complete information element and containing a number that the gateway cannot determine to be complete, QSIG timer T302 SHALL be restarted. When QSIG timer T302 expires or a QSIG INFORMATION message containing a Sending complete information element is received, the gateway SHALL send a SIP INVITE request as described in Section 8.2.1.1. The Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages. The gateway SHALL also send a QSIG CALL PROCEEDING message.
全く完全な情報要素を送信し、ゲートウェイが完全であることを決定することができない数を含むを含まない各QSIG情報メッセージの受信時に、QSIGタイマーT302を再起動するものとします。 QSIGタイマT302が満了するか、送信完了情報エレメントを含むQSIG情報メッセージを受信した場合、ゲートウェイはセクション8.2.1.1に記載されるようにSIP INVITE要求を送信しなければなりません。 Request-URIおよびフィールドには（セクション9を参照）を受信QSIGの設定と情報メッセージに着番号情報要素内の情報の連結から生成されなければなりません。ゲートウェイは、QSIGコールPROCEEDINGメッセージを送信しなければなりません。
SIP responses to INVITE requests SHALL be mapped as described in 8.2.1.
8.2.1で説明したようにINVITEリクエストするSIP応答がマップされなければなりません。
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ネットワークにおけるシグナリングオーバーラップ使用のための以下の手順は、ISDNユーザ部（ISUP）と相互作用するときオーバーラップ送信を使用する[18]に記載の原理に従っています。 [18]において、SIPネットワークにおけるオーバーラップ送信の使用に起因するいくつかの潜在的な問題の議論があります。これらの潜在的な問題は、QSIG-SIPインターワーキングの文脈においても適用可能であり、QSIGネットワークに送信重なりセクション8.2.2.1に従って、ゲートウェイで終了した場合に回避することができます。 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 SETUPメッセージを受信すると、ゲートウェイは、メッセージを確認し、QSIGタイマT302を開始QSIGのSETUPをバック送付しなければなりません。 QSIG SETUPメッセージは、ルートIPネットワーク内のコールに必要な最小桁数が含まれている場合、ゲートウェイはセクション8.2.1.1で指定されたSIP INVITE要求を送信しなければなりません。そうでない場合、ゲートウェイはQSIG情報メッセージに到着する複数の数字を待つものとします。
On receipt of a QSIG INFORMATION message, the gateway SHALL handle the QSIG timer T302 in accordance with [2].
QSIG情報メッセージを受信すると、ゲートウェイは、[2]に従ってQSIGタイマT302を取り扱うものとします。
NOTE: [2] requires the QSIG timer to be stopped if the INFORMATION message contains a Sending complete information element or to be restarted otherwise.
注：[2] INFORMATIONメッセージを送信する完全な情報要素が含まれているか、そうでない場合は再起動する場合QSIGタイマーを停止する必要があり。
Further behaviour of the gateway SHALL depend on whether or not it has already sent a SIP INVITE request. If the gateway has not sent a SIP INVITE request and it now has the minimum number of digits required to route the call, it SHALL send a SIP INVITE request as specified in Section 8.2.2.1.2. If the gateway still does not have the minimum number of digits required, it SHALL wait for more QSIG INFORMATION messages to arrive.
ゲートウェイの更なる行動は、それが既にSIPのINVITE要求を送信したか否かに依存するものとします。ゲートウェイは、SIP INVITE要求を送信していないと、それは今すぐ経路に必要な最小桁数を有する場合、それはセクション8.2.2.1.2に指定されたSIP INVITE要求を送信しなければなりません。ゲートウェイは、まだ必要な最小桁数を持っていない場合、それが到着するよりQSIG情報メッセージを待つものとします。
If the gateway has already sent one or more SIP INVITE requests, whether or not final responses to those requests have been received, it SHALL send a new SIP INVITE request in accordance with Section 3.2 of [18]. The updated Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages.
ゲートウェイは、既に一つ以上のSIPがこれらの要求への最終応答が受信されたか否か、INVITE要求送信した場合、それは新しいSIPは、[18]のセクション3.2に従って、INVITEリクエストを送信しなければなりません。更新のRequest-URIとフィールドへ（セクション9を参照）を受けたQSIGのSETUPとINFORMATIONメッセージに着番号情報要素内の情報の連結から生成されなければなりません。
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]同じCall-IDと前INVITEリクエストのように（タグを含む）ヘッダから同じを持つ新しい要求を必要とします。 [18]のCSeqヘッダが前INVITE要求よりも高い値を含むべきであることをお勧めします。
The requirements of Section 8.2.1.2 SHALL apply.
セクション8.2.1.2の要求事項を適用しなければなりません。
The requirements of Section 8.2.1.3 SHALL apply.
セクション8.2.1.3の要求事項を適用しなければなりません。
The requirements of Section 8.2.1.4 SHALL apply. In addition, the gateway SHALL send a SIP CANCEL request in accordance with Section 3.4 of [18] to cancel any SIP INVITE transactions for which no final response has been received.
セクション8.2.1.4の要求事項を適用しなければなりません。また、ゲートウェイには、最終的な応答が受信されていないいる任意のSIP INVITEトランザクションをキャンセルする[18]のセクション3.4に従ってリクエストをキャンセルSIPを送信しなければなりません。
The requirements of Section 8.2.1.5 SHALL apply.
セクション8.2.1.5の要求事項を適用しなければなりません。
8.2.2.2.7. Receipt of a SIP 4xx, 5xx, or 6xx Final Response to an INVITE Request
8.2.2.2.7。 SIPの4xx、5xxのの領収書、またはINVITEリクエストへの6xx最終回答
On receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request, the gateway SHALL send back a SIP ACK request. Unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL also send a QSIG DISCONNECT message (8.4.4) if no further QSIG INFORMATION messages are expected and final responses have been received to all transmitted SIP INVITE requests.
SIP 4XX、5xxの、またはINVITE要求への6xx最終応答を受信すると、ゲートウェイは、SIP ACKリクエストをバック送信しなければなりません。ゲートウェイは（401または407応答の場合に、認証を供給することによって、例えば）問題を回避するために、INVITE要求を再試行することができない限り、さらにQSIG情報場合、ゲートウェイは、QSIGのDISCONNECTメッセージ（8.4.4）を送信しなければなりませんメッセージは、INVITE要求が予想され、最終的な応答はすべて送信された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 INFORMATIONメッセージが予想されることはありません。
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のの受領、又はINVITE要求への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 INFORMATIONメッセージが到着した場合、これらは、成功した呼の確立につながる可能性があるそのうちの一つ送られて、さらにSIP INVITEリクエスト、になります。例えば、初期のは、Request-URIが不完全な番号に由来しているため要求は484（不完全アドレス）または404（見つかりません）応答を生じる可能性がありますINVITEルーティングすることはできません、まだルーティング可能なのRequest-URIと、後続のINVITEリクエストが2xxの最終的な応答を生じる可能性があります以上有意義4XX、5xxの、または6xxの最終的な応答。
Section 3.3 of [18] applies.
[18]適用のセクション3.3。
As stated in Section 3.4 of [18], when a gateway sends a new SIP INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL request to cancel a previous SIP INVITE transaction that has not had a final response. This SIP CANCEL request could arrive at an egress gateway before the new SIP INVITE request and trigger premature call clearing.
[18]の3.4節で述べたように、ゲートウェイが新しいSIPは、新しい数字を含むINVITEリクエストを送信するとき、それは最終的な応答がなかったINVITEトランザクション前のSIPをキャンセルするCANCELリクエストをSIPを送るべきではありません。このSIPリクエストがINVITEリクエストを、早期コールのクリアをトリガする新しいSIP前に出口ゲートウェイに到着することができCANCEL。
NOTE: Previous SIP INVITE transactions can be expected to result in SIP 4xx class responses, which terminate the transaction. In Section 8.2.2.2.5, there is provision for cancelling any transactions still in progress after a SIP 2xx response has been received.
注：前のSIP INVITEトランザクションは、トランザクションを終了SIPの4xxクラス応答をもたらすことが期待できます。セクション8.2.2.2.5では、SIPの2xx応答が受信された後にまだ進行中のトランザクションをキャンセルするための規定があります。
If QSIG timer T302 expires and the gateway has received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway has not received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL ignore any further QSIG INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at this stage.
QSIGタイマーT302が満了したとゲートウェイがINVITE要求をすべて送信SIPへの4xx、5xxの、または6xxの応答を受信した場合、ゲートウェイはQSIGのDISCONNECTメッセージを送信しなければなりません。 T302が満了し、ゲートウェイがINVITE要求をすべて送信SIPへの4xx、5xxの、または6xxの応答を受信していない場合、ゲートウェイはそれ以上のQSIG INFORMATIONメッセージを無視するが、この段階ではQSIGのDISCONNECTメッセージを送信してはなりません。
NOTE: A QSIG DISCONNECT request will be sent when all outstanding SIP INVITE requests have received 4xx, 5xx, or 6xx responses.
注：すべての未処理のSIP INVITEリクエストはの4xx、5xxの、または6xxの応答を受け取ったときQSIG切断要求が送信されます。
On receipt of a SIP INVITE request for a new call, if a suitable channel is available on the inter-PINX link, the gateway SHALL generate a QSIG SETUP message from the received SIP INVITE request. The gateway SHALL generate the Called party number and Calling party number information elements in accordance with Section 9 and SHALL generate the Bearer capability information element in accordance with Section 10. If the gateway can determine that the number placed in the Called party number information element is complete, the gateway MAY include the Sending complete information element.
SIPの受信適切なチャネルがインターPINXリンク上で利用可能である場合、新しいコール要求をINVITEに、ゲートウェイは、受信したSIP INVITEリクエストからQSIG SETUPメッセージを生成しなければなりません。ゲートウェイは、セクション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内の情報は、要求が（QSIG着番号情報要素がSIPのRequest-URIフィールドに由来することができない場合、例えば）QSIG SETUPメッセージに必須の情報要素のいずれかを生成するには不向きであるINVITE場合又は全く適したチャネルが利用可能でない場合PINX間リンクを、ゲートウェイはQSIG SETUPメッセージを発行しないと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要求はSDP情報が含まれていないと必要なヘッダまたはオプションタグ100relでサポートヘッダのいずれかが含まれていない実装が代わりにSIP 488（ここでは許容できない）応答を送信することができるが、ゲートウェイは依然として、上記のように進むべきINVITE場合、その場合には、QSIG SETUPメッセージを発行しません。
NOTE: The absence of SDP offer information in the SIP INVITE request means that the gateway might need to send SDP offer information in a provisional response and receive SDP answer information in a SIP PRACK request (in accordance with [11]) in order to ensure that tones and announcements from the PISN are transmitted. SDP offer information cannot be sent in an unreliable provisional response because SDP answer information would need to be returned in a SIP PRACK request. The recommendation above still to proceed with call establishment in this situation reflects the desire to maximise the chances of a successful call. However, if important in-band information is likely to be denied in this situation, a gateway can choose not to proceed.
注：SIPにおけるSDPオファー情報の欠如は、INVITE要求をゲートウェイが暫定応答でSDPオファー情報を送信する必要があると保証するために、（[11]に従って）SIP PRACK要求でSDP回答情報を受け取る可能性があることを意味PISNからトーンおよびアナウンスメントが送信されること。 SDP回答情報は、SIP PRACK要求で返される必要があるので、SDPオファー情報は信頼できない暫定応答して送信することはできません。まだこの状況で呼確立を続行するには、上記の勧告は、成功したコールの可能性を最大化したいという願望を反映しています。重要な帯域内の情報は、このような状況で拒否される可能性がある場合は、ゲートウェイは続行しないことを選択することができます。
NOTE: If SDP offer information is present in the INVITE request, the issuing of a QSIG SETUP message is not dependent on the presence of a Required header or a Supported header with option tag 100rel.
注：SDPオファー情報は、INVITE要求に存在している場合は、QSIG SETUPメッセージの発行が必要なヘッダの存在またはオプションタグ100relを持つSupportedヘッダーに依存していません。
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 INVITEリクエストを受信すると、8.3.9の手順を適用しなければなりません。
The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any SIP message being sent.
任意のSIPメッセージをもたらさないものとQSIG呼進行メッセージの受信が送信されます。
A QSIG PROGRESS message can be received in the event of interworking on the remote side of the PISN or if the PISN is unable to complete the call and generates an in-band tone or announcement. In the latter case, a Cause information element is included in the QSIG PROGRESS message.
QSIG PROGRESSメッセージはPISNのリモート側またはPISNがコールを完了することができず、インバンドトーンやアナウンスを生成した場合のインターワーキングの場合に受信することができます。後者の場合には、原因情報要素は、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.
ゲートウェイは、INVITEリクエストに対するSIP 183（セッションプログレス）応答を受信したQSIG PROGRESSメッセージをマッピングSHALL。 SIPのINVITE場合、要求は要求ヘッダーまたはオプションタグ100relでサポートヘッダのいずれかが、ゲートウェイはSIP 183応答オプションタグ100relを持つRequireヘッダーを含むものと含まれています。
NOTE: In accordance with [11], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [11] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received.
注：[11]によれば、暫定応答のオプションタグ100relの包含は、PRACK要求を送ることによって、暫定的な応答を確認するためにUACを指示します。 [11]また、何PRACKが受信されない場合、オプションタグ100relとの暫定応答を反復するための手順を規定します。
If the QSIG PROGRESS message contained a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response to the INVITE request or has already been sent or received. Inclusion of SDP offer or answer information in the 183 provisional response SHALL be in accordance with Section 8.3.5.
QSIG PROGRESSメッセージが進行説明番号1又は8に進捗インジケータ情報要素が含まれている場合、ゲートウェイは、それがまだ行っていない場合、インターPINXリンクの対応するユーザ情報チャネルにメディアストリームを接続するSDP回答ことを条件とするものと情報は、INVITEリクエストに送信されたSIPレスポンスに含まれているか、すでに送信または受信されています。 183暫定応答でSDPオファーを含めるか答えるの情報は、セクション8.3.5に従わなければなりません。
If the QSIG PROGRESS message is received with a Cause information element, the gateway SHALL either wait until the tone/announcement is complete or has been applied for sufficient time before initiating call clearing, or wait for a SIP CANCEL request. If call clearing is initiated, the cause value in the QSIG PROGRESS message SHALL be used to derive the response to the SIP INVITE request in accordance with Table 1.
QSIG PROGRESSメッセージが原因の情報要素を受信した場合、ゲートウェイはトーン/アナウンスが完了するか、コールのクリアを開始する前に十分な時間にわたって適用されるまで待つか、SIP CANCELリクエストを待つものとのいずれか。コールのクリアが開始されている場合は、QSIG PROGRESSメッセージで原因値は、表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.
ゲートウェイは、INVITEリクエストに対するSIP 180（リンギング）応答にQSIGのALERTINGメッセージをマッピングSHALL。 SIPのINVITE場合、要求は要求ヘッダーまたはオプションタグ100relでサポートヘッダのいずれかが、ゲートウェイはSIP 180応答オプションタグ100relを持つRequireヘッダーを含むものと含まれています。
NOTE: In accordance with [11], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [11] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received.
注：[11]によれば、暫定応答のオプションタグ100relの包含は、PRACK要求を送ることによって、暫定的な応答を確認するためにUACを指示します。 [11]また、何PRACKが受信されない場合、オプションタグ100relとの暫定応答を反復するための手順を規定します。
If the QSIG ALERTING message contained a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response or has already been sent or received. Inclusion of SDP offer or answer information in the 180 provisional response SHALL be in accordance with Section 8.3.5.
QSIG警報メッセージが進行説明番号1又は8に進捗インジケータ情報要素が含まれている場合、ゲートウェイは、それがまだ行っていない場合、インターPINXリンクの対応するユーザ情報チャネルにメディアストリームを接続するSDP回答ことを条件とするものと情報は、送信されたSIP応答に含まれているか、すでに送信または受信されています。 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オファーや情報を答えるがすでに交換された場合、何のSDP情報をSIP 18xの暫定応答に含まれてはなりません。
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で受信された場合、要求をINVITEが、ない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.
何SDPオファー情報はSIPで受信されなかった場合、SIPリクエストなしSDPオファー情報が既に送信されたINVITE、SDPオファー情報は、SIP 18X仮に含めなければならない要求がオプションタグ100relで必須またはサポートされているヘッダを含まINVITE、および場合応答。
NOTE: In this case, SDP answer information can be expected in the SIP PRACK.
注：この場合、SDP回答情報は、SIP PRACKに期待することができます。
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要求が必要でも、オプションタグ100relを持つSupportedヘッダーも含まれていませんINVITE場合は、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を持つSupportedヘッダーでもないが、それは、第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.
ゲートウェイは、SIP INVITE要求をするためのSIP 200（OK）最終応答にQSIG CONNECTメッセージをマッピングSHALL。ゲートウェイは、メッセージをACKNOWLEDGE QSIG CONNECTを送信しなければなりません。
If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 200 response.
SIPは、INVITEリクエストした場合には、オプションタグ100relを持つ必須またはサポートされているヘッダを含有し、SDPオファーや情報を答えるがすでに交換された場合、何のSDP情報は、SIP 200応答に含まれてはなりません。
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リクエストは、オプションタグ100relで必須またはサポートされているヘッダを含有し、SDPオファー情報はSIPで受信された場合は、要求をINVITEが、何のSDP回答情報が送信されていないINVITE場合、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を持つ必須またはサポートされているヘッダを含有し、およびNO SDPオファー情報は、SIPで受信されなかった場合は、すでに、SDPオファー情報は、SIP 200応答に含まれるものと送信された要求なしSDPオファー情報をINVITE 。
NOTE: In this case, SDP answer information can be expected in the SIP ACK.
注：この場合、SDP回答情報は、SIP ACKに期待することができます。
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要求が必要でも、オプションタグ100relを持つSupportedヘッダーも含まれていませんINVITE場合は、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を持つSupportedヘッダーでもないが、それは、第8.3.1項に従って拒否された可能性があります。
The gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response or has already been sent or received.
それはまだ行っていない場合間PINXリンクの対応するユーザ情報チャネルにメディアストリームを接続SHALLゲートウェイは、SDP情報が送信されたSIP応答に含まれているか、すでに送信または受信された応答ことを条件とします。
The receipt of a SIP PRACK request acknowledging a reliable provisional response SHALL NOT result in any QSIG message being sent. The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK request.
任意QSIGメッセージをもたらさないものと信頼できる暫定的な応答を認めるSIP PRACK要求の受信が送信されます。ゲートウェイは、SIP PRACK要求に対するSIP 200（OK）レスポンスを返す送信しなければなりません。
If the SIP PRACK contains SDP answer information and a QSIG message containing a Progress indicator information element with progress description number 1 or 8 has been received, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link.
SIP PRACKは、SDP回答情報と受信した進捗説明番号1又は8に進捗インジケータ情報要素を含むQSIGメッセージが含まれている場合、ゲートウェイは、インターPINXリンクの対応するユーザ情報チャネルにメディアストリームを接続するものとします。
The receipt of a SIP ACK request SHALL NOT result in any QSIG message being sent.
SIP ACKリクエストの受信は、送信される任意のQSIGメッセージをもたらさないものとします。
If the SIP ACK contains SDP answer information, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so.
SIP ACKは、SDP回答情報が含まれている場合、それはまだ行っていない場合、ゲートウェイは、インターPINXリンクの対応するユーザ情報チャネルにメディアストリームを接続するものとします。
8.3.9. Receipt of a SIP INVITE Request for a Call Already Being Established
8.3.9. SIPの領収書は、すでに確立されている通話のためのINVITEリクエスト
A gateway can receive a call from SIP using overlap procedures. This should occur when the UAC for the INVITE request is a gateway from a network that employs overlap procedures (e.g., an ISUP gateway or another QSIG gateway) and the gateway has not absorbed overlap.
ゲートウェイは、オーバーラップの手順を使用してSIPからの呼を受信することができます。 UACがINVITE要求に対して重複手順（例えば、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の呼に対して、ゲートウェイは、複数のSIPが同じ呼に属しているが、異なるのRequest-URIおよびToフィールドを持つINVITE要求受信します。各SIP INVITEリクエストは異なるダイアログに属します。
A SIP INVITE request is considered to be for the purpose of overlap sending if, compared to a previously received SIP INVITE request, it has:
SIP INVITE要求がINVITE要求を以前に受信したSIPに、場合オーバーラップ送信の目的のためであると考えられて比較され、それがあります。
- the same Call-ID header;
- the same From header (including the tag);
- no tag in the To header;
- 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;
- 更新されたRequest-URIが、そこから先に受信したSIP INVITEリクエストに由来する数字のスーパーセットと被呼者番号を導出することができます。
and if
で、もし
- the gateway has not yet sent a final response other than 484 to the previously received SIP INVITE request.
- ゲートウェイは、まだ以前に受信されたSIPの484以外の最終応答INVITE要求を送信していません。
If a gateway receives a SIP INVITE request for the purpose of overlap sending, it SHALL generate a QSIG INFORMATION message using the call reference of the existing QSIG call instead of a new QSIG SETUP message and containing only the additional digits in the Called party number information element. It SHALL also respond to the SIP INVITE request received previously with a SIP 484 Address Incomplete response.
ゲートウェイは、SIPが重なりが送信のためにINVITEリクエストを受信した場合、それは代わりに新しいQSIG SETUPメッセージの既存のQSIG呼の呼番号を使用して被呼者番号情報にのみ追加の数字を含むQSIG情報メッセージを生成するものと素子。また、要求はSIP 484の住所不完全な応答を以前に受信したINVITE 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.
ゲートウェイは、SIPがRequest-URIに関する条件以外はオーバーラップ送信のためにINVITE要求をSIPための条件をすべて満たしているINVITE要求を受信した場合、ゲートウェイはSIP 485（曖昧な）応答を持つ新しい要求に応答しなければなりません。
8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE Message
8.4.1. QSIGのDISCONNECT、RELEASE、またはRELEASE COMPLETEメッセージの受信
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 DISCONNECT、RELEASE、またはメッセージをクリア第QSIGコールとしてCOMPLETEメッセージを解放を受信すると、ゲートウェイの動作は、呼確立の状態に依存するものとします。
1) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE request and received a SIP ACK request, or if it has received a SIP 200 (OK) response to a SIP INVITE request and sent a SIP ACK request, the gateway SHALL send a SIP BYE request to clear the call.
1）ゲートウェイは、SIP INVITE要求をSIP 200（OK）応答を送信し、SIP ACK要求を受信し、またはそれはSIPにSIP 200（OK）レスポンスを受信した場合はINVITE要求をし、SIP ACKリクエストを送信した場合、ゲートウェイは、コールをクリアするSIP BYEリクエストを送信しなければなりません。
2) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE request (indicating that call establishment is complete) but has not received a SIP ACK request, the gateway SHALL wait until a SIP ACK is received and then send a SIP BYE request to clear the call.
2）ゲートウェイは、呼確立が完了したことを示すSIP INVITE要求（）へのSIP 200（OK）応答を送信した場合にはSIP ACKリクエストを受信していない、ゲートウェイは、送信次いで、SIP ACKを受信するまで待機しSHALL 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.
ゲートウェイは、SIP INVITE要求を送信し、SIP暫定応答ではなく、SIP最終応答を受信した場合3）、ゲートウェイはコールをクリアする要求をSIP CANCELを送信しなければなりません。
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を送信した後、INVITE要求をSIPの2xx応答がSIPに受信されたリクエストをキャンセルすると、ゲートウェイは、SIP BYE要求を送信する必要があります。
4) If the gateway has sent a SIP INVITE request but received no SIP response, the gateway SHALL NOT send a SIP message. If a SIP final or provisional response is subsequently received, the gateway SHALL then act in accordance with 1, 2, or 3 above, respectively.
4）ゲートウェイがSIP INVITE要求を送ったが、何のSIP応答を受信しなかった場合、ゲートウェイは、SIPメッセージを送信してはなりません。 SIP最終または暫定的な応答は、その後受信された場合、ゲートウェイは、次いで、それぞれ、上記1、2、または3に応じて行動するものとします。
5) If the gateway has received a SIP INVITE request but not sent a SIP final response, the gateway SHALL send a SIP final response chosen according to the cause value in the received QSIG message as specified in Table 1. SIP response 500 (Server internal error) SHALL be used as the default for cause values not shown in Table 1.
ゲートウェイが受信した場合は5）SIPのINVITEリクエストが、SIP最終応答を送信しない、受信されたQSIGメッセージに原因値に応じて選択されたSIP最終応答を送信しなければならないゲートウェイを表1 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：これらの原因値は、ゲートウェイのみで意味があるので、必ずしもメッセージをSIPに、いくつかのQSIG原因値をマッピングすることは適切ではありません。この良い例は、送信されたQSIG SETUPメッセージ内のチャンネル番号がピアPINXに受け入れられなかったことを意味する「要求回路またはチャネルは使用できません」、原因値44です。この場合の適切な動作は、異なるチャネル番号を示す別のSETUPメッセージを送信するゲートウェイのためのものです。または（デフォルトSIP応答コードが適用される場合）、ゲートウェイ故障状況として、これが不可能な場合、ゲートウェイは、輻輳状況として（セクション8.3.1を参照のないチャネル利用可能）のいずれかに扱うべきです。
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：INVITE要求への4xx-の6xxレスポンスをSIPするQSIGのCause値のマッピング
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
タイマー満了504サーバーのタイムアウトの70のみ88互換性のない宛先に禁断のデジタル488受け入れられない、ここで（注4）情報利用できる79サービスまたはオプションではないCUG 403の501実装されていない実装、未指定87ユーザーではないメンバーを制限503サービスは使用できません102回復
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の送信につながるか、要求をキャンセルします。 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要求を受信すると、ゲートウェイは、原因値16（通常の呼クリア）とQSIGのDISCONNECTメッセージを送信しなければなりません。ゲートウェイはまた、確立された場合、メディアストリームを切断し、QSIGとSIP [2]及び[10]、それぞれに応じて完了するためにシグナリングを許可しなければなりません。
NOTE: When responding to a SIP BYE request, in accordance with [10], the gateway is also required to respond to any other outstanding transactions, e.g., with a SIP 487 (Request Terminated) response. This applies in particular if the gateway has not yet returned a final response to the SIP INVITE request.
注：SIP BYE要求に応答するとき、[10]によれば、ゲートウェイはまた、SIP 487（リクエスト終端）応答で、例えば、他の未処理のトランザクションに応答することが要求されます。ゲートウェイはまだSIPへの最終応答はINVITEリクエストを返さなかった場合、これは特に当てはまります。
On receipt of a SIP CANCEL request to clear a call for which the gateway has not sent a SIP final response to the received SIP INVITE request, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing). The gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.
SIPを受信するゲートウェイは、受信したSIPにSIP最終応答は、INVITEリクエストを送信されなかったために呼をクリアする要求をCANCEL、ゲートウェイは、原因値16（通常の呼クリア）とQSIGのDISCONNECTメッセージを送信しなければなりません。ゲートウェイはまた、確立された場合、メディアストリームを切断し、QSIGとSIP [2]及び[10]、それぞれに応じて完了するためにシグナリングを許可しなければなりません。
Except where otherwise specified in the context of overlap sending (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP INVITE request, unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL transmit a QSIG DISCONNECT message. The cause value in the QSIG DISCONNECT message
そうでない場合はSIP最終応答（4xxの-の6xx）の受信時に、（8.2.2.2）をオーバーラップ送信のコンテキストで指定された場合を除き、SIPへのゲートウェイは、問題を回避するために、INVITE要求を再試行することができない限り、INVITEリクエストを（例えば）401または407応答の場合に、認証を供給することにより、ゲートウェイは、QSIGのDISCONNECTメッセージを送付します。 QSIGのDISCONNECTメッセージに原因値
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.
31（通常、不特定の）表2原因値に応じてSIP 4XX-の6xxレスポンスに由来するものと、表2に示されていないSIP応答のための標準として使用しなければならないゲートウェイSHALLも切断メディアストリーム、確立された場合、およびQSIGとSIP [2]及び[10]、それぞれに応じて完了するためにシグナリングを可能にします。
When generating a QSIG Cause information element, the location field SHOULD contain the value "user", if generated as a result of a SIP response code 6xx, or the value "Private network serving the remote user" in other circumstances.
QSIG原因情報要素を生成するときにSIP応答コードの6xx、または値他の状況では、「リモートユーザにサービスを提供するプライベートネットワーク」の結果として生成された場合に、位置フィールドは、値「ユーザ」を含むべきです。
Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to QSIG Cause values
表2：QSIG原因値へINVITEリクエストを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)
ここで終了487リクエスト（注7）488許容できない忙しい484の住所不完全28無効な番号形式（注6）485あいまい1未割り当て番号486忙しいここ17ユーザー65ベアラ機能は実装されていませんか31通常、未指定（注8）500 Serverの内部エラー41一時的な障害501は、注文503サービスから利用不可能41一時的な障害タイマー満了505版に504ゲートウェイタイムアウト102リカバリがサポートされていない127インターワーキング、不特定（注6を実装していない79サービスまたはオプション、不特定502不正ゲートウェイ38のネットワークを実装されていません）513メッセージが大きすぎる127インターワーキング、未指定（注6）600がビジーどこでも17ユーザー多忙603衰退21コールは存在しない604を拒絶どこでも1つの未割り当て番号606ない許容65ベアラ機能が実装されたりしませ31通常、未指定（注8）
NOTE 5: In some cases, it may be possible for the gateway to provide credentials to the SIP UAS that is rejecting an INVITE due to authorization failure. If the gateway can authenticate itself, then obviously it should do so and proceed with the call. Only if the gateway cannot authorize itself should the gateway clear the call in the QSIG network with this cause value.
注5：ゲートウェイが原因許可が失敗にINVITEを拒否されたSIPのUASに資格情報を提供するためにいくつかのケースでは、それが可能です。ゲートウェイは自身を認証することができた場合は、明らかにそれはそうと、コールを進める必要があります。ゲートウェイは自身を承認できない場合にのみゲートウェイは、この原因値とQSIGネットワークにコールをクリアする必要があります。
NOTE 6: For some response codes, the gateway may be able to retry the INVITE request in order to work around the problem. In particular, this may be the case with response codes indicating a protocol error. The gateway SHOULD clear the call in the QSIG network with the indicated cause value only if retry is not possible or fails.
注6：いくつかの応答コードについて、ゲートウェイは、問題を回避するために、INVITE要求を再試行することができるかもしれません。特に、これはプロトコルエラーを示す応答コードを有する場合であってもよいです。ゲートウェイは、再試行が可能ではないか、障害が発生した場合にのみ、指定された原因値をQSIGネットワークにコールをクリアする必要があります。
NOTE 7: The circumstances in which SIP response code 487 can be expected to arise do not require it to be mapped to a QSIG cause code, since the QSIG call will normally already be cleared or in the process of clearing. If QSIG call clearing does, however, need to be initiated, the default cause value should be used.
注7：SIP応答コード487は、QSIGコールが正常にすでにまたは清算の過程でクリアされているので、QSIG原因コードにマップすることを必要としない発生すると予想することができる状況。 QSIGコールのクリアは、しかし、開始する必要がない場合は、デフォルトの原因値を使用する必要があります。
NOTE 8: When the Warning header is present in a SIP 606 or 488 message, the warning code should be examined to determine whether it is reasonable to generate cause value 65. This cause value should be generated only if there is a chance that a new call attempt with 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を生成するのが妥当であるかどうかを決定するために検討されるべきであるが、新たな可能性がある場合にのみ生成されるべきです伝達能力情報要素内のさまざまなコンテンツを持つコールの試みは、問題を回避します。他の状況では、デフォルトの原因値を使用する必要があります。
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.
ゲートウェイは、ゲートウェイはまた、セクション8.4.1に従って、SIP呼のクリアを開始しなければならない[2]に従ってQSIGタイマ満了、QSIGプロトコルエラー、またはQSIG再開メッセージの使用によりQSIGコールのクリアを開始する場合。このSIP INVITE要求に対する最終応答の送信を含む場合、ゲートウェイは、応答コード480（一時的に利用できない）任意QSIGタイマT301が満了した場合、または、そうでなければ、レスポンスコード408（要求タイムアウト）または500（サーバ内部エラーを使用しなければなりません）、 適切に。
If the gateway initiates clearing of the SIP call owing to SIP timer expiry or SIP protocol error in accordance with [10], the gateway SHALL also initiate clearing of the QSIG call in accordance with [2] using cause value 102 (Recovery on timer expiry) or 41 (Temporary failure), as appropriate.
ゲートウェイは、[10]に従ってSIPタイマ満了またはSIPプロトコルエラーに起因SIP呼のクリアを開始する場合、ゲートウェイはまた、タイマ満了の[2]原因値102を使用して（回復に従って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.
呼び出しが正常に確立された後、ゲートウェイはSIPがPISN内で使用中のベアラ機能と互換性がないような方法でコールのメディア特性を変更するためのINVITEリクエストを受信した場合、ゲートウェイは（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.
[1]で定義されるようにQSIGでは、ユーザは、数字によって識別されます。数字は、パーティの数、および接続先番号情報要素を呼び出し、着番号内を搬送されています。発番号と接続先番号情報要素はまた、プライバシーが必要であることを示すことができ、プレゼンテーションインジケータを、（プレゼンテーションが制限）を含有し、その数のソースおよび認証ステータスを示すスクリーニングインジケータ、。
In SIP, users are identified by Universal Resource Identifiers (URIs) conveyed within the Request-URI and various headers, including the From and To headers specified in [10] and optionally the P-Asserted-Identity header specified in [14]. In addition, privacy is indicated by the Privacy header specified in [13].
SIPにおいては、ユーザは、ユニバーサルリソース識別子（URIの）によって識別されるリクエストURI及び[10]で指定されたヘッダからとし、[14]で指定されたP-Asserted-Identityヘッダを任意に含む種々のヘッダ、内搬送されます。また、プライバシーは[13]で指定されたプライバシー・ヘッダによって示されています。
This clause specifies the mapping between QSIG Called party number, Calling party number, and Connected number information elements and corresponding elements in SIP.
この句は、パーティの数、および接続先番号情報要素とSIPの対応する要素を呼び出すと、着番号QSIGの間のマッピングを指定します。
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に番号を変換するために使用される方法は、本明細書の範囲外です。番号を解釈するときしかし、ゲートウェイは、数（TON）当該QSIG情報要素のフィールドの番号計画（NPI）とタイプを考慮すべきです。
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.
マッピングのいくつかの側面（すなわち、プロキシまたはUAがそのINVITEリクエストが送信されるか、または要求が受信されたINVITEそこからされたネクストホップSIPノードとして（[14]で定義されるように）ゲートウェイが同じ信頼ドメイン内にあるかどうかに依存します）プライバシーヘッダ内のアイデンティティプライバシーの要求を尊重すること。これは、ネットワークに依存するであろう、そしてP-Asserted-Identityヘッダをサポートするゲートウェイがこの点で信頼されるべき次ホップノードの設定リストを保持することが推奨されます。
9.1.1. Using Information from the QSIG Called Party Number Information Element
9.1.1. パーティー番号情報要素呼び出さQSIGからの情報を使用して
When mapping a QSIG SETUP message to a SIP INVITE request, the gateway SHALL convert the number in the QSIG Called party number information to a URI and include that URI in the SIP Request-URI and in the To header.
SIP INVITE要求にQSIG SETUPメッセージをマッピングする場合、ゲートウェイは、URIにQSIG着番号情報に番号を変換しURI SIPリクエストURIおよびでは、ヘッダへの含まなければなりません。
9.1.2. Using Information from the QSIG Calling Party Number Information Element
9.1.2. 者番号情報要素を呼び出すQSIGからの情報を使用して
When mapping a QSIG SETUP message to a SIP INVITE request, the gateway SHALL use the Calling party number information element, if present, as follows.
INVITE要求をSIPにQSIG SETUPメッセージをマッピングする際に存在する場合、以下のように、ゲートウェイは、発呼者番号情報要素を使用しなければなりません。
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.
（コーリングパーティ番号情報要素が存在しない場合を含む）この場合、ゲートウェイからヘッダにゲートウェイを識別するURIを含まなければなりません。ゲートウェイは[14]で定義された機構をサポートしている場合も、ゲートウェイは、P-Asserted-Identityヘッダを生成しないもの。
9.1.2.2. No URI derived, and presentation indicator has value "presentation restricted"
9.1.2.2。いいえURIは得られない、とプレゼンテーションインジケータは、「プレゼンテーションが制限された」値を持っています
In this case, the gateway SHALL generate an anonymous From header. Also, if the gateway supports the mechanism defined in [14], the gateway SHALL generate a Privacy header field with parameter priv-value = "id" and SHALL NOT generate a P-Asserted-Identity header. The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
この場合、ゲートウェイは、ヘッダからの匿名を生成しなければなりません。ゲートウェイは[14]で定義された機構をサポートしている場合も、ゲートウェイは、パラメータPRIV-値=「ID」とプライバシーヘッダフィールドを生成するものとし、P-Asserted-Identityヘッダを生成しないもの。プライバシーヘッダにおけるPRIV-valueパラメータの追加の値を含めることは、本明細書の範囲外です。
9.1.2.3. URI derived, and presentation indicator has value "presentation restricted"
9.1.2.3。 URIは、派生、およびプレゼンテーションインジケータが値を持っている「プレゼンテーションは制限さ」
If the gateway supports the P-Asserted-Identity header and trusts the next hop proxy to honour the Privacy header, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI, SHALL generate a Privacy header with parameter priv-value = "id", and SHALL generate an anonymous From header. The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
ゲートウェイは、P-Asserted-Identityヘッダをサポートしており、プライバシーヘッダを尊重するために次のホッププロキシを信頼している場合、ゲートウェイは、=パラメーターPRIV-値とプライバシーヘッダを生成するものと、誘導されたURIを含むP-Asserted-Identityヘッダを生成するものと「ID」、及びヘッダからの匿名を生成しなければなりません。プライバシーヘッダにおけるPRIV-valueパラメータの追加の値を含めることは、本明細書の範囲外です。
If the gateway does not support the P-Asserted-Identity header or does not trust the proxy to honour the Privacy header, the gateway SHALL behave as in Section 9.1.2.2.
ゲートウェイは、P-Asserted-Identityヘッダをサポートしていないか、プライバシーのヘッダを称えるためにプロキシを信頼していない場合は、ゲートウェイは、セクション9.1.2.2のように振る舞うものとします。
9.1.2.4. URI derived, and presentation indicator does not have value "presentation restricted"
9.1.2.4。 URIは、派生、およびプレゼンテーションインジケータが値「プレゼンテーションが制限され、」持っていません
In this case, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI if the gateway supports this header, SHALL NOT generate a Privacy header, and SHALL include the derived URI in the From header. In addition, the gateway MAY use S/MIME, as described in Section 23 of [10], to sign a copy of the From header included in a message/sipfrag body of the INVITE request as described in [20].
ゲートウェイは、このヘッダーをサポートしている場合この場合、ゲートウェイは、プライバシーヘッダを生成しないものとし、誘導されたURIを含むP-Asserted-Identityヘッダを生成するものとし、ヘッダから誘導されるURIを含むものとします。 [10]のセクション23に記載されるように加えて、ゲートウェイは、[20]に記載されているように、INVITE要求のメッセージ/ sipfragのボディに含まれるヘッダからのコピーに署名するために、S / MIMEを使用するかもしれません。
9.1.3. Using Information from the QSIG Connected Number Information Element
9.1.3. 番号情報要素接続QSIGからの情報を使用して
When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an INVITE request, the gateway SHALL use the Connected number information element, if present, as follows.
INVITE要求へのSIP 200（OK）応答にQSIG CONNECTメッセージをマッピングする際に存在する場合、以下のように、ゲートウェイは、接続先番号情報要素を使用しなければなりません。
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-値=「ID」とプライバシーヘッダフィールドを生成するものとし、P-Asserted-Identityヘッダを生成しないものをサポートしている場合。プライバシーヘッダにおけるPRIV-valueパラメータの追加の値を含めることは、本明細書の範囲外です。
9.1.3.3. URI derived, and presentation indicator has value "presentation restricted"
9.1.3.3。 URIは、派生、およびプレゼンテーションインジケータが値を持っている「プレゼンテーションは制限さ」
If the gateway supports the P-Asserted-Identity header and trusts the next hop proxy to honour the Privacy header, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI and SHALL generate a Privacy header with parameter priv-value = "id". The inclusion of additional values of the priv-value parameter in the Privacy header is outside the scope of this specification.
ゲートウェイは、P-Asserted-Identityヘッダをサポートしており、プライバシーヘッダを尊重するために次のホッププロキシを信頼している場合、ゲートウェイは、派生URIを含むP-Asserted-Identityヘッダを生成するものとし、=パラメータPRIV-値とプライバシーヘッダを生成するものと"ID"。プライバシーヘッダにおけるPRIV-valueパラメータの追加の値を含めることは、本明細書の範囲外です。
If the gateway does not support the P-Asserted-Identity header or does not trust the proxy to honour the Privacy header, the gateway SHALL behave as in Section 9.1.3.2.
ゲートウェイは、P-Asserted-Identityヘッダをサポートしていないか、プライバシーのヘッダを称えるためにプロキシを信頼していない場合は、ゲートウェイは、セクション9.1.3.2のように振る舞うものとします。
9.1.3.4. URI derived, and presentation indicator does not have value "presentation restricted"
9.1.3.4。 URIは、派生、およびプレゼンテーションインジケータが値「プレゼンテーションが制限され、」持っていません
In this case, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI if the gateway supports this header and SHALL NOT generate a Privacy header. In addition, the gateway MAY use S/MIME, as described in Section 23 of [10], to sign a To header containing the derived URI, the To header being included in a message/sipfrag body of the INVITE response as described in [20].
ゲートウェイは、このヘッダーをサポートし、プライバシーヘッダを生成しないものこの場合、ゲートウェイは、派生URIを含むP-Asserted-Identityヘッダを生成しなければなりません。に記載のように加えて、ゲートウェイは、S / MIMEは、セクション23で説明したように[10]、誘導されたURIを含むToヘッダの署名に使用するかもしれ、INVITE応答のメッセージ/ sipfragのボディに含まれるヘッダに[ 20]。
NOTE: The To header in the message/sipfrag body may differ from the to header in the response's headers.
注記：メッセージ/ sipfragボディにToヘッダは、応答のヘッダにヘッダに異なっていてもよいです。
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.
マッピングのいくつかの側面は、P-Asserted-Identityヘッダに正確な情報を提供するために、（要求が受信されたINVITEすなわち、プロキシまたはUAがそのINVITEリクエストが送信されたり、そこから）ゲートウェイが次ホップSIPノードを信頼するかどうかに依存します。これは、ネットワークに依存するだろう、とゲートウェイがこの点で、信頼されるネクストホップ・ノードの構成可能なリストを保持することをお勧めします。
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のSETUPメッセージにINVITE要求をマッピングする場合、ゲートウェイは、多数のSIPリクエストURIにURIを変換し、QSIG着番号情報要素内のその番号を含まなければなりません。
NOTE: The To header should not be used for this purpose. This is because re-targeting of the request in the SIP network can change the Request-URI but leave the To header unchanged. It is important that routing in the QSIG network be based on the final target from the SIP network.
注：Toヘッダは、この目的のために使用すべきではありません。 SIPネットワークに要求の再標的化のRequest-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 SETUPメッセージにINVITE要求をマッピングする場合、以下のように、ゲートウェイは、発呼者番号情報要素を生成しなければなりません。
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]を含み、ゲートウェイはこの機能をサポートしており、この情報の信憑性及び信頼性を検証することができれば、ゲートウェイから番号を導出するために試みなければなりませんそのヘッダにおけるURI。 SIP INVITEをも何ら番号が、メッセージ/ sipfrag体から誘導されていない場合、要求は、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.
いかなる数は、上記ゲートウェイは、ヘッダから符号なしまたは未検証を使用する用意がある場合に記載したように導出されていない場合、ゲートウェイは、ヘッダからのURIの数を導出するために試みなければなりません。番号はヘッダから誘導された場合、ゲートウェイは、発呼者番号情報要素に含めスクリーニングインジケータの「ユーザ提供は、スクリーニングされない」の値を含まなければなりません。
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-値の値「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 SETUPメッセージから情報要素を省略することができます。
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 CONNECTメッセージにINVITE要求への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の数を導出するために試みなければなりませんそのヘッダーです。 SIP 2XX応答は、P-Asserted-Identityヘッダが含まれており、ゲートウェイはそのヘッダーをサポートしており、その中の情報を信頼している場合、ゲートウェイは、URIの数を導出するために試みなければならない場合に何数は、メッセージ/ sipfrag体から誘導されていない場合そのヘッダーです。数はこれらのヘッダのいずれかから誘導された場合、ゲートウェイは、スクリーニングインジケータの「ネットワークが提供された」接続先番号情報要素に含め、値を含まなければなりません。
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-値の値「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 SETUPメッセージにおけるベアラ能力情報要素を生成しなければなりません。唯一の「オーディオ」であるSIP SDPオファー情報またはSDPオファー情報におけるメディアタイプを含まないINVITE要求をした場合、その後、伝達能力情報要素は、他のメディアの伝達能力情報要素の表3符号化に応じて発生するものタイプは、本明細書の範囲外です。
In addition, the gateway MAY include a Low layer compatibility information element and/or High layer compatibility information in the QSIG SETUP message if the gateway is able to derive relevant information from the SDP offer information. Specific mappings are outside the scope of this specification.
ゲートウェイは、SDPオファー情報から関連情報を導出することが可能であればまた、ゲートウェイは、QSIG SETUPメッセージに低位レイヤ整合性情報要素及び/又は高レイヤ整合性情報を含むことができます。特定のマッピングはこの仕様の範囲外です。
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 SETUPメッセージ内の情報に基づいてINVITE要求をSIPに含めるSDPオファー情報を生成しなければなりません。特定のマッピングは、本明細書の範囲外である場合にはQSIG SETUPメッセージ、SDPオファー情報を導出する、中に存在する場合、ゲートウェイは、QSIG低位レイヤ整合性及び/又は高レイヤ整合性情報要素のアカウントを取ることができます。そうでない場合、ゲートウェイは、メディアの種類を表4に従って導出することものとする場合にはQSIG SETUPメッセージにおけるベアラ能力情報要素に基づいて、SDPオファー情報を生成しなければなりません。
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]に記載されているように、認証、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.
SIPヘッダにQSIG情報要素の翻訳は、いくつかのプライバシーとセキュリティの懸念を導入することができます。例えば、介護は発番号情報要素が公然とFromヘッダーにマッピングされている場合は、ユーザー要求の表示制限のために十分なプライバシーを提供するために取られる必要があります。この特定の状況に対処するための手順は、9.1.2項で規定されています。本書で指定されたマッピングは、ルートSIPリクエストに使用されるヘッダおよびフィールドに情報要素を変換すると、主に懸念しているので、ゲートウェイは、結果（この翻訳プロセスを通して）情報の最小可能量を明らかにする。
There are some concerns, however, that arise from the other direction of mapping, the mapping of SIP headers to QSIG information elements, which are enumerated in the following paragraphs.
以下の段落で列挙された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のSETUPメッセージに着番号情報要素を取り込みます。同様に、SIP URIまたはTEL URLとゲートウェイでその情報要素のSIPデバイス、マップのエンドユーザによって直接作成することができるSIP INVITE要求のリクエストURIでそのオプションパラメータ、。しかし、PISNに、ポリシーは、特定の（無効または制限）の番号をダイヤルからユーザーを防ぐことができます。したがって、ゲートウェイの実装は、ゲートウェイ管理者は、QSIGにSIPからの呼び出しを許可する場合、特定の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応答コードを持つゲートウェイからINVITE要求に応答することができ、したがって、それらは（ゲートウェイによってサポートされるマッピングの境界内）ゲートウェイによって送信されるQ.850原因コードを決定することができますメッセージをクリアしたQSIGコールインチ一般的に言って、コールが拒否される方法は、（呼び出しが課金、またはネットワークがオフラインの重要なリソースを取る必要があることをすべきではないことを知らせることで、例えば）サービスの詐欺または拒否するためにあらゆる手段を提供することはほとんどありません。しかし、ゲートウェイの実装は、ゲートウェイの管理者は、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.
この仕様は、Request-URIはなく、QSIG SETUPメッセージで呼び出されたパーティ番号情報要素にINVITE要求をSIPのヘッダをマップするためにゲートウェイを必要とします。 SIP UAは、ヘッダーとRequest-URI中に同じURIを置くことが予想されるが、これは他のSIPエンティティによってポリシングされていません。したがって、リクエストURIはゲートウェイで受信異なる点URIヘッダには、コールがSIPネットワークまたは元の標的の信頼できる指標として再標的化されたことを信頼できる指標として使用することができません。 （QSIGコール迂回シグナリングの一部として、例えば、）QSIG要素にマッピングするためのToヘッダを利用してゲートウェイの実装は、当該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ユーザエージェントによる要求のヘッダからの任意の集団は、発信者の身元の正確な表現として、Fromヘッダに依存しているデバイスのためのいくつかのよく理解セキュリティ意味を有します。要求の発信元を認証し、番号を呼び出す（またはすることは、いくつかを利用することを主張することが許可されていることを確認する必要がありQSIG SETUPメッセージの発番号情報要素を取り込むために、ヘッダから符号なしまたは未検証を使用しようとする任意のゲートウェイ呼び出し側の身元を確認するために、より安全な方法）。 [10]に記載されているように、他のすべてのSIPユーザーエージェントのようなゲートウェイは、ダイジェスト認証をサポートしなければならないことに留意されたいです。同様の考察が、すなわち、この情報のソースが認証されなければならない、相手番号や接続先番号情報要素を呼び出しQSIGにマッピングするためのSIP P-Asserted-Identityヘッダの使用に適用されます。パーティの数や接続先番号情報要素を呼び出しQSIGを導出するために署名されたメッセージ/ sipfragボディの使用は別の安全な代替手段です。
There is another class of potential risk that is related to the cut-through of the backwards media path before the call is answered. Several practices described in this document involve the connection of media streams to user information channels on inter-PINX links and the sending of progress description number 1 or 8 in a backward QSIG message. This can result in media being cut through end-to-end, and it is possible for the called user agent then to play arbitrary audio to the caller for an indefinite period of time before transmitting a final response (in the form of a 2xx or higher response code) to an INVITE request. This is useful since it also permits network entities (particularly legacy networks that are incapable of transmitting Q.850 cause values) to play tones and announcements to indicate call failure or call progress, without triggering charging by transmitting a 2xx response. Also, early cut-through can help prevent clipping of the initial media when the call is answered. There are conceivable respects in which this capability could be used fraudulently by the called user agent for transmitting arbitrary information without answering the call or before answering the call. However, in corporate networks, charging is often not an issue, and for calls arriving at a corporate network from a carrier network, the carrier network normally takes steps to prevent fraud.
コールが応答される前に、逆方向メディアパスのカットスルーに関連している潜在的なリスクの別のクラスがあります。この文書に記載され、いくつかの実践は、インターPINXリンクおよび逆方向QSIGメッセージの進捗説明番号1又は8の送信に関するユーザ情報チャネルのメディアストリームの接続を含みます。このメディアをもたらすことができる、エンドツーエンドを介して切断され、そして呼び出されるユーザエージェントは、その後の2xx又はの形態で（最終的な応答を送信する前に無期限に発呼者に任意のオーディオを再生することが可能ですINVITEリクエストに高いレスポンスコード）。それはまた、2xx応答を送信することにより、充電トリガすることなく、通話障害を示すか、進捗状況を呼び出すためにトーンとアナウンスを再生するためのネットワーク・エンティティ（Q.850原因値を送信することができない、特にレガシーネットワーク）を許可するので、これは便利です。また、早期カットスルーは、コールが応答されたときに、最初のメディアのクリッピングを防ぐことができます。この機能は、呼び出しに応答することなく、またはコールに応答する前に任意の情報を送信するために呼び出されるユーザエージェントによって不正に使用することができたに考えられる点があります。しかし、企業ネットワークでは、充電がしばしば問題ではなく、キャリアネットワークから企業ネットワークに到着コールのために、キャリアネットワークは、通常、不正を防止するための手順を実行します。
The usefulness of this capability appears to outweigh any risks involved, which may in practice be no greater than in existing PISN/ISDN environments. However, gateway implementers may wish to make provision for gateway administrators to turn off cut-through or minimise its impact (e.g., by imposing a time limit) when deployed in situations where problems can arise.
この機能の有用性は、実際には、既存のPISN / ISDN環境におけるよりも大きくないかもしれ関わるあらゆるリスクを上回ると表示されます。しかし、ゲートウェイの実装は、問題が発生する可能性がある状況で展開されたとき（時間制限を課すことにより、例えば）ゲートウェイ管理者は、カットスルーをオフにするまたはその影響を最小限にするための準備を行うことを望むかもしれません。
Unlike a traditional PISN phone, a SIP user agent can launch multiple simultaneous requests in order to reach a particular resource. It would be trivial for a SIP user agent to launch 100 SIP INVITE requests at a 100 port gateway, thereby tying up all of its ports. A malicious user could choose to launch requests to telephone numbers that are known never to answer, or, where overlap signalling is used, 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ユーザエージェントは、SIP 100は、100ポートゲートウェイにINVITE要求を起動し、それによって、そのポートのすべてを占有することは自明であろう。悪意のあるユーザーは、オーバーラップシグナリングが不完全なアドレスに、使用されている電話答える決して知られている番号、または、への要求を起動することを選択することができます。これは、潜在的に任意の電荷を発生させることなく、無期限ゲートウェイでのリソースを飽和ことができます。ゲートウェイの実装は、したがって、ポリシーに従ってこの可能DoS攻撃に対処するために、同じ認証ソース、又は同様のメカニズムに由来する同時要求の数を制限する手段を提供することを望むかもしれません。
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.
著者はフランソワAudet、アダムローチ、ジャン=フランソワ・レイ、トーマスStachの支援を認めることを望む、と準備し、この文書にコメントであるEcma TC32-TG17のメンバー。
[1] International Standard ISO/IEC 11571 "Private Integrated Services Networks (PISN) - Addressing" (also published by Ecma as Standard ECMA-155).
[1]国際標準ISO / IEC 11571 "私設総合サービス網（PISN） - アドレス指定"（も標準ECMA-155としてEcmaの発行）。
[2] International Standard ISO/IEC 11572 "Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (also published by Ecma as Standard ECMA-143).
[2]国際標準ISO / IEC 11572「私設総合サービス網 - 回線モードベアラサービス - インター交換シグナリング手順およびプロトコル」（も標準ECMA-143としてEcmaの発行）。
[3] International Standard ISO/IEC 11582 "Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol" (also published by Ecma as Standard ECMA-165).
[3]国際規格ISO / IEC 11582「私設総合サービス網 - 付加サービス実現のための汎用機能プロトコル - インター交換シグナリング手順およびプロトコル」（も標準ECMA-165としてEcmaの発行）。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[6]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[7]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[9]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
、RFC 3262、2002年6月[11]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[12]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[13] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[13]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼されたネットワーク内でアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[15]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[16]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[17] ITU-T Recommendation E.164, "The International Public Telecommunication Numbering Plan", (1997-05).
[17] ITU-T勧告E.164、 "国際公衆通信番号計画"（1997年から1905年）。
[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]キャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オング、 "セッション開始プロトコル（SIP）へのシグナリング重複統合サービスデジタル網（ISDN）ユーザ部（ISUP）のマッピング"、 RFC 3578、2003年8月。
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[19]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[20] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[20]スパークス、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月。
Appendix A. Example Message Sequences
付録A.例のメッセージシーケンス
A.1. Introduction
A.1。前書き
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.
注：これらの例では、（100を除く）SIP暫定応答を肯定応答するためのPRACKメソッドを使用して、確実に送信されるように示されています。
A.2. Message Sequences for Call Establishment from QSIG to SIP
A.2。 QSIGからSIPへのコールの確立のためのメッセージシーケンス
Below are typical message sequences for successful call establishment from QSIG to SIP
以下は、QSIGからSIPに成功した呼確立のための典型的なメッセージ配列であります
A.2.1. QSIG to SIP, using en bloc procedures on both QSIG and SIP
A.2.1。 SIPにQSIG、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：SIPへQSIGから成功した呼確立のための典型的なメッセージシーケンス、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は、SIP UAとのセッションを開始するためにゲートウェイにQSIG SETUPメッセージを送信します。図2は、QSIG SETUPメッセージを受信すると、ゲートウェイは、SIP INVITE要求を生成し、着信番号に基づいて、IPネットワーク内の適切なSIPエンティティに送信します。 3ゲートウェイがPISNにQSIG呼進行メッセージを送信します。 QSIG INFORMATIONメッセージこれ以上は受け付けられません。 4 IPネットワークは、ゲートウェイにSIP 100（試行）応答を送信します。 5 IPネットワークは、SIP 180（リンギング）応答を送信します。
6 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 7 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request 8 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PISN. 9 The IP network sends a SIP 200 (OK) response when the call is answered. 10 The gateway sends a SIP ACK request to acknowledge the SIP 200 (OK) response. 11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message and sends it to the PISN. 12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message.
6ゲートウェイは、ヘッダーまたは初期SIP INVITE要求のオプションタグ100relでサポートヘッダが必要の包含に基づいて、IPネットワークにSIP PRACK要求を送り返すことができます。 7 IPネットワークは、SIP PRACK要求8を確認するためにゲートウェイにSIP 200（OK）応答を送信するゲートウェイがQSIG ALERTINGメッセージにこのSIP 180（リンギング）応答をマッピングし、PISNに送ります。コールが応答されたときに9 IPネットワークは、SIP 200（OK）応答を送信します。 10ゲートウェイは、SIP 200（OK）応答を確認するためにSIP ACKリクエストを送信します。 11ゲートウェイは、QSIG CONNECTメッセージにこのSIP 200（OK）応答をマッピングし、PISNに送ります。 12 PISNはQSIG CONNECTは、QSIG CONNECTメッセージに応答してメッセージをACKNOWLEDGE送信します。
A.2.2. QSIG to SIP, using overlap receiving on QSIG and en bloc sending on SIP
A.2.2。 SIPにQSIG、QSIG上およびSIPに送信一括受信オーバーラップを使用して
+------------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +--------+-------+-------+ |
1|-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2|<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3|-------------------------->| | |
| | | |
| QSIG INFORMATION | | 1-INVITE |
3a|-------------------------->|.......|----------------------->|4
| QSIG CALL PROCEEDING | | 1-100 TRYING |
5|<--------------------------| |<-----------------------|6
| | | |
| QSIG ALERTING | | 1-180 RINGING |
10|<--------------------------|.......|<-----------------------|7
| | | 2-PRACK |
| | |----------------------->|8
| | | 2-200 OK |
| | |<-----------------------|9
| QSIG CONNECT | | 1-200 OK |
13|<--------------------------|.......|<-----------------------|11
| | | |
| QSIG CONNECT ACK | | 1-ACK |
14|-------------------------->| |----------------------->|12
| AUDIO | | AUDIO |
|<=========================>| |<======================>|
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：SIPへQSIGから成功した呼確立のための典型的なメッセージシーケンス、オーバーラップを使用してSIPに送信QSIGに及び一括受信
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は、SIP UAとのセッションを開始するためにゲートウェイにQSIG SETUPメッセージを送信します。 QSIG SETUPメッセージを送信する完全な情報要素が含まれていません。 2ゲートウェイは、QSIG設定がPISNにACKNOWLEDGEメッセージを送信します。より多くの桁が期待されています。 3つの以上の数字はQSIG INFORMATIONメッセージ内PISNから送信されます。図3（a）複数の数字は、QSIG INFORMATIONメッセージ内PISNから送信されます。 QSIG INFORMATIONメッセージが送信完全な情報要素が含まれています。
4 The Gateway generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network, based on the called number. 5 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more QSIG INFORMATION messages will be accepted. 6 The IP network sends a SIP 100 (Trying) response to the gateway. 7 The IP network sends a SIP 180 (Ringing) response. 8 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 9 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request. 10 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PINX. 11 The IP network sends a SIP 200 (OK) response when the call is answered. 12 The gateway sends an SIP ACK request to acknowledge the SIP 200 (OK) response. 13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message and sends it to the PINX. 14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message.
4ゲートウェイは、SIP INVITE要求を生成し、着信番号に基づいて、IPネットワーク内の適切なSIPエンティティに送信します。 5ゲートウェイがPISNにQSIG呼進行メッセージを送信します。 QSIG INFORMATIONメッセージこれ以上は受け付けられません。 6 IPネットワークは、ゲートウェイにSIP 100（試行）応答を送信します。 7 IPネットワークは、SIP 180（リンギング）応答を送信します。 8ゲートウェイは、ヘッダーまたは初期SIP INVITE要求のオプションタグ100relでサポートヘッダが必要の包含に基づいて、IPネットワークにSIP PRACK要求を送り返すことができます。 9 IPネットワークは、SIP PRACK要求の受信を確認するためにゲートウェイにSIP 200（OK）応答を送信します。 10ゲートウェイは、QSIG ALERTINGメッセージにこのSIP 180（リンギング）応答をマッピングし、PINXに送ります。コールが応答されたときに11 IPネットワークは、SIP 200（OK）応答を送信します。 12ゲートウェイは、SIP 200（OK）応答を確認するためにSIP ACKリクエストを送信します。 13ゲートウェイは、QSIG CONNECTメッセージにこのSIP 200（OK）応答をマッピングし、PINXに送ります。 14 PISNはQSIG CONNECTは、QSIG CONNECTメッセージに応答してメッセージをACKNOWLEDGE送信します。
A.2.3. QSIG to SIP, using overlap procedures on both QSIG and SIP
A.2.3。 SIPにQSIG、QSIGとSIPの両方に重複手順を用いて
+----------------------+
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：SIPへQSIGから成功した呼確立のための典型的なメッセージシーケンス、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は、SIP UAとのセッションを開始するためにゲートウェイにQSIG SETUPメッセージを送信します。 QSIG SETUPメッセージを送信する完全な情報要素が含まれていません。 2ゲートウェイは、QSIG設定がPISNにACKNOWLEDGEメッセージを送信します。より多くの桁が期待されています。 3つの以上の数字はQSIG INFORMATIONメッセージ内PISNから送信されます。 4ゲートウェイはコールをルーティングするために必要な最小桁数を受信すると、SIP INVITE要求を生成し、これにより桁数が不足、IPと呼ばれる数5に基づいて、IPネットワーク内の適切なSIPエンティティに送信しますネットワークは、SIP 484（不完全なアドレス）応答を返します。 6 SIP 484（不完全なアドレス）応答が認められています。 7桁以上は、QSIG INFORMATIONメッセージにPISNから受信されます。新しいINVITEは、同じCall-IDと値からではなく、更新のRequest-URIに送信されます。 8桁以上は、QSIG INFORMATIONメッセージにPISNから受信されます。 QSIG INFORMATIONメッセージが送信完全な情報要素が含まれています。 9ゲートウェイがPISNにQSIG呼進行メッセージを送信します。これ以上の情報は受け付けられません。 10ゲートウェイは、新しいSIP更新リクエストURIフィールドを持つINVITEリクエストを送信します。 11 IPネットワークは、ゲートウェイにSIP 100（試行）応答を送信します。 12 IPネットワークは、SIP 180（リンギング）応答を送信します。 13ゲートウェイは、要求ヘッダの包含または初期SIPのオプションタグ100relでサポートヘッダINVITE要求に基づいて、IPネットワークにSIP PRACK要求を送り返すことができます。 14 IPネットワークは、SIP PRACK要求の受信を確認するためにゲートウェイにSIP 200（OK）応答を送信します。 15ゲートウェイは、QSIG ALERTINGメッセージにこのSIP 180（リンギング）応答をマッピングし、PISNに送ります。コールが応答されたときに16 IPネットワークは、SIP 200（OK）応答を送信します。 17ゲートウェイは、SIP 200（OK）応答を確認するためにSIP ACKリクエストを送信します。 18ゲートウェイは、QSIG CONNECTメッセージにこのSIP 200（OK）応答をマッピングします。 19 PISNはQSIG CONNECTは、QSIG CONNECTメッセージに応答してメッセージをACKNOWLEDGE送信します。
A.3. Message sequences for call establishment from SIP to QSIG
A.3。 QSIGへのSIPから呼確立のためのメッセージシーケンス
Below are typical message sequences for successful call establishment from SIP to QSIG
以下は、SIPからQSIGに成功した呼確立のための典型的なメッセージ配列であります
A.3.1. SIP to QSIG, using en bloc procedures
A.3.1。一括手続きエン使用して、QSIGにSIP
+----------------------+
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：QSIGへSIPから成功した呼設定のための典型的なメッセージシーケンス、ブロック手順エン使用
1 The IP network sends a SIP INVITE request to the gateway. 2 The gateway sends a SIP 100 (Trying) response to the IP network. 3 On receipt of the SIP INVITE request, the gateway sends a QSIG SETUP message. 4 The PISN sends a QSIG CALL PROCEEDING message to the gateway. 5 A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted. 6 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response.
1 IPネットワークはSIPゲートウェイにINVITE要求を送ります。 2ゲートウェイは、IPネットワークへのSIP 100（試行）応答を送信します。 SIPを受信する3は、INVITE要求を、ゲートウェイはQSIG SETUPメッセージを送信します。 4 PISNはゲートウェイにQSIGコールPROCEEDINGメッセージを送信します。 5 A QSIG ALERTINGメッセージはPISNにエンドユーザが警告されていることを示すために戻されます。 6ゲートウェイは、SIP 180（リンギング）応答にメッセージを警告QSIGをマッピングします。
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でサポートヘッダが必要の包含に基づいて、IPネットワークにSIP PRACK要求を送り返すことができます。 8ゲートウェイは、SIP PRACK要求の受信を確認するためにSIP 200（OK）応答を送信します。 9 PISNは、呼が応答されるゲートウェイにQSIG CONNECTメッセージを送信します。 10ゲートウェイは、QSIG CONNECTは、QSIG CONNECTメッセージを確認するメッセージをACKNOWLEDGE送信します。 11 QSIG CONNECTメッセージは、SIP 200（OK）応答にマッピングされます。 12 IP網、SIPは、最終応答（200）をINVITE受信すると、受信を確認するためにSIP ACKリクエストを送信します。
A.3.2. SIP to QSIG, using overlap receiving on SIP and en bloc sending on QSIG
A.3.2。 QSIGに送信SIPに及び一括受信オーバーラップを使用して、QSIGにSIP
+----------------------+
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：QSIGへSIPから成功した呼設定のための典型的なメッセージシーケンス、SIP上およびQSIGに送信一括受信オーバーラップを使用して
1 The IP network sends a SIP INVITE request to the gateway. 2 Due to an insufficient number of digits, the gateway returns a SIP 484 (Address Incomplete) response. 3 The IP network acknowledges the SIP 484 (Address Incomplete) response.
1 IPネットワークはSIPゲートウェイにINVITE要求を送ります。 2により桁の不十分な数に、ゲートウェイは、SIP 484（アドレス不完全）応答を返します。 3 IPネットワークは、SIP 484（不完全なアドレス）応答を認めています。
4 The IP network sends a new SIP INVITE request with the same Call-ID and updated Request-URI. 5 The gateway now has all the digits required to route the call to the PISN. The gateway sends back a SIP 100 (Trying) response. 6 The gateway sends a QSIG SETUP message. 7 The PISN sends a QSIG CALL PROCEEDING message to the gateway. 8 A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted. 9 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response. 10 The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 11 The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request. 12 The PISN sends a QSIG CONNECT message to the gateway when the call is answered. 13 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the CONNECT message. 14 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 15 The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
4 IPネットワークは、新しいSIPが同じCall-IDおよび更新のRequest-URIを持つINVITEリクエストを送信します。 5ゲートウェイは、現在PISNへの呼び出しの経路に必要とされるすべての数字があります。ゲートウェイは、SIP 100（試行）応答を返送します。 6ゲートウェイは、QSIG SETUPメッセージを送信します。 7 PISNはゲートウェイにQSIGコールPROCEEDINGメッセージを送信します。 8 A QSIG ALERTINGメッセージはPISNにエンドユーザが警告されていることを示すために戻されます。 9ゲートウェイは、SIP 180（リンギング）応答にメッセージを警告QSIGをマッピングします。 10 IPネットワークは要求ヘッダの包含または初期SIP INVITEリクエストのオプションタグ100relでサポートヘッダに基づいて、IPネットワークにSIP PRACK要求を送り返すことができます。 11ゲートウェイは、SIP PRACK要求の受信を確認するためにSIP 200（OK）応答を送信します。 12 PISNは、呼が応答されるゲートウェイにQSIG CONNECTメッセージを送信します。 13ゲートウェイは、QSIG CONNECTはCONNECTメッセージを確認するメッセージをACKNOWLEDGE送信します。 14 QSIG CONNECTメッセージは、SIP 200（OK）応答にマッピングされます。 15 IP網、SIPは、最終応答（200）をINVITE受信すると、受信を確認するためにSIP ACKリクエストを送信します。
A.3.3. SIP to QSIG, using overlap procedures on both SIP and QSIG
A.3.3。 SIPおよびQSIGの両方に重複手順を使用して、QSIGにSIP
+----------------------+
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：QSIGへSIPから成功した呼設定のための典型的なメッセージシーケンス、SIPおよびQSIGの両方に重複手順を用いて
1 The IP network sends a SIP INVITE request to the gateway. 2 Due to an insufficient number of digits, the gateway returns a SIP 484 (Address Incomplete) response. 3 The IP network acknowledges the SIP 484 (Address Incomplete) response.
1 IPネットワークはSIPゲートウェイにINVITE要求を送ります。 2により桁の不十分な数に、ゲートウェイは、SIP 484（アドレス不完全）応答を返します。 3 IPネットワークは、SIP 484（不完全なアドレス）応答を認めています。
4 The IP network sends a new SIP INVITE request with the same Call-ID and updated Request-URI. 5 The gateway now has all the digits required to route the call to the PISN. The gateway sends back a SIP 100 (Trying) response to the IP network. 6 The gateway sends a QSIG SETUP message. 7 The PISN needs more digits to route the call and sends a QSIG SETUP ACKNOWLEDGE message to the gateway. 8 The IP network sends a new SIP INVITE request with the same Call-ID and From values and updated Request-URI. 9 The gateway sends back a SIP 100 (Trying) response to the IP network. 10 The gateway maps the new SIP INVITE request to a QSIG INFORMATION message. 11 The PISN has all the digits required and sends back a QSIG CALL PROCEEDING message to the gateway. 12 A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted. 13 The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response. 14 The gateway sends a SIP 484 (Address Incomplete) response for the previous SIP INVITE request. 15 The IP network acknowledges the SIP 484 (Address Incomplete) response. 16 The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request. 17 The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request. 18 The PISN sends a QSIG CONNECT message to the gateway when the call is answered. 19 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the QSIG CONNECT message. 20 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 21 The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
4 IPネットワークは、新しいSIPが同じCall-IDおよび更新のRequest-URIを持つINVITEリクエストを送信します。 5ゲートウェイは、現在PISNへの呼び出しの経路に必要とされるすべての数字があります。ゲートウェイは、IPネットワークへのSIP 100（試行）応答を返送します。 6ゲートウェイは、QSIG SETUPメッセージを送信します。 7 PISNルートに呼を複数の桁を必要とQSIG設定がゲートウェイにメッセージをACKNOWLEDGE送信します。 8 IPネットワークは、新しいSIPが同じCall-IDとし、値、および更新のRequest-URIからのINVITEリクエストを送信します。 9ゲートウェイは、IPネットワークへのSIP 100（試行）応答を返送します。 10ゲートウェイは、新しいSIPは、QSIG情報メッセージにINVITE要求をマッピングします。 11 PISNは、必要なすべての数字を有し、ゲートウェイにQSIG呼進行メッセージを返送します。 12 A QSIG ALERTINGメッセージはPISNにエンドユーザが警告されていることを示すために戻されます。 13ゲートウェイは、SIP 180（リンギング）応答にQSIG警報メッセージをマッピングします。 14ゲートウェイは、前のSIP INVITE要求をするためのSIP 484（アドレス不完全）応答を送信します。 15 IPネットワークは、SIP 484（不完全なアドレス）応答を認めています。 16 IPネットワークは要求ヘッダの包含または初期SIP INVITEリクエストのオプションタグ100relでサポートヘッダに基づいて、IPネットワークにSIP PRACK要求を送り返すことができます。 17ゲートウェイは、SIP PRACK要求の受信を確認するためにSIP 200（OK）応答を送信します。 18 PISNは、呼が応答されるゲートウェイにQSIG CONNECTメッセージを送信します。 19ゲートウェイは、QSIG CONNECTは、QSIG CONNECTメッセージを確認するメッセージをACKNOWLEDGE送信します。 20 QSIG CONNECTメッセージは、SIP 200（OK）応答にマッピングされます。 21 IP網、SIPは、最終応答（200）をINVITE受信すると、受信を確認するためにSIP ACKリクエストを送信します。
A.4. Message Sequence for Call Clearing from QSIG to SIP
A.4。 QSIGからSIPへのコールクリアのメッセージシーケンス
Below are typical message sequences for Call Clearing from QSIG to SIP
以下は、QSIGからSIPへのコールのクリアのための典型的なメッセージ配列であります
A.4.1. QSIG to SIP, subsequent to call establishment
A.4.1。設立を呼び出すために、後続のSIPへのQSIG、
+-------------------+
| |
| 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のDISCONNECTメッセージを送信します。 2ゲートウェイは、QSIGのDISCONNECTメッセージに応答してPISNにQSIG RELEASEメッセージを返送します。 3 PISNに応答してQSIG RELEASE COMPLETEメッセージを送信します。すべてのPISNのリソースは、現在リリースされています。 4ゲートウェイは、SIP BYE要求にQSIGのDISCONNECTメッセージをマッピングします。 5 IPネットワークは、SIP BYE要求へのSIP 200（OK）レスポンスを返信します。すべてのIPリソースは、現在リリースされています。
A.4.2. QSIG to SIP, during establishment of a call from SIP to QSIG
A.4.2。 QSIGへのSIPからの呼の確立中にSIPにQSIG、
+-------------------+
| |
| 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：QSIGへSIPの呼の確立時に、SIPするQSIGからクリアコールのための典型的なメッセージシーケンス（ゲートウェイは、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はゲートウェイ2にQSIGのDISCONNECTメッセージを送信するゲートウェイがPISNに応答してQSIG RELEASE COMPLETEメッセージを送信するQSIGのDISCONNECTメッセージ3に応答しPISNにQSIG RELEASEメッセージを返送します。すべてのPISNのリソースは、現在リリースされています。 4ゲートウェイは、IPネットワークは、SIP 4XX-の6xxレスポンスに応答してSIP ACKリクエストを返信するSIP 4XX-の6xxレスポンス5にQSIGのDISCONNECTメッセージをマッピングします。すべてのIPリソースは、現在リリースされています
A.4.3. QSIG to SIP, during establishment of a call from QSIG to SIP
A.4.3。 SIPへのQSIGから呼の確立中にSIPにQSIG、
+-------------------+
| |
| 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：呼び出しはSIPにQSIGからの呼の確立中に、SIPにQSIGからクリアするための典型的なメッセージシーケンス（ゲートウェイは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のDISCONNECTメッセージを送信します。 2ゲートウェイは、QSIGのDISCONNECTメッセージに応答してPISNにQSIG RELEASEメッセージを返送します。 3 PISNに応答してQSIG RELEASE COMPLETEメッセージを送信します。すべてのPISNのリソースは、現在リリースされています。 4ゲートウェイは、要求（暫定応答の受信にではなく、最終的な応答の被験体）をキャンセルSIPにQSIGのDISCONNECTメッセージをマッピングします。 5 IPネットワークは、SIP INVITE要求へのSIP 487（リクエスト終端）応答を返送します。 6ゲートウェイは、SIP INVITE要求をSIP最終応答（487）を受信すると、受信を確認するためにSIP ACKリクエストを返信します。 7 IPネットワークは、要求をSIP CANCELにSIP 200（OK）レスポンスを返信します。すべてのIPリソースは、現在リリースされています。
A.5. Message Sequence for Call Clearing from SIP to QSIG
A.5。 SIPからQSIGへのコールクリアのメッセージシーケンス
Below are typical message sequences for Call Clearing from SIP to QSIG
以下は、SIPからQSIGへのコールのクリアのための典型的なメッセージ配列であります
A.5.1. SIP to QSIG, subsequent to call establishment
A.5.1。設立を呼び出すことが、その後の、QSIGにSIP
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 2- BYE | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 2-200 OK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
Figure 12: Typical message sequence for call clearing from SIP to QSIG, subsequent to call establishment
図12：SIPからQSIGに呼クリアのための典型的なメッセージシーケンス、確立を呼び出す後続
1 The IP network sends a SIP BYE request to the gateway. 2 The gateway sends back a SIP 200 (OK) response to the SIP BYE request. All IP resources are now released. 3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message. 4 The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
1 IPネットワークはゲートウェイにSIP BYE要求を送信します。 2ゲートウェイは、SIP BYE要求へのSIP 200（OK）レスポンスを返信します。すべてのIPリソースは、現在リリースされています。 3ゲートウェイは、QSIGのDISCONNECTメッセージにSIP BYE要求をマッピングします。 4 PISNは、QSIGのDISCONNECTメッセージに応答して、ゲートウェイにQSIG RELEASEメッセージを返送します。 5ゲートウェイが応答してQSIG RELEASE COMPLETEメッセージを送信します。すべてのPISNのリソースは、現在リリースされています。
A.5.2. SIP to QSIG, during establishment of a call from QSIG to SIP
A.5.2。 SIPへのQSIGから呼の確立中に、QSIGにSIP
+-------------------+
| |
| 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：SIPからQSIGに呼クリアのための典型的なメッセージシーケンス、SIPへQSIGから呼の確立時（ゲートウェイが以前にSIPへの最終的な応答を受信しなかったINVITE要求）
1 The IP network sends a SIP 4xx-6xx response to the gateway. 2 The gateway sends back a SIP ACK request in response to the SIP 4xx-6xx response. All IP resources are now released. 3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT message. 4 The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 5 The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
1 IPネットワークはゲートウェイへのSIP 4XX-の6xxレスポンスを送信します。 2ゲートウェイは、SIP 4XX-の6xxレスポンスに応答してSIP ACKリクエストを返信します。すべてのIPリソースは、現在リリースされています。 3ゲートウェイは、QSIGのDISCONNECTメッセージにSIP 4XX-の6xx応答をマッピングします。 4 PISNは、QSIGのDISCONNECTメッセージに応答して、ゲートウェイにQSIG RELEASEメッセージを返送します。 5ゲートウェイが応答してQSIG RELEASE COMPLETEメッセージを送信します。すべてのPISNのリソースは、現在リリースされています。
A.5.3. SIP to QSIG, during establishment of a call from SIP to QSIG
A.5.3。 QSIGへのSIPからの呼の確立中に、QSIGにSIP
+-------------------+
| |
| 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：QSIGにSIPからの呼の確立中に、SIPからQSIGにクリアコールのための典型的なメッセージシーケンス（ゲートウェイはSIPに暫定的な応答は、INVITEリクエストを送信されなくていない最終的な応答）
1 The IP network sends a SIP CANCEL request to the gateway. 2 The gateway sends back a SIP 487 (Request Terminated) response to the SIP INVITE request. 3 The IP network, on receiving a SIP final response (487) to the SIP INVITE request, sends back a SIP ACK request to acknowledge receipt. 4 The gateway sends back a SIP 200 (OK) response to the SIP CANCEL request. All IP resources are now released. 5 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT message. 6 The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 7 The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
1 IPネットワークはSIPゲートウェイに要求をキャンセル送ります。 2ゲートウェイは、SIP INVITE要求へのSIP 487（リクエスト終端）応答を返送します。 3 IPネットワークは、SIP INVITE要求をSIP最終応答（487）を受信すると、受信を確認するためにSIP ACKリクエストを返信します。 4ゲートウェイは、要求をSIP CANCELにSIP 200（OK）レスポンスを返信します。すべてのIPリソースは、現在リリースされています。 5ゲートウェイは、QSIGのDISCONNECTメッセージにSIP 4XX-の6xx応答をマッピングします。 6 PISNは、QSIGのDISCONNECTメッセージに応答して、ゲートウェイにQSIG RELEASEメッセージを返送します。 7ゲートウェイが応答してQSIG RELEASE COMPLETEメッセージを送信します。すべてのPISNのリソースは、現在リリースされています。
Authors' Addresses
著者のアドレス
John Elwell Siemens plc Technology Drive Beeston Nottingham, UK, NG9 1LA
ジョンエルウェルシーメンスのPLC技術ドライブビーストンノッティンガム、イギリス、NG9 1LA
EMail: john.elwell@siemens.com
メールアドレス：john.elwell@siemens.com
Frank Derks NEC Philips Unified Solutions Anton Philipsweg 1 1223 KZ Hilversum The Netherlands
フランクDerks NECフィリップスユニファイドソリューションズアントンPhilipsweg 1 1223 KZヒルフェルスムザ・ネザーランズ
EMail: frank.derks@nec-philips.com
メールアドレス：frank.derks@nec-philips.com
Olivier Rousseau Alcatel Business Systems 32,Avenue Kleber 92700 Colombes France
オリヴィエ・ルソーアルカテルビジネスシステム32アベニュークレベール92700コロンブフランス
EMail: Olivier.Rousseau@alcatel.fr
メールアドレス：Olivier.Rousseau@alcatel.fr
Patrick Mourot Alcatel Business Systems 1,Rue Dr A. Schweitzer 67400 Illkirch France
パトリックMourotアルカテルビジネスシステム1、ルー博士A.シュバイツァー67400イルキルシュフランス
EMail: Patrick.Mourot@alcatel.fr
メールアドレス：Patrick.Mourot@alcatel.fr
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。