Network Working Group M. Handley Request for Comments: 2327 V. Jacobson Category: Standards Track ISI/LBNL April 1998 SDP: セッション記述プロトコル SDP: Session Description Protocol 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラック プロトコルを規定するものであり、改善のための議論や提案を依頼するものであ る。標準化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。この文書の配信は無制 限である。 著作権表記 Copyright (C) The Internet Society (1998).All Rights Reserved. 概要 本文書は、セッション記述プロトコル(Session Description Protocol/SDP)を定 義する。SDPは、セッション告知、セッションの招待などの形式を持つマルチメ ディアセッションの開始という目的で、マルチメディアセッションを記述するた めのプロトコルである。 本文書は、Internet Engineering Task ForceのMultiparty Multimedia Session Control (MMUSIC)ワーキンググループが作成した。このドキュメントに関するコ メントは、ワーキンググループのメーリングリストconfctrl@isi.eduと著者のど ちらかまたは双方に提出されたい。 1. はじめに インターネットのマルチキャストバックボーン(Mbone)では、セッションディレ クトリツールは、マルチメディアカンファレンスの通知(advertise)、および参 加に必要なカンファレンスアドレスとカンファレンスツール固有の情報の通信に 使用される。本文書では、この用途と、一般的なリアルタイムのマルチメディア セッション記述用途に、セッション記述プロトコルを定義する。本文書では、マ ルチキャストアドレスの割り当てやSDPメッセージ配信の詳細については説明し ない。参考文献を参照されたい。SDPは、メディアエンコーディングのネゴシ エーションを目的としたものではない。 Handley & Jacobson Standards Track [Page 1] RFC 2327 SDP April 1998 2. 背景 Mboneは、IPマルチキャストをサポートするインターネットの一部なので、効率 的な多対多通信を許容している。Mboneはマルチメディアカンファレンス向けに 広く利用されている。このようなカンファレンスには、一般的に、カンファレン ス参加者の密な連携を必要としないという特性がある。Mboneサイトのユーザー は、カンファレンスのマルチキャストグループアドレスと、カンファレンスデー タストリームのUDPポートがわかれば、カンファレンスを受信することができ る。 セッションディレクトリは、参加者候補に対するカンファレンスセッションの通 知と、関連するカンファレンスのセットアップ情報の通信を補助する。SDPは、 このような情報を受信側に伝達するように設計されている。SDPは、単にセッ ションを記述するための書式である。伝送プロトコルは組み込まれていない。ま た。また、必要に応じて異なる伝送プロトコルを使用するように設計されてい る。たとえば、Session Announcement Protocol [4]、Session Initiation Protocol [11]、Real-Time Streaming Protocol [12]、MIME拡張を使用した電子 メール、Hypertext Transport Protocolなどである。 SDPは、マルチキャストセッションディレクトリだけでなく、幅広いネットワー ク環境やアプリケーションに使用できるよう、汎用的に設計されている。ただ し、セッションコンテンツまたはメディアエンコーディングのネゴシエーション をサポートすることは対象としていない。これは、セッション記述の範囲外と見 なしている。 3. 用語集 次の用語は、本文書で使用され、本文書内で独自の意味を持つ。 カンファレンス(Conference) マルチメディアカンファレンスは、2人以上の通信ユーザーと通信に使用す るソフトウェアの集合である。 セッション(Session) マルチメディアセッションは、マルチメディアの送信側と受信側、および送信 側から受信側に流れるデータストリームの集合である。マルチメディアカン ファレンスは、マルチメディアセッションの一例である。 セッションの通知(Session Advertisement) 「セッション告知」を参照。 セッション告知(Session Announcement) セッション告知とは、セッション記述を主体的な形式でユーザーに伝達する メカニズムである。つまり、セッション記述は、ユーザーから明示的に要求 されるものではない。 Handley & Jacobson Standards Track [Page 2] RFC 2327 SDP April 1998 セッション記述(Session Description) マルチメディアセッションを検出し、参加するために十分な情報を伝達するた めの定義済み書式。 3.1. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」はRFC 2119に記載されるとおりに解釈されるべきである。 4. SDPの用法 4.1. マルチキャストの告知 SDPは、マルチメディアセッションのセッション記述プロトコルである。一般的 な用法モデルは、クライアントが、Session Announcement Protocol (SAP)を使 用し、既知のマルチキャストアドレスとポートに対して告知パケット (announcement packet)を定期的にマルチキャストすることで、カンファレンス セッションを告知するというものである。 SAPパケットは、次の形式のUDPパケットである。 |--------------------| | SAPヘッダー | |--------------------| | テキストペイロード | |////////// このヘッダーは、Session Announcement Protocolヘッダーである。SAPの詳細 については、参考文献の[4]を参照のこと。 テキストペイロードは、本文書に記述されているSDPセッション記述である。テ キストペイロードの長さは1 KB以下にすべきである。SAPによって告知される場 合、1つのパケットで1つのセッション告知のみが許容される。 4.2. 電子メール告知とWWW告知 セッション記述を伝達するその他の手段として、電子メールとWWW (World Wide Web)がある。電子メールとWWWどちらを配信する場合でも、MIMEコンテンツタイ プ「application/sdp」を使用すべきである。こうすることで、セッションに参 加するときにWWWクライアントやメールクライアントから標準的な方法で、自動 的にアプリケーションを起動することが可能になる。 Handley & Jacobson Standards Track [Page 3] RFC 2327 SDP April 1998 電子メールまたはWWW (World Wide Web)経由のみで作成されたマルチメディア セッションの告知には、セッション告知の受信側がセッションを必ず受信できる という特性はない。これは、マルチメディアセッションは、スコープに制約を受 ける可能性があるためである。WWWサーバーへのアクセス、または電子メールの 受信は、このスコープ外にある可能性がある。SAP告知の場合、このような不整 合の問題はない。 5. 要件と推奨 SDPの目的は、マルチメディアセッションのメディアストリームに関する情報を 伝達し、セッション記述の受信者がセッションに参加できるようにすることであ る。SDPは、主にインターネットワークでの使用を対象にしている。ただし、他 のネットワーク環境におけるカンファレンスを記述する場合も一般的である。 このような目的のマルチメディアセッションは、一定の期間存在するメディアス トリーム群として定義される。メディアストリームは、多対多の可能性がある。 セッションがアクティブな期間は、連続している必要はない。 したがって、インターネット上のセッションに基づくマルチキャストは、トラ フィックを受信する誰もが(セッショントラフィックが暗号化されていなければ) セッションに参加できる、多くのカンファレンス形式とは異なる。このような環 境で、SDPには主に2つの目的がある。1つはセッションの存在を通信する手段、 もう1つはセッションに追加および参加するのに十分な情報を伝達する手段であ る。ユニキャスト環境では、後者の目的の方に関係性が高い。 したがって、SDPには次の情報が含まれる。 o セッションの名前と目的 o セッションがアクティブな時間 o セッションを構成するメディア o そのメディアを受信するための情報(アドレス、ポート、形式など) セッションに参加する必要があるリソースは制約を受ける可能性があるため、他 の情報が必要になる場合もある。 o カンファレンスで使用する帯域に関する情報 o セッションに責任を持つ人物のコンタクト情報 Handley & Jacobson Standards Track [Page 4] RFC 2327 SDP April 1998 一般的に、SDPでは、セッションに参加し、情報が必要な非参加者に対して使用 するリソースを告知するために十分な情報を伝達する必要がある(暗号化キーは 除外される場合もある)。 5.1. メディア情報 SDPには次のメディア情報が含まれる。 o メディアの種類(ビデオ、音声など) o トラフィックプロトコル(RTP/UDP/IP、H.320など) o メディアの形式(H.261ビデオ、MPEGビデオなど) IPマルチメディアセッションの場合、次の情報も伝達される。 o メディアのマルチキャストアドレス o メディアの伝送ポート このアドレスとポートは、送受信どちらの場合でも、マルチキャストストリーム の送信先アドレスと送信先ポートである。 IPユニキャストセッションの場合、次の情報も伝達される。 o メディアのリモートアドレス o コンタクトアドレスの伝送ポート このアドレスとポートのセマンティクスは、定義されているメディアと伝送プロ トコルによって異なる。デフォルトで、これはデータの送信対象であるリモート アドレスとリモートポートであり、データを受信するローカルアドレスとローカ ルポートである[訳注: 原文では受信の場合に「remote address and local port」となっていますが、前者の「remote」は「local」の誤植と考えられま す]。ただし、メディアによっては、実際のメディアフローで制御チャネルを確 立する目的で、この情報を使用するように定義する可能性がある。 5.2. タイミング情報 セッションは時間に関連付けられている場合と関連付けられていない場合があ る。いずれにしても、特定の時間にのみアクティブな場合がある。 SDPは次のタイミング情報を伝達できる。 o セッションに関連付けた開始時間と停止時間の任意なリスト o 関連付けごとに、「every Wednesday at 10am for one hour(毎週水曜日、 午前10時に1時間)」などの繰り返し回数 Handley & Jacobson Standards Track [Page 5] RFC 2327 SDP April 1998 このタイミング情報は、地域のタイムゾーンやサマータイムにかかわらず、グ ローバルに整合性がある。 5.3. プライベートセッション パブリックセッションとプライベートセッションのどちらも作成することができ る。一般的に、プライベートセッションは、配信するセッション記述を暗号化し て伝達される。暗号化の実行方法は、SDPを伝達するときに使用するメカニズム によって変わる。セッション告知の場合の実行方法については、[4]を参照のこ と。 セッション告知がプライベートの場合、カンファレンスの各メディアをデコード するために必要な暗号化キーを、プライベートな告知を使用して伝達することが できる。たとえば、各メディアに使用する暗号化スキームを知るために必要な情 報などである。 5.4. セッションに関する詳細情報の取得 セッション記述では、セッションに参加するかどうかを判断するために十分な情 報を伝達する必要がある。セッションに関する詳細情報として、URI (Universal Resources Identifiers)の形式で追加のポインタをSDPに含めることができる。 5.5. 分類化 多くのセッション記述がSAPまたは他の告知メカニズムによって配信されるとき に、興味がある告知とそうでない告知をフィルタすることが望ましい場合があ る。SDPでは、自動化できるセッションの分類化メカニズムをサポートしてい る。 5.6. 国際化 SDP仕様では、UTF-8エンコーディングでISO 10646文字セットを使用することを 推奨している。これは、多様な言語を表記するためである。ただし、短縮表記を 支援するために、SDPでは、必要に応じてISO 8859-1などの文字セットを使用す ることも許容している。国際化は、SDP全体ではなく、フリーテキストのフィー ルド(セッション名と背景情報)にのみ適用される。 6. SDP仕様 SDPのセッション記述は、全体にUTF-8エンコーディング形式のISO 10646文字 セットを使用したテキストである。SDPのフィールド名と属性名では、UTF-8のUS -ASCIIサブセットのみを使用するが、テキストフィールドと属性値には、ISO 10646のフル文字セットを使用できる。ASN/1やXDRなどのバイナリエンコーディ Handley & Jacobson Standards Track [Page 6] RFC 2327 SDP April 1998 ングとは対照的なテキスト形式が選択されたのは、携帯性を強化し、多様な伝送 方法(MIME電子メールメッセージでのセッション記述など)を使用できるようにす るためである。また、テキスト形式にすることで、柔軟なテキストベースのツー ルキット(Tcl/Tkなど)を使用して、セッション記述の生成と処理が可能になる。 ただし、SAP告知全体に割り当てられる総帯域は厳重に制約を受けるため、エン コーディングは意図的にコンパクトにされている。また、告知は、信頼性が非常 に低い手段(電子メールなど)で伝送されたり、仲介のキャッシングサーバーで損 失する可能性があるため、エンコーディングは厳密な順序規則と書式規則で設計 された。これは、ほとんどのエラーを、容易に検出して破棄できる不正な形式の 告知になるようにするためである。こうすることで、受信側が正しいキーを持っ ていない暗号化済み告知を速やかに破棄することができる。 SDPのセッション記述は、<タイプ>=<値>という形式の複数行のテキストで構成さ れる。<タイプ>は、常に1文字で、大文字と小文字が区別される。<値>は、構造 的なテキスト文字列で、形式は<タイプ>によって変わる。また、特定のフィール ドで指定されない限り、大文字と小文字が区別される。「=」記号の両脇にホワ イトスペースは指定できない。一般的に、<値>は、スペース1文字で区切られた 複数のフィールド、または自由形式の文字列である。 セッション記述は、セッションレベルの記述(セッションとメディアストリーム 全体に適用される詳細)と、オプションのメディアレベルの記述(1つのメディア ストリームに適用される詳細)がいくつかで構成される。 告知は、セッションレベルのセクションと、それに続く0個以上のメディアレベ ルのセクションで構成される。セッションレベルのパートは「v=」行で始まり、 最初のメディアレベルのセクションまで続く。メディア記述は、「m=」行で始ま り、次のメディア記述またはセッション記述全体の末尾まで続く。一般的に、 セッションレベルの値は、同等のメディアレベルの値で上書きされない場合、す べてのメディアのデフォルト値になる。 SAPによってSDPを伝達する場合、1つのパケットに付き1つのセッション記述のみ が許容される。SDPを他の手段で伝達する場合、複数のSDPセッション記述を連結 することができる(セッション記述の開始を示す「v=」行によって前の記述が終 了する)。各記述の行には必須のものとオプションのものがある。ただし、いず れも本文書で指定した順序どおりに表記する必要がある(順序を固定すること で、エラーの検出が大幅に強化され、パーサーを単純にすることができる)。オ プションの項目は、「*」という印が付けられている。 [訳注: 以下、<値>の部分は、翻訳と原文をスラッシュで区切って併記します] セッション記述 v= (プロトコルのバージョン / protocol version) o= (所有者/作成者およびセッションの識別子 / owner/creator and session identifier) s= (セッション名 / session name) i=* (セッション情報 / session information) Handley & Jacobson Standards Track [Page 7] RFC 2327 SDP April 1998 u=* (記述のURI / URI of description) e=* (電子メールアドレス / email address) p=* (電話番号 / phone number) c=* (セッション情報 / connection information - すべてのメディアに 含まれる場合は必要なし) b=* (帯域情報 / bandwidth information) 1つ以上の時間記述(後述参照) z=* (タイムゾーンの調整 / time zone adjustments) k=* (暗号化キー / encryption key) a=* (0行以上のセッション属性行 / zero or more session attribute lines) 0個以上のメディア記述(後述参照) 時間記述 t= (セッションがアクティブな時間 / time the session is active) r=* (0回以上の繰り返し回数) メディア記述 m= (メディア名と伝送アドレス / media name and transport address) i=* (メディアのタイトル) c=* (接続情報 - セッションレベルで含める場合はオプション) b=* (帯域情報 / bandwidth information) k=* (暗号化キー / encryption key) a=* (0行以上のメディア属性行 / zero or more media attribute lines) 「タイプ」文字のセットは意図的に小さくされており、拡張する意図はない。 SDPパーサーは、理解できない「タイプ」文字を含む告知は、完全に無視しなけ ればならない。「属性」のメカニズム(後述の「a=」)は、SDPを拡張し、特定の アプリケーションまたはメディアに合わせるための主な手段である。属性(本文 書で列挙するもの)には意味が定義されているが、アプリケーション、メディ ア、またはセッション固有の属性を追加してもよい。セッションディレクトリで は、理解できない属性はすべて無視しなければならない。 セッションレベルセクションの接続(「c=」)と属性(「a=」)の各情報は、メディ ア記述で同じ名前の接続情報または属性で上書きされた場合を除き、すべての セッションのメディアに適用される。たとえば、次の例に示すように、各メディ アは、「recvonly(受信のみ)」属性を指定された場合と同様に動作する。 SDPの記述例は以下のとおり。 v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/127 Handley & Jacobson Standards Track [Page 8] RFC 2327 SDP April 1998 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait セッション名や情報などのテキストレコードは、0x00 (Nul)、0x0a (ASCIIの改 行文字)、および0x0d (ASCIIのキャリッジリターン)を除く任意のバイトを含む バイト文字列である。レコードを終了するときにシーケンスのCRLF (0x0d0a)を 使用するが、パーサーは、1つの改行文字で終了するレコードを許容し、受け入 れるべきである。デフォルトで、このバイト文字列にはUTF-8エンコーディング のISO-10646文字が含まれるが、このデフォルトは「charset」属性を使用して変 更できる。 プロトコルのバージョン v=0 「v=」フィールドで、セッション記述プロトコルのバージョンを指定する。 マイナーバージョン番号はない。 発信元 o=<ユーザー名> <セッションID> <バージョン> <ネットワークタイプ> <アドレスタイプ> <アドレス> 「o=」フィールドでは、セッションの発信元(ユーザーのホストのユーザー名と アドレス)と、セッションID、セッションのバージョン番号を指定する。 <ユーザー名>は、ユーザーが発信元ホストにログインするときの名前である。発 信元ホストでユーザーIDという概念がサポートされていない場合は「-」であ る。<ユーザー名>にスペースを含めてはならない。<セッションID>は、数値文字 列(numeric string)である。これは、<ユーザー名>、<セッションID>、<ネット ワークタイプ>、<アドレスタイプ>、および<アドレス>で、そのセッションのグ ローバルに一意な識別子を構成するためである。 <セッションID>の割り当て方法は作成ツールに委ねられるが、NTP (Network Time Protocol)のタイムスタンプを使用して一意性を確保する方法が提案されて いる[1]。 <バージョン>はこの告知のバージョン番号である。これは、同じセッションの告 知が複数ある場合、どれが最新のものかをプロキシの告知で検出するために必要 Handley & Jacobson Standards Track [Page 9] RFC 2327 SDP April 1998 である。セッションデータが修正されたときに<バージョン>を増やす、という点 以外の用法については、ここでも作成ツールに委ねられる。また、この場合も NTPタイムスタンプの使用が推奨される(ただし必須ではない)。 <ネットワークタイプ>は、ネットワークのタイプを指定するテキスト文字列で ある。初期設定として「IN」が「インターネット(Internet)」の意味で定義され ている。<アドレスタイプ>は、次のアドレスのタイプを指定するテキスト文字列 である。初期設定として「IP4」と「IP6」が定義されている。<アドレス>は、 セッションを作成したマシンのグローバルに一意なアドレスである。アドレスタ イプがIP4の場合、マシンの完全修飾ドメイン名か、マシンのIPバージョン4アド レスのドット付き10進数表記である。アドレスタイプがIP6の場合、マシンの完 全修飾ドメイン名か、マシンのIPバージョン6アドレスの圧縮されたテキスト表 記である。IP4とIP6のどちらの場合でも、使用できない場合を除き、完全修飾ド メイン名を使用すべきである[SHOULD]。完全修飾ドメイン名を使用できない場 合、グローバルに一意なアドレスを代用してもよい。SDP記述がローカルのIPア ドレスが意味を持たないスコープに出る場合、ローカルのIPアドレスを使用して はならない[MUST NOT]。 一般的に、「o=」フィールドは、そのセッション記述のそのバージョンに関し て、グローバルに一意な識別子として機能する。また、バージョン以外のサブ フィールドを合わせると、どのような修正があってもセッションを識別できる。 セッション名 s=<セッション名> 「s=」フィールドは、セッション名である。1つのセッション記述ごとに許容さ れている「s=」フィールドは1つのみである。また、ISO 10646文字を含める必要 がある(ただし、後述の「charset」属性も参照すること)。 セッション情報とメディア情報 i=<セッション記述> 「i=」フィールドは、セッションに関する情報である。1つのセッション記述ご とに最大1つのセッションレベルの「i=」フィールドを指定できる。また、1つの メディアごとに最大1つの「i=」フィールドを指定できる。省略可能だが、セッ ション告知の場合、省略は推奨されない。また、セッションを構成するユーザー インターフェイスでは、テキストを入力する必要がある。指定する場合、ISO 10646を含める必要がある(ただし、後述の「charset」属性も参照のこと)。 1つの「i=」フィールドは、各メディア定義にも使用できる。メディア定義で は、「i=」フィールドは主にメディアストリームのラベル付けに使用される。し たがって、1つのセッションに、同じメディアタイプを持つ複数のメディアスト Handley & Jacobson Standards Track [Page 10] RFC 2327 SDP April 1998 リームがあるときに、有効な場合が多い。たとえば、2つの異なるホワイトボー ドがあり、1つはスライド用、もう1つはフィードバックと質問用という場合など である。 URI u= o URIはWWWクライアントで使用されるUniversal Resource Identifierである。 o URIは、カンファレンスに関する追加情報へのポインタにすべきである。 o このフィールドはオプションだが、指定する場合、最初のメディアフィールド の前に指定すべきである。 o 1つのセッション記述ごとに許容されているURIフィールドは1つ以下である。 電子メールアドレスと電話番号 e=<電子メールアドレス> p=<電話番号> o カンファレンスに責任を持つ人物のコンタクト情報を指定する。カンファレン ス告知を作成した人物と同一にする必要はない。 o 電子メールフィールドまたは電話フィールドのどちらかを指定する必要があ る。電子メールフィールドと電話フィールドを追加することもできる。 o 指定する場合、最初のメディアフィールドの前に指定すべきである。 o セッション記述に、1つ以上の電子メールフィールドまたは電話フィールド を指定できる。 o 電話番号は、慣習的な国際形式で指定すべきである。つまり、「+」記号の後 に国コードを指定する方法である。国コードと残りの電話番号の間には、 スペースまたはハイフン(「-」)が必要である。スペースとハイフンは、読み やすいように、必要に応じて電話フィールドを区分するために使用しても よい。たとえば、次のとおり。 p=+44-171-380-7777 or p=+1 617 253 6011 Handley & Jacobson Standards Track [Page 11] RFC 2327 SDP April 1998 o 電子メールアドレスと電話番号のいずれも、関連するフリーのテキスト文字列 をオプションで付けることができる。一般的に、接続相手の名前を指定する。 指定する場合、丸かっこで囲むべきである。たとえば、次のとおり。 e=mjh@isi.edu (Mark Handley) 代わりに、RFC822の名前の引用規約も許容される。電子メールアドレスと電話 番号のどちらにも使用できる。たとえば、次のとおり。 e=Mark Handley フリーのテキスト文字列には、UTF-8エンコーディングされたISO-10646文字 セットを使用すべきである。適切な文字セットのセッションレベル属性が設定 されている場合、代わりにISO-8859-1などのエンコーディングを使用すること もできる。 接続データ c=<ネットワークタイプ> <アドレスタイプ> <接続アドレス> 「c=」フィールドには接続データを含める。 セッション告知には、メディア記述ごとに1つの「c=」フィールドを含めるか(後 述参照)、セッションレベルで「c=」フィールドを含める必要がある。セッショ ンレベルで1つの「c=」フィールドと、メディア記述ごとに追加で1つの「c=」 フィールドを含めることができる。この場合、メディアごとの値の方が、関連メ ディアのセッションレベル設定よりも優先される。 最初のサブフィールドは、ネットワークタイプである。これは、ネットワークの タイプを指定するテキスト文字列である。初期設定として「IN」が「インター ネット(Internet)」の意味で定義されている。 2つ目のサブフィールドはアドレスタイプである。これによって、SDPをIPベース ではないセッションにも使用できる。現時点ではIP4のみが定義されている。 3つ目のサブフィールドは接続アドレスである。<アドレスタイプ>フィールドの値 によっては、接続アドレスの後にオプションで別のサブフィールドを追加するこ とができる。 IP4アドレスの場合、接続アドレスは次のように定義される。 o 一般的に、接続アドレスはclass-DのIPマルチキャストグループアドレスで ある。セッションがマルチキャストではない場合、追加の属性フィールドの指 定どおり、接続アドレスには、期待されるデータソース、データリレー、また はデータシンクの完全修飾ドメイン名またはユニキャストのIPアドレスが含ま Handley & Jacobson Standards Track [Page 12] RFC 2327 SDP April 1998 れる。マルチキャスト告知で通信されるセッション記述で、完全修飾ドメイン 名またはユニキャストアドレスを指定することは想定していない。ただし、禁 止もしていない。ユニキャストデータストリームがNATを経由する場合、ユニ キャストのIPアドレスではなく完全修飾ドメイン名を使用することが推奨され る[RECOMMENDED]。他に、マルチホームのホスト上にある特定のインター フェース指定する場合、IPアドレスの使用が必要なこともある。したがって、 本仕様では、どちらを使用するかについては個々のアプリケーションに判断を 委ねる。ただし、どのアプリケーションでも、両方の形式を受信できるように 対応しなければならない[MUST]。 o IPマルチキャスト接続アドレスを使用したカンファレンスには、マルチキャス トアドレスとは別に、有効期間(time to live/TTL)値を指定しなければならな い。TTLとアドレスの両方で、このカンファレンスで送信されるマルチキャス トパケットのスコープが定義される。TTL値は、0〜255の範囲にしなければな らない。 セッションのTTLは、スラッシュをセパレータに使用して、アドレスに付加 する。たとえば、次のとおり。 c=IN IP4 224.2.1.1/127 階層化されたスキームは、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 Handley & Jacobson Standards Track [Page 13] RFC 2327 SDP April 1998 複数のアドレスまたは「c=」行は、メディアごとにのみ指定でき、セッション レベルの「c=」フィールドでは指定できない。 IPユニキャストアドレスに使用する上記のスラッシュ表記の場合、これは不正 である。 帯域 b=<変更子>:<帯域値> o セッションまたはメディアで使用する帯域案を指定する。また、オプション である。 o <帯域値>は、1秒当たりのキロビット数である。 o <変更子>は、英数字の1単語であり、帯域の桁数の意味を示す。 o 次の2つの変更子が定義済みである。 CT Conference Total: 暗黙的な最大帯域は、Mbone上、または特定のマルチキャ スト管理のスコープ領域内にある各TTLに関連付けられる(Mboneの帯域対TTLの 制限は、MboneのFAQを参照のこと)。セッションまたはセッション内のメディ アの帯域が、スコープの暗黙的な帯域と異なる場合、使用する帯域の上限案を 指定するセッションには、「b=CT:...」行を指定する。この主な目的は、2つ 以上のカンファレンスが同時に共存できるかどうかについて、適切なアイデア を提供することである。 AS Application-Specific Maximum: 帯域は、アプリケーション固有のものに 変換される。つまり、アプリケーションの最大帯域の概念である。一般的に、 これは、(適用可能な場合)アプリケーションの「最大帯域」制御に関する設定 と一致する。 CTでは、すべてのサイトにあるすべてのメディアに関する総帯域の桁を指定す るという点に注意すること。ASでは、同時に複数サイトの送信がある場合で も、1つのサイトにおける1つのメディアに関する帯域幅の桁数を指定する。 o Extension Mechanism: ツール開発者は、実験的な帯域の変更子を定義するこ とができる。この場合、接頭辞として「X-」を付ける。たとえば、次のとお り。 b=X-YZ:128 SDPパーサーは、未知の変更子が含まれる帯域フィールドを無視すべきで ある。変更子は、英数字にし、長さの制限がない場合でも、短くすることが 推奨される。 Handley & Jacobson Standards Track [Page 14] RFC 2327 SDP April 1998 時間、繰り返す回数、およびタイムゾーン t=<開始時間> <停止時間> o 「t=」フィールドでは、カンファレンスセッションの開始時間と終了時間を指 定する。不定期に複数回の間隔を置いてセッションがアクティブになる場合、 複数の「t=」フィールドを使用してもよい。追加の各「t=」フィールドで、 セッションがアクティブになる各期間を指定する。セッションが規則正しい時 間にアクティブになる場合、「t=」フィールドとは別に、続けて「r=」フィー ルド(後述参照)を使用すべきである。この場合、「t=」フィールドでは、繰り 返しシーケンスの開始時間と停止時間を指定する。 o 最初と2つ目のサブフィールドで、それぞれカンファレンスの開始時間と終了 時間を指定する。この値は、NTP時間値(秒単位)を10進表記したものである [1]。この値をUNIX時間に変換するには、10進の2208988800を引く。 o 終了時間をゼロに設定すると、セッションに制約はないが、開始時間後になる までアクティブにならない。開始時間もゼロの場合、セッションは永続すると 見なされる。 制約なしのセッションおよび永続的なセッションを作成するユーザー イン ターフェースは、避けるべきである。これは、セッションが実際に終了する時 間に関する情報が与えられず、予定が困難になるためである。 ユーザーに対して、有効期限切れが指定されていない制限なしのセッションを 表示する場合、一般的な推測は可能である。制限なしのセッションは、現在の 時間またはセッションの開始時間のうち遅い時点から30分までのみ、アクティ ブである、という推測である。これ以外の動作が必要な場合、セッションが実 際に終了する時間に関して新たな情報が入手できたときに、必要に応じて終了 時間を指定または修正する必要がある。 永続的なセッションは、ユーザーに提示してもよい。これは、関連付けられた 繰り返し回数(セッションをアクティブにするタイミングの正確な指定)がなけ れば、アクティブにならないためである。一般的に、2か月未満の継続期間が あることを期待されるセッションの場合、永続的なセッションは作成すべきで はない。また、6か月未満の継続期間があることを期待されるセッションの場 合、推奨されない。 r=<繰り返し間隔> <アクティブな継続期間> <開始時間からのオフセット一覧> o 「r=」フィールドでは、セッションの繰り返し回数を指定する。たとえば、 セッションが、3か月の間、毎週月曜日と火曜日の午前10時に、1時間アクティ Handley & Jacobson Standards Track [Page 15] RFC 2327 SDP April 1998 ブになる場合、関連する「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」フィールドとは別のフィールドを セッション回数を明示的に列挙するときに使用すべきである。 z=<調節時間> <オフセット> <調節時間> <オフセット> .... o サマータイムから標準時間への切り替え期間またはその逆をはさむ期間の場合 に、セッションの予定を立てるには、基本の繰り返し回数からのオフセットを 指定する必要がある。これは、タイムゾーンによって日時が変わり、国によっ てサマータイムかどうかが変わり、サマータイム制度がない国もあるためであ る。 したがって、冬と夏の同じ時間にセッションの予定を立てるには、セッション の予定を立てたタイムゾーンを明確に指定できる必要がある。受信側のこのタ スクを単純にするために、本文書では、送信側がタイムゾーンの調整が発生す るNTP時間と、最初にセッションを予定した時点からのオフセットを指定でき るようにした。送信側は、「z」フィールドを使用して、この調整時間の一覧 と、基本時間からのオフセットをを指定できる。 Handley & Jacobson Standards Track [Page 16] RFC 2327 SDP April 1998 例は次のようになる。 z=2882844526 -1h 2898848070 0 これによって、時間2882844526に、セッションの繰り返し回数を計算する基本時 間が1時間シフトが戻され、時間2898848070に、セッションの元の時間ベースが 復元される。調整は、指定した開始時間に常に相対的であり、蓄積されない。 o セッションが数年間続く場合、1つのセッション告知で数年に値する調整を送 信するのではなく、セッション告知を定期的に修正することが予想される。 暗号化キー k=<メソッド> k=<メソッド>:<暗号化キー> o セッション記述プロトコルを使用して、暗号化キーを伝達することができる。 キーフィールドは、必要に応じて、最初のメディアエントリの前(この場合は セッション内の全メディアに適用される)、または各メディアエントリに許容 されている。 o キーの形式とその用法は、本文書の範囲外である。[3]を参照のこと。 o メソッドは、外部的な手段、またはエンコードされた暗号化キーがあればそこ から、使用できるキーを取得するときに使用されるメカニズムである。 次のメソッドが定義される。 k=clear:<暗号化キー> 暗号化キー(AVプロファイル以下のRTPメディアストリームの場合、[3]で記 述されるとおり)は、このキーフィールドで変換されないまま含まれる。 k=base64:<暗号化キー> 暗号化キー(AVプロファイル以下のRTPメディアストリームの場合、[3]で記 述されるとおり)は、このキーフィールドに含まれるが、base64でエンコー ド済みである。これは、SDPで禁止されている文字が含まれるためである。 k=uri:<キーを取得するURI> WWWクライアントが使用するURIがこのキーフィールドに含まれる。このURI はキーを含むデータを参照し、キーが返ってくる前に追加で認証が必要な Handley & Jacobson Standards Track [Page 17] RFC 2327 SDP April 1998 場合もある。リクエストが特定のURIに対して行われた場合、返ってくる MIMEコンテンツタイプで、返信のキーのエンコーディングが指定される。 ユーザーはセッションに参加する意思がなければ、キーを取得すべきではな い。これは、WWWサーバーに対するリクエストの同期を減らすためである。 k=prompt このSDP記述にはキーが含まれないが、このキーフィールドが参照するセッ ションまたはメディアストリームは暗号化される。ユーザーがセッションに 参加しようとすると、キーの入力が要求されるべきである。また、このユー ザーが入力したキーは、メディアストリームの復号に使用されるべきであ る。 属性 a=<属性> a=<属性>:<値> 属性は、SDPを拡張するための主な手段である。「セッションレベル」属性、 「メディアレベル」属性、またはその両方に使用する属性を定義できる。 メディア記述には、メディア固有の属性(「a=」フィールド)を複数指定してもよ い。これは、「メディアレベル」属性と呼ばれ、メディアストリームに関する情 報が追加される。属性フィールドは、最初のメディアフィールドの前に追加する こともできる。この「セッションレベル」属性は、個々のメディアではなく、カ ンファレンス全体に適用する追加情報を伝達する。一例を挙げると、カンファレ ンスのフロア制御ポリシーがある。 属性フィールドには2つの形式が考えられる。 o プロパティ属性(property attribute)。プロパティ属性は、単純に「a=<フラ グ>」という形式を持つ。これはバイナリ属性であり、この属性を示すと、 この属性がセッションのプロパティであることが伝達される。 一例を挙げると、「a=recvonly」。 o 値属性(value attribute)。値属性は、「a=<属性>:<値>」という形式を持つ。 一例を挙げると、ホワイトボードが「a=orient:landscape」という値属性を持 つ場合など。 属性の解釈は、呼び出されるメディアツールによって変わる。したがってセッ ション記述の受信側は、一般的な告知の解釈と特定の属性の解釈とを設定できる ようにすべきである。 属性名は、ISO-10646/UTF-8のサブセットであるUS-ASCIIの文字を使用しなけれ ばならない。 Handley & Jacobson Standards Track [Page 18] RFC 2327 SDP April 1998 属性値はバイト文字列であり、 0x00 (Nul)、0x0A (LF)、および0x0D (CR)以外 の任意のバイトを使用してもよい[MAY]。デフォルトで、属性値は、UTF-8エン コーディングのISO-10646文字セットに含まれると解釈すべきである。他のテキ ストフィールドとは異なり、属性値は、「charset」属性に影響を受けない [NOT]。これは、既知の値に対する比較の問題になるためである。ただし、属性 を定義するときに、文字セット依存に定義することができる。この場合、値は、 ISO-10646ではなくセッションの文字セットで解釈すべきである。 一般的に使用される属性は、IANAに登録することができる(付録B参照)。登録さ れていない属性は、登録済み属性と誤って重複しないように、先頭に「X-」を付 けるべきである。いずれの場合でも、理解できない属性を受信した場合、受信側 は単に無視すべきである。 メディアの告知 m=<メディア> <ポート> <トランスポート> セッション記述には、複数のメディア記述を含めることができる。各メディア記 述は「m=」フィールドで始まり、次の「m=」フィールドまたはセッション記述の 末尾で終了する。メディアフィールドには、複数のサブフィールドも含まれる。 o 最初のサブフィールドは、メディアタイプである。現時点で定義されているメ ディアは、「audio」、「video」、「application」、「data」、および 「control」だが、新しい通信様式が出現した場合は追加される可能性がある (telepresenseなど)。「application」と「data」の違いは、前者がホワイト ボード情報などのメディアフローなのに対し、後者はバルクデータ(ユーザー に通常は表示されない、マルチキャストの実行可能プログラムなど)の転送で ある点である。「control」は、そのセッションで追加のカンファレンス制御 チャネルを指定するときに使用される。 o 2つ目のサブフィールドは、メディアストリームを送信する伝送ポートであ る。伝送ポートの意味は、関連する「c」フィールドで指定きれているよう に、使用するネットワークによって変わる。また、3つ目のサブフィールドで 定義される伝送プロトコルによっても変わる。メディアアプリケーションが使 用するその他のポート([2]のRTCPなど)は、基本のメディアポートからアルゴ リズム的に配信すべきである。 注意：UDPに基づいたトランスポートのためには、値は、1024から65535を含む 範囲内になければならない。RTP準拠のため、値は偶数でなければならない。 Handley & Jacobson Standards Track [Page 19] RFC 2327 SDP April 1998 階層的にエンコードされたストリームがユニキャストアドレスに送られている アプリケーションでは、複数のトランスポートポートを指定することが必要 な場合がある。これは、「c=」フィールドのIPマルチキャストアドレスに使用 されているのと同等な記法を使って行える： m= / このような場合、使用されるポートはトランスポートプロトコルに依存する。 RTPにおいては、偶数値のポートだけがデータに使用され、それより1つ大きい 奇数値のポートがRTCPに使用される。 m=video 49170/2 RTP/AVP 31 上記の例では、ポート49170と49171が一組目のRTP/RTCPを形成しており、ポー ト49172と49173が二組目のRTP/RTCPを形成していることを示している。RTP/ AVPはトランスポートプロトコルであり、31は、その形式である(下記参照)。 1つのセッション記述内に複数のアドレスを「c=」フィールドで指定する のは不法である。また、1つのセッション記述内に複数のポートを「m=」 フィールドで指定することも不法である。 o 3番目のサブフィールドはトランスポートプロトコルである。トランスポート プロトコル値は、「c=」フィールド内の
フィールドによって決 まる。したがって、IP4の「c=」フィールドは、トランスポートプロトコルが IP4上で実行されることを定義する。IP4においては、通常、ほとんどのメディ アトラフィックがRTPとしてUDP上で伝達されることが期待されている。以下の トランスポートプロトコルは試験的に定義されているが、IANAへ新しいプロ トコルを登録する過程で拡張される可能性がある。 - RTP/AVP - UDP上で伝達される、Audio/Videoプロファイルを使ったIETFの RTP (Realtime Transport Protocol) - udp - UDP (User Datagram Protocol) アプリケーションが、独自のメディアフォーマットとトランスポートプロト コルを一つに結合してUDP上で使用する場合、単純に、トランスポートプロト コルをudpとして指定し、この結合されたプロトコルを区別するためにフォー マットフィールドを使用することが推奨される。セッションディレクトリに よって区別される必要がある、異なるいくつかのメディアタイプを伝達するた めに、UDP上でトランスポートプロトコルが使用される場合は、トランスポー トプロトコルとメディアフォーマットを別々に指定する必要がある。RTPは、 適切なツール、リレー、ミキサーまたはレコーダーの開始方法を知るために、 セッションディレクトリによって区別されなければならない、複数のペイロー ド形式を伝達するトランスポートプロトコルの例である。 Handley & Jacobson Standards Track [Page 20] RFC 2327 メディアフォーマットに加え、トランスポートプロトコルを指定する主な 理由は、たとえネットワークプロトコルが同じでも、一つの標準的なメディア フォーマットは、異なるトランスポートプロトコル上で伝達される場合もある からである。歴史的な一例として、vat(仮想アドレス変換機構) PCM audioと RTP PCM audioがあげられる。さらに、リレーとモニターツールでは、トラン スポートプロトコルは決まっているが、フォーマットには影響されないという のもある。 RTP Audio/Videoプロファイル下で運用するRTPメディアストリームにおいて は[3]、プロトコルフィールドは「RTP/AVP」である。他のRTPプロファイルが 将来的に定義された場合、それらのプロファイルも同様に指定されるであろ う。例えば、プロトコルフィールド「RTP/XYZ」は、「XYZ」という省略名称を もつプロファイル下で運用するRTPを指定する。 o 4番目と、4番目以降のサブフィールドはメディア形式である。オーディオと ビデオでは、通常、RTP Audio/Videoプロファイルで定義されるメディアペイ ロードタイプになるだろう。 ペイロード形式のリストが与えられるとき、これらすべての形式がセッション で使用されるかもしれないということを暗に意味しているが、リスト中の最初 の形式がセッションのデフォルト形式となる。 トランスポートプロトコルがRTP、もしくはUDPでないメディアにおいて、 フォーマットフィールドはプロトコル特有である。そのようなフォーマッ トは、追加仕様ドキュメントで定義されなければならない。 トランスポートプロトコルがRTPであるメディアにおいて、SDPは、メディ アエンコーディングの動的バインドをRTPペイロードタイプに提供するのに 使用することができる。RTP AVプロファイルのエンコード名は、固有のオー ディオエンコーディング(クロックレートとオーディオチャネルの数という 点で)を指定しないので、それらエンコード名は、SDPフォーマットフィー ルドでは直接使用されない。その代わりに、ペイロードタイプ番号は、静的 ペイロードタイプの形式を指定するのに使用されなければならない。また、 ペイロードタイプ番号は追加エンコーディング情報と共に、動的に割り当てら れたペイロードタイプに使用されなければならない。 静的ペイロードタイプの例は、8KHzでサンプリングされ、u-law PCMでコード 化された単一チャネルオーディオである。これは、RTP Audio/Videoプロファ イルで、ペイロードタイプ0として完全に定義されているため、UDPポート 49232に送られるストリームのメディアフィールドは以下のようになる。 m=video 49232 RTP/AVP 0 動的ペイロードタイプの例は、16KHzでサンプリングされ、16ビットリニアエ ンコードされたステレオオーディオである。そのようなストリームに、動 的RTP/AVPペイロードタイプ98を使用することを望むとき、そのデコードのた めに追加情報が必要とされる。 m=video 49232 RTP/AVP 98 Handley & Jacobson Standards Track [Page 21] RFC 2327 SDP April 1998 a=rtpmap:98 L16/16000/2 rtpmap属性の一般的なフォームは以下の通りである： a=rtpmap: /[/] オーディオストリームでは、はオーディオチャネル 数を指定する場合もある。このパラメータは、チャネル数が1であるならば省 略される場合もある。追加パラメータは不要である。ビデオストリームにお いては、現在、どのようなも指定されていない。 追加パラメータは、将来的に定義されるかもしれないが、コーデック特有 のパラメータを追加してはならない。rtpmap属性に加えられるパラメータ は、セッションに参加するのに適切なメディアも選択するために、セッショ ンディレクトリに必要とされるものだけでなければならない。コーデック特 有のパラメータは、他の属性に追加されなければならない。 指定される各メディアフォーマットのために、最大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 プロファイルがSDPと共に使用される場合、動的ペイロードタイプの使用方法 を指定するRTPプロファイルは、有効なエンコード名の組とエンコード名の登 録方法の両方あるいは片方を定義しなければならない。 rtpmapを使用することで、試験的なエンコード形式を指定することができる。 標準の形式名として登録されていないRTP形式は、「X-」で始めなければなら ない。ゆえに、動的ペイロードタイプ99を使用するGSMLPCと呼ばれる新しい 試験的な冗長オーディオストリームは、以下のように指定することができる： m=video 49232 RTP/AVP 99 a=rtpmap:99 X-GSMLPC/8000 このような試験的なエンコード形式を利用するには、このメディアストリーム を受けることを希望するサイトがどのツールを使えばいいかわかるように、サ イト内のセッションディレクトリを適切に設定された状態にする必要がある。 通常、RTPオーディオ形式は、1パケットあたりのサンプル数についての情報 を含んでいないことに注意しなさい。RTP Audio/Videoプロファイルで定義 されているような非デフォルトのパケット化が必要とされる場合、以下で定義 される「ptime」属性が使用される。 Handley & Jacobson Standards Track [Page 22] RFC 2327 RTP Audio/Video形式の詳細については、[3]を参照。 o 非RTPメディアの形式は、付録Bで説明されているようにMINEのcontent-type として登録されていなければならない。例えば、LBLホワイトボードアプリ ケーションは、特定のファイル形式を定めず、MIME content-type 「application/wb」として登録され、エンコーディングを考慮して、UDP上 で動作することを指定されるかもしれない。これは次に、SDPにおいては、 「media」フィールドと「fmt」フィールドの組み合わせを使用して以下のよ うに表現されるだろう。 m=application 32416 udp wb 提案されている属性 以下の属性が提案されている。 アプリケーションの作成者は、必要とする新し い属性を追加することもありえるので、以下の属性がすべてではない。 a=cat: この属性は、ドットで区切られた、セッションの階層的なカテゴリを与え る。これは、受信側が、カテゴリを使って必要ないセッションを取り除くこ とを可能にする。現時点で試験的な性質のものだということがなければ、必 須の独立したフィールドになっていたかもしれない。またこれはセッション レベル属性であり、「charset」に依存しない。 a=keywds: この属性は、前出のcat属性のように、受信側で必要とされるセッションを 識別することを補助する属性である。この属性は、セッションの目的につい て説明しているキーワードに基づいて、興味のあるセッションを、受信側に 選択させることを許可するセッションレベル属性である。これはまた、 「charset」に依存する属性である。つまり、この属性の値は、セッション 記述で「charset」が指定されていればそれに従って、デフォルトでは ISO 10646/UTF-8で解釈されなければならない。 a=tool: この属性は、セッション記述作成のために使用されたツールの名前とバー ジョン番号を与える。これはセッションレベル属性であり、「charset」 に依存しない。 a=ptime: この属性は、パケット内のメディアのミリ秒単位の時間長を与える。この属 性は、おそらく、オーディオデータにとってのみ意味がある。RTP、または vatオーディオをデコードするためにptimeを知ることが必要とされてはなら ない。また、オーディオのエンコード／パケット化のために推奨されること を予定している。これは、メディア属性であり、「charset」に依存しな い。 Handley & Jacobson Standards Track [Page 23] RFC 2327 SDP April 1998 a=recvonly この属性は、適用可能であれば、ツールが受信専用モードで開始されなけれ ばならないことを指定する。セッション属性、またはメディア属性のどちら にもなることが可能であり、「charset」に依存しない。 a=sendrecv この属性は、ツールが送受信モードで開始されなければならないことを指定 する。これは、受信専用モードをデフォルトとする、wbのようなツールを使 用する対話式カンファレンスにおいて必要である。セッション属性、または メディア属性のどちらにもなることが可能であり、「charset」に依存しない。 a=sendonly この属性は、ツールが送信専用モードで開始されなければならないことを指 定する。たとえば、トラフィックの宛先として、トラフィックの送信元とは 異なるユニキャストアドレスが使用される場合がある。そのような場合に は、2つのメディア記述が使用されることがあり、そのうちの1つはsendonly (送信専用)、もう1つはrecvonly(受信専用)として使用される。セッション 属性、またはメディア属性のどちらにもなることが可能であるが、通常は、 メディア属性としてのみ使用される。また、「charset」に依存しない。 a=orient: 通常、この属性はホワイトボードメディア仕様においてのみ使用される。 画面上のホワイトボードの向きを指定するメディア属性である。許可されて いる値は、「portrait(縦長)」、「landscape(横長)」、「seascape (landscapeを逆さまにしたもの)」である。「charset」に依存しない。 a=type: この属性は、カンファレンスのタイプを指定する。提案されている値は、 「broadcast」、「meeting」、「moderated」、「test」、「H332」であ る。「type:broadcast」セッションのデフォルトは「recvonly」でなければ ならない。「type:meeting」は、「sendrecv」を暗黙指定しなければならな い。「type:moderated」は、発言権制御ツールの使用を指示しなければなら ず、メディアツールは、カンファレンスに入会する新しいサイトを「mute」 するように、開始されなければならない。 属性type:H332を指定することは、この疎結合セッションが、ITU H.332規格 [10]で定義されている、H.332セッションの一部であることを示す。メディ アツールは、「recvonly」で開始されなければならない。 属性type:testを指定することは、受信側がこのセッション記述を、 ユーザーに表示することを(もし、別の方法で明確に要求されなければ)安全 に回避することができることを示す印として提案されている。 「type」属性はセッションレベル属性であり、「charset」に依存しない。 Handley & Jacobson Standards Track [Page 24] RFC 2327 SDP April 1998 a=charset: この属性は、セッション名と情報データの表示に使用する文字セットを指定 する。デフォルトでは、UTF-8エンコードのISO-10646文字セットが使用され る。さらにコンパクトに表したい場合、北欧言語用のISO-8859-1文字セット などが使用されることもある。特にISO 8859-1は、以下のSDP属性で指定 される。 a=charset:ISO-8859-1 これは、セッションレベル属性である。この属性を使用する場合、最初のメ ディアフィールドの前に存在しなければならない。指定される文字セット は、必ずIANAに登録されている、ISO-8859-1のような文字セットのうちの1 つでなければならない[MUST]。文字セットの識別子はUS-ASCII文字列とし、 必ずIANA識別子と大文字小文字を区別せずに比較しなければならない [MUST]。識別子が認識されないかサポートされないならば、それに影響を受 けるすべてのストリングは、バイトストリングとしてみなすべきである [SHOULD]。 指定される文字セットでは、必ず0x00 (Nul)、0x0A (LF)、0x0d (CR)の使用 を禁止しなければならない[MUST]ことに注意すること。これらの文字を使 用することを必要とする文字セットでは、これらの文字がテキストフィール ドに表示されることを防止するため、必ず引用メカニズムを定義しなければ ならない[MUST]。 a=sdplang: この属性は、セッションレベル属性、または、メディアレベル属性になるこ ができる。セッションレベル属性の場合には、セッション記述用の言語 を指定する。メディアレベル属性の場合には、メディアに関連するメディ アレベルSDP情報フィールド用の言語を指定する。一つのセッション記述 またはメディアの中にある複数の言語が多言語を使用するとき、複数の 「sdplang」属性をセッションレベルもしくはメディアレベルのどちらかで 提供することができる。その場合、属性の順序は、もっとも重要なものから そうでないものの順で、セッションまたはメディアの種々の言語の重要性を しめす。 一般に、多言語から構成されるセッション記述の送信はなされるべきではな い。その代わり、各言語につき1つのセッションを記述して、複数のセッ ションを送られなければならない。しかし、これはすべてのトランスポート メカニズムにおいて可能であるわけではない。そのため、推奨されてはいな いが、複数の「sdplang」属性が許可されている。 「sdpang」属性値は、US-ASCIIで表された、単一のRFC 1766言語タグでなけ ればならない。この属性は「charset」に依存しない。セッションが、地理 Handley & Jacobson Standards Track [Page 25] RFC 2327 SDP April 1998 的な境界を超えるのに十分な範囲のもので、受信者の言語が想定できない場 合、または地理的に想定されるのとは違う言語の場合、「sdplang」属性を 指定すべきである[SHOULD]。 a=lang: この属性は、セッションレベル属性、またはメディアレベル属性になること ができる。セッションレベル属性の場合には、記述されるセッションのデ フォルトの言語を指定する。メディアレベル属性の場合には、セッションレ ベルの言語指定を無効にし、そのメディア独自の言語を指定する。1つの SessionDescriptionまたはメディアの中にある複数の言語が多言語を使用す るとき、複数の「lang」属性をセッションレベルもしくはメディアレベルの どちらかで提供することができる。その場合、属性の順序は、もっとも重要 なものからそうでないものの順で、セッションまたはメディアの種々の言語 の重要性をしめす。 「lang」属性値は、US-ASCIIで表された、単一のRFC 1766言語タグでなけれ ばならない。この属性は「charset」に依存しない。セッションが、地理的 な境界を超えるのに十分な範囲のもので、受信者の言語が想定できない場 合、または地理的に想定されるのとは違う言語の場合、「lang」属性を指定 すべきである[SHOULD]。 a=framerate: この属性は、最大ビデオフレームレート(フレーム/秒)を与える。これは、 ビデオデータをエンコードするときの推奨とされている。 「.」という表記を使用した、10進の少数表記が許可さ れている。これは、ビデオメディアにおいてのみ定義されるメディア属性で あり、に依存しない。 a=quality: この属性は、エンコードするときの品質の提案を整数値で与える。 ビデオの「quality」属性の意図するものは、非デフォルトでの、フレーム レートと静止画像の品質の間のトレードオフを指定することである。ビデ オにおいては、提案されている以下の意味を持つ、0〜10の範囲内の値になる。 10 - 圧縮スキームが提供できる最良の静止画品質 5 - 品質の提案がない場合のデフォルトの動作 0 - コーデックの設計者が使用可能だと考える最低限の静止画品質 この属性はメディア属性であり、に依存しない。 Handley & Jacobson Standards Track [Page 26] RFC 2327 SDP April 1998 a=fmtp: この属性は、SDPが理解する必要のない方法で送られる、ある特定の形式の ためだけのパラメータを許可する。形式は、メディアのために指定される形 式のうちの1つでなければならない。形式特定のパラメータは、SDPによって 送られる必要があるパラメータの組でありえる。また、この形式を使用す るメディアツールに変更なしで渡される。 この属性はメディア属性であり、に依存しない。 6.1. カンファレンス制御ポリシーの伝達 カンファレンス制御ポリシーを伝える方法に関するいくつかの論議が存在する。 一般に、作成者達は、可能な場合は、カンファレンス制御を指定する暗黙宣言 スタイルが望ましいと信じている。 単純な宣言スタイルは、最初のメディアフィールドの前に単一のカンファレン ス属性フィールドを使用する。これは、おそらくは、いくつかのメディアツール のへの「recvonly」のようなプロパティーによって補われる。このカンファレン ス属性は、カンファレンス制御ポリシーを送る。例としては以下のようなものが ある： a=type:moderated しかし、場合によっては、この属性が、通常とは異なるカンファレンス制御ポリ シーの詳細を伝えるのに不十分なことがある。この場合、外部制御を指定するカ ンファレンス属性が設定されるかもしれない。そしてそれから、1つまたは1つ以 上の「メディア」フィールドが、カンファレンス制御ツールの指定と、それらツー ルの設定データの指定に使用されるかもしれない。以下は、ITU H.332セッション における例である： c=IN IP4 224.5.6.7 a=type:H332 m=audio 49230 RTP/AVP 0 m=video 49232 RTP/AVP 31 m=application 12349 udp wb m=control 49234 H323 mc c=IN IP4 134.134.157.81 この例では、汎用カンファレンス属性(type:H332)が、カンファレンス制御が外 部のH.332ツールによって提供されることを指定し、H.323セッションマルチポイ ントコントローラーの連絡先アドレスが与えられている。 このドキュメントでは、カンファレンス制御宣言の宣言スタイルのみが詳解され ている。他のカンファレンス制御形式は、適切なtype属性を指定し、また、コン トロールメディアとの関わりを定義しなければならない。 Handley & Jacobson Standards Track [Page 27] RFC 2327 SDP April 1998 7. セキュリティの考慮 SDPは、マルチメディアセッションを記述する、セッション記述形式である。 セッション記述は、信頼できるところからの認証されたトランスポートプ ロトコルによって取得されていない場合、信頼してはいけない。多くの、異なる トランスポートプロトコルが、セッション記述の配布に使用されるかもし れない。また、認証の種類は、トランスポートプロトコルによって異なる。 セッション記述の配布に頻繁に使用されるトランスポートプロトコルは、セッ ション告知プロトコル(SAP)である。SAPは、暗号化と認証の両方のメカニズムを 提供するが、セッション告知の性質から、セッション告知の発信元は、その受信 者に前もって知られていなかったり、共通の公開鍵のインフラストラクチャーが 利用可能でなかったりするため、認証されることができないという多くの場合が ありうる。 認証されないトランスポートメカニズムで、または信頼できない相手から セッション記述を受けるとき、セッションを解析するソフトウェアは、い くつかの注意を払わなければならない。セッション記述は、受信側システ ムのソフトウェアを開始するために必要な情報を含んでいる。セッション記述 を解析するソフトウェアは、マルチメディアセッションに参加する 適切なソフトウェアとして特に設定されたソフトウェア以外は、絶対に開始でき てはならない[MUST]。通常、セッション記述を解析するソフトウェアが ユーザーのシステム上で、マルチメディアセッションに参加するのに適切なソフ トウェアを、(あらかじめユーザーにそのようなソフトウェアが開始されること を知らせ、同意を得ることなしに)開始することは適切ではない[INAPPROPREATE] とされている。したがって、セッション告知、E-mail、セッションの招待、WWW ページによって送られてくるセッション記述は、ユーザーに知らせずに、その ユーザーを{it interractive}マルチメディアセッションに送り込んではならな い[SHOULD NOT]。セッションが対話式であるかどうかを見分けることは常に簡単 というわけではないので、どちらなのか判別できないアプリケーションは、セッ ションが対話式であると想定するべきである。 この仕様では、送信することがデフォルトモードであるマルチメディアツールを 開始することを、セッション記述の受信者に知らせることを許可する属性 は存在しない。いくつかの状況下では、そのような属性を定義することは適切 であるかもしれない。そうしたときには、そのような属性を含むSession Descriptionを解析するアプリケーションは、それらを無視するか、このセッ ションに加入するとマルチメディアデータを自動的送ることになる旨ユーザー に知らせるべきである[SHOULD]。不明な属性に対するデフォルトの動作は、それ を無視することである。 Handley & Jacobson Standards Track [Page 28] RFC 2327 SDP April 1998 セッション記述は、マルチメディアセッションへの参加を許可するために、 ファイアウォールに穴をあける目的で、ファイアウォールなどの中間システムで 解析されるかもしれない。セッション記述がファイアウォールの内側から の要求としてやってくるのでなければ、ユニキャストのデータストリームを流す ためにそのような穴をあけることは、ファイアウォールにとって不適切である [INAPPROPRIATE]とされている。 マルチキャストセッションにおいて、ローカルの管理者が、独自のポリシーを適 用することがありえる。しかし、ファイアウォールの内側での、「local」、 「site-local」という管理適応範囲の排他的使用と、そのような適応範囲のため に穴をあけることをファイアウォールが拒否するのは、ローカルのマルチキャス トセッションとグローバルのマルチキャストセッションを分離することになる。 Handley & Jacobson Standards Track [Page 29] RFC 2327 SDP April 1998 付録A: SDP文法 この付録では、SDPのAugmented BNF文法を提供する。ABNFは、RFC 2234で 定義されている。 announcement = 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 = "v=" 1*DIGIT CRLF ;このメモはバージョン０における記述である origin-field = "o=" username space sess-id space sess-version space nettype space addrtype space addr CRLF session-name-field = "s=" text CRLF information-field = ["i=" text CRLF] uri-field = ["u=" uri CRLF] email-fields = *("e=" email-address CRLF) phone-fields = *("p=" phone-number CRLF) connection-field = ["c=" nettype space addrtype space connection-address CRLF] ;connection fieldは、すべてのメディア記述、 ;またはセッションレベルにおいて存在しなけ ;ればならない bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) Handley & Jacobson Standards Track [Page 30] RFC 2327 SDP April 1998 time-fields = 1*( "t=" start-time space stop-time *(CRLF repeat-fields) CRLF) [zone-adjustments CRLF] repeat-fields = "r=" repeat-interval space typed-time 1*(space typed-time) zone-adjustments = time space ["-"] typed-time *(space time space ["-"] typed-time) key-field = ["k=" key-type CRLF] key-type = "prompt" | "clear:" key-data | "base64:" key-data | "uri:" uri key-data = email-safe | "~" | " attribute-fields = *("a=" attribute CRLF) media-descriptions = *( media-field information-field *(connection-field) bandwidth-fields key-field attribute-fields ) media-field = "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF media = 1*(alpha-numeric) ;通常、「audio」、「video」、「application」、 ;または、「data」 fmt = 1*(alpha-numeric) ;通常、オーディオおよびビデオメディアの ;RTPペイロードタイプ Handley & Jacobson Standards Track [Page 31] RFC 2327 SDP April 1998 proto = 1*(alpha-numeric) ;通常、IP4の「RTP/AVP」、または、「udp」 port = 1*(DIGIT) ;UDPベースのメディアでは、1024〜65535 ;の範囲でなければならない attribute = (att-field ":" att-value) | att-field att-field = 1*(alpha-numeric) att-value = byte-string sess-id = 1*(DIGIT) ;これの送信元username/hostでユニークでなければ ;ならない sess-version = 1*(DIGIT) ;ゼロ(0)のときは新しいセッションである connection-address = multicast-address | addr multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl [ "/" integer ] ;マルチキャストアドレスは、224.0.0.0〜 ;239.255.255.255の範囲にある ttl = decimal-uchar start-time = time | "0" stop-time = time | "0" time = POS-DIGIT 9*(DIGIT) ;2世紀にわたる期間を表すのに十分な値である repeat-interval = typed-time Handley & Jacobson Standards Track [Page 32] RFC 2327 SDP April 1998 typed-time = 1*(DIGIT) [fixed-len-time-unit] fixed-len-time-unit = "d" | "h" | "m" | "s" bwtype = 1*(alpha-numeric) bandwidth = 1*(DIGIT) username = safe ;広範囲の定義が可能だが、スペースを含んではいけない email-address = email | email "(" email-safe ")" | email-safe "<" email ">" email = ;RFC822で定義されている uri= ;RFC1630で定義されている phone-number = phone | phone "(" email-safe ")" | email-safe "<" phone ">" phone = "+" POS-DIGIT 1*(space | "-" | DIGIT) ;国際コードと残りの番号の間は、 スペース、 ;または、ハイフンでなければならない nettype = "IN" ;このリストは拡張される addrtype = "IP4" | "IP6" ;このリストは拡張される addr = FQDN | unicast-address FQDN = 4*(alpha-numeric|"-"|".") ;RFC1035で指定されている絶対ドメイン名 Handley & Jacobson Standards Track [Page 33] RFC 2327 SDP April 1998 unicast-address = IP4-address | IP6-address IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 b1 = decimal-uchar ;224未満 ;127と0は使用できない b4 = decimal-uchar ;0は使用できない IP6-address = ;今後定義される text = byte-string ;デフォルトでは、IS0-10646 UTF8として解釈される ;ISO 8859-1には、「a=charset:ISO-8859-1」セッション ;レベル属性が使用される必要がある byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) ;NUL、CR、LF以外のバイト decimal-uchar = DIGIT | POS-DIGIT DIGIT | ("1" 2*(DIGIT)) | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) integer = POS-DIGIT *(DIGIT) alpha-numeric = ALPHA | DIGIT DIGIT = "0" | POS-DIGIT POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"| "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"| "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"| "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" Handley & Jacobson Standards Track [Page 34] RFC 2327 SDP April 1998 email-safe = safe | space | tab safe = alpha-numeric | "'" | "'" | "-" | "." | "/" | ":" | "?" | """ | "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | "~" | " space = %d32 tab = %d9 CRLF = %d13.10 Handley & Jacobson Standards Track [Page 35] RFC 2327 SDP1998年4月 付録B: IANAにSDP名を登録するためのガイドライン IANAに登録されるかもしれない７つのフィールド名がある。それらは、SDP仕様 のBNF用語で表すと、「media」、「proto」、「fmt」、「att-field」、 「bwtype」、「nettype」、「addrtype」である。 "media" (例：audio、video、application、 data). RTPで使用されているような、パケット化されたメディアタイプは、メディ アタイプレジストリ(参考文献 [RFC 2048])(例：MIMEタイプ)によって使用 される名前空間を共有する。有効なメディア名のリストは、トップレベルの MINE content-typeである。メディアは小さくされており、まれな状況化を 除き、拡張されることを意図していない。(MINEのサブタイプは、下記の 「fmt」パラメータに対応する) "proto" 一般に、「proto」は、RTP/AVP(rfc 1890プロファイル下のrfc 1889)など のような、IETF標準化過程のトランスポートプロトコル識 別子でなければならない。 しかし、それぞれ独自のトランスポートプロトコルを考案したいと思うこ とがあるだろう。これらのうちのいくつかは、プロトコルとして「udp」を 使い、「fmt」で登録されなければならない。また、それ以外のいくつかは 恐らく登録することはできない。 UDP上で独自の特別用途のプロトコルを使うLBLホワイトボードwbのように、 プロトコルとアプリケーションが密接に結びついている場合には、プロトコ ル名は「udp」で、登録されなければならない形式名は、「wb」でなければ ならない。形式のルール(下記参照)は、このような登録に適用する。 独自のトランスポートプロトコルが、実際に多くの異なるデータ形式を伝 達する場合には、IANAに新しいプロトコル名を登録することができる。そ のような場合、このプロトコルを記述したRFCが提供され、登録時に参照さ れなければならない[MUST]。そのようなRFCは、標準化過程であること が望ましいが、そうでなくとも情報源として活用してもよい[MAY]。 "fmt" 形式の名前空間は、「proto」フィールドの内容に依存する。そのため、形式 を適用する1つ以上のトランスポートプロトコルを指定しないと、登録する ことができない。 形式は、マルチメディアセッションでの送信が望まれることがあるすべての エンコーディングをカバーしている。 Handley & Jacobson Standards Track [Page 36] RFC 2327 SDP April 1998 静的ペイロードタイプが割り当てられたRTP形式では、ペイロードタイプ番号 が使用される。動的ペイロードタイプ番号を使用するRTP形式では、動的ペイ ロードタイプ番号は形式として与えられる。そして付加的に、rtpmap属性が 形式とパラメータを指定する。 非RTP形式では、登録されていない形式名はMIMEタイプ登録プロセス (RFC 2048参照)を通して登録されることがある。ここで与えられるタイプ はMIMEサブタイプのみである(トップレベルのMIME content-typeは、メディ アパラメータによって指定される)。MIMEタイプの登録は、このメディアタ イプのためのトランスポートプロトコルを記述するスタンダードトラッ クRFCを参照すべきである[SHOULD]。この形式のためのMIMEタイプが 存在するときは、そのMIME登録は、このメディアタイプのトランスポート 仕様を参照するために拡大されなければならない。この形式のためのMIMEタ イプが存在していていなく、適切なファイル形式が存在しない場合は、「適 切なファイル形式がない」として、エンコード時に考慮されるべきことの中 に示されなければならない。 "att-field" (属性名) 必須ではないが、属性フィールド名はIANAに登録してもよい[MAY]。 また、未知の属性は単に無視される。 属性を登録するときは、必ず以下の事柄についての簡潔な仕様を添えなけれ ばならない： ・連絡先の名前、E-mailアドレス、および電話番号 ・属性名(SDPに現れる名前) ・英語で書かれた、長い形式の属性名 ・属性のタイプ (セッションレベル、メディアレベル、またはその両方) ・属性値が、「charset」属性に依存するかどうか ・属性の目的を説明する一節 ・この属性のための、適切な属性値の仕様 IANAは、属性登録が既存の登録と衝突しないことを保証するが、それが健全 であるかどうかはチェックしない。 Handley & Jacobson Standards Track [Page 37] RFC 2327 SDP April 1998 上記は、IANAが受理する最低限の仕様である。登録しようとする属性が広 範囲で使用されることが期待され、相互運用性が重要となる場合、立案者 は、その属性をより詳細に述べた標準化過程のRFCを提出するこ とが奨励されている。 登録書を提出する人は、その属性の仕様がSDP属性の精神に則ったものである ことを保証しなければならない。SDP属性の精神に則った属性は、特に、オペ レーティングシステムについて暗黙の推測を行わないという意味において、 プラットフォーム非依存である。そしてまた、相互運用性を抑制するかもし れないので、特定のソフトウェアを指定しない。 "bwtype" (帯域幅指定子) 帯域幅指定子を増やすことは、強く推奨されていない。 新しい帯域幅指定子がIANAに登録されることがある。登録のための提出書 は、その帯域幅指定子の意味論を詳細に指定し、その帯域幅指定子がどんな ときに使われるべきかを示し、なぜ登録されている既存の帯域幅指定子では 不十分なのかを示した標準化過程のRFCを、必ず参照しなければな らない[MUST]。 "nettype" (ネットワークタイプ) SDPが非インターネット環境という状況で使用される必要があるならば、 新しいネットワークタイプがIANAに登録されることもありえる。これは通常 IANAの管轄外である一方、インターネット電話の通話をゲートウェイ経由で PSTNに流すときのように、インターネットアプリケーションを非インターネッ トアプリケーションと相互に運用する必要があるとき、新しいネットワーク タイプをIANAに登録するという状況が起こりえる。ネットワークタイプの数 は少なくなければならず、稀にしか拡張されてはいけない。新しいネット ワークタイプは、そのネットワークタイプで使用される少なくとも1つのアド レスタイプが登録されていなければ、登録することができない。新しいネッ トワークタイプの登録は、そのネットワークタイプとアドレスタイプの詳細 を与え、それらがいつどのように使用されるかという指定があるRFCを参照し なければならない[MUST]。そのようなRFCを情報源にしてもよい[MAY]。 "addrtype" (アドレスタイプ) 新しいアドレスタイプがIANAに登録されることもありえる。アドレスタイプ は、ネットワークタイプにおいてのみ意味も持つ。アドレスタイプの登録は、 登録されているネットワークタイプを指定しなければならない[MUST]。 または、ネットワークタイプの登録と共に提出されなければならない[MUST]。 新しいアドレスタイプ登録は、そのアドレスタイプのシンタックスの詳細を 与えるRFCを参照しなければならない[MUST]。そのようなRFCを情報源に してもよい[MAY]。アドレスタイプが頻繁に登録されることは期待されて いない。 Handley & Jacobson Standards Track [Page 38] RFC 2327 SDP April 1998 登録手順 SDP名を登録するためには、必要となる、要求されるレベルのドキュメントを考 慮して、上記のガイドラインに従わなければならない。登録書自体は、IANAに送 付されなければならない。属性登録書は、上で与えられた情報を含まなければな らない。他の登録書は、以下の追加情報を含まなければならない： ・連絡先の名前、E-mailアドレス、および電話番号 ・登録されるSDP名(SDPに現れる名前) ・英語で書かれた長い形式のSDP名 ・SDP名のタイプ (「media」、「proto」、「fmt」、「bwtype」、「nettype」、 または「addrtype」) ・登録されるSDP名の目的を説明する一節 ・登録されるSDP名の仕様を参照するもの(例：RFC番号) IANAはレビューのために、IESG、または適切なIETFワーキンググループの登録を 参照することがある。また、登録される前に改定を要求することもある。 Handley & Jacobson Standards Track [Page 39] RFC 2327 SDP April 1998 付録C: 著者の連絡先 Mark Handley Information Sciences Institute c/o MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 United States electronic mail: mjh@isi.edu Van Jacobson MS 46a-1121 Lawrence Berkeley Laboratory Berkeley, CA 94720 United States electronic mail: van@ee.lbl.gov 謝辞 IETF MMUSICワーキンググループに参加する多くの人々が、コメントと提案を 本文書に寄せてくださった。特に、Eve Schooler、Steve Casner、Bill Fenner、Allison Mankin、Ross Finlayson、Peter Parnes、Joerg Ott、Carsten Bormann、Rob Lanphier、Steve Hannaに感謝を述べたい。 参考文献 [1] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992. [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996 [4] Handley, M., "SAP - Session Announcement Protocol", Work in Progress. [5] V. Jacobson, S. McCanne, "vat - X11-based audio teleconferencing tool" vat manual page, Lawrence Berkeley Laboratory, 1994. [6] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996. Handley & Jacobson Standards Track [Page 40] RFC 2327 SDP April 1998 [7] ISO/IEC 10646-1:1993. International Standard -- Information technol- ogy -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Five amendments and a techn- ical corrigendum have been published up to now. UTF-8 is described in Annex R, published as Amendment 2. [8] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641, July 1994. [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Receiving Internet-based H.323 Conferences", ITU, Geneva. [11] Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation Protocol (SIP)", Work in Progress. [12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Handley & Jacobson Standards Track [Page 41] RFC 2327 SDP April 1998 完全な著作権表示 Copyright (C) The Internet Society (1998).All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた派生 的製品や、この文書を説明したり、その実装を補助するもので、上記の著作権表 示およびこの節を付加するものはすべて、全体であってもその一部であっても、 いっさいの制約を課されること無く、準備、複製、発表、配布することができ る。しかし、この文書自体にはいかなる方法にせよ、著作権表示やインターネッ ト協会もしくは他のインターネット関連団体への参照を取り除くなどの変更を加 えてはならない。インターネット標準を開発するために必要な場合は例外とされ るが、その場合はインターネット標準化過程で定義されている著作権のための手 続きに従わなければならない。またRFCを英語以外の言語に翻訳する必要がある 場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくはその 継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネット 協会およびIETFは、この情報がいかなる権利も侵害していないという保証、商用 利用および特定目的への適合性への保証を含め、また、これらだけに限らずすべ ての保証について、明示的もしくは暗黙的の保証は行われない。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Handley & Jacobson Standards Track [Page 42]