セッション記述プロトコル(SDP )は、告知や招待を目的としたマルチメディア通信セッションを記述するためのフォーマットです。 [ 1 ]主な用途は、 VoIP(Voice over IP )やビデオ会議などのストリーミングメディアアプリケーションのサポートです。SDP自体はメディアストリームを配信しませんが、エンドポイント間でネットワークメトリック、メディアタイプ、その他の関連プロパティのネゴシエーションに使用されます。プロパティとパラメータのセットはセッションプロファイルと呼ばれます。
SDPは、新しいメディアタイプやフォーマットをサポートするために拡張可能です。SDPは元々セッションアナウンスメントプロトコル(SAP)[ 2 ]のコンポーネントでしたが、リアルタイムトランスポートプロトコル(RTP)、リアルタイムストリーミングプロトコル(RTSP)、セッション開始プロトコル(SIP)と組み合わせて、またマルチキャストセッションを記述するためのスタンドアロンプロトコルとして、他の用途も見つかりました。
IETFは、1998年4月に提案標準として最初の仕様を公開しました(RFC 2327)。[ 3 ]改訂仕様は2006年(RFC 4566) [ 1 ]と2021年(RFC 8866) [ 4 ]に公開されました。
セッション記述プロトコルでは、セッションをテキストベースの形式でフィールドのグループとして記述します。1行に1つのフィールドが記述されます。[注1 ]各フィールドの形式は次のとおりです。
<文字>=<値><CR><LF>
ここで、は大文字と<character>小文字を区別する単一の文字であり、は文字に依存する形式の構造化テキストです。値は通常UTF-8でエンコードされます。[注 2 ]等号のすぐ両側に空白文字を入れることはできません。 [ 1 ]:セクション 5<value>
セッション記述は、セッション、タイミング、メディア記述の 3 つのセクションで構成されます。各記述には、複数のタイミング記述とメディア記述が含まれる場合があります。名前は、関連する構文構造内でのみ一意です。[ 5 ]
項目は表示されている順序で入力する必要があります。オプション項目にはアスタリスク(*)が付いています。
v = (プロトコルバージョン番号、現在は0のみ) o = (発信者とセッション識別子: ユーザー名、ID、バージョン番号、ネットワークアドレス) s=(セッション名:必須。少なくとも1文字はUTF-8エンコード文字) i=*(セッションタイトルまたは簡単な情報) u=* (説明のURI) e=*(連絡先のメールアドレス(0個以上、名前は任意)) p=*(0個以上の電話番号と、オプションで連絡先名) c=*(接続情報 - すべてのメディアに含まれている場合は不要) b=*(帯域幅情報行が0本以上) 1つ以上の時間記述("t=" 行と "r=" 行。下記参照) z=*(タイムゾーン調整) k=*(暗号化キー) a=*(セッション属性行が0行以上) メディアの説明は0個以上(それぞれ「m="」行で始まります。下記参照)
t = (セッションがアクティブな時間) r=*(0回以上の繰り返し)
m = (メディア名と輸送先住所) i=*(メディアのタイトルまたは情報フィールド) c=*(接続情報 - セッションレベルに含める場合は省略可能) b=*(帯域幅情報行が0本以上) k=*(暗号化キー) a=*(メディア属性行が0行以上 - セッション属性行を上書きします)
以下はRFC 4566からのセッション記述のサンプルです。このセッションは、IPv4アドレス10.47.16.5のユーザー「jdoe」によって開始されました。セッション名は「SDP Seminar」で、拡張セッション情報(「セッション記述プロトコルに関するセミナー」)と、追加情報へのリンク、および担当者であるJane Doeに連絡するための電子メールアドレスが含まれています。このセッションはNTPタイムスタンプを使用して2時間継続するように指定されており、接続アドレス(クライアントが接続する必要があるアドレス、またはマルチキャストアドレスが提供されている場合(この例では)購読する必要があるアドレス)はIPv4 224.2.17.12で、TTLは127です。このセッション記述の受信者は、メディアのみを受信するように指示されています。2つのメディア記述が提供されており、どちらもRTPオーディオビデオプロファイルを使用しています。 1つ目は、RTP/AVPペイロードタイプ0(RFC 3551でPCMUとして定義)を使用するポート49170のオーディオストリーム、2つ目は、RTP/AVPペイロードタイプ99(「dynamic」として定義)を使用するポート51372のビデオストリームです。最後に、RTP/AVPペイロードタイプ99を90kHz クロックレートのh263-1998フォーマットにマッピングする属性が含まれています。オーディオストリームとビデオストリームのRTCPポートは、それぞれ49171と51373で暗黙的に指定されます。
v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDPセミナー i=セッション記述プロトコルに関するセミナー u= http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (ジェーン・ドゥ) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=オーディオ 49170 RTP/AVP 0 m=ビデオ 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
SDP仕様は、セッション記述のための純粋なフォーマットです。SA P、SIP、RTSPなど、必要に応じて様々なトランスポートプロトコルを介して配信されることを想定しています。SDPは電子メールやHTTPペイロードとして送信することも可能です。
SDPは属性を使用してコアプロトコルを拡張します。属性はセッションセクションまたはメディアセクション内に出現し、セッションレベルまたはメディアレベルとして適切にスコープされます。新しい属性は、IANAへの登録を通じて標準に随時追加されます。[ 6 ]
属性とは、プロパティまたは値のどちらかです。
これらの属性のうち2つは特別に定義されています。
どちらの場合も、ユーザーに表示されることを意図したテキストフィールドは不透明な文字列として解釈されますが、現在のメディアセクション内のcharset フィールドとsdplangフィールドの最後の出現箇所で示された値、またはセッションセクション内のそれらの最後の値を使用して、ユーザーまたはアプリケーションにレンダリングされます。
パラメータv、s、およびoは必須であり、空であってはならず、UTF-8 でエンコードする必要があります。これらは識別子として使用され、ユーザーに表示されることを想定していません。
例には他にもいくつかの属性が存在し、セッションレベルの属性(プロパティ形式の属性a=recvonlyなど)[注 3 ]またはメディアレベルの属性(例のビデオの値形式の属性a=rtpmap:99 h263-1998/90000など)として存在します。
絶対時刻は、ネットワークタイムプロトコル(NTP)形式(1900年からの秒数)で表されます。停止時刻が0の場合、セッションは無制限です。開始時刻も0の場合、セッションは永続的とみなされます。無制限セッションと永続セッションは推奨されませんが、禁止されているわけではありません。間隔は、NTP時刻または型付き時刻(値と時間単位(日: d、時間:h、分:m、秒:s)のシーケンス)で表すことができます。
したがって、2010年8月1日午前10時(UTC)から始まる1時間の会議と、1週間後の同じ時刻に1回繰り返される会議は、次のように表すことができます。
t= 1280656800 1281265200 r=604800 3600 0
または、入力した時間を使用する:
t= 1280656800 1281265200 r=7日1時間0
繰り返し時間が指定されている場合、開始時刻から終了時刻までの期間全体を通して、特定のタイムゾーンで同じ現地時刻になるように、各繰り返しの開始時刻を夏時間の変更に合わせて調整する必要がある場合があります。
このタイムゾーンを指定して、夏時間調整がいつどこで必要になるかを知るためのタイムゾーンのデータベースをサポートする代わりに、繰り返し時刻はすべて同じタイムゾーン内で定義されているものと想定され、SDP は、夏時間オフセット (秒単位またはタイプ時刻を使用) を、各夏時間調整時またはそれ以降に発生する繰り返し開始時刻または終了時刻に適用する必要がある場合の NTP 絶対時刻の指定をサポートします。これらのオフセットはすべて開始時刻に対する相対値であり、累積的ではありません。NTP は、フィールドzを使用してこれをサポートします。フィールド z は、最初の項目が夏時間調整が発生する NTP 絶対時刻であり、2 番目の項目がフィールドrで計算された絶対時刻に対する適用オフセットを示す一連のペアを示します。
例えば、2010年10月31日 午前3時(UTC)に夏時間調整によって1時間が減算される場合(つまり、2010年8月1日(日曜日)午前10時(UTC)の開始時刻から60日後から7時間後)、そしてこれが2010年8月1日から2010年11月28日午前10時 (毎週同じ現地時間に繰り返される1時間のセッションの終了時刻で、88日後)までのスケジュール期間中に適用される唯一の夏時間調整である場合、次のように指定できます。
t = 1280656800 1290938400 r=7日1時間0 z= 1288494000 -1h
週1時間のセッションを1年間、つまり2010年8月1日(日)午前3時(UTC)から2011年6月26日(日)午前4時(UTC)(最後の繰り返しの終了時刻、つまり360日+1時間後、または31107600秒後)まで毎週日曜日に繰り返した場合、2011年3月27日(日) 午前2時の夏時間への移行が含まれることになります(現地時間に再び1時間が加算されるため、2回目の夏時間への移行は最初の開始時刻から209日後に発生します)。
t = 1280656800 1290938400 r=7日1時間0 z= 1288494000 -1h 1269655200 0
繰り返しセッションの SDP アナウンスは数年を超える非常に長い期間を対象とすべきではないため、z= パラメータに含める日照調整の数は少なく抑えるべきです。
セッションは週を通して不規則に繰り返される場合がありますが、rパラメータにタプルを追加することで、期間内のすべての週で同じ方法でスケジュールできます。たとえば、同じイベントを土曜日にも(同じ時間帯に)スケジュールするには、次のようにします。
t = 1280656800 1290938400 r=7日1時間06日 z= 1288494000 -1h 1269655200 0
SDPプロトコルは、このような単純な繰り返し時間による月次および年次のセッションの繰り返しをサポートしていません。これは、セッションの間隔が不規則であるためです。代わりに、各月または各年ごとに、追加のt / rタプルを提供することができます。