Network Working Group G. Camarillo Request for Comments: 3388 G. Eriksson Category: Standards Track J. Holler Ericsson H. Schulzrinne Columbia University December 2002 セッション記述プロトコル(SDP)におけるメディア行のグループ化 Grouping of Media Lines in the Session Description Protocol (SDP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 本文書は、「group」と「mid」というセッション記述プロトコル(Session Description Protocol/SDP)の2つの属性を定義する。これら属性によって、2 つの目的を持つ複数の「m」行を1つにグループ化することができる。たとえ ば、リップシンク(lip synchronization)用と1つのフローからのメディア受信 用(複数のメディアストリーム)など。これらは、特定のセッション中に、異な るポートとホストのインターフェースで、異なる形式でエンコードされる。 目次 1. はじめに ..................................................... 2 2. 用語 ...................................................... 2 3. メディアストリームの識別属性 ................................. 3 4. group属性 .................................................... 3 5. 「group」と「mid」の使用 ..................................... 3 6. リップシンク(LS) ............................................. 4 6.1 LSの例 ................................................... 5 7. フロー識別(FID) .............................................. 5 7.1 SIPと携帯電話のアクセス .................................. 6 7.2 DTMFトーン ............................................... 6 7.3 メディアフロー定義 ....................................... 6 7.4 FIDのセマンティクス ...................................... 7 7.4.1 FIDの例 ............................................ 8 7.5 FIDで網羅されないシナリオ ............................... 11 7.5.1 異なるコーデックを使用した並行エンコーディング .... 11 7.5.2 階層エンコーディング .............................. 12 7.5.3 同じIPアドレスとポート番号 ........................ 12 8. SIPにおける「group」属性の用法 .............................. 13 8.1 アンサーの「mid」値 ..................................... 13 8.1.1 例 ................................................ 14 8.2 アンサーのグループ値 .................................... 15 8.2.1 例 ................................................ 15 8.3 能力のネゴシエーション .................................. 16 8.3.1 例 ................................................ 17 8.4 下位互換性 .............................................. 17 8.4.1 オファー側が「group」に対応しない場合 ............. 17 8.4.2 アンサー側が「group」に対応しない場合 ............. 17 9. セキュリティの考慮 ....................................... 18 10. IANA条項 ................................................. 18 11. 謝辞 ..................................................... 19 12. 参考文献 ................................................. 19 13. 著者の連絡先 ............................................. 20 14. 完全な著作権表示 ......................................... 21 1. はじめに SDPセッション記述には、通常、1つ以上のメディア行が含まれる。メディア行 は一般的に「m」行とも呼ばれる。セッション記述に複数の「m」行が含まれる 場合、SDPでは、それらの具体的な関係性を表現する方法を提供していない。 アプリケーションで複数の「m」行を含むSDPセッション記述を受信した場合、 対処方法はアプリケーションに委ねられる。SDPでは、メディアストリームの グループ化に関する情報を何も伝達しない。 環境によってはこの情報は帯域外伝達される可能性があるが、セッション記述 内で異なるメディアストリームを互いに関連付ける方法について、SDPによっ て表現できる拡張が存在することが望ましい。本文書では、このような拡張を 定義する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119のBCP 14(参考文献[1])に 記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベ ルを示すものである。 Camarillo et. al. Standards Track [Page 2] RFC 3388 Grouping of Media Lines in SDP December 2002 3. メディアストリームの識別属性 新たに「メディアストリーム識別(media stream identification)」メディア 属性を定義する。この属性は、セッション記述内のメディアストリームを識別 するために使用される。SDP(参考文献[2])では、次のBNFで記述される。 mid-attribute = "a=mid:" identification-tag identification-tag = token 識別タグは、1つのSDPセッション記述内で固有でなければならない[MUST]。 4. group属性 新たに「グループ」セッションレベル属性を定義する。この属性は、異なるメ ディアストリームをグループ化するときに使用される。SDP(参考文献[2])で は、次のBNFで記述される。 group-attribute = "a=group:" semantics *(space identification-tag) semantics = "LS" | "FID" 本文書では、LD(Lip Synchronization/リップシンク)とFID(Flow Identification/フロー識別)という2つの標準セマンティクスを定義する。そ の他のセマンティクスは、標準化過程の文書で定義する必要がある。ただし、 LSおよびFIDとは別に、新しいセマンティクスを定義することは推奨されな い。そうではなく、SDPngなど、他のセッション記述メカニズムを使用するこ とが推奨される[RECOMMENDED]。 5. 「group」と「mid」の使用 「group」を使用するセッション記述の「m」行はいずれも、group行で使用す るかどうかにかかわらず、「mid」属性で識別されなければならない[MUST]。 セッション記述に「mid」識別が指定されていない「m」行が1行以上ある場 合、アプリケーションでメディア行のグループ化を実行してはならない[MUST NOT]。 「a=group」行は、「mid」行で識別される複数の「m」行をグループ化すると きに使用される。セッション記述内の「m」行と関連付けられない識別タグが 指定された「a=group」は、無視しなければならない[MUST]。この場合、アプ リケーションは「a=group」が存在しなかったときと同様に動作する。グルー プ化された「m」行を含むSDPを受信したアプリケーションの動作は、「a= group」行のセマンティクスフィールドで定義される。 Camarillo et. al. Standards Track [Page 3] RFC 3388 Grouping of Media Lines in SDP December 2002 1つのセッション記述内で複数の「a=group」行を含んでもよい[MAY]。1つの セッション記述の「a=group」行はいずれも、同じセマンティクスを使用して もよいし[MAY]、使用しなくてもよい[MAY NOT]。「mid」属性で識別される1つ の「m」行は、複数の「a=group」行で使用してもよい[MAY]が、各「a=group」 行で異なるセマンティクスを使用している場合に限定される。「mid」属性で 識別される1つの「m」行は、同じセマンティクスを使用する複数の「a= group」行で使用してはならない[MUST NOT]。 6. リップシンク(LS) LSセマンティクスを使用してグループ化された「m」行を含むセッション記述 を受信した場合、アプリケーションは、対応するメディアストリームの再生を 同期しなければならない[MUST]。LSセマンティクスが適用されるのは、音声ス トリームと同期する必要があるビデオストリームだけではない、ということに 注意。同じタイプの2つのストリームを再生する場合も、同期することができ る。 RTPストリームの場合、通常、同期はRTCPを使用して実行される。RTCPによっ て、異なるストリームのタイムスタンプを掛け時計にマッピングするために十 分な情報が得られる。ただし、メディアストリームの同期という概念は、RTP を利用しないメディアストリームにも適用してもよい[MAY]。この場合、アプ リケーションでは、ストリームで利用可能なメカニズムが何であろうと、スト リーム間にあった元の時間関係を復元しなければならない[MUST]。 Camarillo et. al. Standards Track [Page 4] RFC 3388 Grouping of Media Lines in SDP December 2002 6.1 LSの例 次の例では、会議がマルチキャストの場合のセッション記述を示す。1つ目の メディアストリーム(mid:1)には、英語で話す話者の声が含まれる。2つ目のメ ディアストリーム(mid:2)にはビデオコンポーネントが含まれ、3つ目のメディ アストリーム(mid:3)では、1つ目のメディアストリームをスペイン語に通訳し たものが流される。1つ目と2つ目のメディアストリームは同期しなければなら ない[MUST]。 v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 224.2.17.12/127 a=group:LS 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=video 30002 RTP/AVP 31 a=mid:2 m=audio 30004 RTP/AVP 0 i=This media stream contains the Spanish translation a=mid:3 3つ目のメディアストリームはgroup行に含まれないが、前に説明したように、 mid属性(mid:3)を含めなければならない[MUST]。 7. フロー識別(FID) SDPセッション記述の「m」行によって、メディアストリームを定義する。ただ し、SDPでは、メディアストリームの内容を定義しない。メディアストリーム の定義は、RTSP仕様に記載されている。RTSP(参考文献[5])では、メディアス トリームを「1つのメディアインスタンス。たとえば、1つのホワイトボードや 共有アプリケーショングループだけでなく、音声ストリームやビデオストリー ムなど。RTPを使用する場合、ストリームは、RTPセッション内のソースによっ て作成されたRTPパケットとRTCPパケットで構成される。」 この定義では、1つの音声(またはビデオ)ストリームは、1つのRTPセッション にマッピングされると想定している。RTPのRFC(参考文献[6])では、RTPセッ ションを「個々の参加者ごとに、セッションは一対の送信先伝送アドレス(1つ のネットワークアドレス + RTPとRTCPのポートペア)によって定義される」と 定義している。 前者の定義は、ほとんどの一般的なケースを網羅しているが、複数のRTPセッ ションを使用して1つのメディアインスタンス(音声ストリームやビデオスト リームなど)が送信される状況もある。このような状況は数多くあるが、SIP (参考文献[3])を使用する携帯電話システムと、音声とは異なるホストでDTMF トーンを受信するシステムという2つの例を挙げる。 Camarillo et. al. Standards Track [Page 5] RFC 3388 Grouping of Media Lines in SDP December 2002 7.1 SIPと携帯電話のアクセス 携帯電話のアクセスとSIPをシグナリングプロトコルとして使用するシステム では、無線でメディアを受信する必要がある。セッション中に、メディアは異 なるコーデックでエンコードされる可能性がある。エンコードされたメディア は、無線通信(radio)のインターフェースをトラバースする必要がある。無線 通信のインターフェースは、一般的にビットエラーが発生しやすいという特徴 があり、比較的高いパケット伝送の遅延があるとされている。さらに、携帯電 話環境における無線通信のインターフェースリソースは乏しいため高価であ り、結果的に、非常に効率的な伝送を実現する特殊な方法が求められる。効率 的な伝送とともに適切な音声品質を実現するには、メディアを伝送する前に RTPセッション用に正しく無線通信ベアラ(radio bearer)を構成できるよう に、コーデック特性の正確な知識が必要である。この無線通信ベアラは、メ ディアタイプ(つまりコーデック)ごとに専用のベアラである。 携帯電話システムは、通常、異なるポート番号上で異なる無線ベアラを構成す る。そのため、無線通信ベアラに正しくルートするには、受信メディアでコー デックごとに異なる送信先ポート番号を指定する必要がある。つまり、これは 複数のRTPセッションを使用して1つのメディアインスタンス(送信側からのエ ンコードされた音声)を伝達する一例である。 7.2 DTMFトーン 音声セッションには、DTMFトーンが含まれる場合がある。状況によって、音声 操作は、DTMF操作とは異なるホストで実行される。ユーザーが自分のユーザー エージェントでエンコード済みの音声を受信する一方で、ネットワークでユー ザーのDTMFトーンを集めるアプリケーションサーバーを置くことは一般的であ る。この場合、音声用とDTMFトーン用に2つのRTPセッションを確立する必要が ある。どちらのRTPセッションも、論理的には同じメディアインスタンスの一 部である。 7.3 メディアフロー定義 前の例は、参考文献[5]のメディアストリーム定義で網羅していないシナリオ である。このとき、1つのメディアストリームが1つのRTPセッションにマッピ ングされるかどうかは確定できない。したがって、本書ではメディアフロー定 義を導入する。 メディアフローは、1つのメディアインスタンスで構成される。たとえば、1つ のホワイトボードや共有アプリケーショングループだけでなく、音声ストリー ムやビデオストリームなど。RTPを使用する場合、メディアフローは1つ以上の RTPセッションで構成される。 Camarillo et. al. Standards Track [Page 6] RFC 3388 Grouping of Media Lines in SDP December 2002 7.4 FIDのセマンティクス FIDを使用してグループ化された複数の「m」行によって、1つのメディアフ ローが構成される。複数の「m」行で構成されるメディアフローを操作するメ ディアエージェントは、「m」行にあるコーデックとディレクションの属性で 許容されている場合、フローの全「m」行部分にメディアのコピーを送信しな ければならない[MUST]。 作成されるメディアをエンコードする時点で、アプリケーションは1つのコー デックのみを使用すると推定される。このコーデックは、セッション中に動的 に変わってもよい[MAY]が、どの時点でも、使用中なのは1つのコーデックのみ である。 アプリケーションは、現在のコーデックを使用してメディアをエンコードし、 フローに含まれるすべての「m」行を1つずつチェックする。特定の「m」行に 使用中のコーデックが含まれ、ディレクション属性が「sendonly」または 「sendrecv」の場合、エンコードされたメディアのコピーは、そのメディアス トリームで指定されたアドレス/ポートに送信される。「m」行に使用中のコー デックが含まれないか、ディレクション属性が「sendonly」でも「sendrecv」 でもない場合、このメディアストリームでは何も送信されない。 通常、アプリケーションは、最終的に任意の時点で使用されるコーデックに応 じて、メディアを異なる送信先(IPアドレス/ポート番号)に送信する。 Camarillo et. al. Standards Track [Page 7] RFC 3388 Grouping of Media Lines in SDP December 2002 7.4.1 FIDの例 下のセッション記述は、携帯電話アクセスを使用するSIPユーザーエージェン トから送信された可能性がある。ユーザーエージェントは、ポート30000上で GSM、ポート30002上でAMRに対応する。リモート側は、GSMを送信するときに RTPパケットをポート番号30000へ送信する。AMRがコーデックに選択される と、パケットはポート30002に送信される。リモート側は、このセッション中 に2つのコーデック間で動的に切り替えることができる、という点に注意。た だし、この例では、同時に音声を伝達するのは1つのメディアストリームのみ である。その他のメディアストリームは、相当するコーデックが使用中ではな いときに「無音(muted)」状態である。 v=0 o=Laura 289083124 289083124 IN IP4 two.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 3 a=rtpmap:3 GSM/8000 a=mid:1 m=audio 30002 RTP/AVP 97 a=rtpmap:97 AMR/8000 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-neighbor; maxframes=1 a=mid:2 (fmtp行の改行は、RFCの書式制限に合わせたものであり、SDPに継続行はない) 前の例で、システムは、異なるポート番号の同じIPアドレスでメディアを受信 している。次の例では、システムが異なるIPアドレスで異なるコーデックを受 信できる方法を示す。 Camarillo et. al. Standards Track [Page 8] RFC 3388 Grouping of Media Lines in SDP December 2002 v=0 o=Laura 289083124 289083124 IN IP4 three.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 20000 RTP/AVP 0 c=IN IP4 131.160.1.111 a=rtpmap:0 PCMU/8000 a=mid:1 m=audio 30002 RTP/AVP 97 a=rtpmap:97 AMR/8000 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-neighbor; maxframes=1 a=mid:2 (fmtp行の改行は、RFCの書式制限に合わせたものであり、SDPに継続行はない) この例の携帯端末は、AMRコーデックのみに対応している。ただし、現在では 多くのIP電話は、PCM(ペイロード0)のみに対応している。このようなIP電話と 相互運用するために、携帯端末はIPアドレスが131.160.1.111のトランスコー ダを使用する。携帯端末は、そのIPアドレスでPCM用のSDP対応を組み込む。リ モートシステムでは、AMRを端末に直接送信するが、PCMはトランスコーダに送 信される。トランスコーダは、受信するPCM音声をAMRに変換して端末に送信す るように、(何らかの手段を使用して)構成される。 次の例は、FIDセマンティクスと使用する「group」属性で、双方向メディアス トリームの各方向で2つの異なるコーデックを使用することを示す方法であ る。 v=0 o=Laura 289083124 289083124 IN IP4 four.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30002 RTP/AVP 8 a=recvonly a=mid:2 上記のSDPを受信したユーザーエージェントは、その時点で、PCM u-lawをポー ト番号30000へ送信するか、PCM A-lawをポート番号30002へ送信することがで きる、ということがわかる。一方で、メディアエージェントは、相手側が送信 するのはPCM u-law (ペイロード0)のみであることもわかる。 Camarillo et. al. Standards Track [Page 9] RFC 3388 Grouping of Media Lines in SDP December 2002 次の例は、同じコーデックを含むFIDセマンティクスを使用してグループ化さ れた、異なる「m」行を含むセッション記述を示す。 v=0 o=Laura 289083124 289083124 IN IP4 five.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 3 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30002 RTP/AVP 8 a=mid:2 m=audio 20000 RTP/AVP 0 8 c=IN IP4 131.160.1.111 a=recvonly a=mid:3 ある時点で、メディアエージェントがPCM u- law(ペイロード0)を送信してい る場合、RTPパケットは、ポート30000上の131.160.1.112およびポート20000上 の131.160.1.111に送信される(1行目と2行目の「m」行)。PCM A-law(ペイロー ド8)を送信している場合、RTPパケットは、ポート30002上の131.160.1.112お よびポート20000上の131.160.1.111に送信される(2行目と3行目の「m」行)。 上記のSDPを生成するシステムは、ポート30000上でPCM u-lawおよびポート 30002上でPCM A-lawに対応する。また、会話を記録するために、IPアドレスが 131.160.1.111のアプリケーションサーバーが使用されている。これが、どの 時点でも、使用されているコーデックにかかわらず、アプリケーションサー バーが常に音声ストリームのコピーを受信している理由である(実際はRTPのダ ンプを実行しているため、どのコーデックでも効率的に受信できる)。 以前にも説明したように、FIDセマンティクスを使用してグループ化された複 数の「m」行に同じコーデックが含まれる場合、メディアエージェントは同時 に複数のRTPセッション上でメディアを送信しなければならない[MUST]。 Camarillo et. al. Standards Track [Page 10] RFC 3388 Grouping of Media Lines in SDP December 2002 このセクションで最後の例は、DTMFトーンの処理方法を示す。DTMFトーンは、 通常の音声コーデックを使用して伝送するか、電話イベントとして伝送するこ とができる。電話イベントとして扱われるDTMFトーンのRTPペイロードは、RFC 2833(参考文献[7])に記述される。次の例は、FIDセマンティクスとこのペイ ロードタイプを使用するSDPセッション記述を示す。 v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 20000 RTP/AVP 97 c=IN IP4 131.160.1.111 a=rtpmap:97 telephone-events a=mid:2 リモート側は、PCMでエンコードされた音声(ペイロード0)を131.160.1.112に 送信し、電話イベントとしてエンコードされたDTMFトーンを131.160.1.111に 送信する。この時点で送信されているのは、音声またはDTMFのみであることに 注意。DTMFトーンが送信される場合、最初のメディアストリームでデータを伝 達せず、音声が送信される場合、2つ目のメディアストリームにデータはな い。FIDセマンティクスによって、異なるコーデック用に異なる送信先を用意 することができる。 7.5 FIDで網羅されないシナリオ ここでは、既存のセマンティクス(特にFID)を使用する「group」属性が適用可 能に見えて実際はできない場合について触れる。 7.5.1 異なるコーデックを使用した並行エンコーディング FIDセマンティクスは、アプリケーションで同時に1つのコーデックのみが使用 される場合に有用である。同じメディアを同時に異なるコーデックでエンコー ドするアプリケーションは、「m」行のグループ化にFIDを使用してはならない [MUST NOT]。DTMFトーンを処理するシステムによっては、異なるコーデックを 使用して並行エンコーディングを行う一般的な例がある。 一部のシステムは、RFC 2833で定義されているRTPペイロードを実装すること もあるが、DTMFトーンを送信するときに音声チャネルを無音にすることはな い。したがって、実質的に、このようなシステムでは、同じDTMFトーンのコ ピー2つ(音声としてのエンコードと電話イベントとしてのエンコード)を送信 しているのである。受信側が両方のコピーを受信すると、通常、音声としてエ ンコードされたトーンよりも、電話イベントの方が使用される。この場合、 FIDセマンティクスを2つのメディアストリームをグループ化するために使用し てはならない[MUST NOT]。このようなシステムでは、代替のコーデックを使用 Camarillo et. al. Standards Track [Page 11] RFC 3388 Grouping of Media Lines in SDP December 2002 せず、同じ情報の異なる並行エンコーディングを使用するためである。 7.5.2 階層エンコーディング 階層エンコーディングスキームでは、メディアを異なる階層でエンコーディン グする。受信側の品質は、受信する階層数によって変わる。SDPによって、異 なる階層を伝送する隣接マルチキャストアドレスをグループ化することができ る。以下の「c」行は、 c=IN IP4 224.2.1.1/127/3 以下の3つの「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 同じ情報を示していない「m」行をグループ化するときにFIDを使用してはなら ない[MUST NOT]。したがって、異なる階層の異なるエンコーディングスキーム を含む「m」行をグループ化するときに、FIDを使用してはならない[MUST NOT]。また、本書では、異なる階層をグループ化する、より柔軟な方法を実現 するために、新しいグループセマンティクスを定義するようなことはしない。 これは、既存のSDPメカニズムで、ほとんどの有益なシナリオが網羅されてい るためである。 7.5.3 同じIPアドレスとポート番号 同じIPアドレスとポートに複数のコーデックを送信する必要がある場合、同じ 「m」行に複数のコーデックを列挙するという従来のSDP構文を使用しなければ ならない[MUST]。同じIPアドレス/ポートが指定された「m」行をグループ化す るときに、FIDを使用してはならない[MUST NOT]。したがって、以下のような SDPを生成してはならない[MUST NOT]。 v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30000 RTP/AVP 8 a=mid:2 Camarillo et. al. Standards Track [Page 12] RFC 3388 Grouping of Media Lines in SDP December 2002 上記のセッションのSDPを修正すると、以下のようになる。 v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 m=audio 30000 RTP/AVP 0 8 FIDを使用して2つの「m」行をグループ化する場合、「m」行の伝送アドレス (つまり、IPアドレスとポート)は変えなければならない[MUST]。 8. SIPにおける「group」属性の用法 SDP記述は、SIPなどさまざまなプロトコルで使用される。本書では、 「group」属性を主に使用するのはSIPシステムであるため、SIPに関するセク ションを設けた。 SIP(参考文献[3])は、マルチメディアセッションの確立、終了、修正を行う、 アプリケーション階層のプロトコルである。SIPでは、SIPメッセージのボディ でセッション記述が伝達されるが、SIPはセッション記述に使用されるプロト コルとは独立している。SDP(参考文献[2])は、この用途に使用できるプロトコ ルのひとつである。 セッションの確立時に、SIPは、端末間で3ウェイハンドシェイク(INVITE- 200 OK-ACK)を実行している。ただし、これら3つのメッセージのうち、SDPを伝達 するのは2つのみである(参考文献[4]参照)。 8.1 アンサーの「mid」値 「mid」属性は、特定のメディアストリームを指す識別子である。したがっ て、オファーの「mid」値は、アンサーの「mid」値と同じでなければならない [MUST]。また、以降のオファー(re-INVITEなど)では、既存のメディアスト リームと同じ「mid」値を使用すべきである[SHOULD]。 RFC 3264(参考文献[4])には、SIPと関連するSDPの使用方法が記載されてい る。オファー側のセッション記述に含まれるn番目のメディアストリーム (「m」行)が、アンサー側の記述に含まれるn番目のメディアストリームと対応 するように、オファー側とアンサー側はメディア記述の配列を揃える。 SDPセッション記述に「group」属性が含まれる場合でも、この動作は修正され ない。 「mid」属性によって「m」行にラベルが付けられるため、n番目の「m」行を マッチングさせるのではなく、「mid」ラベルを使用してメディアの配列を揃 えることができる。ただし、こうしても何も利益がなく、実装が複雑になる。 Camarillo et. al. Standards Track [Page 13] RFC 3388 Grouping of Media Lines in SDP December 2002 したがって、SIPシステムは、「group」属性または「mid」属性の有無にかか わらず、メディア配列を揃えなければならない[MUST]。 特定の「mid」識別子をオファーで指定されたメディアストリームが、アン サーでは異なる識別子が指定された場合、アプリケーションは、セッション記 述に指定されるすべての「mid」行と「group」行を無視する。次の例で、この シナリオを説明する。 8.1.1 例 2つのSIPエンティティが、セッションの確立時にSDPを変更する。INVITEには 以下のSDPが含まれる。 v=0 o=Laura 289083124 289083124 IN IP4 seven.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 0 8 a=mid:1 m=audio 30002 RTP/AVP 0 8 a=mid:2 200 OK応答には、以下のSDPが含まれる。 v=0 o=Bob 289083122 289083122 IN IP4 eigth.example.com t=0 0 c=IN IP4 131.160.1.113 a=group:FID 1 2 m=audio 25000 RTP/AVP 0 8 a=mid:2 m=audio 25002 RTP/AVP 0 8 a=mid:1 n行目のマッチングに基づいて「m」行の配列が揃えられたため、最初のスト リームには、INVITEに「mid:1」、200 OKに「mid:2」があった。したがって、 アプリケーションはSDPに含まれるすべての「mid」行と「group」行を無視し なければならない[MUST]。 Camarillo et. al. Standards Track [Page 14] RFC 3388 Grouping of Media Lines in SDP December 2002 SIP仕様に従うユーザーエージェントであれば、200 OKで以下のSDPを返す。 v=0 o=Bob 289083122 289083122 IN IP4 nine.example.com t=0 0 c=IN IP4 131.160.1.113 a=group:FID 1 2 m=audio 25002 RTP/AVP 0 8 a=mid:1 m=audio 25000 RTP/AVP 0 8 a=mid:2 8.2 アンサーのグループ値 SIPエンティティは、理解できないセマンティクスが指定された「a=group」行 を含むオファーを受信した場合、「group」行のないアンサーを返さなければ ならない[MUST]。前のセクションでも説明したが、「mid」行をアンサーに含 めたままにしなければならない[MUST]、という点に注意。 SIPエンティティは、理解できるセマンティクスが指定された「a=group」行を 含むオファーを受信した場合、同じセマンティクスを指定した「a=group」行 を含むアンサーを返さなければならない[MUST]。この「a=group」行に含まれ る識別タグは、オファーで受信したものと同じにするか、タグのサブセット(0 の識別タグは有効なサブセットである)にしなければならない[MUST]。アン サーの識別タグがサブセットの場合、セッションで使用される「group」値 は、アンサーで提示される中のいずれかにしなければならない[MUST]。 SIPエンティティがメディアストリームを拒否するには、相当する「m」行の ポートを0に設定する。「a=group」行には、ポート0が指定された「m」行に相 当する識別タグを含めてはならない[MUST NOT]。 「m」行のグループ化は、常にオファー側によって要求されなければならず [MUST]、アンサー側によって要求されることはない、ということに注意。SIP では双方向のSDP交換を提供しているため、グループ化を要求したアンサー側 は、「group」属性がオファー側に受け入れられたかどうかを判断できない。 アンサー側が「m」行のグループ化を望む場合、最初のオファーに応答した後 で、別のオファーを(たとえばre-INVITEなどで)発行すべきである[SHOULD]。 8.2.1 例 以下の例は、着呼側が、ポート番号を0に設定することで、発呼側からオ ファーされたメディアストリームを拒否する方法を示す。このメディアスト リームに相当する「mid」値は、アンサーの「group」値から削除される。 Camarillo et. al. Standards Track [Page 15] RFC 3388 Grouping of Media Lines in SDP December 2002 発呼側から着呼側へのINVITEに含まれるSDP: v=0 o=Laura 289083124 289083124 IN IP4 ten.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 3 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30002 RTP/AVP 8 a=mid:2 m=audio 30004 RTP/AVP 3 a=mid:3 着呼側から発呼側へのINVITEに含まれるSDP: v=0 o=Bob 289083125 289083125 IN IP4 eleven.example.com t=0 0 c=IN IP4 131.160.1.113 a=group:FID 1 3 m=audio 20000 RTP/AVP 0 a=mid:1 m=audio 0 RTP/AVP 8 a=mid:2 m=audio 20002 RTP/AVP 3 a=mid:3 8.3 能力のネゴシエーション 「group」と「mid」を理解しているが特定のセッションで使用する意思がない クライアントは、「group」と「mid」に対応することを示してもよい[MAY]。 この場合、クライアントは、理解するすべてのセマンティクスで、識別タグの ない「a=group」行を追加すべきである[SHOULD]。 サーバーは、空の「a=group」行を含むオファーを受信した場合、アンサー側 に対して、空の「a=group」行の形式で能力(capabilities)も追加すべきであ る[SHOULD]。 Camarillo et. al. Standards Track [Page 16] RFC 3388 Grouping of Media Lines in SDP December 2002 8.3.1 例 LSとFIDのセマンティクスの両方に対応するが、特定のセッションでメディア ストリームをグループ化しないシステムでは、以下のSDPを生成する。 v=0 o=Bob 289083125 289083125 IN IP4 twelve.example.com t=0 0 c=IN IP4 131.160.1.113 a=group:LS a=group:FID m=audio 20000 RTP/AVP 0 8 このオファーを受信するサーバーは、FIDに対応するがLSには対応しない。そ のため、以下のSDPで応答する。 v=0 o=Laura 289083124 289083124 IN IP4 thirteen.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID m=audio 30000 RTP/AVP 0 8.4 下位互換性 本文書では、SIPの「Require」ヘッダーを定義しない。したがって、SIPユー ザーエージェントのいずれかが「group」属性を理解しない場合、標準的なSDP のフォールバックメカニズムを使用しなければならない[MUST](理解されない 属性は単に無視される)。 8.4.1 オファー側が「group」に対応しない場合 この場合、グループ化のリクエストは常にオファー側から行われ、アンサー側 から行われることはないため、問題は発生しない。オファー側が「group」属 性に対応しない場合、この属性が使用されないだけである。 8.4.2 アンサー側が「group」に対応しない場合 アンサー側は、理解できないため「group」属性を無視する(また、「mid」属 性も無視する)。LSセマンティクスの場合、アンサー側は、メディアストリー ム間の同期を実行するかどうかを決定する場合がある。 FIDセマンティクスの場合、アンサー側は、セッションが複数のメディアスト リームで構成されると見なす。 実装が異なれば、動作方法も異なる。 Camarillo et. al. Standards Track [Page 17] RFC 3388 Grouping of Media Lines in SDP December 2002 異なるコーデックに異なる「m」行の音声の場合、実装によっては、異な る受信RTPセッションでミキサーとして動作する可能性があるが、これは正 しい動作である。 実装によっては、複数の「m」行が含まれるため、リクエストを拒否する場合 もある(たとえば、488 Not acceptable hereまたは606 Not Acceptable)。こ の場合、サーバーは、発呼側が確立を望むセッションタイプに対応しない。い ずれにせよ、クライアントがより単純なセッションを確立することを望む場 合、「group」属性を含まないリクエストか、1フローに付き「m」行が1つしか ないリクエストで再試行すべきである[SHOULD]。 9. セキュリティの考慮 エンティティが、マルチメディアセッションを確立するために、FIDセマン ティクスで「group」パラメータを使用して、参加者間で交換されるセッショ ン記述を修正しようとする場合、参加者が特定の送信先へメディアのコピーを 送信することを強制する可能性がある。 この攻撃を防ぐには、セッション記述とメディアの暗号を交換するときに使用 されるプロトコルが提供する、整合性のメカニズムを使用することができる。 10. IANA条項 本文書は、「group」と「mid」という2つのSDP属性を定義する。 「mid」属性は、セッション記述内のメディアストリームを識別するために使 用され、書式はセクション3で定義されている。 「group」属性は、異なるメディアストリームをグループ化するために使用さ れ、書式はセクション4で定義されている。 本文書は、複数のセマンティクスを使用して、SDPにおけるメディア行のグ ループ化フレームワークを定義する。このフレームワークと共に使用されるセ マンティクスは、標準化過程のRFCで発行されるときに、IANAによって登録さ れる。 RFCのIANA条項セクションには、以下の情報を含めなければならない[MUST]。 これは、公開されるRFC番号とともに、IANA登録に表示される。 o セマンティクスの簡潔な説明。 o 「group」属性内で使用されるトークン。このトークンの長さは任意で よいが、4文字を超えないようにすべきである[SHOULD]。 o 標準化過程RFCへの参照。 Camarillo et. al. Standards Track [Page 18] RFC 3388 Grouping of Media Lines in SDP December 2002 現時点の登録項目は、以下のみ。 セマンティクス トークン 参照 --------------- -------- ----------- リップシンク LS RFC 3388 フロー識別 FID RFC 3388 11. 謝辞 Jonathan Rosenberg、Adam Roach、Orit Levin、Joerg Ottの各氏からいただ いた本書へのフィードバックに感謝を述べたい。 12. 参考文献 12.1 規範的な参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] 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. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. 12.2 有益な参考文献 [5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. Camarillo et. al. Standards Track [Page 19] RFC 3388 Grouping of Media Lines in SDP December 2002 13. 著者の連絡先 Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland Phone: +358 9 299 3371 Fax: +358 9 299 3052 EMail: Gonzalo.Camarillo@ericsson.com Jan Holler Ericsson Research S-16480 Stockholm Sweden Phone: +46 8 58532845 Fax: +46 8 4047020 EMail: Jan.Holler@era.ericsson.se Goran AP Eriksson Ericsson Research S-16480 Stockholm Sweden Phone: +46 8 58531762 Fax: +46 8 4047020 EMail: Goran.AP.Eriksson@era.ericsson.se Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Camarillo et. al. Standards Track [Page 20] RFC 3388 Grouping of Media Lines in SDP December 2002 14. 完全な著作権表示 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著作 権表示およびこの節を付加するものはすべて、全体であってもその一部であっ ても、いっさいの制約を課されること無く、準備、複製、発表、配布すること ができる。しかし、この文書自体にはいかなる方法にせよ、著作権表示やイン ターネットソサエティもしくは他のインターネット関連団体への参照を取り除 くなどの変更を加えてはならない。インターネット標準を開発するために必要 な場合は例外とされるが、その場合はインターネット標準化過程で定義されて いる著作権のための手続きに従わなければならない。またRFCを英語以外の言 語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティもし くはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないという 保証、商用利用および特定目的への適合性への保証を含め、また、これらだけ に限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2004年 ----------------------------------------------------------------------- Camarillo et. al. Standards Track [Page 21]