[要約] 要約：RFC 3398は、ISDNユーザーパート（ISUP）とセッションイニシエーションプロトコル（SIP）のマッピングに関する技術仕様です。 目的：このRFCの目的は、ISUPとSIPの間の相互運用性を確保し、ISDNネットワークとIPベースのネットワークの接続を容易にすることです。
Network Working Group G. Camarillo
Request for Comments: 3398 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
December 2002
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
統合サービスデジタルネットワーク（ISDN）ユーザーパート（ISUP）からセッション開始プロトコル（SIP）へのマッピング
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
このドキュメントでは、2つのシグナリングプロトコル間のマッピングを実行する方法について説明します。SessionInitiation Protocol（SIP）とSignaling System No. 7（SS7）のIntegrated Services Digital Network（ISDN）User Part（ISUP）です。このメカニズムは、コールの一部に公衆交換電話網（PSTN）とのインターワーキングが含まれる環境でSIPを使用するときに実装される場合があります。
Table of Contents
目次
1. Introduction............................................ 3
2. Scope................................................... 4
3. Terminology............................................. 5
4. Scenarios............................................... 5
5. SIP Mechanisms Required................................. 7
5.1 'Transparent' Transit of ISUP Messages.................. 7
5.2 Understanding MIME Multipart Bodies..................... 7
5.3 Transmission of DTMF Information........................ 8
5.4 Reliable Transmission of Provisional Responses.......... 8
5.5 Early Media............................................. 8
5.6 Mid-Call Transactions which do not change SIP state..... 9
5.7 Privacy Protection...................................... 9
5.8 CANCEL causes........................................... 10
6. Mapping................................................. 10
7. SIP to ISUP Mapping..................................... 11
7.1 SIP to ISUP Call flows.................................. 11
7.1.1 En-bloc Call Setup (no auto-answer)..................... 11
7.1.2 Auto-answer call setup.................................. 12
7.1.3 ISUP T7 Expires......................................... 13
7.1.4 SIP Timeout............................................. 14
7.1.5 ISUP Setup Failure...................................... 15
7.1.6 Cause Present in ACM Message............................ 16
7.1.7 Call Canceled by SIP.................................... 17
7.2 State Machine........................................... 18
7.2.1 INVITE received......................................... 19
7.2.1.1 INVITE to IAM procedures................................ 19
7.2.2 ISUP T7 expires......................................... 23
7.2.3 CANCEL or BYE received.................................. 23
7.2.4 REL received............................................ 24
7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24
7.2.5 Early ACM received...................................... 27
7.2.6 ACM received............................................ 27
7.2.7 CON or ANM Received..................................... 28
7.2.8 Timer T9 Expires........................................ 29
7.2.9 CPG Received............................................ 29
7.3 ACK received............................................ 30
8. ISUP to SIP Mapping..................................... 30
8.1 ISUP to SIP Call Flows.................................. 30
8.1.1 En-bloc call setup (non auto-answer).................... 31
8.1.2 Auto-answer call setup.................................. 32
8.1.3 SIP Timeout............................................. 33
8.1.4 ISUP T9 Expires......................................... 34
8.1.5 SIP Error Response...................................... 35
8.1.6 SIP Redirection......................................... 36
8.1.7 Call Canceled by ISUP................................... 37
8.2 State Machine........................................... 39
8.2.1 Initial Address Message received........................ 39
8.2.1.1 IAM to INVITE procedures................................ 40
8.2.2 100 received............................................ 41
8.2.3 18x received............................................ 41
8.2.4 2xx received............................................ 43
8.2.5 3xx Received............................................ 44
8.2.6 4xx-6xx Received........................................ 44
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45
8.2.7 REL Received............................................ 47
8.2.8 ISUP T11 Expires........................................ 47
9. Suspend/Resume and Hold................................. 48
9.1 SUS and RES............................................. 48
9.2 Hold (re-INVITE)........................................ 50
10. Normal Release of the Connection........................ 50
10.1 SIP initiated release................................... 50
10.2 ISUP initiated release.................................. 51
10.2.1 Caller hangs up......................................... 51
10.2.2 Callee hangs up (SUS)................................... 52
11. ISUP Maintenance Messages............................... 52
11.1 Reset messages.......................................... 52
11.2 Blocking messages....................................... 53
11.3 Continuity Checks....................................... 53
12. Construction of Telephony URIs.......................... 54
12.1 ISUP format to tel URL mapping.......................... 56
12.2 tel URL to ISUP format mapping.......................... 57
13. Other ISUP flavors...................................... 58
13.1 Guidelines for sending other ISUP messages.............. 58
14. Acronyms................................................ 60
15. Security Considerations................................. 60
16. IANA Considerations..................................... 64
17. Acknowledgments......................................... 64
18. Normative References.................................... 64
19. Non-Normative References................................ 65
Authors' Addresses...................................... 67
Full Copyright Statement................................ 68
SIP [1] is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over IP. Telephone calls are considered a type of multimedia sessions where just audio is exchanged.
SIP [1]は、マルチメディアセッションを確立、終了、変更するためのアプリケーション層プロトコルです。通常、IPで伝送されます。電話は、音声だけが交換される一種のマルチメディアセッションと見なされます。
Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a level 4 protocol used in Signaling System No. 7 (SS7) networks. It typically runs over Message Transfer Part (MTP) although it can also run over IP (see SCTP [19]). ISUP is used for controlling telephone calls and for maintenance of the network (blocking circuits, resetting circuits etc.).
Integrated Services Digital Network（ISDN）User Part（ISUP）[12]は、Signaling System No. 7（SS7）ネットワークで使用されるレベル4プロトコルです。通常はMessage Transfer Part（MTP）で実行されますが、IPで実行することもできます（SCTP [19]を参照）。 ISUPは、通話の制御とネットワークのメンテナンス（ブロック回路、リセット回路など）に使用されます。
A module performing the mapping between these two protocols is usually referred to as Media Gateway Controller (MGC), although the terms 'softswitch' or 'call agent' are also sometimes used. An MGC has logical interfaces facing both networks, the network carrying ISUP and the network carrying SIP. The MGC also has some capabilities for controlling the voice path; there is typically a Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public Switched Telephone Network - PSTN) and with IP interfaces (Voice over IP - VoIP). The MGC and the MG can be merged together in one physical box or kept separate.
これら2つのプロトコル間のマッピングを実行するモジュールは、通常、メディアゲートウェイコントローラー（MGC）と呼ばれますが、「ソフトスイッチ」または「コールエージェント」という用語も使用されることがあります。 MGCには、ISUPを伝送するネットワークとSIPを伝送するネットワークの両方のネットワークに面する論理インターフェイスがあります。 MGCには、音声パスを制御するいくつかの機能もあります。通常、E1 / T1トランキングインターフェイス（公衆交換電話網-PSTNからの音声）とIPインターフェイス（Voice over IP-VoIP）を備えたメディアゲートウェイ（MG）があります。 MGCとMGは、1つの物理的なボックスに統合するか、別々にしておくことができます。
These MGCs are frequently used to bridge SIP and ISUP networks so that calls originating in the PSTN can reach IP telephone endpoints and vice versa. This is useful for cases in which PSTN calls need to take advantage of services in IP world, in which IP networks are used as transit networks for PSTN-PSTN calls, architectures in which calls originate on desktop 'softphones' but terminate at PSTN terminals, and many other similar next-generation telephone architectures.
これらのMGCはSIPおよびISUPネットワークのブリッジに頻繁に使用されるため、PSTNで発信されたコールはIP電話エンドポイントに到達でき、その逆も可能です。これは、PSTNコールがIPワールドのサービスを利用する必要がある場合に役立ちます。IPネットワークは、PSTN-PSTNコールのトランジットネットワークとして使用されます。このアーキテクチャでは、コールはデスクトップの「ソフトフォン」で始まり、PSTN端末で終了します。そして他の多くの同様の次世代電話アーキテクチャ。
This document describes logic and procedures which an MGC might use to implement the mapping between SIP and ISUP by illustrating the correspondences, at the message level and parameter level, between the protocols. It also describes the interplay between parallel state machines for these two protocols as a recommendation for implementers to synchronize protocol events in interworking architectures.
このドキュメントでは、プロトコル間のメッセージレベルとパラメータレベルでの対応を示すことにより、MGCがSIPとISUP間のマッピングを実装するために使用するロジックと手順について説明します。また、実装者がインターワーキングアーキテクチャでプロトコルイベントを同期するための推奨事項として、これら2つのプロトコルのパラレルステートマシン間の相互作用についても説明します。
This document focuses on the translation of ISUP messages into SIP messages, and the mapping of ISUP parameters into SIP headers. For ISUP calls that traverse a SIP network, the purpose of translation is to allow SIP elements such as proxy servers (which do not typically understand ISUP) to make routing decisions based on ISUP criteria such as the called party number. This document consequently provides a SIP mapping only for those ISUP parameters which might be used by intermediaries in the routing of SIP requests. As a side effect of this approach, translation also increases the overall interoperability by providing critical information about the call to SIP endpoints that cannot understand encapsulated ISUP, or perhaps which merely cannot understand the particular ISUP variant encapsulated in a message.
このドキュメントでは、ISUPメッセージのSIPメッセージへの変換、およびISUPパラメータのSIPヘッダーへのマッピングに焦点を当てています。 SIPネットワークを通過するISUP呼び出しの場合、変換の目的は、プロキシサーバー（通常はISUPを理解しない）などのSIP要素が、着番号などのISUP基準に基づいてルーティングを決定できるようにすることです。したがって、このドキュメントでは、SIP要求のルーティングで仲介者が使用する可能性のあるISUPパラメータのみにSIPマッピングを提供します。このアプローチの副作用として、変換は、カプセル化されたISUPを理解できない、またはメッセージにカプセル化された特定のISUPバリアントを単に理解できないSIPエンドポイントへのコールに関する重要な情報を提供することにより、全体的な相互運用性も向上させます。
This document also only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these messages neither have nor require any analog in SIP.
このドキュメントでは、ISUPの呼び出し機能も考慮されています。 PSTNトランクを処理するメンテナンスメッセージは、進行中のコールの制御に影響を与える範囲でのみ処理されます。それ以外の場合、これらのメッセージにはSIPのアナログはありません。
Messages indicating error or congestion situations in the PSTN (MTP-3) and the recovery mechanisms used such as User Part Available and User Part Test ISUP messages are outside the scope of this document
PSTN（MTP-3）のエラーまたは輻輳状況を示すメッセージと、使用可能なユーザーパーツおよびユーザーパーツテストISUPメッセージなどの回復メカニズムは、このドキュメントの範囲外です。
There are several flavors of ISUP. International Telecommunication Union Telecommunication Standardization Sector (ITU-T) International ISUP [12] is used through this document; some differences with the American National Standards Institute (ANSI) [11] ISUP and the Telecommunication Technology Committee (TTC) ISUP are also outlined. ITU-T ISUP is used in this document because it is the most widely known of all the ISUP flavors. Due to the small number of fields that map directly from ISUP to SIP, the signaling differences between ITU-T ISUP and specific national variants of ISUP will generally have little to no impact on the mapping. Note, however, that the ITU-T has not substantially standardized practices for Local Number Portability (LNP) since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. The number portability practices described in this document are presented as an optional mechanism.
ISUPにはいくつかの種類があります。このドキュメントでは、国際電気通信連合電気通信標準化部門（ITU-T）の国際ISUP [12]を使用しています。米国規格協会（ANSI）[11] ISUPおよび電気通信技術委員会（TTC）ISUPとのいくつかの違いについても概説します。 ITU-T ISUPは、すべてのISUPフレーバーの中で最も広く知られているため、このドキュメントで使用されています。 ISUPからSIPに直接マッピングするフィールドの数が少ないため、ITU-T ISUPとISUPの特定の国別バリアントの間のシグナリングの違いは、マッピングにほとんど影響を与えません。ただし、移植性は国別の番号計画の慣行に基づいている傾向があるため、ITU-Tは市内番号の移植性（LNP）に関する実質的に標準化された慣習を備えておらず、そのためLNPは事実上国ごとに説明する必要があることに注意してください。このドキュメントで説明する番号の移植性の実践は、オプションのメカニズムとして提示されています。
Mapping of SIP headers to ISUP parameters in this document focuses largely on the mapping between the parameters found in the ISUP Initial Address Message (IAM) and the headers associated with the SIP INVITE message; both of these messages are used in their respective protocols to request the establishment of a call. Once an INVITE has been sent for a particular session, such headers as the To and From field become essentially fixed, and no further translation will be required during subsequent signaling, which is routed in accordance with Via and Route headers. Hence, the problem of parameter-to-header mapping in SIP-T is confined more or less to the IAM and the INVITE. Some additional detail is given in the population of parameters in the ISUP messages Address Complete Message (ACM) and Release Message (REL) based on SIP status codes.
このドキュメントのSIPヘッダーのISUPパラメーターへのマッピングは、ISUP初期アドレスメッセージ（IAM）にあるパラメーターとSIP INVITEメッセージに関連付けられたヘッダーとの間のマッピングに主に焦点を当てています。これらのメッセージは両方とも、それぞれのプロトコルで使用され、コールの確立を要求します。特定のセッションでINVITEが送信されると、ToおよびFromフィールドなどのヘッダーは本質的に固定され、ViaおよびRouteヘッダーに従ってルーティングされる後続のシグナリング中に、それ以上の変換は必要ありません。したがって、SIP-Tでのパラメーターとヘッダーのマッピングの問題は、多かれ少なかれIAMとINVITEに限定されます。 SIPステータスコードに基づくISUPメッセージのアドレス完了メッセージ（ACM）およびリリースメッセージ（REL）のパラメーターの母集団に、追加の詳細がいくつか示されています。
This document describes when the media path associated with a SIP call is to be initialized, terminated, modified, etc., but it does not go into details such as how the initialization is performed or which protocols are used for that purpose.
このドキュメントでは、SIPコールに関連付けられたメディアパスをいつ初期化、終了、変更するかなどについて説明しますが、初期化の実行方法やその目的で使用されるプロトコルなどの詳細については説明しません。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant SIP implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」 、および「OPTIONAL」は、RFC2119 [2]で説明されているように解釈され、準拠するSIP実装の要件レベルを示します。
There are several scenarios where ISUP-SIP mapping takes place. The way the messages are generated is different depending on the scenario.
ISUP-SIPマッピングが行われるシナリオはいくつかあります。メッセージが生成される方法は、シナリオによって異なります。
When there is a single MGC and the call is from a SIP phone to a PSTN phone, or vice versa, the MGC generates the ISUP messages based on the methods described in this document.
MGCが1つあり、コールがSIP電話からPSTN電話へ、またはその逆の場合、MGCはこのドキュメントで説明されている方法に基づいてISUPメッセージを生成します。
+-------------+ +-----+ +-------------+
| PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
+-------------+ +-----+ +-------------+
The scenario where a call originates in the PSTN, goes into a SIP network and terminates in the PSTN again is known as "SIP bridging". SIP bridging should provide ISUP transparency between the PSTN switches handling the call. This is achieved by encapsulating the incoming ISUP messages in the body of the SIP messages (see [3]). In this case, the ISUP messages generated by the egress MGC are the ones present in the SIP body (possibly with some modifications; for example, if the called number in the request Uniform Resource Identifier - URI - is different from the one present in the ISUP due to SIP redirection, the ISUP message will need to be adjusted).
コールがPSTNで発信され、SIPネットワークに入り、再びPSTNで終了するシナリオは、「SIPブリッジング」と呼ばれます。 SIPブリッジングは、コールを処理するPSTNスイッチ間のISUP透過性を提供する必要があります。これは、着信ISUPメッセージをSIPメッセージの本文にカプセル化することで実現されます（[3]を参照）。この場合、出力MGCによって生成されたISUPメッセージは、SIP本体に存在するメッセージです（たとえば、いくつかの変更が加えられている場合があります。たとえば、要求の着信番号Uniform Resource Identifier-URI-が、 SIPリダイレクトによるISUP、ISUPメッセージを調整する必要があります）。
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+
SIP is used in the middle of both MGCs because the voice path has to be established through the IP network between both MGs; this structure also allows the call to take advantage of certain SIP services. ISUP messages in the SIP bodies provide further information (such as cause values and optional parameters) to the peer MGC.
両方のMG間のIPネットワークを介して音声パスを確立する必要があるため、両方のMGCの中間でSIPが使用されます。この構造により、コールは特定のSIPサービスを利用できます。 SIP本体のISUPメッセージは、ピアMGCに詳細情報（原因の値やオプションのパラメーターなど）を提供します。
In both scenarios, the ingress MGC places the incoming ISUP messages in the SIP body by default. Note that this has security implications; see Section 15. If the recipient of these messages (typically a SIP User Agent Client/User Agent Server - UAC/UAS) does not understand them, a negotiation using the SIP 'Accept' and 'Require' headers will take place and they will not be included in the next SIP message exchange.
どちらのシナリオでも、入力MGCはデフォルトで着信ISUPメッセージをSIP本体に配置します。これはセキュリティに影響を与えることに注意してください。セクション15を参照してください。これらのメッセージの受信者（通常はSIPユーザーエージェントクライアント/ユーザーエージェントサーバー-UAC / UAS）がメッセージを理解できない場合、SIPの「Accept」および「Require」ヘッダーを使用したネゴシエーションが行われ、次のSIPメッセージ交換には含まれません。
There can be a Signaling Gateway (SG) between the PSTN and the MGC. It encapsulates the ISUP messages over IP in a manner such as the one described in [19]. The mapping described in this document is not affected by the underlying transport protocol of ISUP.
PSTNとMGCの間にシグナリングゲートウェイ（SG）を配置できます。 [19]で説明されているような方法でIPを介してISUPメッセージをカプセル化します。このドキュメントで説明されているマッピングは、ISUPの基になるトランスポートプロトコルの影響を受けません。
Note that overlap dialing mechanisms (use of the Subsequent Address Message - SAM) are outside the scope of this document. This document assumes that gateways facing ISUP networks in which overlap dialing is used will implement timers to insure that all digits have been collected before an INVITE is transmitted to a SIP network.
オーバーラップダイヤリングメカニズム（後続アドレスメッセージ-SAMの使用）は、このドキュメントの範囲外であることに注意してください。このドキュメントでは、オーバーラップダイヤリングが使用されているISUPネットワークに面するゲートウェイがタイマーを実装して、INVITEがSIPネットワークに送信される前にすべての数字が確実に収集されることを前提としています。
In some instances, gateways may receive incomplete ISUP messages which indicate message segmentation due to excessive message length. Commonly these messages will be followed by a Segmentation Message (SGM) containing the remainder of the original ISUP message. An incomplete message may not contain sufficient parameters to allow for a proper mapping to SIP; similarly, encapsulating (see below) an incomplete ISUP message may be confusing to terminating gateways. Consequently, a gateway MUST wait until a complete ISUP message is received (which may involve waiting until one or more SGMs arrive) before sending any corresponding INVITE.
場合によっては、ゲートウェイは、過度のメッセージ長が原因でメッセージのセグメント化を示す不完全なISUPメッセージを受信することがあります。通常、これらのメッセージの後には、元のISUPメッセージの残りを含むセグメンテーションメッセージ（SGM）が続きます。不完全なメッセージには、SIPへの適切なマッピングを可能にするのに十分なパラメータが含まれていない場合があります。同様に、不完全なISUPメッセージをカプセル化（下記を参照）すると、ゲートウェイの終了を混乱させる可能性があります。その結果、ゲートウェイは、対応するINVITEを送信する前に、完全なISUPメッセージが受信されるまで待機する必要があります（1つ以上のSGMが到着するまで待機する必要がある場合があります）。
For a correct mapping between ISUP and SIP, some SIP mechanisms above and beyond those available in the base SIP specification are needed. These mechanisms are discussed below. If the SIP UAC/UAS involved in the call does not support them, it is still possible to proceed, but the behavior in the establishment of the call may be slightly different than that expected by the user (e.g., other party answers before receiving the ringback tone, user is not informed about the call being forwarded, etc.).
ISUPとSIPの間の正しいマッピングには、基本SIP仕様で利用可能なもの以上のSIPメカニズムが必要です。これらのメカニズムについては、以下で説明します。通話に関与するSIP UAC / UASがそれらをサポートしていない場合でも、続行することは可能ですが、通話の確立における動作は、ユーザーが期待する動作とは少し異なる場合があります（たとえば、呼び出し音、転送されている通話についてユーザーに通知されないなど）。
To allow gateways to take advantage of the full range of services afforded by the existing telephone network when placing calls from PSTN to PSTN across a SIP network, SIP messages MUST be capable of transporting ISUP payloads from gateway to gateway. The format for encapsulating these ISUP messages is defined in [3].
ゲートウェイがSIPネットワークを介してPSTNからPSTNに通話を発信するときに既存の電話ネットワークによって提供されるサービスの全範囲を利用できるようにするには、SIPメッセージはISUPペイロードをゲートウェイからゲートウェイに転送できる必要があります。これらのISUPメッセージをカプセル化するためのフォーマットは、[3]で定義されています。
SIP user agents which do not understand ISUP are permitted to ignore these optional MIME bodies.
ISUPを理解しないSIPユーザーエージェントは、これらのオプションのMIME本文を無視できます。
In most PSTN interworking situations, SIP message bodies will be required to carry session information (Session Description Protocol - SDP) in addition to ISUP and/or billing information.
ほとんどのPSTNインターワーキング状況では、ISUPや課金情報に加えて、セッション情報（Session Description Protocol-SDP）を運ぶためにSIPメッセージ本文が必要になります。
PSTN interworking nodes MUST understand the MIME type of "multipart/mixed" as defined in RFC2046 [4]. Clients express support for this by including "multipart/mixed" in an "Accept" header.
PSTNインターワーキングノードは、RFC2046 [4]で定義されている「multipart / mixed」のMIMEタイプを理解する必要があります。クライアントは、「マルチパート/混合」を「Accept」ヘッダーに含めることで、これに対するサポートを表明します。
How DTMF tones played by the user are transmitted by a gateway is completely orthogonal to how SIP and ISUP are interworked; however, as DTMF carriage is a component of a complete gatewaying solution some guidance is offered here.
ユーザーが再生するDTMFトーンがゲートウェイによって送信される方法は、SIPとISUPのインターワーク方法と完全に直交しています。ただし、DTMFキャリッジは完全なゲートウェイソリューションのコンポーネントであるため、ここではいくつかのガイダンスを提供しています。
Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is desirable (since out-of-band transmission alone would provide many challenges for synchronization of the media stream for tone re-insertion). This transmission MAY be performed as described in RFC2833 [5].
音声送信用に選択されたコーデックはDTMF情報を運ぶのに理想的に適していない可能性があるため、この情報を帯域内で送信するシンボリックな方法が望ましいです（帯域外送信だけでは、トーンのメディアストリームの同期に多くの課題があるため）再挿入）。この送信は、RFC2833 [5]で説明されているように実行される場合があります。
Provisional responses (in the 1xx class) are used in the transmission of call progress information. PSTN interworking in particular relies on these messages for control of the media channel and timing of call events.
暫定応答（1xxクラス）は、コールプログレス情報の送信に使用されます。特にPSTNインターワーキングは、メディアチャネルの制御とコールイベントのタイミングをこれらのメッセージに依存しています。
When interworking with the PSTN, SIP messages MUST be sent reliably end-to-end; reliability of requests is guaranteed by the base protocol. One application-layer provisional reliability mechanism for responses is described in [18].
PSTNと連動する場合、SIPメッセージはエンドツーエンドで確実に送信される必要があります。リクエストの信頼性は、基本プロトコルによって保証されています。応答のための1つのアプリケーション層暫定信頼性メカニズムは、[18]で説明されています。
Early media denotes the capability to play media (audio for telephony) before a SIP session has been established (before a 2xx response code has been sent). For telephony, establishment of media in the backwards direction is desirable so that tones and announcements can be played, especially when interworking with a network that cannot signal call status out of band (such as a legacy MF network). In cases where interworking has not been encountered, use of early media is almost always undesirable since it consumes inter-machine trunk recourses to play media for which no revenue is collected. Note that since an INVITE almost always contains the SDP required to send media in the backwards direction, and requires that user agents prepare themselves to receive backwards media as soon as an INVITE transmitted, the baseline SIP protocol has enough support to enable rudimentary unidirectional early media systems. However, this mechanism has a number of limitations - for example, media streams offered in the SDP of the INVITE cannot be modified or declined, and bidirectional RTCP required for session maintenance cannot be established.
初期メディアは、SIPセッションが確立される前（2xx応答コードが送信される前）にメディア（テレフォニー用のオーディオ）を再生する機能を示します。テレフォニーの場合、特に帯域外のコールステータスを通知できないネットワーク（レガシーMFネットワークなど）と連動する場合に、トーンとアナウンスを再生できるように、逆方向にメディアを確立することが望ましいです。インターワーキングに遭遇していない場合、初期のメディアの使用は、収益が収集されていないメディアを再生するためにマシン間のトランクリソースを消費するため、ほとんど常に望ましくありません。 INVITEには、ほとんどの場合、メディアを逆方向に送信するために必要なSDPが含まれており、ユーザーエージェントは、INVITEが送信されるとすぐに逆方向メディアを受信する準備をする必要があるため、基本的なSIPプロトコルは、基本的な一方向の初期メディアを有効にするのに十分なサポートを備えています。システム。ただし、このメカニズムにはいくつかの制限があります。たとえば、INVITEのSDPで提供されるメディアストリームは変更または拒否できず、セッションメンテナンスに必要な双方向RTCPを確立できません。
Therefore gateways MAY support more sophisticated early media systems as they come to be better understood. One mechanism that provides a way of initiating a fully-featured early media system is described in [20].
したがって、ゲートウェイは、よりよく理解されるようになるにつれて、より洗練された初期のメディアシステムをサポートする場合があります。フル機能の初期メディアシステムを開始する方法を提供する1つのメカニズムは、[20]で説明されています。
Note that in SIP networks not just switches but also user agents can generate the 18x response codes and initiate early backwards media, and that therefore some gateways may wish to enforce policies that restrict the use of backwards media from arbitrary user agents (see Section 15).
SIPネットワークでは、スイッチだけでなく、ユーザーエージェントも18x応答コードを生成して早期の後方メディアを開始できることに注意してください。したがって、一部のゲートウェイは、任意のユーザーエージェントからの後方メディアの使用を制限するポリシーを適用したい場合があります（セクション15を参照）。 。
When interworking with the PSTN, there are situations when gateways will need to send messages to each other over SIP that do not correspond to any SIP operations.
PSTNと連動する場合、SIP操作に対応しないゲートウェイがSIPを介して相互にメッセージを送信する必要がある状況があります。
In support of mid-call transactions and other ISUP events that do not correspond to existing SIP methods, SIP gateways MUST support the INFO method, defined in RFC2976 [6]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits.
既存のSIPメソッドに対応しない通話中のトランザクションやその他のISUPイベントをサポートするために、SIPゲートウェイは、RFC2976 [6]で定義されているINFOメソッドをサポートする必要があります。このドキュメントでは、DTMFディジットを伝送するためのINFOの使用を規定または推奨していないことに注意してください。
Gateways MUST accept "405 Method Not Allowed" and "501 Not Implemented" as non-fatal responses to INFO requests - that is, any call in progress MUST NOT be torn down if a destination so rejects an INFO request sent by a gateway.
ゲートウェイは、「405 Method Not Allowed」および「501 Not Implemented」をINFOリクエストに対する致命的でない応答として受け入れる必要があります。つまり、宛先がゲートウェイによって送信されたINFOリクエストを拒否する場合、進行中の呼び出しは切断されてはなりません。
ISUP has a concept of presentation restriction - a mechanism by which a user can specify that they would not like their telephone number to be displayed to the person they are calling (presumably someone with Caller ID). When a gateway receives an ISUP request that requires presentation restriction, it must therefore shield the identity of the caller in some fashion.
ISUPには表示制限の概念があります。これは、ユーザーが自分の電話番号を通話相手（おそらく発信者IDを持つ人）に表示されないように指定できるメカニズムです。したがって、ゲートウェイがプレゼンテーション制限を必要とするISUP要求を受信すると、何らかの方法で呼び出し元のIDを保護する必要があります。
The base SIP protocol supports a method of specifying that a user is anonymous. However, this system has a number of limitations - for example, it reveals the identity of the gateway itself, which could be a privacy-impacting disclosure. Therefore gateways MAY support more sophisticated privacy systems. One mechanism that provides a way of supporting fully-featured privacy negotiation (which interacts well with identity management systems) is described in [9B].
基本SIPプロトコルは、ユーザーが匿名であることを指定する方法をサポートしています。ただし、このシステムにはいくつかの制限があります。たとえば、ゲートウェイ自体のIDが明らかになるため、プライバシーに影響を与える可能性があります。したがって、ゲートウェイはより高度なプライバシーシステムをサポートする場合があります。フル機能のプライバシーネゴシエーションをサポートする方法を提供する1つのメカニズム（ID管理システムと適切に相互作用します）は、[9B]で説明されています。
There is a way in ISUP to signal that you would like to discontinue an attempt to set up a call - the general-purpose REL is sent in the forwards direction. There is a similar concept in SIP - that of a CANCEL request that is sent in order to discontinue the establishment of a SIP dialog. For various reasons, however, CANCEL requests cannot contain message bodies, and therefore in order to carry the important information in the REL (the cause code) end-to-end in sip bridging cases, ISUP encapsulation cannot be used.
ISUPには、コールをセットアップする試みを中止することを通知する方法があります-汎用RELが順方向に送信されます。 SIPにも同様の概念があります。SIPダイアログの確立を中止するために送信されるCANCEL要求の概念です。ただし、さまざまな理由により、CANCEL要求にメッセージ本文を含めることができないため、SIPブリッジングの場合にREL（原因コード）で重要な情報をエンドツーエンドで伝達するために、ISUPカプセル化を使用できません。
Ordinarily, this is not a big problem, because for practical purposes the only reason that a REL is ever issued to cancel a call setup attempt is that a user hangs up the phone while it is still ringing (which results in a "Normal clearing" cause code). However, under exceptional conditions, like catastrophic network failure, a REL may be sent with a different cause code, and it would be handy if a SIP network could carry the cause code end-to-end. Therefore gateways MAY support a mechanism for end-to-end delivery of such failure reasons. One mechanism that provides this capability is described in [9].
通常、これは大きな問題ではありません。RELがコールセットアップの試行をキャンセルするために発行される唯一の理由は、ユーザーが電話を呼び出している間に電話を切ったためです（これにより、「通常のクリア」が発生します。原因コード）。ただし、壊滅的なネットワーク障害などの例外的な状況では、RELは別の原因コードで送信される可能性があり、SIPネットワークが原因コードをエンドツーエンドで伝送できると便利です。したがって、ゲートウェイは、このような障害の理由をエンドツーエンドで配信するメカニズムをサポートする場合があります。この機能を提供する1つのメカニズムは、[9]で説明されています。
The mapping between ISUP and SIP is described using call flow diagrams and state machines. One state machine handles calls from SIP to ISUP and the second from ISUP to SIP. There are details, such as some retransmissions and some states (waiting for the Release Complete Message - RLC, waiting for SIP ACK etc.), that are not shown in the figures in order to make them easier to follow.
ISUPとSIP間のマッピングは、コールフロー図とステートマシンを使用して説明されます。 1つの状態マシンはSIPからISUPへの呼び出しを処理し、2番目の状態マシンはISUPからSIPへの呼び出しを処理します。一部の再送信および一部の状態（Release Complete Message-RLCの待機、SIP ACKの待機など）などの詳細は、わかりやすくするために図には示されていません。
The boxes represent the different states of the gateway, and the arrows show changes in the state. The event that triggers the change in the state and the actions to take appear on the arrow: event / section describing the actions to take.
ボックスはゲートウェイのさまざまな状態を表し、矢印は状態の変化を示します。状態の変化をトリガーするイベントと実行するアクションが矢印に表示されます。イベント/実行するアクションを説明するセクション。
For example, 'INVITE / 7.2.1' indicates that an INVITE request has been received by the gateway, and the procedure upon reception is described in the section 7.2.1 of this document.
たとえば、「INVITE / 7.2.1」は、INVITE要求がゲートウェイによって受信されたことを示します。受信時の手順は、このドキュメントのセクション7.2.1で説明されています。
It is RECOMMENDED that gateways implement functional equivalence with the call flows detailed in Section 7.1 and Section 8.1. Deviations from these flows are permissible in support of national ISUP variants, or any of the conservative policies recommended in Section 15.
ゲートウェイがセクション7.1およびセクション8.1に詳述されているコールフローと同等の機能を実装することをお勧めします。これらのフローからの逸脱は、国内のISUPバリアント、またはセクション15で推奨されている保守的なポリシーをサポートするために許容されます。
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the SIP network. "100 Trying" acknowledgements to INVITE requests are not displayed below although they are required in many architectures.
次のコールフローは、SIPネットワークから開始されたコールをセットアップするときの、成功した場合とエラーの場合のメッセージの順序を示しています。 INVITEリクエストに対する「100回試行中」の確認応答は、多くのアーキテクチャで必要ですが、下には表示されません。
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG."
これらの図では、すべてのコールシグナリング（SIP、ISUP）がMGCに出入りしています。メディア処理（オーディオカットスルー、トランク解放など）は、MGCの制御下でMGによって実行されています。簡単にするために、これらは「MGC / MG」というラベルの付いた単一のノードとして示されています。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。
3. The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message.
3. リモートISUPノードは、ACMメッセージを送り返すことで、アドレスがコールをセットアップするのに十分であることを示します。
4. The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 7.2.5 and Section 7.2.6) and returned to the SIP node. This response may contain SDP to establish an early media stream (as shown in the diagram). If no SDP is present, the audio will be established in both directions after step 8.
4. ACMメッセージの「着呼側ステータス」コードは、SIP暫定応答にマップされ（セクション7.2.5およびセクション7.2.6で説明）、SIPノードに返されます。この応答には、初期のメディアストリームを確立するためのSDPが含まれている可能性があります（図に示すとおり）。 SDPが存在しない場合、オーディオはステップ8の後に双方向で確立されます。
5. If the ISUP variant permits, the remote ISUP node may issue a variety of Call Progress (CPG) messages to indicate, for example, that the call is being forwarded.
5. ISUPバリアントが許可する場合、リモートISUPノードはさまざまなCall Progress（CPG）メッセージを発行して、たとえば、コールが転送されていることを示すことができます。
6. Upon receipt of a CPG message, the gateway will map the event code to a SIP provisional response (see Section 7.2.9) and send it to the SIP node.
6. CPGメッセージを受信すると、ゲートウェイはイベントコードをSIP暫定応答（セクション7.2.9を参照）にマップし、SIPノードに送信します。
7. Once the PSTN user answers, an Answer (ANM) message will be sent to the gateway.
7. PSTNユーザーが応答すると、Answer（ANM）メッセージがゲートウェイに送信されます。
8. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node.
8. ANMを受信すると、ゲートウェイは200メッセージをSIPノードに送信します。
9. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt.
9. SIPノードは、INVITE最終応答（200）を受信すると、受信を確認するためにACKを送信します。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
Note that this flow is not supported in ANSI networks.
このフローはANSIネットワークではサポートされていないことに注意してください。
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。
3. Since the remote node is configured for automatic answering, it will send a Connect Message (CON) upon receipt of the IAM. (For ANSI, this message will be an ANM).
3. リモートノードは自動応答用に構成されているため、IAMの受信時に接続メッセージ（CON）を送信します。 （ANSIの場合、このメッセージはANMになります）。
4. Upon receipt of the CON, the gateway will send a 200 message to the SIP node.
4. CONを受信すると、ゲートウェイは200メッセージをSIPノードに送信します。
5. The SIP node, upon receiving an INVITE final response (200), will send an ACK to acknowledge receipt.
5. SIPノードは、INVITE最終応答（200）を受信すると、受信を確認するためにACKを送信します。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network. The ISUP timer T7 is started at this point.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。この時点で、ISUPタイマーT7が開始されます。
3. The ISUP timer T7 expires before receipt of an ACM or CON message, so a REL message is sent to cancel the call.
3. ISUPタイマーT7は、ACMまたはCONメッセージを受信する前に期限切れになるため、コールをキャンセルするためにRELメッセージが送信されます。
4. A gateway timeout message is sent back to the SIP node.
4. ゲートウェイタイムアウトメッセージがSIPノードに送り返されます。
5. The SIP node, upon receiving an INVITE final response (504), will send an ACK to acknowledge receipt.
5. SIPノードは、INVITE最終応答（504）を受信すると、受信を確認するためにACKを送信します。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。
3. Since the remote node is configured for automatic answering, it will send a CON message upon receipt of the IAM. In ANSI flows, rather than a CON, an ANM (without ACM) would be sent.
3. リモートノードは自動応答用に構成されているため、IAMを受信するとCONメッセージを送信します。 ANSIフローでは、CONではなく、ANM（ACMなし）が送信されます。
4. Upon receipt of the ANM, the gateway will send a 200 message to the SIP node and set SIP timer T1.
4. ANMを受信すると、ゲートウェイは200メッセージをSIPノードに送信し、SIPタイマーT1を設定します。
5. The response is retransmitted every time the SIP timer T1 expires.
5. 応答は、SIPタイマーT1が期限切れになるたびに再送信されます。
6. After seven retransmissions, the call is torn down by sending a REL to the ISUP node, with a cause code of 102 (recover on timer expiry).
6. 7回の再送信の後、原因コード102（タイマーの期限切れで回復）を指定してRELをISUPノードに送信することにより、コールは切断されます。
7. A BYE is transmitted to the SIP node in an attempt to close the call. Further handling for this clean up is not shown, since the SIP node's state is not easily known in this scenario.
7. BYEは、コールをクローズしようとしてSIPノードに送信されます。このシナリオではSIPノードの状態が簡単に分からないため、このクリーンアップの以降の処理は示されていません。
8. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message.
8. RELメッセージを受信すると、リモートISUPノードはRLCメッセージで応答します。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。
3. Since the remote ISUP node is unable to complete the call, it will send a REL.
3. リモートISUPノードは呼び出しを完了できないため、RELを送信します。
4. The gateway releases the circuit and confirms that it is available for reuse by sending an RLC.
4. ゲートウェイは回線を解放し、RLCを送信して再利用できることを確認します。
5. The gateway translates the cause code in the REL to a SIP error response (see Section 7.2.4) and sends it to the SIP node.
5. ゲートウェイは、RELの原因コードをSIPエラー応答（セクション7.2.4を参照）に変換し、それをSIPノードに送信します。
6. The SIP node sends an ACK to acknowledge receipt of the INVITE final response.
6. SIPノードは、ACKを送信して、INVITE最終応答の受信を確認します。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。
3. Since the ISUP node is unable to complete the call and wants to generate the error tone/announcement itself, it sends an ACM with a cause code. The gateway starts an interwork timer.
3. ISUPノードはコールを完了できず、エラートーン/アナウンス自体を生成する必要があるため、原因コードを含むACMを送信します。ゲートウェイはインターワークタイマーを開始します。
4. Upon receipt of an ACM with cause (presence of the CAI parameter), the gateway will generate a 183 message towards the SIP node; this contains SDP to establish early media cut-through.
4. 原因（CAIパラメータの存在）を含むACMを受信すると、ゲートウェイはSIPノードに向けて183メッセージを生成します。これには、初期メディアカットスルーを確立するためのSDPが含まれています。
5. A final INVITE response, based on the cause code received in the earlier ACM message, is generated and sent to the SIP node to terminate the call. See Section 7.2.4.1 for the table which contains the mapping from cause code to SIP response.
5. 以前のACMメッセージで受信された原因コードに基づいて、最終的なINVITE応答が生成され、SIPノードに送信されて通話が終了します。原因コードからSIP応答へのマッピングを含む表については、7.2.4.1項を参照してください。
6. Upon expiration of the interwork timer, a REL is sent towards the PSTN node to terminate the call. Note that the SIP node can also terminate the call by sending a CANCEL before the interwork timer expires. In this case, the signaling progresses as in Section 7.1.7.
6. インターワークタイマーの満了時に、RELがPSTNノードに送信され、コールが終了します。 SIPノードは、インターワークタイマーが期限切れになる前にCANCELを送信して、コールを終了することもできます。この場合、シグナリングはセクション7.1.7のように進行します。
7. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message.
7. RELメッセージを受信すると、リモートISUPノードはRLCメッセージで応答します。
8. The SIP node sends an ACK to acknowledge receipt of the INVITE final response.
8. SIPノードは、ACKを送信して、INVITE最終応答の受信を確認します。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request.
1. SIPユーザーがPSTNユーザーとのセッションを開始したい場合、SIPノードはINVITE要求を発行します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM message and sends it to the ISUP network.
2. INVITE要求を受信すると、ゲートウェイはそれをIAMメッセージにマップし、ISUPネットワークに送信します。
3. The remote ISUP node indicates that the address is sufficient to set up a call by sending back an ACM message.
3. リモートISUPノードは、ACMメッセージを送り返すことで、アドレスがコールをセットアップするのに十分であることを示します。
4. The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 7.2.5 and Section 7.2.6) and returned to the SIP node. This response may contain SDP to establish an early media stream.
4. ACMメッセージの「着呼側ステータス」コードは、SIP暫定応答にマップされ（セクション7.2.5およびセクション7.2.6で説明）、SIPノードに返されます。この応答には、初期のメディアストリームを確立するためのSDPが含まれる場合があります。
5. To cancel the call before it is answered, the SIP node sends a CANCEL request.
5. 応答する前にコールをキャンセルするために、SIPノードはCANCEL要求を送信します。
6. The CANCEL request is confirmed with a 200 response.
6. CANCELリクエストは200応答で確認されます。
7. Upon receipt of the CANCEL request, the gateway sends a REL message to terminate the ISUP call.
7. CANCEL要求を受信すると、ゲートウェイはRELメッセージを送信してISUPコールを終了します。
8. The gateway sends a "487 Call Cancelled" message to the SIP node to complete the INVITE transaction.
8. ゲートウェイは、「487 Call Cancelled」メッセージをSIPノードに送信して、INVITEトランザクションを完了します。
9. Upon receipt of the REL message, the remote ISUP node will reply with an RLC message.
9. RELメッセージを受信すると、リモートISUPノードはRLCメッセージで応答します。
10. Upon receipt of the 487, the SIP node will confirm reception with an ACK.
10. 487を受信すると、SIPノードはACKで受信を確認します。
Note that REL can be received in any state; the handling is the same for each case (see Section 10).
RELはどの状態でも受信できることに注意してください。処理は各ケースで同じです（セクション10を参照）。
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
When an INVITE request is received by the gateway, a "100 Trying" response MAY be sent back to the SIP network indicating that the gateway is handling the call.
INVITE要求がゲートウェイによって受信されると、ゲートウェイが通話を処理していることを示す「100 Trying」応答がSIPネットワークに返される場合があります。
The necessary hardware resources for the media stream MUST be reserved in the gateway when the INVITE is received, since an IAM message cannot be sent before the resource reservation (especially TCIC selection) takes place. Typically the resources consist of a time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources might also include any quality-of-service provisions (although no such practices are recommended in this document).
リソースの予約（特にTCICの選択）が行われる前にIAMメッセージを送信できないため、メディアストリームに必要なハードウェアリソースは、INVITEを受信したときにゲートウェイで予約する必要があります。通常、リソースは、E1 / T1のタイムスロットとIP側のRTP / UDPポートで構成されます。リソースには、サービス品質の規定も含まれる場合があります（ただし、このドキュメントではそのようなプラクティスは推奨されていません）。
After sending the IAM the timer T7 is started. The default value of T7 is between 20 and 30 seconds. The gateway goes to the 'Trying' state.
IAMを送信した後、タイマーT7が開始されます。 T7のデフォルト値は20〜30秒です。ゲートウェイは「試行中」状態になります。
This section details the mapping of the SIP headers in an INVITE message to the ISUP parameters in an Initial Address Message (IAM). A PSTN-SIP gateway is responsible for creating an IAM when it receives an INVITE.
このセクションでは、INVITEメッセージのSIPヘッダーの、初期アドレスメッセージ（IAM）のISUPパラメータへのマッピングについて詳しく説明します。 PSTN-SIPゲートウェイは、INVITEを受信したときにIAMを作成します。
Five mandatory parameters appear within the IAM message: the Called Party Number (CPN), the Nature of Connection Indicator (NCI), the Forward Call Indicators (FCI), the Calling Party's Category (CPC), and finally a parameter that indicates the desired bearer characteristics of the call - in some ISUP variants the Transmission Medium Requirement (TMR) is required, in others the User Service Information (USI) (or both). All IAM messages MUST contain these five parameters at a minimum. Thus, every gateway must have a means of populating each of those five parameters when an INVITE is received. Many of the values that will appear in these parameters (such as the NCI or USI) will most likely be the same for each IAM created by the gateway. Others (such as the CPN) will vary on a call-by-call basis; the gateway extracts information from the INVITE in order to properly populate these parameters.
IAMメッセージ内に5つの必須パラメーターが表示されます：着信側番号（CPN）、接続の性質インジケーター（NCI）、転送呼び出しインジケーター（FCI）、発信者のカテゴリ（CPC）、最後に目的のパラメーターコールのベアラ特性-一部のISUPバリアントでは、伝送媒体要件（TMR）が必要です。それ以外のユーザーでは、ユーザーサービス情報（USI）（またはその両方）が必要です。すべてのIAMメッセージには、少なくともこれらの5つのパラメーターが含まれている必要があります。したがって、すべてのゲートウェイには、INVITEを受信したときに、これらの5つのパラメータのそれぞれに入力する手段が必要です。これらのパラメーターに表示される値の多く（NCIやUSIなど）は、ゲートウェイによって作成された各IAMで同じである可能性が高いです。その他（CPNなど）はコールごとに異なります。ゲートウェイは、これらのパラメータを適切に入力するために、INVITEから情報を抽出します。
There are also quite a few optional parameters that can appear in an IAM message; Q.763 [17] lists 29 in all. However, each of these parameters need not to be translated in order to achieve the goals of SIP-ISUP mapping. As is stated above, translation allows SIP network elements to understand the basic PSTN context of the session (who it is for, and so on) if they are not capable of deciphering any encapsulated ISUP. Parameters that are only meaningful to the PSTN will be carried through PSTN-SIP- PSTN networks via encapsulation - translation is not necessary for these parameters. Of the aforementioned 29 optional parameters, only the following are immediately useful for translation: the Calling Party's Number (CIN, which is commonly present), Transit Network Selection (TNS), Carrier Identification Parameter (CIP, present in ANSI networks), Original Called Number (OCN), and the Generic Digits (known in some variants as the Generic Address Parameter (GAP)).
IAMメッセージに表示される可能性があるかなりの数のオプションパラメータもあります。 Q.763 [17]は全部で29をリストしています。ただし、SIP-ISUPマッピングの目的を達成するために、これらの各パラメータを変換する必要はありません。上で述べたように、SIPネットワーク要素は、カプセル化されたISUPを解読できない場合、変換によってセッションの基本的なPSTNコンテキスト（目的など）を理解できます。 PSTNにのみ意味のあるパラメータは、カプセル化によってPSTN-SIP-PSTNネットワークを介して伝送されます。これらのパラメータの変換は必要ありません。前述の29のオプションパラメータのうち、変換にすぐに役立つのは次のものだけです。発呼側の番号（CIN、一般的に存在）、トランジットネットワーク選択（TNS）、キャリア識別パラメータ（CIP、ANSIネットワークに存在）、元の着信番号（OCN）、およびジェネリックディジット（一部のバリアントでは、ジェネリックアドレスパラメータ（GAP）として知られています）。
When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD attempt to make use of encapsulated ISUP (see [3]), if any, within the INVITE to assist in the formulation of outbound PSTN signaling, but SHOULD also heed the security considerations in Section 15. If possible, the gateway SHOULD reuse the values of each of the ISUP parameters of the encapsulated IAM as it formulates an IAM that it will send across its PSTN interface. In some cases, the gateway will be unable to make use of that ISUP - for example, if the gateway cannot understand the ISUP variant and must therefore ignore the encapsulated body. Even when there is comprehensible encapsulated ISUP, the relevant values of SIP header fields MUST 'overwrite' through the process of translation the parameter values that would have been set based on encapsulated ISUP. In other words, the updates to the critical session context parameters that are created in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases, over the encapsulated ISUP. This allows many basic services, including various sorts of call forwarding and redirection, to be implemented in the SIP network.
SIP INVITEがPSTNゲートウェイに到着すると、ゲートウェイはINVITE内でカプセル化されたISUP（[3]を参照）を使用して、発信PSTNシグナリングの形成を支援する必要がありますが、セキュリティに関する考慮事項にも注意する必要があります（SHOULD）ゲートウェイは、可能であれば、カプセル化されたIAMの各ISUPパラメータの値を再利用して、PSTNインターフェイスを介して送信するIAMを作成する必要があります（SHOULD）。場合によっては、ゲートウェイがそのISUPを利用できないことがあります。たとえば、ゲートウェイがISUPバリアントを理解できないため、カプセル化された本文を無視する必要がある場合などです。包括的なカプセル化されたISUPがある場合でも、SIPヘッダーフィールドの関連する値は、カプセル化されたISUPに基づいて設定されていたであろうパラメーター値の変換プロセスを通じて「上書き」する必要があります。つまり、ISUP-SIP-ISUPブリッジングの場合、SIPネットワークで作成された重要なセッションコンテキストパラメータへの更新は、カプセル化されたISUPよりも優先されます。これにより、さまざまな種類のコール転送やリダイレクトなど、多くの基本的なサービスをSIPネットワークに実装できます。
For example, if an INVITE arrives at a gateway with an encapsulated IAM with a CPN field indicating the telephone number +12025332699, but the Request-URI of the INVITE indicates 'tel:+15105550110', the gateway MUST use the telephone number in the Request-URI, rather than the one in the encapsulated IAM, when creating the IAM that the gateway will send to the PSTN. Further details of how SIP header fields are translated into ISUP parameters follow.
たとえば、INVITEが、電話番号+12025332699を示すCPNフィールドを持つカプセル化されたIAMでゲートウェイに到着したが、INVITEのRequest-URIが「tel：+15105550110」を示している場合、ゲートウェイは、ゲートウェイがPSTNに送信するIAMを作成するときの、カプセル化されたIAMのURIではなく、Request-URI。 SIPヘッダーフィールドがISUPパラメータにどのように変換されるかについて、さらに詳しく説明します。
Gateways MUST be provisioned with default values for mandatory ISUP parameters that cannot be derived from translation(such as the NCI or TMR parameters) for those cases in which no encapsulated ISUP is present. The FCI parameter MUST also have a default, as only the 'M' bit of the default may be overwritten during the process of translation if the optional number portability translation mechanisms described below are used.
ゲートウェイは、カプセル化されたISUPが存在しない場合に、変換から導出できない必須のISUPパラメータ（NCIまたはTMRパラメータなど）のデフォルト値でプロビジョニングする必要があります。以下に説明するオプションの番号ポータビリティ変換メカニズムが使用される場合、変換のプロセス中にデフォルトの「M」ビットのみが上書きされる可能性があるため、FCIパラメータにもデフォルトが必要です。
The first step in the translation of the fields of an INVITE message to the parameters of an IAM is the inspection of the Request-URI.
INVITEメッセージのフィールドをIAMのパラメーターに変換する最初のステップは、Request-URIの検査です。
If the optional number portability practices are supported by the gateway, then the following steps related to handling of the 'npdi' and 'rn' parameters of the Request-URI should be followed.
オプションの番号ポータビリティプラクティスがゲートウェイでサポートされている場合、Request-URIの「npdi」および「rn」パラメータの処理に関連する次の手順に従う必要があります。
If there is no 'npdi=yes' field within the Request-URI, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
Request-URI内に「npdi = yes」フィールドがない場合、Tel URLの主要電話番号（「tel：」の直後の数字）は、セクション12で説明されている手順に従って、ISUP形式に変換する必要があります。また、CPNパラメータの入力に使用されます。
If the 'npdi=yes' field exists in the Request-URI, then the FCI parameter bit for 'number translated' within the IAM MUST reflect that a number portability dip has been performed.
Request-URIに「npdi = yes」フィールドが存在する場合、IAM内の「number translation」のFCIパラメータビットは、数値の移植性の低下が実行されたことを反映している必要があります。
If in addition to the 'npdi=yes' field there is no 'rn=' field present, then the main telephone number in the tel URL MUST be converted to ISUP format (see Section 12) and used to populate the CPN parameter. This indicates that a portability dip took place, but that the called party's number was not ported.
「npdi = yes」フィールドに加えて「rn =」フィールドが存在しない場合は、Tel URLのメインの電話番号をISUP形式（セクション12を参照）に変換し、CPNパラメータの入力に使用する必要があります。これは、移植性の低下が起こったが、着信側の番号が移植されなかったことを示しています。
If in addition to the 'npdi=yes' field an 'rn=' field is present, then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format and used to populate the CPN. The main telephone number in the tel URL MUST be converted to ISUP format and used to populate the Generic Digits Parameter (or GAP in ANSI). In some other ISUP variants, the number given in the 'rn=' field would instead be prepended to the main telephone number (with or without a prefix or separator) and the combined result MUST be used to populate the CPN. Once the 'rn=' and 'npdi=' parameters have been translation, the number portability translation practices are complete.
「npdi = yes」フィールドに加えて「rn =」フィールドが存在する場合、ANSI ISUPで「rn =」フィールドをISUP形式に変換し、CPNに入力するために使用する必要があります。電話URLの主要な電話番号をISUP形式に変換し、Generic Digitsパラメータ（またはANSIのGAP）に入力するために使用する必要があります。他の一部のISUPバリアントでは、「rn =」フィールドで指定された番号が代わりにメインの電話番号の前に付加されます（プレフィックスまたはセパレーターの有無にかかわらず）。結合された結果を使用してCPNを設定する必要があります。 「rn =」および「npdi =」パラメータが変換されると、数値ポータビリティ変換のプラクティスが完了します。
The following mandatory translation practices are performed after number portability translations, if any.
次の必須の変換プラクティスは、番号の移植性の変換がある場合に、その後に実行されます。
If number portability practices are not supported by the gateway, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
番号の移植性の実践がゲートウェイでサポートされていない場合は、Tel URLのプライマリ電話番号（「tel：」の直後の数字）をセクション12で説明されている手順に従ってISUP形式に変換し、 CPNパラメータ。
If the primary telephone number in the Request-URI and that of the To header are at variance, then the To header SHOULD be used to populate an OCN parameter. Otherwise the To header SHOULD be ignored.
Request-URIのプライマリ電話番号とToヘッダーの電話番号が異なる場合、Toヘッダーを使用してOCNパラメーターを設定する必要があります（SHOULD）。それ以外の場合は、Toヘッダーを無視する必要があります（SHOULD）。
Some optional translation procedures are provided for carrier-based routing. If the 'cic=' parameter is present in the Request-URI, the gateway SHOULD consult local policy to make sure that it is appropriate to transmit this Carrier Identification Code (CIC, not to be confused with the MTP3 'circuit identification code') in the IAM; if the gateway supports many independent trunks, it may need to choose a particular trunk that points to the carrier identified by the CIC, or a tandem through which that carrier is reachable. Policies for such trunks (based on the preferences of the carriers with which the trunks are associated and the ISUP variant in use) SHOULD dictate whether the CIP or TNS parameter is used to carry the CIC. In the absence of any pre-arranged policies, the TNS should be used when the CPN parameter is in an international format (i.e., the tel URL portion of the Request-URI is preceded by a '+', which will generate a CPN in international format), and (where supported) the CIP should be used in other cases.
キャリアベースのルーティングのために、いくつかのオプションの変換手順が提供されています。 'cic ='パラメータがRequest-URIに存在する場合、ゲートウェイはローカルポリシーを参照して、このキャリア識別コード（CIC、MTP3 '回路識別コード'と混同しないでください）を送信することが適切であることを確認する必要があります。 IAM内。ゲートウェイが多くの独立したトランクをサポートしている場合、CICによって識別されるキャリアを指す特定のトランク、またはそのキャリアが到達可能なタンデムを選択する必要がある場合があります。このようなトランクのポリシー（トランクが関連付けられているキャリアの設定と使用中のISUPバリアントに基づく）は、CIPまたはTNSパラメータを使用してCICを伝送するかどうかを指示する必要があります。事前に設定されたポリシーがない場合、CPNパラメータが国際形式の場合（つまり、Request-URIのtel URL部分の前に「+」を付けるとTNSが使用され、CPNが生成されます）他のケースでは、CIPを使用する必要があります。
When a SIP call has been routed to a gateway, then the Request-URI will most likely contain a tel URL (or a SIP URI with a tel URL user portion) - SIP-ISUP gateways that receive Request-URIs that do not contain valid telephone numbers SHOULD reject such requests with an appropriate response code. Gateways SHOULD however continue to process requests with a From header field that does not contain a telephone number, as will sometimes be the case if a call originated at a SIP phone that employs a SIP URI user@host convention. The CIN parameter SHOULD be omitted from the outbound IAM if the From field is unusable. Note that as an alternative, gateway implementers MAY consider some non-standard way of mapping particular SIP URIs to telephone numbers.
SIPコールがゲートウェイにルーティングされた場合、Request-URIにはTel URL（またはTel URLユーザー部分を持つSIP URI）が含まれている可能性が高い-有効なものを含まないRequest-URIを受信するSIP-ISUPゲートウェイ電話番号は、適切な応答コードでそのような要求を拒否する必要があります。ただし、ゲートウェイは、SIP URI user @ host規則を使用するSIP電話機でコールが発信された場合のように、電話番号を含まないFromヘッダーフィールドを使用して要求の処理を続行する必要があります（SHOULD）。 Fromフィールドが使用できない場合は、CINパラメータを送信IAMから省略してください。代わりに、ゲートウェイの実装者は、特定のSIP URIを電話番号にマッピングする非標準的な方法を検討してもよいことに注意してください。
When a gateway receives a message with (comprehensible) encapsulated ISUP, it MUST set the FCI indicator in the generated IAM so that all interworking-related bits have the same values as their counterparts in the encapsulated ISUP. In most cases, these indicators will state that no interworking was encountered, unless interworking has been encountered somewhere else in the call path. If usable encapsulated ISUP is not present in an INVITE received by the gateway, it is STRONGLY RECOMMENDED that the gateway set the Interworking Indicator bit of the FCI to 'no interworking' and the ISDN User Part Indicator to 'ISUP used all the way'; the gateway MAY also set the Originating Access indicator to 'Originating access non-ISDN' (generally, it is not safe to assume that SIP phones will support ISDN endpoint services, and the procedures in this document do not detail mappings to translate all such services).
ゲートウェイが（わかりやすい）カプセル化されたISUPでメッセージを受信すると、生成されたIAMでFCIインジケーターを設定して、すべてのインターワーキング関連ビットがカプセル化されたISUPの対応するビットと同じ値になるようにする必要があります。ほとんどの場合、これらのインジケーターは、呼び出しパスのどこかでインターワーキングが発生していない限り、インターワーキングが発生しなかったことを示します。ゲートウェイが受信したINVITEに使用可能なカプセル化ISUPが存在しない場合は、ゲートウェイがFCIのインターワーキングインジケータービットを「インターワーキングなし」に設定し、ISDNユーザーパーツインジケーターを「ISUPずっと使用」に設定することを強くお勧めします。ゲートウェイは、Originating Accessインジケーターを「Originating access non-ISDN」に設定することもできます（通常、SIP電話がISDNエンドポイントサービスをサポートすると想定することは安全ではありません。このドキュメントの手順では、このようなすべてのサービスを変換するマッピングの詳細は説明していません）。
Note that when 'interworking encountered' is set in the FCI parameter of the IAM, this indicates that ISUP is interworking with a network which is not capable of providing as many services as ISUP does. ISUP networks will therefore not employ certain features they otherwise normally would, including potentially the use of ISDN cause codes in failure conditions (as opposed to sending ACMs followed by audible announcements). If desired, gateway vendors MAY provide a configurable option, usable at the discretion of service providers, that will signal in the FCI that interworking has been encountered (and that ISUP is not used all the way) when encapsulated ISUP is not present; however, doing so may significantly limit the efficiency and transparency of SIP-ISUP translation.
IAMのFCIパラメータで「interworking遭遇」が設定されている場合、これは、ISUPがISUPが提供するサービスを提供できないネットワークとインターワークしていることを示しています。したがって、ISUPネットワークは、（ACMを送信した後に音声アナウンスを送信するのではなく）障害状態でISDN原因コードを使用する可能性を含め、通常そうである特定の機能を使用しません。必要に応じて、ゲートウェイベンダーは、カプセル化されたISUPが存在しない場合に、インターワーキングが発生した（およびISUPが完全に使用されていない）ことをFCIで通知する、構成可能なオプションを提供できます（サービスプロバイダーの裁量で使用できます）。ただし、これを行うと、SIP-ISUP変換の効率と透過性が大幅に制限される可能性があります。
Claiming to be an ISDN node might make the callee request ISDN user to user services. Since user to user services 1 and 2 must be requested by the caller, they do not represent a problem (see [14]). User to user service 3 can be requested by the callee also. In non-SIP bridging situations, the MGC should be capable of rejecting this service request.
ISDNノードであると主張すると、呼び出し先がISDNユーザー間サービスを要求する場合があります。ユーザー間サービス1と2は呼び出し側から要求される必要があるため、問題とはなりません（[14]を参照）。ユーザー間サービス3は、呼び出し先からも要求できます。 SIP以外のブリッジング状況では、MGCはこのサービス要求を拒否できる必要があります。
Since no response was received from the PSTN all the resources in the MG are released. A '504 Server Timeout' SHOULD be sent back to the SIP network. A REL message with cause value 102 (protocol error, recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can expect the PSTN to respond with RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
PSTNから応答を受信しなかったため、MG内のすべてのリソースが解放されます。 「504サーバータイムアウト」はSIPネットワークに送り返されるべきです。原因値102（プロトコルエラー、タイマー満了時の回復）を含むRELメッセージをPSTNに送信する必要があります（SHOULD）。ゲートウェイは、PSTNがRLCで応答し、SIPネットワークが解放シーケンスが完了したことを示すACKで応答することを期待できます。
If a CANCEL or BYE request is received before a final SIP response has been sent, a '200 OK' MUST be sent to the SIP network to confirm the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE transaction. All the resources are released and a REL message SHOULD be sent to the PSTN with cause value 16 (normal clearing). Gateways can expect an RLC from the PSTN to be received indicating that the release sequence is complete.
最後のSIP応答が送信される前にCANCELまたはBYE要求が受信された場合、CANCELまたはBYEを確認するために「200 OK」をSIPネットワークに送信する必要があります。 INVITEトランザクションを終了するには、487も送信する必要があります。すべてのリソースが解放され、RELメッセージが原因値16（通常のクリア）でPSTNに送信される必要があります（SHOULD）。ゲートウェイは、リリースシーケンスが完了したことを示すPSTNからのRLCを受信することを期待できます。
In SIP bridging situations, a REL might be encapsulated in the body of a BYE request. Although BYE is usually mapped to cause code 16 (normal clearing), under exceptional circumstances the cause code in the REL message might be different. Therefore the Cause Indicator parameter of the encapsulated REL should be re-used in the REL sent to the PSTN.
SIPブリッジング状況では、RELがBYEリクエストの本文にカプセル化される場合があります。 BYEは通常、原因コード16（通常のクリア）にマップされますが、例外的な状況下では、RELメッセージの原因コードは異なる場合があります。したがって、カプセル化されたRELの原因インジケータパラメータは、PSTNに送信されるRELで再利用する必要があります。
Note that a BYE or CANCEL request may contain a Reason header that SHOULD be mapped to the Cause Indicator parameter (see Section 5.8). If a BYE contains both a Reason header and encapsulated ISUP, the value in the Reason header MUST be preferred.
BYEまたはCANCELリクエストには、原因インジケータパラメータにマッピングする必要がある理由ヘッダーが含まれている場合があることに注意してください（セクション5.8を参照）。 BYEにReasonヘッダーとカプセル化されたISUPの両方が含まれている場合、Reasonヘッダーの値を優先する必要があります。
All the resources in the gateway SHOULD be released before the gateway sends any REL message.
ゲートウェイがRELメッセージを送信する前に、ゲートウェイ内のすべてのリソースを解放する必要があります。
This section applies when a REL is received before a final SIP response has been sent. Typically, this condition arises when a call has been rejected by the PSTN.
このセクションは、最終的なSIP応答が送信される前にRELを受信した場合に適用されます。通常、この状態は、PSTNによってコールが拒否されたときに発生します。
Any gateway resources SHOULD be released immediately and an RLC MUST be sent to the ISUP network to indicate that the circuit is available for reuse.
ゲートウェイリソースはすぐに解放する必要があり（SHOULD）、RLCをISUPネットワークに送信して、回路が再利用できることを示す必要があります。
If the INVITE that originated this transaction contained a legitimate and comprehensible encapsulated ISUP message (i.e., an IAM using a variant supported by the gateway, preferably with a digital signature), then encapsulated ISUP SHOULD be sent in the response to the INVITE when possible (since this suggests an ISUP-SIP-ISUP bridging case) - therefore, the REL message just received SHOULD be included in the body of the SIP response. The gateway SHOULD NOT return a response with encapsulated ISUP if the originator of the INVITE did not enclose ISUP itself.
このトランザクションを開始したINVITEに、正当で理解可能なカプセル化されたISUPメッセージ（つまり、ゲートウェイでサポートされているバリアントを使用するIAM、できればデジタル署名が付いているIAM）が含まれている場合は、カプセル化されたISUPを可能な限りINVITEへの応答で送信する必要があります（これはISUP-SIP-ISUPブリッジングのケースを示唆しているため）-したがって、受信したRELメッセージはSIP応答の本文に含める必要があります（SHOULD）。 INVITEの発信者がISUP自体を囲んでいない場合、ゲートウェイはカプセル化されたISUPで応答を返すべきではありません（SHOULD NOT）。
Note that the receipt of certain maintenance messages in response to IAM such as Blocking Message (BLO) or Reset Message (RSC) (or their circuit group message equivalents) may also result in the teardown of calls in this phase of the state machine. Behavior for maintenance messages is given below in Section 11.
ブロッキングメッセージ（BLO）やリセットメッセージ（RSC）（または同等の回路グループメッセージ）などのIAMへの応答として特定のメンテナンスメッセージを受信すると、ステートマシンのこのフェーズで呼び出しがティアダウンされる場合があります。メンテナンスメッセージの動作については、セクション11で説明します。
The use of the REL message in the SS7 network is very general, whereas SIP has a number of specific tools that, collectively, play the same role as REL - namely BYE, CANCEL, and the various status/response codes. An REL can be sent to tear down a call that is already in progress (BYE), to cancel a previously sent call setup request that has not yet been completed (CANCEL), or to reject a call setup request (IAM) that has just been received (corresponding to a SIP status code).
SS7ネットワークでのRELメッセージの使用は非常に一般的ですが、SIPにはまとめてRELと同じ役割を果たす、BYE、CANCEL、およびさまざまなステータス/応答コードなどの特定のツールがいくつかあります。 RELを送信して、すでに進行中のコールを切断する（BYE）、以前に送信した未完了のコールセットアップ要求をキャンセルする（CANCEL）、または完了したばかりのコールセットアップ要求を拒否する（IAM）受信されました（SIPステータスコードに対応）。
Note that it is not necessarily appropriate to map some ISDN cause codes to SIP messages because these cause codes are only meaningful to the ISUP interface of a gateway. A good example of this is cause code 44 "Request circuit or channel not available." 44 signifies that the CIC for which an IAM had been sent was believed by the receiving equipment to be in a state incompatible with a new call request - however, the appropriate behavior in this case is for the originating switch to re-send the IAM for a different CIC, not for the call to be torn down. Clearly, there is not (nor should there be) an SIP status code indicating that a new CIC should be selected - this matter is internal to the originating gateway. Hence receipt of cause code 44 should not result in any SIP status code being sent; effectively, the cause code is untranslatable.
一部のISDN原因コードをSIPメッセージにマップすることは必ずしも適切ではないことに注意してください。これらの原因コードはゲートウェイのISUPインターフェイスに対してのみ意味があるためです。この良い例は、原因コード44「要求回路またはチャネルが利用できない」です。 44は、IAMが送信されたCICが受信機器によって新しい呼び出し要求と互換性のない状態にあると信じられていたことを示します-ただし、この場合の適切な動作は、発信元スイッチがIAMを再送信することです。別のCIC。コールが取り壊されるのではありません。明らかに、新しいCICを選択する必要があることを示すSIPステータスコードはありません（あるはずもありません）。これは発信元ゲートウェイの内部にあります。したがって、原因コード44を受信しても、SIPステータスコードが送信されることはありません。事実上、原因コードは翻訳不可能です。
If a cause value other than those listed below is received, the default response '500 Server internal error' SHOULD be used.
下記以外の原因値を受け取った場合、デフォルトの応答「500サーバー内部エラー」を使用する必要があります（SHOULD）。
Finally, in addition to the ISDN Cause Code, the CAI parameter also contains a cause 'location' that gives some sense of which entity in the network was responsible for terminating the call (the most important distinction being between the user and the network). In most cases, the cause location does not affect the mapping to a SIP status code; some exceptions are noted below. A diagnostic field may also be present for some ISDN causes; this diagnostic will contain additional data pertaining to the termination of the call.
最後に、ISDN原因コードに加えて、CAIパラメータには、ネットワーク内のどのエンティティがコールの終了を担当したかを示す原因「場所」も含まれます（ユーザーとネットワークの最も重要な区別）。ほとんどの場合、原因の場所はSIPステータスコードへのマッピングに影響しません。いくつかの例外を以下に示します。 ISDNの原因によっては、診断フィールドが存在する場合もあります。この診断には、通話の終了に関する追加データが含まれます。
The following mapping values are RECOMMENDED:
次のマッピング値をお勧めします。
Normal event
通常のイベント
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing --- (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable
(*) ISDN Cause 16 will usually result in a BYE or CANCEL
（*）ISDN原因16は通常BYEまたはCANCELになります。
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603)
（+）原因の場所が「ユーザー」の場合、4xxコードではなく6xxコードを指定できます（つまり、403は603になります）。
(=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 'misrouted ported number'. Presumably, a number portability dip should have been performed by a prior network. Otherwise cause 26 is usually not used in ISUP procedures.
（=）ANSI手順-ANSIネットワークでは、26が過負荷になり、「誤ってルーティングされたポート番号」を示します。おそらく、以前のネットワークでは番号の移植性の低下があったはずです。それ以外の場合、原因26は通常ISUP手順では使用されません。
A REL with ISDN cause 22 (number changed) might contain information about a new number where the callee might be reachable in the diagnostic field. If the MGC is able to process this information it SHOULD be added to the SIP response (301) in a Contact header.
ISDN原因22（番号が変更された）のRELには、診断フィールドで呼び出し先に到達できる新しい番号に関する情報が含まれている場合があります。 MGCがこの情報を処理できる場合は、ContactヘッダーのSIP応答（301）に追加する必要があります（SHOULD）。
Resource unavailable
リソースを利用できません
This kind of cause value indicates a temporary failure. A 'Retry-After' header MAY be added to the response if appropriate.
この種類の原因値は、一時的な障害を示します。必要に応じて、 'Retry-After'ヘッダーを応答に追加してもよい（MAY）。
ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
47 resource unavailable 503 Service unavailable
Service or option not available
サービスまたはオプションは利用できません
This kind of cause value indicates that there is a problem with the request, rather than something that will resolve itself over time.
この種類の原因値は、時間の経過とともに解決するものではなく、要求に問題があることを示します。
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
available
Service or option not available
サービスまたはオプションは利用できません
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 488 Not Acceptable Here
70 only restricted digital avail 488 Not Acceptable Here
79 service or option not implemented 501 Not implemented
Invalid message
無効なメッセージ
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 403 Forbidden
88 incompatible destination 503 Service unavailable
Protocol error
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 504 Gateway timeout
111 protocol error 500 Server internal error
Interworking
インターワーキング
ISUP Cause value SIP response
---------------- ------------
127 interworking unspecified 500 Server internal error
An ACM message is sent in certain situations to indicate that the call is in progress in order to satisfy ISUP timers, rather than to signify that the callee is being alerted. This occurs for example in mobile networks, where roaming can delay call setup significantly. The early ACM is sent before the user is alerted to reset T7 and start T9. An ACM is considered an 'early ACM' if the Called Party's Status Indicator is set to 00 (no indication).
ACMメッセージは特定の状況で送信され、呼び出し先がアラートされていることを示すのではなく、ISUPタイマーを満たすために呼び出しが進行中であることを示します。これは、たとえばモバイルネットワークで発生し、ローミングによってコールのセットアップが大幅に遅延する可能性があります。初期のACMは、T7をリセットしてT9を開始するようユーザーに警告する前に送信されます。着信側のステータスインジケータが00（表示なし）に設定されている場合、ACMは「初期のACM」と見なされます。
After sending an early ACM, the ISUP network can be expected to indicate the further progress of the call by sending CPGs.
初期のACMを送信した後、ISUPネットワークはCPGを送信することにより、コールのさらなる進行を示すことが期待できます。
When an early ACM is received the gateway SHOULD send a 183 Session Progress response (see [1]) to the SIP network. In SIP bridging situations (where encapsulated ISUP was contained in the INVITE that initiated this call) the early ACM SHOULD also be included in the response body.
初期のACMを受信すると、ゲートウェイは183 Session Progress応答（[1]を参照）をSIPネットワークに送信する必要があります（SHOULD）。 SIPブリッジング状況（カプセル化されたISUPがこの呼び出しを開始したINVITEに含まれていた場合）では、初期のACMも応答本文に含める必要があります（SHOULD）。
Note that sending 183 before a gateway has confirmation that the address is complete (ACM) creates known problems in SIP bridging cases, and it SHOULD NOT therefore be sent.
ゲートウェイがアドレスの完了を確認する前に183を送信すると（ACM）、SIPブリッジングの場合に既知の問題が発生するため、送信しないでください。
Most commonly, on receipt of an ACM a provisional response (in the 18x class) SHOULD be sent to the SIP network. If the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP, then the ACM received by the gateway SHOULD be encapsulated in the provisional response.
最も一般的には、ACMの受信時に、暫定応答（18xクラス）をSIPネットワークに送信する必要があります（SHOULD）。このセッションを開始したINVITEに、正当でわかりやすいカプセル化されたISUPが含まれている場合、ゲートウェイによって受信されたACMは、暫定応答にカプセル化される必要があります（SHOULD）。
If the ACM contains a Backward Call Indicators parameter with a value of 'subscriber free', the gateway SHOULD send a '180 Ringing' response. When a 180 is sent, it is assumed, in the absence of any early media extension, that any necessary ringback tones will be generated locally by the SIP user agent to which the gateway is responding (which may in turn be a gateway).
ACMに「subscriber free」の値を持つBackward Call Indicatorsパラメータが含まれている場合、ゲートウェイは「180 Ringing」応答を送信する必要があります（SHOULD）。 180が送信されると、初期のメディア拡張がない場合、ゲートウェイが応答しているSIPユーザーエージェント（ゲートウェイの場合もあります）によって必要なリングバックトーンがローカルで生成されると想定されます。
If the Backward Call Indicators (BCI) parameter of the ACM indicates that interworking has been encountered (generally designating that the ISUP network sending the ACM is interworking with a less sophisticated network which cannot report its status via out-of-band signaling), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message, and if possible a backwards media transmission SHOULD be initiated. Backwards media SHOULD also be transmitted if the Optional Backward Call Indicators parameter field for in-band media is set. For more information on early media (before 200 OK/ANM) see Section 5.5. After early media transmission has been initiated, the gateway SHOULD send a 183 Session Progress response code.
ACMのBackward Call Indicators（BCI）パラメータがインターワーキングが発生したことを示している場合（一般に、ACMを送信するISUPネットワークが、帯域外シグナリングを介してそのステータスを報告できないより高度でないネットワークとインターワーキングしていることを示します）、可聴ビジートーンや発信者傍受メッセージなどの通話ステータスの帯域内アナウンスがあり、可能であれば逆方向メディア送信を開始する必要があります。インバンドメディアのオプションのBackward Call Indicatorsパラメータフィールドが設定されている場合は、逆方向メディアも送信する必要があります。初期のメディア（200 OK / ANMより前）の詳細については、セクション5.5を参照してください。初期のメディア送信が開始された後、ゲートウェイは183 Session Progress応答コードを送信する必要があります（SHOULD）。
Gateways MAY have some means of ascertaining the disposition of in-band audio media; for example, a way of determining by inspecting signaling in some ISUP variants, or by listening to the audio, that ringing, or a busy tone, is being played over the circuit. Such gateways MAY elect to discard the media and send the corresponding response code (such as 180 or 486) in its stead. However, the implementation of such a gateway would entail overcoming a number of known challenges that are outside the scope of this document.
ゲートウェイは、インバンドオーディオメディアの配置を確認するいくつかの手段を持つ場合があります。たとえば、一部のISUPバリアントのシグナリングを検査することによって、またはオーディオを聞くことによって、そのリンギングまたはビジートーンを回線上で再生していることを判別する方法です。そのようなゲートウェイは、メディアを破棄し、代わりに対応する応答コード（180や486など）を送信することを選択できます（MAY）。ただし、このようなゲートウェイの実装には、このドキュメントの範囲外である多くの既知の課題を克服する必要があります。
When they receive an ACM, switches in many ISUP networks start a timer known as "T9" which usually lasts between 90 seconds and 3 minutes (see [13]). When early media is being played, this timer permits the caller to hear backwards audio media (in the form ringback, tones or announcements) from a remote switch in the ISUP network for that period of time without incurring any charge for the connection. The nearest possible local ISUP exchange to the callee generates the ringback tone or voice announcements. If longer announcements have to be played, the network has to send an ANM, which initiates bidirectional media of indefinite duration. In common ISUP network practice, billing commences when the ANM is received. Some networks do not support timer T9.
多くのISUPネットワークのスイッチは、ACMを受信すると、「T9」と呼ばれるタイマーを開始します。このタイマーは通常、90秒から3分間持続します（[13]を参照）。初期のメディアが再生されている場合、このタイマーにより、発信者はISUPネットワーク内のリモートスイッチからその期間、オーディオメディアを（リングバック、トーン、またはアナウンスの形式で）逆方向に聞くことができます。呼び出し先に最も近い可能なローカルISUP交換は、リングバックトーンまたは音声アナウンスを生成します。より長いアナウンスを再生する必要がある場合、ネットワークはANMを送信する必要があります。これにより、無期限の双方向メディアが開始されます。一般的なISUPネットワークの慣例では、ANMを受信すると課金が開始されます。一部のネットワークはタイマーT9をサポートしていません。
When an ANM or CON message is received, the call has been answered and thus '200 OK' response SHOULD be sent to the SIP network. This 200 OK SHOULD contain an answer to the media offered in the INVITE. In SIP bridging situations (when the INVITE that initiated this call contained legitimate and comprehensible encapsulated ISUP), the ISUP message is included in the body of the 200 OK response. If it has not done so already, the gateway MUST establish a bidirectional media stream at this time.
ANMまたはCONメッセージが受信された場合、コールは応答されているため、「200 OK」応答をSIPネットワークに送信する必要があります。この200 OKには、INVITEで提供されるメディアへの回答を含める必要があります（SHOULD）。 SIPブリッジング状況（このコールを開始したINVITEに正当でわかりやすいカプセル化されたISUPが含まれていた場合）では、ISUPメッセージが200 OK応答の本文に含まれます。まだ行っていない場合、ゲートウェイはこの時点で双方向メディアストリームを確立する必要があります。
When there is interworking with some legacy networks, it is possible for an ISUP switch to receive an ANM immediately after an early ACM (without CPG or any other backwards messaging), or without receiving any ACM at all (when an automaton answers the call). In this situation the SIP user will never have received a 18x provisional response, and consequently they will not hear any kind of ringtone before the callee answers. This may result in some clipping of the initial forward media from the caller (since forward media transmission cannot commence until SDP has been acquired from the destination). In ISDN (see [12]) this is solved by connecting the voice path backwards before sending the IAM.
一部のレガシーネットワークとのインターワーキングがある場合、ISUPスイッチが初期のACMの直後に（CPGまたは他の逆方向メッセージングなしで）、またはACMをまったく受信せずに（オートマトンが呼び出しに応答するとき）、ANMを受信する可能性があります。この状況では、SIPユーザーは18xの暫定応答を受信することはなく、そのため、呼び出し先が応答する前に、いかなる種類の呼び出し音も聞こえません。これにより、発信者からの最初の転送メディアの一部がクリッピングされる可能性があります（転送メディア転送は、宛先からSDPが取得されるまで開始できないため）。 ISDN（[12]を参照）では、IAMを送信する前に音声パスを逆に接続することでこれを解決します。
The expiry of this timer (which is not used in all networks) signifies that an ANM has not arrived a significant period of time after alerting began (with the transmission of an ACM) for this call. Usually, this means that the callee's terminal has been alerted for many rings but has not been answered. It may also occur in interworking cases when the network is playing a status announcement (such as one indicating that a number is not in service) that has cycled several times. Whatever the cause of the protracted incomplete call, when this timer expires the call MUST be released. All of the gateway resources related to the media path SHOULD be released. A '480 Temporarily Unavailable' response code SHOULD be sent to the SIP network, and an REL message with cause value 19 (no answer from the user) SHOULD be sent to the ISUP network. The PSTN can be expected to respond with an RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
このタイマーの満了（すべてのネットワークで使用されているわけではありません）は、この呼び出しのアラートが（ACMの送信によって）開始された後、ANMがかなりの時間到着していないことを意味します。通常、これは、呼び出し先の端末に多くの呼び出し音が鳴ったが、応答がないことを意味します。また、ネットワークが数回循環するステータスアナウンス（番号が使用されていないことを示すものなど）を再生しているインターワーキングケースでも発生する可能性があります。このタイマーが時間切れになると、長期にわたる不完全な呼び出しの原因が何であれ、解放する必要があります。メディアパスに関連するすべてのゲートウェイリソースを解放する必要があります。 '480 Temporarily Unavailable'応答コードをSIPネットワークに送信する必要があり（SHOULD）、原因値19（ユーザーからの応答なし）のRELメッセージをISUPネットワークに送信する必要があります（SHOULD）。 PSTNは、RLCおよびSIPネットワークで応答して、解放シーケンスが完了したことを示すACKで応答することが期待できます。
A CPG is a provisional message that can indicate progress, alerting or in-band information. If a CPG suggests that in-band information is available, the gateway SHOULD begin to transmit early media and cut through the unidirectional backwards media path.
CPGは、進行状況、警告、またはインバンド情報を示すことができる暫定的なメッセージです。 CPGがインバンド情報が利用可能であることを示唆している場合、ゲートウェイは初期メディアの送信を開始し、単方向の逆方向メディアパスをカットする必要があります（SHOULD）。
In SIP bridging situations (when the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP), the CPG SHOULD be sent in the body of a particular 18x response, determined from the CPG Event Code as follows:
SIPブリッジング状況（このセッションを開始したINVITEに正当でわかりやすいカプセル化されたISUPが含まれていた場合）では、CPGは特定の18x応答の本文で送信される必要があり、次のようにCPGイベントコードから決定されます。
ISUP event code SIP response
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Session progress
3 In-band information 183 Session progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Session progress
Note that if the CPG does not indicate "Alerting," the current state will not change.
CPGが「警告」を示さない場合、現在の状態は変化しないことに注意してください。
At this stage, the call is fully connected and the conversation can take place. No ISUP message should be sent by the gateway when an ACK is received.
この段階で、通話は完全に接続されており、会話を行うことができます。 ACKを受信したときに、ゲートウェイからISUPメッセージを送信しないでください。
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the PSTN network. "100 Trying" acknowledgements to INVITE requests are not depicted, since their presence is optional.
次のコールフローは、PSTNネットワークから開始されたコールをセットアップする場合の、通常の成功およびエラーの場合のメッセージの順序を示しています。 INVITE要求に対する "100 Trying"確認は、その存在がオプションであるため、表示されていません。
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG".
これらの図では、すべてのコールシグナリング（SIP、ISUP）がMGCに出入りしています。メディア処理（オーディオカットスルー、トランク解放など）は、MGCの制御下でMGによって実行されています。簡単にするために、これらは「MGC / MG」というラベルの付いた単一のノードとして示されています。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、それを適切なSIPノードに送信します。
3. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.
3. コールに十分なアドレッシング情報があることを示すイベントが発生すると、SIPノードは180以上の暫定応答を生成します。
4. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message. If the response is not 180, the ACM will carry a "called party status" value of "no indication."
4. 180以上の暫定応答を受信すると、ゲートウェイはACMメッセージを生成します。応答が180でない場合、ACMは「着呼側ステータス」値「通知なし」を伝送します。
5. The SIP node may use further provisional messages to indicate session progress.
5. SIPノードは、追加の暫定メッセージを使用して、セッションの進行状況を示すことができます。
6. After an ACM has been sent, all provisional responses will translate into ISUP CPG messages as indicated in Section 8.2.3.
6. ACMが送信された後、セクション8.2.3に示すように、すべての暫定応答はISUP CPGメッセージに変換されます。
7. When the SIP node answers the call, it will send a 200 OK message.
7. SIPノードが通話に応答すると、200 OKメッセージが送信されます。
8. Upon receipt of the 200 OK message, the gateway will send an ANM message towards the ISUP node.
8. 200 OKメッセージを受信すると、ゲートウェイはISUPノードに向けてANMメッセージを送信します。
9. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
9. ゲートウェイは、SIPノードにACKを送信して、INVITE最終応答の受信を確認します。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message and sends it to an appropriate SIP node based on called number analysis.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、着信番号分析に基づいて適切なSIPノードに送信します。
3. Since the SIP node is set up to automatically answer the call, it will send a 200 OK message.
3. SIPノードは自動的に通話に応答するように設定されているため、200 OKメッセージを送信します。
4. Upon receipt of the 200 OK message, the gateway will send a CON message towards the ISUP node.
4. 200 OKメッセージを受信すると、ゲートウェイはCONメッセージをISUPノードに送信します。
5. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
5. ゲートウェイは、SIPノードにACKを送信して、INVITE最終応答の受信を確認します。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
6|<--------CANCEL-----------| |
| |<-----------RLC-----------|7
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis. The ISUP timer T11 and SIP timer T1 are set at this time.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、着信番号分析に基づいて適切なSIPノードに送信します。このとき、ISUPタイマーT11とSIPタイマーT1が設定されます。
3. The INVITE message will continue to be sent to the SIP node each time the timer T1 expires. The SIP standard specifies that INVITE transmission will be performed 7 times if no response is received.
3. タイマーT1が期限切れになるたびに、INVITEメッセージは引き続きSIPノードに送信されます。 SIP標準では、応答が受信されない場合、INVITE送信が7回実行されることが規定されています。
4. When T11 expires, an ACM message will be sent to the ISUP node to prevent the call from being torn down by the remote node's ISUP T7. This ACM contains a 'Called Party Status' value of 'no indication.'
4. T11が期限切れになると、ACMメッセージがISUPノードに送信され、リモートノードのISUP T7によってコールが切断されるのを防ぎます。このACMには、「表示なし」の「着信側ステータス」値が含まれています。
5. Once the maximum number of INVITE requests has been sent, the gateway will send a REL (cause code 18) to the ISUP node to terminate the call.
5. INVITE要求の最大数が送信されると、ゲートウェイはREL（原因コード18）をISUPノードに送信して、通話を終了します。
6. The gateway also sends a CANCEL message to the SIP node to terminate any initiation attempts.
6. ゲートウェイはまた、CANCELメッセージをSIPノードに送信して、開始試行を終了します。
7. Upon receipt of the REL, the remote ISUP node will send an RLC to acknowledge.
7. RELを受信すると、リモートISUPノードはRLCを送信して確認します。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis. The ISUP timer T11 and SIP timer T1 are set at this time.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、着信番号分析に基づいて適切なSIPノードに送信します。このとき、ISUPタイマーT11とSIPタイマーT1が設定されます。
3. The INVITE message will continue to be sent to the SIP node each time the timer T1 expires. The SIP standard specifies that INVITE transmission will be performed 7 times if no response is received. Since SIP T1 starts at 1/2 second or more and doubles each time it is retransmitted, it will be at least a minute before SIP times out the INVITE request; since SIP T1 is allowed to be larger than 500 ms initially, it is possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP T9.
3. タイマーT1が期限切れになるたびに、INVITEメッセージは引き続きSIPノードに送信されます。 SIP標準では、応答が受信されない場合、INVITE送信が7回実行されることが規定されています。 SIP T1は1/2秒以上で開始し、再送信されるたびに2倍になるため、SIPがINVITE要求をタイムアウトするまでに少なくとも1分かかります。 SIP T1は最初は500ミリ秒を超えることが許可されているため、7 x SIP T1がISUP T11 + ISUP T9よりも長くなる可能性があります。
4. When T11 expires, an ACM message will be sent to the ISUP node to prevent the call from being torn down by the remote node's ISUP T7. This ACM contains a 'Called Party Status' value of 'no indication.'
4. T11が期限切れになると、ACMメッセージがISUPノードに送信され、リモートノードのISUP T7によってコールが切断されるのを防ぎます。このACMには、「表示なし」の「着信側ステータス」値が含まれています。
5. When ISUP T9 in the remote PSTN node expires, it will send a REL.
5. リモートPSTNノードのISUP T9が期限切れになると、RELを送信します。
6. Upon receipt of the REL, the gateway will send an RLC to acknowledge.
6. RELを受信すると、ゲートウェイはRLCを送信して確認します。
7. The REL will trigger a CANCEL request, which gets sent to the SIP node.
7. RELはCANCEL要求をトリガーし、SIPノードに送信されます。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、着信番号分析に基づいて適切なSIPノードに送信します。
3. The SIP node indicates an error condition by replying with a response with a code of 400 or greater.
3. SIPノードは、コード400以上の応答で応答することにより、エラー状態を示します。
4. The gateway sends an ACK message to acknowledge receipt of the INVITE final response.
4. ゲートウェイは、ACKメッセージを送信して、INVITE最終応答の受信を確認します。
5. An ISUP REL message is generated from the SIP code, as specified in Section 8.2.6.1.
5. ISUP RELメッセージは、8.2.6.1項で指定されているように、SIPコードから生成されます。
6. The remote ISUP node confirms receipt of the REL message with an RLC message.
6. リモートISUPノードは、RLCメッセージでRELメッセージの受信を確認します。
SIP node 1 MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP node 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、着信番号分析に基づいて適切なSIPノードに送信します。
3. The SIP node indicates that the resource which the user is attempting to contact is at a different location by sending a 3xx message. In this instance we assume the Contact URL specifies a valid URL reachable by a VoIP SIP call.
3. SIPノードは、3xxメッセージを送信して、ユーザーが接続しようとしているリソースが別の場所にあることを示します。この例では、連絡先URLがVoIP SIPコールで到達可能な有効なURLを指定していると想定しています。
4. The gateway sends a CPG with event indication that the call is being forwarded upon receipt of the 3xx message. Note that this translation should be able to be disabled by configuration, as some ISUP nodes do not support receipt of CPG messages before ACM messages.
4. ゲートウェイは、3xxメッセージの受信時にコールが転送されているというイベントを示すCPGを送信します。一部のISUPノードはACMメッセージの前のCPGメッセージの受信をサポートしていないため、この変換は構成によって無効にできるはずです。
5. The gateway acknowledges receipt of the INVITE final response by sending an ACK message to the SIP node.
5. ゲートウェイは、ACKメッセージをSIPノードに送信することにより、INVITE最終応答の受信を確認します。
6. The gateway re-sends the INVITE message to the address indicated in the Contact: field of the 3xx message.
6. ゲートウェイは、3xxメッセージのContact：フィールドに示されているアドレスにINVITEメッセージを再送信します。
7. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.
7. コールに十分なアドレッシング情報があることを示すイベントが発生すると、SIPノードは180以上の暫定応答を生成します。
8. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message with an event code as indicated in Section 8.2.3.
8. ゲートウェイは、180以上の暫定応答を受信すると、セクション8.2.3に示すように、イベントコードを含むACMメッセージを生成します。
9. When the SIP node answers the call, it will send a 200 OK message.
9. SIPノードが通話に応答すると、200 OKメッセージが送信されます。
10. Upon receipt of the 200 OK message, the gateway will send an ANM message towards the ISUP node.
10. 200 OKメッセージを受信すると、ゲートウェイはISUPノードに向けてANMメッセージを送信します。
11. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
11. ゲートウェイは、SIPノードにACKを送信して、INVITE最終応答の受信を確認します。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the PSTN network generates an IAM message towards the gateway.
1. PSTNユーザーがSIPユーザーとのセッションを開始する場合、PSTNネットワークはゲートウェイに向けてIAMメッセージを生成します。
2. Upon receipt of the IAM message, the gateway generates an INVITE message, and sends it to an appropriate SIP node based on called number analysis.
2. IAMメッセージを受信すると、ゲートウェイはINVITEメッセージを生成し、着信番号分析に基づいて適切なSIPノードに送信します。
3. When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater.
3. コールに十分なアドレッシング情報があることを示すイベントが発生すると、SIPノードは180以上の暫定応答を生成します。
4. Upon receipt of a provisional response of 180 or greater, the gateway will generate an ACM message with an event code as indicated in Section 8.2.3.
4. ゲートウェイは、180以上の暫定応答を受信すると、セクション8.2.3に示すように、イベントコードを含むACMメッセージを生成します。
5. If the calling party hangs up before the SIP node answers the call, a REL message will be generated.
5. SIPノードがコールに応答する前に発呼者が電話を切ると、RELメッセージが生成されます。
6. The gateway frees the PSTN circuit and indicates that it is available for reuse by sending an RLC.
6. ゲートウェイはPSTN回線を解放し、RLCを送信して再利用できることを示します。
7. Upon receipt of a REL message before an INVITE final response, the gateway will send a CANCEL towards the SIP node.
7. INVITE最終応答の前にRELメッセージを受信すると、ゲートウェイはCANCELをSIPノードに送信します。
8. Upon receipt of the CANCEL, the SIP node will send a 200 response.
8. CANCELを受信すると、SIPノードは200応答を送信します。
9. The remote SIP node will send a "487 Call Cancelled" to complete the INVITE transaction.
9. リモートSIPノードは「487 Call Cancelled」を送信して、INVITEトランザクションを完了します。
10. The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response.
10. ゲートウェイは、SIPノードにACKを送信して、INVITE最終応答の受信を確認します。
Note that REL may arrive in any state. Whenever this occurs, the actions in section Section 8.2.7. are taken. Not all of these transitions are shown in this diagram.
RELはどの状態でも到着する可能性があることに注意してください。これが発生するときはいつでも、セクション8.2.7のアクション。取られます。これらの遷移のすべてがこの図に示されているわけではありません。
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | IAM/7.2.1 |
| V |
| REL/7.2.7 +-------------------------+ 400+/7.2.6 |
+<----------------+ Trying |------------>|
| +-+--------+------+-------+ |
| | | | |
| | T11/ | 18x/ | 200/ |
| | 7.2.8 |7.2.3 | 7.2.4 |
| V | | |
| REL/7.2.7 +--------------+ | | 400+/7.2.6 |
|<----------| Progressing |-|------|-------------------->|
| +--+----+------+ | | |
| | | | | |
| 200/ | | 18x/ | | |
| 7.2.4 | | 7.2.3 | | |
| | V V | |
| REL/7.2.7 | +---------------+ | 400+/7.2.6 |
|<-------------|--| Alerting |-|-------------------->|
| | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.2.4 | |
| V V V |
| BYE/9.1 +-----------------------------+ REL/9.2 |
+<------------+ Connected +------------>+
+-----------------------------+
Upon receipt of an IAM, the gateway SHOULD reserve appropriate internal resources (Digital Signal Processors - DSPs - and the like) necessary for handling the IP side of the call. It MAY make any necessary preparations to connect audio in the backwards direction (towards the caller).
IAMを受信すると、ゲートウェイは、コールのIP側を処理するために必要な適切な内部リソース（デジタルシグナルプロセッサ-DSPなど）を予約する必要があります（SHOULD）。音声を逆方向（発信者の方向）に接続するために必要な準備を行う場合があります。
When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message MUST be created for transmission to the SIP network. This section details the process by which a gateway populates the fields of the INVITE based on parameters found within the IAM.
IAMがPSTN-SIPゲートウェイに到着すると、SIPネットワークへの送信用にSIP INVITEメッセージを作成する必要があります。このセクションでは、IAM内で見つかったパラメーターに基づいて、ゲートウェイがINVITEのフィールドに入力するプロセスについて詳しく説明します。
The context of the call setup request read by the gateway in the IAM will be mapped primarily to two URIs in the INVITE, one representing the originator of the session and the other its destination. The former will always appear in the From header (after it has been converted from ISUP format by the procedure described in Section 12), and the latter is almost always used for both the To header and the Request-URI.
IAMのゲートウェイによって読み取られたコールセットアップリクエストのコンテキストは、主にINVITEの2つのURIにマップされます。1つはセッションの発信者を表し、もう1つはその宛先を表します。前者は常にFromヘッダーに表示され（セクション12で説明されている手順でISUP形式から変換された後）、後者はほとんどの場合、ToヘッダーとRequest-URIの両方に使用されます。
Once the address of the called party number has been read from the IAM, it SHOULD be translated into a destination tel URL that will serve as the Request-URI of the INVITE. Alternatively, a gateway MAY first attempt a Telephone Number Mapping (ENUM) [8] query to resolve the called party number to a URI. Some additional ISUP fields MAY be added to the tel URL after translation has been completed, namely:
着番号のアドレスがIAMから読み取られると、INVITEのRequest-URIとして機能する宛先tel URLに変換する必要があります（SHOULD）。あるいは、ゲートウェイは、最初に電話番号マッピング（ENUM）[8]クエリを試行して、着番号をURIに解決する場合があります。変換が完了した後、いくつかの追加のISUPフィールドが電話URLに追加される場合があります。
o If the gateway supports carrier-based routing (which is optional in this specification), it SHOULD ascertain if either the CIP (in ANSI networks) or TNS parameter is present in the IAM. If a value is present, the CIC SHOULD be extracted from the given parameter and analyzed by the gateway. A 'cic=' field with the value of the CIC SHOULD be appended to the destination tel URL, if doing so is in keeping with local policy (i.e., provided that the CIC does not indicate the network which owns the gateway or some similar condition). Note that if it is created, the 'cic=' parameter MUST be prefixed with the country code used or implied in the called party number, so that CIC '5062' becomes, in the United States, '+1-5062'. For further information on the 'cic=' tel URL field see [21].
o ゲートウェイがキャリアベースのルーティング（この仕様ではオプション）をサポートしている場合は、IAMにCIP（ANSIネットワーク内）またはTNSパラメータが存在するかどうかを確認する必要があります（SHOULD）。値が存在する場合、CICは指定されたパラメーターから抽出され、ゲートウェイによって分析される必要があります（SHOULD）。 CICの値を含む「cic =」フィールドは、ローカルのポリシーに準拠している場合（つまり、CICがゲートウェイを所有するネットワークまたは同様の条件を示していない場合）、宛先tel URLに追加する必要があります（SHOULD） ）。作成される場合、「cic =」パラメーターには、使用されるか、または着信側番号で暗黙的に指定された国コードをプレフィックスとして付ける必要があるため、CIC「5062」は米国では「+ 1-5062」になります。 'cic =' tel URLフィールドの詳細については、[21]を参照してください。
o If the gateway supports number portability-based routing (which is optional in this specification), then the gateway will need to look at a few other fields. To correctly map the FCI 'number translated' bit indicating that an LNP dip had been performed in the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL. If a GAP is present in the IAM, then the contents of the CPN (the Location Routing Number - LRN) SHOULD be translated from ISUP format (as described in Section 12) and copied into an 'rn=' field which must be appended to the tel URL, whereas the GAP itself should be translated to ISUP format and used to populate the primary telephone number field of the tel URL. Note that in some national numbering plans, both the LRN and the dialed number may be stored in the CPN parameter, in which case they must be separated out into different fields to be stored in the tel URL. Note that LRNs are necessarily national in scope, and consequently they MUST NOT be preceded by a '+' in the 'rn=' field. For further information on these tel URL fields see [21].
oゲートウェイが番号ポータビリティベースのルーティング（この仕様ではオプション）をサポートしている場合、ゲートウェイは他のいくつかのフィールドを調べる必要があります。 LTNディップがPSTNで実行されたことを示すFCIの「番号変換」ビットを正しくマップするには、「npdi = yes」フィールドを電話のURLに追加する必要があります（SHOULD）。 IAMにGAPが存在する場合は、CPN（ロケーションルーティング番号-LRN）の内容をISUP形式から変換し（セクション12で説明）、追加する必要がある 'rn ='フィールドにコピーする必要があります（SHOULD）。 telURL。GAP自体はISUP形式に変換され、tel URLの主要な電話番号フィールドに入力するために使用されます。一部の国の番号計画では、LRNとダイヤル番号の両方がCPNパラメータに格納される場合があることに注意してください。この場合、tel URLに格納するには、それらを異なるフィールドに分離する必要があります。 LRNのスコープは必ずしも国別であるため、「RN =」フィールドの「+」を前に付けてはならないことに注意してください。これらのtel URLフィールドの詳細については、[21]を参照してください。
In most cases, the resulting destination tel URL SHOULD be used in both the To field and Request-URI sent by the gateway. However, if the OCN parameter is present in the IAM, the To field SHOULD be constructed from the translation (from ISUP format following Section 12 of the OCN parameter, and hence the Request-URI and To field MAY be different.
ほとんどの場合、結果の宛先tel URLは、ゲートウェイによって送信されるToフィールドとRequest-URIの両方で使用する必要があります（SHOULD）。ただし、OCNパラメーターがIAMに存在する場合、Toフィールドは変換から構築する必要があります（OCNパラメーターのセクション12に続くISUPフォーマットから）。したがって、Request-URIとToフィールドは異なる場合があります。
The construction of the From header field is dependent on the presence of a CIN parameter. If the CIN is not present, then the gateway SHOULD create a dummy From header field containing a SIP URI without a user portion which communicates only the hostname of the gateway (e.g., 'sip:gw.sipcarrier.com). If the CIN is available, then it SHOULD be translated (in accordance with the procedure described above) into a tel URL which should populate the From header field. In either case, local policy or requests for presentation restriction (see Section 12.1) MAY result in a different value for the From header field.
Fromヘッダーフィールドの構成は、CINパラメータの存在に依存します。 CINが存在しない場合、ゲートウェイは、ゲートウェイのホスト名（例： 'sip：gw.sipcarrier.com）のみを通信するユーザー部分のないSIP URIを含むダミーのFromヘッダーフィールドを作成する必要があります（SHOULD）。 CINが利用可能な場合、（上記の手順に従って）Fromヘッダーフィールドに入力するtel URLに変換する必要があります（SHOULD）。どちらの場合も、ローカルポリシーまたはプレゼンテーション制限のリクエスト（セクション12.1を参照）により、Fromヘッダーフィールドの値が異なる場合があります。
A 100 response SHOULD NOT trigger any PSTN interworking messages; it only serves the purpose of suppressing INVITE retransmissions.
100応答は、PSTNインターワーキングメッセージをトリガーしてはなりません（SHOULD NOT）。これは、INVITEの再送信を抑制する目的でのみ使用されます。
Upon receipt of a 18x provisional response, if no ACM has been sent and no legitimate and comprehensible ISUP is present in the 18x message body, then the ISUP message SHOULD be generated according to the following table. Note that if an early ACM is sent, the call MUST enter state "Progressing" instead of state "Alerting."
18x暫定応答の受信時に、ACMが送信されておらず、18xメッセージ本文に正当でわかりやすいISUPが存在しない場合、次の表に従ってISUPメッセージを生成する必要があります（SHOULD）。初期のACMが送信された場合、コールは「Alerting」状態ではなく「Progressing」状態に入る必要があることに注意してください。
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing ACM (BCI = subscriber free)
181 Call is being forwarded Early ACM and CPG, event=6
182 Queued ACM (BCI = no indication)
183 Session progress message ACM (BCI = no indication)
If an ACM has already been sent and no ISUP is present in the 18x
message body, an ISUP message SHOULD be generated according to the
following table.
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing CPG, event = 1 (Alerting)
181 Call is being forwarded CPG, event = 6 (Forwarding)
182 Queued CPG, event = 2 (Progress)
183 Session progress message CPG, event = 2 (Progress)
Upon receipt of a 180 response, the gateway SHOULD generate the ringback tone to be heard by the caller on the PSTN side (unless the gateway knows that ringback will be provided by the network on the PSTN side).
180応答を受信すると、ゲートウェイはPSTN側の発信者が聞くリングバックトーンを生成する必要があります（ゲートウェイがPSTN側のネットワークによってリングバックが提供されることを認識していない場合）。
Note however that a gateway might receive media at any time after it has transmitted an SDP offer that it has sent in an INVITE, even before a 18x provisional response is received. Therefore the gateway MUST be prepared to play this media to the caller on the PSTN side (if necessary, ceasing any ringback tone that it may have begun to generate and then playing media). Note that the gateway may also receive SDP offers in responses for an early media session using some SIP extension, see Section 5.5. If a gateway receives a 183 response while it is playing backwards media, then when it generates a mapping for this response, if no encapsulated ISUP is present, the gateway SHOULD indicate that in-band information is available (for example, with the Event Information parameter of the CPG message or the Optional Backward Call Indicators parameter of the ACM).
ただし、ゲートウェイは、INVITEで送信したSDPオファーを送信した後、18x暫定応答を受信する前であっても、いつでもメディアを受信する可能性があることに注意してください。したがって、ゲートウェイは、PSTN側の発信者に対してこのメディアを再生できるように準備する必要があります（必要に応じて、生成し始めた可能性のあるリングバックトーンを停止してからメディアを再生します）。ゲートウェイは、一部のSIP拡張を使用した初期メディアセッションの応答でSDPオファーを受信する場合もあります。セクション5.5を参照してください。メディアを逆方向に再生しているときにゲートウェイが183応答を受信した場合、この応答のマッピングを生成するときに、カプセル化されたISUPが存在しない場合、ゲートウェイは帯域内情報が利用可能であることを示す必要があります（たとえば、イベント情報とともにCPGメッセージのパラメーターまたはACMのオプションの後方呼び出しインジケーターパラメーター）。
When an ACM is sent, the mandatory Backward Call Indicators parameter must be set, as well as any optional parameters as gateway policy dictates. If legitimate and comprehensible ISUP is present in the 18x response, the gateway SHOULD re-use the appropriate parameters of the ISUP message contained in the response body, including the value of the Backward Call Indicator parameter, as it formulates a message that it will send across its PSTN interface. In the absence of a usable encapsulated ACM, the BCI parameter SHOULD be set as follows: Message type: ACM
ACMを送信するときは、必須のBackward Call Indicatorsパラメータと、ゲートウェイポリシーで指定されているオプションのパラメータを設定する必要があります。 18x応答に正当でわかりやすいISUPが存在する場合、ゲートウェイは、送信するメッセージを定式化するときに、応答本文に含まれるISUPメッセージの適切なパラメーター（Backward Call Indicatorパラメーターの値を含む）を再利用する必要があります（SHOULD）。 PSTNインターフェイス全体。使用可能なカプセル化されたACMがない場合、BCIパラメータは次のように設定する必要があります（SHOULD）。メッセージタイプ：ACM
Backward Call Indicators Charge indicator: 10 charge Called party's status indicator: 01 subscriber free or 00 no indication Called party's category indicator: 01 ordinary subscriber End-to-end method indicator: 00 no end-to-end method Interworking indicator: 0 no interworking End-to-end information indicator: 0 no end-to-end info ISDN user part indicator: 1 ISUP used all the way Holding indicator: 0 no holding ISDN access indicator: 0 No ISDN access Echo control device indicator: It depends on the call SCCP method indicator: 00 no indication
バックワードコールインジケーターチャージインジケーター：10充電着信側のステータスインジケーター：01サブスクライバーフリーまたは00表示なし着信側のカテゴリインジケーター：01通常のサブスクライバーエンドツーエンドメソッドインジケーター：00エンドツーエンドメソッドインターワーキングインジケーターなし：0インターワーキングなしエンドツーエンド情報インジケーター：0エンドツーエンド情報なしISDNユーザーパーツインジケーター：1 ISUPはずっと使用されている保持インジケーター：0保持ISDNアクセスインジケーターがない：0 ISDNアクセスがないエコー制御デバイスインジケーター： SCCPメソッドインジケーターの呼び出し：00指示なし
Note that when the ISUP Backward Call Indicator parameter Interworking indicator field is set to 'interworking encountered', this indicates that ISDN is interworking with a network which is not capable of providing as many services as ISDN does. ISUP therefore may not employ certain features it otherwise normally uses. Gateway vendors MAY however provide a configurable option, usable at the discretion of service providers when they require additional ISUP services, that in the absence of encapsulated ISUP will signal in the BCI that interworking has been encountered, and that ISUP is not used all the way, for those operators that as a matter of policy would rather operate in this mode. For more information on the effects of interworking see Section 7.2.1.1.
ISUPバックワードコールインジケータパラメータのインターワーキングインジケータフィールドが「インターワーキングが発生しました」に設定されている場合、これは、ISDNがISDNほど多くのサービスを提供できないネットワークとインターワーキングしていることを示しています。したがって、ISUPは通常使用する特定の機能を使用しない場合があります。ただし、ゲートウェイベンダーは、追加のISUPサービスが必要な場合にサービスプロバイダーの裁量で使用できる構成可能なオプションを提供できます。カプセル化されたISUPがない場合、BCIでインターワーキングが発生し、ISUPが完全に使用されていないことを通知します。 、ポリシーの問題としてむしろこのモードで動作するそれらのオペレーターのために。インターワーキングの影響の詳細については、7.2.1.1項を参照してください。
Response received Message sent by the MGC
----------------- -----------------------
200 OK ANM, ACK
After receiving a 200 OK response the gateway MUST establish a directional media path in the gateway and send an ANM to the PSTN as well as an ACK to the SIP network.
200 OK応答を受信した後、ゲートウェイはゲートウェイに方向性メディアパスを確立し、ANMをPSTNに、ACKをSIPネットワークに送信する必要があります。
If the 200 OK response arrives before the gateway has sent an ACM, a CON is sent instead of the ANM, in those ISUP variants that support the CON message.
ゲートウェイがACMを送信する前に200 OK応答が到着した場合、CONメッセージをサポートするISUPバリアントでは、ANMの代わりにCONが送信されます。
When a legitimate and comprehensible ANM is encapsulated in the 200 OK response, the gateway SHOULD re-use any relevant ISUP parameters in the ANM it sends to the PSTN.
正当でわかりやすいANMが200 OK応答にカプセル化されると、ゲートウェイは、PSTNに送信するANM内の関連するISUPパラメータを再利用する必要があります（SHOULD）。
Note that gateways may sometimes receive 200 OK responses for requests other than INVITE (for example, those used in managing provisional responses, or the INFO method). The procedures described in this section apply only to 200 OK responses received as a result of sending an INVITE. The gateway SHOULD NOT send any PSTN messages if it receives a 200 OK in response to non-INVITE requests it has sent.
ゲートウェイは、INVITE以外の要求（たとえば、暫定応答やINFOメソッドの管理に使用される要求）に対して200 OK応答を受信する場合があることに注意してください。このセクションで説明する手順は、INVITEを送信した結果として受信された200 OK応答にのみ適用されます。ゲートウェイは、送信したINVITE以外の要求に応答して200 OKを受信した場合、PSTNメッセージを送信してはなりません（SHOULD NOT）。
When any 3xx response (a redirection) is received, the gateway SHOULD try to reach the destination by sending one or more new call setup requests using URIs found in any Contact header field(s) present in the response, as is mandated in the base SIP specification. Such 3xx responses are typically sent by a redirect server, and can be thought of as similar to a location register in mobile PSTN networks.
3xx応答（リダイレクト）が受信されると、ゲートウェイは、ベースに指定されているように、応答にあるContactヘッダーフィールドにあるURIを使用して1つ以上の新しいコールセットアップ要求を送信することにより、宛先に到達しようとします（SHOULD）。 SIP仕様。このような3xx応答は通常、リダイレクトサーバーによって送信され、モバイルPSTNネットワークのロケーションレジスタと同様に考えることができます。
If a particular URI presented in the Contact header of a 3xx is best reachable (according to the gateway's routing policies) via the PSTN, the gateway SHOULD send a new IAM and from that moment on act as a normal PSTN switch (no SIP involved) - usually this will be the case when the URI in the Contact header is a tel URL, one that the gateway cannot reach locally and one for which there is no ENUM mapping.
3xxのContactヘッダーに提示された特定のURIがPSTN経由で（ゲートウェイのルーティングポリシーに従って）最も到達可能である場合、ゲートウェイは新しいIAMを送信し、その瞬間から通常のPSTNスイッチとして機能します（SIPは含まれません）。 -通常、これは、ContactヘッダーのURIがtel URL、ゲートウェイがローカルに到達できないURI、およびENUMマッピングがないURIの場合です。
Alternatively, the gateway MAY send a REL message to the PSTN with a redirection indicator (23) and a diagnostic field corresponding to the telephone number in the URI. If, however, the new location is best reachable using SIP (if the URI in the Contact header contains no telephone number at all), the MGC SHOULD send a new INVITE with a Request-URI possibly a new IAM generated by the MGC in the message body.
あるいは、ゲートウェイは、リダイレクトインジケーター（23）とURIの電話番号に対応する診断フィールドを含むRELメッセージをPSTNに送信してもよい（MAY）。ただし、SIPを使用して新しい場所に最適に到達できる場合（ContactヘッダーのURIに電話番号がまったく含まれていない場合）、MGCはRequest-URIを使用して新しいINVITEを送信する必要があります。メッセージ本文。
While it is exploring a long list of Contact header fields with SIP requests, a gateway MAY send a CPG message with an event code of 6 (Forwarding) to the PSTN in order to indicate that the call is proceeding (where permitted by the ISUP variant in question).
SIPリクエストでContactヘッダーフィールドの長いリストを調査している間、ゲートウェイは、コールが進行中であることを示すために、イベントコード6（転送）のCPGメッセージをPSTNに送信できます（ISUPバリアントで許可されている場合）。問題）。
All redirection situations have to be treated very carefully because they involved special charging situations. In PSTN the caller typically pays for the first leg (to the gateway) and the callee pays the second (from the forwarding switch to the destination).
すべてのリダイレクト状況は、特別な課金状況に関係しているため、非常に注意深く処理する必要があります。 PSTNでは、通常、発信者は最初のレッグ（ゲートウェイへ）に対して支払い、着信者は2番目（転送スイッチから宛先へ）に支払います。
When a response code of 400 or greater is received by the gateway, then the INVITE previously sent by the gateway has been rejected. Under most circumstances the gateway SHOULD release the resources in the gateway, send a REL to the PSTN with a cause value and send an ACK to the SIP network. Some specific circumstances are identified below in which a gateway MAY attempt to rectify a SIP-specific problem communicated by a status code without releasing the call by retrying the request. When a REL is sent to the PSTN, the gateway expects the arrival of an RLC indicating that the release sequence is complete.
400以上の応答コードがゲートウェイによって受信された場合、ゲートウェイによって以前に送信されたINVITEは拒否されました。ほとんどの状況では、ゲートウェイはゲートウェイのリソースを解放する必要があり（SHOULD）、原因値を指定してRTNをPSTNに送信し、SIPネットワークにACKを送信します。ゲートウェイがリクエストを再試行することによってコールを解放することなくステータスコードによって伝えられたSIP固有の問題を修正しようと試みるかもしれないいくつかの特定の状況は以下に識別されます。 RELがPSTNに送信されると、ゲートウェイは、リリースシーケンスが完了したことを示すRLCの到着を予期します。
When a REL message is generated due to a SIP rejection response that contains an encapsulated REL message, the Cause Indicator (CAI) parameter in the generated REL SHOULD be set to the value of the CAI parameter received in the encapsulated REL. If no encapsulated ISUP is present, the mapping below between status code and cause codes are RECOMMENDED.
カプセル化されたRELメッセージを含むSIP拒否応答が原因でRELメッセージが生成された場合、生成されたRELの原因インジケーター（CAI）パラメーターは、カプセル化されたRELで受信したCAIパラメーターの値に設定する必要があります。カプセル化されたISUPが存在しない場合、ステータスコードと原因コード間の以下のマッピングが推奨されます。
Any SIP status codes not listed below (associated with SIP extensions, versions of SIP subsequent to the issue of this document, or simply omitted) should be mapping to cause code 31 "Normal, unspecified". These mappings cover only responses; note that the BYE and CANCEL requests, which are also used to tear down a dialog, SHOULD be mapped to 16 "Normal clearing" under most circumstances (although see Section 5.8).
以下にリストされていないSIPステータスコード（SIP拡張、このドキュメントの発行後のSIPのバージョンに関連付けられている、または単に省略されている）は、コード31「通常、未指定」を引き起こすようにマッピングする必要があります。これらのマッピングは応答のみをカバーします。ダイアログを破棄するためにも使用されるBYEリクエストとCANCELリクエストは、ほとんどの状況で16の「通常のクリア」にマップする必要があります（ただし、セクション5.8を参照）。
By default, the cause location associated with the CAI parameter should be encoded such that 6xx codes are given the location 'user', whereas 4xx and 5xx codes are given a 'network' location. Exceptions are marked below.
デフォルトでは、CAIパラメータに関連付けられた原因の場所は、6xxコードには「user」という場所が与えられ、4xxおよび5xxコードには「network」という場所が与えられるようにエンコードする必要があります。例外は以下に示されています。
Just as there are certain ISDN cause codes that are ISUP-specific and have no corollary SIP action, so there are SIP status codes that should not simply be translated to ISUP - some SIP-specific action should be attempted first. See the note on the (+) tag below.
ISUP固有で当然のSIPアクションがない特定のISDN原因コードがあるのと同じように、単にISUPに変換する必要のないSIPステータスコードがあります-一部のSIP固有のアクションを最初に試行する必要があります。以下の（+）タグの注記を参照してください。
Response received Cause value in the REL
----------------- ----------------------
400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented (+)
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
(w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
423 Interval Too Brief 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
481 Call/Transaction Does not Exist 41 Temporary Failure
482 Loop Detected 25 Exchange - routing error
483 Too many hops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
487 Request Terminated --- (no mapping)
488 Not Acceptable here --- by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 79 Not implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header
(*) In some cases, it may be possible for a SIP gateway to provide
credentials to the SIP UAS that is rejecting an INVITE due to
authorization failure. If the gateway can authenticate itself, then
obviously it SHOULD do so and proceed with the call; only if the
gateway cannot authenticate itself should cause code 21 be sent.
(+) If at all possible, a SIP gateway SHOULD respond to these protocol errors by remedying unacceptable behavior and attempting to re-originate the session. Only if this proves impossible should the SIP gateway fail the ISUP half of the call.
（+）可能な場合、SIPゲートウェイは、許容できない動作を修正し、セッションの再発信を試みることにより、これらのプロトコルエラーに応答する必要があります（SHOULD）。これが不可能であることが判明した場合にのみ、SIPゲートウェイはコールのISUPの半分に失敗します。
When the Warning header is present in a SIP 606 or 488 message, there may be specific ISDN cause code mappings appropriate to the Warning code. This document recommends that '31 Normal, unspecified' SHOULD by default be used for most currently assigned Warning codes. If the Warning code speaks to an unavailable bearer capability, cause code '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping.
警告ヘッダーがSIP 606または488メッセージに存在する場合、警告コードに適切な特定のISDN原因コードマッピングがある場合があります。このドキュメントでは、現在割り当てられているほとんどの警告コードに対して、デフォルトで「31通常、未指定」を使用することを推奨しています。警告コードが使用できないベアラ機能について話している場合、原因コード「65 Bearer Capability Not Implemented」は推奨されるマッピングです。
This circumstance generally arises when the user on the PSTN side hangs up before the call has been answered; the gateway therefore aborts the establishment of the session. A CANCEL request MUST be issued (a BYE is not used, since no final response has arrived from the SIP side). A 200 OK for the CANCEL can be expected by the gateway, and finally a 487 for the INVITE arrives (which the gateway ACKs in turn).
この状況は、通常、PSTN側のユーザーが通話に応答する前に電話を切ったときに発生します。したがって、ゲートウェイはセッションの確立を中止します。 CANCEL要求を発行する必要があります（SIP側から最終応答が到着していないため、BYEは使用されません）。ゲートウェイはCANCELに対して200 OKを期待でき、最後にINVITEに対して487が到着します（ゲートウェイは次にACKします）。
The gateway SHOULD store state information related to this dialog for a certain period of time, since a 200 final response for the INVITE originally sent might arrive (even after the reception of the 200 OK for the CANCEL). In this situation, the gateway MUST send an ACK followed by an appropriate BYE request.
ゲートウェイは、最初に送信されたINVITEの200最終応答が到着する可能性があるため（CANCELの200 OKの受信後も）、このダイアログに関連する状態情報を一定期間保存する必要があります（SHOULD）。この状況では、ゲートウェイはACKに続いて適切なBYE要求を送信する必要があります。
In SIP bridging situations, the REL message cannot be encapsulated in a CANCEL message (since CANCEL cannot have a message body). Usually, the REL message will contain a CAI value of 16 "Normal clearing". If the value is other than a 16, the gateway MAY wish to use some other means of communicating the cause value (see Section 5.8).
SIPブリッジング状況では、RELメッセージはCANCELメッセージにカプセル化できません（CANCELはメッセージ本文を持つことができないため）。通常、RELメッセージには、16の「通常のクリア」のCAI値が含まれます。値が16以外の場合、ゲートウェイは原因値を通信する他の手段を使用する場合があります（セクション5.8を参照）。
In order to prevent the remote ISUP node's timer T7 from expiring, the gateway MAY keep its own supervisory timer; ISUP defines this timer as T11. T11's duration is carefully chosen so that it will always be shorter than the T7 of any node to which the gateway is communicating.
リモートISUPノードのタイマーT7が期限切れにならないようにするために、ゲートウェイは独自の監視タイマーを保持する場合があります。 ISUPはこのタイマーをT11として定義します。 T11の期間は、ゲートウェイが通信しているどのノードのT7よりも常に短くなるように、慎重に選択されています。
To clarify timer T11's relevance with respect to SIP interworking, Q.764 [12] explains its use as: "If in normal operation, a delay in the receipt of an address complete signal from the succeeding network is expected, the last common channel signaling exchange will originate and send an address complete message 15 to 20 seconds [timer (T11)] after receiving the latest address message." Since SIP nodes have no obligation to respond to an INVITE request within 20 seconds, SIP interworking inarguably qualifies as such a situation.
SIPインターワーキングに関するタイマーT11の関連性を明確にするために、Q.764 [12]はその使用法を次のように説明しています。「通常の動作では、後続のネットワークからのアドレス完了信号の受信の遅延が予想されます。交換は発信され、最新のアドレスメッセージを受信してから15〜20秒[タイマー（T11）]でアドレス完了メッセージを送信します。」 SIPノードは20秒以内にINVITE要求に応答する義務がないので、SIPインターワーキングは間違いなくそのような状況に該当します。
If the gateway supports this optional mechanism, then if its T11 expires, it SHOULD send an early ACM (i.e., called party status set to "no indication") to prevent the expiration of the remote node's T7 (where permitted by the ISUP variant). See Section 8.2.3 for the value of the ACM parameters.
ゲートウェイがこのオプションのメカニズムをサポートしている場合、T11が期限切れになると、リモートノードのT7（ISUPバリアントで許可されている場合）の期限切れを防ぐために、早期のACM（つまり、「通知なし」に設定された着信側ステータス）を送信する必要があります（SHOULD）。 。 ACMパラメータの値については、セクション8.2.3を参照してください。
If a "180 Ringing" message arrives subsequently, it SHOULD be sent in a CPG, as shown in Section 8.2.3.
その後、「180 Ringing」メッセージが到着した場合は、セクション8.2.3に示すように、CPGで送信する必要があります（SHOULD）。
See Section 8.1.3 for an example callflow that includes the expiration of T11.
T11の有効期限を含むコールフローの例については、セクション8.1.3を参照してください。
In ISDN networks, a user can generate a SUS (timer T2, user initiated) in order to unplug the terminal from the socket and plug it in another one. A RES is sent once the terminal has been reconnected and the T2 timer has not expired. SUS is also frequently used to signaling an on-hook state for a remote terminal before timers leading to the transmission of a REL message are sent (this is the more common case by far). While a call is suspended, no audio media is passed end-to-end.
ISDNネットワークでは、ユーザーはSUS（タイマーT2、ユーザー開始）を生成して、端末をソケットから取り外し、別の端末に接続することができます。端末が再接続され、T2タイマーが満了していない場合は、RESが送信されます。 SUSは、RELメッセージの送信につながるタイマーが送信される前にリモート端末のオンフック状態を通知するためにも頻繁に使用されます（これははるかに一般的なケースです）。コールが一時停止されている間、オーディオメディアはエンドツーエンドで渡されません。
When a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received. Putting the media on hold insures that bandwidth is conserved when no audio traffic needs to be transmitted.
SIPレッグを持つコールに対してSUSが送信されると、ゲートウェイは、RESが受信されるまでIPメディア送信を一時停止する場合があります。メディアを保留にすると、オーディオトラフィックを送信する必要がないときに帯域幅が確実に節約されます。
If media suspension is appropriate, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to request that the far-end's transmission of the media stream be placed on hold. The subsequent reception of a RES from the PSTN SHOULD then trigger a re-INVITE that requests the resumption of the media stream. Note that the MGC may or may not elect to stop transmitting any media itself when it requests the cessation of far-end transmission.
メディアの一時停止が適切な場合、SUSがPSTNから到着すると、MGCはINVITEを送信して、メディアストリームの遠端の送信を保留にするように要求できます（MAY）。その後、PSTNからRESを受信すると、メディアストリームの再開を要求するre-INVITEがトリガーされる必要があります（SHOULD）。 MGCが遠端の送信の停止を要求したときに、MGCがメディア自体の送信を停止する場合としない場合があることに注意してください。
If media suspension is not required by the MGC receiving the SUS from the PSTN, the SIP INFO [6] method MAY be used to transmit an encapsulated SUS rather than a re-INVITE. Note that the recipient of such an INFO request may be a simple SIP phone that does not understand ISUP (and would therefore take no action on receipt of this message); if a prospective destination for an INFO-encapsulated SUS has not used encapsulated ISUP in any messages it has previously sent, the gateway SHOULD NOT relay the INFO method, but rather should handle the SUS and the corresponding RES without signaling their arrival to the SIP network.
PSTNからSUSを受信するMGCがメディアの一時停止を必要としない場合、SIP INFO [6]メソッドを使用して、re-INVITEではなくカプセル化されたSUSを送信できます。このようなINFOリクエストの受信者は、ISUPを理解しない単純なSIPフォンである可能性があることに注意してください（したがって、このメッセージの受信時にアクションを実行しません）。 INFOでカプセル化されたSUSの予想される宛先が、以前に送信したメッセージでカプセル化されたISUPを使用していない場合、ゲートウェイはINFOメソッドをリレーすべきではなく、SIPネットワークへの到着を通知せずにSUSと対応するRESを処理する必要があります。 。
In any case, subsequent RES messages MUST be transmitted in the same method that was used for the corresponding SUS (i.e., if an INFO is used for a SUS, INFO should also be used for the subsequent RES).
いずれの場合も、後続のRESメッセージは、対応するSUSに使用されたのと同じ方法で送信する必要があります（つまり、INFOがSUSに使用される場合、INFOは後続のRESにも使用される必要があります）。
Regardless of whether the INFO or re-INVITE mechanism is used to carry a SUS message, neither has any implication that the originating side will cease sending IP media. The recipient of an encapsulated SUS message MAY therefore elect to send a re-INVITE themselves to suspend media transmission from the MGC side if desired.
INFOまたはre-INVITEメカニズムを使用してSUSメッセージを伝送するかどうかに関係なく、発信側がIPメディアの送信を停止するという意味はありません。したがって、カプセル化されたSUSメッセージの受信者は、必要に応じて、MGC側からのメディア送信を一時停止するために、自分でre-INVITEを送信することを選択できます。
The following example uses the INVITE mechanism. Note that this flow is informative, not proscriptive; compliant gateways are free to implement functionally equivalent flows, as described in the preceding paragraphs.
次の例では、INVITEメカニズムを使用しています。このフローは有益ではなく、有益であることに注意してください。前の段落で説明したように、準拠ゲートウェイは機能的に同等のフローを自由に実装できます。
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
The handling of a network-initiated SUS immediately prior to call teardown is handled in Section 10.2.2.
コールティアダウンの直前のネットワーク起動SUSの処理は、セクション10.2.2で処理されます。
After a call has been connected, a re-INVITE could be sent to a gateway from the SIP side in order to place the call on hold. This re-INVITE will have an SDP offer indicating that the originator of the re-INVITE no longer wishes to receive media.
通話が接続された後、通話を保留にするために、SIP側からゲートウェイにre-INVITEを送信できます。このre-INVITEには、re-INVITEの発信者がメディアの受信を望まないことを示すSDPオファーがあります。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |
When such a re-INVITE is received, the gateway SHOULD send a CPG in order to express that the call has been placed on hold. The CPG SHOULD contain a Generic Notification Indicator (or, in ANSI networks, a Notification Indicator) with a value of 'remote hold'.
そのようなre-INVITEを受信すると、ゲートウェイは、コールが保留になったことを示すためにCPGを送信する必要があります（SHOULD）。 CPGは、「リモートホールド」の値を持つ汎用通知インジケーター（またはANSIネットワークでは通知インジケーター）を含む必要があります（SHOULD）。
If, subsequent to the sending of the re-INVITE, the SIP side wishes to take the remote end off hold and begin receiving media again, it SHOULD repeat the flow above with an INVITE that contains an SDP offer with an appropriate media destination. The Generic Notification Indicator would in this instance have a value of 'remote retrieval' (or in some variants 'remote hold released').
re-INVITEの送信に続いて、SIP側がリモートエンドの保留を解除してメディアの受信を再開したい場合は、適切なメディア宛先を持つSDPオファーを含むINVITEで上記のフローを繰り返す必要があります。この場合、汎用通知インジケーターの値は「リモート取得」（または一部のバリアントでは「リモート保留解除」）になります。
Finally, note that a CPG with hold indicators may be received by a gateway from the PSTN. In the interests of conserving bandwidth, the gateway SHOULD stop sending media until the call is resumed and SHOULD send a re-INVITE to the SIP leg of the call requesting that the remote side stop sending media.
最後に、ホールドインジケータを備えたCPGがゲートウェイによってPSTNから受信される可能性があることに注意してください。帯域幅を節約するために、ゲートウェイは、コールが再開されるまでメディアの送信を停止し（SHOULD）、リモート側がメディアの送信を停止するように要求するコールのSIPレッグにre-INVITEを送信する必要があります（SHOULD）。
From the perspective of a gateway, either the SIP side or the ISUP side can release a call, regardless of which side initiated the call. Note that cancellation of a call setup request (either from the ISUP or SIP side) is discussed elsewhere in this document (in Section 8.2.7 and Section 7.2.3, respectively).
ゲートウェイの観点から見ると、SIP側またはISUP側は、どちらの側が呼び出しを開始したかに関係なく、呼び出しを解放できます。 （ISUP側またはSIP側からの）コールセットアップ要求のキャンセルについては、このドキュメントの他の部分（それぞれセクション8.2.7およびセクション7.2.3）で説明します。
Gateways SHOULD implement functional equivalence with the flows in this section.
ゲートウェイは、このセクションのフローと同等の機能を実装する必要があります（SHOULD）。
For a normal termination of the dialog (receipt of a BYE request), the gateway MUST immediately send a 200 response. The gateway then MUST release any media resources in the gateway (DSPs, TCIC locks, and so on) and send an REL with a cause code of 16 (normal call clearing) to the PSTN. Release of resources is confirmed by the PSTN side with an RLC message.
ダイアログの正常終了（BYE要求の受信）の場合、ゲートウェイはすぐに200応答を送信する必要があります。次に、ゲートウェイはゲートウェイ内のメディアリソース（DSP、TCICロックなど）を解放し、原因コード16（通常のコールクリア）を含むRELをPSTNに送信する必要があります。リソースの解放は、RLCメッセージでPSTN側によって確認されます。
In SIP bridging situations, the cause code of any REL encapsulated in the BYE request SHOULD be re-used in any REL that the gateway sends to the PSTN.
SIPブリッジングの状況では、BYEリクエストにカプセル化されたRELの原因コードは、ゲートウェイがPSTNに送信するすべてのRELで再利用する必要があります（SHOULD）。
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
If the release of the connection was caused by the reception of a REL, the REL SHOULD be encapsulated in the BYE sent by the gateway. Whether the caller or callee hangs up first, the gateway SHOULD release any internal resources used in support of the call and then MUST confirm that the circuit is ready for re-use by sending an RLC.
接続の解放がRELの受信によって引き起こされた場合、RELはゲートウェイによって送信されるBYEにカプセル化される必要があります（SHOULD）。発信者と着信者のどちらが先に電話を切るかに関係なく、ゲートウェイは、呼び出しのサポートに使用されているすべての内部リソースを解放する必要があります（SHOULD）。次に、RLCを送信して、回線が再利用できる状態であることを確認する必要があります。
When the caller hangs up, the SIP dialog MUST be terminated by sending a BYE request (which is confirmed with a 200).
発信者が電話を切ると、SIPダイアログはBYEリクエスト（200で確認）を送信して終了する必要があります。
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
In some PSTN scenarios, if the callee hangs up in the middle of a call, the local exchange sends a SUS instead of a REL and starts a timer (T6, SUS is network initiated). When the timer expires, the REL is sent. This necessitates a slightly different SIP flow; see Section 9 for more information on handling suspension. It is RECOMMENDED that gateways implement functional equivalence with the following flow for this case:
一部のPSTNシナリオでは、呼び出し先が通話の途中で電話を切ると、ローカル交換機がRELではなくSUSを送信し、タイマーを開始します（T6、SUSはネットワークで開始されます）。タイマーが切れると、RELが送信されます。これには、わずかに異なるSIPフローが必要です。一時停止の処理の詳細については、セクション9を参照してください。この場合、ゲートウェイが次のフローと同等の機能を実装することをお勧めします。
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
ISUP contains a set of messages used for maintenance purposes. They can be received during any ongoing call. There are basically two kinds of maintenance messages (apart from the continuity check): messages for blocking circuits and messages for resetting circuits.
ISUPには、メンテナンス目的で使用されるメッセージのセットが含まれています。進行中の通話中に受信することができます。メンテナンスメッセージには、基本的に2つの種類があります（導通チェックを除く）。回路をブロックするメッセージと回路をリセットするメッセージです。
Upon reception of an RSC message for a circuit currently being used by the gateway for a call, the call MUST be released immediately (this typically results from a serious maintenance condition). RSC MUST be answered with an RLC after resetting the circuit in the gateway. Group reset (GRS) messages which target a range of circuits are answered with a Circuit Group Reset ACK Message (GRA) after resetting all the circuits affected by the message.
ゲートウェイが通話に現在使用している回線のRSCメッセージを受信すると、すぐに通話を解放する必要があります（これは通常、深刻なメンテナンス状態が原因です）。 RSCは、ゲートウェイの回線をリセットした後、RLCで応答する必要があります。一連の回線をターゲットとするグループリセット（GRS）メッセージは、メッセージの影響を受けるすべての回線をリセットした後、回線グループリセットACKメッセージ（GRA）で応答されます。
The gateways SHOULD behave as if a REL had been received in order to release the dialog on the SIP side. A BYE or a CANCEL are sent depending of the status of the call. See the procedures in Section 10.
ゲートウェイは、SIP側でダイアログを解放するためにRELを受信したかのように動作する必要があります（SHOULD）。 BYEまたはCANCELは、コールのステータスに応じて送信されます。セクション10の手順を参照してください。
There are two kinds of blocking messages: maintenance messages or hardware-failure messages. Maintenance blocking messages indicate that the circuit is to be blocked for any subsequent calls, but these messages do not affect any ongoing call. This allows circuits to be gradually quiesced and taken out of service for maintenance.
ブロッキングメッセージには、メンテナンスメッセージとハードウェア障害メッセージの2種類があります。メンテナンスブロッキングメッセージは、以降のコールで回線がブロックされることを示しますが、これらのメッセージは進行中のコールには影響しません。これにより、回路を徐々に休止し、メンテナンスのためにサービスを停止できます。
Hardware-oriented blocking messages have to be treated as reset messages. They generally are sent only when a hardware failure has occurred. Media transmission for all calls in progress on these circuits would be affected by this hardware condition, and therefore all calls must be released immediately.
ハードウェア指向のブロッキングメッセージは、リセットメッセージとして扱う必要があります。通常、ハードウェア障害が発生した場合にのみ送信されます。これらの回線で進行中のすべてのコールのメディア送信は、このハードウェアの状態の影響を受けるため、すべてのコールをすぐに解放する必要があります。
BLO is always maintenance oriented and it is answered by the gateway with a Blocking ACK Message (BLA) when the circuit is blocked - this requires no corresponding SIP actions. Circuit Group Blocking (CGB) messages have a "type indicator" inside the Circuit Group Supervision Message Type Indicator. It indicates if the CGB is maintenance or hardware failure oriented. If the CGB results from a hardware failure, then each call in progress in the affected range of circuits MUST be terminated immediately as if a REL had been received, following the procedures in Section 10. CGBs MUST be answered with CGBAs.
BLOは常にメンテナンス指向であり、回線がブロックされている場合、ゲートウェイはBlocking ACK Message（BLA）で応答します。これには、対応するSIPアクションは必要ありません。 Circuit Group Blocking（CGB）メッセージには、Circuit Group Supervisionメッセージタイプインジケータ内に「タイプインジケータ」があります。これは、CGBが保守向けかハードウェア障害向けかを示します。 CGBがハードウェア障害の結果である場合、影響を受ける回線の範囲で進行中の各コールは、RELが受信されたかのように、セクション10の手順に従ってただちに終了する必要があります。CGBはCGBAで応答する必要があります。
A continuity check is a test performed on a circuit that involves the reflection of a tone generated at the originating switch by a loopback at the destination switch. Two variants of the continuity check appear in ISUP: the implicit continuity check request within an IAM (in which case the continuity check takes place as a precondition before call setup begins), and the explicit continuity check signaled by a Continuity Check Request (CCR) message. PSTN gateways in regions that support continuity checking generally SHOULD have some way of accommodating these tests (if they hope to be fielded by providers that interconnect with any major carrier).
導通チェックは、宛先スイッチでのループバックによって発信スイッチで生成されたトーンの反射を含む回路で実行されるテストです。 ISUPには、連続性チェックの2つのバリアントが表示されます。IAM内の暗黙的な連続性チェックリクエスト（この場合、連続性チェックは、コールセットアップが始まる前の前提条件として行われます）と、連続性チェックリクエスト（CCR）によって通知される明示的な連続性チェックです。メッセージ。継続性チェックをサポートする地域のPSTNゲートウェイは、通常、これらのテストに対応する方法を備えている必要があります（主要な通信事業者と相互接続するプロバイダーによって実行されることを望む場合）。
When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT send any corresponding SIP messages; the scope of the continuity check applies only to the PSTN trunks, not to any IP media paths beyond the gateway. CCR messages also do not designate any called party number, or any other way to determine what SIP user agent server should be reached.
CCRがPSTN-SIPゲートウェイによって受信されると、ゲートウェイは対応するSIPメッセージを送信してはなりません（SHOULD NOT）。導通チェックの範囲はPSTNトランクにのみ適用され、ゲートウェイを越えたIPメディアパスには適用されません。 CCRメッセージは、着呼側番号や、どのSIPユーザーエージェントサーバーに到達する必要があるかを決定する他の方法も指定しません。
When an IAM with the Continuity Check Indicator flag set within the NCI parameter is received, the gateway MUST process the continuity check before sending an INVITE message (and proceeding normally with call setup); if the continuity check fails (a COT with Continuity Indicator of 'failed' is received), then an INVITE MUST NOT be sent.
NCIパラメーター内で設定された継続性チェックインジケーターフラグを持つIAMを受信した場合、ゲートウェイは、INVITEメッセージを送信する前に継続性チェックを処理する必要があります（そして、コールセットアップを通常どおり続行します）。導通チェックが失敗した場合（「Continuity Indicator」が「failed」であるCOTを受信した場合）、INVITEを送信してはなりません（MUST NOT）。
SIP proxy servers MAY route SIP messages on any signaling criteria desired by network administrators, but generally the Request-URI is the foremost routing criterion. The To and From headers are also frequently of interest in making routing decisions. SIP-ISUP mapping assumes that proxy servers are interested in at least these three fields of SIP messages, all of which contain URIs.
SIPプロキシサーバーは、ネットワーク管理者が希望する任意のシグナリング基準でSIPメッセージをルーティングできますが、通常、Request-URIが最も重要なルーティング基準です。 ToヘッダーとFromヘッダーも、ルーティングを決定する際に頻繁に使用されます。 SIP-ISUPマッピングは、プロキシサーバーが少なくともURIを含むSIPメッセージのこれら3つのフィールドに関心があることを前提としています。
SIP-ISUP mapping frequently requires the representation of telephone numbers in these URIs. In some instances these numbers will be presented first in ISUP messages, and SS7-SIP gateways will need to translate the ISUP formats of these numbers into SIP URIs. In other cases the reverse transformation will be required.
SIP-ISUPマッピングでは、これらのURIでの電話番号の表現が必要になることがよくあります。場合によっては、これらの番号はISUPメッセージで最初に提示され、SS7-SIPゲートウェイはこれらの番号のISUP形式をSIP URIに変換する必要があります。他の場合には、逆変換が必要になります。
The most common format used in SIP for the representation of telephone numbers is the tel URL [7]. When converting between formats, the tel URL MAY constitute the entirety of a URI field in a SIP message, or it MAY appear as the user portion of a SIP URI. For example, a To field might appear as:
SIPで電話番号の表現に使用される最も一般的な形式は、tel URL [7]です。形式間で変換する場合、tel URLはSIPメッセージのURIフィールド全体を構成する場合があります。または、SIP URIのユーザー部分として表示される場合があります。たとえば、[宛先]フィールドは次のように表示されます。
To: tel:+17208881000
Or
または
To: sip:+17208881000@level3.com
Whether or not a particular gateway or endpoint should formulate URIs in the tel or SIP format is a matter of local administrative policy - if the presence of a host portion would aid the surrounding network in routing calls, the SIP format should be used. A gateway MUST accept either tel or SIP URIs from its peers.
特定のゲートウェイまたはエンドポイントがURIをtelまたはSIP形式で作成する必要があるかどうかは、ローカル管理ポリシーの問題です。ホスト部分の存在が周囲のネットワークのコールのルーティングに役立つ場合は、SIP形式を使用する必要があります。ゲートウェイは、ピアからのtelまたはSIP URIを受け入れる必要があります。
The '+' sign preceding the number in tel URLs indicates that the digits which follow constitute a fully-qualified E.164 [16] number; essentially, this means that a country code is provided before any national-specific area codes, exchange/city codes, or address codes. The absence of a '+' sign MAY signify that the number is merely nationally significant, or perhaps that a private dialing plan is in use. When the '+' sign is not present, but a telephone number is represented by the user portion of the URI, the SIP URI SHOULD contain the optional ';user=phone' parameter; e.g.,
電話URLの番号の前にある「+」記号は、続く数字が完全修飾E.164 [16]番号を構成することを示します。基本的に、これは国別コードが国別の市外局番、取引所/都市コード、または住所コードの前に提供されることを意味します。 「+」記号がないことは、その番号が単に全国的に重要であること、またはおそらくプライベートダイヤリングプランが使用されていることを意味する場合があります。 「+」記号は存在しないが、電話番号がURIのユーザー部分で表される場合、SIP URIにはオプションの「; user = phone」パラメーターを含める必要があります（SHOULD）。例えば。、
To: sip:83000@sip.example.net;user=phone However, it is strongly RECOMMENDED that only internationally significant E.164 numbers be passed between SIP-T gateways, especially when such gateways are in different regions or different administrative domains. In many if not most SIP-T networks, gateways are not responsible for end-to-end routing of SIP calls; practically speaking, gateways have no way of knowing if the call will terminate in a local or remote administrative domain and/or region, and hence gateways SHOULD always assume that calls require an international numbering plan. There is no guarantee that recipients of SIP signaling will be capable of understanding national dialing plans used by the originators of calls - if the originating gateway does not internationalize the signaling, the context in which the digits were dialed cannot be extrapolated by far-end network elements.
To：sip：83000@sip.example.net; user = phoneただし、国際的に有効なE.164番号のみをSIP-Tゲートウェイ間で渡すことを強くお勧めします。このようなゲートウェイが異なる地域または異なる管理ドメインにある場合は特にそうです。ほとんどではないにしても多くのSIP-Tネットワークでは、ゲートウェイはSIPコールのエンドツーエンドルーティングを担当しません。実際には、ゲートウェイは、コールがローカルまたはリモートの管理ドメインやリージョンで終了するかどうかを知る方法がないため、ゲートウェイは常にコールに国際番号計画が必要であると想定する必要があります。 SIPシグナリングの受信者が、コールの発信者が使用する国内ダイヤリングプランを理解できる保証はありません。発信元ゲートウェイがシグナリングを国際化していない場合、数字がダイヤルされたコンテキストを遠端ネットワークで推定できません。要素。
In ISUP signaling, a telephone number appears in a common format that is used in several parameters, including the CPN and CIN; when it represents a calling party number it sports some additional information (detailed below). For the purposes of this document, we will refer to this format as 'ISUP format' - if the additional calling party information is present, the format shall be referred to as 'ISUP- calling format'. The format consists of a byte called the Nature of Address (NoA) indicator, followed by another byte which contains the Numbering Plan Indicator (NPI), both of which are prefixed to a variable-length series of bytes that contains the digits of the telephone number in Binary Coded Decimal (BCD) format. In the calling party number case, the NPI's byte also contains bit fields which represent the caller's presentation preferences and the status of any call screening checks performed up until this point in the call.
ISUPシグナリングでは、電話番号は、CPNやCINなどのいくつかのパラメータで使用される共通の形式で表示されます。それが発呼者番号を表すとき、それはいくつかの追加情報をスポーツします（以下で詳述されます）。このドキュメントでは、この形式を「ISUP形式」と呼びます。追加の発呼者情報が存在する場合、この形式は「ISUP呼び出し形式」と呼ばれます。この形式は、Nature of Address（NoA）インジケーターと呼ばれるバイトと、それに続く番号計画インジケーター（NPI）を含む別のバイトで構成されます。どちらのバイトも、電話の数字を含む可変長の一連のバイトの前に付けられます。 2進化10進数（BCD）形式の数値。発呼者番号の場合、NPIのバイトには、発信者の表示設定と、通話のこの時点までに実行された通話スクリーニングチェックのステータスを表すビットフィールドも含まれます。
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ISUP format ISUP calling format
ISUP形式ISUP呼び出し形式
ISUP numbering formats
ISUP番号付け形式
The NPI field is generally set to the value 'ISDN (Telephony) numbering plan (Recommendation E.164)', but this does not mean that the digits which follow necessarily contain a country code; the NoA field dictates whether the telephone number is in a national or international format. When the represented number is not designated to be in an international format, the NoA generally provides information specific to the national dialing plan - based on this information one can usually determine how to convert the number in question into an international format. Note that if the NPI contains a value other than 'ISDN numbering plan', then the tel URL may not be suitable for carrying the address digits, and the handling for such calls is outside the scope of this document.
NPIフィールドは通常、値「ISDN（テレフォニー）番号計画（推奨E.164）」に設定されますが、これは、後に続く数字に必ず国コードが含まれることを意味するものではありません。 NoAフィールドは、電話番号が国内形式か国際形式かを指定します。代表番号が国際形式であるように指定されていない場合、NoAは通常、国内のダイヤルプランに固有の情報を提供します。この情報に基づいて、問題の番号を国際形式に変換する方法を通常決定できます。 NPIに「ISDN番号計画」以外の値が含まれている場合、電話番号のURLはアドレスの桁を運ぶのに適していない可能性があり、そのような呼び出しの処理はこのドキュメントの範囲外です。
Based on the above, conversion from ISUP format to a tel URL is as follows. First, provided that the NPI field indicates that the telephone number format uses E.164, the NoA is consulted. If the NoA indicates that the number is an international number, then the telephone number digits SHOULD be appended unmodified to a 'tel:+' string. If the NoA has the value 'national (significant) number', then a country code MUST be prefixed to the telephone number digits before they are committed to a tel URL; if the gateway performing this conversion interconnects with switches homed to several different country codes, presumably the appropriate country code SHOULD be chosen based on the originating switch or trunk group. If the NoA has the value 'subscriber number', both a country code and any other numbering components necessary for the numbering plan in question (such as area codes or city codes) MAY need to be added in order for the number to be internationally significant - however, such procedures vary greatly from country to country, and hence they cannot be specified in detail here. Only if a country or network-specific value is used for the NoA SHOULD a tel URL not include a '+' sign; in these cases, gateways SHOULD simply copy the provided digits into the tel URL and append a 'user=phone' parameter if a SIP URI format is used. Any non-standard or proprietary mechanisms used to communicate further context for the call in ISUP are outside the scope of this document.
上記に基づき、ISUP形式からtel URLへの変換は次のとおりです。まず、NPIフィールドが電話番号の形式でE.164を使用していることを示している場合、NoAが参照されます。 NoAが番号が国際番号であることを示している場合、電話番号の数字は変更せずに「tel：+」文字列に追加する必要があります（SHOULD）。 NoAの値が「国の（重要な）番号」である場合、国番号を電話番号の数字の前に付けてから、電話番号にコミットする必要があります。この変換を実行するゲートウェイが複数の異なる国コードをホームとするスイッチと相互接続する場合、おそらく適切な国コードが発信元のスイッチまたはトランクグループに基づいて選択される必要があります。 NoAの値が「加入者番号」である場合、国コードと、問題の番号計画に必要なその他の番号コンポーネント（市外局番や都市コードなど）の両方を追加して、番号が国際的に意味を持つようにする必要があります。 -ただし、このような手順は国によって大きく異なるため、ここでは詳細を指定できません。国またはネットワーク固有の値がNoAに使用される場合のみ、電話URLに「+」記号を含めないでください。これらの場合、SIP URI形式が使用されている場合、ゲートウェイは、提供された数字を電話のURLにコピーし、「user = phone」パラメータを追加する必要があります（SHOULD）。 ISUPでコールのコンテキストをさらに伝達するために使用される非標準または独自のメカニズムは、このドキュメントの範囲外です。
If a nationally-specific parameter is present that allows for the transmission of the calling party's name (such as the Generic Name Parameter in ANSI), then generally, if presentation is not restricted, this information SHOULD be used to populate the display-name portion of the From field.
発呼者の名前の送信を可能にする国固有のパラメーター（ANSIの総称名パラメーターなど）が存在する場合、一般に、表示が制限されていない場合、この情報を使用して表示名部分を設定する必要があります（SHOULD） Fromフィールドの。
If ISUP calling format is being converted rather than ISUP format, then two additional pieces of information must be taken into account: presentation indicators and screening indicators. If the presentation indicators are set to 'presentation restricted', then a special URI is created by the gateway which communicates to the far end that the caller's identity has been omitted. This URI SHOULD be a SIP URI with a display-name and username of 'Anonymous', e.g.:
ISUP形式ではなくISUP呼び出し形式を変換する場合は、プレゼンテーションインジケータとスクリーニングインジケータという2つの追加情報を考慮する必要があります。プレゼンテーションインジケータが「プレゼンテーション制限」に設定されている場合、発信者のIDが省略されていることを遠端と通信する特別なURIがゲートウェイによって作成されます。このURIは、表示名とユーザー名が「匿名」のSIP URIである必要があります。例：
From: Anonymous <sip:anonymous@anonymous.invalid>
For further information about privacy in SIP, see Section 5.7.
SIPのプライバシーの詳細については、セクション5.7を参照してください。
If presentation is set to 'address unavailable', then gateways should treat the IAM as if the CIN parameter was omitted. Screening indicators should not be translated, as they are only meaningful end-to-end.
プレゼンテーションが「アドレス利用不可」に設定されている場合、ゲートウェイはIAMをCINパラメータが省略されているかのように処理する必要があります。スクリーニングインジケーターは、エンドツーエンドでのみ意味があるため、翻訳しないでください。
Conversion from tel URLs to ISUP format is simpler. If the URI is in international format, then the gateway SHOULD consult the leading country code of the URI. If the country code is local to the gateway (the gateway has one or more trunks that point to switches which are homed to the country code in question), the gateway SHOULD set the NoA to reflect 'national (significant) number' and strip the country code from the URI before populating the digits field. If the country code is not local to the gateway, the gateway SHOULD set the NoA to 'international number' and retain the country code. In either case the NPI MUST be set to 'ISDN numbering plan'.
tel URLからISUP形式への変換はより簡単です。 URIが国際形式の場合、ゲートウェイはURIの主要国コードを調べる必要があります（SHOULD）。国コードがゲートウェイに対してローカルである場合（ゲートウェイには、問題の国コードをホームとするスイッチを指す1つ以上のトランクがあります）、ゲートウェイは、「国の（有効な）番号」を反映するようにNoAを設定し、数字フィールドに入力する前のURIからの国コード。国コードがゲートウェイに対してローカルでない場合、ゲートウェイはNoAを「国際番号」に設定し、国コードを保持する必要があります（SHOULD）。どちらの場合も、NPIは「ISDN番号計画」に設定する必要があります。
If the URI is not in international format, the gateway MAY attempt to treat the telephone number within the URI as if it were appropriate to its national or network-specific dialing plan; if doing so gives rise to internal gateway errors or the gateway does not support such procedures, then the gateway SHOULD respond with appropriate SIP status codes to express that the URI could not be understood (if the URI in question is the Request-URI, a 484).
URIが国際的な形式でない場合、ゲートウェイは、URI内の電話番号を、国内またはネットワーク固有のダイヤリングプランに適切であるかのように処理しようとします（MAY）。そうすることで内部ゲートウェイエラーが発生するか、ゲートウェイがそのような手順をサポートしない場合、ゲートウェイは適切なSIPステータスコードで応答して、URIを理解できなかったことを表現する必要があります（問題のURIがRequest-URIの場合、 484）。
When converting from a tel URL to ISUP calling format, the procedure is identical to that described in the preceding paragraphs, but additionally, the presentation indicator SHOULD be set to 'presentation allowed' and the screening indicator to 'network provided', unless some service provider policy or user profile specifically disallows presentation.
Tel URLからISUP呼び出し形式に変換する場合、手順は前の段落で説明した手順と同じですが、さらに、サービスがない限り、プレゼンテーションインジケーターを「プレゼンテーション許可」に設定し、スクリーニングインジケーターを「ネットワーク提供」に設定する必要があります。プロバイダーポリシーまたはユーザープロファイルは、具体的にプレゼンテーションを禁止します。
Other flavors of ISUP different than ITU-T ISUP have different parameters and more features. Some of the parameters have more possible values and provide more information about the status of the call.
ITU-T ISUPとは異なるISUPの他のフレーバーには、異なるパラメーターとより多くの機能があります。一部のパラメーターには、より多くの可能な値があり、呼び出しの状況に関する詳細情報を提供します。
The Circuit Query Message (CQM) and Circuit Query Response (CQR) are used in many ISUP variants. These messages have no analog in SIP, although receipt of a CQR may cause state reconciliation if the originating and destination switches have become desynchronized; as states are reconciled some calls may be terminated, which may cause SIP or ISUP messages to be sent (as described in Section 10).
Circuit Query Message（CQM）およびCircuit Query Response（CQR）は、多くのISUPバリアントで使用されています。これらのメッセージにはSIPのアナログはありませんが、発信元と宛先のスイッチが非同期になると、CQRを受信すると状態の調整が発生する可能性があります。状態が調整されると、一部のコールが終了し、SIPまたはISUPメッセージが送信される場合があります（セクション10で説明）。
However, differences in the message flows are more important. In ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent instead (when no ACM has been sent before the call is answered). In call forwarding situations, CPGs MAY be sent before the ACM is sent. SAMs MUST NOT be sent; 'en-bloc' signaling is always used. The ANSI Exit Message (EXM) SHOULD NOT result in any SIP signaling in gateways. ANSI also uses the Circuit Reservation Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of its interworking procedures - in the event that an MGC does receive a CRM, a CRA SHOULD be sent in return (in some implementations, transmissions of a CRA could conceivably be based on a resource reservation system); after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and process it normally. Any further circuit reservation mechanism is outside the scope of this document.
ただし、メッセージフローの違いはより重要です。 ANSI [11] ISUPでは、CONメッセージを送信してはなりません（MUST NOT）。代わりにANMが送信されます（通話に応答する前にACMが送信されていない場合）。コール転送状況では、ACMが送信される前にCPGが送信される場合があります。 SAMを送信してはなりません。 「en-bloc」シグナリングが常に使用されます。 ANSI終了メッセージ（EXM）は、ゲートウェイでSIPシグナリングを発生させてはなりません（SHOULD NOT）。 ANSIはまた、インターワーキング手順の一部として回線予約メッセージ（CRM）と回線予約確認（CRA）を使用します。MGCがCRMを受信した場合、CRAを返送する必要があります（一部の実装では、 CRAは、リソース予約システムに基づくと考えられます。 CRAが送信された後、MGCは後続のIAMを待ち、通常どおり処理する必要があります（SHOULD）。これ以上の回線予約メカニズムは、このドキュメントの範囲外です。
Although receipt of a Confusion (CFN) message is an indication of a protocol error, corresponding SIP messages SHOULD NOT be sent on receipt of a CFN - the CFN should be handled with ISUP-specific procedures by the gateway (usually by retransmission of the packet to which the CFN responded). Only if ISUP procedures fails repeatedly should this cause a SIP error condition (and call failure) to arise.
混乱（CFN）メッセージの受信はプロトコルエラーを示していますが、対応するSIPメッセージはCFNの受信時に送信すべきではありません-CFNはゲートウェイによってISUP固有の手順で処理される必要があります（通常はパケットの再送信による） CFNが応答した）。 ISUPプロシージャが繰り返し失敗する場合にのみ、これによりSIPエラー状態（およびコールの失敗）が発生します。
In TTC ISUP CPGs MAY be sent before the ACM is sent. Messages such as a Charging Information Message (CHG) MAY be sent between ACM and ANM. 'En-bloc' signaling is always used and there is no T9 timer.
TTCでは、ACMが送信される前にISUP CPGが送信される場合があります。課金情報メッセージ（CHG）などのメッセージは、ACMとANMの間で送信される場合があります。 「一括」シグナリングが常に使用され、T9タイマーはありません。
Some ISUP variants send more messages than the ones described in this document. Therefore, some guidelines are provided here with regard to transport and mapping of these ISUP message.
一部のISUPバリアントは、このドキュメントで説明されているものよりも多くのメッセージを送信します。したがって、これらのISUPメッセージのトランスポートとマッピングに関して、いくつかのガイドラインがここに提供されています。
From the caller to the callee, other ISUP messages SHOULD be encapsulated (see [3]) inside INFO messages, even if the INVITE transaction is still not finished. Note that SIP does not ensure that INFO requests are delivered in order, and therefore in adverse network conditions an egress gateway might process INFOs out of order. This issue, however, does not represent an important problem since it is not likely to happen and its effects are negligible in most of the situations. The Information (INF) message and Information Response (INR) are examples of messages that should be encapsulated within an INFO. Gateway implementers might also consider building systems that wait for each INFO transaction to complete before initiating a new INFO transaction.
呼び出し元から呼び出し先まで、INVITEトランザクションがまだ完了していない場合でも、INFOメッセージ内に他のISUPメッセージをカプセル化する必要があります（[3]を参照）。 SIPはINFO要求が順序どおりに配信されることを保証しないため、ネットワーク条件が悪い場合、出力ゲートウェイがINFOを順序どおりに処理しない可能性があることに注意してください。ただし、この問題は発生する可能性が低く、その影響はほとんどの状況で無視できるため、重要な問題ではありません。情報（INF）メッセージと情報応答（INR）は、INFO内にカプセル化する必要があるメッセージの例です。ゲートウェイの実装者は、新しいINFOトランザクションを開始する前に、各INFOトランザクションが完了するのを待つシステムの構築を検討する場合もあります。
From the callee to the caller, if a message is received by a gateway before the call has been answered (i.e., ANM is received) it SHOULD be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it SHOULD be encapsulated in a provisional 1xx response). Similarly a message which is received on the originating side (probably in response to an INR) before a 200 OK has been received by the gateway should be carried within an INFO. In order for this mechanism to function properly in the forward direction, any necessary Contact or To-tag must have appeared in a previous provisional response or the message might not be correctly routed to its destination. As such all SIP-T gateways MUST send all provisional responses with a Contact header and any necessary tags in order to enable proper routing of new requests issued before a final response has been received. When the INVITE transaction is finished INFO requests SHOULD also be used in this direction.
呼び出し先から呼び出し元へ、呼び出しが応答される前にメッセージがゲートウェイによって受信される（つまり、ANMが受信される）場合、これはINFOにカプセル化される必要があります（ただし、これが逆方向に送信される最初のSIPメッセージではない場合）方向（その場合、暫定1xx応答にカプセル化する必要があります）。同様に、200 OKがゲートウェイによって受信される前に、発信側で（おそらくINRに応答して）受信されたメッセージは、INFO内で運ばれる必要があります。このメカニズムが順方向で正しく機能するためには、必要な連絡先または宛先タグが以前の暫定応答に含まれている必要があります。そうでない場合、メッセージが宛先に正しくルーティングされない可能性があります。そのため、すべてのSIP-Tゲートウェイは、最終応答を受信する前に発行された新しい要求を適切にルーティングできるようにするために、Contactヘッダーと必要なタグを含むすべての暫定応答を送信する必要があります。 INVITEトランザクションが終了すると、INFOリクエストもこの方向で使用する必要があります（SHOULD）。
ACK Acknowledgment ACM Address Complete Message ANM Answer Message ANSI American National Standards Institute BLA Blocking ACK message BLO Blocking Message CGB Circuit Group Blocking Message CGBA Circuit Group Blocking ACK Message CHG Charging Information Message CON Connect Message CPG Call Progress Message CUG Closed User Group GRA Circuit Group Reset ACK Message GRS Circuit Group Reset Message HLR Home Location Register IAM Initial Address Message IETF Internet Engineering Task Force IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part ITU-T International Telecommunication Union Telecommunication Standardization Sector MG Media Gateway MGC Media Gateway Controller MTP Message Transfer Part REL Release Message RES Resume Message RLC Release Complete Message RTP Real-time Transport Protocol SCCP Signaling Connection Control Part SG Signaling Gateway SIP Session Initiation Protocol SS7 Signaling System No. 7 SUS Suspend Message TTC Telecommunication Technology Committee UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol VoIP Voice over IP
ACK確認ACMアドレス完了メッセージANM応答メッセージANSI American National Standards Institute BLAブロッキングACKメッセージBLOブロッキングメッセージCGB回線グループブロッキングメッセージCGBA回線グループブロッキングACKメッセージCHG課金情報メッセージCON接続メッセージCPGコール進行メッセージCUGクローズユーザーグループGRA回線グループリセットACKメッセージGRS回路グループリセットメッセージHLRホームロケーションレジスタIAM初期アドレスメッセージIETFインターネットエンジニアリングタスクフォースIPインターネットプロトコルISDN統合サービスデジタルネットワークISUP ISDNユーザーパートITU-T国際電気通信連合電気通信標準化セクターMGメディアゲートウェイMGCメディアゲートウェイコントローラーMTPメッセージ転送部RELリリースメッセージRES再開メッセージRLCリリース完了メッセージRTPリアルタイム転送プロトコルSCCPシグナリング接続制御部SGシグナリングゲートウェイSIPセッション開始プロトコルSS7シグナリングシステムNo. 7 SUSサスペンドメッセージTTC電気通信技術ogy委員会UACユーザーエージェントクライアントUASユーザーエージェントサーバーUDPユーザーデータグラムプロトコルVoIP Voice over IP
The translation of ISUP parameters into SIP headers may introduce some privacy and security concerns above and beyond those that have been identified for other functions of SIP-T [9A]. Merely securing encapsulated ISUP, for example, would not provide adequate privacy for a user requesting presentation restriction if the Calling Party Number parameter is openly mapped to the From header. Section 12.2 shows how SIP Privacy [9B] should be used for this function. Since the scope of SIP-ISUP mapping has been restricted to only those parameters that will be translated into the headers and fields used to route SIP requests, gateways consequently reveal through translation the minimum possible amount of information.
ISUPパラメータをSIPヘッダーに変換すると、SIP-T [9A]の他の機能で確認されたものを超えて、プライバシーとセキュリティの問題が発生する可能性があります。たとえば、カプセル化されたISUPを安全に保護するだけでは、発信者番号パラメータがFromヘッダーにオープンにマップされている場合、プレゼンテーションの制限を要求するユーザーに十分なプライバシーを提供できません。セクション12.2は、SIPプライバシー[9B]をこの機能に使用する方法を示しています。 SIP-ISUPマッピングのスコープは、SIPリクエストのルーティングに使用されるヘッダーとフィールドに変換されるパラメーターのみに制限されているため、ゲートウェイは、変換を通じて最小限の情報を公開します。
A security analysis of ISUP is beyond the scope of this document. ISUP bridging across SIP is discussed more fully in [9A], but Section 7.2.1.1 discusses processing the translated ISUP values in relation to any embedded ISUP in a request arriving at PSTN gateway. Lack of ISUP security analysis may pose some risks if embedded ISUP is blindly interpreted. Accordingly, gateways SHOULD NOT blindly trust embedded ISUP unless the request was strongly authenticated [9A], and the sender is trusted, e.g., is another MGC that is authorized to use ISUP over SIP in bridge mode. When requests are received from arbitrary end points, gateways SHOULD filter any received ISUP. In particular, only known-safe commands and parameters should be accepted or passed through. Filtering by deleting believed-to-be dangerous entries does not work well.
ISUPのセキュリティ分析は、このドキュメントの範囲外です。 SIPを介したISUPブリッジングについては、[9A]で詳しく説明していますが、7.2.1.1項では、PSTNゲートウェイに到着するリクエストに埋め込まれたISUPに関連して、変換されたISUP値の処理について説明します。埋め込まれたISUPが盲目的に解釈される場合、ISUPセキュリティ分析の欠如はいくつかのリスクをもたらす可能性があります。したがって、ゲートウェイは、リクエストが強力に認証されない限り、埋め込みISUPを盲目的に信頼してはなりません[9A]。送信者は信頼されています。たとえば、ブリッジモードでSIPを介したISUPの使用が許可されている別のMGCです。リクエストが任意のエンドポイントから受信されると、ゲートウェイは受信されたISUPをフィルタリングする必要があります（SHOULD）。特に、既知の安全なコマンドとパラメーターのみを受け入れたり、通過させたりする必要があります。危険と思われるエントリを削除することによるフィルタリングは、うまく機能しません。
In most respects, the information that is translated from ISUP to SIP has no special security requirements. In order for translated parameters to be used to route requests, they should be legible to intermediaries; end-to-end confidentiality of this data would be unnecessary and most likely detrimental. There are also numerous circumstances under which intermediaries can legitimately overwrite the values that have been provided by translation, and hence integrity over these headers is similarly not desirable.
ほとんどの点で、ISUPからSIPに変換される情報には、特別なセキュリティ要件はありません。変換されたパラメータを使用してリクエストをルーティングするには、仲介者が判読できる必要があります。このデータのエンドツーエンドの機密性は不要であり、おそらく有害です。仲介者が変換によって提供された値を合法的に上書きできる状況も数多くあります。そのため、これらのヘッダーの整合性も同様に望ましくありません。
There are some concerns however that arise from the other direction of mapping, the mapping of SIP headers to ISUP parameters, which are enumerated in the following paragraphs. When end users dial numbers in the PSTN today, their selections populate the telephone number portion of the Called Party Number parameter, as well as the digit portions of the Carrier Identification Code and Transit Network Selection parameters of an ISUP IAM. Similarly, the tel URL and its optional parameters in the Request-URI of a SIP, which can be created directly by end users of a SIP device, map to those parameters at a gateway. However, in the PSTN, policy can prevent the user from dialing certain (invalid or restricted) numbers, or selecting certain carrier identification codes. Thus, gateway operators MAY wish to use corresponding policies to restrict the use of certain tel URLs, or tel URL parameters, when authorizing a call.
ただし、マッピングの別の方向、つまりSIPヘッダーからISUPパラメーターへのマッピングについては、次の段落で列挙するいくつかの懸念があります。エンドユーザーが今日PSTNで番号をダイヤルすると、その選択により、着信側番号パラメーターの電話番号部分と、ISUP IAMのキャリア識別コードおよび中継ネットワーク選択パラメーターの数字部分が入力されます。同様に、SIPデバイスのエンドユーザーが直接作成できるSIPのRequest-URI内のtel URLとそのオプションのパラメーターは、ゲートウェイでこれらのパラメーターにマップされます。ただし、PSTNでは、ポリシーにより、ユーザーが特定の（無効または制限された）番号にダイヤルしたり、特定のキャリア識別コードを選択したりできないようにすることができます。したがって、ゲートウェイオペレーターは、コールを承認するときに、対応するポリシーを使用して、特定のtel URL、またはtel URLパラメータの使用を制限することができます。
The fields relevant to number portability, which include in ANSI ISUP the LRN portion of the Generic Address Parameter and the 'M' bit of the Forward Call Indicators, are used to route calls in the PSTN. Since these fields are rendered as tel URL parameters in the SIP-ISUP mapping, users can set the value of these fields arbitrarily. Consequently, an end-user could change the end office to which a call would be routed (though if LRN value were chosen at random, it is more likely that it would prevent the call from being delivered altogether). The PSTN is relatively resilient to calls that have been misrouted on account of local number portability, however. In some networks, a REL message with some sort of "misrouted ported number" cause code is sent in the backwards direction when such a condition arises. Alternatively, the PSTN switch to which a call was misrouted can forward the call along to the proper switch after making its own number portability query - this is an interim number portability practice that is still common in most segments of the PSTN that support portability. It is not anticipated that end users will typically set these SIP fields, and the risks associated with allowing an adventurous or malicious user to set the LRN do not seem to be grave, but they should be noted by network operators. The limited degree to which SIP signaling contributes to the interworking indicators of the Forward Call Indicators and Backward Call Indicator parameters incurs no foreseeable risks.
ANSI ISUPのGeneric Address ParameterのLRN部分とForward Call Indicatorsの「M」ビットを含む番号ポータビリティに関連するフィールドは、PSTNでコールをルーティングするために使用されます。これらのフィールドはSIP-ISUPマッピングでtel URLパラメータとしてレンダリングされるため、ユーザーはこれらのフィールドの値を任意に設定できます。その結果、エンドユーザーは、通話のルーティング先のエンドオフィスを変更できます（ただし、LRN値がランダムに選択された場合、通話が完全に配信されなくなる可能性が高くなります）。ただし、PSTNは、市内番号のポータビリティのために誤ってルーティングされたコールに対して比較的回復力があります。一部のネットワークでは、このような状態が発生すると、何らかの「誤ルーティングされたポート番号」原因コードを含むRELメッセージが逆方向に送信されます。または、コールが誤ってルーティングされたPSTNスイッチは、独自の番号ポータビリティクエリを実行した後、適切なスイッチにコールを転送できます。これは、ポータビリティをサポートするPSTNのほとんどのセグメントで依然として一般的な暫定番号ポータビリティの慣行です。エンドユーザーが通常これらのSIPフィールドを設定することは想定されておらず、冒険的または悪意のあるユーザーがLRNを設定できるようにすることに関連するリスクは重大ではないようですが、ネットワークオペレーターは注意する必要があります。 SIPシグナリングがフォワードコールインジケーターパラメータとバックワードコールインジケーターパラメーターのインターワーキングインジケーターに寄与する程度が限定されていても、予測可能なリスクは発生しません。
Some additional risks may result from the SIP response code to ISUP Cause Code parameter mapping. SIP user agents could conceivably respond to an INVITE from a gateway with any arbitrary SIP response code, and thus they can dictate (within the boundaries of the mappings supported by the gateway) the Q.850 cause code that will be sent by the gateway in the resulting REL message. Generally speaking, the manner in which a call is rejected is unlikely to provide any avenue for fraud or denial of service - to the best knowledge of the authors there is no cause code identified in this document that would signal that some call should not be billed, or that the network should take critical resources off-line. However, operators may want to scrutinize the set of cause codes that could be mapped from SIP response codes (listed in 7.2.6.1) to make sure that no undesirable network-specific behavior could result from operating a gateway supporting the recommended mappings. In some cases, operators MAY wish to implement gateway policies that use alternative mappings, perhaps selectively based on authorization data.
SIP応答コードからISUP原因コードへのパラメーターのマッピングにより、いくつかの追加のリスクが生じる可能性があります。 SIPユーザーエージェントは、おそらく任意のSIP応答コードでゲートウェイからのINVITEに応答する可能性があるため、ゲートウェイによって送信されるQ.850原因コードを（ゲートウェイによってサポートされるマッピングの境界内で）指示できます。結果のRELメッセージ。一般的に言って、通話が拒否される方法は、詐欺やサービス拒否の手段を提供することはほとんどありません-作者の知る限り、このドキュメントには特定の通話が課金されないことを示す原因コードはありません、またはネットワークが重要なリソースをオフラインにする必要があること。ただし、オペレーターは、SIP応答コード（7.2.6.1に記載）からマップできる原因コードのセットを精査して、推奨されるマッピングをサポートするゲートウェイを操作することによって望ましくないネットワーク固有の動作が発生しないようにする必要があります。場合によっては、オペレーターは、おそらく許可データに基づいて選択的に、代替マッピングを使用するゲートウェイポリシーを実装することを希望する場合があります。
If the Request-URI and the To header field of a request received at a gateway differ, Section 7.2.1.1 recommends that the To header (if it is a telephone number) should map to the Original Called Number parameter, and the Request-URI to the Called Party Number parameter. However, the user can, at the outset of a request, select a To header field value that differs from the Request-URI; these two field values are not required to be the same. This essentially allows a user to set the ISUP Original Called Number parameter arbitrarily. Any applications that rely on the Original Called Number for settlement purposes could be affected by this mapping recommendation. It is anticipated that future SIP work in this space will arrive at a better general account of the re-targeting of SIP requests that may be applicable to the OCN mapping.
ゲートウェイで受信した要求のRequest-URIとToヘッダーフィールドが異なる場合、セクション7.2.1.1は、Toヘッダー（電話番号の場合）をOriginal Called Numberパラメータにマッピングし、Request-URIを要求することを推奨しています。着番号パラメータに。ただし、ユーザーはリクエストの最初に、Request-URIとは異なるToヘッダーフィールド値を選択できます。これら2つのフィールド値は同じである必要はありません。これにより、本質的にユーザーはISUP Original Called Numberパラメータを任意に設定できます。決済目的で元の着信番号に依存するアプリケーションは、このマッピングの推奨事項の影響を受ける可能性があります。この分野での今後のSIP作業は、OCNマッピングに適用可能なSIPリクエストの再ターゲットのより一般的な説明に到達すると予想されます。
The arbitrary population of the From header of requests by SIP user agents has some well-understood security implications for devices that rely on the From header as an accurate representation of the identity of the originator. Any gateway that intends to use the From header to populate the called party's number parameter of an ISUP IAM message should authenticate the originator of the request and make sure that they are authorized to assert that calling number (or make use of some more secure method to ascertain the identity of the caller). Note that gateways, like all other SIP user agents, MUST support Digest authentication as described in [1].
SIPユーザーエージェントによる要求のFromヘッダーの任意の集団は、発信者のIDの正確な表現としてFromヘッダーに依存するデバイスに対して、いくつかのよく理解されているセキュリティの影響があります。 Fromヘッダーを使用してISUP IAMメッセージの着信側の番号パラメーターを設定しようとするゲートウェイは、要求の発信者を認証し、その発信者番号をアサートする権限があることを確認する必要があります（または、より安全な方法を使用して、発信者の身元を確認します）。他のすべてのSIPユーザーエージェントと同様に、ゲートウェイは[1]で説明されているダイジェスト認証をサポートする必要があることに注意してください。
There is another class of potential risk that is related to the cut-through of the backwards media path before the call is answered. Several practices described in this document recommend that a gateway signal an ACM when a called user agent returns a 18x provisional response code. At that time, backwards media will be cut through end-to-end in the ISUP network, and it is possible for the called user agent then to play arbitrary audio to the caller for an indefinite period of time before transmitting a final response (in the form of a 2xx or higher response code). There are conceivable respects in which this capability could be used illegitimately by the called user agent. It is also however a useful feature to allow progress tones and announcements to be played in the backwards direction in the 'ACM sent' state (so that the caller won't be billed for calls that don't actually complete but for which failure conditions must be rendered to the user as in-band audio). In fact, ISUP commonly uses this backwards cut-through capability in order to pass tones and announcements relating to the status of a call when an ISUP network interworks with legacy networks that are not capable of expressing Q.850 cause codes.
コールが応答される前の逆方向メディアパスのカットスルーに関連する潜在的なリスクの別のクラスがあります。このドキュメントで説明するいくつかのプラクティスでは、呼び出されたユーザーエージェントが18x暫定応答コードを返したときにゲートウェイがACMに信号を送ることを推奨しています。その時点で、後方メディアはISUPネットワークでエンドツーエンドでカットされ、呼び出されたユーザーエージェントは、最終的な応答を送信する前に、無期限に任意の音声を発信者に再生することが可能です（ 2xx以上の応答コードの形式）。呼び出されたユーザーエージェントがこの機能を不正に使用する可能性があるという点が考えられます。ただし、「ACM送信済み」状態で逆方向にプログレストーンとアナウンスを再生できるようにすることも便利な機能です（これにより、実際には完了しなかったが、障害状態の通話については発信者に請求されません。インバンドオーディオとしてユーザーにレンダリングする必要があります）。実際、ISUPネットワークは、Q.850原因コードを表現できないレガシーネットワークとISUPネットワークが相互作用するときに、通常、この後方カットスルー機能を使用して、コールのステータスに関連するトーンとアナウンスを渡します。
It is the contention of the authors that SIP introduces no risks with regard to backwards media that do not exist in Q.931-ISUP mapping, but gateways implementers MAY develop an optional mechanism (possibly something that could be configured by an operator) that would cut off such 'early media' on a brief timer - it is unlikely that more than 20 or 30 seconds of early media is necessary to convey status information about the call (see Section 7.2.6). A more conservative approach would be to never cut through backwards media in the gateway until a 2xx final response has been received, provided that the gateway implements some way of prevent clipping of the initial media associated with the call.
SIPがQ.931-ISUPマッピングに存在しない後方メディアに関してリスクをもたらさないのは著者の主張ですが、ゲートウェイの実装者はオプションのメカニズム（おそらくオペレーターが設定できるもの）を開発してもよい（MAY）短いタイマーでそのような「アーリーメディア」を切り取ります。コールに関するステータス情報を伝えるために、20秒または30秒を超えるアーリーメディアが必要になることはほとんどありません（セクション7.2.6を参照）。より保守的なアプローチは、ゲートウェイがコールに関連付けられた初期メディアのクリッピングを防止する何らかの方法を実装している場合、2xxの最終応答が受信されるまで、ゲートウェイの逆方向メディアをカットスルーしないことです。
Unlike a traditional PSTN phone, a SIP user agent can launch multiple simultaneous requests in order to reach a particular resource. It would be trivial for a SIP user agent to launch 100 SIP requests at a 100 port gateway, thereby tying up all of its ports. A malicious user could choose to launch requests to telephone numbers that are known never to answer, which would saturate these resources indefinitely and potentially without incurring any charges. Gateways therefore MAY support policies that restrict the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack.
従来のPSTN電話とは異なり、SIPユーザーエージェントは特定のリソースに到達するために複数の同時要求を起動できます。 SIPユーザーエージェントが100ポートのゲートウェイで100のSIPリクエストを起動して、そのすべてのポートを占有するのは簡単です。悪意のあるユーザーは、応答することが知られていない電話番号へのリクエストを開始することを選択できます。これにより、これらのリソースが無期限に、場合によっては課金されることなく飽和します。したがって、ゲートウェイは、この認証されたサービス拒否攻撃に対処するために、同じ認証済みソースまたは同様のメカニズムから発信される同時リクエストの数を制限するポリシーをサポートする場合があります。
This document introduces no new considerations for IANA.
このドキュメントでは、IANAに関する新しい考慮事項を紹介していません。
This document existed as an Internet-Draft for four years, and it received innumerable contributions from members of the various Transport Area IETF working groups that it called home (which included the MMUSIC, SIP and SIPPING WGs). In particular, the authors would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars Tovander, Al Varney and William T. Marshall for their help and feedback on this document. The authors would also like to thank ITU-T SG11 for their advice on ISUP procedures.
このドキュメントは4年間インターネットドラフトとして存在し、ホームと呼ばれたさまざまなトランスポートエリアIETFワーキンググループ（MMUSIC、SIP、およびSIPPING WGを含む）のメンバーから無数の貢献を受けました。特に、著者はOlli Hynonen、Tomas Mecklin、Bill Kavadas、Jonathan Rosenberg、Henning Schulzrinne、Tawya Sawada、Miguel A. Garcia、Igor Slepchin、Douglas C. Sicker、Sam Hoffpauir、Jean-Francois Mule、Christer Holmbergに特に感謝します。 、Doug Hurtig、Tahir Gun、Jan Van Geel、Romel Khan、Mike Hammer、Mike Pierce、Roland Jesske、Moter Du、John Elwell、Steve Bellovin、Mark Watson、Denis Alexeitsev、Lars Tovander、Al Varney、William T. Marshallこのドキュメントに関するヘルプとフィードバック。 ISUPの手順に関するアドバイスを提供してくれたITU-T SG11にも感謝します。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camariillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261、 2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
[3] Zimmerer、E.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M. and M. Zonoun、 "MIME media types for ISUP and QSIG objects"、RFC 3204、December 2001 。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[5] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーンおよびテレフォニーシグナル用のRTPペイロード」、RFC 2833、2000年5月。
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Donovan、S。、「The SIP INFO Method」、RFC 2976、2000年10月。
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[7] Vaha-Sipila、A。、「電話のURL」、RFC 2806、2000年4月。
[8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[8] Faltstrom、P。、「E.164番号およびDNS」、RFC 2916、2000年9月。
[9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header Field for the Session Initiation Protocol", RFC 3326, December 2002.
[9] Schulzrinne、H.、Camarillo、G。、およびD. Oran、「セッション開始プロトコルの理由ヘッダーフィールド」、RFC 3326、2002年12月。
[9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[9A]ヴェムリA.およびJ.ピーターソン、「電話用セッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ」、BCP 63、RFC 3372、2002年9月。
[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[9B]ピーターソンJ.、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[10] International Telecommunications Union, "Application of the ISDN user part of CCITT Signaling System No. 7 for international ISDN interconnection", ITU-T Q.767, February 1991, <http://www.itu.int>.
[10] 国際電気通信連合、「国際ISDN相互接続のためのCCITT信号システムNo. 7のISDNユーザー部分の適用」、ITU-T Q.767、1991年2月、<http://www.itu.int>。
[11] American National Standards Institute, "Signaling System No. 7; ISDN User Part", ANSI T1.113, January 1995, <http://www.itu.int>.
[11] American National Standards Institute、「Signaling System No. 7; ISDN User Part」、ANSI T1.113、1995年1月、<http://www.itu.int>。
[12] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 1999, <http://www.itu.int>.
[12] International Telecommunications Union、「Signaling System No. 7; ISDN User Part Signaling procedure」、ITU-T Q.764、December 1999、<http://www.itu.int>。
[13] International Telecommunications Union, "Abnormal conditions - Special release", ITU-T Q.118, September 1997, <http://www.itu.int>.
[13] 国際電気通信連合、「異常な状況-特別リリース」、ITU-T Q.118、1997年9月、<http://www.itu.int>。
[14] International Telecommunications Union, "Specifications of Signaling System No. 7 - ISDN supplementary services", ITU-T Q.737, June 1997, <http://www.itu.int>.
[14] International Telecommunications Union、「Specifications of Signaling System No. 7-ISDN補足サービス」、ITU-T Q.737、1997年6月、<http://www.itu.int>。
[15] International Telecommunications Union, "Usage of cause location in the Digital Subscriber Signaling System No. 1 and the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998, <http://www.itu.int>.
[15] 国際電気通信連合、「デジタル加入者信号システムNo. 1および信号システムNo. 7 ISDNユーザーパートにおける原因の特定の場所の使用」、ITU-T Q.850、1998年5月、<http://www.itu.int >。
[16] International Telecommunications Union, "The international public telecommunications numbering plan", ITU-T E.164, May 1997, <http://www.itu.int>.
[16] 国際電気通信連合、「国際公衆電気通信番号計画」、ITU-T E.164、1997年5月、<http://www.itu.int>。
[17] International Telecommunications Union, "Formats and codes of the ISDN User Part of Signaling System No. 7", ITU-T Q.763, December 1999, <http://www.itu.int>.
[17] 国際電気通信連合、「信号システムのISDNユーザー部のフォーマットとコードNo. 7」、ITU-T Q.763、1999年12月、<http://www.itu.int>。
[18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", RFC 3262, June 2002.
[18] Rosenberg、J。およびH. Schulzrinne、「SIPでの暫定応答の信頼性」、RFC 3262、2002年6月。
[19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, October 2000.
[19] Stewart、R。、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[20] Rosenberg、J。、「セッション開始プロトコル（SIP）UPDATEメソッド」、RFC 3311、2002年10月。
[21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of Number Portability and Freephone Service", Work in Progress.
[21] Yu、J.、「番号ポータビリティとフリー電話サービスをサポートするための「tel」および「fax」URLへの拡張」、作業中。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。 FIN-02420 Jorvasフィンランド
Phone: +358 9 299 3371
URI: http://www.ericsson.com/
EMail: Gonzalo.Camarillo@Ericsson.com
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024 USA
URI: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
Jon Peterson NeuStar、Inc. 1800 Sutter St Suite 570 Concord、CA 94520 USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA
リンドンオンシエナ10480リッジビューコートクパチーノ、カリフォルニア95014アメリカ
URI: http://www.ciena.com/
EMail: lyOng@ciena.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。