RFC3578 統合ディジタル通信サービス網（ＩＳＤＮ）ユーザ部（ＩＳＵＰ）のセッション開始プロトコルへの重畳マッピング

この文書はRFC3578の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group G. Camarillo Request for Comments: 3578 Ericsson Category: Standards Track A. B. Roach dynamicsoft J. Peterson NeuStar L. Ong Ciena August 2003 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) 統合ディジタル通信サービス網（ＩＳＤＮ）ユーザ部（ＩＳＵＰ）のセッション開始プロトコルへの重畳マッピング Status of this Memo

この文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書はインターネット共同体のためのインターネット標準化作業中のプロトコルを指定して、そして改良のために議論と提案を求めます。標準化状態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ１）の現在の版を参照してください。このメモの配布は無制限です。 Copyright Notice 著作権表示

Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 概要 This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). 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. Conversion of ISUP Overlap Signalling into SIP en-bloc Signalling 2. ＳＩＰ一括信号へのＩＳＵＰ分割信号の変換 2.1. Waiting for the Minimum Amount of Digits 2.1. 最小の桁数のを待つこと 2.2. The Minimum Amount of Digits has been Received 2.2. 最小桁の受信 3. Sending Overlap Signalling to a SIP Network 3. ＳＩＰネットワークに分割信号を送信 3.1. One vs. Several Transactions 3.1. 単一処理と多数処理 3.2. Generating Multiple INVITEs 3.2. 多数のＩＮＶＩＴＥを生成 3.3. Receiving Multiple Responses 3.3. 多数の応答の受信 3.4. Canceling Pending INVITE Transactions 3.4. 処理中のＩＮＶＩＴＥ処理の中止 3.5. SIP to ISUP 3.5. ＳＩＰからＩＳＵＰ 4. Security Considerations 4. セキュリティの考察 5. Acknowledgments 5. 謝辞 6. Normative References 6. 参照する参考文献 7. Intellectual Property Statement 7. 知的所有権宣言 8. Authors' Addresses 8. 著者のアドレス 9. Full Copyright Statement 9. 著作権表示全文 1. Introduction 1. はじめに A mapping between the Session Initiation Protocol (SIP) [1] and the ISDN User Part (ISUP) [2] of SS7 is described in RFC 3398 [3]. However, RFC 3398 only takes into consideration ISUP en-bloc signalling. En-bloc signalling consists of sending the complete telephone number of the callee in the first signalling message. Although modern switches always use en-bloc signalling, some parts of the PSTN still use overlap signalling. セッション開始プロトコル（ＳＩＰ）[1]とＳＳ７のＩＳＤＮユーザ部（ＩＳＵＰ）[2]間のマッピングがＲＦＣ３３９８[3]で記述されます。しかしながら、ＲＦＣ３３９８はただＩＳＵＰ一括信号を考慮するだけです。一括信号は呼の完全な電話番号を最初の信号メッセージで送ることから成ります。近代的交換機が常に一括信号を使うが、ＰＳＴＮの一部では依然として分割信号を使が使われます。 Overlap signalling consists of sending only some digits of the callee's number in the first signalling message. Further digits are sent in subsequent signalling messages. Although overlap signalling in the PSTN is the source of much additional complexity, it is still in use in some countries. 分割信号は呼の番号の数桁だけを最初の信号メッセージで送ります。以降の桁は次の信号メッセージで送られます。ＰＳＴＮでの分割信号は複雑さを増やす原因であるが、ある国でまだ使用中です。 Like modern switches, SIP uses en-bloc signalling. The Request-URI of an INVITE request always contains the whole address of the callee. Native SIP end-points never generate overlap signalling. 近代的交換機のように、ＳＩＰは一括信号を使います。ＩＮＶＩＴＥ要請の要請ＵＲＩは常に着信者番号全体を含んでいます。ネイティブのＳＩＰ終端点は決して分割信号を生成しません。 Therefore, the preferred solution for a gateway handling PSTN overlap signalling and SIP is to convert the PSTN overlap signalling into SIP en-bloc signalling using number analysis and timers. The gateway waits until all the signalling messages carrying parts of the callee's number arrive, and only then, it generates a SIP INVITE request. Section 2 describes how to convert ISUP overlap signalling into en-bloc SIP this way. それ故に、ＰＳＴＮ分割信号とＳＩＰを扱うゲートウェイの望ましい解決策は、ＰＳＴＮ分割信号を番号分析とタイマーを使ってＳＩＰ一括信号に換えるはずです。ゲートウェイは、着番号の一部を運ぶ信号メッセージの全てが到着するまで待ち、それからＳＩＰのＩＮＶＩＴＥ要請を生成します。２章がこのようにＩＳＵＰ分割信号をＳＩＰ一括信号に換える方法を記述します。 However, although it is the preferred solution, conversion of overlap to en-bloc signalling sometimes results in unacceptable (multiple second) call setup delays to human users. In these situations, some form of overlap signalling has to be used in the SIP network to minimize the call setup delay. However, introducing overlap signalling in SIP introduces complexity and brings some issues. Section 3 analyzes the issues related to the use of overlap signalling in a SIP network and describe ways to deal with them in some particular network scenarios. Section 3 also describes in which particular network scenarios those issues make the use of overlap signalling in the SIP network unacceptable. しかしながら、それが望ましい解決であるけれども、分割信号を一括信号へ変換は、時々電話をしている人間のユーザに受け入れ難い接続遅延（数秒）をもたらします。これらの状態で、ある分割信号の形式が電話の接続遅延を最小にするためにＳＩＰネットワークで使われなければなりません。しかしながら、ＳＩＰに分割信号を導入することは複雑さを導入し、そしてある問題を持ちます。３章がＳＩＰネットワークで分割信号を使用する場合と関係がある問題を分析し、そしてある特定のネットワークの状況で扱う方法を記述します。３章でさらにどの状況でＳＩＰネットワークでの分割信号の使用を受け入れ難くする問題を生じるかを記述します。 2. Conversion of ISUP Overlap Signalling into SIP en-bloc Signalling 2. ＳＩＰ一括信号へのＩＳＵＰ分割信号の変換 In this scenario, the gateway receives an IAM (Initial Address Message) that contains only a portion of the called number. The rest of the digits dialed arrive later in one or more SAMs (Subsequent Address Message). このシナリオで、ゲートウェイは着番号の１部だけを含んでいるＩＡＭ（アドレス開始メッセージ）を受け取ります。ダイヤルされた残りの桁が後の１つ以上のＳＡＭ（次アドレスメッセージ）で到着します。 2.1. Waiting for the Minimum Amount of Digits 2.1. 最小の桁数のを待つこと If the IAM contains less than the minimum amount of digits to route a call, the gateway starts T35 and waits until the minimum amount of digits that can represent a telephone number is received (or a stop digit is received). If T35 expires before the minimum amount of digits (or a stop digit) has been received, a REL with cause value 28 is sent to the ISUP side. T35 is defined in Q.764 [4] as 15-20 seconds. もしＩＡＭが呼の経路を決めるに必要な最小の桁数を含んでいないなら、ゲートウェイはＴ３５を開始し、電話番号を表すことができる最小桁数（あるいはストップ番号）を受信するまで待ちます。もしＴ３５が、最小桁（あるいはストップ番号）を受信する前にタイムアウトするなら、原因値２８のＲＥＬがＩＳＵＰ側に送られます。Ｔ３５は１５-２０秒としてQ.７６４[4]で定義されます。 If a stop digit is received, the gateway can already generate an INVITE request with the complete called number. Therefore, the call proceeds as usual. もしストップ番号を受信するなら、ゲートウェイは完全な着番号でＩＮＶＩＴＥ要請を生成することができます。それ故に、呼処理は通常どおりに進みます。 2.2. The Minimum Amount of Digits has been Received 2.2. 最小桁の受信 Once the minimum amount of digits that can represent a telephone number has been received, the gateway should use number analysis to decide if the number that has been received so far is a complete number. If it is, the gateway can generate an INVITE request with the complete called number. Therefore, the call proceeds as usual. 電話番号を表すことができる最小桁を受信したら、ゲートウェイは受信した番号が完全な番号であるか決めるための番号分析を使うべきです。もし完全な番号であるなら、ゲートウェイは完全な着番号でＩＮＶＩＴＥ要請を生成することができます。それ故に、呼処理は通常どおりに進みます。 However, there are cases when the gateway cannot know whether the number received is a complete number or not. In this case, the gateway should collect digits until a timer (T10) expires or a stop digit (such as, #) is entered by the user (note that T10 is refreshed every time a new digit is received). しかしながら、ゲートウェイが受信番号が完全な番号であるかどうか知ることができない場合があります。この場合、ゲートウェイは、タイマ（Ｔ１０）が切れるかユーザがストップ番号（例えば＃）を入力するまで番号を集めるべきです（新しい番号を受信する度にＴ１０を再設定することを指摘します）。 When T10 expires, an INVITE with the digits collected so far is sent to the SIP side. After this, any SAM received is ignored. Ｔ１０がタイムアウトする時、これまで集められた番号を持つＩＮＶＩＴＥがＳＩＰ側に送られます。この後で、受信したＳＡＭは無視されます。 PSTN MGC/MG SIP | | | |-----------IAM----------->| Starts T10 | | | | |-----------SAM----------->| Starts T10 | | | | |-----------SAM----------->| Starts T10 | | | | | | | | T10 expires |---------INVITE---------->| | | | Figure 1: Use of T10 to convert overlap signalling to en-bloc 図１：分割信号を一括に換えるためのＴ１０の使用 Note that T10 is defined for conversion between overlap signalling (e.g., CAS) and en-bloc ISUP. PSTN switches usually implement a locally defined value of timer T10 -- which may not be within the 4-6 second range recommended by Q.764 [4] -- to convert overlap ISUP to en-bloc ISUP. This document uses T10 and recommends the range of values defined in Q.764 [4], which seems suitable for conversion from overlap to en-bloc SIP operation. The actual choice of the timer value is a matter of local policy. 分割信号（例えば、ＣＡＳ）と一括ＩＳＵＰの間の変換のためにＴ１０が定義されることに注意してください。ＰＳＴＮ交換機が通常分割ＩＳＵＰを一括ＩＳＵＰに換えるためにタイマＴ１０のローカルに定義したタイマ値－これはＱ.７６４ [4]が推薦した４-６秒の範囲ないでないかもしれない－を実装します。この文書はＴ１０を使用し、その値の範囲がＱ.７６４[4]で定義されるものを勧めます、これは分割から一括ＳＩＰオペレーションに変換するのに適しているように思われます。タイマ値の実際の選択はローカルなポリシーの問題です。 3. Sending Overlap Signalling to a SIP Network 3. ＳＩＰネットワークに分割信号を送信 This section analyzes the issues related to the use of overlap signalling in a SIP network and describes a possible solution and its applicability scope. It is important to note that, if used outside its applicability scope, this solution could cause a set of problems, which are identified in this section. この章はＳＩＰネットワークでの分割信号の使用と関係がある問題を分析し、そして可能な解決策とその適用性範囲を記述します。もしその適用性範囲外で使われるなら、この解決策が問題を起こす可能性があることを指摘することは重要で、そしてそれはこの章で明らかにされます。 3.1. One vs. Several Transactions 3.1. 単一処理と多数処理 An ingress gateway receiving ISUP overlap signalling (i.e., one IAM and one or more SAMs) needs to map it into SIP signalling. One possible approach would consists of sending an INVITE with the digits received in the IAM, and once an early dialog is established, sending the digits received in SAMs in a SIP request (e.g., INFO) within that early dialog. ＩＳＵＰ分割信号（すなわち、１つのＩＡＭと１つ以上のＳＡＭ）を受信する入口ゲートウェイがＳＩＰ信号にこれをマップする必要があります。１つの可能な方法は、ＩＡＭで受信した番号をＩＮＶＩＴＥで送り、早期ダイアログが確立されると、早期ダイアログの中のＳＩＰ要請（例えば、ＩＮＦＯ）でＳＡＭで受信した番号を送ることです。 This approach has several problems. It requires that the remote SIP user agent (which might be a gateway) sends a non-100 provisional response as soon as it receives the initial INVITE to establish the early dialog. Current gateways, following the procedures in RFC 3398 [3], do not generate such a provisional response. Having gateways generate such a response (e.g., 183 Session Progress) would cause ingress gateways to generate early ACMs, confusing the PSTN state machine even in calls that do not use overlap signalling. この方法はいくつかの問題を持ちます。それは遠隔ＳＩＰユーザエージェント（ゲートウェイかもしれない）が、それが早期ダイアログを確立するために初期ＩＮＶＩＴＥを受信するとすぐに、非１００の暫定応答を送ることを要求します。現在のゲートウェイは、ＲＦＣ３３９８[3]手順に従って、このような暫定応答を生成しません。ゲートウェイがこのような応答（例えば、１８３セッション進捗）を生み出すようにすることは、入口ゲートウェイで早期ＡＣＭを生成させ、分割信号を使わない呼でもＰＳＴＮ状態遷移を混乱させるでしょう。 In this approach, once the initial INVITE request is routed, all the subsequent requests sent within the early dialog follow the same path. That is, they cannot be re-routed to take advantage of SIP- based services. Therefore, we do not recommend using this approach. この方法で、初期ＩＮＶＩＴＥ要請の経路が決められると、早期ダイアログの中の続く要請がすべては同じパスを通ります。すなわち、ＳＩＰベースのサービスを利用するために経路を変更することができません。それ故に、我々はこの方法を使うことを勧めません。 An alternative approach consists of sending a new INVITE that contains all the digits received so far every time a new SAM is received. Since every new INVITE sent represents a new transaction, they can be routed in different ways. This way, every new INVITE can take advantage of any SIP service that the network may provide. 代替手段はすべての番号を含んでいる新しいＩＭＶＩＴＥを、新しいＳＡＭが受信する毎に送ることです。すべての送られた新しいＩＮＶＩＴＥが新しい処理を表現するので、それらは異なる方法で経路を決めれます。このように、すべての新しいＩＮＶＩＴＥはネットワークが供給する全てのＳＩＰサービスを利用できます。 However, having subsequent INVITEs routed in different ways brings some problems as well. The first INVITE, for instance, might be routed to a particular gateway, and a subsequent INVITE, to another. The result is that both gateways generate an IAM. Since one of the IAMs (or both) has an incomplete number, it would fail, having already consumed PSTN resources. It could even happen that both IAMs contained complete, but different numbers (i.e., one number is the prefix of the other one). しかしながら、次のＩＮＶＩＴＥが異なった道に経路を決めるといくつかの問題をもたらします。最初のＩＮＶＩＴＥは、例えば、特定のゲートウェイに、次のＩＮＶＩＴＥに他に経路を決められるかもしれません。結果は両方のゲートウェイがＩＡＭを生成するということです。ＩＡＭの１一方（あるいは両方）が不完全な番号を持つので、それはＰＳＴＮ資源を消費して、失敗するでしょう。両方のＩＡＭが完全であるが、異なった番号を含むことが生じえます（すなわち、１つの番号が他の番号のプレフィックスです）。 Routing in SIP can be controlled by the administrator of the network. Therefore, a gateway can be configured to generate SIP overlap signalling in the way described below only if the SIP routing infrastructure ensures that INVITEs will only reach one gateway. When the routing infrastructure is not under the control of the administrator of the gateway, the procedures of Section 2 have to be used instead. ＳＩＰのルーティングがネットワーク管理者によって制御できます。それ故に、ゲートウェイが、ＳＩＰルーティングインフラがＩＮＶＩＴＥがただ１つのゲートウェイに届くことを保証する場合に限り、下に記述された方法でＳＩＰ分割信号を生成するように設定することができます。ルーティングインフラがゲートウェイの管理制御下でない時、２章の手順が代わりに使われなければなりません。 Within some dialing plans in the PSTN, a phone number might be a prefix of another one. This situation is not common, but it can occur. Where en-bloc signalling is used, this ambiguity is resolved before the digits are placed in the en-bloc signalling. If overlap signaling was used in this situation, a different user than the one the caller intended to call might be contacted. That is why in the parts of the PSTN where overlap is used, a prefix of a telephone number never identifies another valid number. Therefore, SIP overlap signalling should not be used when attempting to reach parts of the PSTN where it is possible for a number and some shorter prefix of the same number to both be valid addresses of different terminals. ＰＳＴＮのある番号計画で、ある電話番号は他の電話番号のプレフィックスであるかもしれません。この状態は普通ではありませんが、起こることがあります。一括信号が使われる場合、このあいまい性は、番号を一括信号に置かれる前に、解決されます。もし分割信号がこの状態で使われたなら、呼び出し人が意図したもののと異なるユーザに接続するかもしれません。それは分割が使われるＰＳＴＮの部分で、電話番号のプレフィックスが決して他の正しい番号とならない理由です。それ故に、ＳＩＰ分割信号は、ある番号と、その番号のより短いプレフィックスが、共に異なる端末の正当な番号であるようなＰＳＴＮに達しようと試みる時、使われるべきではありません。 3.2. Generating Multiple INVITEs 3.2. 多数のＩＮＶＩＴＥを生成 In this scenario, the gateway receives an IAM (Initial Address Message) and possibly one or more SAMs (Subsequent Address Message) that provide more than the minimum amount of digits that can represent a phone number. このシナリオで、ゲートウェイはＩＡＭ（アドレス開始メッセージ）ともしかしたら最小桁数以上の電話番号を表す１つ以上のＳＡＭ（次アドレスメッセージ）を受信します。 As soon as the minimum amount of digits is received, the gateway sends an INVITE and starts T10. This INVITE is built following the procedures described in RFC 3398 [3]. 最小桁を受信するとすぐにゲートウェイはＩＮＶＩＴＥを送りＴ１０を開始します。このＩＮＶＩＴＥはＲＦＣ３３９８[3]で記述された手順に従って行われます。 If a SAM arrives to the gateway, T10 is refreshed and a new INVITE with the new digits received is sent. The new INVITE has the same Call-ID and the same From header field including the tag as the first INVITE sent, but has an updated Request-URI. The new Request-URI contains all the digits received so far. The To header field of the new INVITE contains all the digits as well, but has no tag. もしＳＡＭがゲートウェイに到着するなら、Ｔ１０は再設定され、そして受信した新しい番号を持つ新しいＩＮＶＩＴＥが送られます。新しいＩＮＶＩＴＥは同じ電話ＩＤと、最初に送ったＩＮＶＩＴＥのタグと更新された要求ＵＲＩ含む同じＦｒｏｍヘッダフィールドを持ちます。新しい要請ＵＲＩはこれまで受け取ったすべての番号を含んでいます。新しいＩＮＶＩＴＥのＴｏフィールドは、同様にすべての番号を含みますが、タグを含みません。 Note that it is possible to receive a response to the first INVITE before having sent the second INVITE. In this case, the response received would contain a To tag and information (Record-Route and Contact) to build a Route header field. The new INVITE to be sent (containing new digits) should not use any of these headers. That is, the new INVITE does not contain neither To tag nor Route header field. This way, this new INVITE can be routed dynamically by the network providing services. ２番目のＩＮＶＩＴＥを送る前に最初のＩＮＶＩＴＥに対する応答を受け取ることが可能であることに注意してください。この場合、受信応答はＴｏタグとＲｏｕｔｅヘッダフィールドを作るための情報（Ｒｅｃｏｒｄ－ＲｏｕｔｅとＣｏｎｔａｃｔを含むでしょう。送信する新しいＩＮＶＩＴＥ（新しい番号を含む）は、これらのヘッダのどれも使うべきありません。すなわち、新しいＩＮＶＩＴＥはＴｏタグとＲｏｕｔｅヘッダフィールドを含みません。このように、この新しいＩＮＶＩＴＥはサービスを供給しているネットワークによって動的に経路を変えれます。 The new INVITE should, of course, contain a Cseq field. It is recommended that the Cseq of the new INVITE is higher than any of the previous Cseq that the gateway has generated for this Call-ID (no matter for which dialog the Cseq was generated). 新しいＩＮＶＩＴＥは、もちろん、Ｃｓｅｑフィールドを含んでいるべきです。新しいＩＮＶＩＴＥのＣｓｅｑはゲートウェイがこの電話ＩＤのために生成した前のＣｓｅｑのどれよりも大きいことが勧められます（ダイアログでＣｓｅｑが生成されたかにかかわらず）。 When an INVITE forks, responses from different locations might arrive establishing one or more early dialogs. New requests such as, PRACK or UPDATE can be sent within every particular early dialog. This implies that the Cseq number spaces of different early dialogs are different. Sending a new INVITE with a Cseq that is still unused by any of the remote destinations avoids confusion at the destination. ＩＮＶＩＴＥが分岐する時、異なった場所からの応答が１つ以上の早期ダイアログを確立して到着するかもしれません。ＰＲＡＣＫやＵＰＤＡＴＥのような新しい要請がすべての特定の早期ダイアログの中で送ることができます。これは異なった早期ダイアログのＣｓｅｑ番号空間が異なっていることを意味します。遠隔宛先のどれででもまだ使われていないＣｓｅｑで新しいＩＮＶＩＴＥを送ることは宛先での混乱を避けます。 If the gateway is encapsulating ISUP messages as SIP bodies, it should place the IAM and all the SAMs received so far in this INVITE. もしゲートウェイがＳＩＰ本体にＩＳＵＰメッセージをカプセル化するなら、このＩＮＶＩＴＥまでに受け取った全てのＩＡＭとＳＡＭを含めるべきです。 PSTN MGC/MG SIP | | | |-----------IAM----------->| Starts T10 | | |---------INVITE---------->| | | | |-----------SAM----------->| Starts T10 | | |---------INVITE---------->| | | | |-----------SAM----------->| Starts T10 | | |---------INVITE---------->| | | | Figure 2: Overlap signalling in SIP 図２：ＳＩＰでの分割信号 If 4xx, 5xx or 6xx final responses arrive (e.g., 484 address incomplete) for the pending INVITE transactions before T10 has expired, the gateway should not send any REL. A REL is sent only if no more SAMs arrive, T10 expires, and all the INVITEs sent have been answered with a final response (different than 200 OK). もし処理中のＩＮＶＩＴＥ取引に対し４ｘｘか５ｘｘか６ｘｘの最終応答（例えば、４８４不完全アドレス）が到着するなら、Ｔ１０がタイムアウトする前にゲートウェイはＲＥＬを送るべきではありません。ＲＥＬはこれ以上のＳＡＭが到着しない場合にだけ送信し、Ｔ１０がタイムアウトし、送った全てのＩＮＶＩＴＥの（２００Ｏ以外の）最終回答が来た場合にだけ送ります。 PSTN MGC/MG SIP | | | |-----------IAM----------->| Starts T10 | | |---------INVITE---------->| | |<---------484-------------| | |----------ACK------------>| | | | | | | | T10 expires | | |<----------REL------------| | Figure 3: REL generation when overlap signalling is used 図３：分割信号が使われる時のＲＥＬ生成 The best status code among all the responses received for all the INVITEs that were generated is used to calculate the cause value of the REL as described in RFC 3398 [3]. 生成したすべてのＩＮＶＩＴＥに対して受信したすべての応答の中で最も良い状態コードが、ＲＦＣ３３９８[3]で記述されるように、ＲＥＬの原因値を計算するために使われます。 The computation of the best response is done in the same way as forking proxies compute the best response to be returned to the client for a particular INVITE. Note that the best response is not always the response to the INVITE that contained more digits. If the user dials a particular number and then types an extra digit by mistake, a 486 (Busy Here) could be received for the first INVITE and a 484 (Address Incomplete) for the second one (which contained more digits). 最も良い回答の計算は特定のＩＮＶＩＴＥのために分岐プロキシがクライアントに返す最も良い応答を計算するのと同じ方法でされます。最も良い回答が常にもっと多くの桁を含むＩＮＶＩＴＥに対する回答ではないことに注意してください。もしユーザが特定の番号に電話し、そして次にまちがって余分の番号をダイヤルしたら、最初のＩＮＶＩＴＥに対して４８６（ビジー）を受信し、次のＩＮＶＩＴＥ（余計な桁を含む）に対し４８４（アドレス不完全）を受信できます。 3.3. Receiving Multiple Responses 3.3. 多数の応答の受信 When overlap signalling in SIP is used, the ingress gateway sends multiple INVITEs. Accordingly, it will receive multiple responses. The responses to all the INVITEs sent, except for one (normally, but not necessarily the last one), are typically 400 class responses (e.g., 484 Address Incomplete) that terminate the INVITE transaction. ＳＩＰでの分割信号が使われる時、入口ゲートウェイは多数のＩＮＶＩＴＥを送ります。したがって、多数の応答を受け取るでしょう。ＩＮＶＩＴＥが送ったすべてに対する応答は、１つ以外（通常最後の、しかし必ずしも最後ではなくてもよい）、一般にＩＮＶＩＴＥ処理を終える４００クラス応答（例えば、４８４不完全アドレス）です。 However, a 183 Session Progress response with a media description can also be received. The media stream will typically contain a message such as, "The number you have just dialed does not exist". しかしながら、メディア記述を持つ１８３のセッション進捗応答も同じく受信できます。メディア流は一般にメッセージ「あなたが電話した番号は存在しない」を含んでいるでしょう。 The issue of receiving different 183 Session Progress responses with media descriptions does not only apply to overlap signalling. When vanilla SIP is used, several responses can also arrive to a gateway if the INVITE forked. It is then up to the gateway to decide which media stream should be played to the user. メディア記述を持つ異なる１８３セッション進捗応答を受信する問題は分割信号だけの問題ではありません。バニラＳＩＰが使われる時、もしＩＮＶＩＴＥが分岐したなら、いくつかの応答がゲートウェイに到着できます。いずれのメディア流をユーザに聞かせるべきか決めることをゲートウェイはしようとしています。 However, overlap signalling adds a requirement to this process. As a general rule, a media stream corresponding to the response to an INVITE with a greater number of digits should be given more priority than media streams from responses with less digits. しかしながら、分割信号がこの処理に必要条件を加えます。一般的な規則として、桁数の大きい番号のＩＮＶＩＴＥに対する応答に対応しているメディア流はより少ない桁数の番号の応答からのメディア流より大きい優先順位を与えられるべきです。 3.4. Canceling Pending INVITE Transactions 3.4. 処理中のＩＮＶＩＴＥ処理の中止 When a gateway sends a new INVITE containing new digits, it should not CANCEL the previous INVITE transaction. This CANCEL could arrive before the new INVITE to an egress gateway and trigger a REL before the new INVITE arrived. INVITE transactions are typically terminated by the reception of 4xx responses. ゲートウェイが新しいＩＮＶＩＴＥを新しい番号を含て送る時、前のＩＮＶＩＴＥ処理を中止するべきではありません。このＣＡＮＣＥＬは出口ゲートウェイに新しいＩＮＶＩＴＥが到着する前に到着し、新しいＩＮＶＩＴＥが到着する前にＲＥＬを引き起こすことがあります。ＩＮＶＩＴＥ処理が一般に４ｘｘ応答の受信で終わります。 However, once a 200 OK response has been received, the gateway should CANCEL all the other INVITE transactions were generated. A particular gateway might implement a timer to wait for some time before sending any CANCEL. This gives time to all the previous INVITE transactions to terminate smoothly without generating more signalling traffic (CANCEL messages). しかし、２００ＯＫ応答を受信したら、ゲートウェイが生成したすべての他のＩＮＶＩＴＥ処理をＣＡＮＣＥＬすべきです。特定のゲートウェイがＣＡＮＣＥＬを送る前にしばらくの間待つタイマを実装するかもしれません。これは追加の信号トラフィック（ＣＡＮＣＥＬメッセージ）を生成せずに順調にＩＮＶＩＴＥ処理を終了させる時間を与えます。 3.5. SIP to ISUP 3.5. ＳＩＰからＩＳＵＰ In this scenario (the call originates in the SIP network), the gateway receives multiple INVITEs that have the same Call-ID but have different Request-URIs. Upon reception of the first INVITE, the gateway generates an IAM following the procedures described in RFC 3398 [3]. このシナリオ（電話はＳＩＰネットワークから始まる）で、ゲートウェイは同じ電話ＩＤを持つが、要請－ＵＲＩが異なる多数のＩＮＶＩＴＥを受け取ります。最初のＩＮＶＩＴＥを受信したら、ゲートウェイはＲＦＣ３３９８ [3]で記述した処理に従いＩＡＭを生成します。 When a gateway receives a subsequent INVITE with the same Call-ID and From tag as the previous one, and an updated Request-URI, a SAM should be generated as opposed to a new IAM. Upon reception of a subsequent INVITE, the INVITE received previously is answered with 484 Address Incomplete. ゲートウェイが前と同じ電話ＩＤとＦｒｏｍタグと、更新された要請ＵＲＩを持つ続くＩＮＶＩＴＥを受信したら、新しいＩＡＭに対応するＳＡＭが生成されるべきです。次のＩＮＶＩＴＥを受信したら、前に受信したＩＮＶＩＴＥには、４８４アドレス不完全でで応答します。 If the gateway is attached to the PSTN in an area where en-bloc signalling is used, a REL for the previous IAM and a new IAM should be generated. もしゲートウェイが一括信号が使われる区域でＰＳＴＮに接続するなら、前のＩＡＭに対するＲＥＬと新しいＩＡＭが生成されるべきです。 4. Security Considerations 4. セキュリティの考察 When overlap signaling is employed, it is possible that an attacker could send multiple INVITEs containing an incomplete address to the same gateway in an attempt to occupy all available ports and thereby deny service to legitimate callers. Since none of these partially addressed calls would ever complete, in a traditional billing scheme, the sender of the INVITEs might never be charged. To address this threat, the authors recommend that gateway operators authenticate the senders of INVITE requests, first, in order to have some accountability for the source of calls (it is very imprudent to give gateway access to unknown users on the Internet), but second, so that the gateway can determine when multiple calls are originating from the same source in a short period of time. Some sort of threshold of hanging overlap calls should be tracked by the gateway, and after the limit is exceeded, the further similar calls should be rejected to prevent the saturation of gateway trunking resources. 分割信号が使用される時、攻撃者が不完全なアドレスを含んでいる多数のＩＮＶＩＴＥを同じゲートウェイに送り、すべての利用可能なポートを占領して、正当な発信者のサービスを妨害する試みは可能です。これらの部分アドレス電話のいずれも完了しないだろうから、伝統的な請求処理で、ＩＮＶＩＴＥの送信者は決して告発されないかもしれません。この脅威を扱うために、著者は、最初に、呼の発信者に対する責任を持つためにゲートウェイオペレータが最初にＩＮＶＩＴＥの送信者の認証をし（インターネット上の未知のユーザにゲートウェイアクセスを与えることは非常に軽率である）、第二に、ゲートウェイが多数の呼が短期間に同じ発信者から生成された事を検出する事を薦めます。何らかの閾値を設けて重複呼をゲートウェイが追跡するべき、そして限界を越えた後、それ以上の類似の呼はゲートウェイ中継資源の飽和を妨げるために拒絶されるべきです。 5. Acknowledgments 5. 謝辞 Jonathan Rosenberg, Olli Hynonen, and Mike Pierce provided useful feedback on this document. Jonathan RosenbergとOlli HynonenとMike Pierceはこの文書の有用なフィードバックを供給しました。 6. Normative References 6. 参照する参考文献 [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] "Application of the ISDN user part of CCITT signaling system no. 7 for international ISDN interconnections", ITU-T Q.767, February 1991. [3] Camarillo, G., Roach, A. B., Peterson, J. and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. [4] "Signalling system no. 7 - ISDN user part signalling procedures," ITU-T Q.764, December 1999. 7. Intellectual Property Statement 7. 知的所有権宣言 The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. この文書に記述された実装や技術に関して主張される知的財産や他の権利の正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書での権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの結果はＩＥＴＦ事務局で得られます。 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカバーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求めます。どうかＩＥＴＦ専務に情報を伝えてください。 8. Authors' Addresses 8. 著者のアドレス Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA EMail: adam@dynamicsoft.com Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA EMail: jon.peterson@neustar.biz Lyndon Ong Ciena 5965 Silver Creek Valley Road San Jose, CA 95138 USA EMail: lyong@ciena.com 9. Full Copyright Statement 9. 著作権表示全文 Copyright (C) The Internet Society (2003). 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 assignees. 上に与えられた限定された許可は永久で、インターネット学会やその後継者や譲渡者によって無効にされません。 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. ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって供給されます。

Japanese translation by Ishida So