Network Working Group M. Handley Request for Comments: 4566 UCL Obsoletes: 2327, 3266 V. Jacobson Category: Standards Track Packet Design C. Perkins University of Glasgow July 2006 SDP: セッション記述プロトコル SDP: Session Description Protocol 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を依頼 するものである。標準化の段階や、プロトコルの位置付けについては、最 版の"Internet Official Protocol Standards" (STD 1)を参照されたい。こ の文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 本文書は、セッション記述プロトコル(Session Description Protocol/SDP) を定義する。SDPは、セッション告知、セッションの招待などの形式を持つ マルチメディアセッションの開始という目的で、マルチメディアセッション を記述するためのプロトコルである。 目次 1. はじめに ....................................................... 3 2. 用語集 ......................................................... 3 3. SDPの使用例 ................................................... 4 3.1. セッションの開始 ......................................... 4 3.2. ストリーミングメディア ................................... 4 3.3. 電子メールとWWW ........................................... 4 3.4. マルチキャストセッション告知 ............................. 4 4. 要件と推奨 ..................................................... 5 4.1. メディアとトランスポートの情報 ........................... 6 4.2. タイミング情報 ........................................... 6 4.3. プライベートセッション ................................... 7 4.4. セッションに関する詳細情報の取得 ......................... 7 4.5. 分類化 ................................................... 7 4.6. 国際化 ................................................... 7 Handley, et al. Standards Track [Page 1] RFC 4566 SDP July 2006 5. SDP仕様 ....................................................... 7 5.1. プロパティバージョン(「v=」) ............................ 10 5.2. 送信元(「o=」) .......................................... 11 5.3. セッション名(「s=」) .................................... 12 5.4. セッション情報(「i=」) .................................. 12 5.5. URI (「u=」) ............................................ 13 5.6. 電子メールアドレスと電話番号(「e=」 と 「p=」) .......... 13 5.7. 接続データ(「c=」) ...................................... 14 5.8. 帯域(「b=」) ............................................ 16 5.9. タイミング(「t=」) ...................................... 17 5.10. 繰り返し回数(「r=」) .................................... 18 5.11. タイムゾーン(「z=」) .................................... 19 5.12. 暗号化キー(「k=」) ...................................... 19 5.13. 属性(「a=」) ............................................ 21 5.14. メディア記述(「m=」) .................................... 22 6. SDP属性 ...................................................... 24 7. セキュリティの考慮事項 ........................................ 31 8. IANA条項 ...................................................... 33 8.1. "application/sdp"メディアタイプ .......................... 33 8.2. パラメータの登録 ........................................ 34 8.2.1. メディアタイプ(「media」) ........................ 34 8.2.2. トランスポートプロトコル(「proto」)................ 34 8.2.3. メディアタイプ(「fmt」) .......................... 35 8.2.4. 属性名("att-field") .............................. 36 8.2.5. 帯域指定子(「bwtype」) ............................ 37 8.2.6. ネットワークタイプ(「nettype」) .................. 37 8.2.7. アドレスタイプ(「addrtype」) ...................... 38 8.2.8. 登録手順 .......................................... 38 8.3. 暗号化キーのアクセス方法 ................................ 39 9. SDPの文法 .................................................... 39 10. RFC 2327からの変更の概要 .................................... 44 11. 謝辞 ........................................................ 45 12. 参考文献 .................................................... 45 12.1. 規範となる参考文献 ...................................... 45 12.2. 有益な参考文献 .......................................... 46 Handley, et al. Standards Track [Page 2] RFC 4566 SDP July 2006 1. はじめに マルチメディアの電話会議、VoIP (Voice-over-IP)、ストリーミングビデ オ、またはその他のセッションを開始するときに、メディアの詳細、トラン スポートアドレスなどのセッション記述メタデータを参加者に伝達する必要 がある。 SDPは、このような情報の標準的な表記方法を提供する。ただし、情報の伝 送方法については関与しない。SDPは、単にセッションを記述するための書 式である。トランスポートプロトコルは組み込まれていない。また。また、 必要に応じて異なるトランスポートプロトコルを使用するように設計されて いる。たとえば、Session Announcement Protocol [14]、Session Initiation Protocol [15]、Real-Time Streaming Protocol [16]、MIME拡 張を使用した電子メール、Hypertext Transport Protocolなどである。 SDPは、幅広いネットワーク環境やアプリケーションに使用できるよう、汎 用的に設計されている。ただし、セッションコンテンツまたはメディアエン コーディングのネゴシエーションをサポートすることは対象としていない。 これは、セッション記述の範囲外と見なしている。 本文書によってRFC 2327 [6]とRFC 3266 [10]は廃止される。セクショ ン10に、本文書で組み込まれた変更点を概説している。 2. 用語集 次の用語は、本文書で使用され、本文書内で独自の意味を持つ。 カンファレンス(Conference): マルチメディアカンファレンスは、2人以上 の通信ユーザーと通信に使用するソフトウェアの集合である。 セッション(Session): マルチメディアセッションは、マルチメディアの送信 側と受信側、および送信側から受信側に流れるデータストリームの集合 である。 マルチメディアカンファレンスは、マルチメディアセッションの一例で ある。 セッション記述(Session Description): マルチメディアセッションを検 出し、参加するために十分な情報を伝達するための定義済み書式。 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[3]に記載されるとお りに解釈されるべきである。 Handley, et al. Standards Track [Page 3] RFC 4566 SDP July 2006 3. SDPの使用例 3.1. セッションの開始 セッション開始プロトコル(Session Initiation Protocol/SIP) [15]は、イ ンターネットマルチメディアカンファレンス、インターネット電話の通話、 マルチメディアの配信など、セッションの開始、変更、および終了を行う、 アプリケーション層の制御プロトコルである。セッションを作成するときに 使用されるSIPメッセージでは、互換性のあるメディアタイプに関して参加 者どうしが同意することができるセッション記述を伝達する。このような セッション記述は、一般的にSDPを使用して構築される。SIPと共に使用する 場合、オファー/アンサーモデル[17]は、SDPを使用したネゴシエーション用 に限定されたフレームワークを提供する。 3.2. ストリーミングメディア リアルタイムストリーミングプロトコル(Real Time Streaming Protocol/ RTSP) [16]は、リアルタイムの特性を持つデータの配信に関して制御する、 アプリケーション層プロトコルである。RTSPは、音声やビデオなどのリアル タイムデータを制御されたオンデマンド配信することができる、拡張性のあ るフレームワークを提供している。RTSPのクライアントとサーバーは、 メディア配信用の適切なパラメータ群をネゴシエートする。このとき、SDP 構文を部分的に使用して、パラメータを記述する。 3.3. 電子メールとWWW セッション記述を伝達するその他の手段として、電子メールとWWW (World Wide Web)がある。電子メールとWWWどちらを配信する場合でも、メディアタ イプ「application/sdp」が使用される。こうすることで、セッションに参 加するときにWWWクライアントやメールクライアントから標準的な方法で、 自動的にアプリケーションを起動することが可能になる。 電子メールまたはWWW経由のみで作成されたマルチメディアセッションの告知 には、セッション告知の受信側がセッションを必ず受信できるという特性は ないということに注意。これは、マルチメディアセッションは、スコープに 制約を受ける可能性があるためである。WWWサーバーへのアクセス、または 電子メールの受信は、このスコープ外にある可能性がある。 3.4. マルチキャストセッション宣言 マルチキャストマルチメディアカンファレンスや他のマルチキャストセッ ションの告知と、関連するセッション確立情報を参加予定者への通知を補助 する目的で、分散型のセッションディレクトリが使用されることがある。 このようなセッションディレクトリのインスタンスは、セッション記述を含 むパケットを既知のマルチキャストグループに対して定期的に送信する。 リモートの参加予定者が、セッション記述を使用してセッションに参加する ために必要なツールを起動できるように、こうした告知は他のセッション ディレクトリによって受信される。 Handley, et al. Standards Track [Page 4] RFC 4566 SDP July 2006 このような分散型ディレクトリを実装するためによく使用されるプロトコル のひとつに、セッション告知プロトコル(Session Announcement Protocol/ SAP) [14]がある。SDPでは、このようなセッション告知用に、推奨のセッ ション記述形式を用意している。 4. 要件と推奨 SDPの目的は、マルチメディアセッションのメディアストリームに関する情報 を伝達し、セッション記述の受信者がセッションに参加できるようにするこ とである。SDPは、主にインターネットワークでの使用を対象にしている。 ただし、他のネットワーク環境におけるカンファレンスを記述する場合も一 般的である。メディアストリームは、多対多の可能性がある。セッションは 継続的にアクティブである必要はない。 したがって、インターネット上のセッションに基づくマルチキャストは、 トラフィックを受信する誰もが(セッショントラフィックが暗号化されてい なければ)セッションに参加できる、多くのカンファレンス形式とは異なる。 このような環境で、SDPには主に2つの目的がある。1つはセッションの存在 を通信する手段、もう1つはセッションに追加および参加するのに十分な情 報を伝達する手段である。ユニキャスト環境では、後者の目的の方に関係性 が高い。 SDPセッション記述には以下の要素が含まれる。 o セッションの名前と目的 o セッションがアクティブな時間 o セッションを構成するメディア o そのメディアを受信するために必要な情報(アドレス、ポート、形式など) セッションに参加する必要があるリソースは制約を受ける可能性があるた め、他の情報が必要になる場合もある。 o セッションで使用する帯域に関する情報 o セッションに責任を持つ人物のコンタクト情報 一般的に、SDPでは、セッションに参加し、情報が必要な非参加者に対して 使用するリソースを告知するために十分な情報を伝達する必要がある(暗号 化キーは除外される場合もある)(この後者の機能が主に有効なのは、SDPを セッション告知プロトコルと共に使用する場合である)。 Handley, et al. Standards Track [Page 5] RFC 4566 SDP July 2006 4.1. メディアとトランスポートの情報 SDPセッション記述には次のメディア情報が含まれる。 o メディアの種類(ビデオ、音声など) o トランスポートプロトコル(RTP/UDP/IP、H.320など) o メディアの形式(H.261ビデオ、MPEGビデオなど) メディア形式とトランスポートプロトコルの他に、SDPはアドレスとポート の詳細も伝達する。IPマルチキャストセッションの場合、次の情報で構成さ れる。 o メディアのマルチキャストグループアドレス o メディアのトランスポートポート このアドレスとポートは、送受信どちらの場合でも、マルチキャストスト リームの送信先アドレスと送信先ポートである。 IPユニキャストセッションの場合、次の情報が伝達される。 o メディアのリモートアドレス o メディアのリモートのトランスポートポート このアドレスとポートのセマンティクスは、定義されているメディアとトラ ンスポートプロトコルによって異なる。デフォルトで、これはデータが送信 される先のリモートアドレスとリモートポートにすべきである[SHOULD]。 メディアタイプによってはこの動作を再定義してもよい[MAY]が、実装が複 雑になるため、推奨されない[NOT RECOMMENDED] (アドレスを解析してNAT (Network Address Translation)またはファイアウォールの穴を開ける必要 があるミドルボックスの場合を含む)。 4.2. タイミング情報 セッションは時間に関連付けられている場合と関連付けられていない場合が ある。いずれにしても、特定の時間にのみアクティブな場合がある。SDPは 次のタイミング情報を伝達できる。 o セッションに関連付けた開始時間と停止時間の任意なリスト o 関連付けごとに、「every Wednesday at 10am for one hour(毎週水曜 日、午前10時に1時間)」などの繰り返し回数 このタイミング情報は、地域のタイムゾーンやサマータイムにかかわらず、 グローバルに整合性がある(セクション5.9参照)。 Handley, et al. Standards Track [Page 6] RFC 4566 SDP July 2006 4.3. プライベートセッション パブリックセッションとプライベートセッションのどちらも作成することが できる。SDP自体はこの両者を区別しない。プライベートセッションは一般 的に、配信時にセッション記述を暗号化して伝達される。暗号化方法の詳 細は、SDPを伝達するときに使用するメカニズムによって異なる。メカニズ ムについては、現在のところSAP [14]とSIP [15]を使用して伝送するSDPに ついて定義されている。将来的にその他の方法が定義される可能性がある。 セッション告知がプライベートの場合、カンファレンスの各メディアを デコードするために必要な暗号化キーを、プライベートな告知を使用して伝 達することができる。たとえば、各メディアに使用する暗号化スキームを知 るために必要な情報などである。 4.4. セッションに関する詳細情報の取得 セッション記述では、セッションに参加するかどうかを判断するために十分 な情報を伝達する必要がある。セッションに関する詳細情報として、URI (Uniform Resources Identifiers)の形式で追加のポインタをSDPに含めるこ とができる。 4.5. 分類化 多くのセッション記述がSAPまたは他の告知メカニズムによって配信される ときに、興味がある告知とそうでないセッション告知をフィルタすることが 望ましい場合がある。SDPでは、自動化できるセッションの分類化メカニズ ムをサポートしている("a=cat:"属性、セクション6参照)。 4.6. 国際化 SDP仕様では、UTF-8エンコーディング[5]でISO 10646文字セットを使用する ことを推奨している。これは、多様な言語を表記するためである。ただし、 短縮表記を支援するために、SDPでは、必要に応じてISO 8859-1などの文字 セットを使用することも許容している。国際化は、SDP全体ではなく、 フリーテキストのフィールド(セッション名と背景情報)にのみ適用される。 5. SDP仕様 SDPセッション記述は、メディアタイプで「application/sdp」と示される (セクション8を参照)。 SDPセッション記述は、全体にUTF-8エンコーディング形式のISO 10646文字 セットを使用したテキストである。SDPのフィールド名と属性名では、UTF-8 のUS-ASCIIサブセットのみを使用するが、テキストフィールドと属性値に は、ISO 10646のフル文字セットを使用してもよい[MAY]。完全なUTF-8文字 Handley, et al. Standards Track [Page 7] RFC 4566 SDP July 2006 セットを使用するフィールドと属性値は直接比較されることはないため、 UTF-8の正規化に要件はない。テキスト形式が選択された理由は、ASN.1や XDRなどのバイナリエンコーディングとは対照的で、ポータビリティを強化 するため、多彩なトランスポートを使用できるようにするため、および柔軟 性の高いテキストベースのツールけっとを使用してセッション記述の生成と 処理を行うためである。ただし、SDPは、セッション記述の最大許容サイズが 制限されている環境で使用できるため、エンコーディングは意図的にコンパ クトである。また、告知は、信頼性が非常に低い手段で伝送されたり、仲介 のキャッシングサーバーで損失する可能性があるため、エンコーディングは 厳密な順序規則と書式規則で設計された。これは、ほとんどのエラーを、 容易に検出して破棄できる不正な形式のセッション告知になるようにするた めである。こうすることで、受信側が正しいキーを持っていない暗号化済み セッション告知を速やかに破棄することができる。 SDPセッション記述は、次のような複数行のテキストで構成される。 = このは、大文字と小文字を区別する1文字でなければならない[MUST]。 また、は構造化されたテキストであり、によって形式が変わ る。一般的に、<値>は、スペース1文字で区切られた複数のフィールド、ま たは自由形式の文字列である。さらに、特に定義されていなければ、大文字 と小文字は区別される。ホワイトスペースは、「=」記号の両側に使用して はならない[MUST NOT]。 SDPセッション記述は、セッションレベルのセクションと、それに続く0個以 上のメディアレベルのセクションで構成される。セッションレベルのパート は「v=」行で始まり、最初のメディアレベルのセクションまで続く。各メ ディアレベルセクションは「m=」行で始まり、次のメディアレベルセクショ ンまたはセッション記述全体の末尾まで続く。一般的に、セッションレベル の値は、同等のメディアレベルの値で上書きされない場合、すべてのメディ アのデフォルト値になる。 各記述の行には必須[REQUIRED]のものとオプション[OPTIONAL]のものがあ る。ただし、いずれも本文書で指定した順序どおりに表記しなければならな い[MUST](順序を固定することで、エラーの検出が大幅に強化され、パー サーを単純にすることができる)。 オプション[OPTIONAL]の項目は、「*」という印が付けられている。 Handley, et al. Standards Track [Page 8] RFC 4566 SDP July 2006 セッション記述 v= (プロトコルのバージョン) o= (発信元およびセッション識別子) s= (セッション名) i=* (セッション情報) u=* (記述のURI) e=* (電子メールアドレス) p=* (電話番号) c=* (セッション情報 -- すべてのメディアに含まれる場合は 必要なし) b=* (0行以上の帯域情報行) 1つ以上の時間記述(「t=」と「r=」行については次を参照) z=* (タイムゾーンの調整) k=* (暗号化キー) a=* (0行以上のセッション属性行) 0以上のメディア記述 時間記述 t= (セッションがアクティブな時間) r=* (0回以上の繰り返し回数) メディア記述(存在する場合) m= (メディア名と伝送アドレス) i=* (メディアのタイトル) c=* (接続情報 -- セッションレベルで含める場合はオプション) b=* (0行以上の帯域情報行) k=* (暗号化キー) a=* (0行以上のメディア属性行) 入力文字のセットは意図的に少なくされており、拡張する予定はない。SDP パーサーは、理解できない入力文字を含むセッション記述は、完全に無視し なければならない[MUST]。属性のメカニズム(後述の「a=」)は、SDPを拡張 し、特定のアプリケーションまたはメディアに合わせるための主な手段で ある。一部の属性(本文書のセクション6で列挙するもの)には意味が定義さ れているが、アプリケーション、メディア、またはセッション固有の属性を 追加してもよい。SDPパーサーは、理解できない属性はすべて無視しなけれ ばならない[MUST]。 SDPセッション記述には、「u=」、「k=」、および「a=」の各行の外部コンテ ンツを参照するURIを含めることができる。場合によってはこのURIを逆参 照し、セッション記述自体を含まないようにすることもできる。 Handley, et al. Standards Track [Page 9] RFC 4566 SDP July 2006 セッションレベルセクションの接続(「c=」)と属性(「a=」)の各情報は、 メディア記述で同じ名前の接続情報または属性で上書きされた場合を除き、 すべてのセッションのメディアに適用される。たとえば、次の例に示すよ うに、各メディアは、「recvonly(受信のみ)」属性を指定された場合と同様 に動作する。 SDPの記述例は以下のとおり。 v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 セッション名や情報などのテキストフィールドは、0x00 (Null)、0x0a (ASCIIの改行文字)、および0x0d (ASCIIのキャリッジリターン)を除く任意 のオクテットを含むオクテット文字列である。レコードを終了するときに シーケンスのCRLF (0x0d0a)を使用するが、パーサーは、1つの改行文字で終 了するレコードを許容し、受け入れるべきである[SHOULD]。「a=charset」 属性が存在しない場合、このようなオクテット文字列は、UTF-8エンコー ディングのISO-10646文字を含むものとして解釈しなければならない[MUST] (「a=charset」属性が存在するときに、一部のフィールドに対して別の解釈 方法を強要してもよい)。 セッション記述の「o=」、「u=」、「e=」、「c=」、「a=」の各行には、 ドメイン名を含めることができる。SDPで使用するドメイン名は、[1]と[2] に準拠しなければならない[MUST]。国際対応ドメイン名(Internationalised domain name/IDN)は、[11]で定義されているASCII互換エンコーディング (ASCII Compatible Encoding/ACE)形式で表記しなければならない[MUST]。 また、直接UTF-8またはその他のエンコーディングで表記してはならない [MUST NOT](この要件は、国際対応ドメイン名の開発より前に発行されたRFC 2327や他のSDP関連の規格と互換性を保つためである)。 5.1. プロパティバージョン(「v=」) v=0 「v=」フィールドで、セッション記述プロトコルのバージョンを指定する。 本文書ではバージョン0を定義する。マイナーバージョン番号はない。 Handley, et al. Standards Track [Page 10] RFC 4566 SDP July 2006 5.2. 送信元(「o=」) o= 「o=」フィールドでは、セッションの発信元(ユーザーのホストのユーザー名 とアドレス)と、セッションID、セッションのバージョン番号を指定する。 は、ユーザーが発信元ホストにログインするときの名前である。 発信元ホストでユーザーIDという概念がサポートされていない場合は 「-」である。 にスペースを含めてはならない[MUST NOT]。 は、数値文字列(numeric string)である。これは、、<アドレスタイプ>、、および で、そのセッションのグローバルに固有な識別子を構 成するためである。の割り当て方法は作成ツールに委ねられる が、NTP (Network Time Protocol)のタイムスタンプを使用して一意性を 確保する方法が提案されている[13]。 はこのセッション記述のバージョン番号である。セッション データが修正されたときにを増やす、という点以外の用 法については、ここでも作成ツールに委ねられる。繰り返しになるが、 NTP形式のタイムスタンプを使用することが推奨される[RECOMMENDED]。 は、ネットワークのタイプを指定するテキスト文字列である。 元々、「IN」は「インターネット」の意味を持つように定義されてい たが、将来的に他の値を登録してもよい[MAY](セクション8参照)。 は、次のアドレスのタイプを指定するテキスト文字列である。 元々は「IP4」と「IP6」が定義されているが、将来的に他の値を登録し てもよい[MAY](セクション8参照)。 は、セッションを作成したマシンのアドレスである。ア ドレスタイプがIP4の場合、マシンの完全修飾ドメイン名か、マシンのIP バージョン4アドレスのドット付き10進数表記である。 アドレスタイプがIP6の場合、マシンの完全修飾ドメイン名か、マシンの IPバージョン6アドレスの圧縮されたテキスト表記である。IP4とIP6のど ちらの場合でも、使用できない場合を除き、完全修飾ドメイン名を使用 すべきである[SHOULD]。完全修飾ドメイン名を使用できない場合、 グローバルに一意なアドレスを代用してもよい[MAY]。SDP記述がローカル のIPアドレスが意味を持たないスコープに出る場合、ローカルのIPアドレ スを使用してはならない[MUST NOT](たとえば、ローカルアドレスは、 スコープを出る可能性があるアプリケーションレベル照会に含めてはな らない[MUST NOT])。 Handley, et al. Standards Track [Page 11] RFC 4566 SDP July 2006 一般的に、「o=」フィールドは、そのセッション記述のそのバージョンに関 して、グローバルに一意な識別子として機能する。また、バージョン以外の サブフィールドを合わせると、どのような修正があってもセッションを識別 できる。 プライバシ上の理由から、セッション開始元のユーザー名とIPアドレスはわ かりづらくするのが望ましい場合もある。この場合、任意のとプ ライベートのを選択して、「o=」フィールドを作成して もよい[MAY](ただし、フィールドのグローバルな一意性に影響がない方法で 選択されたという前提で)。 5.3. セッション名(「s=」) s= 「s=」フィールドは、テキストのセッション名である。各セッション記述ご とに指定できるのは1つの「s=」フィールドのみである[MUST]。「s=」フィー ルドは空にしてはならない[MUST NOT]。また、ISO 10646文字を含めるべき である[SHOULD](ただし、「a=charset」も参照すること)。セッションに意 味のある名前がない場合、値「s=」を使用すべきである[SHOULD](つまり、1 つのスペースをセッション名として使用する)。 5.4. セッション情報(「i=」) i= 「i=」フィールドは、セッションに関するテキスト情報である。1つのセッ ション記述ごとに最大1つのセッションレベルの「i=」フィールドを指定し、 1つのメディアごとに最大1つの「i=」フィールドを指定しなければならない [MUST]。「a=charset」属性が存在する場合、それによって「i=」フィール ドで使用される文字セットが指定される。「a=charset」属性が存在しない 場合、「i=」フィールドにはUTF-8エンコーディングのISO 10646文字を含め なければならない[MUST]。 1つの「i=」フィールドには、各メディア定義に使用してもよい[MAY]。 メディア定義で、「i=」フィールドは主にメディアストリームのラベル付け に使用される。したがって、1つのセッションに、同じメディアタイプを持つ 複数のメディアストリームがあるときに、有効な場合が多い。たとえば、2つ の異なるホワイトボードがあり、1つはスライド用、もう1つはフィードバッ クと質問用という場合などである。 「i=」フィールドは、自由形式で可読のセッションの説明やメディアスト リームの目的を提供するために用意されている。自動装置が解析するのには 適していない。 Handley, et al. Standards Track [Page 12] RFC 4566 SDP July 2006 5.5. URI (「u=」) u= URIはWWWクライアントで使用されるURI (Uniform Resource Identifier)で ある[7]、[9]。URIは、セッションに関する追加情報へのポインタにすべき である。このフィールドはオプション[OPTIONAL]だが、指定する場合、最初 のメディアフィールドの前に指定しなければならない[MUST]。1つのセッ ション記述ごとに許容されているURIフィールドは1つ以下である。 5.6. 電子メールアドレスと電話番号(「e=」 と 「p=」) e= p= 「e=」行と「p=」行は、カンファレンスに責任を持つ人物のコンタクト情報 を指定する。カンファレンス告知を作成した人物と同一にする必要はない。 電子メールまたは電話番号を含めるのはオプション[OPTIONAL]である。旧 バージョンのSDPでは、電子メールフィールドと電話番号フィールドは指定 しなければならない[MUST]と規定されていたが、本文書では広範囲にわたっ て無視されたということに注意。この変更によって、この仕様は汎用的に なった。 電子メールアドレスまたは電話番号を指定する場合、最初のメディアフィー ルドの前に指定しなければならない[MUST]。1つのセッション記述に、複数 の電子メールフィールドまたは電話フィールドを指定できる。 電話番号は、先頭に「+」が付いた国際電話番号の形式に表すべきである [SHOULD]。スペースとハイフンは、読みやすいように、必要に応じて電話 フィールドを区分するために使用してもよい。例: p=+1 617 555-6011 電子メールアドレスと電話番号のいずれも、関連するフリーのテキスト文字 列をオプション[OPTIONAL]で付けることができる。一般的に、接続相手の名 前を指定する。指定する場合、丸かっこで囲まなければならない[MUST]。例: e=j.doe@example.com (Jane Doe) 代わりに、RFC2822 [29]の名前の引用規約も許容される。電子メールアドレ スと電話番号のどちらにも使用できる。例: e=Jane Doe Handley, et al. Standards Track [Page 13] RFC 4566 SDP July 2006 フリーのテキスト文字列には、UTF-8エンコーディングされたISO-10646文字 セットを使用すべきである[SHOULD]。適切な文字セットのセッションレベル の「a=charset」属性が設定されている場合、代わりにISO-8859-1などのエン コーディングを使用することもできる。 5.7. 接続データ(「c=」) c= 「c=」フィールドには接続データを含める。 セッション記述には、メディア記述ごとに少なくとも1つの「c=」フィール ドを含めるか、セッションレベルで1つの「c=」フィールドを含めなければ ならない[MUST]。セッションレベルで1つの「c=」フィールドと、メディア 記述ごとに追加で「c=」フィールド(複数もあり)を含めてもよい[MAY]。こ の場合、メディアごとの値の方が、関連メディアのセッションレベル設定よ りも優先される。 最初のサブフィールド(「」)は、ネットワークタイプである。これ は、ネットワークのタイプを指定するテキスト文字列である。元々、「IN」 は「インターネット」の意味を持つように定義されていたが、将来的に他の 値を登録してもよい[MAY](セクション8参照)。 2つ目のサブフィールド(「」)はアドレスタイプである。これに よって、SDPをIPベースではないセッションにも使用できる。本文書ではIP4 とIP6しか定義していないが、将来的に他の値を登録してもよい[MAY](セク ション8参照)。 3つ目のサブフィールド(「」)は接続アドレスである。 フィールドの値によっては、接続アドレスの後にオプション [OPTIONAL]で別のサブフィールドを追加してもよい[MAY]。 がIP4とIP6の場合、接続アドレスは次のように定義される。 o セッションがマルチキャストの場合、接続アドレスはIPマルチキャスト グループのアドレスになる。セッションがマルチキャストではない場合、 追加の属性フィールドの指定どおり、接続アドレスには、期待される データソース、データリレー、またはデータシンクのユニキャストのIP アドレスが含まれる。マルチキャスト告知で通信されるセッション記 述で、ユニキャストアドレスを指定することは想定していない。ただ し、禁止もしていない。 o IPv4マルチキャスト接続アドレスを使用したセッションには、マルチキャ ストアドレスとは別に、有効期間(time to live/TTL)値を指定しなけれ ばならない[MUST]。TTLとアドレスの両方で、このカンファレンスで送信 されるマルチキャストパケットのスコープが定義される。TTL値は、 0〜255の範囲にしなければならない[MUST]。TTLを指定しなければならな い[MUST]が、マルチキャストトラフィックをスコープ指定する用法は廃 止予定である。 Handley, et al. Standards Track [Page 14] RFC 4566 SDP July 2006 アプリケーションは、その代わりに管理者がスコープ指定したアドレ スを使用すべきである[SHOULD]。 セッションのTTLは、スラッシュをセパレータに使用して、アドレスに付加 する。例: c=IN IP4 224.2.36.42/127 IPv6マルチキャストではTTLのスコープを使用しないため、TTL値はIPv6マル チキャストに存在してはならない[MUST NOT]。IPv6のスコープのアドレス は、カンファレンスのスコープを制限するために使用することが期待され る。 階層化されたスキームは、1つのメディアソースからのエンコーディングが 複数の層に分割されたデータストリームである。受信側は、この層のサブ セットにサブスクライブするだけで、目的の品質(と帯域)を選択できる。こ のような階層化されたエンコーディングは、一般的に複数のマルチキャスト グループで送信することで、マルチキャストの余計な部分の切りつめを可能 にしている。この技術では、階層の特定レベルのみを必要とするサイトから の未承諾トラフィックを維持する。アプリケーションが複数のマルチキャス トグループを必要とする場合、本文書では接続アドレスに次の表記方法を許 容している。 [/]/ アドレス数を指定しない場合、1と仮定される。そのため割り当てられる マルチキャストアドレスは、ベースアドレスの上に隣接して配置される。 たとえば、次のとおり。 c=IN IP4 224.2.1.1/127/3 これは、アドレス224.2.1.1、224.2.1.2、および224.2.1.3は、127のTTLで 使用されることを示す。これは、構文的には、1つのメディア記述に複数の 「c=」行を含める場合と同じである。 c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.3/127 同様に、IPv6の例を次に示す。 c=IN IP6 FF15::101/3 これは構文的に以下と同一である。 c=IN IP6 FF15::101 c=IN IP6 FF15::102 c=IN IP6 FF15::103 Handley, et al. Standards Track [Page 15] RFC 4566 SDP July 2006 (TTLフィールドはIPv6マルチキャストに存在しないことに注意) メディアベースで複数のアドレスまたは「c=」行を指定しもよい[MAY]が、 階層的または多層のエンコーディングスキームで、異なる階層のマルチキャ ストアドレスを指定する場合に限られる。セッションレベルの「c=」フィー ルドの場合、指定してはならない[MUST NOT]。 前述のような複数のアドレスをスラッシュで区切る表記法は、IPユニキャス トアドレスに使用してはならない[MUST NOT]。 5.8. 帯域(「b=」) b=: このオプション[OPTIONAL]のフィールドは、セッションまたはメディアで使 用する帯域の提案を指定する。は英数字の修飾子であり、 の意味を指定する。2つの値が本仕様で定義されているが、その 他の値を将来的に登録してもよい[MAY](セクション8と[21]、[25]を参照)。 セッションまたはセッション内のメディアの帯域が、スコープの暗黙的な帯 域と異なる場合、使用する帯域の上限案を指定するセッションには、 「b=CT:...」行を指定すべきである[SHOULD]。この主な目的は、2つ以上 のセッションが同時に共存できるかどうかについて、適切なアイデアを 提供することである。CT修飾子をRTPと共に使用するときに、いくつか のRTPセッションがカンファレンスの一部である場合、カンファレンス全 体は、RTPセッションの総帯域を参照する。 帯域は、アプリケーション固有のものに変換される。つまり、アプリケー ションの最大帯域の概念である。一般的に、これは、(適用可能な場合) アプリケーションの「最大帯域」制御に関する設定と一致する。RTPベー スのアプリケーションでは、[19]のセクション6.2で定義されているよ うに、ASがRTPの「セッション帯域」が指定する。 CTでは、すべてのサイトにあるすべてのメディアに関する総帯域の桁を指定 するという点に注意すること。ASでは、同時に複数サイトの送信がある場合 でも、1つのサイトにおける1つのメディアに関する帯域幅の桁数を指定す る。 接頭辞「X-」が名のために定義されている。これは、実験目的にの み使用することができる。例: b=X-YZ:128 Handley, et al. Standards Track [Page 16] RFC 4566 SDP July 2006 「X-」接頭辞の使用は推奨されない[NOT RECOMMENDED]。代わりに、標準の 名前空間でIANAに新しい修飾子を登録すべきである[SHOULD]。SDPパーサー は、未知の修飾子が含まれる帯域フィールドを無視しなければならな い[MUST]。修飾子は、英数字にしなければならない[MUST]。また、長さの制 限がない場合でも、短くすることが推奨される。 は、デフォルトでキロビット/秒と解釈される。新しい 修飾子の定義で、その他の単位で帯域を解釈するように指定してもよい[MAY] (本文書で定義されている「CT」と「AS」修飾子はデフォルトの単位を使用 する)。 5.9. タイミング(「t=」) t= 「t=」行は、セッションの開始時間と終了時間を指定する。 不定期に複数回の間隔を置いてセッションがアクティブになる場合、複数 の「t=」行を使用してもよい[MAY]。追加の各「t=」行で、セッションが アクティブになる各期間を指定する。セッションが規則正しい時間にアク ティブになる場合、「t=」行とは別に、続けて「r=」行(後述参照)を使用す べきである。この場合、「t=」行では、繰り返しシーケンスの開始時間と停 止時間を指定する。 最初と2つ目のサブフィールドで、それぞれセッションの開始時間と終了時 間を指定する。この値は、1900年以降のNTP (Network Time Protocol)時間 値(秒単位)を10進表記したものである[1900]。この値をUNIX時間に変換する には、10進の2208988800を引く。 それ以外の場合、NTPタイムスタンプは64ビット値で表記され、2036年のあ る時間でラップする。SDPでは任意長の10進表記を使用するため、これで問 題が発生することはない(SDPタイムスタンプは、1900年以降の秒数をカウン トし続けなければならない[MUST]ため、NTPは64ビット制限を法(modulo)と する値を使用する)。 をゼロに設定すると、セッションに制約はないが、 後になるまでアクティブにならない。もゼロの場合、セッショ ンは永続すると見なされる。 制約なしのセッションおよび永続的なセッションを作成するユーザーイン ターフェースは、避けるべきである[SHOULD]。これは、セッションが実際に 終了する時間に関する情報が与えられず、予定が困難になるためである。 ユーザーに対して、有効期限切れが指定されていない制限なしのセッション を表示する場合、一般的な推測は可能である。制限なしのセッションは、 現在の時間またはセッションの開始時間のうち遅い時点から30分までのみ、 Handley, et al. Standards Track [Page 17] RFC 4566 SDP July 2006 アクティブである、という推測である。これ以外の動作が必要な場合、セッ ションが実際に終了する時間に関して新たな情報が入手できたときに、必要 に応じて終了時間を指定または修正すべきである[SHOULD]。 永続的なセッションは、ユーザーに提示してもよい。これは、関連付けられ た繰り返し回数(セッションをアクティブにするタイミングの正確な指定)が なければ、アクティブにならないためである。 5.10. 繰り返し回数(「r=」) r= 「r=」フィールドは、セッションの繰り返し回数を指定する。たとえば、 セッションが、3か月の間、毎週月曜日と火曜日の午前10時に、1時間アク ティブになる場合、関連する「t=」フィールドのは最初の月曜 日の午前10を表すNTP、は1週間、は1 時間、オフセットはゼロと25時間になる。対応する「t=」フィールドの終了 時間は、最終セッションである3か月後の終了時間のNTP表記になる。デフォ ルトで、すべてのフィールドは秒単位である。そのため、「r=」と「t=」 フィールドは次のようになる。 t=3034423619 3042462419 r=604800 3600 0 90000 記述をよりコンパクトにするために、時間の単位を日数、時間数、分数にす ることもできる。この構文は、数字の後に1文字を指定する。この文字は、 大文字と小文字が区別される。 補助単位(fractional unit)は許容されていない。代わりに小さな単位を使 用すべきである。次の単位仕様文字が許容されている。 d - 日数単位(86400秒) h - 時間数単位(3600秒) m - 分数単位(60秒) s - 秒数単位(網羅するために考慮されている) したがって上記のセッション告知は、次のように記述することができる。 r=7d 1h 0 25h 月単位および年単位の繰り返しは、1つのSDP繰り返し回数で直接指定するこ とはできない。代わりに、「t=」フィールドとは別のフィールドをセッショ ン回数を明示的に列挙するときに使用すべきである。 Handley, et al. Standards Track [Page 18] RFC 4566 SDP July 2006 5.11. タイムゾーン(「z=」) z= .... サマータイムから標準時間への切り替え期間またはその逆をはさむ期間の場 合に、セッションの予定を立てるには、基本の回数からのオフセットを指定 する必要がある。これは、タイムゾーンによって日時が変わり、国によって サマータイムかどうかが変わり、サマータイム制度がない国もあるためで ある。 したがって、冬と夏の同じ時間にセッションの予定を立てるには、セッショ ンの予定を立てたタイムゾーンを明確に指定できる必要がある。受信側の このタスクを単純にするために、本文書では、送信側がタイムゾーンの調整 が発生するNTP時間と、最初にセッションを予定した時点からのオフセット を指定できるようにした。送信側は、「z=」フィールドを使用して、この調 整時間の一覧と、基本時間からのオフセットをを指定できる。 例は次のようになる。 z=2882844526 -1h 2898848070 0 これによって、時間2882844526に、セッションの繰り返し回数を計算する基 本時間が1時間シフトが戻され、時間2898848070に、セッションの元の時間 ベースが復元される。調整は、指定した開始時間に常に相対的であり、蓄積 されない。調整は、セッション記述の「t=」行と「r=」行すべてに適用さ れる。 セッションが数年間続く場合、1つのセッション告知で数年に値する調整を 送信するのではなく、セッション告知を定期的に修正することが予想され る。 5.12. 暗号化キー(「k=」) k= k=: 安全で信頼できるチャネルで伝送する場合、セッション記述プロトコルを使 用して暗号化キーを伝達してもよい[MAY]。キー交換の単純なメカニズムと して、キーフィールド(「k=」)が用意されているが、主にこれは古い実装と の互換性のためにサポートされているため、使用は推奨されない [NOT RECOMMENDED]。SDPと併用するための新しいキー交換メカニズムの定義 は研究中であり[27] [28]、新しいアプリケーションではそのメカニズムを 使用することが期待される。 Handley, et al. Standards Track [Page 19] RFC 4566 SDP July 2006 キーフィールドは、必要に応じて、最初のメディアエントリの前(この場合は セッション内の全メディアに適用される)、または各メディアエントリに許容 されている。キーの形式とキーの用法は、本文書の範囲外である。また、 キーフィールドに、使用する暗号化アルゴリズム、キーの種類、またはキー に関するその他の情報を示す機能はない。このような情報は、SDPを使用する より高階層のプロトコルで提供されると想定されている。このような情報を SDP内で伝達する必要がある場合、前述した拡張を使用すべきである [SHOULD]。多くのセキュリティプロトコルでは2つのキーを必要とする。1つ は機密保護のためのキー、もう1つは完全性のためのキーである。本仕様 では、2つのキーの転送をサポートしていない。 この方法は、外部的な手段、またはエンコードされた暗号化キーがあればそ こから、使用できるキーを取得するときに使用されるメカニズムを示す。次 のメソッドが定義される。 k=clear: 暗号化キーは、このキーフィールドに変更しないで含める。 この方法は、SDPが安全なチャネルで伝達されると保証可能な場合を 除き、使用してはならない[MUST NOT]。暗号化キーは、charset属性 に従ってテキストとして解釈されるため、"k=base64:"メソッドを使 用して文字を伝達すること(それ以外の場合、この文字はSDPで禁止さ れている)。 k=base64: 暗号化キーは、このキーフィールドに含まれるが、SDPで禁止されて いる文字を含むため、base64でエンコードされている[12]。この方 法は、SDPが安全なチャネルで伝達されると保証可能な場合を除き、 使用してはならない[MUST NOT]。 k=uri: URI (Uniform Resource Identifier)がキーフィールドに含まれる。 このURIはキーを含むデータを参照し、キーが返ってくる前に追加で 認証が必要な場合もある。指定のURIに対してリクエストが送信され た場合、応答ではキーのエンコーディングを指定すべきである。こ のURIはSecure Socket Layer/Transport Layer Security (SSL/TLS) で保護されたHTTP URI(「https:」)の場合もあるが、必須ではない。 k=prompt このSDP記述にはキーが含まれないが、このキーフィールドが参照す るセッションまたはメディアストリームは暗号化される。ユーザーが セッションに参加しようとすると、キーの入力が要求されるべきであ る。また、このユーザーが入力したキーは、メディアストリームの復 Handley, et al. Standards Track [Page 20] RFC 4566 SDP July 2006 号に使用されるべきである。ユーザー指定したキーの使用は、セキュ リティが弱いという特性を持つ傾向があるため、推奨されない [NOT RECOMMENDED]。 このキーフィールドは、SDPが安全で信頼できるチャネルで伝達されると保証 可能な場合を除き、使用してはならない[MUST NOT]。このようなチャネルの 一例としては、S/MIMEメッセージまたはTLSで保護されたHTTPセッション内に SDPを組み込む方法がある。安全なチャネルが、仲介パーティではなく、セッ ションに参加する権限を持つパーティにあるようにすることが重要である。 キャッシュするプロキシサーバーを使用する場合、プロキシが信頼されてい るか、プロキシがSDPにアクセスできないようにすることが重要である。 5.13. 属性(「a=」) a= a=: 属性は、SDPを拡張するための主な手段である。「セッションレベル」属性、 「メディアレベル」属性、またはその両方に使用する属性を定義できる。 メディア記述には、メディア固有の属性(「a=」フィールド)を複数指定して もよい。これは、「メディアレベル」属性と呼ばれ、メディアストリームに 関する情報が追加される。属性フィールドは、最初のメディアフィールドの 前に追加することもできる。この「セッションレベル」属性は、個々の メディアではなく、カンファレンス全体に適用する追加情報を伝達する。 属性フィールドには2つの形式が考えられる。 o 特性の属性は、単純に「a=<フラグ>」という形式を持つ。これはバイナリ 属性であり、この属性を示すと、この属性がセッションのプロパティで あることが伝達される。一例を挙げると、「a=recvonly」。 o 値の属性は、「a=<属性>:<値>」という形式を持つ。一例を挙げると、 ホワイトボードが「a=orient:landscape」という値属性を持つ場合など。 属性の解釈は、呼び出されるメディアツールによって変わる。 したがってセッション記述の受信側は、一般的なセッション記述の解釈と特 定の属性の解釈とを設定できるようにすべきである。 属性名は、ISO-10646/UTF-8のサブセットであるUS-ASCIIの文字を使用しな ければならない[MUST]。 Handley, et al. Standards Track [Page 21] RFC 4566 SDP July 2006 属性値はオクテット文字列であり、 0x00 (Nul)、0x0A (LF)、および0x0D (CR)以外の任意のオクテットを使用してもよい[MAY]。デフォルトで、属性 値は、UTF-8エンコーディングのISO-10646文字セットに含まれると解釈すべ きである。他のテキストフィールドとは異なり、属性値は、「charset」属 性に影響を受けない[NOT]。これは、既知の値に対する比較の問題になるた めである。ただし、属性を定義するときに、文字セット依存に定義すること ができる。この場合、値は、ISO-10646ではなくセッションの文字セットで 解釈すべきである。 属性は、IANAで登録しなければならない[MUST](セクション8参照)。理解で きない属性を受信した場合、受信側は無視しなければならない[MUST]。 5.14. メディア記述(「m=」) m= ... セッション記述には、複数のメディア記述を含めることができる。 各メディア記述は「m=」フィールドで始まり、次の「m=」フィールドまたは セッション記述の末尾で終了する。メディアフィールドには、複数のサブ フィールドが含まれる。 はメディアタイプである。現在定義されているメディアは、 「audio」、「video」、「text」、「application」、「message」だが、 このリストは将来的に拡張される可能性がある(セクション8参照)。 は、メディアストリームを送信するトランスポートポートである。 トランスポートポートの意味は、関連する「c=」フィールドで指定され ているように、使用するネットワークによって変わる。また、メディア フィールドのサブフィールドで定義されるトランスポートプロト コルによっても変わる。メディアアプリケーションで使用するその他の ポート(RTP Control Protocol (RTCP)ポート[19]など)は、基本のメディ アポートからアルゴリズム的に取得してもよい[MAY]。または、別の属性 ([22]で定義されているように、「a=rtcp:」など)で指定してもよ い[MAY]。 隣接していないポートが使用される場合、または偶数のRTPポートと奇数 のRTCPポートというパリティ規則に従わない場合、「a=rtcp」属性を使 用しなければならない[MUST]。アプリケーションが、奇数のに メディアを送信するようにリクエストされ、「a=rtcp:」が存在する場 合、RTPポートから1を差し引いてはならない[MUST NOT]。つまり、RTPは で指定されたポートに送信し、RTCPは「a=rtcp」属性で指定され たポートに送信しなければならない[MUST]。 階層的にエンコードしたストリームがユニキャストアドレスに送信される 場合、アプリケーションは複数のトランスポートポート指定が必要な場合も ある。この場合、「c=」フィールドのIPマルチキャストアドレスと同様の表 記方法を使用する。 Handley, et al. Standards Track [Page 22] RFC 4566 SDP July 2006 m= / ... このような場合、使用ポートはトランスポートプロトコルによって変わ る。RTPの場合、デフォルトは、データには偶数のポートのみが使用さ れ、そのRTPセッションに所属するRTCPには、対応する1つ上の奇数ポート が使用される。は、RTPセッションの数を示す。例: m=video 49170/2 RTP/AVP 31 これは、ポート49170と49171のが1つ目のRTP/RTCPペアを構成し、49172と 49173が2つ目のRTP/RTCPペアを構成することを示す。RTP/AVPはトランス ポートプロトコルであり、31は形式である(以下を参照)。隣接していな いポートが必要な場合、異なる属性を使用してシグナルする必要がある (たとえば、[22]で定義されているように「a=rtcp:」など)。 複数のアドレスを「c=」フィールドで指定し、複数のポートを「m=」 フィールドで指定する場合、ポートと対応するアドレスに関する1対1の マッピングが暗示される。例: c=IN IP4 224.2.1.1/127/2 m=video 49170/2 RTP/AVP 31 これは、224.2.1.1はポート49170と49171と共に使用され、アドレス 224.2.1.2はポート49172と49173と共に使用されることが暗示される。 同じトランスポートアドレスを使用した複数の「m=」行のセマンティクス は定義されていない。つまり、制約された過去の慣例とは異なり、この ような手段で定義された暗黙的なグルーピング方法はないため、明示的 なグルーピングの枠組み(たとえば[18])を代わりに使用して目的のセマ ンティクスを表すべきである。 はトランスポートプロトコルである。トランスポートプロトコルの 意味は、関連する「c=」フィールドのアドレスタイプフィールドによっ て変わる。したがって、IP4の「c=」フィールドは、トランスポートプロ トコルがIP4上で実行されていることを示す。次のトランスポートプロト コルが定義されている。ただし、IANAで新しいプロトコルが登録されて 拡張される可能性がある(セクション8参照)。 * udp: UDP上で実行されている、特定されていないプロトコルを示す。 * RTP/AVP: UDP上で実行されている、「RTP Profile for Audio and Video Conferences with Minimal Control」[20]の下で使用されてい るRTP [19]を示す。 * RTP/SAVP: UDP上で実行されている、Secure Real-time Transport Protocol [23]を示す。 Handley, et al. Standards Track [Page 23] RFC 4566 SDP July 2006 メディア形式とは別にトランスポートプロトコルを指定する主な理由は、 ネットワークプロトコルが同じ場合でも、異なるトランスポートプロト コル上で同じ標準のメディア形式が伝達される可能性があるためである。 従来の例を挙げると、vat Pulse Code Modulation (PCM)音声やRTP PCM 音声がある。その他に、TCP/RTP PCM音声も考えられる。さらに、トラン スポートプロトコル固有だが、形式には非依存のリレーツールと監視 ツールが考えられる。 はメディア形式の説明である。第4以降のサブフィールドは、メディア の形式を記述する。メディア形式の解釈は、サブフィールドの値 によって変わる。 サブフィールドが「RTP/AVP」または「RTP/SAVP」の場合、 サブフィールドにはRTPペイロードタイプ番号が含まれる。ペイロードタ イプ番号の一覧が指定される場合、そのペイロード形式すべてをその セッションで使用してもよい[MAY]ことを意味するが、セッションの デフォルト形式としてリストの最初にある形式を使用すべきである [SHOULD]。動的なペイロードタイプ割り当ての場合、「a=rtpmap:」属 性(セクション6参照)を使用して、RTPペイロードタイプ番号から、ペイ ロード形式を特定するメディアエンコード名へとマップすべきであ る[SHOULD]。「a=fmtp:」属性を使用して、形式のパラメータを指定して もよい[MAY](セクション6)。 サブフィールドが「udp」の場合、サブフィールドは、トッ プレベルのメディアタイプ「audio」、「video」、「text」、 「application」、「message」の下で形式を記述するメディアタイプを 参照しなければならない[MUST]。メディアタイプの登録は、UDPトラン スポートと共に使用するパケット形式を定義すべきである[SHOULD]。 他のトランスポートプロトコルを使用するメディアの場合、フィー ルドはプロトコル固有である。新しいプロトコルを登録する場合、 サブフィールドを解釈する規則を定義しなければならない[MUST](セク ション8.2.2参照)。 6. SDP属性 次の属性が定義される。アプリケーションの作成者は必要に応じて新しい属 性を追加してもよいため、この一覧がすべてではない。 新しい属性の登録手続きは、セクション8.2.4で定義されている。 a=cat: この属性は、ドットで区切った、セッションの階層的なカテゴリで ある。用途は、受信側がカテゴリを使用して不要なセッションをフィ ルタするためである。カテゴリには中央の登録場所はない。セッショ ンレベル属性であり、文字セットに依存しない。 Handley, et al. Standards Track [Page 24] RFC 4566 SDP July 2006 a=keywds: cat属性と同様に、これは受信側が必要なセッションを特定するとき の補助として使用する属性である。これによって、受信側は、セッ ションの目的を記述したキーワードに基づいて、関心のあるセッショ ンを選択することができる。キーワードには中央の登録場所はない。 セッションレベルの属性である。この属性は文字セットに依存する。 つまり、この属性値は、セッション記述で文字セットが指定されてい る場合はその文字セットで解釈し、それ以外の場合はデフォルトのISO 10646/UTF-8で解釈すべきである。 a=tool: この属性は、セッション記述を作成するときに使用したツールの名前 とバージョン番号を指定する。セッションレベル属性であり、文字 セットに依存しない。 a=ptime: この属性は、パケット内のメディアが表す時間の長さをミリ秒単位で 指定する。この属性は、音声データの場合にのみ意味があるが、有用 であれば他のメディアタイプで使用してもよい。RTPまたはvat音声を デコードするときにptimeを知る必要はない。この属性は、音声のエン コーディング/パケット化に関する推奨として使用するためのもので ある。メディアレベル属性であり、文字セットに依存しない。 a=maxptime: 各パケットでカプセル化することができるメディアの総量。ミリ秒単 位の時間として表される。この時間は、パケット内に存在するメディ アの合計時間数として計算すべきである[SHALL]。フレームベース のコーデックの場合、この時間は、フレームサイズの倍数(整数)にす べきである[SHOULD]。この属性は、音声データの場合にのみ意味があ るが、有用であれば他のメディアタイプで使用してもよい。メディア レベル属性であり、文字セットに依存しない。この属性はRFC 2327以 降に導入されたということに注意。古い実装の場合、この属性は無視 される。 a=rtpmap: / [/] この属性は、RTPペイロードタイプ番号から、使用するペイロード形 式を示すエンコーディング名へとマップする。また、クロックレート とエンコーディングパラメータに関する情報も指定する。メディアレ ベル属性であり、文字セットに依存しない。 Handley, et al. Standards Track [Page 25] RFC 4566 SDP July 2006 RTPプロファイルで、ペイロードタイプ番号の静的な割り当てをペイ ロード形式にしてもよいが、「a=rtpmap:」属性を使用して動的に割 り当てを実行する方が一般的である。静的ペイロードタイプの一例を 挙げると、8 kHzでサンプリングされたu-law PCMコーディングの単一 チャネル音声がある。これは、RTP Audio/Videoプロファイルでペイ ロードタイプ0であると完全に定義される。そのため、「a=rtpmap:」 属性を使用する必要はない。また、UDPポート49232にこのようなス トリームが送信される場合、メディアは次のように指定することがで きる。 m=audio 49232 RTP/AVP 0 動的なペイロードタイプの一例を挙げると、16kHzでサンプリングされ た、16ビットリニアエンコーディングのステレオ音声がある。このス トリームに動的なRTP/AVPペイロードタイプ98を使用する場合、それ を示すために追加の情報が必要である。 m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 指定するメディア形式ごとに、最大でも1つのrtpmap属性しか定義で きない。したがって、次のように指定する。 m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 動的ペイロードタイプの使用を指定するRTPプロファイルで、そのプロ ファイルをSDPと共に使用する場合、有効なエンコーディング名とエン コーディング名を登録する手段の両方または片方を定義しなければな らない[MUST]。「RTP/AVP」と「RTP/SAVP」の各プロファイルは、 「m=」行で示されるトップレベルのメディアタイプの下で、エンコー ディング名のメディアサブタイプを使用する。上記の例では、この メディアタイプが「audio/l8」と「audio/l16」になる。 音声ストリームの場合、は、音声チャネルの 数を示す。このパラメータはオプション[OPTIONAL]であり、チャネル 数が1で、追加のパラメータが必要ない場合は省略してもよい。 ビデオストリームの場合、エンコーディングパラメータは現在のとこ ろ指定されていない。 将来的に、追加のエンコーディングパラメータを定義してもよい [MAY]。ただし、コーデック固有のパラメータは追加すべきではない [SHOULD NOT]。「a=rtpmap:」属性にパラメータを追加する場合、 セッションに参加する適切なメディアを選択するときに、セッション ディレクトリに必要なものにすべきである[SHOULD]。コーデック固有 Handley, et al. Standards Track [Page 26] RFC 4566 SDP July 2006 のパラメータは、他の属性(「a=fmtp:」など)で追加すべきである。 注意: RTP音声形式には、一般的に、パケットごとのサンプル数に関 する情報は含まれない。デフォルト以外(RTP Audio/Video Profileの 定義による)のパケット化が必要な場合、「ptime」属性を前述のよう に使用する。 a=recvonly 適用可能な場合には、受信のみのモードでツールを起動すべきであ る、ということを指定する。セッションレベル属性とメディアレベル 属性のどちらも可能であり、文字セットに依存しない。recvonlyは メディアにのみ適用され、関連する制御プロトコルには適用されない ということに注意(たとえば、recvonlyモードのRTPベースシステム でも、RTCPパケットを送信すべきである[SHOULD])。 a=sendrecv 送受信モードでツールを起動すべきである、ということを指定する。 この属性が必要なのは、受信のみのモードがデフォルトのツールと、 対話式のカンファレンスを行う場合である。セッションレベル属性と メディアレベル属性のどちらも可能であり、文字セットに依存しない。 「sendonly」、「recvonly」、「inactive」、「sendrecv」のどの属 性も存在しない場合、カンファレンスタイプが「broadcast」または 「H332」でないセッションには、「sendrecv」をデフォルトと仮定す べきである[SHOULD](以下を参照)。 a=sendonly 送信のみのモードでツールを起動すべきである、ということを指定 する。例としては、異なるユニキャストアドレスをトラフィックの ソースではなくトラフィックの送信先に使用する場合が考えられる。 このような場合、2つのメディア記述を使用し、1つはsendonlyにし、 もう1つはrecvonlyにする。セッションレベル属性とメディアレベル 属性のどちらも可能だが、通常はメディア属性としてのみ使用され る。文字セットには依存しない。sendonlyはメディアのみに適用され るため、関連する制御プロトコル(RTCPなど)は通常どおり受信され、 処理されるべきである[SHOULD]ということに注意。 a=inactive 非アクティブモードでツールを起動すべきである、ということを指定 する。これが必要なのは、対話式カンファレンスで、ユーザーが別の ユーザーを保留する場合である。inactiveのメディアストリームで Handley, et al. Standards Track [Page 27] RFC 4566 SDP July 2006 は、メディアが送信されない。RTPベースのシステムは、inactiveで 起動した場合でも、RTCPを送信すべきである[SHOULD]ということに 注意。セッションレベル属性とメディアレベル属性のどちらも可能で あり、文字セットに依存しない。 a=orient: 通常、ホワイトボードツールまたはプレゼンテーションツールにのみ 使用される。画面上の作業スペースの向きを指定する。メディアレベ ルの属性である。使用できる値は、「portrait」、「landscape」、 「seascape」(landscape (横長)の上下反対)。文字セットには依存し ない。 a=type: カンファレンスの種類を指定する。提案されている値は 「broadcast」、「meeting」、「moderated」、「test」、「H332」 である。「type:broadcast」セッションの場合、「recvonly」を デフォルトにすべきである。「type:meeting」は「sendrecv」を暗示 すべきである。「type:moderated」は、フロア制御ツールの使用を 示し、さらにカンファレンスに参加する新しいサイトをミュートする ようにメディアツールを起動することを示すべきである。 「type:H332」属性を示す場合、ITU H.332仕様[26]の定義どおり、こ の疎結合のセッションがH.332セッションの一部であることを示す。 メディアツールは「recvonly」で起動すべきである。 「type:test」属性を指定する場合、明示的にリクエストされていな ければ、受信側がこのセッション記述をユーザーに表示するのを防ぐ ことができることを示す。 type属性はセッションレベル属性であり、文字セットに依存しない。 a=charset: セッション名と情報を表示するときに使用する文字セットを指定す る。デフォルトで、UTF-8エンコーディングで設定されたISO-10646文 字が使用される。よりコンパクトな表記が必要な場合、別の文字セッ トを使用してもよい。 たとえば、次のSDP属性ではISO 8859-1が指定されている。 a=charset:ISO-8859-1 Handley, et al. Standards Track [Page 28] RFC 4566 SDP July 2006 これはセッションレベル属性であり、文字セットに依存しない。指定 する文字セットは、ISO-8859-1など、IANAに登録されているものでな ければならない[MUST]。文字セットの識別子はUS-ASCII文字列であ り、大文字と小文字を区別する比較方法で、IANAの識別子と比較しな ければならない[MUST]。識別子を認識できない場合、またはサポート していない場合、その識別子の影響を受ける文字列はすべてオクテッ ト文字列として扱うべきである[SHOULD]。 指定する文字セットに、0x00 (Nul)、0x0A (LF)、および0x0d (CR)を 使用することは禁止しなければならない[MUST]ということに注意。文 字セットでこれらの文字を使用する必要がある場合、これらのバイト がテキストフィールドに表示されないように引用メカニズムを定義し なければならない[MUST]。 a=sdplang: セッションレベル属性とメディアレベル属性のどちらも可能である。 セッションレベル属性としては、セッション記述の言語を指定する。 メディアレベル属性としては、このメディアと関連するメディアレベ ルの任意のSDP情報フィールドについて、言語を指定する。セッショ ン記述で複数の言語を使用する場合、またはメディアで複数の言語を 使用する場合、セッションレベルまたはメディアレベルで、複数の sdplangを指定することができる。この場合、属性の順序は、セッショ ンまたはメディア内の言語の重要度を示す。最重要の言語から重要度 が低い言語の順である。 一般的に、複数言語で構成されたセッション記述を送信することは推 奨されていない。そうではなく、1つのセッションで1つの言語を記述 して、複数の記述を送信すべきである[SHOULD]。 ただし、この方法はどのトランスポートメカニズムでも可能ではな い。そのため、複数のsdplang属性は許容されているが、推奨されて いない[NOT RECOMMENDED]。 「sdplang」属性値は、US-ASCIIで記載した、単一のRFC 3066言語タグ にしなければならない[9]。文字セット属性には依存しない。受信者の 言語を想定できない場合、またはセッションがローカルで想定した標 準とは異なる言語で行われる場合、セッションの範囲がそのように 地理的境界を越えるときには、「sdplang」属性を指定すべきであ る[SHOULD]。 a=lang: セッションレベル属性とメディアレベル属性のどちらも可能である。 セッションレベル属性としては、記述するセッションのデフォルト言 語を指定する。メディアレベル属性としては、そのメディアの言語を 指定する。セッションレベル言語が指定されている場合、メディアレ Handley, et al. Standards Track [Page 29] RFC 4566 SDP July 2006 ベル属性の方が優先される。セッション記述またはメディアで複数言 語を使用する場合、セッション記述またはメディアで複数の言語を使 用することができる。この場合、属性の順序は、セッションまたは メディア内の言語の重要度を示す。最重要の言語から重要度が低い言 語の順である。 「lang」属性値は、US-ASCIIで記載した、単一のRFC 3066言語タグに しなければならない[9]。文字セット属性には依存しない。受信者の言 語を想定できない場合、またはセッションがローカルで想定した標準 とは異なる言語で行われる場合、セッションの範囲がそのように地理 的境界を越えるときには、「lang」属性を指定すべきである[SHOULD]。 a=framerate: フレーム/秒単位で最大のビデオフレームレートを指定する。ビデオ データのエンコーディングに関する推奨として使用するためのもので ある。「<整数部>.<小数部>」という表記方法を使用して、十進の小 数値を表記することができる。メディアレベル属性であり、ビデオメ ディア用にのみ定義されている。文字セットには依存しない。 a=quality: 整数値で、エンコーディングの品質に関する推奨を示す。ビデオの 場合、quality属性の用途は、フレームレートと静止画の品質に関し て、デフォルトではないトレードオフを指定することである。ビデオ の場合、0〜10の範囲の値があり、次の意味が提案される。 10 - 圧縮スキームで指定できる最高の静止画像品質。 5 - 品質に関して何も提案しないデフォルトの動作。 0 - コーデック設計者が想定する最低の静止画像品質も使用する ことができる。 メディアレベル属性であり、文字セットに依存しない。 a=fmtp: この属性は、SDPが理解する必要のない方法で伝達される、特定の形式 に固有のパラメータを許容する。この形式は、メディアに指定された 形式の1つでなければならない。形式固有のパラメータは、この形式を 使用するメディアツールに変更がなければ、SDPが伝達する必要がある Handley, et al. Standards Track [Page 30] RFC 4566 SDP July 2006 任意のパラメータでもよい。1つの形式ごとに、この属性の1インスタ ンスのみが許容されている。 メディアレベル属性であり、文字セットに依存しない。 7. セキュリティの考慮事項 SDPは、ユニキャストセッションのパラメータについて合意するときに、 オファー/アンサーモデル[17]を利用するセッション開始プロトコル(Session Initiation Protocol/SIP)[15]と併用されることが多い。この方法で使用さ れる場合、これらのプロトコルにおけるセキュリティの考慮事項が適用さ れる。 SDPは、マルチメディアセッションを記述するセッション記述形式である。 SDPメッセージを受信し、メッセージに従って動作するエンティティは、既知 のソースまたは信頼済みソースから認証済みトランスポートプロトコルに よって取得した場合を除き、セッション記述を信頼できないということに注 意すべきである[SHOULD]。セッション記述を配信する場合、多彩なトランス ポートプロトコルが使用される可能性があり、認証の性質は、トランスポー トによって異なる。トランスポートによっては、セキュリティ機能が配備さ れていないことがよくある。信頼できる方法でセッション記述を取得しな かった場合、考えられる攻撃の中でも特に、受信したメディアセッションは 意図したものではない可能性、メディアを送信する宛て先が予想されるもの ではない可能性、セッションパラメータのいずれかが正しくない可能性、 メディアのセキュリティが危うくなる可能性があるため、エンドポイントは 注意すべきである[SHOULD]。 アプリケーションとユーザー設定のセキュリティリスクを考慮して適切な判 断を下すことは、エンドポイントに委ねられる。また、セッションを受け入 れるかどうかをユーザーに尋ねることもできる。 セッション記述を配信するときに使用できるトランスポートの1つに、セッ ション告知プロトコル(Session Announcement Protocol/SAP)がある。SAPは 暗号化と認証の両メカニズムを備えているが、セッション告知の性質から、 セッション告知の送信元を認証できない場合が多く発生する傾向がある。こ の原因は、告知の受信者が送信元を事前に知らないため、および利用できる 共通のパブリックキーインフラストラクチャがないためである。 認証されていないトランスポートメカニズム上で、または信頼されていな いパーティから、セッション記述を受信した場合、セッションを解析する ソフトウェアが注意すべき事項がいくつかある。セッション記述には、受信 側システムのソフトウェアを起動するときに必要な情報が含まれる。 セッション記述を解析するソフトウェアは、マルチメディアセッションに参 加する適切なソフトウェアとして明示的に設定されている場合を除き、他の ソフトウェアを起動する機能を持ってはならない[MUST NOT]。通常、セッ ション記述を解析するソフトウェアが、ユーザーのシステムで、マルチ Handley, et al. Standards Track [Page 31] RFC 4566 SDP July 2006 メディアセッションに参加するのが適切なソフトウェアを起動することは不 適切と考えられている。ただし、ソフトウェアの起動をユーザーに通知し、 ユーザーの同意を得た場合は除く。したがって、セッション告知、電子メー ル、セッションの招待、またはWWWページによって受信したセッション記述 では、ユーザーが明示的に事前認可していなければ、ユーザーを対話式のマ ルチメディアセッションに参加させてはならない[MUST NOT]。セッションが 対話式かどうかを区別するのは必ずしも簡単とは限らないため、アプリケー ションで判断できない場合、セッションは対話式であると仮定すべきである。 本仕様では、送信がデフォルトのモードでマルチメディアツールを起動する ことを、セッション記述の受信者に対して通知できる属性はない。環境に よっては、このような属性を定義するのが適切な場合もある。この場合、そ のような属性を含むセッション記述を解析したアプリケーションは、その属 性を無視するか、ユーザーに対して、このセッションに参加するとマルチメ ディアデータが自動的に送信されるということを通知すべきである [SHOULD]。未知の属性に対するデフォルトの動作は、無視することである。 環境によっては、他のシグナリングプロトコルに含まれるセッション記述を 中間システムが傍受および分析する方法が一般的になる。これは幅広い目的 で実行される。たとえば、ファイアウォールに穴をを開けてメディアスト リームを通過させたり、特定のトラフィックに印を付けたり、優先順位を付 けたり、ブロックしたり、などの操作である。場合によっては、こうした中 間システムがセッション記述を修正することがある。たとえば、セッション 記述の内容を動的に作成されたNATバインディングと一致させる場合などで ある。中間システムが適切なチェックを実行でき、ソースの権限保持者がこ うした通信セッションを確立できる方法でセッション記述が伝達される場合 を除き、この動作は推奨されない[NOT RECOMMENDED]。 SDP自体には、このようなチェックを実行するために必要な情報が含まれな い。これはカプセル化しているプロトコル(SIPまたはRTCPなど)に依存して いる。 「k=」フィールドを使用すると、セッションの暗号化キーが平文で伝達され るため、セキュリティ上の重大なリスクにつながる。SDPを配信するチャネ ルがプライベートかつ認証済みであることを保証できる場合を除き、キーの 素材を伝達するときにSDPを使用してはならない[MUST NOT]。 さらに、「k=」行は、暗号化キーアルゴリズムを示したり、ネゴシエートし たりする方法にはならない。「k=」行は機密保護と完全性保護のために別個 のキーではなく、単一の対称キーを提供するのみのため、用途はごく限られ ている。セクション5.12で説明したように、「k=」行の使用は推奨されな い[NOT RECOMMENDED]。 Handley, et al. Standards Track [Page 32] RFC 4566 SDP July 2006 8. IANA条項 8.1. "application/sdp"メディアタイプ RFC 2327の1つのメディアタイプ登録が、以下の定義のように更新される。 宛先: ietf-types@iana.org 件名: MIMEメディアタイプ「application/sdp」の登録 タイプ名: application サブタイプ名: sdp 必須のパラメータ: なし。 オプションのパラメータ: なし。 エンコーディングの考慮: SDPファイルは、主にUTF-8形式のテキストである。「a=charset:」属 性は、SDPファイルの一部で、他の文字セットが存在することをシグ ナリングするときに使用することができる(RFC 4566のセクション6を 参照)。任意のバイナリコンテンツをSDPで直接表すことはできない。 セキュリティの考慮: RFC 4566のセクション7を参照 相互運用性の考慮: RFC 4566を参照 発行済みの仕様: RFC 4566を参照 このメディアタイプを使用するアプリケーション: VoIP、ビデオ通信、ストリーミングメディア、インスタントメッセー ジなど。RFC 4566のセクション3も参照。 補足情報: マジックナンバー: なし。 ファイルの拡張子: 拡張子「.sdp」が一般的に使用される。 Macintoshファイルタイプコード: 「sdp」 より詳しい情報についての連絡先窓口とe-mailアドレス: Mark Handley Colin Perkins IETF MMUSIC working group Handley, et al. Standards Track [Page 33] RFC 4566 SDP July 2006 用途: 汎用(COMMON) 著者/改版管理者: IESGを代表する、RFC 4566 IETF MMUSICワーキンググループの著者達 8.2. パラメータの登録 IANAに登録されるフィールド名が7つある。これは、SDP仕様のBNF (Backus- Naur Form)における用語を使用すると、「media」、「proto」、「fmt」、 「att-field」、「bwtype」、「nettype」、「addrtype」である。 8.2.1. メディアタイプ(「media」) メディアタイプのセットは小さくする意図があるため、ごく一部の例外を 除き、拡張すべきではない[SHOULD NOT]。トップレベルのメディアコンテン ツタイプに関して、メディア名にも同じ規則を適用すべきである。また、可 能な限り、MIMEと同じ名前をSDPに登録すべきである。既存のメディアトッ プレベルのコンテンツタイプ以外のメディアについては、トップレベルのコ ンテンツタイプを新たに登録する標準化過程のRFCを作成しなければならな い[MUST]。また、登録時に、既存のメディア名は適切ではない正当な理由を 示さなければならない[MUST](RFC 2434 [8]の「Standards Action(標準化の 行動)」ポリシー)。 本文書は、メディアタイプ「audio」、「video」、「text」、 「application」、「message」を登録する。 注意: メディアタイプ「control」と「data」は、本仕様の旧版[6]で有効な タイプとして列挙されていたが、セマンティクスは完全に規定されておら ず、広く使用されていない。 これらのメディアタイプは本仕様から削除されたが、RFC 3840 [24]で定義 されているように、SIPユーザーエージェントの有効なメディアタイプ能力 として残っている。これらのメディアタイプが、将来的に有効と考えられる ようになった場合、用法を記載した標準化過程のRFCを作成しなければなら ない[MUST]。RFCが作成されない限り、アプリケーションはこれらのタイプ を使用すべきではない[SHOULD NOT]。また、SIPの能力宣言でこれらのタイ プのサポートを宣言すべきではない[SHOULD NOT](RFC 3840で作成されたレ ジストリに存在する場合でも)。 8.2.2. トランスポートプロトコル("proto) 「proto」フィールドは、使用するトランスポートプロトコルを記述する。 これは、標準化過程のプロトコルRFCを参照すべきである[SHOULD]。本文書 は、3つの値を登録する。「RTP/AVP」は、UDP/IP上で実行される「RTP Profile for Audio and Video Conferences with Minimal Control」[20]の Handley, et al. Standards Track [Page 34] RFC 4566 SDP July 2006 制御下で使用されるRTP [19]への参照である。「RTP/SAVP」は、Secure Real-time Transport Protocol [23]への参照である。「udp」は、UDP上の 特定されないプロトコルを示す。 将来的に他のRTPプロファイルが定義される場合、その「proto」名も同じ方 法で指定すべきである[SHOULD]。たとえば、短縮名が「XYZ」のRTPプロファ イルは、「RTP/XYZ」という「proto」フィールドで示される。 新しいトランスポートプロトコルは、IANAに登録すべきである。 登録は、プロトコルを説明するRFCを参照しなければならない[MUST]。この RFCは、「実験的(Experimental)」または「参考情報(Informational)」でも よい[MAY]が、標準化過程(Standards-Track)の方が望ましい。登録では、 「fmt」名前空間を管理する規則も定義しなければならない[MUST](以下を 参照)。 8.2.3. メディアタイプ(「fmt」) 「proto」フィールドで定義される各トランスポートプロトコルは、関連す る「fmt」名前空間がある。「fmt」は、そのプロトコルで伝達されるメディ ア形式を記述する。形式は、マルチメディアセッションで伝送することが考 えられる、すべてのエンコーディングを網羅する。 「RTP/AVP」と「RTP/SAVP」プロファイル以下のRTPペイロード形式は、 ペイロードタイプ番号を「fmt」値として使用しなければならない[MUST]。 ペイロードタイプ番号が、このセッション記述で動的に割り当てられる場 合、ペイロード形式のメディアタイプ登録で定義されているとおりに、追加 の「rtpmap」属性を含めて、形式の名前とパラメータを指定しなければなら ない[MUST]。SDPトランスポートプロトコルとして(RTPと組み合わせて)登録 されている他のRTPプロファイルでは、「fmt」名前空間に同じ規則を指定す ることが推奨される[RECOMMENDED]。 「udp」プロトコルの場合、新しい形式を登録すべきである[SHOULD]。この 形式には、既存のメディアサブタイプを使用することが推奨される。メディ アサブタイプが存在しない場合、その形式のトランスポートプロトコルを定 義する標準化過程のRFCを作成するか参照して、IETFの過程[31]を通じて適 切なMIMEサブタイプを登録することが推奨される。 他のプロトコルの場合、関連する「proto」仕様の規則に従って形式を登録 してもよい[MAY]。 新しい形式の登録では、適用するトランスポートプロトコルを指定しなけれ ばならない[MUST]。 Handley, et al. Standards Track [Page 35] RFC 4566 SDP July 2006 8.2.4. 属性名("att-field") 属性フィールド名(「att-field」)は、IANAに登録し、文書化しなければな らない[MUST]。これは、同じ名前以下で属性が衝突する問題を把握しやすく するためである。SDP内で未知の属性は単に無視されるだけだが、属性が衝 突するとプロトコルが分かれてしまうため深刻な問題である。 新しい属性登録は、以下の情報が仕様に含まれている場合、RFC 2434の「必 須の仕様(Specification Required)」ポリシーに従って受け入れられる。 o コンタクト名、電子メールアドレス、および電話番号 o 属性名(SDPに出現する場合の名前) o 長い形式の属性名(英語) o 属性のタイプ(セッションレベル、メディアレベル、または両方) o 属性値がcharset属性に従っているかどうか o 属性の目的を記した1段落の説明。 o この属性に関する適切な属性値の仕様。 上記は、IANAで受け入れられる最小の項目である。広範囲な利用と相互運用 性を実現することが期待されている属性は、属性の詳細を規定した標準化過 程のRFCに文書化すべきである[SHOULD]。 登録申請者は、仕様がSDP属性の精神に準じているように留意すべきである。 特に、オペレーティングシステムに関する暗黙的な仮定を何も行わないとい う意味で属性がプラットフォーム非依存であること、相互運用性を妨げる方 法でソフトウェアの特定部分を指定しないことに留意すべきである。 IANAは、属性名の初期セット(「att-field」値)として以下を登録すること、 および本文書のセクション6の定義を登録した(本文書の定義は、RFC 2327の 定義を更新する)。 Handley, et al. Standards Track [Page 36] RFC 4566 SDP July 2006 名前 | セッションレベル | 文字セットへの依存? | またはメディアレベル? | ----------+-------------------------+---------------------- cat | セッション | なし keywds | セッション | あり tool | セッション | なし ptime | メディア | なし maxptime | メディア | なし rtpmap | メディア | なし recvonly | どちらか | なし sendrecv | どちらか | なし sendonly | どちらか | なし inactive | どちらか | なし orient | メディア | なし type | セッション | なし charset | セッション | なし sdplang | どちらか | なし lang | どちらか | なし framerate | メディア | なし quality | メディア | なし fmtp | メディア | なし 8.2.5. 帯域指定子(「bwtype」) 帯域指定子の増加はまったく推奨されない。 新しい帯域指定子(「bwtype」フィールド)は、IANAに登録しなければならな い[MUST]。申請では、帯域指定子のセマンティクスを詳細に規定し、使用す るタイミングと、既存の登録済み帯域指定子では十分ではない理由を示し た、標準化過程のRFCを参照しなければならない[MUST]。 本文書のセクション5.8ど定義されているように、IANAは帯域指定子「CT」 と「AS」を登録した(本文書の定義はRFC 2327の定義を更新している)。 8.2.6. ネットワークタイプ(「nettype」) 新しいネットワークタイプ(「nettype」フィールド)は、インターネット以 外の環境という背景でSDPを使用する必要がある場合にIANAで登録すること ができる。インターネット以外の環境については、一般的にIANAの領域では ないが、インターネットアプリケーションが非インターネットアプリケー ションと相互運用する必要がある場合もある。たとえば、インターネット電 話の呼をPSTN (Public Switched Telephone Network)にゲートウェイする場 合などである。ネットワークタイプの数は少なくすべきであり、あまり拡張 すべきではない。新しいネットワークタイプを登録するには、そのネット ワークタイプと共に使用される1つ以上のアドレスタイプを登録する必要が Handley, et al. Standards Track [Page 37] RFC 4566 SDP July 2006 ある。新しいネットワークタイプの登録は、そのネットワークタイプとアド レスタイプの詳細、使用方法、使用するタイミングを説明するRFCを参照し なければならない[MUST]。 IANAは、インターネットを表すネットワークタイプ「IN」を登録した。この 定義は、本文書のセクション5.2および5.7を参照のこと(本文書の定義はRFC 2327の定義を更新している)。 8.2.7. アドレスタイプ(「addrtype」) 新しいアドレスタイプ(「addrtype」)をIANAで登録することができる。アド レスタイプは、ネットワークタイプのコンテキストでのみ意味があり、アド レスタイプの登録はいずれも、登録済みネットワークタイプを指定するか、 ネットワークタイプ登録と共に提出しなければならない[MUST]。新しいアド レスタイプ登録は、アドレスタイプの構文について詳細を説明したRFCを参 照しなければならない[MUST]。アドレスタイプの登録は頻繁に行われるとは 予想されていない。 本文書のセクション5.2ど定義されているように、IANAに対してアドレスタ イプ「IP4」と「IP6」を登録した(本文書の定義はRFC 2327の定義を更新し ている)。 8.2.8. 登録手順 SDPの「media」、「proto」、「fmt」、「bwtype」、「nettype」、 「addrtype」の各フィールドを登録するRFC文書を作成する場合、IANAが適 切に登録できるように、次の情報を含めなければならない[MUST]。 o コンタクト名、電子メールアドレス、および電話番号 o 登録する名前(SDPに出現する場合の名前) o 長い形式の属性名(英語) o 名前の種類 (「media」、「proto」、「fmt」、「bwtype」、 「nettype」、または「addrtype」) o 登録名の目的を記した1段落の説明。 o 登録名の仕様への参照(一般的に、RFC番号) IANAは、レビューのためにIESGへの登録を照会する場合があり、登録が実行 される前に改版を要求する場合もある。 Handley, et al. Standards Track [Page 38] RFC 4566 SDP July 2006 8.3. 暗号化キーのアクセス方法 IANAはSDP暗号化キーのアクセス方法(「enckey」)名の表を維持していた。 「k=」行は拡張できないため、この表はサポートされなくなった。新しい登 録は受諾されない[MUST NOT]。 9. SDPの文法 このセクションでは、SDPのAugmented BNF文法について説明する。ABNFは[4]で定義されている。 ; SDPの構文 session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions proto-version = %x76 "=" 1*DIGIT CRLF ;本文書ではバージョン0である origin-field = %x6f "=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF session-name-field = %x73 "=" text CRLF information-field = [%x69 "=" text CRLF] uri-field = [%x75 "=" uri CRLF] email-fields = *(%x65 "=" email-address CRLF) phone-fields = *(%x70 "=" phone-number CRLF) connection-field = [%x63 "=" nettype SP addrtype SP connection-address CRLF] ; connectionフィールドは、すべてのメディア記 ; 述、またはセッションレベルで提示しなければな ; らない。 Handley, et al. Standards Track [Page 39] RFC 4566 SDP July 2006 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) time-fields = 1*( %x74 "=" start-time SP stop-time *(CRLF repeat-fields) CRLF) [zone-adjustments CRLF] repeat-fields = %x72 "=" repeat-interval SP typed-time 1*(SP typed-time) zone-adjustments = %x7a "=" time SP ["-"] typed-time *(SP time SP ["-"] typed-time) key-field = [%x6b "=" key-type CRLF] attribute-fields = *(%x61 "=" attribute CRLF) media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields ) media-field = %x6d "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF ; 「o=」のサブ規則 username = non-ws-string ;かなり広い定義だが、スペースは含まない sess-id = 1*DIGIT ; このusername/hostで一意にすべきである sess-version = 1*DIGIT nettype = token ;一般的に「IN」 addrtype = token ;一般的に「IP4」または「IP6」 ; 「u=」のサブ規則 uri = URI-reference ; RFC 3986を参照 Handley, et al. Standards Track [Page 40] RFC 4566 SDP July 2006 ; 「e=」のサブ規則、定義についてはRFC 2822を参照 email-address = address-and-comment / dispname-and-address / addr-spec address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" ; 「p=」のサブ規則 phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) ; 「c=」のサブ規則 connection-address = multicast-address / unicast-address ; 「b=」のサブ規則 bwtype = token bandwidth = 1*DIGIT ; 「t=」のサブ規則 start-time = time / "0" stop-time = time / "0" time = POS-DIGIT 9*DIGIT ; 1900年以降のNTP時間(秒単位)の10進表記NTP時間 ; の表記は、10桁以上の数値を含む長さが限定され ; ていないフィールドである。他の部分で使用され ; る64ビット表記とは異なり、SDPの時間は2036年 ; でラップしない。 ; 「r=」と「z=」のサブ規則 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit] fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 ; 「k=」のサブ規則 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" %x75 %x72 %x69 ":" uri ; "uri:" base64 = *base64-unit [base64-pad] Handley, et al. Standards Track [Page 41] RFC 4566 SDP July 2006 base64-unit = 4base64-char base64-pad = 2base64-char "==" / 3base64-char "=" base64-char = ALPHA / DIGIT / "+" / "/" ; 「a=」のサブ規則 attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string ; 「m=」のサブ規則 media = token ; 一般的に、「audio」、「video」、「text」、ま ; たは「application」 fmt = token ; 一般的に、音声メディアおよびビデオメディア ; のRTPペイロード proto = token *("/" token) ; 一般的に、「RTP/AVP」または「udp」 port = 1*DIGIT ; 汎用的なサブ規則: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast / FQDN / extn-addr IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] ; IPv4マルチキャストアドレスは、224.0.0.0か ; ら239.255.255.255の範囲に含めることができる。 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = hexpart [ "/" integer ] ; FFで始まるIPv6アドレス ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; RFC 1035 (およびその更新)で規定されている完 ; 全修飾ドメイン名 Handley, et al. Standards Track [Page 42] RFC 4566 SDP July 2006 IP4-address = b1 3("." decimal-uchar) b1 = decimal-uchar ; 「224」未満 ; 次の行は RFC 2373 [30]の付録Bに準拠している。 IP6-address = hexpart [ ":" IP4-address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG ; 他のアドレスファミリに汎用 extn-addr = non-ws-string ; 汎用的なサブ規則: datatypes text = byte-string ;デフォルトでは、これをUTF8テキストと解釈する。 ;ISO 8859-1は、「a=charset:ISO-8859-1」セッ ;ションレベル属性の使用を要求する。 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;NUL、CR、またはLF以外の任意のバイト non-ws-string = 1*(VCHAR/%x80-FF) ;可視文字の文字列 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E token = 1*(token-char) email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;NUL、CR、LFまたは引用文字()<>以外の任意の ;バイト integer = POS-DIGIT *DIGIT ; 汎用的なサブ規則: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 Handley, et al. Standards Track [Page 43] RFC 4566 SDP July 2006 decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2*(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) ; 外部参照: ; ALPHA、DIGIT、CRLF、SP、VCHAR (RFC 4234) ; URI参照: RFC 3986 ; addr-spec: RFC 2822 10. RFC 2327からの変更の概要 本文書は、使用を考慮して、大幅に再構築され、仕様に多数の説明を追加し た。以下に記した項目意外に本文書で加えた変更は、下位互換性を持たせる ための説明である。ただし、RFC 2327には矛盾や不明確な定義があるため、 RFC 2327と今回のバージョンのSDPとがいくつかの点で異なると解釈する実 装があることは考えられる。 セクション9のABNF文法は、広範囲にわたって改版および更新され、多数の誤 りが修正され、RFC 3266 IPv6拡張が組み込まれた。文法と仕様の文章につ いて既知の矛盾は修正された。 SDPについてメディアタイプの登録が含まれた。IANAに属性や他のパラメー タを登録する場合の要件は、明確に、かつ厳格になった(セクション8)。 「text」と「message」はSDPで使用できる有効なメディアタイプだが、 「control」と「data」は仕様を策定中であり、推奨されない。 RFC 2119の用語は、要件レベルを指定する場合に全体で使用されるように なった。このような要件の一部は(特にパラメータ登録に関する場合)、RFC 2327の場合よりも厳格になっている。 RTPプロファイル「RTP/SAVP」とその名前空間「fmt」が登録された。 属性「a=inactive」と「a=maxptime」が追加された。 RFC 2327では、「e=」または「p=」を必須としていた。実際の使用方法を反 映し、いずれも今バージョンではオプションになった。 「k=」フィールドの大幅な制約について注記が加えられ、このフィールドを 使用することは推奨されなくなった。 実験的なパラメータに「x-」接頭辞表記を使用することは、ほとんどの場 合、許可されなくなった。また、その他の用法も推奨されていない。 Handley, et al. Standards Track [Page 44] RFC 4566 SDP July 2006 11. 謝辞 IETF Multiparty Multimedia Session Control (MMUSIC)ワーキンググルー プに参加する多くの人々が、コメントと提案を本文書に寄せてくださった。 特に、Eve Schooler、Steve Casner、Bill Fenner、Allison Mankin、Ross Finlayson、Peter Parnes、Joerg Ott、Carsten Bormann、Steve Hanna、 Jonathan Lennox、Keith Drage、Sean Olson、Bernie Hoeneisen、Jonathan Rosenberg、John Elwell、Flemming Andreasen、Jon Peterson、Spencer Dawkinsに感謝を述べたい。 12. 参考文献 12.1. 規範となる参考文献 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002. Handley, et al. Standards Track [Page 45] RFC 4566 SDP July 2006 [11] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. 12.2. 有益な参考文献 [13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [15] 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. [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [21] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. [22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Handley, et al. Standards Track [Page 46] RFC 4566 SDP July 2006 [24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [25] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004. [26] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. [27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [28] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [29] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [30] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [31] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. Handley, et al. Standards Track [Page 47] RFC 4566 SDP July 2006 著者の連絡先 Mark Handley University College London Department of Computer Science Gower Street London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 USA EMail: van@packetdesign.com Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ UK EMail: csp@csperkins.org Handley, et al. Standards Track [Page 48] RFC 4566 SDP July 2006 完全な著作権表示 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 については、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2006年 ----------------------------------------------------------------------- Handley, et al. Standards Track [Page 49]