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 セッション開始プロトコル(SIP)に対する 統合デジタルネットワーク(ISDN)ユーザー部分(ISUP) 重複シグナリングのマッピング Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The Internet Society (2003).All Rights Reserved. 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP)に 対して統合サービスデジタルネットワークユーザー部(Integrated Services Digital Network User Part / ISUP)重複シグナリング(overlap signalling) をマッピングする方法について説明する。このメカニズムは、呼の一部が公 衆電話交換回線網(Public SwitchedTelephone Network / PSTN)との相互作用 に関係するときに実装することができる。 Camarillo, et al. Standards Track [Page 1] RFC 3578 ISUP Overlap Signalling to SIP August 2003 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ISUP重複シグナリングからSIP en-blocシグナリング への変換 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. 最小桁数の待機 . . . . . . . . . . . . . . . . . . . . . 4 2.2. 最小桁数の受信 . . . . . . . . . . . . . . . . . . . . . 4 3. SIPネットワークに対する重複シグナリングの送信 . . . . . . . . 5 3.1. 1対複数のトランザクション . . . . . . . . . . . . . . . 5 3.2. 複数のINVITEの生成 . . . . . . . . . . . . . . . . . . . 6 3.3. 複数の応答の受信 . . . . . . . . . . . . . . . . . . . . 8 3.4. 保留中のINVITEトランザクションのキャンセル . . . . . . . 9 3.5. SIPからISUPへ . . . . . . . . . . . . . . . . . . . . . 9 4. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 10 5. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . . 10 7. 知的所有権表記 . . . . . . . . . . . . . . . . . . . . . . . . 11 8. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . . 13 Camarillo, et al. Standards Track [Page 2] RFC 3578 ISUP Overlap Signalling to SIP August 2003 1. はじめに セッション開始プロトコル(SIP) [1]とSS7のISDNユーザー部(ISUP) [2]間の マッピングについては、RFC 3398 [3]で説明されている。ただし、ISUP en-blocシグナリングを考慮に入れているのはRFC 3398のみである。en-bloc シグナリングでは、最初のシグナリングメッセージで着呼側の完全な電話番 号が送信される。現在の回線交換では、常にen-blocシグナリングを使用す るが、PSTNの一部はまだ重複シグナリングを使用している。 重複シグナリングは、最初のシグナリングメッセージで着呼側番号の一部の 桁のみが送信される。その他の桁は、後続のシグナリングメッセージで送信 される。PSTNの重複シグナリングは処理が大幅に複雑になる原因だが、一部 の国ではまだ使用されている。 現在の回線交換と同様に、SIPはen-blocシグナリングを使用している。 INVITEリクエストのRequest-URIには、常に着呼側側のアドレス全体が含ま れる。ネイティブのSIPエンドポイントが重複シグナリングを生成すること はない。 したがって、ゲートウェイ処理を行うPSTNの重複シグナリングとSIPに適し たソリューションは、番号分析とタイマーを使用して、PSTNの重複シグナリ ングをSIPのen-blocシグナリングを変換する方法である。ゲートウェイは、 着呼側番号の一部を伝達するすべてのシグナリングメッセージが到達するま で待機し、完了後に、SIP INVITEリクエストを生成する。セクション2では、 この方法でISUP重複シグナリングをen-bloc SIPに変換する手順について説 明する。 ただし、これは推奨のソリューションではあるが、重複シグナリングから en-blocシグナリングへの変換によって、ユーザーには容認できない(複数の 第2の)通話のセットアップ遅延が発生する可能性がある。このような場合、 ある種の重複シグナリングをSIPネットワークに使用して、通話のセット アップ遅延を最小限に抑える必要がある。ただし、SIPに重複シグナリング を導入することで、複雑さが増し、いくつかの問題も発生する。 セクション3では、SIPネットワークに重複シグナリングを使用することに関 する問題について分析し、いくつかの具体的なネットワークシナリオを使用 して対処方法について説明する。また、セクション3では、SIPネットワーク で重複シグナリングを使用できなくなるような問題が発生するネットワーク シナリオについても説明する。 2. ISUP重複シグナリングからSIP en-blocシグナリングへの変換 このシナリオでは、ゲートウェイが着呼側番号の一部のみを含むIAM (Initial Address Message/初期アドレスメッセージ)を受信する。ダイヤル された残りの桁は、1つまたは複数のSAM (Subsequent Address Message/後 続アドレスメッセージ)で到達する。 Camarillo, et al. Standards Track [Page 3] RFC 3578 ISUP Overlap Signalling to SIP August 2003 2.1. 最小桁数の待機 呼をルーティングするために必要な最小桁数を下回る桁しかIAMに含まれない 場合、ゲートウェイはT35を開始し、電話番号を表現できる最小桁数を受信す るまで(または停止桁を受信するまで)待機する。最小桁数(停止桁)を受信す る前にT35が期限切れになった場合、理由値28のRELがISUP側に送信される。 T35はQ.764 [4]に15〜20秒と定義されている。 停止桁を受信した場合、ゲートウェイは完全な着呼側番号を含むINVITEリク エストを生成することができる。したがって、呼は通常どおり進行する。 2.2. 最小桁数の受信 電話番号を表現できる最小桁数を受信した後、ゲートウェイは番号分析を使 用して、それまでに受信した番号が完全な番号かどうかを判断する。完全な 番号の場合、ゲートウェイはその完全な着呼側番号を使用してINVITEリクエ ストを生成することができる。したがって、呼は通常どおり進行する。 ただし、受信した番号が完全な番号かどうかをゲートウェイが認識できない 場合がある。この場合、タイマー(T10)が期限切れになるか、ユーザーが停 止桁(#など)を入力するまで、ゲートウェイは桁を収集すべきである(T10は 新しい桁の受信ごとに更新されることに注意)。 T10が期限切れになると、それまでに収集した桁を使用してINVITEがSIP側に 送信される。この後、受信したSAMは無視される。 PSTN MGC/MG SIP | | | |-----------IAM----------->| Starts T10 | | | | |-----------SAM----------->| Starts T10 | | | | |-----------SAM----------->| Starts T10 | | | | | | | | T10 expires |---------INVITE---------->| | | | 図1: T10を使用した重複シグナリングのen-blocへの変換 Camarillo, et al. Standards Track [Page 4] RFC 3578 ISUP Overlap Signalling to SIP August 2003 重複シグナリング(CASなど)とen-bloc ISUP間の変換にT10が定義されている ことに注意。通常、PSTNスイッチは、ローカルで定義されたタイマーT10の 値を実装し(Q.764 [4]が推奨する4〜6秒の範囲に含まれない可能性がある)、 重複のISUPをen-bloc ISUPに変換する。本文書はT10を使用し、Q.764 [4]で 定義されている値の範囲を推奨している。この値は、重複からen-bloc SIP 操作への変換に適していると考えられる。タイマー値の実際の選択は、ロー カルポリシーの問題である。 3. SIPネットワークに対する重複シグナリングの送信 このセクションでは、SIPネットワークにおける重複シグナリングの使用に 関する問題について分析し、考えられるソリューションと適用可能範囲につ いて説明する。注意が必要なのは、適用可能範囲外で使用された場合、この ソリューションは複数の問題を引き起こす可能性がある点である。これらの 問題については、このセクションで確認する。 3.1. 1対複数のトランザクション ISUP重複シグナリング(つまり、1つのIAMと1つまたは複数のSAM)を受信する 入り口ゲートウェイは、それをSIPシグナリングにマッピングする必要があ る。考えられる1つのアプローチは、IAMで受信した桁を使用してINVITEを送 信し、初期ダイアログが確立したら、その初期ダイアログ内のSIPリクエス ト(INFOなど)のSAMで受信した桁を送信する方法である。 このアプローチには複数の問題がある。リモートのSIPユーザーエージェン ト(ゲートウェイの可能性あり)が、最初のINVITEを受信してすぐに非100暫 定応答を送信して、初期ダイアログを確立する必要がある。現在のゲート ウェイは、RFC 3398 [3]の手順に従っているため、このような暫定応答を生 成しない。ゲートウェイにこのような応答(183 Session Progressなど)を生 成させると、入り口のゲートウェイが初期ACMを生成するため、重複シグナ リングを使用しない通話でも、PSTNのステートマシンが混乱する。 このアプローチでは、最初のINVITEリクエストがルーティングされると、初 期ダイアログ内で送信される以降のリクエストすべてが同じパスに従う。つ まり、SIPベースのサービスを利用するようにルーティングを変更できなく なる。したがって、このアプローチの使用は推奨しない。 代替のアプローチとして、新しいSAMが受信されるたびに、それまでに受信 したすべての桁を含む新しいINVITEを送信する方法がある。送信されるそれ ぞれの新しいINVITEは新しいトランザクションを表すため、異なる方法で ルーティングすることができる。このように、それぞれの新しいINVITEは、 ネットワークが提供するすべてのSIPサービスを利用できるようになる。 Camarillo, et al. Standards Track [Page 5] RFC 3578 ISUP Overlap Signalling to SIP August 2003 ただし、後続のINVITEを異なる方法でルーティングした場合も、いくつか問 題が発生する。たとえば、最初のINVITEが特定のゲートウェイにルーティン グされ、後続のINVITEは別のゲートウェイにルーティングされる可能性が ある。その結果、両方のゲートウェイがIAMを生成する。IAMのいずれか(また は両方)は不完全な番号を保持しているため失敗するが、PSTNリソースはすで に消費されている。さらに、両方のIAMに完全で異なる番号が含まれる状況も 発生する可能性がある(つまり、一方の番号がもう一方のプレフィックスの 場合)。 SIPのルーティングは、ネットワーク管理者が制御することができる。 したがって、ゲートウェイを設定して、後述のようにSIPの重複シグナリン グを生成することができる。ただし、INVITEが1つのゲートウェイにのみ到 達するように、SIPルーティングインフラが確保されている場合に限られる。 ルーティングインフラがゲートウェイ管理者の制御下にない場合、セクショ ン2の手順を代わりに使用する必要がある。 PSTNの一部のダイヤル計画では、電話番号が別の電話番号のプレフィックス の場合がある。この状況は一般的ではないが、発生する可能性がある。 en-blocシグナリングを使用する場合、番号がen-blocシグナリングに設定さ れる前に、このあいまいさは解決される。この状況で重複シグナリングが使 用された場合、発信側が通話相手として意図したユーザーとは異なるユー ザーにつながる可能性がある。この理由は、重複を使用する一部のPSTNで は、電話番号のプレフィックスが別の有効な番号を識別しないためである。 したがって、番号とその番号の短いプレフィックスの両方を、異なる端末の 有効なアドレスとして扱う可能性がある一部のPSTN宛ての場合、SIP重複シ グナリングは使用すべきではない。 3.2. 複数のINVITEの生成 このシナリオでは、電話番号を表現できる最小桁数より多くの桁数を示す、 IAM (Initial Address Message)ともしかすると1つまたは複数のSAM (Subsequent Address Message) をゲートウェイが受信する。 最小桁数を受信するとすぐに、ゲートウェイはINVITEを送信し、T10を開始 する。このINVITEは、RFC 3398 [3]に記載されている手順に従って構築さ れる。 SAMがゲートウェイに到達すると、T10が更新され、受信した新しい桁を含む 新しいINVITEが送信される。新しいINVITEは、最初に送信されたINVITEと同 じCall-IDと同じFromヘッダーフィールド(タグを含む)だが、Request-URIは 更新されている。新しいRequest-URIには、これまでに受信したすべての桁 数が含まれる。新しいINVITEのToヘッダーフィールドには同様にすべての桁 が含まれるが、タグは含まれない。 Camarillo, et al. Standards Track [Page 6] RFC 3578 ISUP Overlap Signalling to SIP August 2003 2番目のINVITEを送信する前に、最初のINVITEに対する応答を受信する可 能性があることに注意。この場合、受信した応答には、Routeヘッダー フィールドを構築するためのToタグと情報が含まれる。送信される新し いINVITE (新しい桁を含む)は、これらのヘッダーのいずれも使用すべき ではない。つまり、新しいINVITEにはToタグもRouteヘッダーフィールド も含まれない。その結果、この新しいINVITEは、ネットワークが提供す るサービスによって動的にルーティングすることができる。 新しいINVITEには、当然ながらCseqフィールドが含まれる。新しいINVITEの Cseqは、(Cseqを生成したダイアログに関係なく、)ゲートウェイがこの Call-ID用に生成したそれまでのCseqよりも高くすることを推奨する。 INVITEが分岐する場合、異なる場所から応答が送信され、1つまたは複数 の初期ダイアログが確立する可能性がある。PRACKやUPDATEなどの新しい リクエストは、個々の初期ダイアログ内で送信することができる。つま り、異なる初期ダイアログのCseq番号空間は異なることを意味する。ど のリモートの送信先もまだ使用していないCseqで新しいINVITEを送信す ると、送信先での混乱を防ぐことができる。 ゲートウェイがSIPの本文としてISUPメッセージをカプセル化している場合、 このINVITEに、それまでに受信したIAMとすべてのSAMを含めるべきである。 PSTN MGC/MG SIP | | | |-----------IAM----------->| Starts T10 | | |---------INVITE---------->| | | | |-----------SAM----------->| Starts T10 | | |---------INVITE---------->| | | | |-----------SAM----------->| Starts T10 | | |---------INVITE---------->| | | | 図2: SIPの重複シグナリング Camarillo, et al. Standards Track [Page 7] RFC 3578 ISUP Overlap Signalling to SIP August 2003 T10が期限切れになる前に、保留中のINVITEトランザクションの4xx、5xx、ま たは6xx 最終応答 (484 address incomplete など) が到達した場合、ゲート ウェイはRELを一切送信すべきではない。RELを送信するのは、SAMの受信が 停止し、T10が期限切れになり、すべてのINVITEに最終応答(200 OK以外)が 送信された場合のみである。 PSTN MGC/MG SIP | | | |-----------IAM----------->| Starts T10 | | |---------INVITE---------->| | |<---------484-------------| | |----------ACK------------>| | | | | | | | T10 expires | | |<----------REL------------| | 図3: 重複シグナリング使用時のREL生成 RFC 3398 [3]に従って、生成されたすべてのINVITEに対して受信されたすべ ての応答の中で、最適なステータスコードを使用して、RELの理由値を計算 する。 最適な応答の計算は、分岐実行プロキシが、特定のINVITEに関してクラ イアントに返す最適な応答を計算する場合と同様の方法で実行される。 より多い桁数を含むINVITEに対する応答が常に最適な応答とは言えない ことに注意。ユーザーが特定の番号をダイヤルし、間違って余計な番号 を入力した場合、最初のINVITEに対して486 (Busy Here)が受信され、 2番目のINVITE (桁数が多い方)に対して484 (Address Incomplete)が受 信される可能性がある。 3.3. 複数の応答の受信 SIPで重複シグナリングを使用すると、入り口のゲートウェイは複数のINVITE を送信する。また、それに従って複数の応答を受信することになる。 送信されたすべてのINVITEに対する応答は、1つ(通常は最後の応答だが最後 とは限らない)を除き、一般的に、INVITEトランザクションを終了する400ク ラスの応答である(484 Address Incompleteなど)。 ただし、メディア記述付きの183 Session Progress応答も受信する可能性が ある。一般的に、メディアストリームには「ダイヤルした番号は存在しま せん」などのメッセージが含まれる。 Camarillo, et al. Standards Track [Page 8] RFC 3578 ISUP Overlap Signalling to SIP August 2003 異なるメディア記述付きの183 Session Progress応答を受信する問題は、重 複シグナリングに限られた問題ではありません。標準的なSIPを使用する 場合、INVITEが分岐すると、複数の応答がゲートウェイに到達する可能性が ある。この場合、ユーザーに対して再生するメディアストリームを決定する のは、ゲートウェイである。 ただし、重複シグナリングによってこの処理に1つの要件が加わる。一般則 として、より桁数が多いINVITEに対する応答に対応するメディアストリーム には、少ない桁数の応答のメディアストリームよりも高い優先度が与えられ るべきである。 3.4. 保留中のINVITEトランザクションのキャンセル ゲートウェイが新しい桁を含む新しいINVITEを送信する場合、前のINVITEト ランザクションをCANCELすべきではない。このCANCELは、新しいINVITEより 先に入り口のゲートウェイに到達し、新しいINVITEが到達する前にRELをト リガする可能性がある。INVITEトランザクションは、一般的に、4xx応答の 受信で終了する。 ただし、200 OK応答を受信した場合、ゲートウェイは、生成されたその他す べてのINVITEトランザクションをCANCELすべきである。ゲートウェイで、 CANCELを送信する前に一定の時間を待機するタイマーを実装することもで きる。これによって、追加のシグナリングトラフィック(CANCELメッセージ) を生成することなく、それまでのすべてのINVITEトランザクションを円滑に 終了する時間ができる。 3.5. SIPからISUPへ このシナリオ(SIPネットワークから発信される場合)では、Call-IDは同じだ がRequest-URIは異なる複数のINVITEをゲートウェイが受信する。ゲート ウェイは最初のINVITEを受信すると、RFC 3398 [3]に記載されている手順に 従って、IAMを生成する。 ゲートウェイが、以前のINVITEとCall-IDとFromタグが同じで、Request-URI が更新された後続のINVITEを受信すると、新しいIAMとは対照的にSAMを生成 すべきである。後続のINVITEを受信した場合、以前に受信したINVITEには 484 Address Incompleteで応答する。 en-blocシグナリングを使用する領域のPSTNにゲートウェイが属している場 合、以前のIAMと新しいIAMのRELを生成すべきである。 Camarillo, et al. Standards Track [Page 9] RFC 3578 ISUP Overlap Signalling to SIP August 2003 4. セキュリティの考慮事項 重複シグナリングを採用する場合、攻撃者が不完全なアドレスを含む複数の INVITEを同じゲートウェイに送信して使用できるすべてのポートを独占し、 正規の発信者に対するサービスを妨害する可能性がある。このように部分的 にアドレスが指定された発呼は完了しないため、従来の請求スキームでは、 INVITEの送信者に請求することはできない。この脅威に対処するために、 ゲートウェイオペレータがINVITEリクエストの送信者を認証する(インター ネットでは不明なユーザーにゲートウェイのアクセス権を与えるのは非常に 無分別である)。これは、第1に発信元に一定の説明責任を持たせるためであ り、第2に短い間隔で同じ発信元から複数の発信があった場合にゲートウェ イが判断できるようにするためである。ゲートウェイは、重複する発呼を切 断する何らかのしきい値を追跡するべきである。また、その制限を超えた 場合、以降は同様の発呼を拒否し、ゲートウェイのトランキングリソースを 飽和を防ぐべきである。 5. 謝辞 Jonathan Rosenberg、Olli Hynonen、Mike Pierceからこの文書に有益な フィードバックをいただいた。 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. Camarillo, et al. Standards Track [Page 10] RFC 3578 ISUP Overlap Signalling to SIP August 2003 7. 知的所有権表記 IETFは、知的所有権、あるいは本文書に記載される技術の実装または使用に 関して主張される可能性のある他のいかなる権利についても、有効期間また は範囲に関して、あるいはこのような権利下でどのようなライセンスの範囲 までが利用可能か否かに関して、何ら見解を持たない。また、このような権 利を特定しようともしていない。標準化過程および標準化関連の文書におけ る権利についてIETFの手続き上の情報は、BCP-11を参照すること。こうした 所有権について、本仕様の実装者あるいはユーザーが公開のために利用可能 とされた権利請求のコピー、および、利用可能とされたライセンスの保証、 あるいは、一般的なライセンスまたは許可を取得しようと試みた結果は、 IETF事務局から入手できる。 IETFは、この規格を実行するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。これ らの情報については、IETFの事務局長への連絡を請う。 Camarillo, et al. Standards Track [Page 11] RFC 3578 ISUP Overlap Signalling to SIP August 2003 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 Camarillo, et al. Standards Track [Page 12] RFC 3578 ISUP Overlap Signalling to SIP August 2003 9. 完全な著作権表記 Copyright (C) The Internet Society (2003).All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた 派生的製品や、この文書を説明したり、その実装を補助するもので、上記の 著作権表示およびこの節を付加するものはすべて、全体であってもその一部 であっても、いっさいの制約を課されること無く、準備、複製、発表、配布 することができる。しかし、この文書自体にはいかなる方法にせよ、著作権 表示やインターネット協会もしくは他のインターネット関連団体への参照を 取り除くなどの変更を加えてはならない。インターネット標準を開発するた めに必要な場合は例外とされるが、その場合はインターネット標準化過程で 定義されている著作権のための手続きに従わなければならない。またRFCを 英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくは その継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという 保証、商用利用および特定目的への適合性への保証を含め、また、これらだ けに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2008年 ----------------------------------------------------------------------- Camarillo, et al. Standards Track [Page 13]