[要約] RFC 4796は、セッション記述プロトコル（SDP）のコンテンツ属性に関する仕様であり、SDPメッセージ内のメディアコンテンツの特性を定義しています。このRFCの目的は、SDPを使用してセッションの特性を記述するための一貫性のある方法を提供することです。
Network Working Group J. Hautakorpi
Request for Comments: 4796 G. Camarillo
Category: Standards Track Ericsson
February 2007
The Session Description Protocol (SDP) Content Attribute
セッション説明プロトコル（SDP）コンテンツ属性
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document defines a new Session Description Protocol (SDP) media-level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content.
このドキュメントでは、新しいセッション説明プロトコル（SDP）メディアレベルの属性「コンテンツ」を定義します。「コンテンツ」属性は、メディアストリームのコンテンツをメディアの説明行よりも詳細なレベルに定義します。SDPセッションの説明の送信者は、「コンテンツ」属性を1つ以上のメディアストリームに添付できます。その後、受信アプリケーションは、各メディアストリームを異なる方法で扱うことができます（たとえば、大画面または小さな画面に表示します）。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Related Techniques . . . . . . . . . . . . . . . . . . . . . . 2
4. Motivation for the New Content Attribute . . . . . . . . . . . 3
5. The Content Attribute . . . . . . . . . . . . . . . . . . . . 4
6. The Content Attribute in the Offer/Answer Model . . . . . . . 5
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informational References . . . . . . . . . . . . . . . . 9
The Session Description Protocol (SDP) [1] is a protocol that is intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. One of the most typical use cases of SDP is where it is used with the Session Initiation Protocol (SIP) [5].
セッション説明プロトコル（SDP）[1]は、セッションの発表、セッションの招待状、およびその他の形式のマルチメディアセッション開始の目的でマルチメディアセッションを記述することを目的としたプロトコルです。SDPの最も典型的なユースケースの1つは、セッション開始プロトコル（SIP）[5]で使用される場所です。
There are situations where one application receives several similar media streams, which are described in an SDP session description. The media streams can be similar in the sense that their content cannot be distinguished just by examining their media description lines (e.g., two video streams). The 'content' attribute is needed so that the receiving application can treat each media stream appropriately based on its content.
SDPセッションの説明で説明されているいくつかの類似のメディアストリームを1つのアプリケーションに受信する状況があります。メディアストリームは、メディアの説明行（2つのビデオストリームなど）を調べるだけでコンテンツを区別できないという意味で似ています。「コンテンツ」属性が必要であり、受信アプリケーションがコンテンツに基づいて各メディアストリームを適切に処理できるようにします。
This specification defines the SDP 'content' media-level attribute, which provides more information about the media stream than the 'm' line in an SDP session description.
この仕様は、SDPセッションの説明の「M」行よりもメディアストリームに関するより多くの情報を提供するSDP「コンテンツ」メディアレベルの属性を定義します。
The main purpose of this specification is to allow applications to take automated actions based on the 'content' attributes. However, this specification does not define those actions. Consequently, two implementations can behave completely differently when receiving the same 'content' attribute.
この仕様の主な目的は、アプリケーションが「コンテンツ」属性に基づいて自動化されたアクションを実行できるようにすることです。ただし、この仕様はこれらのアクションを定義しません。その結果、同じ「コンテンツ」属性を受信すると、2つの実装が完全に異なる動作をすることができます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3], and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードは「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうは思わない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [3]に記載されているように解釈され、準拠の実装の要件レベルを示します。
The 'label' attribute [10] enables a sender to attach a pointer to a particular media stream. The namespace of the 'label' attribute itself is unrestricted; so, in principle, it could also be used to convey information about the content of a media stream. However, in practice, this is not possible because of the need for backward compatibility. Existing implementations of the 'label' attribute already use values from that unrestricted namespace in an application-specific way. So, it is not possible to reserve portions of the 'label' attribute's namespace without possible conflict with already used application-specific labels.
「ラベル」属性[10]により、送信者は特定のメディアストリームへのポインターを接続できます。「ラベル」属性自体の名前空間は無制限です。したがって、原則として、メディアストリームの内容に関する情報を伝えるためにも使用できます。ただし、実際には、これは後方互換性の必要性のために不可能です。「ラベル」属性の既存の実装は、アプリケーション固有の方法でその無制限の名前空間の値をすでに使用しています。したがって、すでに使用されているアプリケーション固有のラベルと競合する可能性がなく、「ラベル」属性の名前空間の一部を予約することはできません。
It is possible to assign semantics to a media stream with an external document that uses the 'label' attribute as a pointer. The downside of this approach is that it requires an external document. Therefore, this kind of mechanism is only applicable to special use cases where such external documents are used (e.g., centralized conferencing).
「ラベル」属性をポインターとして使用する外部ドキュメントを使用して、セマンティクスをメディアストリームに割り当てることができます。このアプローチの欠点は、外部ドキュメントが必要であることです。したがって、この種のメカニズムは、そのような外部文書が使用されている特別なユースケースにのみ適用されます（たとえば、集中化された会議）。
Yet another way to attach semantics to a media stream is to use the 'i' SDP attribute, defined in [1]. However, values of the 'i' attribute are intended for human users and not for automata.
セマンティクスをメディアストリームに添付するもう1つの方法は、[1]で定義されている「i 'SDP属性」を使用することです。ただし、「i」属性の値は、オートマトンではなく、人間のユーザーを対象としています。
Currently, SDP does not provide any means for describing the content of a media stream (e.g., speaker's image, slides, sign language) in a form that the application can understand. Of course, the end user can see the content of the media stream and read its title, but the application cannot understand what the media stream contains.
現在、SDPは、アプリケーションが理解できる形式で、メディアストリーム（スピーカーの画像、スライド、手話など）の内容を説明する手段を提供していません。もちろん、エンドユーザーはメディアストリームのコンテンツを表示してタイトルを読むことができますが、アプリケーションはメディアストリームに含まれるものを理解できません。
The application that is receiving multiple similar (e.g., same type and format) media streams needs, in some cases, to know what the contents of those streams are. This kind of situation occurs, for example, in cases where presentation slides, the speaker's image, and sign language are transported as separate media streams. It would be desirable that the receiving application could distinguish them in a way that it could handle them automatically in an appropriate manner.
複数の類似した（同じタイプと形式）メディアストリームを受信しているアプリケーションは、これらのストリームの内容が何であるかを知るために必要です。この種の状況は、たとえば、プレゼンテーション、スピーカーの画像、手話が別々のメディアストリームとして輸送される場合に発生します。受信アプリケーションは、適切な方法で自動的に処理できる方法でそれらを区別できることが望ましいでしょう。
+--------------------------------------+
|+------------++----------------------+|
|| || ||
|| speaker's || ||
|| image || ||
|| || ||
|+------------+| presentation ||
|+------------+| slides ||
|| || ||
|| sign || ||
|| language || ||
|| || ||
|+------------++----------------------+|
+--------------------------------------+
Figure 1: Application's Screen
図1：アプリケーションの画面
Figure 1 shows a screen of a typical communication application. The 'content' attribute makes it possible for the application to decide where to show each media stream. From an end user's perspective, it is desirable that the user does not need to arrange each media stream every time a new media session starts.
図1は、典型的な通信アプリケーションの画面を示しています。「コンテンツ」属性により、アプリケーションが各メディアストリームを表示する場所を決定できるようになります。エンドユーザーの観点からは、新しいメディアセッションが開始されるたびに、ユーザーが各メディアストリームをアレンジする必要がないことが望ましいです。
The 'content' attribute could also be used in more complex situations. An example of such a situation is an application controlling equipment in an auditorium. An auditorium can have many different output channels for video (e.g., main screen and two smaller screens) and audio (e.g., main speakers and headsets for the participants). In this kind of environment, a lot of interaction from the end user who operates the application would be required in absence of cues from a controlling application. The 'content' attribute would make it possible, for example, for an end user to specify, only once, which output each media stream of a given session should use. The application could automatically apply the same media layout for subsequent sessions. So, the 'content' attribute can help reduce the amount of required end-user interaction considerably.
「コンテンツ」属性は、より複雑な状況でも使用できます。このような状況の例は、講堂のアプリケーション制御機器です。講堂には、ビデオ用のさまざまな出力チャネル（メイン画面と2つの小さな画面）とオーディオ（参加者のメインスピーカーとヘッドセットなど）を使用できます。この種の環境では、アプリケーションを操作するエンドユーザーからの多くの相互作用が、制御アプリケーションからのキューがない場合に必要です。「コンテンツ」属性は、たとえば、エンドユーザーが特定のセッションの各メディアストリームを使用することを1回だけ指定できるようにすることを可能にします。アプリケーションは、後続のセッションに同じメディアレイアウトを自動的に適用できます。したがって、「コンテンツ」属性は、必要なエンドユーザーの相互作用の量を大幅に削減するのに役立ちます。
This specification defines a new media-level value attribute, 'content'. Its formatting in SDP is described by the following ABNF (Augmented Backus-Naur Form) [2]:
この仕様は、新しいメディアレベルの値属性「コンテンツ」を定義します。SDPでのそのフォーマットは、次のABNF（増強されたバックスノール形式）によって説明されています[2]：
content-attribute = "a=content:" mediacnt-tag
mediacnt-tag = mediacnt *("," mediacnt)
mediacnt = "slides" / "speaker" / "sl" / "main"
/ "alt" / mediacnt-ext
mediacnt-ext = token
The 'content' attribute contains one or more tokens, which MAY be attached to a media stream by a sending application. An application MAY attach a 'content' attribute to any media stream it describes.
「コンテンツ」属性には、1つ以上のトークンが含まれており、送信アプリケーションによってメディアストリームに添付される場合があります。アプリケーションは、説明するメディアストリームに「コンテンツ」属性を添付できます。
This document provides a set of pre-defined values for the 'content' attribute. Other values can be defined in the future. The pre-defined values are:
このドキュメントは、「コンテンツ」属性の事前定義された値のセットを提供します。他の値は将来定義できます。事前に定義された値は次のとおりです。
slides: the media stream includes presentation slides. The media type can be, for example, a video stream or a number of instant messages with pictures. Typical use cases for this are online seminars and courses. This is similar to the 'presentation' role in H.239 [12].
スライド：メディアストリームにはプレゼンテーションスライドが含まれています。メディアタイプは、たとえば、ビデオストリームまたは写真付きのいくつかのインスタントメッセージにすることができます。これの典型的なユースケースは、オンラインセミナーとコースです。これは、H.239 [12]の「プレゼンテーション」の役割に似ています。
speaker: the media stream contains the image of the speaker. The media can be, for example, a video stream or a still image. Typical use cases for this are online seminars and courses.
スピーカー：メディアストリームには、スピーカーの画像が含まれています。メディアは、たとえば、ビデオストリームや静止画像です。これの典型的なユースケースは、オンラインセミナーとコースです。
sl: the media stream contains sign language. A typical use case for this is an audio stream that is translated into sign language, which is sent over a video stream.
SL：メディアストリームには手話が含まれています。これの典型的なユースケースは、ビデオストリームを介して送信される手話に翻訳されるオーディオストリームです。
main: the media stream is taken from the main source. A typical use case for this is a concert where the camera is shooting the performer.
メイン：メディアストリームはメインソースから取得されます。これの典型的なユースケースは、カメラがパフォーマーを撃っているコンサートです。
alt: the media stream is taken from the alternative source. A typical use case for this is an event where the ambient sound is separated from the main sound. The alternative audio stream could be, for example, the sound of a jungle. Another example is the video of a conference room, while the main stream carries the video of the speaker. This is similar to the 'live' role in H.239.
ALT：メディアストリームは、代替ソースから取得されます。これの典型的なユースケースは、周囲の音がメインサウンドから分離されるイベントです。代替オーディオストリームは、たとえばジャングルの音である可能性があります。別の例は、会議室のビデオですが、メインストリームにはスピーカーのビデオが搭載されています。これは、H.239の「ライブ」の役割に似ています。
All these values can be used with any media type. We chose not to restrict each value to a particular set of media types in order not to prevent applications from using innovative combinations of a given value with different media types.
これらすべての値は、任意のメディアタイプで使用できます。さまざまなメディアタイプと特定の値の革新的な組み合わせをアプリケーションを使用しないように、各値を特定のメディアタイプに制限しないことを選択しました。
The application can make decisions on how to handle a single media stream based on both the media type and the value of the 'content' attribute. If the application does not implement any special logic for the handling of a given media type and 'content' value combination, it applies the application's default handling for the media type.
アプリケーションは、メディアタイプと「コンテンツ」属性の値の両方に基づいて、単一のメディアストリームを処理する方法を決定することができます。アプリケーションが、特定のメディアタイプと「コンテンツ」値の組み合わせの処理に関する特別なロジックを実装していない場合、メディアタイプにアプリケーションのデフォルトの処理を適用します。
Note that the same 'content' attribute value can occur more than once in a single session description.
同じ「コンテンツ」属性値は、単一のセッションの説明で複数回発生する可能性があることに注意してください。
This specification does not define a means to discover whether the peer endpoint understands the 'content' attribute because 'content' values are just informative at the offer/answer model [8] level. The fact that the peer endpoint does not understand the 'content' attribute does not keep the media session from being established. The only consequence is that end user interaction on the receiving side may be required to direct the individual media streams appropriately.
この仕様は、「コンテンツ」値がオファー/回答モデル[8]レベルで単なる有益であるため、ピアエンドポイントが「コンテンツ」属性を理解しているかどうかを発見する手段を定義するものではありません。ピアエンドポイントが「コンテンツ」属性を理解していないという事実は、メディアセッションが確立されないようにしていません。唯一の結果は、個々のメディアストリームを適切に指示するために、受信側でのエンドユーザーインタラクションが必要になる可能性があることです。
The 'content' attribute describes the data that the application generating the SDP session description intends to send over a particular media stream. The 'content' values for both directions of a media stream do not need to be the same. Therefore, an SDP answer MAY contain 'content' attributes even if none were present in the offer. Similarly, the answer MAY contain no 'content' attributes even if they were present in the offer. Furthermore, the values of 'content' attributes do not need to match in an offer and an answer.
「コンテンツ」属性は、SDPセッションの説明を生成するアプリケーションが特定のメディアストリームを介して送信することを意図しているデータを説明します。メディアストリームの両方向の「コンテンツ」値は同じである必要はありません。したがって、SDPの回答には、オファーに存在していなくても、「コンテンツ」属性が含まれる場合があります。同様に、答えには、オファーに存在していても、「コンテンツ」属性が含まれていない場合があります。さらに、「コンテンツ」属性の値は、オファーと答えに一致させる必要はありません。
The 'content' attribute can also be used in scenarios where SDP is used in a declarative style. For example, 'content' attributes can be used in SDP session descriptors that are distributed with Session Announcement Protocol (SAP) [9].
「コンテンツ」属性は、SDPが宣言スタイルで使用されるシナリオでも使用できます。たとえば、「コンテンツ」属性は、セッションアナウンスプロトコル（SAP）[9]で分布するSDPセッション記述子で使用できます。
There are two examples in this section. The first example, shown below, uses a single 'content' attribute value per media stream:
このセクションには2つの例があります。以下に示す最初の例は、メディアストリームごとに単一の「コンテンツ」属性値を使用します。
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Second lecture from information technology
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides
m=video 53334 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl
The second example, below, is a case where there is more than one 'content' attribute value per media stream. The difference with the previous example is that now the conferencing system might automatically mix the video streams from the presenter and slides:
以下の2番目の例は、メディアストリームごとに複数の「コンテンツ」属性値がある場合です。前の例との違いは、会議システムがプレゼンターとスライドのビデオストリームを自動的に混合する可能性があることです。
v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Second lecture from information technology
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides,speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl
The values of 'content' attribute, defined in Section 5, can also be used with Synchronized Multimedia Integration Language (SMIL) [11]. SMIL contains a 'param' element, which is used for describing the content of a media flow. However, this 'param' element, like the 'content' attribute, provides an application-specific description of the media content.
セクション5で定義されている「コンテンツ」属性の値は、同期されたマルチメディア統合言語（SMIL）で使用することもできます[11]。Smilには、メディアフローの内容を説明するために使用される「パラマ」要素が含まれています。ただし、この「コンテンツ」属性のように、この「パラマ」要素は、メディアコンテンツのアプリケーション固有の説明を提供します。
Details on how to use the values of the 'content' attribute with SMIL's 'param' element are outside the scope of this specification.
「コンテンツ」属性の値をSmilの「パラメーション」要素を使用する方法の詳細は、この仕様の範囲外です。
An attacker may attempt to add, modify, or remove 'content' attributes from a session description. Depending on how an implementation chooses to react to the presence or absence of a given 'content' attribute, this could result in an application behaving in an undesirable way; therefore, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions.
攻撃者は、セッションの説明から「コンテンツ」属性を追加、変更、または削除しようとする場合があります。実装が特定の「コンテンツ」属性の有無に反応することを選択する方法に応じて、これにより、アプリケーションが望ましくない方法で動作する可能性があります。したがって、SDPセッションの説明に完全性保護を適用することを強くお勧めします。
Integrity protection can be provided for a session description carried in an SIP [5], e.g., by using S/MIME [6] or Transport Layer Security (TLS) [7].
S/MIME [6]または輸送層セキュリティ（TLS）[7]を使用して、SIP [5]で送られたセッションの説明には、整合性保護を提供できます。
It is assumed that values of 'content' attribute do not contain data that would be truly harmful if it is exposed to a possible attacker. It must be noted that the initial set of values does not contain any data that would require confidentiality protection. However, S/MIME and TLS can be used to protect confidentiality, if needed.
「コンテンツ」属性の値には、攻撃者にさらされると本当に有害なデータが含まれていないと想定されています。値の初期セットには、機密保護が必要なデータが含まれていないことに注意する必要があります。ただし、S/MIMEおよびTLSを使用して、必要に応じて機密性を保護できます。
This document defines a new 'content' attribute for SDP. It also defines an initial set of values for it. Some general information regarding the 'content' attribute is presented in the following:
このドキュメントは、SDPの新しい「コンテンツ」属性を定義します。また、それの最初の値のセットを定義します。「コンテンツ」属性に関するいくつかの一般情報は、以下に示されています。
Contact name: Jani Hautakorpi <Jani.Hautakorpi@ericsson.com>.
連絡先名：Jani Hautakorpi <Jani.hautakorpi@ericsson.com>。
Attribute name: 'content'.
属性名：「コンテンツ」。
Type of attribute Media level.
属性メディアレベルのタイプ。
Subject to charset: No.
Charsetの対象：いいえ。
Purpose of attribute: The 'content' attribute gives information from the content of the media stream to the receiving application.
属性の目的：「コンテンツ」属性は、メディアストリームのコンテンツから受信アプリケーションに情報を提供します。
Allowed attribute values: "slides", "speaker", "sl", "main", "alt", and any other registered values.
許可された属性値：「スライド」、「スピーカー」、「SL」、「メイン」、「ALT」、およびその他の登録値。
The IANA created a subregistry for 'content' attribute values under the Session Description Protocol (SDP) Parameters registry. The initial values for the subregistry are as follows:
IANAは、セッション説明プロトコル（SDP）パラメーターレジストリの下で「コンテンツ」属性値のサブレジストリを作成しました。サブレジストリの初期値は次のとおりです。
Value of 'content' attribute Reference Description
---------------------------- --------- -----------
slides RFC 4796 Presentation slides
speaker RFC 4796 Image from the speaker
sl RFC 4796 Sign language
main RFC 4796 Main media stream
alt RFC 4796 Alternative media stream
As per the terminology in RFC 2434 [4], the registration policy for new values for the 'content' parameter shall be 'Specification Required'.
RFC 2434 [4]の用語によると、「コンテンツ」パラメーターの新しい値の登録ポリシーは「必要な仕様」でなければなりません。
If new values for 'content' attributes are specified in the future, they should consist of a meta description of the contents of a media stream. New values for 'content' attributes should not describe things like what to do in order to handle a stream.
「コンテンツ」属性の新しい値が将来指定されている場合、メディアストリームのコンテンツのメタ説明で構成する必要があります。「コンテンツ」属性の新しい値は、ストリームを処理するために何をすべきかなどのことを説明するべきではありません。
The authors would like to thank Arnoud van Wijk and Roni Even, who provided valuable ideas for this document. We wish to also thank Tom Taylor for his thorough review.
著者は、この文書に貴重なアイデアを提供してくれたArnoud Van WijkとRoni Evenに感謝したいと思います。トム・テイラーの徹底的なレビューにも感謝したいと思います。
[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[1] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[5] 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.
[5] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[6] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[7] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[9] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[10] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[10] Levin、O。およびG. Camarillo、「セッション説明プロトコル（SDP）ラベル属性」、RFC 4574、2006年8月。
[11] Michel, T. and J. Ayars, "Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition]", World Wide Web Consortium Recommendation REC-SMIL2-20050107, January 2005, <http://www.w3.org/TR/2005/REC-SMIL2-20050107>.
[11] Michel、T。およびJ. Ayars、「Synchronized Multimedia Integration Language（Smil 2.0） - [Second Edition]」、World Wide Webコンソーシアムの推奨Rec-Smil2-20050107、2005年1月、<http://www.w3.org/TR/2005/REC-SMIL2-20050107>。
[12] ITU-T, "Infrastructure of audiovisual services - Systems aspects; Role management and additional media channels for H.300-series terminals", Series H H.239, July 2003.
[12] ITU-T、「視聴覚サービスのインフラストラクチャ - システムの側面、H.300シリーズ端子のロール管理と追加のメディアチャネル」、シリーズH H.239、2003年7月。
Authors' Addresses
著者のアドレス
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。