この文書はRFC3398の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group G. Camarillo
Request for Comments: 3398 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
November 2002
Integrated Services Digital Network (ISDN) User Part (ISUP)
to Session Initiation Protocol (SIP) Mapping
統合ディジタル通信サービス網（ＩＳＤＮ）ユーザ部（ＩＳＵＰ）
とセッション開始プロトコル（ＳＩＰ）の翻訳
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
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).
この文書は２つの信号プロトコル間の翻訳を行う方法を記述します：セッショ
ン開始プロトコル（ＳＩＰ）と、Ｎｏ７共通線信号（ＳＳ７）の統合ディジタ
ル通信サービス網（ＩＳＤＮ）ユーザ部（ＩＳＵＰ）。このメカニズムは公衆
交換電話網（ＰＳＴＮ）と相互接続が必要な環境でＳＩＰを使う時、実装され
るかもしれません。
Table of Contents
目次
1. Introduction
1. はじめに
2. Scope
2. 範囲
3. Terminology
3. 用語
4. Scenarios
4. シナリオ
5. SIP Mechanisms Required
5. ＳＩＰメカニズム要求条件
5.1 'Transparent' Transit of ISUP Messages
5.1 ＩＳＵＰメッセージの「透過的」転送
5.2 Understanding MIME Multipart Bodies
5.2 ＭＩＭＥマルチパート部の理解
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information
5.3 二重トーン多重周波数（ＤＴＭＦ）情報の伝達
5.4 Reliable Transmission of Provisional Responses
5.4 暫定的応答の信頼できる伝達
5.5 Early Media
5.5 早期メディア
5.6 Mid-Call Transactions which do not change SIP state
5.6 ＳＩＰ状態を変えない中間呼処理
5.7 Privacy Protection
5.7 プライバシー保護
5.8 CANCEL causes
5.8 中止理由
6. Mapping
6. 翻訳
7. SIP to ISUP Mapping
7. ＳＩＰからＩＳＵＰへの翻訳
7.1 SIP to ISUP Call flows
7.1 ＳＩＰからＩＳＵＰへの呼フロー
7.1.1 En-bloc Call Setup (no auto-answer)
7.1.1 En-bloc呼設定（自動応答なし）
7.1.2 Auto-answer call setup
7.1.2 自動応答呼設定
7.1.3 ISUP T7 Expires
7.1.3 ＩＳＵＰタイマＴ７タイムアウト
7.1.4 SIP Timeout
7.1.4 ＳＩＰタイムアウト
7.1.5 ISUP Setup Failure
7.1.5 ＩＳＵＰ呼設定失敗
7.1.6 Cause Present in ACM Message
7.1.6 ＡＣＭメッセージでの理由表示
7.1.7 Call Canceled by SIP
7.1.7 ＳＩＰの中止した呼
7.2 State Machine
7.2 状態遷移図
7.2.1 INVITE received
7.2.1 ＩＮＶＩＴＥ受信
7.2.1.1 INVITE to IAM procedures
7.2.1.1 ＩＡＭ手順へのＩＮＶＩＴＥ
7.2.2 ISUP T7 expires
7.2.2 ＩＳＵＰタイマＴ７タイムアウト
7.2.3 CANCEL or BYE received
7.2.3 ＣＡＮＣＥＬかＢＹＥの受信
7.2.4 REL received
7.2.4 ＲＥＬ受信
7.2.4.1 ISDN Cause Code to Status Code Mapping
7.2.4.1 ＩＳＤＮ原因コードから状態コードへの翻訳
7.2.5 Early ACM received
7.2.5 早期ＡＣＭ受信
7.2.6 ACM received
7.2.6 ＡＣＭ受信
7.2.7 CON or ANM Received
7.2.7 ＣＯＮかＡＮＭ受信
7.2.8 Timer T9 Expires
7.2.8 タイマＴ９タイムアウト
7.2.9 CPG Received
7.2.9 ＣＰＧ受信
7.3 ACK received
7.3 ＡＣＫ受信
8. ISUP to SIP Mapping
8. ＩＳＵＰからＳＩＰへの翻訳
8.1 ISUP to SIP Call Flows
8.1 ＩＳＵＰからＳＩＰへの呼フロー
8.1.1 En-bloc call setup (non auto-answer)
8.1.1 Enブロック呼設定（自動応答なし）
8.1.2 Auto-answer call setup
8.1.2 自動応答呼設定
8.1.3 SIP Timeout
8.1.3 ＳＩＰタイムアウト
8.1.4 ISUP T9 Expires
8.1.4 ＩＳＵＰＴ９タイムアウト
8.1.5 SIP Error Response
8.1.5 ＳＩＰエラー回答
8.1.6 SIP Redirection
8.1.6 ＳＩＰ転送
8.1.7 Call Canceled by ISUP
8.1.7 ＩＳＵＰからの呼中止
8.2 State Machine
8.2 状態遷移図
8.2.1 Initial Address Message received
8.2.1 アドレス開始メッセージ受信
8.2.1.1 IAM to INVITE procedures
8.2.1.1 ＩＡＭからＩＮＶＩＴＥへの手順
8.2.2 100 received
8.2.2 １００受信
8.2.3 18x received
8.2.3 １８ｘ受信
8.2.4 2xx received
8.2.4 2xx受信
8.2.5 3xx Received
8.2.5 3xx 受信
8.2.6 4xx-6xx Received
8.2.6 4xx-6xx 受信
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping
8.2.6.1 ＳＩＰ状態コードからＩＳＤＮ理由コードへの翻訳
8.2.7 REL Received
8.2.7 ＲＥＬ受信
8.2.8 ISUP T11 Expires
8.2.8 ＩＳＵＰタイマＴ１タイムアウト
9. Suspend/Resume and Hold
9. 保留／再開と保留
9.1 Suspend (SUS) and Resume (RES) Messages
9.1 保留（ＳＵＳ）と再開（ＲＥＳ）メッセージ
9.2 Hold (re-INVITE)
9.2 保留（再ＩＮＶＩＴＥ）
10. Normal Release of the Connection
10. 標準呼開放
10.1 SIP initiated release
10.1 ＳＩＰからの開放
10.2 ISUP initiated release
10.2 ＩＳＵＰからの開放
10.2.1 Caller hangs up
10.2.1 発信者が受話器を置く
10.2.2 Callee hangs up (SUS)
10.2.2 着信者が受話器を置く（ＳＵＳ）
11. ISUP Maintenance Messages
11. ＩＳＵＰ管理メッセージ
11.1 Reset messages
11.1 リセットメッセージ
11.2 Blocking messages
11.2 閉塞メッセージ
11.3 Continuity Checks
11.3 接続検査
12. Construction of Telephony URIs
12. 電話ＵＲＩの生成
12.1 ISUP format to tel URL mapping
12.1 ＩＳＵＰフォーマットからｔｅｌ ＵＲＬへの翻訳
12.2 tel URL to ISUP format mapping
12.2 ｔｅｌ ＵＲＬからＩＳＵＰフォーマットへの翻訳
13. Other ISUP flavors
13. 他のＩＳＵＰ方言
13.1 Guidelines for sending other ISUP messages
13.1 他のＩＳＵＰメッセージを送るガイドライン
14. Acronyms
14. 頭字語
15. Security Considerations
15. セキュリティの考察
16. IANA Considerations
16. ＩＡＮＡの考慮
17. Acknowledgments
17. 謝辞
18. Normative References
18. 参照する参考文献
19. Non-Normative References
19. 標準でない参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
１．はじめに
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.
ＳＩＰ[1]はマルチメディアのセッションを開始し、終了し、変更するための
アプリケーションレイヤプロトコルです。これは通常ＩＰ上で運ばれます。
電話はオーディオ交換のマルチメディアセッションタイプと思われます。
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.).
統合ディジタル通信サービス網（ＩＳＤＮ）ユーザ部（ＩＳＵＰ）[12]が
Ｎｏ７共通線信号（ＳＳ７）で使われる第４層プロトコルです。これはＩＰ
上でも動作するが（ＳＣＴＰ[19]参照）、通常メッセージ転送部（ＭＴＰ）
上で動作します。ＩＳＵＰは電話呼制御や、ネットワーク保守（回線閉塞や
回路リセット）に使われます。
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.
これらの２つのプロトコルの間の翻訳モジュールが、「ソフトスイッチ」や
「コールエージェント」という用語も使われるが、通常メディアゲートウェ
イコントローラ（ＭＧＣ）と言われます。ＭＧＣがＩＳＵＰネットワークと
ＳＩＰネットワークそれぞれに対する論理的なインタフェースを持ちます。
ＭＧＣはある音声パスを制御能力を持っています；メディアゲートウェイは
通常Ｅ１／Ｔ１中継インタフェース（公衆交換電話網からの音声）とＩＰイ
ンタフェース（ＩＰ上の音声−ＶｏＩＰ）を持ちます。ＭＧＣとＭＧは１つ
の物理的な箱に統合する事も、別にすることもできます。
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.
これらのＭＧＣはしばしばＳＩＰネットワークとＩＳＵＰネットワークのブ
リッジに使われ、ＰＳＴＮからの電話がＩＰ電話終端に達する事ができ、逆
も同様です。これはＰＤＴＮ呼がＩＰ界の有用サービスを利用する時に有用
で、ＩＰネットワークがＰＳＴＮ−ＰＳＴＮ呼の中継網に使う事や、デスク
トップの「ソフト電話」からＰＳＴＮ端末への呼、多くの他の類似の次世代
の電話に役立ちます。
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.
この文書はＭＧＣがプロトコル間の、メッセージレベルとパラメータレベル
の、翻訳を例示することでＳＩＰとＩＳＵＰ間の翻訳を実行するために使う
かもしれないロジックと処理を記述します。これは、相互接続のプロトコル
イベント同期の実装の推薦としての、２つのプロトコルの並列した状態遷移
の間の相互作用を記述します。
2. Scope
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.
この文書はＩＳＵＰメッセージをＳＩＰメッセージへ翻訳する事と、ＩＳＵ
ＰパラメータをＳＩＰヘッダに翻訳することに焦点を合わせます。翻訳の目
的は、ＳＩＰネットワークを横断するＩＳＵＰ要求のため、着信者番号のよ
うなＩＳＵＰ基準に基づいたルーティングを、（典型的にＩＳＵＰを理解し
ない）プロクシサーバーのようなＳＩＰ要素で行うことです。この文書は従っ
てＳＩＰ要求のルーティング中継者に使われるかもしれないＩＳＵＰパラメー
タだけのＳＩＰへの翻訳を提供します。このアプローチの副作用として、カ
プセル化ＩＳＵＰを理解しないか、あるいはただメッセージにカプセル化し
た特定のＩＳＵＰ形を理解するできない、ＳＩＰ終端への呼についての重大
な情報を供給することで、翻訳が全体的な互換性を増やします。
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.
この文書はＩＳＵＰの電話機能だけを考慮します。ＰＳＴＮトランクを扱う
保守メッセージは、それらが通信中の呼制御に影響を与える場合に限り扱い
ます；さもなければこれらのメッセージはＳＩＰに類似ものがないか必要あ
りません。
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
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.
ＰＳＴＮ（ＭＴＰ３）のエラーか混雑を示すメッセージ、ユーザ部利用やユー
ザ部試験ＩＳＵＰメッセージのような回復メカニズムはこの文書の範囲外で
す。ＩＳＵＰのいくつかの方言があります。国際電気通信連合電気通信標準
化セクタ（ＩＴＵ−Ｔ）国際ＩＳＵＰ[12]はこの文書を通して使われます；
米国規格協会（ＡＮＳＩ）[11]ＩＳＵＰとと電気通信技術委員会（ＴＴＣ）
ＩＳＵＰの相違が同じく概説されます。ＩＴＵ−ＴのＩＳＵＰがすべてのＩ
ＳＵＰ方言の中で最も広く知られているので、この文書で使います。直接Ｉ
ＳＵＰからＳＩＰに対応するフィールドが少ないので、ＩＴＵ−ＴのＩＳＵ
ＰとＩＳＵＰの特定の国の方言の間の信号の相違は一般に対応付けにわずか
しか影響しないでしょう。しかしながら、ローカル番号ポータビリティ（Ｌ
ＮＰ）が国内番号計画に基づく傾向があるため、ＩＴＵ−Ｔがローカル番号
ポータビリティに十分な対応をしてなく、従ってＬＮＰは事実上国毎に記述
しなければならないことを指摘します。この文書で記述された番号ポータビ
リティは任意利用の機構として提示されます。
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.
この文書でのＳＩＰヘッダからＩＳＵＰパラメータへの翻訳はＩＳＵＰアド
レスメッセージ（ＩＡＭ）のパラメータとＳＩＰのＩＮＶＩＴＥメッセージ
に関連するヘッダ間の翻訳に焦点を合わせます；両メッセージは呼設立を求
めるためそれぞれのプロトコルで使われます。あるセッションでＩＮＢＩＴ
Ｅが送られると、このようなヘッダでＴｏとＦｒｏｍフィールドは本質的に
固定で、続くメッセージの翻訳は不要で、ＶｉａとＲｏｕｔｅヘッダに従っ
て送られます。それ故、ＳＩＰ−Ｔでのパラメータからヘッダーへの翻訳問
題は多かれ少なかれＩＡＭとＩＮＶＩＴＥに限定されます。ＳＩＰ状態コー
ドに基づいて追加の詳細がＩＳＵＰのアドレス完了メッセージ（ＡＣＭ）と
切断メッセージ（ＲＥＬ）パラメータで与えられます。
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.
この文書はＳＩＰ電話と関連したメディアパスを初期化し、終了し、変更す
る時などを記述しますが、どのように初期化が行われ、どのプロトコルがこ
の目的で使われるか細部を詳しく述べません。
3. Terminology
3. 用語
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]で記述されるように解釈され、準拠ＳＩＰ実装の
必要条件レベルを示すはずである。
4. Scenarios
4. シナリオ
There are several scenarios where ISUP-SIP mapping takes place. The
way the messages are generated is different depending on the
scenario.
ＩＳＵＰからＳＩＰへの翻訳が起こるいくつかのシナリオがあります。メッ
セージが生成される方法はシナリオよって異なっています。
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.
１つのＭＧＣがあり、電話がＳＩＰ電話からＰＳＴＮ電話へ、あるいはその
逆である時、ＭＧＣはこの文書で記述された方法に基づいたＩＳＵＰメッセー
ジを生成します。
+-------------+ +-----+ +-------------+
| 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).
電話がＰＳＴＮから始まって、ＳＩＰネットワークを通り、再びＰＳＴＮで
終わるシナリオは「ＳＩＰブリッジ」として知られています。ＳＩＰブリッ
ジは呼処理でＰＳＴＮ交換機間にＩＳＵＰ透過性を供給するべきです。これ
はＳＩＰメッセージの本体に入りＩＳＵＰメッセージをカプセル化すること
によって成し遂げられます（[3]参照）。この場合、出口ＭＧＣによって生成
されたＩＳＵＰメッセージはＳＩＰ本体にあるものです。（できる限り修正
して；例えば、もし要求の一様リソース識別子−ＵＲＩ−の着番号がＳＩＰ
転送のためにＩＳＵＰにあるものと異なっているなら、ＩＳＵＰメッセージ
は調整する必要があるでしょう）。
+------+ +-------------+ +-----+ +------------+ +------+
| 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.
音声パスが両方のＭＧの間でＩＰネットワークを通して確立されなければな
らないから、ＳＩＰは両方のＭＧＣの間で使われます；この構造は同じく電
話である特定のＳＩＰサービスを利用することを可能にします。ＳＩＰ本体
でのＩＳＵＰメッセージがピアＭＧＣに（原因値と任意のパラメータのよう
な）追加情報を供給します。
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.
両方のシナリオで、入りＭＧＣはデフォルトで入りＩＳＵＰメッセージをＳ
ＩＰ本体に置きます。これがセキュリティ上の意味を持つ事に注意してくだ
さい；１５章参照。もしこれらのＳＩＰメッセージの受信者（典型的にＳＩ
Ｐユーザーエージェントクライアント／ユーザーエージェントサーバ−ＵＡ
Ｃ／ＵＡＳ）がＩＳＵＰを理解できないなら、ＳＩＰ「受理」や「拒否」ヘッ
ダでの交渉が必要で、ＩＳＵＰは次のＳＩＰメッセージ交換に含められない
でしょう。
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.
ＰＳＴＮとＭＧＣの間に信号ゲートウェイ（ＳＧ）があり得ます。これは[19]
で記述されたような方法でＩＰの上にＩＳＵＰメッセージをカプセル化しま
す。この文書で記述された翻訳はＩＳＵＰの下位転送プロトコルの影響を受
けません。
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.
オーバーラップダイヤルメカニズム（次のアドレスメッセージ−ＳＡＭを使
う）がこの文書の範囲の外であることに注意してください。この文書はオー
バーラップダイアルが使われるＩＳＵＰネットワークにつながったゲートウェ
イが、ＩＮＶＩＴＥがＳＩＰネットワークに伝達される前に、すべての桁を
集めらることを保証するタイマーを実装すると想定します。
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.
いくつかの場合には、ゲートウェイが極端なメッセージ長さのためにメッセー
ジ分割を示す不完全なＩＳＵＰメッセージを受け取るかもしれません。一般
にこれらのメッセージにはオリジナルのＩＳＵＰメッセージの残りを含む分
割メッセージ（ＳＧＭ）が続くでしょう。不完全なメッセージがＳＩＰへの
適切な翻訳をするのに十分なパラメータを含んでいないかもしれません；同
様に、不完全なＩＳＵＰメッセージのカプセル化（下記参照）は終端ゲート
ウェイにとって紛らわしいかもしれません。従って、ゲートウェイが対応す
るＩＮＶＩＴＥを送る前に完全なＩＳＵＰメッセージを受け取るまで待たな
くてはならりません(MUST)、（１つ以上のＳＧＭの到着を待つかもしれない）。
5. SIP Mechanisms Required
5. ＳＩＰメカニズム要求条件
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.).
ＩＳＵＰとＳＩＰの間の正しい翻訳のために、基本ＳＩＰ仕様で利用可能な
もの以上のＳＩＰメカニズムが必要とされます。これらのメカニズムは下に
論じられます。もし呼に関係しているＳＩＰのＵＡＣ／ＵＡＳがそれらをサ
ポートしてなくても、先に進むことはまだ可能であるが、呼接続動作はユー
ザーが予想するのとわずかに異なるかもしれません（例えば、呼び出し音の
前に、ユーザに転送呼び出しを知らされる事無く、他者が答えるかもしれま
せん）。
5.1 'Transparent' Transit of ISUP Messages
5.1 ＩＳＵＰメッセージの「透過的」転送
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].
ＳＩＰネットワークを経由してＰＳＴＮからＰＳＴＮに電話をする時、既存
の電話ネットワークに許される全サービスの利用できるために、ＳＩＰメッ
セージはゲートウェイからゲートウェイまでＩＳＵＰペイロードを送れなく
てはなりません(MUST)。これらのＩＳＵＰメッセージをカプセル化するため
のフォーマットは[3]で定義されます。
SIP user agents which do not understand ISUP are permitted to ignore
these optional MIME bodies.
ＩＳＵＰを理解しないＳＩＰユーザーエージェントがこれらのオプションＭ
ＩＭＥ部を無視するのが許されます。
5.2 Understanding MIME Multipart Bodies
5.2 ＭＩＭＥマルチパート部の理解
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 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.
ＰＳＴＮ接続ノードが、 RFC2046[4]で定義される"multipart/mixed"のＭＩ
ＭＥタイプを理解しなくてはなりません(MUST)。クライアントが"受け入れ
"ヘッダーに"multipart/mixed"含めることでこれのサポートを表現します。
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information
5.3 二重トーン多重周波数（ＤＴＭＦ）情報の伝達
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.
ユーザの生成したＤＴＭＦトーンがゲートウェイによって伝達される方法は、
ＳＩＰとＩＳＵＰを接続する方法と完全に無関係です；しかしながら、ＤＴ
ＭＦ転送が、ゲートウェイソリューションの要素の一部なので、ある案内を
ここでします。
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].
音声伝送のためのコーデックが理想的にＤＴＭＦ情報をを運ぶことに適して
いないかもしれず、（アウトバンド転送はメディアにトーンを再挿入する時
の同期に多くの問題があろうから）インバンドでこの情報を伝達するシンボ
ルを使った方法が望ましいです。この伝達は、RFC2833[5]で記述されるよう
に、行われるかもしれません。
5.4 Reliable Transmission of Provisional Responses
5.4 暫定的応答の信頼できる伝達
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.
暫定的応答（１xxクラス）が呼経過情報の伝達で使われます。特別のＰＳＴ
Ｎ接続でメディアチャンネルの制御と電話イベントのタイミングはこれらの
メッセージに依存します。
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].
ＰＳＴＮと接続する際、ＳＩＰメッセージがエンドエンドで信頼できるよう
に送られなくてはなりません(MUST)；要求の信頼性がベースプロトコルによっ
て保証されます。回答で、アプリケーション層の暫定的信頼性メカニズムの
１つが[18]で記述されます。
5.5 Early Media
5.5 早期メディア
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.
早期メディアが、ＳＩＰセッションが確定する前に（2xx回答コードが送られ
る前に）、メディア（電話用オーディオ）を伝達する能力を示します。電話
の場合、特に（旧式なＭＦネットワークのような）アウトバンドで呼状態を
示すことができないネットワークと相互接続する際に、逆方向のメディアを
確立するのがトーンとアナウンスを運ぶため望ましいです。相互接続しない
場合、早期メディアの使用は、利益のないメディア利用のためマシン間のト
ランク資源を消費するので、ほとんど常に望ましくありません。ＩＮＶＩＴ
Ｅがほとんど常に逆方向にメディアを送るように要求するＳＤＰを含み、そ
してユーザーエージェントＩＮＶＩＴＥ信号を送るとすぐに逆方向のメディ
アを受取る準備を要求するので、基本ＳＩＰプロトコルが基本的な一方向性
の早期メディアシステムを可能にするのに十分なサポートを持っていること
に注意してください。しかしながら、このメカニズムは多くの限界を持ちま
す−例えばＩＮＶＩＴＥのＳＤＰで提案したメディアの流れを修正するか止
めることができず、セッション維持に必要な双方向性のＲＴＣＰは確立され
ません。
Therefore gateways MAY support more sophisticated early media systems
as they come to be better understood. One mechanism that provides a
way of initiating a fully-featured early media system is described in
[20].
それ故にゲートウェイが、より良く解釈できるような、より洗練された早期
メディアシステムをサポートするかもしれません。完全に機能する早期メディ
アシステムを開始する方法を供給する１つのメカニズムが[20]で記述されま
す。
Note that in SIP networks not just switches but also user agents can
generate the 18x response codes and initiate early backwards media,
and that therefore some gateways may wish to enforce policies that
restrict the use of backwards media from arbitrary user agents (see
Section 15).
ＳＩＰネットワークでスイッチだけではなくユーザーエージェントが18x回答
コードを生成し、逆方向の早期メディアを始めることができ、それ故にある
ゲートウェイが任意のユーザーエージェントからの逆方向メディアの用途を
限定するポリシーを実施したいと望むかもしれないことに注意してください
（１５章参照）。
5.6 Mid-Call Transactions which do not change SIP state
5.6 ＳＩＰ状態を変えない中間呼処理
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.
ＰＳＴＮと接続する時、ゲートウェイ間でＳＩＰオペレーションに対応しな
いＳＩＰメッセージを送る必要がある状態があります。
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.
既存のＳＩＰに対応しない中間呼処理と他のＩＳＵＰイベントをサポートす
るため、ＳＩＰゲートウェイがRFC2976[6]で定義されたＩＮＦＯをサポート
しなくてはなりません(MUST)。この文書がＤＴＭＦ数字を運ぶ情報の使用を
定めたり保証したりしないことに注意してください。
Gateways MUST accept "405 Method Not Allowed" and "501 Not
Implemented" as non-fatal responses to INFO requests - that is, any
call in progress MUST NOT be torn down if a destination so rejects an
INFO request sent by a gateway.
ゲートウェイがＩＮＦＯ要求に対する致命的でない応答"405 許されない方法"
と"501 未実装"を受け入れなくてはなりません(MUST)、すなわち、もし宛先
がゲートウェイから送られてきたＩＮＦＯ要求を拒絶した場合、処理中の呼
を止めてはなりません(MUST NOT)。
5.7 Privacy Protection
5.7 プライバシー保護
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.
ＩＳＵＰは表示制限の概念を持っています−ユーザーが自分の電話番号（多
分呼び出し者のＩＤ）を電話をしている相手に示すことを好まない事を明示
するメカニズム。ゲートウェイが表示制限を必要とするＩＳＵＰ要請を受け
取る時、なんらかの方法で呼び出し者の識別子を保護しなくてはなりません。
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].
基本となるＳＩＰプロトコルはユーザーが匿名であることを明示する方法を
サポートします。しかしながら、このシステムは多くの限界を持ちます−例
えば、これはゲートウェイ自身の識別子を明らかにし、これはプライバシー
に影響を与える情報であり得ます。それ故にゲートウェイがより洗練された
プライバシーシステムをサポートするかもしれません。（識別子管理システ
ムとうまく相互作用する）完全に機能するプライバシー交渉をサポートする
方法を供給するメカニズムの１つが[9B]で記述されます。
5.8 CANCEL causes
5.8 中止理由
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.
ＩＳＵＰは呼設定の試みを中止したいと合図する方法があります−汎用目的
切断メッセージ（ＲＥＬ）が順方向に送られます。ＳＩＰに類似の概念があ
ります−ＳＩＰダイアログの設定を中止するための送られるＣＡＮＣＥＬ要
求です。しかしながら、様々な理由で、ＣＡＮＣＥＬ要求にメッセージ本体
を含めることができません、それ故ＳＩＰで中継する場合にＲＥＬの重要情
報（原因コード）をエンドエンドで運ぶために、ＩＳＵＰカプセル化を使う
ことができません。
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].
通常、これは大きな問題ではありません、なぜなら実際の呼設定を中止する
ＲＥＬでこれまで表示されている唯一の理由はユーザーが呼び出しがなって
いる間に電話を切る事だからです（「標準クリア」の原因コード）。しかし
ながら、大災害のネットワーク故障のような例外的な条件の下で、ＲＥＬが
別の原因コードを送り、ＳＩＰネットワークがエンドエンドで原因コードを
運べれば、有用かもしれません。それ故にゲートウェイがこのような障害理
由をエンドエンドで運ぶメカニズムをサポートするかもしれません。この能
力を供給するメカニズムの１つが[9]で記述されます。
6. Mapping
6. 翻訳
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.
ＩＳＵＰとＳＩＰ間の翻訳は呼フロー図と状態遷移図を使って記述されます。
１つの状態遷移図がＳＩＰからＩＳＵＰの呼を、第二がＩＳＵＰからＳＩＰ
を処理します。理解を容易にするため、ある再送とある状態（復旧完了メッ
セージ−ＲＬＣ待ちや、ＳＩＰ確認待ちなど）のような細部を記載していま
せん。
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'はＩＮＶＩＴＥ要求をゲートウェイが受信したこと
を示し、受信処理はこの文書の７.２.１章で記述されます。
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.
ゲートウェイが７.１章と８.１章で記述された呼フローと機能的に同等な実
行をすることが勧められます(RECOMMENDED)。これらのフローからの逸脱は、
国内ＩＳＵＰをサポートするためや、あるいは１５章で推薦された保守的な
ポリシーのどれかをサポートするためなら許されます。
7. SIP to ISUP Mapping
7. ＳＩＰからＩＳＵＰへの翻訳
7.1 SIP to ISUP Call flows
7.1 ＳＩＰからＩＳＵＰへの呼フロー
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.
次の呼フローは、ＳＩＰネットワークから始めらた呼を設定する時の、典型
的な成功とエラーの場合のメッセージの順序を例示します。ＩＮＶＩＴＥ要
求の"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."
これらの図で、すべての（ＳＩＰ、ＩＳＵＰ）呼信号はＭＧＣとです；メディ
ア操作（例えば、音声カットスルー、トランク開放）は、ＭＧＣの制御の下
で、ＭＧによって行われます。単純かのため、これらは「ＭＧＣ／ＭＧ」と
表記したひとつのノードで示します。
7.1.1 En-bloc Call Setup (no auto-answer)
7.1.1 En-bloc呼設定（自動応答なし）
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. ＳＩＰユーザがＰＳＴＮユーザへのセッションの開始を望む時、ＳＩＰ
ノードはＩＮＶＩＴＥ要求します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. ＩＮＶＩＴＥ要求を受信したゲートウェイはそれをアドレスメッセージ
（ＩＡＭ）に翻訳しＩＳＵＰネットワークに送ります。
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
3. ＩＳＵＰノードはアドレスが呼設定に十分であることを示すためにアド
レス完了メッセージ（ＡＣＭ）を返送します。
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. ＡＣＭメッセージの「着信者状態」コードが（７.２.５章と７.２.６章
で記述されるように）ＳＩＰ肯定回答に翻訳され、ＳＩＰノードに返さ
れます。この回答は（図に示されるように）早期メディアストリームを
確立するためのＳＤＰを含んでいるかもしれません。もしＳＤＰが存在
していないなら、音声はステップ８の後に両方向で確立されるでしょう。
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. もしＩＳＵＰ方言が許すなら、ＩＳＵＰノードは、例えば、呼が転送さ
れることを示すいろいろな呼経過メッセージ（ＣＰＧ）を送信するかも
しれません。
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. ＣＰＧメッセージを受信したゲートウェイはイベントコードをＳＩＰ暫
定回答に翻訳し（７.２.９章参照）、ＳＩＰノードに送ります。
7. Once the PSTN user answers, an Answer (ANM) message will be sent
to the gateway.
7. ＰＳＴＮユーザが応答すると、応答メッセージ（ＡＮＭ）がゲートウェ
イに送られるでしょう。
8. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node.
8. ＡＮＭを受信したゲートウェイはＳＩＰノードに２００メッセージを送
るでしょう。
9. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
9. ＩＮＶＩＴＥ最終回答（２００）を受信したＳＩＰが、受信確認を送り
ます。
7.1.2 Auto-answer call setup
7.1.2 自動応答呼設定
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.
このフローがＡＮＳＩネットワークでサポートされないことに注意してくだ
さい。
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
1. ＳＩＰユーザがＰＳＴＮユーザへセッションを始めることを望む時、Ｓ
ＩＰノードはＩＮＶＩＴＥ要求を発します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. ＩＮＶＩＴＥ要求を受信したゲートウェイはこれをアドレスメッセージ
（ＩＡＭ）に翻訳し、ＩＳＵＰネットワークに送ります。
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. ＩＳＵＰノードが自動応答の設定をされてるので、ＩＡＭを受信すると
接続メッセージ（ＣＯＮ）を送るでしょう。（ＡＮＳＩでは、このメッ
セージは応答メッセージ（ＡＮＭ）でしょう）。
4. Upon receipt of the CON, the gateway will send a 200 message to
the SIP node.
4. ＣＯＮを受信したゲートウェイはＳＩＰノードに２００メッセージを送
るでしょう。
5. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
5. ＩＮＶＩＴＥ最終回答（２００）を受信したＳＩＰノードが、受信確認
を送るでしょう。
7.1.3 ISUP T7 Expires
7.1.3 ＩＳＵＰタイマＴ７タイムアウト
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. ＳＩＰユーザがＰＳＴＮユーザにセッションを始めることを望む時、Ｓ
ＩＰノードはＩＮＶＩＴＥ要求を発します。
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. ＩＮＶＩＴＥ要求を受信したゲートウェイはこれをアドレスメッセージ
（ＩＡＭ）に翻訳し、ＩＳＵＰネットワークに送ります。ＩＳＵＰタイ
マＴ７はこの時点で開始します。
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. ＩＳＵＰタイマＴ７はアドレス完了メッセージ（ＡＣＭ）か接続メッセー
ジ（ＣＯＮ）の受信前にタイムアウトし、切断メッセージ（ＲＥＬ）が
呼を中止するために送られます。
4. A gateway timeout message is sent back to the SIP node.
4. ゲートウェイタイムアウトメッセージをＳＩＰノードに送ります。
5. The SIP node, upon receiving an INVITE final response (504), will
send an ACK to acknowledge receipt.
5. ＩＮＶＩＴＥ最終回答（５０４）を受信したＳＩＰノードが、受信確認
を送るでしょう。
7.1.4 SIP Timeout
7.1.4 ＳＩＰタイムアウト
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. ＳＩＰユーザがＰＳＴＮユーザへセッションを始めることを望む時、Ｓ
ＩＰノードはＩＮＶＩＴＥ要求を発します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. ＩＮＶＩＴＥ要求を受信したゲートウェイはこれをアドレスメッセージ
（ＩＡＭ）に翻訳し、ＩＳＵＰネットワークに送ります。
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. ＩＳＵＰノードが自動応答に設定されてるので、ＩＡＭを受信すると接
続メッセージ（ＣＯＮ）を送るでしょう。ＡＮＳＩ流では、ＣＯＮで
はなく応答メッセージ（ＡＮＭ）（ＡＣＭなしで）が送られるでしょ
う。
4. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node and set SIP timer T1.
4. ＡＮＭを受信したゲートウェイはＳＩＰノードに２００メッセージを送
り、ＳＩＰタイマーＴ１を開始するでしょう。
5. The response is retransmitted every time the SIP timer T1
expires.
5. ＳＩＰタイマＴ１がタイムアウトする毎に回答が送られるでしょう。
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. 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. 呼を中止するため、ＳＩＰノードにＢＹＥが送られます。ＳＩＰノード
状態がこのシナリオではっきりしないので、これ以降の操作は記述して
いません。
8. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
8. 切断メッセージ（ＲＥＬ）を受信したＩＳＵＰノードは復旧完了メッセー
ジ（ＲＬＣ）で返事するでしょう。
7.1.5 ISUP Setup Failure
7.1.5 ＩＳＵＰ呼設定失敗
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. ＳＩＰユーザーがＰＳＴＮユーザーへセッションを始めることを望む時、
ＳＩＰノードはＩＮＶＩＴＥ要求を発っします。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. ＩＮＶＩＴＥ要求を受信したゲートウェイはこれをアドレスメッセージ
（ＩＡＭ）に翻訳し、ＩＳＵＰネットワークに送ります。
3. Since the remote ISUP node is unable to complete the call, it
will send a REL.
3. ＩＳＵＰノードが呼接続を完了できないので、切断メッセージ（ＲＥＬ）
を送るでしょう。
4. The gateway releases the circuit and confirms that it is
available for reuse by sending an RLC.
4. ゲートウェイは回線を開放し、復旧完了メッセージ（ＲＬＣ）を送って
再利用可能であることを確認します。
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. ゲートウェイはＳＩＰエラー回答にＲＥＬの原因コードを翻訳し（７.
２.４章参照）、ＳＩＰノードに送ります。
6. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
6. ＳＩＰノードはＩＮＶＩＴＥ最終回答の受信確認をります。
7.1.6 Cause Present in ACM Message
7.1.6 ＡＣＭメッセージでの理由表示
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. ＳＩＰユーザがＰＳＴＮユーザへのセッションを始めることを望む時、
ＳＩＰノードはＩＮＶＩＴＥ要求を発します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. ＩＮＶＩＴＥ要求を受信したゲートウェイはこれをアドレスメッセージ
（ＩＡＭ）に翻訳し、ＩＳＵＰネットワークに送ります。
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. ＩＳＵＰノードが呼を完了できないので、エラートーン／アナウンスを
生成することを望み、アドレス完了メッセージ（ＡＣＭ）で原因コード
を送ります。ゲートウェイはインターワークタイマーを起動させます。
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. ＡＣＭを受信した（ＣＡＩパラメータがある）ら、ゲートウェイはＳＩ
Ｐノードに１８３メッセージを生成するでしょう；これは早期メディア
カットスルーを確立するＳＤＰを含んでいます。
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. 以前のＡＣＭメッセージで受信した原因コードに基づいて、呼を終了す
るためにＩＮＶＩＴＥ最終回答が生成され、ＳＩＰノードに送られます。
原因コードからＳＩＰ回答への翻訳表は７.２.４.１章を見てください。
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. インターワークタイマーが切れると、呼を終了するために切断メッセー
ジ（ＲＥＬ）がＰＳＴＮノードに送られます。ＳＩＰノードがインター
ワークタイマーが期限が切れる前に、ＣＡＮＣＥＬを送ることで同じく
要求を終了できることに注意してください。この場合、信号は７.１.７
章のように進行します。
7. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
7. ＲＥＬメッセージを受信すると、ＩＳＵＰノードは復旧完了メッセージ
（ＲＬＣ）で応答するでしょう。
8. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
8. ＳＩＰノードはＩＮＶＩＴＥ最終回答の受信確認を送ります。
7.1.7 Call Canceled by SIP
7.1.7 ＳＩＰの中止した呼
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. ＳＩＰユーザーがＰＳＴＮユーザーへセッションを始めることを望む時、
ＳＩＰノードはＩＮＶＩＴＥ要求を発します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. ＩＮＶＩＴＥ要求を受信したゲートウェイはこれをアドレスメッセージ
（ＩＡＭ）に変換し、ＩＳＵＰネットワークに送ります。
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
3. ＩＳＵＰノードはアドレス完了メッセージ（ＡＣＭ）を送る事で、呼設
定に十分なアドレスであることを示します。
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. ＡＣＭメッセージの「着信者状態」コードが（７.２.５章と７.２.６章
で記述されるように）ＳＩＰ暫定回答に翻訳され、ＳＩＰノードに返さ
れます。この回答は早期メディアストリームを確立するＳＤＰを含んで
いるかもしれません。
5. To cancel the call before it is answered, the SIP node sends a
CANCEL request.
5. 応答前に、電話を中止するために、ＳＩＰノードはＣＡＮＣＥＬ要求を
送ります。
6. The CANCEL request is confirmed with a 200 response.
6. ＣＡＮＣＥＬ要求は２００回答で確認されます。
7. Upon receipt of the CANCEL request, the gateway sends a REL
message to terminate the ISUP call.
7. ＣＡＮＣＥＬ要求を受信したゲートウェイはＩＳＵＰ呼を終える切断
メッセージ（ＲＥＬ）を送ります。
8. The gateway sends a "487 Call Cancelled" message to the SIP node
to complete the INVITE transaction.
8. ゲートウェイはＩＮＶＩＴＥ処理を完了するためにＳＩＰノードに
"487 Call Cancelled"メッセージを送ります。
9. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
9. ＲＥＬメッセージを受信したＩＳＵＰノードは復旧完了（ＲＬＣ）
メッセージで応答するでしょう。
10. Upon receipt of the 487, the SIP node will confirm reception
with an ACK.
10. ４８７を受信したＳＩＰノードは受信確認を送るでしょう。
7.2 State Machine
7.2 状態遷移図
Note that REL can be received in any state; the handling is the same
for each case (see Section 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 +------------>+
+-------------------------+
7.2.1 INVITE received
7.2.1 ＩＮＶＩＴＥ受信
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.
ＩＮＶＩＴＥ要求をゲートウェイが受信すると、ゲートウェイが呼を処理し
ていることを示しす"100 Trying"回答がＳＩＰネットワークに送られるかも
しれません(MAY)。
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).
アドレスメッセージ（ＩＡＭ）がリソース予約（特にＴＣＩＣ選択）の前に
送ることができないので、メディアストリームに必要なハードウェア資源は
ＩＮＶＩＴＥを受信したときにゲートウェイで確保されなければなりません
(MUST)。典型的に資源はＥ１／Ｔ１のタイムスロットとＩＰ側のＲＴＰ／Ｕ
ＤＰポートから成ります。資源にはサービス品質の準備を含むかもしれませ
ん（このような習慣はこの文書で勧められません）。
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.
ＩＡＭを送った後で、タイマーＴ７が開始します。Ｔ７のデフォルト値は
２０秒から３０秒です。ゲートウェイは'Trying'状態に遷移します。
7.2.1.1 INVITE to IAM procedures
7.2.1.1 ＩＡＭ手順へのＩＮＶＩＴＥ
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.
この章はＩＮＶＩＴＥメッセージのＳＩＰヘッダと、アドレスメッセージ
（ＩＡＭ）のＩＳＵＰパラメータへの翻訳を記述します。ＰＳＴＮ−ＳＩＰ
ゲートウェイが、ＩＮＶＩＴＥを受信すると、ＩＡＭを作ることに責任があ
ります。
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.
５つの必須パラメータがＩＡＭメッセージ中に現われます：着信者番号（Ｃ
ＰＮ）、接続表示（ＮＣＩ）、順方向呼表示（ＦＣＩ）、発信者種別（ＣＰ
Ｃ）、呼の望ましいベアラを示すパラメータ−、あるＩＳＵＰ方言で中継条
件条件（ＴＲＴ）、他の方言でユーザーサービス情報（ＵＳＩ）、または両
方が必要です。すべてのＩＡＭメッセージは最小限これらの５つのパラメー
タを含んでいなくてはなりません(MUST)。それで、すべてのゲートウェイは
ＩＮＶＩＴＥを受信する時、それら５つのパラメータのそれぞれを生成する
手段を持っていなくてはなりません。（ＮＣＩやＵＳＩのような）パラメー
タに現われるであろう値の多くが各ゲートウェイの作ったＩＡＭで同じ可能
性が高いでしょう。（ＣＰＮなど）他のものは呼毎に変化するでしょう；ゲー
トウェイは正確にこれらのパラメータを生成するためにＩＮＶＩＴＥから情
報を抽出します。
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)).
ＩＡＭメッセージには多くのオプションパラメータがあります；Ｑ．７６３
[17]が全部で２９個をリストアップします。しかしながら、これらのパラメー
タのそれぞれをＳＩＰ−ＩＳＵＰ翻訳を成し遂げるために翻訳する必要があ
りません。上記の様に、翻訳はカプセル化したＩＳＵＰを理解できないＳＩ
Ｐネットワークに、セッションの基本ＰＳＴＮ要素（誰へなど）を理解させ
る事です。ＰＳＴＮにだけ意味があるパラメータがカプセル化によってＰＳ
ＴＮ−ＳＩＰ−ＰＳＴＮネットワークを通して運ばれ、これらのパラメータ
に翻訳は必要ありません。前記の２９個のオプションパラメータのうち、次
だけがすぐに翻訳して役立ちます：発信者番号（ＣＩＮ、通常存在する）、
中継網選択（ＴＮＳ）、キャリア識別パラメータ（ＣＩＰ、ＡＮＳＩネット
ワークで存在する）、オリジナル着番号（ＯＣＮ）、汎用デジット（ある方
言で汎用アドレスパラメータ（ＧＡＰ）として知られている）。
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.
ＳＩＰ−ＩＮＶＩＴＥがＰＳＴＮゲートウェイに到着する時、ゲートウェイ
は外向きＰＳＴＮ信号を生成するためＩＮＶＩＴＥの中のカプセル化したＩ
ＳＵＰを使おうと試みるべきです(SHOULD)（[3]参照）、しかし１５章のセ
キュリティの考察に注意するべきです(SHOULD)。もし可能なら、ゲートウェ
イはカプセル化したＩＡＭのＩＳＵＰパラメータ値を、ＰＳＴＮインタフェー
スに送るであろうＩＡＭを生成するため、再利用するべきです(SHOULD)。あ
る場合に、ゲートウェイはＩＳＵＰを利用することが不可能でしょう−例え
ば、もしゲートウェイがＩＳＵＰ方言を理解することができなくて、カプセ
ル化本体を無視しなくてはならない場合です。理解可能なカプセル化ＩＳＵ
Ｐがある時さえ、カプセル化ＩＳＵＰに基づく翻訳のプロセスで、ＳＩＰヘッ
ダーフィールドの適切な値をパラメータ値に「上書きしなくて」はなりませ
ん(MUST)。言い換えれば、ＩＳＵＰ−ＳＩＰ−ＩＳＵＰブリッジで、ＳＩＰ
ネットワークで作られた重大セッション情報パラメータの更新はカプセル化
ＩＳＵＰより優先です。これは、種々の種類の転送電話含む、多くの基本的
なサービスをＳＩＰネットワークに実装することを許します。
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.
例えば、もし受信したＩＮＶＩＴＥがにカプセル化ＩＡＭが含まれていて、
ＩＡＭのＣＰＮフィールドが電話番号+12025332699を示していて、しかし、
ＩＮＶＩＴＥの要求ＵＲＩが'tel:+15105550110'であるなら、ゲートウェイ
はＰＳＴＮに送るＩＡＭを生成する際にカプセル化ＩＡＭの値ではなく要求
ＵＲＩの中の電話番号を使わなければなりません(MUST)。ＳＩＰヘッダーフィー
ルドをＩＳＵＰパラメータに翻訳する方法の細部は以下に続きます。
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.
ゲートウェイはカプセル化ＩＳＵＰがない場合に（ＮＣＩやＴＭＲパラメー
タのような）翻訳で得られない必須ＩＳＵＰパラメータのデフォルト値を供
給しなければなりません(MUST)。ＦＣＩパラメータも同デフォルトを持たな
ければなりません(MUST)、もし下記のオプションの番号ポータビリティ翻訳
メカニズムが使われるなら「Ｍ」ビットのデフォルトだけが上書きされるか
もしれません。
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.
ＩＡＭパラメータへのＩＮＶＩＴＥメッセージフィールドの翻訳の第一歩は
要求ＵＲＩの点検です。
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.
もしゲートウェイが任意の番号ポータビリティをサポートするなら、次の要
求ＵＲＩの'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.
もし要求ＵＲＬに'npdi=yes'フィールドがなければ、ＵＲＬの主電話番号
（'tel:'の直後に続く桁）が、１２章で記述されＣＰＮパラメータを設定す
るために使われた手順に従って、ＩＳＵＰフォーマットに変換されなければ
なりません(MUST)。
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.
もし'npdi=yes'フィールドが要求ＵＲＩに存在するなら、ＩＡＭの中で「番
号翻訳」のためのＦＣＩパラメータビットは、番号ポータビリティが行われ
たことを示さなくてはなりません(MUST)。
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='フィールドが存在するなら、ｔｅｌ
ＵＲＬの主電話番号はＩＳＵＰフォーマットに変換され（１２章参照）、Ｃ
ＰＮパラメータを生成するのに使われなくてはなりません(MUST)。これはポー
タビリティが起きたが、着番号がポートされなかったことを示します。
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='フィールドが存在していないなら、
ＡＮＳＩのＩＳＵＰで'rn='フィールドはＩＳＵＰフォーマットに変換されて、
ＣＰＮを生成するために使われなくてはなりません(MUST)。ｔｅｌＵＲＬの
主電話番号はＩＳＵＰフォーマットに変換され、汎用デジットパラメータ
（あるいはＡＮＳＩのＧＡＰ）を生成するために使われなくてはなりません
(MUST)。他のＩＳＵＰ方言で'rn='で与えられた数は（接頭辞あるいはセパレー
タの有無にかかわらず）主電話番号に前に設定され、結合結果はＣＰＮを生
成するのに使われなくてはなりません(MUST)。'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:'の直後の番号）は、１２章で記述されてＣＰＮパラ
メータを設定するために使われた手順に従って、ＩＳＵＰフォーマットに変
換されなければなりません(MUST)。
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.
もし要求ＵＲＬの主電話番号と、Ｔｏヘッダの電話番号が不一致なら、Ｔｏ
ヘッダがＯＣＮパラメータを設定するのに使われるべきです(SHOULD)。さも
なければヘッダーは無視されるべきです(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.
ある任意の翻訳手順がキャリアベースのルーティングで提供されます。もし
'cic='パラメータが要求ＵＲＩに存在しているなら、ゲートウェイはこのＩ
ＡＭのキャリア識別コード（ＣＩＣ，ＭＴＰ３の「回線識別コード」と混同
しないこと）を伝達することが適当である事を確かめるローカルポリシーを
調べるべきす(SHOULD)；もしゲートウェイが多くの他に依存しないトランク
スをサポートするなら、ＣＩＣで識別されたキャリアを指し示す特定のトラ
ンク、あるいはそのキャリアに到達可能な協力者を選択する必要があるかも
しれません。
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.
このようなトランクスのためのポリシーが（トランクスが関連したキャリア
と使用中のＩＳＵＰ方言の優先に基づいて）ＣＩＣを運ぶためにＣＩＰを使
うかＴＮＳを使うか指示するべきです(SHOULD)。事前設定されたポリシーが
なければ、ＣＰＮパラメータが国際フォーマットなら、ＴＮＳが使われるべ
きで（つまり、要求ＵＲＬのｔｅｌＵＲＬ部が'+'で始まり、ｋろえは国際
フォーマットのＣＰＮを生成します）、他の場合はＣＩＰが使われるべきです。
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.
ＳＩＰ呼がゲートウェイに来たとき、要求ＵＲＬはｔｅｌＵＲＬ（あるいは
ｔｅｌＵＲＬ部を持つＳＩＰＵＲＬ）を含む可能性が高いです−正しい電話
番号を含んでいない要求ＵＲＬを受信したＳＩＰ−ＩＳＵＰゲートウェイが
適切な回答コードでこのような要求を拒絶するべきです(SHOULD)。しかしな
がら、もし呼がＳＩＰ−ＵＲＩのuser@host形式を使用するＳＩＰ電話からの
発信の場合にしばしばあるように、ゲートウェイは電話番号を含むＦｒｏｍ
ヘッダフィールドで要求を処理し続けるべきです(SHOULD)。Ｆｒｏｍフィー
ルドが使用できないならＣＩＮパラメータは外行きＩＡＭから削除されるべ
きです(SHOULD)。代わりに、ゲートウェイ実装者が特定のＳＩＰ−ＵＲＩか
ら電話番号への非標準の翻訳を考えるかもしれないことに注意してください。
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).
ゲートウェイが（理解可能な）カプセル化ＩＳＵＰを含むメッセージを受信
した時、インターワーク関連ビットが同じ値を持つように、生成したＩＡＭ
のＦＣＩ表示を設定しなければなりません(MUST)。たいていの場合、呼パス
でインターワークがなければ、これらの表示はインターワークなしを示すで
しょう。もしゲートウェイが受信したＩＮＶＩＴＥに利用可能なカプセル化
したＩＳＵＰがないなら、ゲートウェイがＦＣＩのインターワーク表示ビッ
トをインターワークなしに、ＩＳＤＮユーザ部表示を「全経路でＩＳＵＰ使
用」を設定することが強く推薦されています (STRONGLY RECOMMENDED)；ゲー
トウェイは発アクセス表示を「発アクセス非ＩＳＤＮ」を設定するかもしれ
ません（一般に、ＳＩＰ電話がＩＳＤＮ終端サービスをサポートすると仮定
するのは安全でなく、この文書での手順はこのようなサービスの翻訳を記述
しません）。
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.
ＩＡＭのＦＣＩパラメータの「インターワークあり」が設定されるとき、こ
れはＩＳＵＰサービスの一部を供給できないネットワークとインターワーク
していることを示すことに注意してください。従ってＩＳＵＰネットワーク
が、障害時の原因コードなど（反対に、音声アナウンスの後にＡＣＭを送る）、
通常使用する機能の一部を使用しないでしょう。もし望むならゲートウェイ
のベンダーが、サービスプロバイダの裁量で利用可能な、カプセル化ＩＳＵ
Ｐがない場合に、ＦＣＩでインターワークあり（エンドエンドＩＳＵＰでは
ない）を示すオプションを供給してもよいです；しかしながら、こうすると
ＳＩＰ−ＩＳＵＰ翻訳の効率と透明度を制限するかもしれません。
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.
ＩＳＤＮノードであると主張すると、ＩＳＤＮユーザユーザサービスの着信
者からの要求をがあるかもしれません。ユーザユーザサービス１と２が発信
者からしか求められなくてはならないので、それらは問題がありません
（[14]参照）。ユーザユーザサービス３は着信者が要求できます。非ＳＩＰ
ブリッジ状態で、ＭＧＣはこのサービス要求を拒絶できるべきです。
7.2.2 ISUP T7 expires
7.2.2 ＩＳＵＰタイマＴ７タイムアウト
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.
ＰＳＴＮから回答がないと、ＭＧのすべての資源は解放されます。'504
Server Timeout'がＳＩＰネットワークに送り返されるべきです(SHOULD)。
ＲＥＬメッセージの理由値１０２（プロトコルエラー、タイマー終了での回
復）がＰＳＴＮに送られるべきです(SHOULD)。ゲートウェイがＰＳＴＮから
ＲＬＣ応答を期待でき、ＳＩＰネットワークから開放シーケンスが完了した
ことを示す確認を期待できます。
7.2.3 CANCEL or BYE received
7.2.3 ＣＡＮＣＥＬかＢＹＥの受信
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.
もしＣＡＮＣＥＬかＢＹＥ要求が最終ＳＩＰ応答前に送られたら、ＣＡＮＣ
ＥＬかＢＹＥの確認のため'200 OK'をＳＩＰネットワークに送らなくてはな
りません(MUST)、ＩＮＶＩＴＥ処理を終えるために487が送られなくてはなり
ません(MUST)。すべての資源は開放され、原因値１６のＲＥＬメッセージが
ＰＳＴＮに送られるべきです（標準クリア）(SHOULD)。ゲートウェイが開放
処理が完了したことを示すＰＳＴＮからのＲＬＣの受信を期待できます。
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.
ＳＩＰブリッジの場合、ＲＥＬがＢＹＥ要求の本体にカプセル化されるかも
しれません。ＢＹＥが通常コード１６（標準クリア）に翻訳されるが、例外
的な状況の下でＲＥＬメッセージでの原因コードは異なるかもしれません。
それ故にカプセル化ＲＥＬの原因表示パラメータはＰＳＴＮに送るＲＥＬで
再度使われるべきです。
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.
ＢＹＥかＣＡＮＣＥＬ要求が原因表示パラメータに翻訳されるべき(SHOULD)
Ｒｅａｓｏｎヘッダを含むかもしれないことに注意してくださいです（５.８
章参照）。もしＢＹＥがＲｅａｓｏｎヘッダーとカプセル化ＩＳＵＰの両方
を含んでいるなら、Ｒｅａｓｏｎヘッダの値が優先です(MUST)。
All the resources in the gateway SHOULD be released before the
gateway sends any REL message.
ゲートウェイのすべての資源は、ゲートウェイがＲＥＬメッセージを送る前
に開放されるべきです(SHOULD)。
7.2.4 REL received
7.2.4 ＲＥＬ受信
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.
この章は、最終ＳＩＰ回答が送られる前に、ＲＥＬを受信した場合に適用し
ます。この状態は典型的に、要求がＰＳＴＮによって拒絶された時に生じま
す。
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)、回線の再利用が可能
なことを示すためにＩＳＵＰネットワークにＲＬＣを送らなくてはなりませ
ん(MUST)。
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.
この処理を解したＩＮＶＩＴＥが正しくて理解可能なカプセル化ＩＳＵＰメッ
セージを含むなら（すなわち、ＩＡＭの方言をゲートウェイがサポートし、
なるべくディジタル署名があるなら）、（これがＩＳＵＰ−ＳＩＰ−ＩＳＵ
Ｐブリッジを暗示するので）可能ならカプセル化ＩＳＵＰがＩＮＶＩＴＥの
回答で送られるべきです(SHOULD)−それ故に、受信したＲＥＬメッセージを
ＳＩＰ回答の本体に含むべきです(SHOULD)。もしＩＮＶＩＴＥの発信者がＩ
ＳＵＰをカプセル化しないなら、ゲートウェイはカプセル化ＩＳＵＰを回答
で返すべきではありません(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.
ＩＡＭに対して、閉塞メッセージ（ＢＬＯ）やリセットメッセージ（ＲＳＣ）
（又は同様な回線群メッセージ）のようなある保守メッセージの受信はこの
状態の呼を解放する事に注意してください。保守メッセージのための動作が
１１章で与えられます。
7.2.4.1 ISDN Cause Code to Status Code Mapping
7.2.4.1 ＩＳＤＮ原因コードから状態コードへの翻訳
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).
ＳＳ７ネットワークでのＲＥＬメッセージの使用は非常に一般的であるのに
対して、ＳＩＰにはＲＥＬと同じ役割を演ずる多くの特殊なツールがありま
す−ＢＹＥとＣＡＮＣＥＬとステータス／応答コード。ＲＥＬが通話中の呼
を開放し（ＢＹＥ）、完了していない呼設定要求を中止し（ＣＡＮＣＥＬ）、
受信した呼設定要求（ＩＡＭ）を拒否（ＳＩＰステータスコードに対応）し
ます。
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.
あるＩＳＵＰ原因コードがゲートウェイのＩＳＵＰインターフェースでだけ
意味があるので、これらのコードをＳＩＰメッセージへ翻訳するのは必ずし
も適切ではないことに注意してください。これの良い例は原因コード４４の
「要求回線かチャネルが利用不可」です。４４は受信装置がＩＡＭを受取っ
たＣＩＣが新しい呼設定に不適当な状態であると信じていることを示します
−しかしながら、この場合の初側交換機の適切な行動は呼を開放ではなく、
異なるＣＩＣでのＩＡＭ再送です。明らかに新しいＣＩＣを選択したことを
示すＳＩＰステータスコードはありません（ないべきです）−この問題はゲー
トウェイに内部にあります。それ故原因コード４４の受信の結果としてＳＩ
Ｐステータスコードを送るべきでありません；原因コードは翻訳不可能です。
If a cause value other than those listed below is received, the
default response '500 Server internal error' SHOULD be used.
もし以下にリストアップしたの以外の値の原因を受信したら、デフォルト回
答'500 Server internal error'が使われるべきです(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.
最終的にＩＳＵＰ原因コードのほかに、ＣＡＩパラメータがネットワークの
どのエンティティーが呼を終結した責任があるかについて（最も重要な区別
はユーザかネットワークか）、意味を与える原因「場所」を含んでいます。
たいていの場合、場所がＳＩＰステータスコードの翻訳に影響を与えません；
いくつかの例外は以下です。診断フィールドがあるＩＳＤＮの目的で存在し
ているかもしれません；この診断は呼終了に関して追加のデータを含んでい
るでしょう。
The following mapping values are RECOMMENDED:
次の値翻訳が推薦されます(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
(*) ＩＳＤＮ原因１６は通常ＢＹＥかＣＡＮＣＥＬをもたらすでしょう。
(+) If the cause location is 'user' than the 6xx code could be given
rather than the 4xx code (i.e., 403 becomes 603)
(+) もし原因場所が'user'なら、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.
(=) ＡＮＳＩ手順−ＡＮＳＩネットワークで、２６が「ポート番号転送失敗」
ことを示すため事に上書きされています。多分、番号ポータビリティが前の
ネットワークで行われるべきでした。さもなければ理由２６が通常ＩＳＵＰ
手順で使われません。
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.
ＩＳＤＮ理由２２（番号変更）のＲＥＬが診断のフィールドに受信者に到達
可能かもしれない新しい番号の情報を含んでいるかもしれません。もしＭＧ
Ｃがこの情報を処理可能であるなら、ＳＩＰ回答（３０１）のＣｉｎｔａｃ
ｔヘッダに加えるべきです(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
7.2.5 Early ACM received
7.2.5 早期ＡＣＭ受信
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).
ＡＣＭメッセージが着信者を呼び出し中である事を示すためではなく、ＩＳ
ＵＰタイマを満足させるため、呼処理中であることを示すため送られます。
これは例えば移動ネットワークで起こり、ローミングは呼設定を遅らせます。
早期ＡＣＭはユーザ呼び出し前に送られ、Ｔ７タイマをリセットし、Ｔ９タ
イマを開始します。もしＡＣＭの着信者状態表示が００（表示）に設定され
ていない、「早期ＡＣＭ」であると思われます。
After sending an early ACM, the ISUP network can be expected to
indicate the further progress of the call by sending CPGs.
早期ＡＣＭを送った後で、ＩＳＵＰネットワークはＣＰＧを送ることで呼の
経過を示すことを期待されます。
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.
早期ＡＣＭを受信したゲートウェイはＳＩＰネットワークに１８３セッショ
ン進捗回答（[1]参照）を送るべきです(SHOULD)。（呼を開始したＩＮＶＩＴ
Ｅにカプセル化ＩＳＵＰが含まれる）ＳＩＰブリッジ状態で早期ＡＣＭは同
じく回答本体に含められるべきです(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.
ゲートウェイがアドレスが完全であるという確認（ＡＣＭ）を得る前に、１
８３を送ることはＳＩＰブリッジの場合に既知の問題を発生し、従ってこれ
を送るべきではない(SHOULD NOT)ことに注意してください。
7.2.6 ACM received
7.2.6 ＡＣＭ受信
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.
最も一般的に、ＡＣＭを受信した場合、暫定応答（18xクラス）がＳＩＰネッ
トワークに送られるべきです(SHOULD)。もしこのセッションを始めたＩＮＶ
ＩＴＥが正しく理解可能なカプセル化ＩＳＵＰを含むなら、ゲートウェイは
受信したＡＣＭを暫定回答にカプセル化すべきです(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).
もしＡＣＭに「加入者空き」の逆方向呼表示が含まれている場合、ゲートウェ
イは'180 Ringing'応答を送るべきです(SHOULD)。180が送られる時は、早期
メディア拡張がなくても、ゲートウェイが応答を送るするＳＩＰユーザエー
ジェント（ゲートウェイかもしれない）によって必要な呼び出し音がローカ
ルに生成されると想定されます。
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.
もしＡＣＭｎｏ逆方向呼表示（ＢＣＩ）パラメータがインターワークありを
示すなら（一般にＩＳＵＰネットワークがＡＣＭを送るのはアウトバンド信
号で状態を送れない旧式ネットワークとのインターワークを示します）、ビ
ジートーンや発信者割り込みメッセージなどのインバンドの呼状態のアナウ
ンスがあるかもしれず、可能なら、逆方向メディア伝送が始められるべきで
す。もしインバンドメディアのオプション逆方向呼表示パラメータフィール
ドが設定されるなら、同じく逆方向メディア伝達されるべきです(SHOULD)。
早期メディア（200 OK/ANM）の前のより多くの情報については５.５章を見て
ください。早期メディア転送が始められた後、ゲートウェイは１８３セッショ
ン進捗応答コードを送るべきです(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.
ゲートウェイがインバンド音声メディアの性質を確かめる手段を持つかもし
れません(MAY)；例えば、あるＩＳＵＰ方言で信号を検査することで決定した
り、回線上で送られる呼び出しやビジートーンの音声を聞くことで。このよ
うなゲートウェイはメディアを捨てて、（１８０あるいは４８６のような）
対応する回答コードを代わりに送ることを選ぶかもしれません(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.
ＡＣＭを受信すると多くのＩＳＵＰネットワークの交換機は“Ｔ９”として
知られるタイマーを起動し、これは通常９０秒から３分で切れます（[13]参
照）。早期メディアが送られているとき、このタイマーは発信者が一定時間
の間課金されずに遠方のＩＳＵＰネットワークの交換機からの逆方向オーディ
オメディア（呼出音かアナウンス）を聞くのを許します。着信者へ最も近い
ローカルＩＳＵＰ交換機は呼出音か音声アナウンスを生成します。もし長い
アナウンスを流さないといけない場合、ネットワークはＡＮＭを送らなけれ
ばならず、不明確な持続時間の双方向性メディアを始めます。普通のＩＳＵ
Ｐネットワーク実装で、課金処理がＡＮＭ受信時に始まります。あるネット
ワークがタイマＴ９をサポートしません。
7.2.7 CON or ANM Received
7.2.7 ＣＯＮかＡＮＭ受信
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.
ＡＣＭかＣＯＮメッセージを受信すると、呼は答えられ'200 OK'応答がＳＩ
Ｐネットワークに送られます(SHOULD)。この200 OKはＩＮＶＩＴＥで提案し
たメディアの応答を含むべきです(SHOULD)。ＳＩＰブリッジ状態で（この呼
を開始したＩＮＶＩＴＥが正しくて理解可能なカプセル化ＩＳＵＰを含む場
合）、ＩＳＵＰメッセージは200 OK応答の本体に含められます。まだ確立さ
れていない場合、ゲートウェイは双方向メディアストリームを確立しなくて
はなりません(MUST)。
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.
ある旧式ネットワークとインターワークする時、早期ＡＣＭの直後に（ＣＰ
Ｇや他のいかなる逆方向メッセージなしに）ＡＮＭを受信したり、ＡＣＭ受
信なしにＡＮＭを受信したり（自動装置が呼に応答するとき）する事はＩＳ
ＵＰ交換機に可能です。この場合、ＳＩＰユーザが決して18x暫定応答を受信
せず、着信者が応答する前に呼び出し音を聞かないでしょう。この結果、
（順方向メディア伝送が宛先からＳＤＰを獲得するまで始まらないから）発
信者からの順方向メディアの最初が欠けるかもしれません。ＩＳＤＮで
（[12]参照）これはＩＡＭを送る前に逆方向音声パスを接続することで解決
されます。
7.2.8 Timer T9 Expires
7.2.8 タイマＴ９タイムアウト
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.
（一部のネットワークで使われない）このタイマのタイムアウトは、この呼
で呼び出し開始後一定期間経ってもＡＮＭが到着しなかったことを示します。
通常、これは着信者端末が呼び出されたが誰も応答しなかったことを意味し
ます。これはインターワークの場合、ネットワークが状態のアナウンス（番
号が使われていないなど）をし、これが何回か繰り返された時にも起こるか
もしれません。長期の不完了呼の原因が何であるとしても、このタイマの期
限が切れたとき、呼は開放されなければなりません(MUST)。メディアパスと
関係があるゲートウェイ資源のすべてが開放されるべきです(SHOULD)。
'480 Temporarily Unavailable'応答がＳＩＰネットワークに送られるべきで
(SHOULD)、原因値１９のＲＥＬメッセージ（ユーザ応答なし）がＩＳＵＰネッ
トワークに送られるべきです(SHOULD)。ＰＳＴＮからはＲＬＣ応答が期待で
き、ＳＩＰネットワークからは開放処理の完了を示すＡＣＫが期待できます。
7.2.9 CPG Received
7.2.9 ＣＰＧ受信
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.
ＣＰＧは呼経過や呼出やインバンド情報を示す暫定的なメッセージです。も
しＣＰＧがインバンド情報が利用可能であることを提案するなら、ゲートウェ
イは早期メディアの転送をはじめ、逆向き一方向メディアパスを通し始める
べきです(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:
ＳＩＰブリッジ状態で（このセッションを始めたＩＮＶＩＴＥが正しく理解
可能なカプセル化ＩＳＵＰを含んでいた時）、ＣＰＧは、次のようにＣＰＧ
イベントコードから決定される特定の18x応答の、本体で送られるべきです
(SHOULD)：
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.
もしＣＰＧが「呼出」を示さないなら、現在の状態が変化しないことに注意
してください。
7.3 ACK received
7.3 ＡＣＫ受信
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.
この段階で呼は完全に接続されていて、会話ができます。ＡＣＫ受信時にゲー
トウェイはＩＳＵＰメッセージを送るべきではありません。
8. ISUP to SIP Mapping
8. ＩＳＵＰからＳＩＰへの翻訳
8.1 ISUP to SIP Call Flows
8.1 ＩＳＵＰからＳＩＰへの呼フロー
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.
次の呼フローは、ＰＳＴＮネットワークから開始した呼を設定する時、典型
的な成功とエラーの場合のメッセージの順序を例示します。ＩＮＶＩＴＥ要
求への"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".
これらの図で、すべての呼信号（ＳＩＰ、ＩＳＵＰ）はＭＧＣを通ります；
メディア処理（例えば、オーディオ通過、トランク開放）はＭＧＣの制御下
でＭＧによって実施されます。単純化のため、これらは「ＭＧＣ／ＭＧ」と
いうラベルのひとつのノードと示します。
8.1.1 En-bloc call setup (non auto-answer)
8.1.1 Enブロック呼設定（自動応答なし）
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. ＰＳＴＮユーザがＳＩＰユーザへセッションを始めることを望む時、Ｐ
ＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生成
します。
2. Upon receipt of the IAM message, the gateway generates an INVITE
message, and sends it to an appropriate SIP node.
2. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、適切なＳＩＰノードにそれを送ります。
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. 呼設定に十分なアドレス情報を持つことを示すイベントが起こる時、Ｓ
ＩＰノードは１８０以上の暫定応答を生成するでしょう。
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. １８０以上の暫定応答を受信したゲートウェイは、ＡＣＭメッセージを
生成するでしょう。もし応答が１８０ではないなら、ＡＣＭは「着信者
状態」に「表示なし」の値が設定されるでしょう。
5. The SIP node may use further provisional messages to indicate
session progress.
5. ＳＩＰノードはセッション進捗を示す暫定メッセージを使うかもしれま
せん。
6. After an ACM has been sent, all provisional responses will
translate into ISUP CPG messages as indicated in Section 8.2.3.
6. ＡＣＭを送信後は、すべての暫定応答は８.２.３章で示されるようにＩ
ＳＵＰのＣＰＧメッセージに翻訳します。
7. When the SIP node answers the call, it will send a 200 OK
message.
7. ＳＩＰノードが呼に応答する時、200 OKメッセージを返すでしょう。
8. Upon receipt of the 200 OK message, the gateway will send an ANM
message towards the ISUP node.
8. 200 OKメッセージを受信したゲートウェイはＡＮＭメッセージをＩＳＵ
Ｐノードに向かって送るでしょう。
9. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
9. ゲートウェイはＩＮＶＩＴＥ最終の回答の受信を確認するためにＳＩＰ
ノードにＡＣＫを送るでしょう。
8.1.2 Auto-answer call setup
8.1.2 自動応答呼設定
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. ＰＳＴＮユーザーがＳＩＰユーザーへセッションを始めることを望む時、
ＰＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生
成します。
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. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、着番号分析に基づいて適切なＳＩＰノードにそれを送ります。
3. Since the SIP node is set up to automatically answer the call, it
will send a 200 OK message.
3. ＳＩＰノードが自動的に呼に応答するように設定されてるので、200 OK
メッセージを送るでしょう。
4. Upon receipt of the 200 OK message, the gateway will send a CON
message towards the ISUP node.
4. 200 OKメッセージを受信したゲートウェイはＣＯＮメッセージをＩＳＵ
Ｐノードに送るでしょう。
5. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
5. ゲートウェイはＩＮＶＩＴＥ最終回答の受信を確認するためにＳＩＰノー
ドにＡＣＫを送るでしょう。
8.1.3 SIP Timeout
8.1.3 ＳＩＰタイムアウト
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. ＰＳＴＮユーザがＳＩＰユーザとセッションを始めることを望む時、Ｐ
ＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生成
します。
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. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、着番号分析に基づいて適切なＳＩＰノードにそれを送ります。
ＩＳＵＰタイマＴ１１とＳＩＰタイマＴ１が設定されます。
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. タイマＴ１がタイムアウトする毎にＩＮＶＩＴＥメッセージがＳＩＰノー
ドに送られ続けるでしょう。ＳＩＰ標準は回答を受信できなければＩＮ
ＶＩＴＥ送信が７回行われるであろうことを明示します。
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. T１１がタイムアウトした時、呼が遠隔ＩＳＵＰノードのＴ７タイマによっ
て終了するのを避けるためＡＣＭメッセージが送られるでしょう。この
ＡＣＭの「着信者状態」は「表示なし」です。
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. ＩＮＶＩＴＥ要求が最大回数送られたら、ゲートウェイは呼を終了させ
るためＲＥＬ（原因コード１８）をＩＳＵＰノードに送るでしょう。
6. The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.
6. ゲートウェイは開始の試みを終結するためにＳＩＰノードにＣＡＮＣＥ
Ｌメッセージを送ります。
7. Upon receipt of the REL, the remote ISUP node will send an RLC to
acknowledge.
7. ＲＥＬを受信した遠隔のＩＳＵＰノードは確認のためＲＬＣを送るでしょ
う。
8.1.4 ISUP T9 Expires
8.1.4 ＩＳＵＰＴ９タイムアウト
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. ＰＳＴＮユーザーがＳＩＰユーザーへセッションを始めることを望む時、
ＰＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生
成します。
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. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、着番号分析に基づいて適切なＳＩＰノードに送ります。ＩＳＵ
ＰタイマＴ１１とＳＩＰタイマＴ１が設定されます。
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. Ｔ１タイマが切れるたびに、ＩＮＶＩＴＥメッセージがＳＩＰノードに
送られます。ＳＩＰ標準は応答がなければＩＮＶＩＴＥ送信が７回行わ
れることを明示します。ＳＩＰタイマＴ１が０．５秒以上の値から開始
し、送信毎に２倍になるので、ＩＮＶＩＴＥ要求がタイムアウトするま
で１分以上かかります；ＳＩＰタイマＴ１は初期値が５００ミリセカン
ド以上で、７ ｘ ＳＩＰタイマT１はＩＳＵＰタイマT１１＋ＩＳＵＰタ
イマT９以上になりえます。
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. Ｔ１１がタイムアウトすると、ＩＳＵＰノードが呼を終了させるのを防
ぐため、ＡＣＭメッセージが送られるでしょう。このＡＣＭの「着信者
状態」 値は「表示なし」です。
5. When ISUP T9 in the remote PSTN node expires, it will send a REL.
5. 遠隔のＰＳＴＮノードのＩＳＵＰタイマT９がタイムアウトすると、ＰＳ
ＴＮノードはＲＥＬを送るでしょう。
6. Upon receipt of the REL, the gateway will send an RLC to
acknowledge.
6. ＲＥＬを受信したゲートウェイは確認のためＲＬＣを送るでしょう。
7. The REL will trigger a CANCEL request, which gets sent to the SIP
node.
7. ＲＥＬはＣＡＮＣＥＬ要求を起こし、それはＳＩＰノードに送られます。
8.1.5 SIP Error Response
8.1.5 ＳＩＰエラー回答
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. ＰＳＴＮユーザがＳＩＰユーザへセッションを始めることを望む時、Ｐ
ＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生成
します。
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. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、着番号分析に基づいて適切なＳＩＰノードに送ります。
3. The SIP node indicates an error condition by replying with a
response with a code of 400 or greater.
3. ＳＩＰノードは４００以上のコードでエラー状態を回答します。
4. The gateway sends an ACK message to acknowledge receipt of the
INVITE final response.
4. ゲートウェイはＩＮＶＩＴＥ最終回答受信確認のためＡＣＫメッセージ
を送ります。
5. An ISUP REL message is generated from the SIP code, as specified
in Section 8.2.6.1.
5. ＩＳＵＰのＲＥＬメッセージが８.２.６.１章で指定されるように、ＳＩ
Ｐコードから生成されます。
6. The remote ISUP node confirms receipt of the REL message with an
RLC message.
6. 遠隔のＩＳＵＰノードはＲＬＣメッセージでＲＥＬメッセージの受信を
確認します。
8.1.6 SIP Redirection
8.1.6 ＳＩＰ転送
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. ＰＳＴＮユーザがＳＩＰユーザへセッションを始めることを望む時、Ｐ
ＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生成
します。
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. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、着番号分析に基づいて適切なＳＩＰノードにそれを送ります。
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. ＳＩＰノードはユーザ通信を行いたい資源が異なった場所にある事を示
すため3xxメッセージを送ります。この場合コンタクトＵＲＬがＶｏＩＰ
ＳＩＰ電話に到達可能な正しいＵＲＬを指定すると想定します。
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メッセージを受信し呼が転送されるというイベント表
示のＣＰＧを送ります。あるＩＳＵＰノードがＡＣＭメッセージの前に
ＣＰＧメッセージを受信するのをサポートしないので、この翻訳が設定
によっては使用不能であることに注意してください。
5. The gateway acknowledges receipt of the INVITE final response by
sending an ACK message to the SIP node.
5. ゲートウェイはＳＩＰノードにＡＣＫメッセージを送ることでＩＮＶＩ
ＴＥ最終回答の受信を確認します。
6. The gateway re-sends the INVITE message to the address indicated
in the Contact: field of the 3xx message.
6. ゲートウェイはコンタクトで示されるアドレスへＩＮＶＩＴＥメッセー
ジを再度送ります：3xxメッセージのフィールド。
7. When an event signifying that the call has sufficient addressing
information occurs, the SIP node will generate a provisional
response of 180 or greater.
7. 呼に十分なアドレス情報を持っていることを示すイベントが起こる時、
ＳＩＰノードは１８０以上の暫定応答を生成するでしょう。
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. １８０以上の暫定応答を受信したゲートウェイは８.２.３章で示される
イベントコードでＡＣＭメッセージを生成するでしょう。
9. When the SIP node answers the call, it will send a 200 OK
message.
9. ＳＩＰノードが要求に答える時、120 OKメッセージを送るでしょう。
10. Upon receipt of the 200 OK message, the gateway will send an ANM
message towards the ISUP node.
10. 200 OKメッセージを受信したゲートウェイはＡＮＭメッセージをＩＳＵＰ
ノードに向かって送るでしょう。
11. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
11. ゲートウェイはＩＮＶＩＴＥ最終回答の受信を確認するためにＳＩＰノー
ドにＡＣＫを送るでしょう。
8.1.7 Call Canceled by ISUP
8.1.7 ＩＳＵＰからの呼中止
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. ＰＳＴＮユーザがＳＩＰユーザへセッションを始めることを望む時、Ｐ
ＳＴＮネットワークはゲートウェイに向かってＩＡＭメッセージを生成
します。
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. ＩＡＭメッセージを受信したゲートウェイはＩＮＶＩＴＥメッセージを
生成し、着番号分析に基づいて適切なＳＩＰノードに送ります。
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. 呼に十分なアドレス情報を持っていることを示すイベントが起こる時、
ＳＩＰノードは１８０以上のの暫定応答を生成するでしょう。
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. １８０以上の暫定応答を受信したゲートウェイは、８.２.３章で示され
るイベントコードでＡＣＭメッセージを生成するでしょう。
5. If the calling party hangs up before the SIP node answers the
call, a REL message will be generated.
5. もし発信者が、ＳＩＰノードが要求に答える前に、受話器を置くなら、
ＲＥＬメッセージが生成されるでしょう。
6. The gateway frees the PSTN circuit and indicates that it is
available for reuse by sending an RLC.
6. ゲートウェイはＰＳＴＮ回線を開放し、ＲＬＣを送ることで再利用が可
能であることを示します。
7. Upon receipt of a REL message before an INVITE final response,
the gateway will send a CANCEL towards the SIP node.
7. ＩＮＶＩＴＥ最終回答の前にＲＥＬメッセージを受信したゲートウェイ
はＣＡＮＣＥＬをＳＩＰノードに向かって送るでしょう。
8. Upon receipt of the CANCEL, the SIP node will send a 200
response.
8. ＣＡＮＣＥＬを受信したＳＩＰノードは２００の回答を送るでしょう。
9. The remote SIP node will send a "487 Call Cancelled" to complete
the INVITE transaction.
9. 遠隔ＳＩＰノードはＩＮＶＩＴＥ処理を完了する"487 Call Cancelled"
を送るでしょう。
10. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
10. ゲートウェイはＩＮＶＩＴＥ最終回答の受信を確認するためにＳＩＰノー
ドにＡＣＫを送るでしょう。
8.2 State Machine
8.2 状態遷移図
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.
ＲＥＬがどんな状態ででも到着するかもしれないことに注意してください。
これが起こる時は８.２.７章の行動がとられます。これら移行は一部だけが
この図で示されます。
+---------+
+----------------------->| 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 +------------>+
+-----------------------------+
8.2.1 Initial Address Message received
8.2.1 アドレス開始メッセージ受信
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).
ＩＡＭを受信したゲートウェイは呼のＩＰ側を処理するため適切な内部資源
（デジタル信号プロセッサ−ＤＳＰ−と同種のもの）を予約するべきです
(SHOULD)。逆方向（発信者へ）のオーディオを結合する準備も必要かもしれ
ません(MAY)。
8.2.1.1 IAM to INVITE procedures
8.2.1.1 ＩＡＭからＩＮＶＩＴＥへの手順
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.
ＩＡＭがＰＳＴＮ−ＳＩＰゲートウェイに到着すると、ＳＩＰネットワーク
に送るＩＮＶＩＴＥメッセージを作らなくてはなりません(MUST)。この章は
ゲートウェイがＩＡＭ内に見つけたパラメータに基づいてＩＮＶＩＴＥの
フィールドを生成するプロセスを記述します。
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.
ゲートウェイの受信したＩＡＭの呼設定要求の内容は主にＩＮＶＩＴＥの２
つのＵＲＩに翻訳されます、１つはセッションの発信者で、他は宛先です。
前者がＦｒｏｍヘッダで（１２章で記述された手順でＩＳＵＰフォーマット
から変換された後）、後者はほとんど常にＴｏヘッダと要求ＵＲＩで使われ
ます。
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:
着信者番号のアドレスがＩＡＭから読まれたら、それはＩＮＶＩＴＥの要求
ＵＲＩの役をするであろう宛先ｔｅｌ ＵＲＬに翻訳されるべきです(SHOULD)。
代わりに、ゲートウェイが最初に着信者番号をＵＲＬに翻訳するため電話番
号翻訳（ＥＮＵＭ）[8]問合せを試みるかもしれません(MAY)。ある追加のＩ
ＳＵＰフィールドが翻訳完了後にｔｅｌ ＵＲＬに加えられるかもしれません：
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 もしゲートウェイが（この仕様書で任意である）キャリアベースのルーティ
ングをサポートするなら、ＣＩＰパラメータ（ＡＮＳＩネットワークでは）
か、ＴＮＳパラメータがＩＡＭに存在しているかどうか確認するべきです
(SHOULD)。もし値が存在しているなら、ゲートウェイはパラメータからＣ
ＩＣを抽出し分析するべきです(SHOULD)。もしローカルポリシーで示され
ていれば（すなわちＣＩＣがゲートウェイを所有するネットワークか、類
似の条件を示さないなら）、'cic='フィールドとＣＩＣ値を宛先ｔｅｌ
ＵＲＬに追加すべきです。もしこれが作られたら、着信者番号で使われて
いるか暗示している国番号を'cic='パラメータの頭に追加しなければなら
ない(MUST)ことに注意してください、例えば合衆国でＣＩＣ'5062'が
'+1-5062'になります。'cic='ｔｅｌ ＵＲＬフィールドのこれ以上の情報
は[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 もしゲートウェイが（この仕様書で任意である）番号ポータビリティベー
スのルーティングをサポートするなら、ゲートウェイはいくつかの他の
フィールドを見る必要があるでしょう。正確にＬＮＰがＰＳＴＮで行われ
たことを示すＦＣＩ「番号翻訳済み」ビットを翻訳するために、ｔｅｌ
ＵＲＬに'npdi=yes'フィールドが追加されるべきです(SHOULD)。もしＩＡ
ＭにＧＡＰがあるなら、ＣＰＮの内容（位置ルーティング番号−ＬＲＮ）
が（１２章で記述されるように）ＩＳＵＰフォーマットから翻訳されるべ
きで(SHOULD)、'rn='フィールドにコピーしＵＲＬに追加し、ＧＡＰ自身
はＩＳＵＰフォーマットに翻訳され、ｔｅｌ ＵＲＬの主電話番号フィー
ルドに代入するために使われます。ある国内番号計画で、ＬＲＮとダイヤ
ル番号の両方がＣＰＮに設定され、この場合これらがｔｅｌ ＵＲＬの異
なったフィールドに切り離されなくてはならないことに注意してください。
ＬＲＮの有効範囲で必ず国内で、従って'rn='フィールドが'+'で始まって
はならない(MUST NOT)ことに注意してください。これらのｔｅｌ ＵＲＬ
フィールドについてのこれ以上の情報はが[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.
たいていの場合、結果の宛先ｔｅｌ ＵＲＬはゲートウェイの送るＴｏフィー
ルドと要求ＵＲＬフィールドの両方で使われるべきです(SHOULD)。しかしな
がら、もしＩＡＭにＯＣＮパラメータが存在しているならＴｏフィールドは
ＩＳＵＰフォーマットから１２章のＯＣＮパラメータに従った翻訳から作ら
れるべきで、それ故要求ＵＲＩとＴｏフィールドは異なっているかもしれま
せん。
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.
Ｆｒｏｍヘッダフィールドの生成はＣＩＮパラメータの存在に依存します。
もしＣＩＮが存在しないなら、ゲートウェイはゲートウェイのホスト名だけ
を伝達するユーザ部がないＳＩＰ−ＵＲＩを含むダミーのＦｒｏｍヘッダ
フィールドを生成すべきです(SHOULD)（例えば 'sip:gw.sipcarrier.com'）。
もしＣＩＮが利用可能なら、これは（上記手順どおりに）Ｆｒｏｍヘッダの
ｔｅｌ ＵＲＬに翻訳されるべきです(SHOULD)。いずれかの場合で、ローカル
ポリシーか表示制限（１２.１章参照）の要請がＦｒｏｍヘッダに異る値をも
たらすかもしれません。
8.2.2 100 received
8.2.2 １００受信
A 100 response SHOULD NOT trigger any PSTN interworking messages; it
only serves the purpose of suppressing INVITE retransmissions.
１００応答はＰＳＴＮへのメッセージを引き起こすべきではありません
(SHOULD NOT)；これはＩＮＶＩＴＥ再送を止めるためだけです。
8.2.3 18x received
8.2.3 １８ｘ受信
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暫定応答を受信したら、もしＡＣＭをまだ送っていなければ、そして18x
本体に正しく理解可能なＩＳＵＰが存在していないなら、ＩＳＵＰメッセー
ジが次の表に従って生成されるべきです(SHOULD)。もし早期ACMが送られたら、
呼が「呼び出し」状態ではなく、「進行」状態に入らなければならない
(MUST)ことに注意してください。
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.
もしＡＣＭがすでに送られていて、18xメッセージ本体にＩＳＵＰが存在しな
いなら、ＩＳＵＰメッセージが次の表に従って生成されるべきです(SHOULD)。
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).
１８０応答を受信したゲートウェイは、（ゲートウェイが呼び出し音がＰＳ
ＴＮ側のネットワークによって供給されることを知らないなら）ＰＳＴＮ側
の呼び出し人に聞かせる呼び出し音を生成すべきです(SHOULD)。
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).
ゲートウェイはＳＤＰ提案をＩＮＶＩＴＥで送った後は、18x暫定回答を受信
する前であっても、メディアを受信するかもしれないことに注意してくださ
い。それ故にゲートウェイはＰＳＴＮ側の発信者にメディアの転送をする用
意ができているに違いありません(MUST)（もし必要なら、呼び出し音を生成
した後でメディアを転送します）。ゲートウェイが、あるＳＩＰ拡張を使っ
た早期メディアセッションのため、回答でＳＤＰ提案を受取るかもしれない
ことに注意してください、５.５章参照。もしゲートウェイが逆方法の転送を
している間に１８３回答を受信するなら、この回答の翻訳を生成し、ゲート
ウェイはインバンド情報が利用可のと示すべきです(SHOULD)（例えば、ＣＰ
Ｇメッセージのイベント情報パラメータやＡＣＭのオプション逆方向呼表示
パラメータで）。
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:
ＡＣＭ送信時に、必須の逆方向呼表示パラメータは設定しなければならず、
ゲートウェイポリシーの規定する任意パラメータにあるに違いありません。
もし正しく理解可能なＩＳＵＰが18x回答に存在しているなら、ＰＳＴＮイン
タフェースから送るメッセージの生成のため、ゲートウェイは応答メッセー
ジ本体のＩＳＵＰメッセージのパラメータを、逆方向呼表示パラメータを含
めて、再利用すべきです(SHOULD)。利用可能なＡＣＭカプセルがない場合、
逆方向呼表示パラメータは次のように設定すべきです(SHOULD)：
Message type: 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
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.
ＩＳＤＮの逆方向呼表示パラメータのインターワーク表示を「インターワー
クあり」に設定すると、これがＩＳＤＮほどサービスを供給できないネット
ワークと接続することを示すことに注意してください。従ってＩＳＵＰは通
常使わない機能を使用しないでしょう。逆方向呼表示でインターワークあり
と示しているカプセル化ＩＳＵＰがない場合や、エンドエンドでＩＳＵＰが
使われるのではない場合に、オペレーターのポリシーとして使うため、ゲー
トウェイベンダーが追加のＩＳＵＰサービスを必要とする時サービスプロバ
イダの裁量で使える設定オプションを用意するかもしれません。インターワー
クの効果についての情報は７.２.１.１章を見てください。
8.2.4 2xx received
8.2.4 2xx受信
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応答を受信後、ゲートウェイは双方向メディアパスを確立し、ＰＳＴ
ＮにＡＮＭを、ＳＩＰネットワークにＡＣＫを送らなくてはなりません(MUST)。
If the 200 OK response arrives before the gateway has sent an ACM, a
CON is sent instead of the ANM, in those ISUP variants that support
the CON message.
もしゲートウェイがＡＣＭを送る前に200 OK応答が到着するなら、ＡＮＭの
代わりにＣＯＮメッセージをサポートするＩＳＵＰ方言ではＣＯＮが送られ
ます。
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.
正しく理解可能なＡＮＭが200 OK応答にカプセル化される時、ゲートウェイ
はＰＳＴＮに送るＡＮＭで適切なＩＳＵＰパラメータを再利用すべきです
(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.
ＩＮＶＩＴＥ以外の要求（例えば、管理暫定応答や、情報メソッド）のため
にゲートウェイが時々200 OK応答を受け取るかもしれないことに注意してく
ださい。この章で記述された手順はＩＮＶＩＴＥを送る結果として受信した
200 OK応答にだけ当てはまります。ゲートウェイはもし非ＩＮＶＩＴＥ要求
に応えて200 OKを受け取るなら、ＰＳＴＮメッセージを送るべきではありま
せん(SHOULD NOT)。
8.2.5 3xx Received
8.2.5 3xx 受信
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応答（リダイレクション）受信時に、ゲートウェイはＳＩＰ標準が必須と
するように、応答のＣｏｎｔａｃｔヘッダフィールドのＵＲＩを使って１つ
以上の呼設定を試みるべきです(SHOULD)。このような3xx応答は典型的にリダ
イレクトサーバーによって送られ、移動ＰＳＴＮネットワークのロケーショ
ンレジスタに類似していると考えることができます。
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のＣｏｎｔａｃｔヘッダのＵＲＩがＰＳＴＮ経由で接続するのが最も
良い場合（ゲートウェイのルーチングポリシーに従って）、ゲートウェイは
ＩＡＭを送るべきで、この瞬間から標準ＰＳＴＮ交換機（ＳＩＰなし）の役
を務めるべきです(SHOULD)−通常これはＣｏｎｔａｃｔヘッダのＵＲＩがｔ
ｅｌ ＵＲＬで、ゲートウェイがローカルに接続できず、ＥＮＵＭ翻訳もで
きない場合でしょう。
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.
代わりに、ゲートウェイはリダイレクト表示（２３）と診断フィールドがＵ
ＲＩの電話番号を示したＲＥＬメッセージをＰＳＴＮに送るかもしれません
(MAY)。もし、しかしながら、新しい場所がＳＩＰを使って接続するのが最も
良いなら（もしＣｏｎｔａｃｔヘッダのＵＲＩがまったく電話番号を含んで
いないなら）、ＭＧＣは要求ＵＲＩを含む新しいＩＮＶＩＴＥを生成しする
か、メッセージ本体でＭＧＣの生成した新しいＩＡＭを送るべきです(SHOULD)。
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).
ＳＩＰ要求のＣｏｎｔａｃｔヘッダーフィールドの長いリストを探究してい
る間、呼処理が進んでいることを示すために、ゲートウェイがイベントコー
ド６（転送）のＣＰＧメッセージをＰＳＴＮに送るかもしれません（ＩＳＵ
Ｐ方言が認める場合）。
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).
すべてのリダイレクション状態は、それらが特別な課金状態を伴うので、非
常に慎重に扱われなければなりません。ＰＳＴＮ発信者は典型的に最初の経
路（ゲートウェイまで）を支払い、着信者は第２経路（転送スイッチから宛
先まで）を支払います。
8.2.6 4xx-6xx Received
8.2.6 4xx-6xx 受信
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.
ゲートウェイが受信した回答コードが４００以上である時、前にゲートウェ
イが送ったＩＮＶＩＴＥは拒絶されています。たいていの状況の下でゲート
ウェイはゲートウェイ資源を解放し、原因値を設定したＲＥＬをＰＳＴＮに
送り、ＳＩＰネットワークにＡＣＫを送るべきです(SHOULD)。以下の特殊な
状況で、ゲートウェイがステータスコートで示されたＳＩＰ特有の問題を解
決して、呼を開放せずに再要求を試みるかもしれません(MAY)。ＰＳＴＮにＲ
ＥＬを送る時、ゲートウェイは開放処理が完了したことを示すＲＬＣの到着
を期待します。
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping
8.2.6.1 ＳＩＰ状態コードからＩＳＤＮ理由コードへの翻訳
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.
カプセル化ＲＥＬを含むＳＩＰ拒否応答によりＲＥＬメッセージが生成され
る場合、ＲＥＬの理由表示（ＣＡＩ）パラメータはカプセル化ＲＥＬで受信
した値を設定すべきです(SHOULD)。もしカプセル化ＩＳＵＰが存在しないな
ら、ステータスコードと理由コード間の翻訳が推薦されています(RECOMMENDED)。
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
以下にリストアップされないＳＩＰステータスコード（この文書の後のＳＩ
Ｐの版と関連したＳＩＰ拡張や、ただ省略したもの）は理由コード３１「通
常、特定されていない」に翻訳すべきです。これらの翻訳は応答だけをカバー
します；同じくダイアログを止めるに使われるＢＹＥとＣＡＮＣＥＬ要求が
たいていの状況下で１６「標準クリア」に翻訳されるべきことに注意してく
ださい(SHOULD)。
(although see Section 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.
デフォルトで、ＣＡＩパラメータに関連する原因箇所は、6xxコードは「ユー
ザ」に、4xxと5xxは「ネットワーク」になります。例外は以下です。
Just as there are certain ISDN cause codes that are ISUP-specific and
have no corollary SIP action, so there are SIP status codes that
should not simply be translated to ISUP - some SIP-specific action
should be attempted first. See the note on the (+) tag below.
あるＩＳＤＮ理由コードはＩＳＵＰ特有で、ＳＩＰ動作がなく、ＩＳＵＰに
単純に翻訳すべきでないＳＩＰステータスコードがあります−あるＳＩＰ特
有の動作が最初に試みられるべきです。以下の(+)タグのメモを見てください。
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.
(*) ある場合に、認証失敗でＩＮＶＩＴＥを拒絶しているＳＩＰ ＵＡＳに
ＳＩＰゲートウェイが証明書を供給できるかもしれません。もしゲートウェ
イが自分自身を認証できるなら、明らかにそうしべきで(SHOULD)、呼を続け
るべきです；ただもしゲートウェイが自分自身を認証できないなら原因コー
ド２１が送られるべきです。
(+) 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.
(+) もし可能なら、ＳＩＰゲートウェイが適切でない行動を修正し、セッショ
ンを再生成しようと試みることでプロトコルエラーに返答するべきです
(SHOULD)。ただもしこれが不可能と分かるならＳＩＰゲートウェイがＩＳＵ
Ｐを失敗するべきです。
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.
ＷａｒｎｉｎｇヘッダーがＳＩＰ６０６か４８８のメッセージに存在してい
る時、警告コードに翻訳する特定のＩＳＤＮ理由があるかもしれません。こ
の文書は「３１通常、特定されていない」がデフォルトでたいていの現在割
り当てられた警告コードに使われるべき(SHOULD)であることを勧めます。も
し警告コードが利用できないベアラ能力を言うなら、原因コード「６５未実
装ベアラコード」が翻訳の推薦です(RECOMMENDED)。
8.2.7 REL Received
8.2.7 ＲＥＬ受信
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).
この事象は一般にＰＳＴＮ側のユーザーが、要求に応答がある前に受話器を
置く時に起こります；従ってゲートウェイはセッションの設定を中止します。
ＣＡＮＣＥＬ要求が発行されなくてはなりません(MUST)（最終応答がＳＩＰ
側にきていないので、ＢＹＥが使われません）。ＣＡＮＣＥＬに対して200
OKが期待され、最終的にＩＮＶＩＴＥに対して４８７が帰ります（ゲート
ウェイが順にＡＣＫする）。
The gateway SHOULD store state information related to this dialog for
a certain period of time, since a 200 final response for the INVITE
originally sent might arrive (even after the reception of the 200 OK
for the CANCEL). In this situation, the gateway MUST send an ACK
followed by an appropriate BYE request.
元々のＩＮＶＩＴＥの２００最終回答が（ＣＡＮＣＥＬの200 OK受信後でも）
来るかもしれないので、ゲートウェイはある一定時期このダイアログと関係
がある状態情報を保持すべきです(SHOULD)。この状態で、ゲートウェイはＡ
ＣＫとBYE要求を送ります(MUST)。
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).
ＳＩＰブリッジ状態で、ＲＥＬメッセージは（ＣＡＮＣＥＬメッセージ本体
をたないから）、ＣＡＮＣＥＬメッセージにカプセル化できません。通常、
ＲＥＬメッセージは１６の「標準クリア」のＣＡＩ値を含んでいるでしょう。
もし値が１６以外であるなら、ゲートウェイは原因値を伝達する他の手段を
望むかもしれません（５.８章参照）。
8.2.8 ISUP T11 Expires
8.2.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.
遠隔ＩＳＵＰノードのＴ７タイマがタイムアウトをするのを避けるために、
ゲートウェイは管理のタイマーを保持するかもしれません(MAY)；ＩＳＵＰは
このタイマーをＴ１１と定義します。Ｔ１１の持続時間は、常にゲートウェ
イが通信しているどんなもノードのＴ７より短いように慎重に選択されます。
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.
ＳＩＰインターワーキングでのタイマＴ１１の重要性を明確にするため、Ｑ.
７６４[12]はこう説明します：「もし標準オペレーションで、成功している
ネットワークからのアドレス完了信号の受信の遅延が予想されるなら、最後
の共通線信号交換から始まって、最後のアドレスメッセージの受信から１５
秒から２０秒後［タイマ（Ｔ１１）］にアドレス完了メッセージを送るでしょ
う」。ＳＩＰノードが２０秒の内にＩＮＶＩＴＥ要求に応答する義務を持た
ないので、ＳＩＰインターワークは疑いもなくこのような状態として認めら
れます。
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.
もしゲートウェイがこのオプションのメカニズムをサポートするなら、もし
Ｔ１１がタイムアウトするなら、遠隔ノードのＴ７のタイムアウトを妨げる
ために（ISUP方言が認めるなら）、早期ＡＣＭ（つまり着信者状態が「表示
なし」）を送るべきです(SHOULD)。ＡＣＭパラメータ値は８.２.３章を見て
ください。
If a "180 Ringing" message arrives subsequently, it SHOULD be sent in
a CPG, as shown in Section 8.2.3.
もし「１８０呼出」メッセージがその後到着するなら、８.２.３章に示され
るようにＣＰＧで送られるべきです(SHOULD)。
See Section 8.1.3 for an example callflow that includes the
expiration of T11.
T１１のタイムアウトを含む呼フローの例は８.１.３章を見てください。
9. Suspend/Resume and Hold
9. 中断／再開と保留
9.1 Suspend (SUS) and Resume (RES) Messages
9.1 中断（ＳＵＳ）と再開（ＲＥＳ）メッセージ
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.
ＩＳＤＮネットワークで、ユーザーがソケットからターミナルプラグを抜い
て、他のを挿すためＳＵＳ（タイマT２ 、ユーザ開始）を生成できます。Ｒ
ＥＳが、ターミナルが再接続され、Ｔ２タイマがタイムアウトしていなかっ
たら送られます。ＳＵＳはしばしばＲＥＬメッセージの送信になる前にオン
フック状態を相手端末に伝えるために使われます（これはより普通の場合で
す）。電話が保留されている間、音声メディアがエンドエンドで伝わりませ
ん。
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.
ＳＩＰを使う呼でＳＵＳが送られる時、ゲートウェイはＲＥＳを受信するま
でＩＰメディア送信をしばらく止めるかもしれません(MAY)。待機状態にメ
ディアを置くことは、音声のトラフィックが伝達される必要がない時、バン
ド幅が節約されることを保証します。
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.
もしメディア停止が適切であるなら、ＳＵＳがＰＳＴＮから来るとき、ＭＧ
Ｃは遠端にメディアの流れを止めるように要求するためにＩＮＶＩＴＥを送っ
てもよいです(MAY)。ＰＳＴＮからのＲＥＳ受信はメディアストリームの再開
を求める再ＩＮＶＩＴＥを引き起こすべきです(SHOULD)。ＭＧＣが遠端に伝
達の中止を求める時、自分自身のメディアを伝達をやめることを選ぶかもし
れないし、そうしないかもしれないことに注意してください。
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.
もしＰＳＴＮからＳＵＳを受け取ったＭＧＣがメディア停止を要求しないな
ら、再ＩＮＶＩＴＥでなく、ＳＩＰ−ＩＮＦＯ[6]メソッドがカプセル化ＳＵ
Ｓを転送されるのに使われるかもしれません(MAY)。このようなＩＮＦＯ要求
の受信者がＩＳＵＰを理解しない（従ってこのメッセージの受信に対して行
動しない）単純なＳＩＰ電話であるかもしれないことに注意してください；
もしＳＵＳをカプセル化したＩＮＦＯの受信者と考えられるものが、以前に
送ったカプセル化ＩＳＵＰを使わなかったら、ゲートウェイはＩＮＦＯメソッ
ドを中継すべきではありません(SHOULD NOT)、そしてＳＩＰネットワークに
ＳＵＳやＲＥＳの到着を示さずにＳＵＳと対応するＲＥＳを処理するべきです。
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).
いずれの場合でも、ＳＵＳに対応する次のＲＥＳメッセージは同じ方法で転
送しなければなりません(MUST)(すなわち、もしＳＵＳにＩＮＦＯが使われた
ら、ＲＥＳにもＩＮＦＯを使うべきです）。
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.
ＳＵＳメッセージを運ぶためにＩＮＦＯあるいは再ＩＮＶＩＴＥのメカニズ
ムが使われるかどうかにかかわらず、発側がＩＰメディアを停止するほのめ
かしはありません。従ってカプセル化ＳＵＳメッセージの受信者は、もし望
むなら、ＭＧＣ側からメディア伝達を見合わせるために自身に再ＩＮＶＩＴ
Ｅを送ることを選んでもよいです。
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.
次の例はＩＮＶＩＴＥメカニズムを使います。このフローが教育的で、禁止
的でないことに注意してください；準拠ゲートウェイが、前段落で記述され
るように、機能上等しいフローを実装することが自由です。
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.
呼終了直前のネットワーク起動ＳＵＳの扱いは１０.２.２章で処理され
ます。
9.2 Hold (re-INVITE)
9.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 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'.
このような再ＩＮＶＩＴＥ受信時に、ゲートウェイは呼が保留状態にされた
と言うためＣＰＧを送るべきです(SHOULD)。ＣＰＧは「遠端保留」の値の一
般通知表示（ＡＮＳＩネットワークでは通知表示）を含むべきです(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').
もし、再ＩＮＶＩＴＥ送信後に、ＳＩＰ側が遠端の保留を終えメディア受信
の再開を望むなら、適切なメディア宛のＳＤＰ申し出を含むＩＮＶＩＴＥを
フローで繰り返すべきです(SHOULD)。一般通知表示はこの場合、値は「遠端
回復」の値でしょう（ある方言では「遠端保留解放」）。
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.
最終的に、ＰＳＴＮから保留表示を持つＣＰＧがゲートウェイに来るかもし
れないことに注意してください。帯域節約との利害関係で、ゲートウェイは
呼が再開されるまでメディア送信をやめるべきで(SHOULD)、遠端がメディア
送信をやめることを要求して再ＩＮＶＩＴＥを呼のＳＩＰ側に送るべきです
(SHOULD)。
10. Normal Release of the Connection
10. 標準呼開放
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).
ゲートウェイの見地から、ＳＩＰ側あるいはＩＳＵＰ側のどちらが呼を始め
たかにかかわらず、呼を開放できます。呼設定要求の中止（ＩＳＵＰ側から
でもＳＩＰ側からでも）がこの文書のほかの所（それぞれ８.２.７章と７.
２.３章）で論じられることに注意してください。
Gateways SHOULD implement functional equivalence with the flows in
this section.
ゲートウェイがこの章のフローと機能的に等価な実装をするべきです(SHOULD)。
10.1 SIP initiated release
10.1 ＳＩＰからの開放
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.
標準対話終了（ＢＹＥ要求の受信）で、ゲートウェイはすぐに２００応答を
送らなくてはなりません(MUST)。ゲートウェイはそれからゲートウェイの資
源を解放し（ＤＳＰ，ＴＣＩＣロックなど）、ＰＳＴＮに理由１６（標準呼
クリア）のＲＥＬを送らなくてはなりません(MUST)。資源開放はＰＳＴＮ側
ではＲＬＣメッセージで確認されます。
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.
ＳＩＰブリッジ状態で、ＢＹＥにカプセル化したＲＥＬの理由コードが、ゲー
トウェイがＰＳＴＮに送るＲＥＬで再利用されるべきです(SHOULD)。
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
10.2 ISUP initiated release
10.2 ＩＳＵＰからの開放
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.
もし接続開放がＲＥＬ受信でおきるなら、ＲＥＬはゲートウェイが送るＢＹ
Ｅにカプセル化されるべきです(SHOULD)。発信者と着信者のどちらが最初に
受話器を置くかにかかわらず、ゲートウェイは呼に使われた内部資源を解放
すべきで(SHOULD)、ＲＬＣを送ることで回線の再利用の準備ができているこ
とを確認しなくてはなりません(MUST)。
10.2.1 Caller hangs up
10.2.1 発信者が受話器を置く
When the caller hangs up, the SIP dialog MUST be terminated by
sending a BYE request (which is confirmed with a 200).
発信者が受話器を置く時、ＳＩＰダイアログはＢＹＥ要求を送る事で終わり
ます(MUST)（２００で確認される）。
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
10.2.2 Callee hangs up (SUS)
10.2.2 着信者が受話器を置く（ＳＵＳ）
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:
あるＰＳＴＮシナリオで、もし発信者が呼の途中で受話器を置くと、ローカ
ル交換機はＲＥＬの代わりにＳＵＳを送り、タイマを起動します（Ｔ６、ネッ
トワーク起動ＳＵＳ）。タイマの期限が切れるとＲＥＬが送られます。これ
はわずかに異なったＳＩＰフローを必要とします；保留処理のより多くの情
報は９章を見て下さい。ゲートウェイがこの場合に次のフローと機能的に同
等な実装が勧められます(RECOMMENDED )：
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----------->| |
11. ISUP Maintenance Messages
11. ＩＳＵＰ管理メッセージ
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.
ＩＳＵＰは管理目的のメッセージを含んでいます。それらはどんな呼の状態
ででも受信できます。（継続検査を別として）基本的に管理メッセージに２
つの種類があります：回線閉塞のためのメッセージと回路をリセットするた
めのメッセージ。
11.1 Reset messages
11.1 リセットメッセージ
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.
現在ゲートウェイが呼に使っている回線でＲＳＣメッセージを受信したら、
呼はすぐに開放されなくてはなりません(MUST)（これは典型的に重大な保守
条件の結果として生じます）。ゲートウェイが回線をリセットした後で、Ｒ
ＳＣに対してＲＬＣを返答します(MUST)。広範囲の回線を対象とした回線群
リセット（ＧＲＳ）メッセージの場合、メッセージの対象とするすべての回
線をリセットした後で、回線群リセット確認メッセージを返答します。
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.
ゲートウェイは、ＳＩＰ側のダイアログを開放するためにＲＥＬを受信した
ように、振る舞うべきです(SHOULD)。呼状態によって、ＢＹＥかＣＡＮＣＥ
Ｌが送られます。１０章の手順を見てください。
11.2 Blocking messages
11.2 閉塞メッセージ
There are two kinds of blocking messages: maintenance messages or
hardware-failure messages. Maintenance blocking messages indicate
that the circuit is to be blocked for any subsequent calls, but these
messages do not affect any ongoing call. This allows circuits to be
gradually quiesced and taken out of service for maintenance.
２種類の閉塞メッセージがあります：管理メッセージとハードウェア障害メッ
セージ。管理閉塞メッセージは回線が次の呼で使えない事を示しますが、こ
れらのメッセージは現在の呼影響を与えません。これは回線が次第に静かに
なり、管理のためサービスから外すことを許します。
Hardware-oriented blocking messages have to be treated as reset
messages. They generally are sent only when a hardware failure has
occurred. Media transmission for all calls in progress on these
circuits would be affected by this hardware condition, and therefore
all calls must be released immediately.
ハードウェアに対する閉塞メッセージは、メッセージをリセットしたように
扱います。それらは一般にハードウェア故障が起こった時だけ送られます。
すべてのこれらの回線上の呼のメディア送信がこのハードウェア条件によっ
て影響を与えられ、それ故にすべての呼はすぐに開放されなくてはなりませ
ん。
BLO is always maintenance oriented and it is answered by the gateway
with a Blocking ACK Message (BLA) when the circuit is blocked - this
requires no corresponding SIP actions. Circuit Group Blocking (CGB)
messages have a "type indicator" inside the Circuit Group Supervision
Message Type Indicator. It indicates if the CGB is maintenance or
hardware failure oriented. If the CGB results from a hardware
failure, then each call in progress in the affected range of circuits
MUST be terminated immediately as if a REL had been received,
following the procedures in Section 10. CGBs MUST be answered with
CGBAs.
閉塞メッセージ（ＢＬＯ）は常に管理指向で、回線が閉塞された時、ゲート
ウェイは閉塞確認メッセージ（ＢＬＡ）で答えられます−これは対応するＳ
ＩＰ動作を必要としません。回線群閉塞メッセージ（ＣＧＢ）が回線群管理
メッセージ種別表示の中に「種別表示」を持っています。これはＣＧＢが管
理かハードウェア故障志向かを示します。もしＣＧＢがハードウェア障害に
よって生じるなら、各回線の影響範囲の呼が、１０章の手順に従って、ＲＥ
Ｌ受信のようにすぐに終了しなくてはなりません(MUST)。ＣＧＢに対して回
線群閉塞確認メッセージ（ＣＧＢＡ）で答えなくてはなりません(MUST)。
11.3 Continuity Checks
11.3 接続検査
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).
接続検査は送信側交換機の発生したトーンを宛先側交換機でループバックし
送り返す回線試験です。接続検査の２つの方言がＩＳＵＰにあります：ＩＡ
Ｍでの暗示的な接続検査要求（この場合、接続検査が呼設定の前の前提条件
として起きます）と、接続検査メッセージ（ＣＣＲ）による明示的接続検査。
一般に接続検査をサポートする地域のＰＳＴＮゲートウェイが、（もし主要
キャリアと相互接続するプロバイダに接続を望むなら）、これらの試験を受
け入れる方法を持つべきです(SHOULD)。
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.
ＰＳＴＮ−ＳＩＰゲートウェイがＣＣＲを受信する時、ゲートウェイは対応
するＳＩＰメッセージを送るべきでありません(SHOULD NOT)；接続検査の適
用範囲はＰＳＴＮトランクのみで、ゲートウェイの反対のＩＰメディアパス
ではありません。ＣＣＲメッセージは着信者番号や、他のＳＩＰユーザーエー
ジェントサーバに通信すべきか決定する方法を指定しません。
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.
ＮＣＩパラメータの接続検査表示フラグが設定されたＩＡＭ受信時に、ゲー
トウェイはＩＮＶＩＴＥ送信前に接続検査を処理しなくてはならなりません
(MUST)（そして通常の呼設定をします）；もし、接続検査に失敗したら（接
続表示は「失敗」のＣＯＴ受信）、ＩＮＶＩＴＥを送ってはなりません(MUST
NOT)。
12. Construction of Telephony URIs
12. 電話ＵＲＩの生成
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-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.
ＳＩＰ−ＩＳＵＰ翻訳がこれらのＵＲＩで表現した電話番号をしばしば必要
とします。いくつかの場合にはこれらの番号はＩＳＵＰメッセージで最初に
提出され、ＳＳ７−ＳＩＰゲートウェイがこれらの番号のＩＳＵＰフォーマッ
トをＳＩＰ ＵＲＩに翻訳する必要があるでしょう。他の場合で、逆の翻訳が
必要でしょう。
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:
ＳＩＰで電話番号を表現する最も一般的フォーマットはｔｅｌ ＵＲＬ[7]です。
これらのフォーマット間で翻訳する時、ｔｅｌ ＵＲＬはＳＩＰメッセージの
ＵＲＩフィールドの全部かもしれません、あるいはＳＩＰ ＵＲＩのユーザー
部として現われるかもしれません(MAY)。例えば、Ｔｏフィールドは以下かも
しれません：
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.
特定のゲートウェイあるいは終端がＵＲＩを定式化するべきであるか否かに
かかわらず、ｔｅｌやＳＩＰフォーマットにローカルな管理ポリシー問題が
あります−もしホスト部の表現が電話接続をする周囲のネットワークを手伝
うなら、ＳＩＰフォーマットが使われるべきです。ゲートウェイが相手から
のｔｅｌやＳＩＰ ＵＲＩを受け入れなくてはなりません(MUST)。
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.,
ｔｅｌ ＵＲＬ番号の前の”＋”記号は後に続く数字が完全なＥ．１６４番号
[16]である事を示します；本質的にこれは、国内エリアコードや交換機／都
市コードやアドレスコードの前に国コードがあることを意味します。”＋”
記号がない4場合、番号は国内でだけ意味があることを示すかもしれません
(MAY)、あるいは多分プライベート番号計画です。”＋”記号がないが、電話
番号がＵＲＩのユーザー部にある場合、ＳＩＰ ＵＲＩがオプションの';
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.
しかしながら、特にこのようなゲートウェイが異なった地域や異なった管理
ドメインにある時、国際的に意味があるＥ．１６４番号だけをＳＩＰ−Ｔゲー
トウェイの間で転送することが強く推薦されています(RECOMMENDED)。たいて
いのもしくは多くのＩＰ−Ｔネットワークで、ゲートウェイはＳＩＰ電話の
端エンドエンドルーティングに責任がありません；実際に通話で、ゲートウェ
イは呼がローカルに終わるか、遠隔の管理ドメインか地域で終わるか知る方
法がありません、それ故ゲートウェイが常に呼が国際番号計画を必要とする
と想定するべきです(SHOULD)。ＳＩＰ受信者が呼の発信者の使った国内番号
計画を理解することができる保証がありません−もし発信ゲートウェイが信
号を国際化しないなら、電話のダイヤル桁の意味が遠端ネットワークで推定
できません。
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.
ＩＳＵＰ信号で、電話番号がＣＰＮやＣＩＮを含むいくつかのパラメータで
使われる共通フォーマットです；これが発信者番号を表す時、追加情報があ
ります（下に記述）。この文書で、我々はこのフォーマットを「ＩＳＵＰ
フォーマット」と言います−もし追加の発信者情報があるなら、フォーマッ
トは「ＩＳＵＰ発信フォーマット」と言うべきです。フォーマットは、番号
種別表示（ＮｏＡ）の１バイトと、番号計画表示（ＮＰＩ）の１バイトと、
２進化１０進数（ＢＣＤ）フォーマットの可変上桁数の電話番号のバイト列
から成り立ちます。発信者番号の場合、ＮＰＩバイトは発信者番号の表示識
別と網検証識別を表すビットフィールドを含んでいます。
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 numbering formats
ＩＳＵＰ番号フォーマット
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.
ＮＰＩフィールドは一般に値「ＩＳＤＮ（電話）番号計画（勧告Ｅ．１６４）」
が設定されますが、これは必ず後に続く桁が国コードを含んでいることを意
味しません、ＮｏＡフィールドは電話番号が国内フォーマットか国際フォー
マットかを示します。番号が国際フォーマットでなければ、ＮｏＡは一般に
国内ダイヤル計画に特有な情報を供給します−通常この情報に基づいてどの
ように問題の番号を国際フォーマットに変換するべきか決定できます。もし
ＮＰＩが「ＩＳＤＮ番号計画」以外の値を含んでいるなら、ｔｅｌ ＵＲＬが
アドレス番号でないかもしれず、このような呼の取り扱いがこの文書の範囲
の外であることに注意してください。
12.1 ISUP format to tel URL mapping
12.1 ＩＳＵＰフォーマットからｔｅｌ ＵＲＬへの翻訳
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.
上記に基づいて、ＩＳＵＰフォーマットからｔｅｌ ＵＲＬの変換が次の通り
です。最初に、ＮＰＩフィールドが電話番号フォーマットがＥ．１６４を使
うことを示すなら、ＮｏＡを調べます。もしＮｏＡが番号が国際番号である
ことを示すなら、電話番号は変換されず'tel:+'を付けるべきです(SHOULD)。
もしＮｏＡが値「国内番号」なら、ｔｅｌ ＵＲＬに渡す前に電話番号の前に
国コードを付けます(MUST)；もしこの変換を行っているゲートウェイがいく
つかの異なる国コードに向けの交換機を相互に連結するなら、多分適切な国
コードは出発点の交換機かトランクグループに基づいて選択されるべきです
(SHOULD)。もしＮｏＡが値「加入者番号」なら、国コードと問題の番号計画
に必要な他番号要素（エリアコードとか都市コードのような）が国際番号を
作るために追加が必要かもしれません(MAY)−しかしながら、この手順は国毎
に異なり、それ故ここで詳細を指定できません。ただもし国かネットワーク
特有値がＮｏＡで使われるならｔｅｌ ＵＲＬが「＋」記号を含むべきではあ
りません；この場合、ゲートウェイがｔｅｌ ＵＲＬにただ供給された桁をコ
ピーし、ＳＩＰ ＵＲＩフォーマットが使われるなら'user=phone'パラメータ
を付加するべきです(SHOULD)。ＩＳＵＰ呼でこれ以上の内容を伝達するため
に使われた非標準か特有機構はこの文書の範囲の外です。
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.
もし発信者番号を設定する国内特有のパラメータがあるなら（ＡＮＳＩの一
般番号パラメータのような）、一般に存在が限定されていなければ、この情
報はＦｒｏｍフィールドの表示名部で使われるべきです(SHOULD)。
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.:
もしＩＳＵＰフォーマットでなくＩＳＵＰ発信フォーマットが変換されてい
るなら、２つの追加情報を考慮しなければなりません：表示識別と網検証識
別。もし表示識別が表示不可に設定されるなら、ゲートウェイが遠端に発信
者番号が削除された事を示す特別ＵＲＩを生成します。このＵＲＩは、表示
名とユーザ名が'Anonymous'のＳＩＰ ＵＲＩであるべきです(SHOULD)、例え
ば：
From: Anonymous <sip:anonymous@anonymous.invalid>
For further information about privacy in SIP, see Section 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.
もし表示識別が「使用不可」に設定されているなら、ゲートウェイがＣＩＮ
パラメータがないかのように、ＩＡＭを扱うべきです。網検証識別が、エン
ドエンドでのみ意味があるので、翻訳されるべきではありません。
12.2 tel URL to ISUP format mapping
12.2 ｔｅｌ ＵＲＬからＩＳＵＰフォーマットへの翻訳
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'.
ｔｅｌ ＵＲＬからＩＳＵＰフォーマットへの変換は単純です。もしＵＲＩが
国際フォーマットなら、ゲートウェイはＵＲＩの国コードを調べるべきです
(SHOULD)。もし国コードがゲートウェイのローカルなら（ゲートウェイが問
題の国コードの交換機を指し示す１つ以上のトランクを持っている）、ゲー
トウェイはＮｏＡの「国内番号」を設定し、そして桁フィールドを設定する
前にＵＲＩから国コードを取るべきです(SHOULD)。もし国コードがゲートウェ
イのローカルではないなら、ゲートウェイはＮｏＡを「国際番号」に設定し、
国コードを残すべきです(SHOULD)。いずれの場合でもＮＰＩは「ＩＳＤＮ番
号計画」を設定しなくてはなりません(MUST)。
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).
もしＵＲＩが国際フォーマットでないなら、ゲートウェイはＵＲＩの電話番
号を国内番号計画かネットワーク特有であるかのように扱おうと試みるかも
しれません(MAY)；もしそうすると内部のゲートウェイエラーに遭遇するか、
あるいはゲートウェイがこのような処理をサポートしないなら、ゲートウェ
イは適切なＳＩＰ状態コードでＵＲＩが理解できなかったと答えるべきです
(SHOULD)（もし問題のＵＲＩが要求ＵＲＩなら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.
ｔｅｌ ＵＲＬからＩＳＵＰ発信フォーマットへ変換する時、処理は前の段落
で記述したのとく同じですが、追加で、サービスプロバイダポリシーかユー
ザープロフィールが特に表示を拒否しないなら、表示表示識別が「使用可」
を、網検証識別を「網投入」に設定すべきです(SHOULD)。
13. Other ISUP flavors
13. 他のＩＳＵＰ方言
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.
ＩＴＵ−ＴのＩＳＵＰと異なるＩＳＵＰ方言が異なるパラメータと機能をを
持っています。あるパラメータはより利用可能な値を持ち、呼状態により多
くの情報を供給します。
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).
回路問合せメッセージ（ＣＱＭ）と回路問合せ応答（ＣＱＲ）は多くのＩＳ
ＵＰ方言で使われます。ＣＱＲの受信は発側と着側の交換機状態が不一致の
場合に状態調整を起こすかもしれないけれども、ＳＩＰにこれらのメッセー
ジに類似するものがありません；状態が調整さられる時、ある呼が終了する
かもしれず、これはＳＩＰかＩＳＵＰメッセージを送るかもしれません
（１０章で記述されるように）。
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.
しかしながら、メッセージフローにおける違いはいっそう重要です。ＡＮＳ
Ｉ[11]のＩＳＵＰでＣＯＮメッセージを送ってはなりません(MUST NOT)；Ａ
ＮＭが代わりに送られます（呼に応答する前にＡＣＭを送っていない場合）。
呼転送状態でＣＰＧはＡＣＭが送られる前に送られるかもしれません(MAY)。
ＳＡＭを送ってはなりません(MUST NOT)；「enブロック」信号が常に使われ
ます。ＡＮＳＩ退場メッセージ（ＥＸＭ）はゲートウェイでＳＩＰシグナル
を発生させるべきではありません(SHOULD NOT)。ＡＮＳＩが同じく回線予約
メッセージ（ＣＲＭ）と回線予約確認（ＣＲＡ）をインターワーク処理の一
部として用います−ＭＧＣがＣＲＭを受信する時、ＣＲＡが返送されるべき
です(SHOULD NOT)（ある実装でＣＲＡ送信はたぶん資源予約システムに基づ
きます）；ＣＲＡ送信後、ＭＧＣは次のＩＡＭを待ち、普通にそれを処理す
るべきです(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.
混乱（ＣＦＮ）メッセージ受信はプロトコルエラーの表示であるが、対応す
るＳＩＰメッセージがＣＦＮ受信時に送られるべきではありません(SHOULD
NOT)−ＣＦＮはゲートウェイによるＩＳＵＰ特有手順で処理（通常ＣＦＮ応
答になったパケットの再送）されるべきです。もしＩＳＵＰ手順が繰り返し
失敗するならこれはＳＩＰエラー条件（呼の失敗）を起こすべきです。
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.
ＴＴＣのＩＳＵＰでＣＰＧはＡＣＭが送られる前に送られるかもしれません
(MAY)。課金情報メッセージ（ＣＨＧ）のようなメッセージがＡＣＭとＡＮＭ
の間に送られるかもしれません。「Ｅｎ−ブロック」信号は常に使われ、
Ｔ９タイマーがありません。
13.1 Guidelines for sending other ISUP messages
13.1 他のＩＳＵＰメッセージを送るガイドライン
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.
あるＩＳＵＰ方言がこの文書で記述したより多くのメッセージを送ります。
それ故、これらについてＩＳＵＰメッセージの転送と翻訳のガイドラインが
ここで供給されます。
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.
たとえＩＮＶＩＴＥ処理が終わっていなくても、発信者から着信者まで他の
ＩＳＵＰメッセージがＩＮＦＯメッセージ内にカプセル化（[3]参照）される
べきです(SHOULD)。ＳＩＰがＩＮＦＯ要求を順番に届ける保障をせず、従っ
てネットワーク状態によっては出口ゲートウェイが順番が異なったＩＮＦＯ
を処理するかもしれないことに注意してください。しかしながら、この問題
が起こる可能性は低く、効果が大部分の状態でたいしたことがないので、重
大な問題を起こしません。情報（ＩＮＦ）メッセージと情報回答（ＩＮＲ）
はＩＮＦＯ内にカプセル化されるべきメッセージの例です。ゲートウェイ実
装者が新しいＩＮＦＯ処理を始まる前に各ＩＮＦＯ処理を待つステムの構築
を考えるかもしれません。
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受信前）にメッセー
ジ来たら、これが逆向きに送られる最初のＳＩＰメッセージではないなら、
これはＩＮＦＯにカプセル化されるべきです(SHOULD)（この場合、これは1xx
暫定回答にカプセル化されるべきです(SHOULD)）。同様に200 OKをゲートウェ
イに受信する前に（恐らくＩＮＲに応えて）ゲートウェイが出発側で受信す
るメッセージは、ＩＮＦＯで運ばれるべきです。このメカニズムが順方向で
正確に動作するために、必要なＣｏｎｔａｃｔかＴｏタグが前の暫定応答に
現われたに違いありません、あるいはメッセージはその宛先に正確に転送で
きないかもしれません。すべてのＳＩＰ−ＴゲートウェイはＣｏｎｔａｃｔ
ヘッダーと必要なタグを持つ全ての暫定応答を、新しい要求が適切なルーティ
ングを可能にするため、最終の回答が受け取られる前に送らなくてはなりま
せん(MUST)。ＩＮＶＩＴＥ処理が終了したＩＮＦＯ要求はこの方向で使われ
るべきです(SHOULD)。
14. Acronyms
14. 頭字語
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
15. Security Considerations
15. セキュリティの考察
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.
ＩＳＵＰパラメータのＳＩＰヘッダへの翻訳は、ＳＩＰ−Ｔ[9A]の機能を越
えてプライバシーとセキュリティの懸念を導入するかもしれません。カプセ
ル化ＩＳＵＰだけを安全に保つことは、例えば、発信者番号パラメータが公
然とＦｒｏｍヘッダに翻訳されたら表示制限を求めているユーザーに適切な
プライバシーを提供しないでしょう。１２.２章がＳＩＰプライバシー[9B]
がこの機能でどのように使われるべきであるか示します。ＳＩＰ−ＩＳＵＰ
翻訳の範囲がＳＩＰ要求の転送に使うヘッダとフィールドに翻訳されるパラ
メータに制限されるので、従ってゲートウェイが翻訳の必要な最小情報を明
らかにします。
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.
ＩＳＵＰのセキュリティ分析がこの文書の範囲を越えてます。ＳＩＰを通し
てＩＳＵＰブリッジをつくる議論が[9A]でより完全に論じられますが、７.
２.１.１章がＰＳＴＮゲートウェイに到着している要求で、ＩＳＵＰ値をカ
プセル化ＩＳＵＰへ翻訳する処理の論議します。ＩＳＵＰセキュリティ分析
なしに、もし埋め込まれたＩＳＵＰがやみくもに通訳されるなら、ある危険
があるかもしれません。したがって、ゲートウェイは要求が強く認証され
[9A]送信者が信頼できなかったら、例えば他のＭＧＣがブリッジモードでＳ
ＩＰ上にＩＳＵＰを使う権限を与えられなければ、やみくもに埋め込みのＩ
ＳＵＰを信頼するべきではありません(SHOULD NOT)。要求が任意の末端から
受け取られる時、ゲートウェイがどんな受信ＩＳＵＰもフィルターするべき
です。特に、既知の安全なコマンドとパラメータだけが受け入れられ、通過
されるべきです。危険と思われる項目を削除するだけではフィルターはうま
く働きません。
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.
たいていの点で、ＩＳＵＰからＳＩＰに翻訳される情報は特別なセキュリティ
条件を持っていません。翻訳されたパラメータが転送に使われるため、それ
らは中間者に読みやすくあるべきです；エンドエンド暗号化は不必要で、そ
してたいてい多分有害でしょう。同じく中間者が正当に翻訳によって供給さ
れた値を上書きできる多数の状況があり、それ故これらのヘッダーの完全性
は望ましくありません。
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.
次の段落で列挙されるＳＩＰヘッダからＩＳＵＰパラメータへ翻訳から生ず
る他の翻訳の懸念があります。エンドユーザが今日ＰＳＴＮ番号に電話する
時、選択機構は着信者番号パラメータの電話番号部を設定すると共に、ＩＳ
ＵＰのＩＡＭのキャリア識別コードと中継網選択パラメータを設定します。
同様に、ゲートウェイは、ＳＩＰ装置のエンドユーザが生成したＳＩＰの要
求ＵＲＩのｔｅｌ ＵＲＬとそのオプションパラメータはをこれらのパラメー
タに翻訳します。しかしながらＰＳＴＮで、ポリシーによってユーザーがあ
る特定の（無効であるか、あるいは限定された）番号に電話するか、あるい
はある特定のキャリア識別コードを選択するのを阻止できます。それで、
ゲートウェイオペレーターが、電話を認可する時、ある特定のｔｅｌ ＵＲＬ
やｔｅｌ ＵＲＬパラメータの用途を限定するポリシーを使うことを望むかも
しれません(MAY)。
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.
ＡＮＳＩ ＩＳＵＰの一般アドレスパラメータのＬＲＮ部と順方向呼表示のＭ
ビットを含む番号ポータビリティに関係があるフィールドはＰＳＴＮで呼経
路を決めるために使われます。これらのフィールドがＳＩＰ−ＩＳＵＰ翻訳
でｔｅｌ ＵＲＬパラメータとして表現されるので、ユーザーが独断的にこれ
らのフィールドの値を設定できます。従って、エンドユーザが要求の転送先
エンドオフィスを変えることができます（もしＬＲＮ値がランダムに選択さ
れたなら、電話の転送を妨げることがありそうだけど）。しかしながら、Ｐ
ＳＴＮはローカル番号ポータビリティで転送を誤った呼に比較的回復力があ
ります。あるネットワークでこのような条件が起こる時、何らかの種類の
「番号ポータビリティ転送誤り」の理由コードを持つＲＥＬメッセージを逆
方向に送ります。代わりに、転送誤りをしたＰＳＴＮ交換機電話は呼を番号
ポータビリティ問合せ後に適切な交換機へを転送できます−これはポータビ
リティをサポートするたいていのＰＳＴＮでま一般的な臨時番号ポータビリ
ティ習慣です。エンドユーザが典型的にこれらのＳＩＰフィールドをセット
するとは予想されず、そして冒険的か、あるいは悪意があるユーザーがＬＲ
Ｎを設定することを許すことに関するリスクは重大と思われませんが、ネッ
トワークオペレータが気付くべきです。ＩＰ信号が順方向呼表示と逆方向呼
表示へあたえる影響は限定的なので、予見可能なリスクがありません。
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.
ある追加のリスクがＳＩＰ応答コードからＩＳＵＰ原因コードパラメータの
翻訳の結果として生じるかもしれません。ＳＩＰユーザーのエージェントが
は多分ゲートウェイのＩＮＶＩＴＥに任意のＳＩＰ応答コードを返せます、
そして結果的にＲＥＬメッセージで送られるであろうQ.８５０原因コードを
（翻訳をする境界ゲートウェイに）指示できます。一般的に言って、呼出し
拒否は詐欺やサービス否認を供給になりそうにありません−著者の知識では、
課金やネットワークがオフラインでクリティカル資源を取る原因コードがこ
の文書にありません。しかしながら、推薦翻訳をサポートするゲートウェイ
の運用から望ましくないネットワーク特有動作を生じないことを確かにする
ために、オペレーターがＳＩＰ応答コード（７.２.６.１でリストアップし
た）から翻訳された原因コードを綿密に調べることを望むかもしれません。
ある場合には、オペレーターが、多分選択的に認可データに基づいて、代わ
りの翻訳を使うゲートウェイポリシーの実装を望むかもしれません(MAY)。
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.
もしゲートウェイの受信した要求ＵＲＩとＴｏヘッダフィールドが異なるな
ら、７.２.１.１章がＴｏヘッダ（もし電話番号なら）をオリジナル着番号パ
ラメータに、要求ＵＲＩを着番号に変換するのを推薦します。しかしながら
ユーザーは、要求の発側で、要求ＵＲＩと異なるヘッダーフィールド値を選
択できます；これら２つのフィールド値は同じであるように要求されません。
これは本質的にユーザーに独断的にＩＳＵＰオリジナル着番号パラメータを
設定することを許します。オリジナル着番号に課金を依存するアプリケーショ
ンはこの翻訳推薦の影響を受けます。この場所における将来のＳＩＰの仕事
が、ＯＣＮ翻訳に適用できるかもしれない、ＳＩＰ要請を再転送するもっと
良い一般的な記述に到達するであろうことは予想されます。
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].
ＳＩＰユーザーエージェントの要求のＦｒｏｍヘッダーは、発信者の識別子
の正確な表現のＦｒｏｍヘッダーに依存する装置のためにあるよく理解され
たセキュリティ意味を持っています。ＦｒｏｍヘッダをＩＳＵＰのＩＡＭメッ
セージの発信者番号パラメータに使う事を考えているゲートウェイは、要求
の発信者を認証し、その着番号を使う権限があるかどうか確認すべきです
（または、発信者の身元を確認するセキュリティが高い方法を利用すべきで
す）。他のＳＩＰユーザーエージェントと同じく、ゲートウェイが[1]で記
述されるダイジェスト認証をサポートしなければならないことに注意して
ください(MUST)。
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暫定回答を返すとき、ゲートウェイがＡＣＭを送ることを薦めます。この
時、逆方向メディアはＩＳＵＰネットワークでエンドエンドで届き、最終回
答（２ｘｘ以上の応答コード）が送られる前の一定期間、着信ユーザエージェ
ントが任意の音声を発信者に送れます。着信エージェントがこの能力を違法
に使う事が想像できます。しかしながらこれはトーンとアナウンスを「ＡＣ
Ｍ送信」状態で逆方向で送るのに有用な機能です。（呼が完了していないの
で発信者には請求がないだろうが、失敗条件がインバンドオーディオとして
ユーザーに提出されなくてはなりません）。実際、ＩＳＵＰは一般にＱ.８
５０理由コードを表現できない旧式ネットワークとＩＳＵＰネットワークが
インターワークするとき、呼状態に関連してトーンとアナウンスを通す逆方
向転送能力を使います。
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.
Q.９３１−ＩＳＵＰ翻訳で逆方向メディアが存在しないのはＳＩＰにリスク
を導入しないという著者の主張ですが、ゲートウェイ実装者が短いタイマで
このような「早期メディア」を切断するオプションのメカニズム（多分オペ
レーターが設定できる）を開発するかもしれません(MAY)−２０秒か３０秒以
上の早期メディアが呼の状態情報を運ぶのにために必要でありそうもありま
せん（７.２.６章参照）。もっと保守的な方法はゲートウェイで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.
伝統的なＰＳＴＮ電話と異なり、ＳＩＰユーザーエージェントが特定の資源
に届く多数の同時の要求を開始できます。ＳＩＰユーザーのエージェントが
１００ポートゲートウェイに１００のＳＩＰ要求をするのは簡単で、それに
よってそのポートのすべてを使ってしまうでしょう。悪意があるユーザーが
決して応答しない電話番号への要求をし、いつまでも課金されずに、潜在的
にこれらの資源を埋める事ができます。従ってゲートウェイがこの「サービ
ス否認」攻撃を扱うために、同じ認証されたソースからの同時の要求数を制
限したり類似のメカニズムのポリシーをサポートするかもしれません(MAY)。
16. IANA Considerations
16. ＩＡＮＡの考慮
This document introduces no new considerations for IANA.
この文書はＩＡＮＡに対する新しい考慮を紹介しません。
17. Acknowledgments
17. 謝辞
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.
この文書は４年間インターネットドラフトとして存在し、そしてそれはそれ
が（MMUSICとＳＩＰとSIPPINGワークグループを含む）ホームと呼んだ種々な
トランスポートエリアＩＥＴＦワーキンググループのメンバーから数え切れ
ない貢献を受け取りました。特に、著者はこの文書のヘルプとフィードバッ
クに対して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と
William T. Marshallに感謝したいです。著者は同じくＩＳＵＰ手順のアドバ
イスに対してＩＴＵ−Ｔ ＳＧ１１に感謝します。
18. Normative References
18. 参照する参考文献
[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.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[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.
[5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header
Field for the Session Initiation Protocol", RFC 3326, November
2002.
[9A] Vemuri, A., Peterson, J., "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", RFC 3372,
September 2002.
[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
19. Non-Normative References
19. 標準でない参考文献
[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>.
[11] American National Standards Institute, "Signaling System No. 7;
ISDN User Part", ANSI T1.113, January 1995,
<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>.
[13] International Telecommunications Union, "Abnormal conditions -
Special release", ITU-T Q.118, September 1997,
<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>.
[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>.
[16] International Telecommunications Union, "The international
public telecommunications numbering plan", ITU-T E.164, May
1997, <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>.
[18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in SIP", RFC 3262, June 2002.
[19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
Number Portability and Freephone Service", Work in Progress.
Authors' Addresses
著者のアドレス
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
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
URI: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
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
URI: http://www.ciena.com/
EMail: lyOng@ciena.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。