Network Working Group G. Camarillo Request for Comments: 3960 Ericsson Category: Informational H. Schulzrinne Columbia University December 2004 セッション開始プロトコル(SIP)における 初期メディアと呼び出し音生成 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネット社会に情報を提供するためのものである。いかなる インターネット標準も規定しない。この文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書では、ゲートウェイモデルとアプリケーションサーバーモデルという、 2つのモデルを使用して、セッション開始プロトコル(Session Initiation Protocol/SIP)における初期メディアを管理する方法について説明する。ま た、呼び出し音の生成に関するローカルポリシーを定義する上で、検討が必要 な事項についても説明する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SIPにおけるセッションの確立 . . . . . . . . . . . . . . . . . 3 3. ゲートウェイモデル . . . . . . . . . . . . . . . . . . . . . 4 3.1. フォーク . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. 呼び出し音の生成 . . . . . . . . . . . . . . . . . . . 5 3.3. 初期メディアインジケータがない場合 . . . . . . . . . . . 7 3.4. ゲートウェイモデルの適用性 . . . . . . . . . . . . . . . 8 4. アプリケーションサーバーモデル . . . . . . . . . . . . . . . 8 4.1. インバンド対アウトバンドのセッション進捗情報 . . . . . 9 5. Alert-Infoヘッダーフィールド . . . . . . . . . . . . . . . . . 9 6. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . 9 7. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 11 8.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 11 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 12 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . 13 Camarillo & Schulzrinne Informational [Page 1] RFC 3960 Early Media and Ringing Tone Generation December 2004 1. はじめに 初期メディアとは、特定セッションが着信側ユーザーに受け入れられる前に交 換されるメディア(例: 音声、ビデオ)を指す。ダイアログ内で、初期メディア は、最初のINVITEが送信された瞬間から、ユーザーエージェントサーバー (User Agent Server/UAS)が最終応答を生成するまでの間に生じる。単一方向 性、双方向性の場合があり、発呼側、着呼側、またはその両方で生成される可 能性がある。着呼側で生成される初期メディアの一般的な例は、呼び出し音と 告知(例: 待機状態)である。発呼側で生成される初期メディアは、一般的に、 双方向音声応答(Interactive Voice Responce/IVR)システムを機能させる音声 コマンドやデュアルトーン多重周波数(dual tone multi-frequency/DTMF)トー ンで構成される。 基本のSIP仕様(RFC3261/参考文献[1])では、非常に単純な初期メディアの仕組 みにしか対応していない。RFC3261の単純な仕組みには、フォークとセキュリ ティに関連する問題が数多くあり、ほとんどのアプリケーションの要件を満た さない。本文書では、RFC3261(参考文献[1])で定義された仕組みを超えて、 ゲートウェイモデルとアプリケーションサーバーモデルという、SIPを使用し た初期メディアを実装する2つのモデルについて説明する。 本文書で説明されているどちらの初期メディアモデルも、RFC3261(参考文献 [1])で規定されているものよりも優れているが、ゲートウェイモデルには、い くつかの問題が残っている。特に、ゲートウェイモデルはフォークする場合に は十分に機能しない。それでもなお、ゲートウェイモデルは必要である。理由 は、一部のSIPエンティティ(特に一部のゲートウェイ)は、アプリケーション サーバーモデルを実装できないためである。 アプリケーションサーバーモデルは、ゲートウェイモデルに存在する問題の一 部に対処している。このモデルでは、初期セッションのディスポジションタイ プ(参考文献[2]で規定)を使用する。 本文書では、以下のセクションで構成されている。セクション2では初期メ ディアがない場合のオファー/アンサーモデルについて説明し、セクション3で はゲートウェイモデルを紹介する。このモデルでは、初期メディアセッション は、最初のINVITEによって確立されたearlyダイアログを使用して確立され る。セクション3.1、3.2、3.4では、ゲートウェイモデルの制限と、ゲート ウェイモデルの使用が適切な場合のシナリオについて説明する。セクション4 では、アプリケーションサーバーモデルを紹介し、前述のように、ゲートウェ イモデルに存在する問題の一部に対処する。セクション5では、2つの初期メ ディアモデルにおけるAlert-Infoヘッダーフィールド間の相互作用について論 ずる。 本文書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」は、参考文献[9]で記述されている通りに解釈される。 Camarillo & Schulzrinne Informational [Page 2] RFC 3960 Early Media and Ringing Tone Generation December 2004 2. SIPにおけるセッションの確立 初期メディアモデルを説明する前に、SIPでセッションが確立する方法につい て要約する。これによって、SIP固有の機能(例: メディアの省略(media clipping)を防ぐために200 OK前に再生されるメディア)と、初期メディア操作 とを区別することができる。 SIP(参考文献[1])では、オファー/アンサーモデル(参考文献[3])を使用して、 セッションパラメータをネゴシエートしている。ユーザーエージェントの1つ (オファー側)は、セッション記述(オファーと呼ぶ)を用意する。他方のユー ザーエージェント(アンサー側)は、アンサーという別のセッション記述で応答 する。このツーウェイハンドシェイクによって、両方のユーザーエージェント は、メディアの交換に使用されるセッションパラメータに関して合意すること ができる。 オファー/アンサーモデルによって、オファー/アンサー交換は、セッション記 述の伝送に使用されるメッセージから分離される。たとえば、オファーは INVITEリクエストで送信することができ、アンサーはINVITEに対する200 OK応 答で受信することができる。あるいは、そうではなく、オファーは空のINVITE に対する200 OKで送信して、応答はACKで送信することができる。信頼性のあ る暫定応答(参考文献[4])とUPDATEリクエスト(参考文献[5])を使用すると、オ ファー/アンサーの交換には実に多様な方法が考えられる。 メディアの省略は、ユーザー(またはメディアを生成するマシン)が、メディア セッションが確立済みであると信じているが、確立プロセスがまだ完了してい ない場合に発生する。ユーザーが話し始めると(つまり、メディアを生成する と)、始まりの数文字、場合によっては数単語が失われる。 オファー/アンサー交換を200 OK応答とACKで実行する場合、メディアの省略は 避けられない。着呼側ユーザーは200 OKが送信されると同時に話し始めるが、 UASは、ユーザーエージェントクライアント(User Agent Client/UAC)からのア ンサーがACKで到達するまで、メディアを送信できない。 一方で、メディアの省略は、ほとんどの一般的なオファー/アンサー交換(オ ファーにINVITEとアンサーに200 OK)では見られない。UACは、オファーを送信 してすぐに受信メディアパケットを再生する準備を整える。これは、発呼側で メディアを再生し始める際に、200 (OK)の受信を当てにすることができないた めである。SIPシグナリングとメディアパケットは、通常、異なるパスで伝達 されるため、メディアパケットは、200 (OK)応答の前に到達する可能性があ る。 別形式のメディアの省略は、(初期メディアとは関係ないが)発呼側から着呼側 の方向で発生する。着呼側が電話を取り、話し始めると、UASは、アンサーと 同時に最初のメディアパケットで、200 (OK)応答を送信する。アンサー前に最 Camarillo & Schulzrinne Informational [Page 3] RFC 3960 Early Media and Ringing Tone Generation December 2004 初のメディアパケットがUACに到達して、さらに発呼側が話し始めると、UASか らの200 (OK)応答が届くまでUACはメディアを送信できない。 3. ゲートウェイモデル SIPでは、オファー/アンサーモデルを使用して、セッションパラメータをネゴ シエートしている(セクション2参照)。INVITEの最終応答が送信される前に実 行されるオファー/アンサー交換によって、「初期の」メディアセッションが 確立する。初期メディアセッションは、INVITEに対する最終応答が送信される と、終了する。最終応答が200 (OK)の場合、初期メディアセッションは、通常 のメディアセッションに遷移する。最終応答が非200クラスの最終応答である 場合、初期メディアセッションは、単に終了する。 当然ながら、初期メディアセッション内で交換されるメディアは、初期メディ アと呼ばれる。ゲートウェイモデルは、信頼性のある暫定応答、PRACK、 UPDATEにおけるオファー/アンサー交換を使用する、初期メディアセッション の管理で構成される。 ゲートウェイモデルには、セクション3.1で説明するように、フォークがある 場合には重大な制限がある。そのため、この用法は、セクション3.4で説明す るように、ユーザーエージェント(User Agent/UA)が初期メディアと通常メ ディアとを区別できない場合にのみ、適用可能である。他の状況(UAの大部分) では、ゲートウェイモデルではなく、セクション4で説明されるアプリケー ションサーバーモデルを使用することを強く推奨する。 3.1. フォーク フォークがなく、最初のINVITEにオファーが含まれると仮定すると、ゲート ウェイモデルではメディアの省略は発生しない。以下に示す通常のSIPの手続 きでは、UACは、INVITEで最初のオファーを送信するとすぐに、送信されるメ ディアを再生する準備が行われる。UASは信頼性のある暫定応答でアンサーを 送信すると、送信するメディアがあればすぐにメディアを送信することができ る。1xx応答前に最初のメディアパケットがUACに到達すると、UACは再生す る。 状況によっては、UACは、メディアを再生できるようになる前に、アンサー を受信する必要がある、ということに注意。このような状況(例: QoS、メ ディア認可、またはメディアの暗号化が必要とされる場合)のUAは、メディ アの省略を防ぐために前提条件を使用する。 一方で、INVITEがフォークする場合、ゲートウェイモデルではメディアの省略 が発生する可能性がある。これは、UACが、異なるUASからの複数の暫定応答 で、オファーに対して異なるアンサーを受信するときに発生する。UACは、帯 域の制限と、初期メディアの選択に対処する必要がある。 Camarillo & Schulzrinne Informational [Page 4] RFC 3960 Early Media and Ringing Tone Generation December 2004 UACが初期メディアを異なるUASから受信した場合、それをユーザーに提示する 必要がある。初期メディアが音声で構成される場合、ユーザーに対して、同時 に複数の音声ストリームを再生することは、混乱を招く。一方、他のメディア タイプ(例: ビデオ)は、ユーザーに対して同時に提示することができる。たと えば、UACは、異なる入力を寄せ集めて構成することができる。 ただし、ユーザーに対して同時に再生可能なメディアタイプの場合でも、UAC の帯域が限られている場合、異なるUAS全部から同時に初期メディアを受信す ることはできない。したがって、多くの場合、UACは1つの初期メディアセッ ションを選択し、UPDATEリクエストを送信するものを「ミュート」する必要が ある。 発呼側の観点から、どのメディアセッションがより重要な情報を伝達して いるのかを判断することは困難である。実際に、場合によっては、UAは、 メディアパケットと、そのパケット固有のSIPのearlyダイアログとを関連 付けることすらできない可能性がある。したがって、通常、UACは1つの earlyダイアログをランダムに選んで、残りをミュートする。 ミュートされた初期メディアセッションの1つが、通常のメディアセッション に遷移する場合(つまり、UASが2xx応答を送信)、メディアの省略が発生しやす い。通常、UACは、(INVITEに対する200 (OK)の受信時に)新規のオファーを指 定してUPDATEを送信し、メディアセッションのミュートを解除する。UASは、 UACからオファーを受信するまで、メディアを送信できない。したがって、UAC からのオファーを受信するまで、発呼側が話し始めると、数単語が失われる。 (UACではなく)UASがUPDATEを送信してメディアセッションのミュートを解 除した場合でも、逆方向でのメディアの省略を防ぐことはできず、競合条 件が発生する可能性がある。 3.2. 呼び出し音の生成 PSTNでは、通常、電話のスイッチによって、呼び出し音を発信側に対して再生 し、着呼側に通知されていることを示す。この呼び出し音の生成について、タ イミング、場所、方法は標準化済みである(つまり、着呼側のローカル交換で は、着呼側に通知されている間、標準化された呼び出し音が生成される)。こ の種類のフィードバックをユーザーに提供する標準化のアプローチは、PSTNな ど、同種の環境であれば意味がある。この場合、すべての端末は、同様のユー ザーインターフェースを持っているためである。 この同種性は、SIPユーザーエージェントにはない。SIPユーザーエージェント には、異なる機能があり、異なるユーザーインターフェースを持ち、音声を まったく伴わないセッションを確立するために使用される場合もある。このた め、SIP UAがユーザーに、セッション確立の進捗に関する情報を提供する方法 は、ローカルポリシーの問題である。たとえば、あるグラフィカルユーザーイ ンターフェース(Graphical User Interface/GUI)付きのUAでは、着呼側が着呼 Camarillo & Schulzrinne Informational [Page 5] RFC 3960 Early Media and Ringing Tone Generation December 2004 通知を受けている間、画面上にメッセージを表示することを選択し、他のUAで は、その代わりに、電話が鳴っている画像を表示することを選択する場合があ る。多くのSIP UAは、PSTN電話のユーザーインターフェースをまねて作成され ている。着呼側が着呼通知を受けている間、発呼側には呼び出し音が鳴る。こ のようなUACでは、UASから初期メディアを受信していなければ、ユーザーに対 してローカルで呼び出し音を生成すると想定される。UASが初期メディアを生 成する場合(例: 告知や特殊な呼び出し音)、UACはローカルで呼び出し音を生 成するにではなく、UASからのメディアを再生することになっている。 問題は、場合によって、初期メディアを受信するか、UACがローカルで呼び出 し音を生成するかを判断することが容易なタスクではない、ということであ る。UASは、信頼性のある暫定応答を使用しなくても、初期メディアを送信で きる(非常に単純なUASであれば可能)。あるいは、初期メディアを送信する意 図がなくても、信頼性のある暫定応答でアンサーを送信できる(これは前提条 件が使用される場合)。そのため、SIPシグナリングを注目するだけでは、UAC は、特定セッションの初期メディアが存在するかどうかを確認することはでき ない。UACは、メディアパケットが特定の時間に到達しているかどうかを確認 する必要がある。 実装によっては、メディアパケットのコンテンツに注目することを選択す る可能性もある。これは、静音または気休めの雑音のみを伝達できるため である。 これを留意して、UACは、ローカルの呼び出し音生成に関するローカルポリ シーを開発する必要がある。たとえば、POTS(「Plain Old Telephone Service (一般電話サービス)」)のようなSIPユーザーエージェント(UA)は、以下のロー カルポリシーを実装する可能性がある。 1. 180 (Ringing)応答を受信するまで、ローカルの呼び出し音を生成し ない。 2. 180 (Ringing)を受信したが、メディアパケットが送信されない場合、 ローカルの呼び出し音を生成する。 3. 180 (Ringing)を受信し、メディアパケットが送信される場合、それを 再生し、ローカルの呼び出し音を生成しない。 注意が必要なのは、180 (Ringing)応答とは着呼側で着呼が通知されて いることを意味し、UASがこの応答を送信すべきなのは、初期メディア セッションのステータスにかかわらず、着呼側が着呼の通知を受けてい る場合である、という点である。 一見、このようなポリシーは、分解されたUA(つまりメディアゲートウェイコ ントローラとメディアゲートウェイ)で実装するのは困難に思われるが、この ポリシーは、セクション2で説明したものと同じであり、すべてのUAが実装し なければならない。つまり、すべてのUAは、メディアの省略を防ぐために、 Camarillo & Schulzrinne Informational [Page 6] RFC 3960 Early Media and Ringing Tone Generation December 2004 200 OK応答が到達していない状態でも、送信されるメディアパケットを再生す べきである(また、それが実行された場合、ローカルの呼び出し音生成を停止 すべきである)。そのため、この初期メディアポリシーを実装するツールは、 SIPを使用するすべてのUAですでに使用可能なのである。 注意が必要なのは、すべてのSIP UAが準拠できるように、共通のローカルポリ シーを標準化することは望ましいが、特定サブセットの、おおよそ同種のSIP UAは、慣例によって同じローカルポリシーを使用することができる、という点 である。このようなサブセットのSIP UAについて例を挙げると、「PSTN/SIP ゲートウェイ」や「すべての3GPP IMS(Third Generation Partnership Project Internet Multimedia System)端末」が考えられる。ただし、このよ うなグループのSIPデバイスが使用可能な特定の共通ポリシーを定義すること は、本文書の範囲外である。 3.3. 初期メディアインジケータがない場合 SIPは、他のシグナリングプロトコルとは対照的に、初期メディアインジケー タ機能がない。つまり、SIPでは、初期メディアの有無に関する情報がない。 このようなインジケータは、UASがインバンドの呼び出し音や、何らかの種類 の告知を提示する意図があるときに、UACがローカルで呼び出し音を生成する ことを防ぐために使用される場合がある。ただし、多くの場合、このようなイ ンジケータはSIPの機能方法のためにはほとんど使用されない。 考えられる初期メディアインジケータの利点を損ねる重要な理由の1つは、SIP シグナリングとメディアパス間のゆるい連結である。SIPシグナリングは、メ ディアとは異なるパスで伝達される。メディアパスは、通常、エンドツーエン ドの遅延を減らすよう最適化されるが(例: 最小数の仲介)、SIPシグナリング パスは、通常、セッション用にさまざまなサービスを提供する多数のプロキシ を経由して伝達される。この理由から、初期メディアを含むメディアパケット が、初期メディアインジケータを含むSIPメッセージの前に、UACに到達する可 能性は非常に高い。 それでも、SIP応答が、メディアパケットよりも早くUACに到達する場合があ る。UASが初期メディアを送信する意図があるのに、直ちにそれを実行するこ とができない場合がある。たとえば、ICE(Interactive Connectivity Establishment)(参考文献[6])を使用するUAは、メディアを交換できるように なる前に、いくつかのSTUN(Simple Traversals of the UDP Protocol through NAT)メッセージを交換する必要がある場合がある。この場合、初期メディアイ ンジケータでは、この期間に、UACがローカルで呼び出し音を生成しないよう にする。だが、このとき、初期メディアがUACに到達していないが、ユーザー は、180 (Ringing)を受信済みでも、リモートユーザーが着信を通知されてい るということを認知できない。そのため、よりよい解決方法は、初期メディア パケットをUASからUACへ送信できるまで、ローカルで呼び出し音を適用するこ とである。この解決方法では、初期メディアインジケータを必要としない。 Camarillo & Schulzrinne Informational [Page 7] RFC 3960 Early Media and Ringing Tone Generation December 2004 注意が必要なのは、UACにおけるローカルの呼び出し音から初期メディアへ の移行は、フォークがある場合でも同様に発生するということである。1つ のUASが180 (Ringing)を送信し、後に、別のUASが初期メディアを送信し始 めることがある。 3.4. ゲートウェイモデルの適用性 セクション3では、ゲートウェイモデルの制限についていくつか説明した。 フォークするシナリオではメディアの省略が発生し、ローカルで呼び出し音を 適切に生成するには、メディアの検出が必要となる。これらの問題は、セク ション4で説明するアプリケーションサーバーモデルで対処されている。この モデルは、セッション中に生成される通常のメディアとは分離した初期メディ アを生成する方法として、推奨される。 そのため、ゲートウェイモデルは、UAが初期メディアと通常のメディアを区別 できない場合に適用可能である。PSTNゲートウェイは、適用できる場合の一例 である。PSTNゲートウェイは、回路上でPSTNからメディアを受信し、IPネット ワークに送信する。ゲートウェイは、メディアの内容に関知しておらず、初期 メディアから通常のメディアへの遷移が実行されるタイミングを正確にわかっ ていない。PSTNの観点からは、回路は、連続的なソースのメディアなのであ る。 4. アプリケーションサーバーモデル アプリケーションサーバーモデルは、UACとの初期メディアセッションを確立 するために、UASをアプリケーションサーバーとして動作させることで構成さ れる。UACは、初期メディアセッションのオプションタグを使用して、初期メ ディアセッションのディスポジションタイプ(参考文献[2]で定義)への対応を 示す。このように、UASは、初期メディア用(初期メディアセッションのディス ポジションタイプ)と通常のメディア用(セッションディスポジションタイプ) のオファー/アンサー交換を区別できることがわかる。 初期メディアで、通常のメディア送信に使用されるオファー/アンサー交換と は異なるオファー/アンサー交換を使用することによって、フォークの場合で も、メディアの省略を防ぐ支援となる。UACは、最初のINVITEを受け入れたと きにメディアを伝達するセッションをミュートすることなく、初期メディアの 新規オファーを拒否またはミュートすることができる。UACは、より新しい セッション上で受信されるメディアを優先させることができる。この方法で、 アプリケーションサーバーモデルは、適切なタイミングで、初期メディアから 通常のメディアに遷移する。 また、初期メディアのオファー/アンサー交換を別にすることで、UACはローカ ルの呼び出し音を生成すべきかどうかを判断することができる。新規の初期 セッションが確立され、初期セッションに少なくとも1つの音声ストリームが 含まれる場合、UACは、送信される初期メディアが存在することを推定するこ とができ、それによって、ローカルの呼び出し音生成を防ぐことができる。 Camarillo & Schulzrinne Informational [Page 8] RFC 3960 Early Media and Ringing Tone Generation December 2004 代替モデルでは、新規の初期セッションを確立するのではなく、UPDATEを 使用して、UACとUAS間の元々のセッションに「early media」とラベルを付 けた新しいストリームが追加される。本書では、新規の初期セッションを 確立する方法を選択した。これは、UASと同居して*いない*アプリケーショ ンサーバーが使用する仕組みと、整合を取るためである。以上のように、 UASは、UACと交信するために、ネットワーク内でアプリケーションサー バーと同じ仕組みを使用する。 4.1. インバンド対アウトバンドのセッション進捗情報 注意が必要なのは、アプリケーションサーバーモデルを使用する場合でも、UA は、どの初期メディアセッションがミュート状態か、および、どの初期メディ アセッションをユーザーに提示するかについて、選択しなければならない、と いうことである。UAが容易にこの選択を行えるように、セッションにとって重 要ではない情報は、初期メディアを使用して伝送しないことを強く推奨する。 たとえば、UAは、特殊な呼び出し音を送信するために初期メディアを使用すべ きではない。既存のSIPのステータスコードと理由フレーズを使用すれば、初 期メディアに関連する問題を発生させることなく、リモートユーザーにセッ ション確立の進捗を通知することができる。 5. Alert-Infoヘッダーフィールド Alert-Infoヘッダーフィールドを使用すると、代替の呼び出しコンテンツ(呼 び出し音など)をUACに対して指定することができる。このヘッダーフィールド は、UACに対して、ローカルの呼び出し音が生成されるときに再生すべき音声 を指示するが、ローカルの呼び出し音を生成すべきタイミングは指示しない。 UACは、上記の両モデルにおける呼び出し音生成に関する規則に従うべきであ る。規則に従った上で、UACがローカルで呼び出し音を再生することを判断し た場合は、Alert-Infoヘッダーフィールドを使用して、再生することができ る。 6. セキュリティの考慮 ゲートウェイモデルでも、アプリケーションサーバーモデルでも、SIPは、オ ファー/アンサーモデル(参考文献[3])を使用して初期メディアを確立する。 ユーザーエージェント(UA)は、セッション記述を生成するが、この中に、SIP メッセージでメディアを受信し、相手に送信する場所を示す、伝送アドレス (つまりIPアドレスとポート)が含まれる。メディアパケットがこの伝送アドレ スに到達すると、UAは、セッション記述を伝達するSIPメッセージの受信者か ら、そのパケットが来たと推定する。いずれにせよ、攻撃者は、SIPメッセー ジのコンテンツに対するアクセス権を取得し、セッション記述に福丸伝送アド レスに対してパケットを送信しようとする可能性がある。このような状況を防 ぐためには、UAはセッション記述を暗号化(例: S/MIMEの使用)すべきである [SHOULD]。 Camarillo & Schulzrinne Informational [Page 9] RFC 3960 Early Media and Ringing Tone Generation December 2004 UAがセッション記述を暗号化してもなお、攻撃者は、UAが使用する伝送アドレ スを推測して、メディアパケットをそのアドレスに送信しようとする可能性が ある。このように伝送アドレスを推測することは、予想よりも簡単な場合があ る。これは、多くのUAは、常に、同じ最初のメディアポートを取得するためで ある。このような状況を防ぐために、UAは、SRTP(Secure Realtime Transport Protocol/参考文献[7])など、メディアレベルの認証メカニズムを使用すべき である[SHOULD]。また、通信の機密性保持を望むUAは、メディアレベルの暗 号メカニズム(例: SRTP/参考文献[7])を使用すべきである[SHOULD]。 攻撃者は、DoS攻撃の一部として、UAで被害者にメディアを送信させる可能性 がある。これは、被害者の伝送アドレスが含まれるセッション記述をUAに送信 することで実行できる。この攻撃を防ぐには、UAは、大量のデータを伝送アド レスに送信する前に、(メディアを受信する意思を確認するためだけに)セッ ション記述で受信した伝送アドレスの所有者とハンドシェイクを交わすべきで ある[SHOULD]。この確認は、接続指向の伝送プロトコルを使用することで、実 行できる。たとえば、エンドツーエンド形式でSTUN(参考文献[3])を使用する か、SRTP(参考文献[7])でキー交換を行う。 いずれの場合でも、注意が必要なのは、以上のセキュリティ考慮は、初期メ ディア固有のものではなく、一般的に、セッションを確立するSIPにおけるオ ファー/アンサーモデルを使用する場合に適用されるものである。 さらに、初期メディア固有の危険性(おおまかに言うと、PSTNにおける「通話 料詐欺」の形式と同様)は、一部のオペレータが初期メディアと通常のメディ アに別個に適用している料金徴収ポリシーを、悪用しようとすることである。 UAが、初期メディアは無料で交換できるが、通常のメディアセッションは有料 の場合、悪意のあるUAは、双方向の初期メディアセッションを確立し、INVITE に対して200 (OK)応答を返さないようにする可能性がある。 一方で、一部のアプリケーションサーバー(例: 音声自動応答システム)は、発 呼側から情報を取得するために双方向の初期メディアを使用する(例: 通話 カードのPINコード)。そのため、オペレータが双方向の初期メディアを不許可 にすることは、推奨されない。その代わりに、オペレータは、長すぎる初期メ ディア交換を有料にするか、メディアレベルで初期メディアを停止する改善策 を検討すべきである(オペレータのポリシーによる)。 7. 謝辞 Jon Peterson氏から、ゲートウェイモデルとアプリケーションサーバーモデル の分離について有益なアイデアをいただいた。 Paul Kyzivat、Christer Holmberg、Bill Marshall、Francois Audet、John Hearty、Adam Roach、Eric Burger、Rohan Mahy、Allison Mankinの各氏から 有益なコメントを提案をいただいた。 Camarillo & Schulzrinne Informational [Page 10] RFC 3960 Early Media and Ringing Tone Generation December 2004 8. 参考文献 8.1. 規範となる参考文献 [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] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 8.2. 有益な参考文献 [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [6] Rosenberg, J., "Interactive connectivity establishment (ICE): a methodology for network address translator (NAT) traversal for the session initiation protocol (SIP)", Work in progress, July 2003. [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [8] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Camarillo & Schulzrinne Informational [Page 11] RFC 3960 Early Media and Ringing Tone Generation December 2004 著者の連絡先 Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Camarillo & Schulzrinne Informational [Page 12] RFC 3960 Early Media and Ringing Tone Generation December 2004 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に 記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インタ ーネット協会およびIETFは、この情報がいかなる権利も侵害していないという 保証、商用利用および特定目的への適合性への保証を含め、また、これらだけ に限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記 載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Camarillo & Schulzrinne Informational [Page 13]