Network Working Group J. Rosenberg Request for Comments: 3264 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. June 2002 セッション記述プロトコル(SDP)によるオファー/アンサーモデル An Offer/Answer Model with the Session Description Protocol (SDP) 本文書の位置付け 本文書は、インターネットコミュニティに対してインターネットスタンダー ドトラックプロトコルを規定し、改善のための議論と提案を要求するもので ある。標準化状態およびこのプロトコルのステータスについては、現在の 「Internet Official Protocol Standard」(STD 1)を参照のこと。本文書の 配布に制限はない。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 本文書は、2つのエンティティ間でマルチメディアセッションの共通のビュー に到達するために、セッション記述プロトコル(SDP)を使用できるようにする 仕組みを定義する。このモデルで、一方の参加者は彼らの観点から望まれる セッションの記述を他方にオファーし、そしてもう一方の参加者は彼らの観点 から望まれるセッションでアンサーする。このオファー/アンサーモデルは、 セッションの完全なビューを得るために両方の参加者からの情報が必要とされ るユニキャストのセッションで最も有用である。オファー/アンサーモデルは セッション開始プロトコル(SIP)のようなプロトコルで利用される。 目次 1 はじめに ............................................ 2 2 述語規則 ............................................ 3 3 定義 ................................................ 3 4 プロトコル操作 ...................................... 4 5 最初のオファーの生成 ................................ 5 5.1 ユニキャストストリーム .............................. 5 5.2 マルチキャストストリーム ............................ 8 6 アンサーの生成 ...................................... 9 6.1 ユニキャストストリーム .............................. 9 6.2 マルチキャストストリーム ............................ 12 7 オファー側のアンサー処理 ............................ 12 8 セッションの変更 .................................... 13 Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 8.1 メディアストリームの追加 ............................ 13 8.2 メディアストリームの削除 ............................ 14 8.3 メディアストリームの変更 ............................ 14 8.3.1 アドレス、ポート、またはトランスポートの変更 ........ 14 8.3.2 メディアフォーマットの集合の変更 .................... 15 8.3.3 メディアタイプの変更 ................................ 17 8.3.4 属性の変更 .......................................... 17 8.4 ユニキャストメディアストリームの保留 ................ 17 9 能力の指示 .......................................... 18 10 オファー/アンサー交換の例 ........................... 19 10.1 基本交換 ............................................ 19 10.2 N個のコーデックから1つを選択する .................... 21 11 セキュリティの考慮 .................................. 23 12 IANA条項 ............................................ 23 13 謝辞 ................................................ 23 14 規範となる参考文献 .................................. 23 15 有益な参考文献 ...................................... 24 16 著者の連絡先 ........................................ 24 17 完全な著作権表記 .................................... 25 1 はじめに セッション記述プロトコル(SDP)(参考文献[1])は、元来はMbone上でやり取り されるマルチキャストセッションを記述する方法として考えられた。セッシ ョンアナウンスプロトコル(SAP)(参考文献[6])は、SDPメッセージを運ぶため のマルチキャストの仕組みとして考案された。SDPの仕様はユニキャスト操作 を可能としているが、完全ではない。全参加者が使用するセッションのグロ ーバルなビューがあるマルチキャストとは違って、ユニキャストセッション には2人の参加者が関与し、セッションの完全なビューには両方の参加者と彼 らの間でのパラメータの合意が必要とされる。 例として、マルチキャストセッションは特定のメディアストリームのために 単一のマルチキャストアドレスを伝えることを必要とする。しかしユニキャ ストセッションのためには、それぞれの参加者に1つ、つまり2つのアドレス を必要とする。別な例として、マルチキャストセッションはそのセッション でどのコーデックが使われるかを指示する必要がある。しかしユニキャスト のためには、それぞれの参加者のサポートしているコーデックの集合の一致 部分を見つけることにより、そのセッションで使用するコーデックの集合を 確定する必要がある。 結果として、SDPはユニキャストセッションを記述できる表現力を持っている が、実際にどのようになされるかといったセマンティクスや操作上の詳細が 欠けている。本文書では、SDPを基礎とした簡単なオファー/アンサーモデル を定義し、それらの問題を改善する。このモデルではセッションの一方の参 加者はオファー(オファー側がメディアを受信するために使いたいIPアドレス およびポートと一緒に、オファー側が使うことを望むメディアストリームと コーデックの集合)を構成するSDPを生成する。オファーはもう一方の参加者 Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 (アンサー側)に伝えられる。アンサー側はアンサー(オファー側が提示したオ ファーに対するSDPメッセージ)を生成する。アンサーは、使用されるコーデ ック、およびアンサー側がメディアを受信するために使用を望むIPアドレス とポートとともに、オファー中の各ストリームを受け入れるかどうかを示す それぞれのストリームに一致するメディアストリームを持つ。 マルチキャストセッションがユニキャストセッションと同じように機能する ことも可能である。それのパラメータはユニキャストの場合のようにユーザ ーのペア間でネゴシエートされるが、両方の側は同一の(ユニキャストアドレ スではなく)マルチキャストアドレスにパケットを送る。本文書では、マルチ キャストストリームに対するオファー/アンサーモデルのアプリケーションに ついても議論する。 最初のオファー/アンサー交換のあとにセッションを更新するために、オファ ー/アンサーモデルをどのように使用するかについてのガイドラインも定義す る。 オファーとアンサーを伝える方法は本文書の適用範囲外である。ここで定義 されるオファー/アンサーモデルは、セッション開始プロトコル(SIP)(参考文 献[7])で使われる必修の基本的な仕組みである。 2 述語規則 本文書では、次のキーワードはRFC2119(参考文献[2])に記述されているとお りに解釈すること。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 また、上記の語は準拠した実装をするための要求レベルを示す。 3 定義 以下の用語がこのドキュメントの中で使われる: エージェント: エージェントとはオファー/アンサーの交換に関与するプ ロトコルの実装である。オファー/アンサーの交換には2つのエージェ ントが関与する。 アンサー: オファー側から受信したオファーに対する応答中で、アンサー 側が送信するSDPメッセージ。 アンサー側: 別のエージェントからそれが希望するメディアコミュニケー ションのアスペクトを記述するセッション記述を受信し、次いで、自 身のセッション記述でそれに応答するエージェント。 Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 メディアストリーム: RTSP(参考文献[8])によると、メディアストリーム とは、例えば、単一のホワイトボードや共有アプリケーショングルー プのみならずオーディオストリームやビデオストリームといった、単 一のメディアインスタンスである。SDPにおいて、メディアストリーム は「m=」行とそれに関連付けられた属性によって記述される。 オファー: オファー側が送信するSDPメッセージ。 オファー側: セッションを作成あるいは変更するためにセッション記述を 生成するエージェント。 4 プロトコル操作 オファー/アンサーの交換には、エージェント間のセッションの確立を目的と してSDPの交換を行う能力を持つ、(例えばSIPのような)上位層プロトコルが存 在することが前提となる。 プロトコル操作はあるエージェントが他のエージェントに最初のオファーを送 るときに始まる。オファーが、上位層プロトコルを通じて既に確立されている かもしれないどのコンテキストに対しても外部にある場合、そのオファーは最 初のオファーである。上位層プロトコルは、いろいろなSDPの交換を一緒に関 連付けることを可能にするある種のコンテキストの管理を提供すると仮定され る。 オファーを受信するエージェントはアンサーを生成してもよい[MAY]、または オファーを拒否してもよい[MAY]。オファーを拒否するための手段は、上位層 プロトコルに依存する。オファー/アンサーの交換は分割できない。つまり、 もしアンサーが拒否されると、セッションはオファー前の状態に戻る(セッシ ョンがないことになるかもしれない)。 いつでもどちらのエージェントもセッションをアップデートする新しいオファ ーを生成してよい[MAY]。しかし、アンサーか拒否をまだ行っていないオファ ーを受信している場合は、新しいオファーを生成してはならない[MUST NOT]。 さらに、前の提案へのアンサーか拒否をまだ受け取っていない場合、新しい提 案を生成してはならない[MUST NOT]。エージェントがオファーを送信した後に それに対するアンサーの受信前にオファーを受信する場合、これは「グレア (glare)」な状態であるとみなされる。 グレアという用語はもともと回線交換ネットワークにおいて、2つの交換機 が同じトランク上で有効な同じ回線を同時に押さえようと試みる状態を説 明するために使用された。ここでは、両方のエージェントがアップデート されたオファーの送信を同時に試みたことを意味する。 Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 上位層プロトコルはそのような状態を解決する手段を提供する必要がある。 上位層プロトコルは各方向でメッセージの順序付けを行う手段を提供する必要 があるだろう。SIPはこれらの要件に合う(参考文献[7])。 5 最初のオファーの生成 オファー(およびアンサー)は1つの例外を除きRFC2327(参考文献[1])に定義さ れているような正当なSDPメッセージでなければならない[MUST]。RFC2327は SDPメッセージにe行とp行のどちらかがあることを必須とする。この仕様はそ の制約を緩め、オファー/アンサーアプリケーションのために形成されたSDP は、e行とp行の両方を省略してもよい[MAY]とする。o行のセッションIDと バージョンの数値は符号付き64ビット整数で表せなければならない[MUST]。 バージョンの初期値は循環を避けるために(2**62)-1未満でなければならない [MUST]。SDPの仕様は大きなSDPメッセージの中に連結された複数のセッション 記述を認めているが、オファー/アンサーモデルで使用されるSDPメッセージは 厳密に1つのセッション記述しか含んではならない[MUST]。 SDPの「s=」行はセッションのサブジェクトを伝達する。これは、マルチキャ ストに都合が良いように定義されたものだが、ユニキャストにとっては不適切 な定義である。ユニキャストセッションに対しては、1個の空白文字(0x20)ま たはダッシュ(-)で構成することが推奨される[RECOMMENDED]。 残念ながら、SDPでは「s=」行を空にすることはできない。 SDPの「t=」行はセッション時間を伝達する。一般に、ユニキャストセッション のためのストリームは、SIPのような外部のシグナリング手段を通して、生成 ・破棄される。この場合、「t=」行は「0 0」の値を持つべきである[SHOULD]。 オファーは0以上のメディアストリームを含む(各メディアストリームは「m=」 行とその関連属性で記載される)。0のメディアストリームは、オファー側は 通信したいと望んでいるが、セッションのためのストリームは修正された オファーによって後に追加される、ということを示す。ストリームは ユニキャストとマルチキャストの混合のためのものであってもよい[MAY]。 また、後者は該当する「c=」行で明確ににマルチキャストアドレスを示す。 オファーされた各ストリームの構築は、ストリームがマルチキャストかユニキ ャストかに依存する。 5.1 ユニキャストストリーム オファー側がストリーム上のメディアをピアに送信したいだけの場合、ストリー ムを「a=sendonly」属性を持つsendonlyとマークしなければならない[MUST]。 ディレクション属性がメディアストリーム属性またはセッション属性のどちら かであると提示された場合、ここでは、ストリームが特定の方向にマークされ Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 ている、と言う。オファー側がピアからメディアを受信したいだけの場合、ス トリームをrecvonlyとマークしなければならない[MUST]。オファー側が通信し たいが今はメディアの送受信はしたくない場合、ストリームを「a=inactive」 属性を付けてマークしなければならない[MUST]。inactiveのディレクション属 性は、RFC3108[3]で規定されている。リアルタイムトランスポートプロトコル (RTP)[4]の場合、RTCPはそれでも、sendonly、recvonly、inactiveのストリー ムに対して、送受信されるということに注意。というのも、メディアストリー ムの方向性はRTCPの用法に何も影響を与えないためである。オファー側がピア に対してメディアを送受信したい場合、「a=sendrecv」属性を含んでもよいし [MAY]、または省略してもよい[MAY]。なぜなら、sendrecvはデフォルト値だか らである。 recvonlyとsendrecvのストリームに対して、オファー内のポートとアドレス はオファー側がメディアストリームをどこで受信したいかを示す。sendonly RTPストリームには、アドレスとポート番号はオファー側がRTCPレポートをど こで受信したいかを間接的にします。明示的な指示が他になければ、レポート は指定された番号より1つ大きいポート番号へ送信される。オファーで提示さ れるIPアドレスとポート番号は、オファー側から送信されるRTPとRTCPパケッ トのソースIPアドレスとソースポートについて示すものではない。オファー のポート番号0は、ストリームはオファーされたが、使用してはならない[MUST NOT]ということを示す。これは最初のオファーにおける有益なセマンティクス はないが、拒否されたストリームであると示す0ポートを、アンサーが含めら れるので、完全性の理由から考慮に入れられる(セクション6)。さらに、 既存のストリームはポートを0に設定することで停止することができる(セク ション8)。一般に、ポート番号0はメディアストリームが望まれていないとい うことを示す。 各メディアストリームのためのメディアフォーマットのリストは、2つの情報 を伝達する。具体的には、オファー側が送信かつ/または受信する(ディレク ション属性に依存する)ことができるフォーマット(RTPの場合はコーデックと コーデックに関するパラメータ)のセットと、RTPの場合、それらのフォーマッ トを識別するために使用するRTPペイロードタイプ番号である。複数のフォー マットが列挙される場合、オファー側はセッション中にそれらのフォーマット のどれでも利用できるということを意味する。言い換えると、アンサー側は、 新規のオファーをせずに、列挙されているフォーマットどれかを使用して、 セッション 中にフォーマットを変更してもよい[MAY]。2番目のストリームに は、オファー側がこのストリームに対して送信する意思のあるフォーマットを、 オファーは示すべきである[SHOULD]。recvonlyストリームには、オファー側が このストリームに対して受信する意思のあるフォーマットを、オファーが示 すべきである[SHOULD]。sendrecvストリームには、オファー側が送受信に使う 意思のあるコーデックをオファーが示すべきである[SHOULD]。 recvonlyのRTPストリームでは、ペイロードタイプ番号は、オファー側が そのコーデックに対して受信を期待しているRTPパケット内のペイロードタイプ フィールドの値を示す。sendonlyのRTPストリームでは、ペイロード番号 は、オファー側がそのコーデックに対して送信しようとしているRTPパケット Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 内のペイロードタイプフィールドの値を示す。sendrecvのRTPストリームでは、 ペイロードタイプ番号は、オファー側が受信を期待し、送信しようとしている ペイロードタイプフィールドの値を示す。だが、sendonlyとsendrecvスト リームでは、アンサーは、同じコーデックに対して異なるペイロードタイプ番 号を示すかもしれない。また、このような場合、オファー側はそのアンサーに あるペイロードタイプ番号とともに送信しなければならない[MUST]。 H.323に関わる相互運用性のために、異なるペイロードタイプ番号が各ディ レクトリで必要になるかもしれない。 RFC2327にあるように、新規のメディアフォーマットのパラメータを提供する ためにfmtpパラメータが提示されてもよい[MAY]。 RTPストリームの場合、すべてのメディア記述はRTPペイロードタイプからエン コーディングをマッピングする「a=rtpmap」を含むべきである[SHOULD]。 「a=rtpmap」がない場合、デフォルトのペイロードタイプのマッピングが、 現在使用されているプロファイルで定義されるように(例えばRFC1890[5])、 が使用されるべきである。 これによって、静的なペイロードタイプからの移行がより容易になる。 すべての場合において、「m=」行内の書式は、優先して列挙された最初のフォ ーマットを持つプリファレンス順に列挙されなければならない[MUST]。この場 合、優先して、とは、オファーの受信者が受信できる最高のプリファレンスを 持つ書式を使用すべきである[SHOULD]ということを意味する。 ptime属性がストリームに提示される場合、オファー側が受信したい、望まし いパケット化間隔(packetization interval)を示す。ptime属性は0より大きく なければならない[MUST]。 bandwidth属性はがストリームに提示される場合、オファー側が受信したい、 望ましい帯域を示す。値0は許容されるが、阻止される。それは、すべての メディアが送信されるべきではないということを示す。また、RTPの場合、 すべてのRTCPを使用不可にもする。 異なるタイプの複数のメディアストリームが1つのオファーで提示される場合、 オファー側がこれらのストリームを同時に使用する意思があるということを 意味する。典型的なケースは、ビデオ会議の一部である音声とビデオストリー ムである。 同じタイプの複数のメディアストリームが1つのオファーで提示された場合、 オファー側が同時にそのタイプの複数ストリームを送信(かつ/または受信)す る意思があるということを示す。同タイプの複数のストリームを送信する場 合、それは、そのタイプ(例えばビデオカメラやビデオの場合のVCR)の各メディ アソースが、どのように各ストリームにマップされるかに関しては、ローカル ポリシーの問題である。ユーザーが特定のメディアタイプに対して1個のソー スを持っている場合、ただ1つのポリシーのみに意味がある。それは、ソースは 同じタイプの各ストリームに送信されるということである。各ストリームは異 なるエンコーディングを使用してもよい[MAY]。同じタイプの複数のストリーム Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 を受信する場合、各ストリームが特定のタイプに対して色々なメディアシンク にマップされるかについては、ローカルポリシーの問題である(例えば、音声 の場合、スピーカーまたは録音デバイス)。しかし、ポリシーには制限がある。 まず、同じタイプの複数ストリームを受信する場合、各ストリームは、ユー ザーへの提示の用途で、少なくとも1つのシンクにマップされなければなら ない[MUST]。言い換えると、同じタイプの複数ストリームを受信する目的は、 1個を選択するのではなく、それらはすべてパラレルに提示されるべきである ということである。もうひとつの制限は、複数ストリームが受信され、同じ シンクへ送信した場合、それらは、あるメディア独自の方法で合成されなけれ ばならないことである[MUST]。例えば、2つの音声ストリームの場合、それぞれ からの受信メディアは、スピーカーにマップされるかもしれない。その場合、 合成操作はそれらをミックスすることだろう。シンクがスクリーンのような、 複数のインスタントメッセージングストリームの場合、合成操作は、ユーザー インターフェイスにそれらのすべてを提示することだろう。3番目の制限は、 複数のソースが同じストリームにマップされる場合、それらのソースは、 ストリームに送信される前に、あるメディア独自の方法で合成されなければ ならないということである[MUST]。これらの制限を超越するポリシーは柔軟で はあるが、カンファレンスサーバーでない場合、メディアをそのシンクから ソースへ複製するようなポリシーは、一般的にエージェントは望まないだろ う(例 受信メディアを1つのストリームから別のストリームに複製しない)。 同タイプの複数メディアストリームの典型的な用法の例は、プリペイドコーリ ングカードアプリケーションである。それは、ユーザーが同じカードで、通話 中のいつでも切断して新たに発呼するために、シャープ記号(「#」)を押して 保留にすることがである。ここでは、ユーザーから2つの方向(リモートゲート ウェイとシャープ記号を検出するDTMF処理アプリケーション)へのメディアが 必要である。これは2つのメディアストリームで実現されうる。1つはゲートウ ェイへのsendrecvであり、もう一方はDTMFアプリケーションへのsendonly(ユ ーザーの立場からの)である。 オファー側がオファーを送信するとすぐに、オファー側はオファーに書かれて いるすべてのrecvonlyストリームに対してメディアを受信する準備をしなけれ ばならない[MUST]。それ(訳注: オファー側)は、オファーにあるすべての sendrecvストリームに対して、メディアを送信・受信する準備をし、オファー にあるすべてのsendonleストリームに対してメディアをの送信しなければな らない[MUST](もちろん、ピアが必要なアドレスとポート情報にアンサーを提 供するまで、実際は送信できない。)。RTPの場合、たとえアンサーが届く前に メディアを受信しても良いとしても、アンサーが届くまでRTCP受信側にレポー トを送信することはできない。 5.2 マルチキャストストリーム セッション記述が受信(送信)のみと列挙されているマルチキャストメディアス トリームを含む場合、それはオファー側、アンサー側を含む参加者が、そのス トリームに関しては受信(送信)しかできないということを意味する。これは方 向性がオファー側とアンサー側間のメディアの流れを参照するユニキャストの 観点とは異なる。 Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 その説明の域は超えるが、オファーされたマルチキャストストリームのセマン ティクスは、まったくRFC2327[1]で書かれている通りである。 6 アンサーの生成 オファーされたセッション記述へのアンサーはオファーされたセッション記述 に基づく。アンサーがどこか(異なるIPアドレス、ポート等)オファーとは異な る場合、アンサーは異なるエンティティによって生成されるので、origin (o=)行はアンサーとは異ならなければならない[MUST]。この場合、アンサーの 「o=」行にあるバージョン番号は、オファーのo行にあるバージョン番号とは無 関係である。 オファーにある各「m=」行には、アンサー内の関連する「m=」行がなければな らない[MUST]。アンサーはオファーの「m=」行とまったく同じ数を含まなけ ればならない[MUST]。これによって、ストリームをその順序ベースでマッチす ることができる。このことは、オファーが0の「m=」行を含む場合、アンサーは 0の「m=」行を含まなければならないということを意味する[MUST]。 アンサーの「t=」行はオファーのそれと同じでなければならない[MUST]。セッ ションの時間をネゴシエートすることはできない。 オファーされたストリームは、どのような理由でもアンサーが拒否しても よい[MAY]。ストリームが拒否された場合、オファー側とアンサー側はその ストリームに対してメディア(またはRTCPパケット)を生成してはならない [MUST NOT]。オファーされたストリームを拒否するために、アンサーにある 関連するストリーム内のポート番号は0に設定されなければならない[MUST]。 列挙されるすべてのメディアフォーマットは無視される。SDPで規定されてい るように、少なくとも1つは提示されなければならない[MUST]。 オファーされた各ストリームに対してアンサーを構築することは、ユニキャス トとマルチキャストとで異なる。 6.1 ユニキャストストリーム ストリームがユニキャストアドレスとともにオファーされた場合、そのスト リームに対するアンサーはユニキャストアドレスを含まなければならない [MUST]。アンサー内のストリームのメディアタイプはオファーのそれとマッチ しなければならない[MUST]。 ストリームがsendonlyとしてオファーされる場合、関連するストリームは アンサー内でrecvonlyまたはinactiveとしてマークされなければならない [MUST]。メディアストリームがオファーでrecvonlyとして列挙される場合、 アンサーはアンサー内でsendonlyまたはinactiveとしてマークされなければな らない[MUST]。オファーされたメディアストリームがsendrecvとして列挙され る場合(または、ストリームがデフォルトでsendrecvであるようなケースの、 メディアやセッションレベルでディレクション属性がない場合)、アンサー内 の関連するストリームは、sendonlyまたはrecvonly、sendrecv、inactiveと マークされてもよい[MAY]。オファーされたメディアストリームがinactiveと して列挙される場合、アンサー内でinactiveとマークされなければならない [MUST]。 Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 アンサーでrecvonlyとマークされたストリームでは、「m=」行は、アン サー側がオファーの中で列挙された中で、受信する意思のあるメディアフォー マットを少なくとも1つ含まなければならない[MUST]。オファー内で関連する ストリームに列挙されず、アンサー側が受信する意思があるような、新規の メディアフォーマットを、ストリームは示してもよい[MAY]。アンサーで sendonlyとマークされたストリームでは、「m=」行は、アンサー側がオファー で列挙されている中で、送信する意思のあるメディアフォーマットを少なくと も1つ含まなければならない[MUST]。アンサーでsendrecvとマークされたスト リームでは、「m=」行はオファーで列挙されている中から送受信の両方をする 意思のあるコーデックを少なくとも1つを含まなければならない[MUST]。 オファーの関連するストリームに列挙されず、アンサー側が送信または受信を する意思のあるような、新規のメディアフォーマットをストリームは示しても よい[MAY](もちろん、オファーに列挙されていないので、それらをこのときに 送信することはできない)。アンサーでinactiveとマークされているストリー ムでは、メディアフォーマットのリストはオファーに基づいて構築される。 オファーがsendonlyの場合、リストはアンサーがrecvonlyであるかのように構 築される。同様に、オファーがrecvonlyの場合、リストはアンサーがsendonly のように構築され、また、オファーがsendrecvの場合、リストはアンサーが sendrecvのように構築される。オファーがinactiveの場合、リストはオファー が実際はsendrecvであり、かつアンサーがsendrecvのように構築される。 アンサー内のコネクションアドレスとポートは、アンサー側がメディアを受信 する意思のあるアドレスを示す(RTPの場合、RTCPは、明示的な指示が他にない 場合、1つ上のポート番号で受信される)。このアドレスとポートはsendonly ストリームに対してであっても提示されなければならない[MUST]。というのも RTPの場合、1つ上のポート番号がRTCPを受信するために使われるためである。 RTPの場合、特定のコーデックがオファーで特定のペイロードタイプ番号とと もに参照される場合、同じペイロードタイプ番号がアンサーのコーデックに使 用されるべきである[SHOULD]。たとえ同じペイロードタイプ番号が使用される としても、動的ペイロードタイプのためにペイロードタイプのマッピングを定 義する目的で、アンサーはrtpmap属性を含まなければならず[MUST]、さらに 静的ペイロードタイプのためにマッピングを含むべきである[SHOULD]。「m=」 行内のメディアフォーマットは、優先して列挙された最初のフォーマットを持 つプリファレンス順に列挙されなければならない[MUST]。この場合、優先して、 とは、オファーの受信側が受信できる最高のプリファレンスを持つ書式を使用 すべきである[SHOULD]ということを意味する。 アンサー側は自分の望ましいプリファレンス順でフォーマットを列挙してもよ い[MAY]が、特に理由がなければ、アンサー側はオファーで提示された同じ順 でフォーマットを列挙することが推奨される[RECOMMENDED]。言い換えると、 オファーのストリームが音声コーデックを8、22、48という順で列挙し、アン サー側がコーデック8と48のみに対応する場合、アンサー側に特に変更する理 Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 由がなければ、アンサーのコーデックは、48、8ではなく、8、48になるという ことが推奨される[RECOMMENDED]。このことは、両方向で同じコーデックが使 用されていると推定する助けになる。 オファー内のfmtpパラメータの解釈は、パラメータに依存する。多くの場合、 これらのパラメータはメディアフォーマットの独自設定を記述しているので、 メディアフォーマット値と同様に、処理されるべきである。記載するメディア フォーマットがアンサーで提示される場合は、同じ値を持つ同じfmtpパラメー タが、アンサーに提示されなければならない[MUST]、ということを意味する。 別のfmtpパラメータが、異なる値を使用する各エージェントに完全に適用可能 なパラメータに近い。その場合、アンサーはfmtpパラメータを含んでもよく [MAY]、また、それら(訳注:fmtpパラメータ)はオファーのそれと同じ値を持っ てもよいし[MAY]、異なってもよい[MAY]。新規のパラメータを定義するSDPの 拡張は、オファー/アンサーにおける適切な解釈を指定すべきである[SHOULD]。 アンサー側は、どのメディアストリームに対して0ではないptime属性を含ん でもよい[MAY]。これは、アンサー側が受信したいパケット化の間隔を示す。 パケット化の間隔は特定のストリームのための各方向性と同じである必要はな い。 アンサー側はbandwidth属性をすべてのメディアストリームに対して含めても よい[MAY]。つまり、これはアンサー側がオファー側にメディア送信時に使用 してほしい帯域を示す。値0は許容されるが、セクション5で記載されるよう に、解釈される。 あるオファーされたストリームに対して、アンサー側が共通のメディアフォー マットを持たない場合、アンサー側はポートを0に設定することで、そのメディ アストリームを拒否しなければならない[MUST]。 すべてのストリームで共通のメディアフォーマットがない場合、オファーされ たセッション全体が拒否される。 アンサー側はアンサーを送信するとすぐに、そのアンサーにで記載されるすべ てのrecvonlyストリームに対してメディアを受信する準備をしなければならな い[MUST]。アンサー側は、アンサーにあるすべてのsendrecvストリームに対し てメディアを送信・受信する準備をしなければならず[MUST]、ただちにメディ アを送信してもよい[MAY]。アンサー側は、recvonlyまたはsendrecvストリー ムに対して、アンサーにあるストリームで列挙されているすべてのメディアス トリームを使用して、メディアを受信する準備をしなければならず[MUST]、 また、メディアをただちに送信してもよい[MAY]。メディアを送信する場合、 オファーで提示されていれば、ptime属性値と同一のパケット化の間隔を使用 すべきである[SHOULD]。オファーで提示されていれば、bandwidth属性値より 高くない帯域を使用してメディアを送信すべきである[SHOULD]。アンサー側は アンサーにも列挙されたオファー内のメディアフォーマットを使用して送信し なければならず[MUST]、アンサーにも列挙されたオファー内で最も優先度の高 いメディアフォーマットを使用して送信すべきである[SHOULD]。 Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 RTPの場合、オファーからのペイロードタイプ番号を、たとえアンサーのそれ とは異なっていても、使用しなければならない[MUST]。 6.2 マルチキャストストリーム ストリームの2つの観点があるユニキャストとは違い、マルチキャストには ただ1つのストリームの観点がある。したがって、マルチキャストのオファーへ 1つのアンサーを生成することは、一般に、限定された組み合わせのストリーム の側面を変更することを意味する。 マルチキャストストリームが受け入れられる場合、アンサー内のアドレスと ポート情報はオファーのそれとマッチしなければならない[MUST]。同様に、 アンサー内の方向性情報(sendonly、recvonly、sendrecv)はオファーの それと同一でなければならない[MUST]。これは、RFC2327のマルチキャスト 偏向の潜在的な推定である、マルチキャストセッションのすべての参加者が セッションのパラメータに同一の観点を持つ必要があるということのため である。 アンサーのメディアフォーマットのセットは、オファーのそれと同一か、 サブセットでなければならない[MUST]。フォーマットを削除することは、 アンサー側がそのフォーマットに対応していないことを示す1つの方法で ある。 アンサーのptimeとbandwidth属性は、オファーで提示されていれば、オファー のそれと同一でなければならない[MUST]。提示されていなければ、0ではない ptimeをアンサーに追加してもよい[MAY]。 7 オファー側のアンサー処理 オファー側がアンサーを受信する場合、受け入れられたストリーム(複数も可) 上でメディアを送信してもよい[MAY](アンサーでsendrecvまたはrecvonlyと 列挙されると仮定して)。オファー側はアンサーで列挙されるメディアフォー マットを使用して送信しなければならず[MUST]、送信したときのアンサーに列 挙される最初のメディアフォーマットを使用すべきである[SHOULD]。 これがMUSTではなくSHOULDの理由は(アンサー側でもMUSTではなくSHOULDだ が)、しばしば、進行中にコーデックを変える必要があるためである。例え ば、無音の間、エージェントはコンフォートノイズのコーデックに切り替 えたいかもしれない。または、ユーザーがキーパッドの番号を押したとき、 エージェントはRFC2833[9]を使用してそれを送信したいかもしれない。 コンジェッション制御のために、フィードバックに基づいてより低いレー トのコーデックへの変更が必要になるかもしれない。 オファー側は、アンサーにあるptimeとbandwidth属性の値に応じてメディアを 送信すべきである[SHOULD]。 オファー側は、最初のオファーで列挙されたがアンサーに提示されないメディ アフォーマットをリッスンするのを、ただちに止めてもよい[MAY]。 Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 8 セッションの変更 セッション中のどの時点でも、各参加者はセッションの特性を変更するために 新規のオファーを発行してもよい[MAY]。上記で定義されているまったく同じ オファー/アンサー処理が既存セッションのパラメータを変更するために使用 されることは、オファー/アンサーモデルの操作にとって基本的なことである。 オファーは、(オファーまたはアンサーで提示されていたかもしれない)相手へ 提示された最後のSDPと同一であってもよい[MAY]し、また、異なっていてもよ い[MAY]。ここでは、「前のSDP」として提供される最後のSDPについて記載す る。オファーが同じなら、アンサーはアンサー側の前のSDPと同じであっても よい[MAY]し、異なってもよい[MAY]。オファーされたSDPが前のSDPと異なる場 合、以下で議論されるように、構築時にいくつかの制限がなされる。 セッションのほとんどのすべての側面は、変更できる。新規のストリームが 追加でき、既存のストリームは削除される可能性があり、既存のストリームの パラメータは変更できる。セッションを変更するオファーを発行する場合、 新規SDPの「o=」行は前のSDPのそれと同一でなければならない[MUST]。これに はorigin(o=)フィールドにあるバージョンは前のSDPから1つインクリメントし なければならない[MUST]という例外がある。origin(o=)行のバージョンがイン クリメントしない場合、SDPはバージョン番号を持つSDPと同一でなければなら ない[MUST]。アンサー側は変わらないバージョンを持つSDPを含むオファーを受 け入れる準備がなくてはならない[MUST]。これは、実質的にノーオペレーショ ン命令(no-op)である。だが、アンサー側は、セクション6で定義される手順に 従って、有効なアンサー(アンサー側の前のSDPと同じであってもよい[MAY]し、 異なってもよい[MAY])を生成しなければならない[MUST]。 SDPが提示され、それが前のSDPと異なる場合、新規のSDPは前のSDPにある 各メディアストリームに対してマッチするメディアストリームを持たなければ ならない[MUST]。言い換えると、前のSDPがN個の「m=」行を持つ場合、新規の SDPは少なくともN個の「m=」行を持たなければならない[MUST]。前のSDP内の 先頭から数えてi番目のメディアストリームは、新規のSDPの先頭から数えて i番目のメディアストリームにマッチする。このマッチングはアンサー側が 新規のSDPにあるどのストリームが前のSDPのどのストリームに相当するのかを 決めるために必要である。これらの必要条件のために、ストリーム内の「m=」 行の数は決して減らないが、同じ数のままか、増える。前のSDPから削除され たメディアストリームは新規のSDPで削除されてはならない[MUST NOT]。だが、 これらストリームの属性は提示される必要はない。 8.1 メディアストリームの追加 新規のメディアストリームは、既存の下へ新しく追加するメディア記述に よって、または、ポートを0に設定することで使用不可にされていた古いメディ アストリームに使用された「スロット」を再利用することによって、生成され る。 Rosenberg & Schulzrinne Standards Track [Page 13] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 スロットの再利用は、新規の記述が古いものを置換するが、SDP内の別のメディ ア記述に関係する位置付けを保つ、ということを意味する。新規メディアの 記述はすべての既存メディアのセクションの下に表示しなければならない [MUST]。これらのメディア記述をフォーマットする規則は、セクション5で記 載されているものと同様である。 アンサー側が、オファー側からの前のSDPよりも多くのメディア記述を持つSDP をSDPを受信するか、またはポートが以前は0だったスロットにメディアスト リームを持つSDPを受信する場合、アンサー側は新規のメディアストリームが 追加されているということがわかる。適切に構築されたメディア記述をアン サーに配置することで、拒否したり受け入れたりすることができる。アンサー に新規のメディア記述を構築するための手順はセクション6で記載されている。 8.2 メディアストリームの削除 既存のメディアストリームはストリームに対して0に設定されたポート番号を 持つ新規のSDPを生成することで削除される。ストリーム記述は以前定時され ていたすべての属性を省略してもよく[MAY]、1つのメディアフォーマットのみ を挙げてもよい[MAY]。 0のポートとともにオファーされたストリームは、アンサーでポート0とともに マークされなければならない[MUST]。オファー同様に、アンサーは以前提示さ れていたすべての属性を省略してもよく[MAY]、オファーにある中から1つの メディアフォーマットのみを挙げてもよい[MAY]。 メディアストリームの削除は、メディアがそのストリームに対して、もう 送信せず、受信されるすべてのメディアが廃棄されるということを示す。 RTPの場合、他のRTCPパケットの受信処理と同様に、RTCP送信もまた中断する。 それに関わるすべてのリソースはリリースされる。ユーザーインターフェイス は、例えば、PC上で関係するウィンドウを閉じることで、ストリームが停止し たことを示すかもしれない。 8.3 メディアストリームの変更 メディアストリームのほとんどすべての特性は変更できる。 8.3.1 アドレス、ポート、またはトランスポートの変更 ストリームのポート番号は変更されてもよい[MAY]。これを実行するために、 オファー側は、前のSDPの関連するストリームとは異なる、m行のポート番号を 持つ新規のメディア記述を生成する。ポート番号だけが変更される場合、メ ディアストリーム記述の残りの部分は変更されずに残すべきである[SHOULD]。 オファー側は、オファーが送信されたらすぐに、古いポートと新しいポートの 両方でメディアを受信する準備をしなければならない[MUST]。オファー側は、 アンサーが新規のポートで受信され、メディアが届くまで、古いポートでの メディアのリッスンを中止すべきではない[SHOULD NOT]。それを実行すること は、送信中のメディアをロスする結果になる可能性がある。 Rosenberg & Schulzrinne Standards Track [Page 14] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 この場合、受信した、とは、メディアがメディアシンクにパスされたことを意 味する。これは、再生バッファがある場合、新規ポート上のメディアが再生 バッファの先頭に届くまで、エージェントは古いポートをリッスンし続ける、 ということを意味する。そのとき、古いポート上のメディアをリッスンするの を中止してもよい[MAY]。 アンサー中の関連するメディアストリームは、アンサー側からの前のSDP中に あるストリームと同じでもよいし[MAY]、異なってもよい[MAY]。アップデート されたストリームがアンサー側に受け入れられた場合、アンサー側はただちに 新規のポートへストリームに対するトラフィックを送信し始めるべきである [SHOULD]。アンサー側が前のSDPからポートを変更した場合、アンサーが送信 されたらすぐに古いポートと新規のポートの両方でメディアを受信する準備を しなければならない[MUST]。アンサー側は、メディアが新規のポートに届くま で古いポート上のメディアをリッスンするのを中止してはならない[MUST NOT]。そのとき(訳注: メディアが新規のポートに届いたら)、古いポート上の メディアをリッスンするのを中止してもよい[MAY]。同じことが新規のポート を持つアップデートオファーを送信するオファー側にも言える。つまり、メデ ィアが新規のポートに届くまで、オファー側は古いポート上のメディアをリッ スンするのを中止してはならないのである[MUST NOT]。 もちろん、オファーされたストリームが拒否された場合、オファー側は、 拒否を受信するとすぐに新規のポートを使用して受信する準備を中止すること ができる。 メディアが送信されるIPアドレスを変更するには、ポート番号を変更するのと 同様の処理がされる。ただひとつの違いは、接続ラインがアップデートされる (ポートの場合はアップデートされない)ということである。 ストリームへのトランスポートは変更されてもよい[MAY]。これを実行する処 理は、トランスポートがアップデートされる(ポートの場合はアップデートさ れない)という例外を除き、ポートの変更と同様である。 8.3.2 メディアフォーマットの集合の変更 セッションで使用されるメディアフォーマットのリストは変更されてもよい [MAY]。これを実行するために、オファー側は、前のSDPと関連するメディアス トリームとは異なる「m=」行内のメディアフォーマットのリストを持つ、新規 のメディア記述を生成する。このリストは新規のフォーマットを含んでもよく [MAY]、前のSDPから提示された書式を削除してもよい[MAY]。しかし、RTPの場 合は、メディアストリーム内で特定の動的ペイロードタイプ番号から特定の コーデックへマッピングしたものは、セッションの継続期間の間は変更しては ならない[MUST NOT]。例えば、Aが動的なペイロードタイプ番号46をアサイン されているG.711を持つオファーを生成する場合、この時点から、ペイロード タイプ番号46は、セッション内のそのメディアストリームに対するすべての オファーとアンサー内において、G.711を参照しなければならない[MUST]。 だが、複数のペイロードタイプ番号が同じコーデックにマップされるのは許容 される。なぜなら、アップデートされたオファーがG.711に対してペイロード タイプ番号72もまた使用する可能性があるためである。 Rosenberg & Schulzrinne Standards Track [Page 15] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 SDPとメディアストリームのシグナリング交換の間でのゆるい同期化の ため、セッションの継続期間中は、マッピングが固定されたままである 必要がある。 アンサー中の関連するメディアストリームはセクション6で記載される通りに 定式化され、また、同様に、メディアフォーマットの変更という結果になる可 能性がある。同様に、セクション6で書かれている通り、アンサーを送信する とすぐに、アンサー側はアンサーでも提示されていたオファー内のフォーマッ トのいずれかを使用してメディアを送信し始めなければならず[MUST]、(スト リームが送信を許容すると仮定して)アンサーでも列挙されていたオファー内 で最も優先されるフォーマットを使用すべきである[SHOULD]。また、ピアから の前のSDPにあったとしても、オファーにないフォーマットを使用して送信して はならない[MUST NOT]。同様に、オファー側がアンサーを受信する場合、アン サー内のフォーマットいずれかを使用してメディアを送信し始めなければなら ず[MUST]、(ストリームが送信を許容すると仮定して)最も優先度の高いものを 使用すべきである[SHOULD]。また、ピアからの前のSDPにあったとしても、 アンサーにないフォーマットを使用して送信してはならない[MUST NOT]。 エージェントがメディアフォーマットを使用するのを(それが前のSDPにあった としても、オファーまたはアンサーにあるフォーマットを列挙しないことに よって)中止した場合、エージェントはまだ、少しの間、そのフォーマットを 持つメディアを受信する準備をする必要がある。そのフォーマットの受信を 停止する準備ができたことはどうやって知るのだろうか? 知る必要がある 場合、適用できる技術が3つある。1つ目はフォーマットを変更するのに加え、 エージェントがポートを変更できることである。メディアが新規のポート上で 届くと、ピアは古いフォーマットでの送信を中止したことを知り、そこで 受信準備することを中止することができる。このアプローチはメディアフォー マットを独立したものにする利益がある。だが、ポートの変更は、リソース予 約や、セキュリティプロトコルの再キーイングの変更も必要になるかもしれな い。2つめのアプローチは、1つが廃棄されたときに、すべてのコーデックに対 して動的なペイロードタイプのまったく新規のセットを使用することである。 メディアが新規のペイロードタイプの1つとともに受信すると、エージェントは ピアが古いフォーマットで送信するのを中止したことを知る。このアプローチ は、予約やセキュリティの文脈には影響しないが、RTP独自のものであり、非 常に少ないペイロードタイプスペースでは無駄が多い。3つ目のアプローチは タイマーを使用することである。ピアからのSDPが受信されると、タイマーが 設定される。タイマーが切れると、エージェントは古いフォーマットで受信す る準備を中止することができる。1分の値があれば、一般的に十分すぎるほど である。ある場合では、エージェントは気にしないかもしれず、そのために 古いフォーマットで受信の準備をし続けるかもしれない。この場合では、何も する必要はない。 もちろん、オファーされたストリームが拒否された場合、オファーは 拒否が受信されるとすぐに、新規のフォーマットを使用して受信する準備を 中止することができる。 Rosenberg & Schulzrinne Standards Track [Page 16] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 8.3.3 メディアタイプの変更 ストリームに対するメディアタイプ(音声、ビデオ等)は、変更されてもよい [MAY]。同じ論理データがメディアフォーマットだけが異なる状態で伝達され る場合、メディアタイプが変更される(新規のストリームを追加するのでは なく)ことを推奨する[RECOMMENDED]。これは、別々のメディアタイプである、 音声帯域のfaxと1個のストリーム内のfax間の変更のために、特に有益である。 これを実行するために、オファー側は、変更されるべき前のSDPにある記述の 代わりに、新規のメディアタイプを持つ新規のメディア記述を生成する。 アンサーで関連するメディアストリームはセクション6で書かれているように、 定式化されている。ストリームが受け入れ可能だとして、アンサー側はオファー を受けるとすぐに、新規のメディアタイプとフォーマットともに送信を開始す べきである[SHOULD]。オファー側は、アンサーが受信され、また、新規のタイ プを持つメディアが受信されて再生バッファの先頭に到達するまで、古いタイ プと新規のタイプの両方を持つメディアを受信する準備をしなければならない [MUST]。 8.3.4 属性の変更 メディア記述内にあるその他属性は、オファーまたはアンサーにおいてアップ デートされてもよい[MAY]。一般に、エージェントは、偏向されたSDPを一度受 信したら新規のパラメータを使用して、(ストリームの方向性が許せば)メディ アを送信しなければならない[MUST]。 8.4 ユニキャストメディアストリームの保留 通話中の一方が相手を「保留中」のしたい場合、例えば、1個以上のユニキャ ストメディアストリームを送信するのを一時的に止めるというリクエストとい う、アップデートされたSDPをそのもう一方にオファーする。 保留中にされるストリームが前にsendrecvのメディアストリームの場合、 sendonlyとマークすることで保留中にされる。保留中にされるストリームが 前はrecvonlyのメディアストリームの場合、inactiveとマークすることで保留 中にされる。 これはストリームは各方向ごとに「保留中」にされるということを意味する。 各ストリームは個々に「保留中」にされる。保留中であるストリームに対する オファーの受信者は、保留中のストリームに関係するアンサーを自動的に返す べきではない[SHOULD NOT]。「保留中」のすべてのストリームを持つSDPは保 留されたSDPと呼ばれる。 保留されたSDPへアンサー側が応答する場合、いくつかのサードパーティの 呼制御シナリオは、保留されたSDPに対して機能しないだろう。 Rosenberg & Schulzrinne Standards Track [Page 17] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 一般に、ユーザーが保留を「押す」場合、エージェントはsendonlyの方向を示 すSDP内ですべてのストリームとともにオファーを生成し、さらに、ローカル をミュートするだろう。なぜなら、メディアは向こう側に送信されないし、 メディアは再生されないからである。 RFC2543[10]は、ユーザーを保留中にすることは、接続アドレスを0.0.0.0に設 定することで実現すると規定している。通話を保留中にするその用法はもう推 奨されない。なぜなら、それは、RTCPが保留されたストリームとともに使用さ れることを許容せず、IPv6では機能せず、基点のメディアとの接続を切るため である。だがこれは、オファー側が特定のメディアストリームとフォーマット のセットを使用したいことがわかっているが、オファー時にアドレスとポート を知らない場合、最初のオファーでは有益である。もちろん、使用されるとき にポート番号は0ではならない[MUST NOT]。それは、ストリームが使用不可で あることを示すためである。エージェントは、RTPもRTCPもピアに送信されな いような場合であっても、0.0.0.0の接続アドレスを持つSDPを受信できなけれ ばならない[MUST]。 9 能力の指示 エージェントがオファーを送信する前に、オファー内のメディアフォーマット がアンサー側に受け入れられるものかどうかを知ることは有益である。SIPの ような特定のプロトコルはこのような能力を問い合わせる手段を提供する。 SDPはそのような問い合わせに対する応答で、能力を表すのに使用できる。 このセクションはこのようなSDPメッセージがどのようにフォーマットされる かを記載する。SDPにはメッセージが能力指定の目的のためであることを示す 方法がないので、上位層プロトコルの記述によって決定される。能力を示す基 本的なSDPの機能は非常に限られている。許容されたパラメータ範囲や値を表 すことはできないし、オファー/アンサー自体でパラレルに実行することもで きない。拡張が将来的にこのような制限を宣言するかもしれない。 メディア能力を示すために構築されるSDPは、以下のように構築される。 それは、「e=」と「p=」行の両方を省略してもよい[MAY]ということを例外と して、有効なSDPでなければならない[MUST]。「t=」行は「0 0」に一致しなけ ればならない[MUST]。エージェントが対応する各メディアタイプには、そのタ イプの関連するメディア記述がなければならない[MUST]。origin(o=)フィール ドにあるセッションIDは、メディア能力を示すために構築された各SDPごとに ユニークでなければならない[MUST]。ポート番号は0に設定されなければならな い[MUST]が、接続アドレスは任意である。ポート0の使用は、能力のために フォーマットされたSDPは、オファーまたはアンサーとして解釈される場合、 メディアストリーム確立する結果にはならない。 「m=」行のトランスポートコンポーネントは、メディアタイプのためのトラン スポートを示す。エージェントが対応するタイプの各メディアフォーマットに は、「m=」行で列挙されるメディアフォーマットがあるべきである[SHOULD]。 RTPの場合、動的ペイロードタイプが使用されるときは、特定のフォーマット Rosenberg & Schulzrinne Standards Track [Page 18] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 にタイプを固定するために、rtpmap属性が提示されなければならない[MUST]。 特定のコーデックについて、同時にいくつのストリームが対応できるかといっ た制限を示す方法はない。 v=0 o=carol 28908764872 28908764872 IN IP4 100.3.6.6 s=- t=0 0 c=IN IP4 192.0.2.4 m=audio 0 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 0 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 図1: 能力を示すSDP 図1のSDPはエージェントが3つの音声コーデック(PCMU、1016、GSM)と、2つの ビデオコーデック(H.261とH.263)に対応することを示す。 10 オファー/アンサー交換の例 このセクションはオファー/アンサー交換の例を提供する。 10.1 基本交換 発呼側のAliceは自分のオファーで以下の記述を含むとする。そこには1つの双 方向性の音声ストリームと2つの双方向性のビデオストリームを含み、それら はH.261(ペイロードタイプ31)とMPEG(ペイロードタイプ32)を使用する。 提示されるSDPは以下の通り。 v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 Rosenberg & Schulzrinne Standards Track [Page 19] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 受呼側のBobは最初のビデオストリームは受信または送信したくないので、ア ンサーとして以下のように返す。 v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 後にある時点で、Bobは音声ストリームを受信するポート番号を変更すること に決め(49920から65422へ)、同時に、イベントのためのRTPペイロードフォー マット[9]を使用して、受信のみとして、新規の音声ストリームを追加する。 Bobはオファーに以下のようなSDPを提示する。 v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 65422 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 m=audio 51434 RTP/AVP 110 a=rtpmap:110 telephone-events/8000 a=recvonly Rosenberg & Schulzrinne Standards Track [Page 20] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 Aliceは新規のメディアストリームを受け入れ、そのために以下のアンサーを 生成する。 v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 m=audio 53122 RTP/AVP 110 a=rtpmap:110 telephone-events/8000 a=sendonly 10.2 N個のコーデックから1つを選択する 組み込み電話で共通して発生することは、圧縮のために使用されるDigital Signal Processor (DSP)は同時に複数のコーデックに対応することができる が、一度コーデックが選択されると、進行中にすぐには修正されない、という ことである。この例は、コーデックのセットを固定する2つ目がすぐに続く、 最初のオファー/アンサー交換を使用して、どのようにセッションを確立する かについて示す。 AliceからBobへの最初のオファーは、DSPで利用可能な3つの音声コーデックを 持つ1個の音声ストリームを示す。コーデックが固定されるまでメディアを受 信できないので、受信ストリームはinactiveとマークされている。 v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 0 4 18 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=inactive Rosenberg & Schulzrinne Standards Track [Page 21] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 BobはPCMUとG.723間の動的なスイッチングに対応できている。そのため、 彼は以下のアンサーを送信する。 v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=inactive Aliceは、それからこれら2つのコーデックのうち1つを選択できる。そのため、 彼女はsendrecvストリームとともにアップデートされたオファーを送信する。 v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv Bobは1つのコーデックを受け入れる。 v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv アンサー側(Bob)がN個のコーデックのうち1に対応することができる場合、 Bobはオファーの中からコーデックの1つを選択し、アンサーに配置する。 この場合、Aliceはそのコーデックでストリームをアクティブにするために re-INVITEを行う。 最初の交換で「a="inactive"」を使用する代わりに、Aliceはすべてのコーデ ックを列挙することができ、また、Bobからメディアを受信してすぐに、受信 した1つに固定するアップデートオファーを生成することができる。もちろん、 BobがN個のコーデックのうち1個のみに対応する場合は、彼のアンサーには1個 のコーデックしないだろう。この場合、1個のコーデックに固定するために re-INVITEを行う必要はない。 Rosenberg & Schulzrinne Standards Track [Page 22] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 11 セキュリティの考慮 攻撃者がトランジットでオファーやアンサーを修正できるなら、多くの攻撃が 可能である。これには、一般に、メディアストリームを移転したり(盗聴が可 能になる)、呼を使用できなくしたり、望まないメディアストリームの入れ込 む等が含まれる。消極的リスナーが偽のオファーを構築でき、また、それらを やりとりに入れ込むことができる場合、同様の攻撃が可能である。攻撃者がオ ファーとアンサーを観察できるだけだとしても、既存の会話にメディアストリ ームを入れ込むことはできる。 オファー/アンサーはSIPのようなアプリケーションシグナリングプロトコル内 のトランスポートに依存する。また、セキュリティの能力もまた、そのプロト コルに依存している。上記の攻撃のため、そのプロトコルは、エンドツーエン ドの認証とオファーとアンサー全体を守るための手段を提供しなければならな い[MUST]。 そのプロトコルは盗聴を防ぐためにボディの暗号化を提供すべきである [SHOULD]。だが、メディア注入攻撃は、代わりに認証済みのメディア交換を通 して解決される可能性があり、そのため、暗号化の必要性はMUSTではなく SHOULDである。 再生攻撃もまたやっかいである。攻撃者は、メディアを保留にし、結果的に、 会話中のメディアストリームが使用できなくなるような、古いオファーを再生 する可能性がある。そのため、アプリケーションプロトコルは、ひと続きの オファーとアンサーについて安全な方法を提供し、古いオファーまたはアン サーを検知し、拒否する方法を提供しなければならない[MUST]。 SIP[7]は、これらの要件をすべて満たす。 12 IANA条項 この仕様についてIANA条項はない。 13 謝辞 The authors would like to thank Allison Mankin, Rohan Mahy, Joerg Ott, and Flemming Andreasen for their detailed comments. 14 規範となる参考文献 [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Kumar, R. and M. Mostafa, "Conventions For the Use of The Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. Rosenberg & Schulzrinne Standards Track [Page 23] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 [4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. 15 有益な参考文献 [6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [7] 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. [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 16 著者の連絡先 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Rosenberg & Schulzrinne Standards Track [Page 24] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 17 完全な著作権表記 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2004年 --------------------------------------------------------------------------- Rosenberg & Schulzrinne Standards Track [Page 25]