メインコンテンツまでスキップ

3. SDP定義

3.1. プロファイル定義​

RFC 3551 [2]、RFC 4585 [3]、およびRFC 3711 [4]で定義されたAVプロファイルは、例えばセッション記述プロトコル（SDP）[3]の文脈では、それぞれ「AVP」、「AVPF」、および「SAVP」と呼ばれます。このドキュメントで規定されている複合プロファイルは「SAVPF」と呼ばれます。

3.2. 属性定義​

SAVPセッションを交渉するためのSDP属性は、RFC 4567 [7]およびRFC 4568 [8]で定義されています。これらの属性はSAVPFでも使用してもよい（MAY）。[7]および[8]で定義されたルールが適用されます。

AVPFセッションを交渉するためのSDP属性は、RFC 4585 [3]で定義されています。これらの属性はSAVPFでも使用してもよい（MAY）。[3]で定義されたルールが適用されます。

3.3. プロファイル交渉​

RTPセッションのセッション記述は、セッション開始プロトコル（SIP）[15]で使用されるSDPオファー/アンサーモデル（RFC 3264、[9]）、リアルタイムストリーミングプロトコル（RTSP）[10]、またはセッション告知プロトコル（SAP）[11]などのマルチメディア通信専用のプロトコルを使用して伝達される場合がありますが、電子メール、ネットニュース、ウェブページなどを使用して配信される場合もあります。

オファー/アンサーモデルでは、RFC 4567 [7]およびRFC 4568 [8]で定義されたSDP属性を使用して、結果として得られるセッションパラメータを交渉できます。次のサブセクションでは、オファー/アンサーモデルの観点から交渉プロセスを説明します。

その後、オファー/アンサーモデルを使用しないケースについて扱います。RTSP固有の交渉サポートは、セクション3.3.2で説明するようにRFC 4567 [7]によって提供され、SAP告知（交渉は一切なし）のサポートはセクション3.3.3で扱われます。

3.3.1. セッション記述のオファー/アンサーベースの交渉​

交渉（RTPプロファイル、コーデック、トランスポートアドレスなど）は、メディアセッションごと（SDPのm=行ごとなど）に行われます。1つのメディアセッションの交渉が失敗しても、他のセッションは成功する可能性があります（MAY）。

異なるRTPプロファイルを、異なるメディアセッションで使用してもよい（MAY）。メディア記述の交渉において、AVP、AVPF、SAVP、およびSAVPFの4つのプロファイルは相互に排他的です。ただし、SAVPエンティティとSAVPFエンティティを単一のRTPセッションで混合してもよい（MAY）ことに注意してください（セクション4を参照）。また、オファー/アンサーメカニズムを使用して、同じメディアセッションに対して代替案を提示し、アンサー側がいずれかのプロファイルを選択できるようにしてもよい（MAY）。

代替のセキュリティプロファイルを提示するためのメカニズムが利用可能になれば（現在開発中 [14]）、特定のメディアセッションに対してこれらのプロファイルのうち複数をサポートできるオファー側は、特定の状況で受け入れ可能なすべての選択肢を常に提示すべきです（SHOULD）。選択肢は優先順位に従ってリストされるべきであり（SHOULD）、オファー側は非セキュアなプロファイルよりもセキュアなプロファイルを優先すべきです（SHOULD）。オファーには、同じオファー内にセキュアな選択肢（SAVPおよびSAVPF）と非セキュアな選択肢（AVPおよびAVPFなど）の両方を含めるべきではありません（SHOULD NOT）。これは、ビッディングダウン（格下げ攻撃）やその他の攻撃を可能にする可能性があるためです。したがって、セキュアなRTPプロファイルと非セキュアなRTPプロファイルの両方が提示される場合（ベストエフォートSRTP [14]など）、そのような攻撃を避けるために交渉シグナリングを適切に保護しなければなりません（MUST）。

オファーに複数の代替プロファイルが含まれている場合、アンサー側は、非セキュアなものよりもセキュアなプロファイル（サポートされている場合）を優先すべきです（SHOULD）。セキュアまたは非セキュアなプロファイルの間で、アンサー側は、オファー側の優先順位を尊重するために、最初に受け入れ可能な代替案を選択すべきです（SHOULD）。

オファー内のメディア記述がSAVPFを使用しており、アンサー側がSAVPFをサポートしていない場合、メディアセッションを拒否しなければなりません（MUST）。

オファー内のメディア記述がSAVPFを使用していないが、アンサー側がSAVPFを使用したい場合、アンサー側はメディアセッションを拒否しなければなりません（MUST）。アンサー側は、その後に開始されるオファー/アンサー交換において、SAVPFを示すメディア記述を含むカウンターオファーを提供してもよい（MAY）。

3.3.2. セッション記述のRTSPベースの交渉​

RTSP [10]は、オファー/アンサーモデルをサポートしていません。ただし、RTSPは、Transportヘッダーを使用してメディアセッションパラメータ（プロファイルやアドレス情報を含む）を交換することをサポートしています。RFC 4567 [7]で定義されているSDPベースの鍵管理は、鍵管理プロトコル（鍵情報を含む）の伝達をサポートするために、RTSPヘッダー（KeyMgmt）を追加します。

RTSP Transportヘッダーを使用して、メディアセッションのプロファイルを決定してもよい（MAY）。概念的には、セクション3.3.1で定義されたルールが適宜適用されます。詳細な操作は次のとおりです。SDP記述（DESCRIBEなどによってRTSPサーバから取得されたもの）には、特定のRTSPリソースのメディアストリームの記述が含まれています。

RTSPクライアントは、受信したいメディアストリームごとに1つのプロファイルを正確に選択しなければなりません（MUST）。これはSETUPリクエストで行わなければなりません。RTSPクライアントは、SETUPリクエストに含まれるTransportヘッダーでプロファイルと完全なサーバトランスポートアドレス（IPアドレスとポート番号）を示すことにより、選択したRTPプロファイルを示さなければなりません（MUST）。クライアントのSETUPメッセージに対するRTSPサーバの応答は、このプロファイル選択を確認するか、SETUPリクエストを拒否しなければなりません（MUST）（後者は、そもそもプロファイルを提示した後はすべきではありません）。

注: 使用中のプロファイルを変更するには、クライアントはTEARDOWNメソッドを使用してこのメディアストリーム（および場合によってはRTSPセッション全体）を破棄し、SETUPを使用して再確立する必要があります。これは、メディアの更新（SIPのUPDATEやre-INVITEと同様のもの）が規定され次第、変更される可能性があります。

SDP鍵管理 [7]を使用する場合、セキュアなプロファイルが選択されたならば、適切なRTSPメッセージにKeyMgmtヘッダーを含めなければなりません（MUST）。SDP記述に異なるセキュアなプロファイル（SAVPやSAVPFなど）が提示され、これらに対して異なる鍵情報が提供されている場合、SETUPメッセージで1つのプロファイルを選択した後は、選択したプロファイルに対応するKeyMgmtヘッダーのみを提供しなければなりません（MUST）。RFC 4567 [7]に従ってKeyMgmtヘッダーをメディアストリームに一致させるためのルールが適用されます。

3.3.3. セッション記述の告知​

告知（SAP [11]、ウェブページに掲載された記述、メールで送信された記述など）に基づいてセッション記述を対話的に交渉することを許可しないプロトコルは、メディアセッションへの適切なアクセスの責任をセッションの開始者に課します。

開始者は、アプリケーションやセッションの目的に対して受け入れ可能な範囲で、複数のRTPプロファイルに対して代替のセッション記述を提供すべきです（SHOULD）。セキュリティが望まれる場合、SAVPをSAVPFの代替として提示してもよいが（MAY）、SRTPに依存しない他のセキュリティ手段が採用されていない限り、AVPまたはAVPFセッションを告知すべきではありません（SHOULD NOT）。

RFC 4567 [7]およびRFC 4568 [8]で定義されたSDP属性も、告知されたセッション記述のセキュリティーパラメーター配布に使用される場合があります。

RFC 4568 [8]で定義されたセキュリティスキームの記述は、第三者による鍵情報の盗聴や改ざんを防ぐために、セキュアな通信チャネルを必要とします。したがって、これらのセッション記述の配布やアクセスには、SAPセキュリティ（RFC 2974 [11]で定義）、S/MIME [12]、HTTPS [13]、またはその他の適切なメカニズムを使用すべきです（SHOULD）。

3.3.4. 代替セッションプロファイルの記述​

SAVPおよびSAVPFエンティティは、同じRTPセッション内で混合してもよく（MAY）（セクション4も参照）、AVPおよびAVPFエンティティについても同様です（MAY）。他の組み合わせ、すなわち同じRTPセッションにおけるセキュアなプロファイルと非セキュアなプロファイルの間は互換性がなく、併用してはなりません（MUST NOT）。

関係するピア間での交渉が可能な場合（セクション3.3.1によるオファー/アンサーモデルやセクション3.3.2によるRTSPのように）、代替の（セキュアおよび非セキュアな）プロファイルが1つのエンティティ（オファー側など）によって指定され、もう1つのエンティティによって1つのプロファイルが選択されなければなりません（MUST）。そのような交渉が不可能な場合（セクション3.3.3によるSAPのように）、互換性のないプロファイルを代替案として指定してはなりません（MUST NOT）。

代替プロファイルの交渉については、今後の検討課題です。

RTPプロファイルは、異なるRTPセッションにわたって任意に混合してもよい（MAY）。

3.4. 例​

このセクションには、セキュアなプロファイルと非セキュアなプロファイルの使用を交渉するためのSDPの使用例が含まれています。使用されている鍵管理メカニズムとそのパラメータ化の方法によっては、一般的にSDPメッセージには整合性保護が必要であり、一部のメカニズムでは機密性保護も必要になります。例えば、Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16] の a=fingerprint には整合性保護が必要であり、RFC 4568 [8] (Security Descriptions) の a=crypto には機密性保護が必要であると言えます。

例 1: 次のセッション記述は、DTMFストリームがGeneric NACKを使用する、ポイントツーポイント通信用のオーディオおよびデュアルトーン多周波（DTMF）で構成されるセキュアなセッションを示しています。示されている鍵管理プロトコルはMIKEYです。このセッション記述（オファー）は、SIP INVITEまたは200 OKメッセージに含まれ、その送信者が送信するDTMFストリームに対するフィードバックを受信可能であり、かつ受信する意思があることを示すことができます。対応するアンサーは、200 OKまたはACKで運ばれる場合があります。セキュリティプロトコルのパラメータは、RFC 4567 [7]で定義されたSDP拡張によって説明されているように交渉されます。

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

例 2: この例は、例1と同じフィードバックパラメータを示していますが、セキュアな記述構文 [8] を使用しています。a=crypto属性の鍵部分は盗聴から保護されていないため、セッション記述をセキュアな通信チャネル経由で交換する必要があることに注意してください。

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
  inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
  :32

例 3: この例は、上記の例1を複製したものですが、再びMIKEYを使用して鍵情報を交渉する、オファー側とアンサー側の間のオファー/アンサー交換における相互作用を示しています。

オファー:

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

アンサー:

v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

例 4: この例は、RTSP経由で制御されるビデオストリーミングの交換を示しています。クライアントは、DESCRIBEを使用してサーバからメディア記述を取得し、鍵パラメータのない静的なSDP記述を取得しますが、メディア記述には、(S)AVPFを使用したセキュアおよび非セキュアなメディアセッションの両方が利用可能であることが示されています。セッション記述においてこれらの代替案（すなわち、セキュアおよび非セキュアなセッション）を明示的に識別することを可能にするメカニズムが、現在定義されています [14]。その後、クライアントはSETUPリクエストを発行し、Transportパラメータにそれぞれのプロファイルを含めることで自身の選択を示します。さらに、クライアントは自身のセキュリティパラメータを伝達するためにKeyMgmtヘッダーを含め、これに対しサーバからの対応するKeyMgmtヘッダーが応答で返されます。1つのメディアセッションのみが選択されるため、集約RTSP URIで識別には十分です。

RTSP DESCRIBE リクエスト・レスポンスのペア (オプション):

DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp

200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316

v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
m=video 49170 RTP/SAVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack
m=video 49172 RTP/AVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack

RTSP SETUP リクエスト・レスポンスのペア

SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."

200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
           src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE

例 5: 次のセッション記述は、マルチキャストオーディオ/ビデオセッション（オーディオにPCMUを使用し、ビデオにH.261またはH.263+を使用）を示しており、ビデオソースは両方のコーデックに対してGeneric NACK、H.263に対してReference Picture Selection（参照ピクチャ選択）を受け入れます。セキュリティープロトコルのパラメーターは、セッションレベルで使用されるRFC 4567 [7]で定義されたSDP拡張によって説明されているように交渉されます。このような記述は、セッション告知プロトコル（SAP）を使用して伝達された可能性があります。

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
に最終更新