Network Working Group                                      J. Hautakorpi
Request for Comments: 4796                                  G. Camarillo
Category: Standards Track                                       Ericsson
                                                           February 2007
        
        The Session Description Protocol (SDP) Content Attribute
        

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)IETFトラスト(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
        
1. Introduction
1. はじめに

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]は、セッション告知、セッション招待、およびマルチメディアセッション開始の他の形態の目的のために、マルチメディアセッションを記述することを意図しているプロトコルです。それはセッション開始プロトコル(SIP)で使用されるSDPの最も典型的な使用事例の一つである[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セッション記述に記載されているいくつかの類似のメディアストリームを、受信状況があります。メディアストリームは、コンテンツは、そのメディア記述行(例えば、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つの実装は完全に異なる振る舞いをすることができます。

2. Terminology
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.

この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、「OPTIONAL」はBCP 14、RFC 2119に記載されているように、[3]に解釈されるべきであり、対応する実装の要求レベルを示します。

3. Related Techniques
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]で定義された「I」SDP属性を使用することです。しかし、「I」属性の値は、人間のユーザのためにではなくオートマトンのために意図されています。

4. Motivation for the New Content Attribute
新しいコンテンツ属性4.動機

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つの小さな画面)とオーディオのための多くの異なる出力チャネルを有することができる(例えば、参加者のメインスピーカとヘッドセット)。このような環境では、アプリケーションを動作させる、エンドユーザからの相互作用の多くは、制御アプリケーションからの手がかりが存在しない場合に必要とされるであろう。エンドユーザが指定したセッションの各メディアストリームが使用すべき出力、一度だけ、指定するためのコンテンツ '属性は、例えば、それが可能になるだろう。アプリケーションは自動的にその後のセッションのために同じメディアレイアウトを適用することができます。だから、「コンテンツ」属性がかなり必要なエンドユーザーとの対話の量を減らすことができます。

5. The Content Attribute
5.コンテンツ属性

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]:

この仕様は、「コンテンツの新しいメディアレベルvalue属性を定義します。 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.

同じ「コンテンツ」属性の値は、単一のセッション記述で複数回発生する可能性があることに注意してください。

6. The Content Attribute in the Offer/Answer Model
6.オファー/アンサーモデルでのコンテンツの属性

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)と一緒に配布されたSDPセッション記述子で使用することができる属性[9]。

7. Examples
7.例

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:

第二の例は、以下、メディアストリームごとに複数の「コンテンツ」属性値が存在する場合です。前の例との違いは、今会議システムが自動的にプレゼンターとスライドからビデオストリームを混ぜるかもしれないということです。

       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
        
8. Operation with SMIL
SMIL 8.運用

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は、メディアフローの内容を記述するために使用される「PARAM」要素を含んでいます。しかし、この「PARAM」要素は、「コンテンツ」属性のように、メディアコンテンツのアプリケーション固有の記述を提供します。

Details on how to use the values of the 'content' attribute with SMIL's 'param' element are outside the scope of this specification.

SMILの「PARAM」要素と「コンテンツ」属性の値を使用する方法の詳細については、この仕様の範囲外です。

9. Security Considerations
9.セキュリティの考慮事項

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].

完全性保護は、[7] SIP [5]、例えば、S / MIMEを使用して、[6]またはトランスポート層セキュリティ(TLS)で運ばれるセッション記述のために提供することができます。

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は必要に応じて、機密性を保護するために使用することができます。

10. IANA Considerations
10. IANAの考慮事項

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>.

担当者名:ヤニHautakorpi <Jani.Hautakorpi@ericsson.com>。

Attribute name: 'content'.

「コンテンツ」:属性名。

Type of attribute Media level.

属性メディアレベルのタイプ。

Subject to charset: No.

文字セットの件名:いいえ。

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.

「コンテンツの属性の新しい値は、将来に指定されている場合は、メディアストリームの内容のメタ記述で構成する必要があります。 「コンテンツの属性の新しい値は、ストリームを処理するために何をするかのようなものを記述するべきではありません。

11. Acknowledgements
11.謝辞

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バンWijkとロニを、感謝したいと思います。我々はまた、彼の徹底的なレビューのためにトム・テイラーに感謝したいです。

12. References
12.参考文献
12.1. Normative References
12.1. 引用規格

[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[1]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[2]クロッカー、D.、エド。そして、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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月。

12.2. Informational References
12.2. 情報の参照

[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、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.、RFC 3851、2004年7月 "/多目的インターネットメール拡張(S / MIME)バージョン3.1メッセージ仕様を固定します"。

[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[7]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル(SDP)とのオファー/アンサーモデル" 2002年6月。

[9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.

[9]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。

[10] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.

[10]レヴィン、O.およびG.キャマリロ、 "セッション記述プロトコル(SDP)label属性"、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]ミシェル、T.およびJ. Ayars、 "同期マルチメディア統合言語(SMIL 2.0) - [第二版]"、World Wide Web Consortium(W3C)の勧告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

ヤニHautakorpiエリクソンHirsalantie 11 Jorvas 02420フィンランド

EMail: Jani.Hautakorpi@ericsson.com

メールアドレス:Jani.Hautakorpi@ericsson.com

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド

EMail: Gonzalo.Camarillo@ericsson.com

メールアドレス:Gonzalo.Camarillo@ericsson.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2007).

著作権(C)IETFトラスト(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。