Internet Engineering Task Force (IETF) I. Johansson
Request for Comments: 6236 Ericsson AB
Category: Standards Track K. Jung
ISSN: 2070-1721 Samsung Electronics Co., Ltd.
May 2011
Negotiation of Generic Image Attributes in
the Session Description Protocol (SDP)
Abstract
抽象
This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted.
この文書では、このような画像サイズなどの異なる画像の属性を交渉することを可能にする新しい汎用セッションセットアップ属性を提案しています。可能なユースケースは、ローエンドの携帯端末は、画像を再スケーリングする必要がある、メモリと処理能力を大量に消費する可能性が何かなし映像を表示することが可能にすることです。文書はまた、受信機が所望する画像のみサイズが送信されるように、ビデオのための最適なビットレートを維持するのに役立ちます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6236.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6236で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Specification of the 'imageattr' SDP Attribute . . . . . . . . 5
3.1. Attribute Syntax . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Overall View of Syntax . . . . . . . . . . . . . . . . 5
3.2. Considerations . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. No imageattr in First Offer . . . . . . . . . . . . . 11
3.2.2. Different Payload Type Numbers in Offer and Answer . . 11
3.2.3. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. sendonly and recvonly . . . . . . . . . . . . . . . . 12
3.2.5. Sample Aspect Ratio . . . . . . . . . . . . . . . . . 13
3.2.6. SDPCapNeg Support . . . . . . . . . . . . . . . . . . 13
3.2.7. Interaction with Codec Parameters . . . . . . . . . . 14
3.2.8. Change of Display in Middle of Session . . . . . . . . 16
3.2.9. Use with Layered Codecs . . . . . . . . . . . . . . . 16
3.2.10. Addition of Parameters . . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 16
4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22
This document proposes a new SDP attribute to make it possible to negotiate different image attributes, such as image size. The term image size is defined here, as it may differ from the physical screen size of, for instance, a hand-held terminal. As an example, it may be beneficial to display a video image on a part of the physical screen and leave space on the screen for other features such as menus and other info.
この文書では、このような画像サイズなどの異なる画像属性を、交渉することを可能にする新しいSDP属性を提案しています。それは、例えば、携帯端末のための物理的な画面サイズと異なってもよいという用語画像サイズは、ここで定義されています。一例として、物理画面の一部に映像を表示し、例えばメニューや他の情報のような他の機能のための画面上のスペースを残すことが有益であり得ます。
Allowing negotiation of the image size provides a number of benefits:
画像サイズの許可交渉は多くの利点を提供します。
o Less image distortion: Rescaling of images introduces additional distortion, something that can be avoided (at least on the receiver side) if the image size can be negotiated.
O少ない画像歪み：画像のスケール変更は、画像のサイズをネゴシエートすることができる場合には（少なくとも受信側）を回避することができるものを追加の歪みを導入します。
o Reduced receiver complexity: Image rescaling can be quite computation intensive. For low-end devices, this can be a problem.
Oの削減受信機の複雑：画像再スケーリングは、集中的な、非常に計算することができます。ローエンドのデバイスの場合、これが問題になる可能性があります。
o Optimal quality for the given bitrate: The sender does not need to encode an entire CIF (352x288) image if only an image size of 288x256 is displayed on the receiver screen.
所与のビットレートのために最適な品質O：288x256の画像のみサイズが受信画面に表示されている場合、送信者は、全体のCIF（352×288）の画像を符号化する必要はありません。
o Memory requirement: The receiver device will know the size of the image and can then allocate memory accordingly.
Oメモリ要件：受信装置は、画像のサイズを知っているであろうし、それに応じてメモリを割り当てることができます。
o Optimal aspect ratio: The indication of the supported image sizes and aspect ratio allows the receiver to select the most appropriate combination based on its rescaling capabilities and the desired rendering. For example, if a sender proposes three resolutions in its SDP offer (100x200, 200x100, and 100x100) with sar=1.0 (1:1) etc., then the receiver can select the option that fits the receiver screen best.
O最適なアスペクト比：サポートされている画像サイズとアスペクト比の指示は、受信機がその再スケーリング機能及び所望のレンダリングに基づいて、最も適切な組み合わせを選択することができます。送信者がSARとのSDPオファー（100x200、200x100、および100×100）での3つの解像度= 1.0（1：1）を提案する場合たとえば、などを、受信機は、最良の受信画面に合ったオプションを選択することができます。
In cases where rescaling is not implemented (for example, rescaling is not mandatory to implement in H.264 [H.264]), the indication of the image attributes may still provide an optimal use of bandwidth because the attribute will give the encoder a better indication about what image size is preferred anyway and will thus help to avoid wasting bandwidth by encoding with an unnecessarily large resolution.
属性は、エンコーダAを与えるので、再スケーリングが実装されていない場合（例えば、再スケーリングはH.264 [264]に実装するために必須ではない）において、画像属性の表示は依然として帯域幅の最適な使用を提供することができますとにかく好まれるため、不必要に大きな解像度で符号化することにより、帯域幅の浪費を避けるのに役立ちますどのような画像サイズについて、より良い兆候。
For implementers that are considering rescaling issues, it is worth noting that there are several benefits to doing it on the sender side:
送信側でそれをやってにいくつかのメリットがあることを再スケーリングの問題を検討している実装のために、それは注目に値します。
o Rescaling on the sender/encoder side is likely to be easier to do as the camera-related software/hardware already contains the necessary functionality for zooming/cropping/trimming/sharpening the video signal. Moreover, rescaling is generally done in RGB or YUV domains and should not depend on the codecs used.
カメラ関連のソフトウェア/ハードウェアは既に映像信号を鮮鋭化/トリミング/トリミング/ズームのために必要な機能が含まれているように、送信者/エンコーダ側で再スケーリングoを行うことが容易である可能性が高いです。また、リスケーリングは、一般にRGB又はYUVドメインで行われ、使用されるコーデックに依存するべきではありません。
o The encoder may be able to encode in a number of formats but may not know which format to choose as, without the image attribute, it does not know the receiver's performance or preference.
エンコーダは、フォーマットの数で符号化することができるかもしれないが、画像属性なし、として選択するためにどのフォーマットを知らないかもしれないO、それは受信機のパフォーマンスや嗜好を知りません。
o The quality drop due to digital domain rescaling using interpolation is likely to be lower if it is done before the video encoding rather than after the decoding especially when low bitrate video coding is used.
それはビデオ符号化の前ではなく、低ビットレートビデオ符号化が使用され、特に、復号後に行われる場合、品質低下Oによる補間を使用して再スケーリングデジタルドメインに低くなる可能性があります。
o If low-complexity rescaling operations such as simple cropping must be performed, the benefit with having this functionality on the sender side is that it is then possible to present a miniature "what you send" image on the display to help the user to frame the image correctly.
このような単純なトリミングなどの低複雑再スケーリング操作を実行する必要がある場合は、O、送信者側では、この機能を有する利点は、ミニチュアを提示することが可能であるということであるフレームに、ユーザを支援するために、ディスプレイ上の画像を「あなたが送って何を」正しく画像。
Several of the existing standards ([H.263], [H.264], and [MPEG-4]) have support for different resolutions at different framerates. The purpose of this document is to provide for a generic mechanism, which is targeted mainly at the negotiation of the image size. However, to make it more general, the attribute is named 'imageattr'.
既存の規格のいくつか（[H.263]、[264]、および[MPEG-4]）、異なるフレームレートで異なる解像度をサポートしています。このドキュメントの目的は、画像サイズの交渉で主に対象としている一般的なメカニズム、を提供することです。しかし、それはより一般的にするために、属性が「imageattr」という名前です。
This document is limited to point-to-point unicast communication scenarios. The attribute may be used in centralized conferencing scenarios as well but due to the abundance of configuration options, it may then be difficult to come up with a configuration that fits all parties.
この文書は、ポイントツーポイントのユニキャスト通信シナリオに制限されます。属性は、同様に、集中会議シナリオで使用することができるが、原因の構成オプションの豊富さに、すべての関係者に合った構成を考え出すことが困難な場合があります。
The design of the image attribute is based on the following requirements, which are listed only for informational purposes:
画像属性のデザインは、情報提供のみを目的として記載されている以下の要件に基づいています：
REQ-1: Support the indication of one or more set(s) of image attributes that the SDP endpoint wishes to receive or send. Each image attribute set must include a specific image size.
REQ-1：画像の一つ以上のセット（S）の表示をサポートは、SDPエンドポイントが受信または送信することを望む属性。各画像の属性セットは、特定の画像サイズを含める必要があります。
REQ-2: Support setup/negotiation of image attributes, meaning that each side in the Offer/Answer should be able to negotiate the image attributes it prefers to send and receive.
REQ-2：画像の属性のサポートのセットアップ/交渉、オファー/アンサーの各側が画像を交渉することができるはずという意味は、それが送信および受信することを好む属性。
REQ-3: Interoperate with codec-specific parameters such as sprop-parameter-sets in [H.264] or config in [MPEG-4].
REQ-3：そのような[MPEG-4]の[264]または設定でのspropパラメータセットとしてコーデック固有のパラメータと相互運用。
REQ-4: Make the attribute generic with as few codec specific details/tricks as possible in order to be codec agnostic.
REQ-4：コーデックに依存しないようにするために可能な限り少ないコーデック具体的な詳細/トリックと属性は、一般的なことを確認します。
Besides the above mentioned requirements, the requirement below may be applicable.
上記の要件に加え、以下の要件が適用可能です。
OPT-1: The image attribute should support the description of image-related attributes for various types of media, including video, pictures, images, etc.
OPT-1：画像の属性は、などの各種媒体、などのビデオ、写真、画像、用の画像関連の属性の記述をサポートする必要があります
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section defines the SDP image attribute 'imageattr', which can be used in an SDP Offer/Answer exchange to indicate various image attribute parameters. In this document, we define the following image attribute parameters: image resolution, sample aspect ratio (sar), allowed range in picture aspect ratio (par) and the preference of a given parameter set over another (q). The attribute is extensible and guidelines for defining additional parameters are provided in Section 3.2.10.
このセクションでは、様々な画像属性パラメータを示すために、SDPオファー/アンサー交換に使用することができるSDP画像属性「imageattr」を定義します。画像解像度、サンプルアスペクト比（SAR）、画像のアスペクト比（PAR）と別の（Q）上に設定された所定のパラメータの嗜好に許容範囲：この文書では、我々は、以下の画像属性パラメータを定義します。属性は拡張可能であり、追加のパラメータを定義するためのガイドラインは、セクション3.2.10で提供されています。
In this section, the syntax of the 'imageattr' attribute is described. The 'imageattr' attribute is a media-level attribute. The section is split up in two parts: the first gives an overall view of the syntax, and the second describes how the syntax is used.
このセクションでは、「imageattr」属性の構文が記述されています。 「imageattr」属性は、メディア・レベルの属性です。セクションでは、2つの部分に分割されている：最初の構文の全体的なビューを提供し、そして第二の構文が使用されている方法について説明します。
The syntax for the image attribute is in ABNF [RFC5234]:
画像属性の構文は、ABNF [RFC5234]です：
image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
1*WSP attr-list )
PT = 1*DIGIT / "*"
attr-list = ( set *(1*WSP set) ) / "*"
; WSP and DIGIT defined in [RFC5234]
set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]" ; x is the horizontal image size range (pixel count) ; y is the vertical image size range (pixel count)
セット= "[" "X =" xyrange "" "Y =" xyrange×（ "" キー値） "]"; xは水平方向の画像サイズの範囲（画素数）です。 yは垂直方向の画像サイズの範囲（画素数）であります
key-value = ( "sar=" srange ) / ( "par=" prange ) / ( "q=" qvalue ) ; Key-value MAY be extended with other keyword ; parameters. ; At most, one instance each of sar, par, or q ; is allowed in a set. ; ; sar (sample aspect ratio) is the sample aspect ratio ; associated with the set (optional, MAY be ignored) ; par (picture aspect ratio) is the allowed ; ratio between the display's x and y physical ; size (optional) ; q (optional, range [0.0..1.0], default value 0.5) ; is the preference for the given set, ; a higher value means a higher preference
キー値=（ "SAR =" srange）/（ "PAR =" PRANGE）/（ "Qは=" のqvalue）。キー値は、他のキーワードで延長することができます。パラメーター。 ;せいぜい、1つのインスタンスSAR、パー、またはqの各;セットで許可されています。 ; ; SAR（サンプルアスペクト比）は、サンプルアスペクト比です。セットに関連付けられている（オプション、無視してもよいです）。 PAR（画像縦横比）が許可されています。ディスプレイのxとyの物理間の比。サイズ（オプション）。 Q（オプション、範囲[0.0..1.0]、デフォルト値0.5）。所与のセットのための好みは、です。より高い値は、より高い優先順位を意味します
onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" ; Digit between 1 and 9 xyvalue = onetonine *5DIGIT ; Digit between 1 and 9 that is ; followed by 0 to 5 other digits step = xyvalue xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" ) ; Range between a lower and an upper value ; with an optional step, default step = 1 ; The rightmost occurrence of xyvalue MUST have a ; higher value than the leftmost occurrence. / ( "[" xyvalue 1*( "," xyvalue ) "]" ) ; Discrete values separated by ',' / ( xyvalue ) ; A single value spvalue = ( "0" "." onetonine *3DIGIT ) ; Values between 0.1000 and 0.9999 / ( onetonine "." 1*4DIGIT ) ; Values between 1.0000 and 9.9999 srange = ( "[" spvalue 1*( "," spvalue ) "]" ) ; Discrete values separated by ','. ; Each occurrence of spvalue MUST be ; greater than the previous occurrence. / ( "[" spvalue "-" spvalue "]" ) ; Range between a lower and an upper level (inclusive) ; The second occurrence of spvalue MUST have a higher ; value than the first / ( spvalue ) ; A single value
onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"。 1と9の間の数字xyvalue = onetonine * 5DIGIT。 1と9の間の数字。 0〜5の他の桁ステップ= xyvalue xyrange =（ "[" "：" [ステップ "：" xyvalue] xyvalue "]"）が続きます。下部及び上限値の範囲。任意のステップと、デフォルトのステップ= 1。 xyvalueの右端の発生が持っている必要があります。左端の発生よりも高い値。 /（ "[" xyvalue 1 *（ "" xyvalue） "]"）; 「」/（xyvalue）によって分離された離散値。単一値spvalue =（ "0" "" onetonine * 3DIGIT。）。 0.1000と0.9999 /の間の値（onetonine 1 * 4桁 ""）; 1.0000と9.9999 srange間の値=（ "[" spvalue 1 *（ "" spvalue） "]"）; 「」で区切られた離散的な値。 ; spvalueの各出現はなければなりません。前の出現よりも大きいです。 /（ "[" spvalue " - " spvalue "]"）;下部及び上部レベル（含む）の範囲。 spvalueの第二の発生が高いが必要です。第一/（spvalue）よりも値。単一の値
prange = ( "[" spvalue "-" spvalue "]" ) ; Range between a lower and an upper level (inclusive) ; The second occurrence of spvalue MUST have a higher ; value than the first
PRANGE =（ "[" spvalue " - " spvalue "]"）;下部及び上部レベル（含む）の範囲。 spvalueの第二の発生が高いが必要です。最初よりも値
qvalue = ( "0" "." 1*2DIGIT ) / ( "1" "." 1*2("0") ) ; Values between 0.00 and 1.00
qvalue =（ "0" "" 1 * 2DIGIT /。）（ "1" 1 * 2（ "0"） ""）; 0.00と1.00の間の値
o The attribute typically contains a "send" and a "recv" keyword. These specify the preferences for the media once the session is set up, in the send and receive direction respectively from the point of view of the sender of the session description. One of the keywords ("send" or "recv") MAY be omitted; see Section 3.2.4 and Section 3.2.2 for a description of cases when this may be appropriate.
O属性は、一般的に「送信」および「RECV」のキーワードが含まれています。これらは、セッションがセットアップされると送信において、メディアの設定を指定し、セッション記述の送信者の観点からそれぞれの方向を受信します。キーワードの一つは、（「送信」または「RECV」）省略されるかもしれません。これが適切であり得るケースの説明については、セクション3.2.4及びセクション3.2.2を参照。
o The "send" keyword and corresponding attribute list (attr-list) MUST NOT occur more than once per image attribute.
O「送信」のキーワードとそれに対応する属性リスト（ATTR-リスト）は、一度画像属性ごとのより多く発生してはなりません。
o The "recv" keyword and corresponding attribute list (attr-list) MUST NOT occur more than once per image attribute.
O「RECV」のキーワードとそれに対応する属性リスト（ATTR-リスト）は、一度画像属性ごとのより多く発生してはなりません。
o PT is the payload type number; it MAY be set to "*" (wild card) to indicate that the attribute applies to all payload types in the media description.
O PTは、ペイロードタイプ番号です。 「*」（ワイルドカード）属性はメディア記述内のすべてのペイロードタイプに適用されることを示すために設定されてもよいです。
o For sendrecv streams, both of the send and recv directions SHOULD be present in the SDP.
Oのsendrecvストリームの場合、送信とRECV方向の双方は、SDPで存在すべきです。
o For inactive streams it is RECOMMENDED that both of the send and recv directions are present in the SDP.
O非アクティブなストリームの場合には、送信及びRECV方向の両方がSDP内に存在することをお勧めします。
The following rules apply for the parameters.
次の規則がパラメータに適用されます。
Payload type number (PT): The image attribute is bound to a specific codec by means of the payload type number. A wild card (*) can be specified for the payload type number to indicate that it applies to all payload types in the media description. Several image attributes can be defined, for instance for different video codec alternatives. This however requires that the payload type numbers differ. Note that the attribute is associated to the codec(s), for instance an SDP offer may specify payload type number 101 while the answer may specify 102, this may make it troublesome to specify a payload type number with the 'imageattr' attribute. See Section 3.2.2 for a discussion and recommendation how this is solved.
ペイロードタイプ番号（PT）：画像属性がペイロードタイプ番号により特定コーデックに結合されています。ワイルドカード（*）は、メディア記述内のすべてのペイロードタイプに適用されることを示すために、ペイロードタイプ番号を指定することができます。いくつかの画像の属性が異なるビデオコーデックの選択肢のインスタンスのために、定義することができます。しかし、これはペイロードタイプ番号が異なっていることが必要です。答えが、これは「imageattr」属性とペイロードタイプ番号を指定することが煩わしいことがあり、102を指定してもよいしながら、例えばSDPオファーは、ペイロードタイプ番号101を指定することができる、属性がコーデック（複数可）に関連していることに留意されたいです。これを解決する方法を議論し、提言については、セクション3.2.2を参照してください。
Preference (q): The preference for each set is 0.5 by default; setting the optional q parameter to another value makes it possible to set different preferences for the sets. A higher value gives a higher preference for the given set.
嗜好（Q）：各セットの優先は、デフォルトで0.5です。別の値に、オプションのqパラメータを設定すると、セットごとに異なる設定を設定することが可能となります。より高い値は、所与のセットのために、より高い優先順位を与えます。
sar: The sar (storage aspect ratio) parameter specifies the sample aspect ratio associated to the given range of x and y values. The sar parameter is defined as dx/dy where dx and dy are the physical size of the pixels. Square pixels gives a sar=1.0. The parameter sar MAY be expressed as a range or as a single value.
SAR：SAR（記憶アスペクト比）パラメーターは、xとyの値の所定の範囲に関連するサンプルアスペクト比を指定します。 SARパラメータは、DX及びDYは、ピクセルの物理的な大きさであるDX / DYと定義されます。スクエアピクセルは、sar = 1.0を与えます。パラメータSARは範囲として、または単一の値として表すことができます。
If this parameter is not present, a default sar value of 1.0 is assumed.
このパラメータが存在しない場合、1.0のデフォルトのSAR値が想定されます。
The interpretation of sar differs between the send and the receive directions.
SARの解釈は、送信と受信方向とで異なります。
* In the send direction, sar defines a specific sample aspect ratio associated to a given x and y image size (range).
*送信方向では、SARは、所与のXおよびYの画像サイズ（範囲）に関連付けられた特定のサンプルアスペクト比を定義します。
* In the recv direction, sar expresses that the receiver of the given medium prefers to receive a given x and y resolution with a given sample aspect ratio.
* RECV方向において、SARは、所与の媒体の受信機は、所与のサンプルアスペクト比で与えられるxとy解像度を受け取ることを好むことを表します。
See Section 3.2.5 for a more detailed discussion.
より詳細な議論については、セクション3.2.5を参照してください。
The sar parameter will likely not solve all the issues that are related to different sample aspect ratios, but it can help to solve them and reduce aspect ratio distortion.
SARパラメータは、おそらく異なるサンプルアスペクト比に関連するすべての問題を解決することはできませんが、それはそれらを解決し、アスペクト比の歪みを低減することができます。
The response MUST NOT include a sar parameter if there is no acceptable value given. The reason for this is that if the response includes a sar parameter it is interpreted as "sar parameter accepted", while removal of the sar parameter is treated as "sar parameter not accepted". For this reason, it is safer to remove an unacceptable sar parameter altogether.
指定した受け入れ可能な値が存在しない場合、応答は、sarパラメータを含んではいけません。この理由は、応答がSARパラメータの除去は「受け入れられないSARパラメータ」として取り扱われている間、それは、「受け入れられたSARパラメータ」として解釈されるSARパラメータを含む場合。このような理由から、完全に容認できないSARパラメータを削除する方が安全です。
par: The par (width/height = x/y ratio) parameter indicates a range of allowed ratios between x and y physical size (picture aspect ratio). This is used to limit the number of x and y image size combinations; par is given as
PAR：PAR（幅/高さ= X / Y比）パラメータは、xとyの物理的サイズ（画像縦横比）との間の許容される比の範囲を示します。これは、XおよびYの画像サイズの組み合わせの数を制限するために使用されます。パーは、以下のように与えられます
par=[ratio_min-ratio_max]
マッチ= [ratio_min-ratio_max]
where ratio_min and ratio_max are the min and max allowed picture aspect ratios.
minとmaxは画像のアスペクト比をratio_minとratio_maxが許可されます。
If sar and the sample aspect ratio that the receiver actually uses in the display are the same (or close), the relation between the x and y pixel resolution and the physical size of the image is straightforward. If however sar differs from the sample aspect ratio of the receiver display, this must be taken into consideration when the x and y pixel resolution alternatives are sorted out. See Section 4.2.4 for an example of this.
SARと受信機が実際に表示に使用するサンプルアスペクト比は同じ（または近い）である場合、XおよびYピクセルの解像度と画像の物理的な大きさの関係は簡単です。しかしながら、SARが受信表示のサンプルアスペクト比と異なる場合、xおよびyピクセルの解像度の選択肢が選別されている場合、これを考慮しなければなりません。この例については、セクション4.2.4を参照してください。
In accordance with [RFC3264], offer/answer exchange of the image attribute is as follows.
[RFC3264]に従って、画像属性のオファー/アンサー交換は以下の通りです。
o Offerer sending the offer:
O申出人は申し出を送信します：
* The offerer must be able to support the image attributes that it offers, unless the offerer has expressed a wild card (*) in the attribute list.
*オファー側は、オファーが属性リストにワイルドカード（*）を表現していない限り、画像は、それが提供している属性をサポートできなければなりません。
* It is recommended that a device that sees no reason to use the image attribute includes the attribute with wild cards (*) in the attribute lists anyway for the send and recv directions. An example of this looks like:
*画像の属性を使用する理由を見ていないデバイスは、送信とrecvの方向のため、とにかく属性リストでワイルドカードを持つ属性（*）が含まれていることをお勧めします。この例は次のようになります。
a=imageattr:97 send * recv *
= imageattr：97センド*のrecv *
This gives the answerer the possibility of expressing its preferences. The use of wild cards introduces a risk that the message size can increase in an uncontrolled way. To reduce this risk, these wild cards SHOULD only be replaced by an as small set as possible.
これは、回答にその嗜好を表現する可能性を提供します。ワイルドカードの使用は、メッセージサイズが制御不能な方法で増やすことができ、リスクを紹介します。このリスクを軽減するために、これらのワイルドカードは、できるだけ小さなセットで交換する必要があります。
o Answerer receiving the offer and sending the answer:
回答を提示申し出を受け、答えを送るO：
* The answerer may choose to keep the image attribute but is not required to do so.
*回答は、画像の属性を維持することを選択するかもしれませんが、そうする必要はありません。
* The answerer may, for its receive and send direction, include one or more entries that it can support from the set of entries proposed in the offer.
*回答は、その受信および送信方向のために、それは申し出で提案されているエントリのセットから支援することができる1つまたは複数のエントリを含むことができます。
* The answerer may also, for its receive and send direction, replace the entries with a complete new set of entries different from the original proposed by the offerer. The implementor of this feature should however be aware that this may cause extra offer/answer exchanges.
*回答も、その受信および送信方向のため、オファー側が提案した、オリジナルと異なるエントリの完全な新しいセットを持つエントリを置き換えることができます。この機能の実装は、しかし、これは余分なオファー/アンサー交換を引き起こす可能性があることに注意してください。
* The answerer may also remove its send direction completely if it is deemed that it cannot support any of the proposed entries.
それは提案エントリのいずれかをサポートすることができないと認められる場合*回答も完全にその送信方向を削除することができます。
* The answerer should not include an image attribute in the answer if it was not present in the offer.
それは申し出には存在しなかった場合*回答は答えにイメージ属性を含めるべきではありません。
o Offerer receiving the answer:
O申出人は答えを受け取ります：
* If the image attribute is not included in the SDP answer the offerer SHOULD continue to process the answer as if this mechanism had not been offered.
*画像属性はSDPに含まれていない場合はオファー側は、このメカニズムが提供されていなかったかのように答えを処理し続けるべきで答えます。
* If the image attribute is included in the SDP answer but none of the entries are usable or acceptable, the offerer MUST resort to other methods to determine the appropriate image size. In this case, the offerer must also issue a new offer/ answer without the image attribute to avoid misunderstandings between the offerer and answerer. This will avoid the risk of infinite negotiations.
*画像属性がSDP回答に含まれるが、エントリのいずれも使用可能または許容されない場合、提供者は、適切な画像サイズを決定する他の方法に頼らなければなりません。この場合、オファー側はまた、オファーと回答間の誤解を避けるために、画像の属性を持たない新しいオファー/アンサーを発行する必要があります。これは、無限の交渉のリスクを回避します。
When the initial offer does not contain the 'imageattr' attribute, the rules in Section 3.1.1.2 require the attribute to be absent in the answer. The reasons for this are:
最初のオファーは「imageattr」属性が含まれていない場合は、セクション3.1.1.2でのルールは答えに存在しないと属性が必要です。その理由は以下のとおりです。
o The offerer of the initial SDP is not likely to understand the image attribute if it did not include it in the offer, bearing in mind that Section 3.1.1 recommends that the offerer provide the attribute with wild carded parameters if it has no preference.
O初期SDPのオファー側は、セクション3.1.1は、それが何の好みを持っていない場合は野生のパラメータをカーディングして、オファーが属性を提供することをお勧めしますことを念頭に、それは提供にそれが含まれていなかった場合は、画像の属性を理解しそうではありません。
o Inclusion of the image attribute in the answer may come in conflict with the rules in Section 3.1.1.2, especially the rules that apply to "offerer receiving the answer".
解答の画像属性を含めるo「のオファー側が答えを受け取る」には適用され、特にルールは、セクション3.1.1.2でのルールに抵触して来るかもしれません。
For the above reasons, it is RECOMMENDED that a device that sees no reason to use the image attribute includes the attribute with wild cards (*) in the attribute lists anyway for the send and recv directions.
上記の理由から、イメージ属性を使用する理由を見ていないデバイスは、送信とrecvの方向のため、とにかく属性リストでワイルドカードを持つ属性（*）が含まれていることを推奨します。
In some cases, the answer may specify a different media payload type number than the offer. As an example, the offer SDP may have the m-line
いくつかのケースでは、答えは提供とは異なるメディアペイロードタイプ番号を指定することもできます。一例として、オファーSDPはmラインを有していてもよいです
m=video 49154 RTP/AVP 99
M =ビデオ49154 RTP / AVP 99
while the answer SDP may have the m-line
アンサーSDPは、m行を有することができます
m=video 49154 RTP/AVP 100
M =ビデオ49154 RTP / AVP 100
If the image attribute in the offer specifies payload type number 99, this attribute will then have no meaning in the answerers receive direction as the m-line specifies media payload type number 100.
クーポンの画像属性は、ペイロードタイプ番号99を指定している場合、この属性は、次いで、回答に意味を持たなくなり、M行は、メディアペイロードタイプ番号100を指定するように方向を受け取ります。
There are a few ways to solve this.
これを解決するには、いくつかの方法があります。
1. Use a wild card "*" as the payload type number in the image attribute in the offer SDP. The answer SDP also uses the wild card. The drawback with this approach is that this attribute then applies to all payload type numbers in the media description.
1.オファーSDPの画像属性にペイロードタイプ番号としてワイルドカード「*」を使用してください。回答SDPも、ワイルドカードを使用しています。このアプローチの欠点は、この属性は、メディア記述の全てのペイロードタイプ番号に適用されることです。
2. Specify a wild card "*" as the payload type number in the image attribute in the answer SDP. The offer SDP may contain a defined payload type number in the image attribute but the answer SDP replaces this with a wild card. The drawback here is similar to what is listed above.
2.回答SDPの画像属性にペイロードタイプ番号として「*」ワイルドカードを指定します。オファーSDPは、画像の属性で定義されたペイロードタイプ番号が含まれていてもよいが、回答SDPは、ワイルドカードでこれを置き換えます。ここでの欠点は、上に挙げたものと同様です。
3. The image attribute is split in two parts in the SDP answer. For example the offer SDP (only the parts of interest in this discussion) looks like:
3.画像の属性は、SDPの答えに二つの部分に分割されます。例えば、オファーSDP（この議論の関心の一部のみ）は以下のようになります。
m=video 49154 RTP/AVP 99
a=imageattr:99 send ... recv ...
The answer SDP looks like:
答えSDPは、次のようになります。
m=video 49154 RTP/AVP 100
a=imageattr:99 send ...
a=imageattr:100 recv ...
This alternative does not pose any drawbacks. Moreover, it allows specification of different image attributes if more than one payload type is specified in the offer SDP.
この選択肢は任意の欠点をもたらすことはありません。複数のペイロードタイプをオファーSDPで指定されている場合また、異なる画像属性の指定を可能にします。
Of the alternatives listed above, the last one MUST be used as it is the most safe. The other alternatives MUST NOT be used.
それが最も安全であるとして、上記の選択肢のうち、最後のものを使用しなければなりません。他の選択肢を使用してはいけません。
While the image attribute supports asymmetry, there are some limitations. One important limitation is that the codec being used can only support up to a given maximum resolution for a given profile level.
画像の属性は、非対称性をサポートしていますが、いくつかの制限があります。一つの重要な制限は、使用されるコーデックにのみ与えられたプロファイルレベルのための所定の最大解像度までサポートすることができるということです。
As an example, H.264 [H.264] with profile level 1.2 does not support higher resolution than 352x288 (CIF). The offer/answer rules imply that the same profile level must be used in both directions. This means that in an asymmetric scenario where Alice wants an image size of 580x360 and Bob wants 150x120, profile level 2.2 is needed in both directions even though profile level 1 would have been sufficient in one direction.
一例として、[264]プロファイルレベル1.2とH.264は、352×288（CIF）よりも高い解像度をサポートしていません。オファー/アンサールールは同じプロファイルレベルが両方向で使用しなければならないことを示唆しています。これは、アリスが580x360の画像サイズを望んでいるとボブは150x120たい非対称シナリオでは、プロファイルレベル2.2は、プロファイル、レベル1が一方向に十分であったであろうにもかかわらず、両方向に必要とされることを意味します。
Currently, the only solution to this problem is to specify two unidirectional media descriptions. Note however that the asymmetry issue for the H.264 codec is solved by means of the level-asymmetry-allowed parameter in [RFC6184].
現在、この問題の唯一の解決策は、2つの単方向メディア記述を指定することです。 H.264コーデックのための非対称の問題は[RFC6184]でのレベル非対称許容パラメータの手段によって解決されることに注意してください。
If the directional attributes a=sendonly or a=recvonly are given for a medium, there is of course no need to specify the image attribute for both directions. Therefore, one of the directions in the attribute may be omitted. However, it may be good to do the image attribute negotiation in both directions in case the session is updated for media in both directions at a later stage.
方向性が= sendonlyでまたは=がrecvonlyメディアのために与えられている属性の場合は、両方向のための画像属性を指定する必要はもちろんありません。そのため、属性の指示の1を省略してもよいです。しかし、セッションは後の段階で両方向のメディアのために更新された場合には、両方向の画像属性のネゴシエーションを行うためには良いかもしれません。
The relationship between the sar parameter and the x and y pixel resolution deserves some extra discussion. Consider the offer from Alice to Bob (we set the recv direction aside for the moment):
SARパラメータxおよびyピクセルの解像度との関係は、いくつかの余分な議論に値します。 （私たちは一瞬脇のrecv方向を設定）アリスからボブへのオファーを検討してください。
a=imageattr:97 send [x=720,y=576,sar=1.1]
= imageattr：97センド[X = 720、Y = 576、SAR = 1.1]
If the receiver display has square pixels, the 720x576 image would need to be rescaled to for example 792x576 or 720x524 to ensure a correct image aspect ratio. This in practice means that rescaling would need to be performed on the receiver side, something that is contrary to the spirit of this document.
受信機ディスプレイは正方形のピクセルを有する場合、720×576の画像は、正しい画像のアスペクト比を確保するために、例えば、792x576または720x524に再スケーリングされる必要があるであろう。これは、実際に再スケーリングは、受信側は、この文書の精神に反している何かに実行する必要があることを意味します。
To avoid this problem Alice may specify a range of values for the sar parameter like:
この問題を回避するにはアリスのようなSARパラメータの値の範囲を指定できます。
a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
= imageattr：97センド[X = 720、Y = 576、SAR = [0.91,1.0,1.09,1.45]
Meaning that Alice can encode with any of the mentioned sample aspect ratios, leaving Bob to decide which one he prefers.
アリスは彼が好むどちらかを決定するために、ボブを残して、前述のサンプルアスペクト比のいずれかでエンコードすることができることを意味します。
The image attribute can be used within the SDP Capability Negotiation [RFC5939] framework and its use is then specified using the "a=acap" parameter. An example is
画像属性はSDP機能ネゴシエーション[RFC5939]のフレームワーク内で使用することができ、その使用は、次いで、「A = ACAP」パラメータを使用して指定されます。例があります
a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
= ACAP：1 imageattr：97センド[X = 720、Y = 576、SAR = [0.91,1.0,1.09,1.45]
For use with SDP Media Capability Negotiation extension [SDPMedCapNeg], where it is no longer possible to specify payload type numbers, it is possible to use the parameter substitution rule, an example of this is
ペイロードタイプ番号を指定することはもはや不可能であるSDPメディア能力ネゴシエーション拡張[SDPMedCapNeg]、で使用するために、それはパラメータ置換ルールを使用することが可能であり、この例は、あります
... a=mcap:1 video H264/90000 a=acap:1 imageattr:%1% send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] ...
... = MCAP：1ビデオH264 / 90000 = ACAP：1 imageattr：％1％の送信[X = 720、Y = 576、SAR = [0.91,1.0,1.09,1.45]]···
where %1% maps to media capability number 1.
どこメディア機能番号1％の1％マップ。
It is also possible to use the a=mscap attribute like in the example below.
以下の例のように、A = mscap属性を使用することも可能です。
...
a=mcap:1 video H264/90000
a=mscap:1 imageattr send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
...
As the SDP for most codecs already specifies some kind of indication of, for example, the image size, at session setup, measures must be taken to avoid conflicts between the image attribute and this already existing information.
ほとんどのコーデックのSDPは、すでにの徴候のいくつかの種類を指定するには、例えば、画像サイズは、セッションセットアップで、対策がイメージ属性と、この既存の情報間の競合を避けるようにしなければなりません。
The following subsections describe the most well known codecs and how they define image-size related information. Section 3.2.7.4 outlines a few possible solutions, but this document does not make a recommendation for any of them.
以下のサブセクションでは、最もよく知られているコーデックを説明し、どのように彼らは、画像サイズに関連する情報を定義します。セクション3.2.7.4は、いくつかの可能な解決策の概要を説明しますが、この文書では、それらのいずれかの勧告を行うものではありません。
The payload format for H.263 [H.263] is described in [RFC4629].
H.263 [H.263]のペイロードフォーマットは、[RFC4629]に記載されています。
H.263 defines (on the fmtp line) a list of image sizes and their maximum frame rates (profiles) that the offerer can receive. The answerer is not allowed to modify this list and must reject a payload type that contains an unsupported profile. The CUSTOM profile may be used for image size negotiation but support for asymmetry requires the specification of two unidirectional media descriptions using the sendonly/recvonly attributes.
申出を受け入れることができる263（のfmtpライン上）を定義する画像サイズのリストとそれらの最大フレームレート（プロファイル）。回答は、このリストを変更することが許可されておらず、サポートされていないプロファイルが含まれているペイロードタイプを拒絶しなければなりません。カスタムプロファイルは、画像サイズのネゴシエーションのために使用することができるが、非対称のサポートががrecvonly / sendonlyの属性を使用して2つの単方向メディア記述を指定する必要があります。
The payload format for H.264 [H.264] is described in [RFC6184].
H.264 [264]のペイロードフォーマットは、[RFC6184]に記載されています。
H.264 defines information related to image size in the fmtp line by means of sprop-parameter-sets. According to the specification, several sprop-parameter-sets may be defined for one payload type. The sprop-parameter-sets describe the image size (+ more) that the offerer sends in the stream and need not be complete. This means that sprop-parameter-sets does not represent any negotiation and the answer is not allowed to change the sprop-parameter-sets.
H.264は、のspropパラメータセットを用いてのfmtp線の画像サイズに関連する情報を定義します。仕様によれば、いくつかのspropパラメータセットは、一つのペイロード・タイプに対して定義されてもよいです。 spropパラメータセットは、オファーがストリームに送信し、完全である必要はないことは、画像サイズ（+以上）を記述します。これは、のspropパラメータセットは、任意の交渉を表していないことを意味し、その答えはのspropパラメータセットを変更することはできません。
This configuration may be changed later inband if for instance image sizes need to be changed or added.
例えば、画像サイズを変更または追加する必要がある場合、この構成は、後に帯域内に変更されてもよいです。
The payload format for MPEG-4 [MPEG-4] is described in [RFC3016].
MPEG-4 [MPEG-4]のペイロードフォーマットは、[RFC3016]に記載されています。
MPEG-4 defines a config parameter on the fmtp line, which is a hexadecimal representation of the MPEG-4 visual configuration information. This configuration does not represent any negotiation and the answer is not allowed to change the parameter.
MPEG-4は、MPEG-4ビジュアル設定情報の16進表現であるのfmtp線、上の設定パラメータを定義します。この構成は、任意の交渉を表していないと答えは、パラメータを変更することはできません。
It is not possible to change the configuration using inband signaling.
インバンドシグナリングを使用して設定を変更することはできません。
The subsections above clearly indicate that this kind of information must be aligned well with the image attribute to avoid conflicts. There are a number of possible solutions, listed below without any preference: o Ignore payload format parameters: This may not work well in the presence of bad channel conditions especially in the beginning of a session. Moreover, this is not a good option for MPEG-4.
明らかに上記のサブセクションでは、この種の情報は、競合を避けるために、画像の属性とよく整列しなければならないことを示しています。任意嗜好なし下記の可能な解の数は、存在する：Oペイロードフォーマットパラメータを無視：これは特に、セッションの初めに悪いチャネル条件の存在下ではうまく機能しないかもしれません。また、これは、MPEG-4のための良好な選択肢ではありません。
o Second session-wide offer/answer round: In the second offer/ answer, the parameters specific to codec payload format are defined based on the outcome of the 'imageattr' negotiation. The drawback with this is that setup of the entire session (including audio) may be delayed considerably, especially as the 'imageattr' negotiation can already itself cost up to two offer/answer rounds. Also, the conflict between the 'imageattr' negotiation and the parameters specific to payload format is still present after the first offer/answer round and a fuzzy/buggy implementation may start media before the second offer/answer is completed with unwanted results.
第二に、セッション全体のオファーO /ラウンド答え：二オファー/アンサーでは、コーデックペイロード形式に固有のパラメータを「imageattr」交渉の結果に基づいて定義されています。これの欠点は、（オーディオを含む）セッション全体の設定が「imageattr」交渉はすでにそれ自体が2オファー/アンサーラウンドまでの費用がかかる、特にとして、大幅に遅れることができることです。また、「imageattr」交渉とペイロードフォーマットに固有のパラメータの間に矛盾が最初にオファー/アンサーラウンドとファジー/バギー実装後も存在している第2のオファー/アンサーが不要な結果で完了する前にメディアを起動することがあります。
o Second session-wide offer/answer round only for video: This is similar to the alternative above with the exception that setup time for audio is not increased; moreover, the port number for video is set to 0 during the first offer answer round to avoid the flow of media.
Oセカンドセッション全体のオファー/ビデオのみのラウンド答えは：これは、オーディオのためのセットアップ時間が増加しないことを除いて、上記の代替に似ています。さらに、ビデオのポート番号は、メディアの流れを避けるために、最初のオファー回答ラウンド中に0に設定されています。
This has the effect that video will blend in some time after the audio is started (up to 2 seconds delay). This alternative is likely the most clean-cut and failsafe. The drawback is, as the port number in the first offer is always zero, the media startup will always be delayed even though it would in fact have been possible to start media after the first offer/answer round.
これは、オーディオが（2秒遅れまで）に開始された後、ビデオはいくつかの時間に溶け込むという効果があります。この選択肢はおそらく最もクリーンカットフェイルセーフです。最初のオファーのポート番号は、メディアの起動は常に、実際には最初のオファー/アンサーラウンド後にメディアを起動することは可能であったであろうにもかかわらず、遅れることになる、常にゼロであるような欠点は、です。
Note that according to [RFC3264], a port number of zero means that the whole media line is rejected, meaning that a new offer for the same port number should be treated as a completely new stream and not as an update. The safest way to solve this problem is to use preconditions; this is however outside the scope of this document.
[RFC3264]によれば、ゼロのポート番号が同じポート番号の新しいオファーは完全に新たなストリームとしてではなく、更新として扱われるべきであることを意味し、全体のメディア行が拒否されたことを意味することに留意されたいです。この問題を解決するための最も安全な方法は、前提条件を使用することです。これは、このドキュメントの範囲外ですが。
A very likely scenario is that a user switches to another phone during a video telephony call or plugs a cellphone into an external monitor. In both cases, it is very likely that a renegotiation is initiated using the SIP-REFER [RFC3515] or SIP-UPDATE [RFC3311] methods. It is RECOMMENDED to negotiate the image size during this renegotiation.
非常に可能性の高いシナリオは、ユーザーがビデオ電話通話中に別の電話に切り替わりや外部モニタに携帯電話を差し込むことです。両方の場合において、再交渉が、SIP REFER [RFC3515]またはSIP UPDATE [RFC3311]の方法を使用して開始される可能性が高いです。この再交渉時に画像サイズを交渉することをお勧めします。
As the image attribute is a media-level attribute, its use with layered codecs causes some concern. If the layers are transported in different RTP streams, the layers are specified on different media descriptions, and the relation is specified using the grouping framework [RFC5888] and the depend attribute [RFC5583]. As it is not possible to specify only one image attribute for several media descriptions the solution is either to specify the same image attribute for each media description, or to only specify the image attribute for the base layer.
画像の属性は、メディア・レベルの属性であるとして、層状のコーデックとその使用は、いくつかの懸念を引き起こします。層は、異なるRTPストリームで搬送される場合、層は、異なるメディア記述に指定され、そして関係をグループ化フレームワーク[RFC5888]および依存属性[RFC5583]を使用して指定されます。その溶液は、各メディアの説明のために、または唯一基本層の画像属性を指定するために同一の画像属性を指定するかのいずれかであり、いくつかのメディアの説明は、1つの画像のみ属性を指定することができないからです。
The image attribute allows for the addition of parameters in the future. To make backwards adaptation possible, an entity that processes the attribute MUST ignore any unknown parameters in the offer and MUST NOT include them in the answer it generates. Addition of future parameters that are not understood by the receiving endpoint may lead to ambiguities if mutual dependencies between parameters exist; therefore, addition of parameters must be done with great care.
画像属性は、将来的にパラメータを追加できます。後方可能の適応にするために、属性を処理するエンティティは、提供中の任意の未知のパラメータを無視しなければならないし、それが生成答えにそれらを含んではいけません。パラメータ間の相互依存性が存在する場合、受信エンドポイントによって理解されていない将来のパラメータの添加が曖昧につながり得ます。そのため、パラメータの追加は、細心の注意を払って行う必要があります。
This section gives some more information on how to use the attribute by means of a high-level example and a few detailed examples.
このセクションでは、高レベルの例といくつかの詳細な例を用いて属性を使用する方法についていくつかのより多くの情報を提供します。
Assume that Alice wishes to set up a session with Bob and that Alice takes the first initiative. The syntactical white-space delimiters (1*WSP) and double-quotes are removed to make reading easier.
アリスはボブとのセッションを設定したいと仮定し、アリスは最初のイニシアチブをとること。構文上の空白区切り文字（1 * WSP）と二重引用符は、簡単に読ん作るために除去されます。
In the offer, Alice provides information for both the send and receive (recv) directions. For the send direction, Alice provides a list that the answerer can select from. For the receive direction, Alice may either specify a desired image size range right away or a * to instruct Bob to reply with a list of image sizes that Bob can support for sending. Using the overall high level syntax the image attribute may then look like
オファーでは、アリスは、送信と受信（RECV）方向の両方のための情報を提供します。送信方向の場合、アリスは回答が選択できるリストを提供します。受信方向のために、アリスは、いずれかすぐに所望の画像サイズの範囲を指定することができるか、*は、ボブは、送信のためにサポートすることができる画像サイズのリストを返信し、ボブに指示します。全体的に高いレベルの構文を使用して画像の属性は、次にように見えるかもしれ
a=imageattr:PT send attr-list recv attr-list
= imageattr：PTのattr-リストのrecv ATTR-リストを送信
or
または
a=imageattr:PT send attr-list recv *
= imageattr：PTのattr-リストRECVを送ります*
In the first alternative, the recv direction may be a full list of desired image size formats. It may however (and most likely) just be a list with one alternative for the preferred x and y resolution.
第一の代替では、RECV方向は、所望の画像サイズ・フォーマットの完全なリストであってもよいです。しかしながら、（最も可能性が高い）だけ好ましいXおよびY解像度のための1つの代替を持つリストであってもよいです。
If Bob supports an x and y resolution in at least one of the X and Y ranges given in the send attr-list and in the recv attr-list of the offer, the answer from Bob will look like:
ボブは、送信ATTR-リストとオファーのRECV attrのリストに与えられたXとYの範囲の少なくとも一方で、xとyの解像度をサポートしている場合は、ボブからの答えは次のようになります。
a=imageattr:PT send attr-list recv attr-list
= imageattr：PTのattr-リストのrecv ATTR-リストを送信
and the offer/answer negotiation is done. Note that the attr-list will likely be pruned in the answer. While it may contain many different alternatives in the offer, it may in the end contain just one or two alternatives.
そして、オファー/アンサーネゴシエーションが行われます。 ATTR-リストはそう答えに剪定されることに注意してください。それは提供の多くの異なる選択肢が含まれていてもよいが、それは最終的に1つか2つの選択肢が含まれていてもよいです。
If Bob does not support any x and y resolution in one of the provided send or recv ranges given in the send attr-list or in the recv attr-list, the corresponding part is removed completely. For instance, if Bob doesn't support any of the offered alternatives in the recv attr-list in the offer, the answer from Bob would look like:
ボブは、送信ATTRリストまたはRECVのATTRリストで指定設け送信またはRECV範囲のいずれかで、任意のxとyの解像度をサポートしていない場合、対応する部分が完全に除去されます。ボブが提供中のrecvのattr-listの提供の選択肢のいずれかをサポートしていない場合たとえば、ボブからの答えは次のようになります。
a=imageattr:PT recv attr-list
= imageattr：PTのrecvのattr-リスト
This section gives a few detailed examples. It is assumed where needed that Alice initiates a session with Bob.
このセクションでは、いくつかの詳細な例を示します。アリスはボブとのセッションを開始することを必要な場所にそれを想定しています。
Two image resolution alternatives are offered with 800x640 with sar=1.1 having the highest preference.
二つの画像の解像度の選択肢は、最も高い優先度を有するSARを有する800x640 = 1.1で提供されています。
It is also indicated that Alice wishes to display video with a resolution of 330x250 on her display.
また、アリスは彼女のディスプレイ上の330x250の解像度で映像を表示するように望んでいることを示しています。
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ recv [x=330,y=250]
= imageattr：97センド[X = 800、Y = 640、SAR = 1.1、Q = 0.6]、[X = 480、Y = 320] \のrecv [X = 330、Y = 250]
In case Bob accepts the "recv [x=330,y=250]", the answer may look like
場合ボブが「RECV [X = 330、Y = 250を」受け入れ、回答は次のように見えるかもしれ
a=imageattr:97 recv [x=800,y=640,sar=1.1] \ send [x=330,y=250]
A = imageattr：97のrecv [X = 800、Y = 640、SAR = 1.1] \送る[X = 330、Y = 250]
indicating that the receiver (Bob) wishes the encoder (on Alice's side) to compensate for a sample aspect ratio of 1.1 (11:10) and desires an image size on its screen of 800x640.
受信機（ボブ）が1.1のサンプルアスペクト比（11時10分）を補償する（アリス側）エンコーダを希望し、800x640のその画面上の画像のサイズを希望することを示しています。
There is however a possibility that "recv [x=330,y=250]" is not supported. If the case, Bob may completely remove this part or replace it with a list of supported image sizes.
"RECV [X = 330、Y = 250]" サポートされていない可能性がしかしあります。場合場合は、ボブは完全にこの部分を削除するか、またはサポートされている画像サイズのリストでそれを置き換えることができます。
a=imageattr:97 recv [x=800,y=640,sar=1.1] \ send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]]
A = imageattr：97のrecv [X = 800、Y = 640、SAR = 1.1] \送る[X = 320：16：640]、Y = 240：16：480]、PAR = [1.2~1.3]
Alice can then select a valid image size that is closest to the one that was originally desired (336x256) and performs a second offer/ answer.
アリスは次いで、本来所望されたもの（336x256）に最も近い第二のオファー/アンサーを行い、有効な画像サイズを選択することができます。
a=imageattr:97 send [x=800,y=640,sar=1.1] \ recv [x=336,y=256]
= imageattr：97センド[Y、X = 800、= 640、SAR = 1.1] \のrecv [X = 336、Y = 256]
Bob replies with:
ボブで応答します：
a=imageattr:97 recv [x=800,y=640,sar=1.1] \ send [x=336,y=256]
A = imageattr：97のrecv [X = 800、Y = 640、SAR = 1.1] \送る[X = 336、Y = 256]
Two image resolution sets are offered with the first having a higher preference (q=0.6).
二つの画像の解像度セットが第有する高級嗜好（Q = 0.6）で提供されています。
a=imageattr:97 \ send [x=[480:16:800],y=[320:16:640],par=[1.2-1.3],q=0.6] \ [x=[176:8:208],y=[144:8:176],par=[1.2-1.3]] \ recv *
A = imageattr：97 \送る[X = 480：16：800]、Y = 320：16：640] =による[1.2~1.3]、Q = 0.6]の\ [X = [176：8：208 ]、Y = 144：8：176] = [1.2-1.3]] \ * RECVによって
The x-axis resolution can take the values 480 to 800 in 16 pixels steps and 176 to 208 in 8 pixels steps. The par parameter limits the set of possible x and y screen resolution combinations such that 800x640 (ratio=1.25) is a valid combination while 720x608 (ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations.
x軸解像度が8つの画素ステップ208に16の画素ステップ800及び176に値480を取ることができます。 PARパラメータが可能xとyの画面解像度組み合わせよう800x640（比= 1.25）のセットを制限720x608（比= 1.18）または800x608（比= 1.31）が無効な組み合わせであるが有効な組み合わせです。
For the recv direction (Bob->Alice), Bob is requested to provide a list of supported image sizes.
RECV方向（Bob->アリス）のために、ボブは、サポートされている画像サイズのリストを提供するように要求されています。
In this example, more of the SDP offer is shown. A complicating factor is that the answerer changes the media payload type number in the offer/answer exchange.
この例では、SDPオファーの複数が示されています。複雑な要因は、回答がオファー/アンサー交換でのメディアペイロードタイプ番号を変更することです。
m=video 49154 RTP/AVP 99 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa a=imageattr:99 \ send [x=176,y=144] [x=224,y=176] [x=272,y=224] [x=320,y=240] \ recv [x=176,y=144] [x=224,y=176] [x=272,y=224,q=0.6] [x=320,y=240]
M =ビデオ49154 RTP / AVP 99 = rtpmap：99 H264 / 90000 =のfmtp：99パケットモード= 0;プロファイルレベルID = 42e011。 \のspropパラメータセット= Z0LgC5ZUCg / Iは、aM4BrFSAa A = imageattr：99 \の送信[Y、X = 176 = 144] [X = 224、Y = 176] [X = 272、Y = 224] [X = 320 、Y = 240] \のrecv [X = 176、Y = 144] [X = 224、Y = 176] [X = 272、Y = 224、Q = 0.6]、[X = 320、Y = 240]
In the send direction, sprop-parameter-sets is defined for a resolution of 320x240, which is the largest image size offered in the send direction. This means that if 320x240 is selected, no additional offer/answer is necessary. In the receive direction, four alternative image sizes are offered with 272x224 being the preferred choice.
送信方向では、のspropパラメータセットは、送信方向で提供される最大の画像サイズである320×240の解像度のために定義されています。これは、320×240を選択した場合は、追加のオファー/アンサーを必要としないことを意味しています。受信方向では、4つの別の画像サイズは272x224の好ましい選択された状態で提供されています。
The answer may look like:
答えは次のようになります。
m=video 49154 RTP/AVP 100 a=rtpmap:100 H264/90000 a=fmtp:100 packetization-mode=0;profile-level-id=42e011; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa a=imageattr:99 send [x=320,y=240] a=imageattr:100 recv [x=320,y=240]
M =ビデオ49154 RTP / AVP 100 = rtpmap：100 H264 / 90000 =のfmtp：100パケットモード= 0;プロファイルレベルID = 42e011。 \のspropパラメータセット= Z0LgC5ZUCg / I、aM4BrFSAa A = imageattr：99センド[X = 320、Y = 240] A = imageattr：100のrecv [X = 320、Y = 240]
indicating (in this example) that the image size is 320x240 in both directions. Although the offerer preferred 272x224 for the receive direction, the answerer might not be able to offer 272x224 or not allow encoding and decoding of video of different image sizes simultaneously. The answerer sets new sprop-parameter-sets, constructed for both send and receive directions at the restricted conditions and image size of 320x240.
画像サイズ（この例では）ことを示すことは両方向で320×240です。オファーは、受信方向のための272x224好ましいが、回答者が同時に異なる画像サイズのビデオの符号化及び復号化を可能に272x224を提供するかすることができないかもしれません。回答は、制限された条件と320×240の画像サイズで方向を送信及び受信の両方のために構築され、新しいのspropパラメータセットを設定します。
Note also that, because the payload type number is changed by the answerer, the image attribute is also split in two parts according to the recommendation in Section 3.2.2.
ペイロードタイプ番号は回答によって変化するため、また、そのメモ、画像属性も3.2.2に推奨に従って二つの部分に分割されます。
This example illustrates in more detail how compensation for different sample aspect ratios can be negotiated with the image attribute.
この例では、異なるサンプルアスペクト比の補正は、画像属性と交渉することができる方法をより詳細に示す図です。
We set up a session between Alice and Bob; Alice is the offerer of the session. The offer (from Alice) contains the image attribute below:
私たちは、アリスとボブの間のセッションを設定します。アリスは、セッションのオファー側です。 （アリスからの）オファーは下の画像の属性が含まれています。
a=imageattr:97 \ send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] \ recv [x=800,y=600,sar=1.1]
= imageattr：97 \送る= [1.2~1.3] \ RECV [X = 800、によって、[640：16：320] SAR = [1.0~1.3]を= Y、[X = 400：800：16] Y = 600、SAR = 1.1]
First we consider the recv direction: The offerer (Alice) explicitly states that she wishes to receive the screen resolution 800x600. However, she also indicates that the screen on her display does not use square pixels; the sar value=1.1 means that Bob must (preferably) compensate for this.
まず、RECV方向を考える：オファー側（アリス）は、明示的に、彼女は画面解像度800×600を受信したいと述べています。しかし、彼女はまた彼女のディスプレイ上の画面が正方形のピクセルを使用していないことを示しています。 SAR値= 1.1ボブは（好ましくは）これを補償しなければならないことを意味します。
So, if Bob's video camera produces square pixels, and if Bob wishes to satisfy Alice's sar requirement, the image processing algorithm must rescale a 880x600 pixel image (880=800*1.1) to 800x600 pixels (could be done other ways).
だから、ボブのビデオカメラは、正方形のピクセルを生成し、ボブがアリスのSAR要件を満足することを望む場合、画像処理アルゴリズムは、（他の方法で行うことができる）、800×600ピクセルに880x600ピクセルの画像（* 1.1 880 = 800）を再スケーリングする必要がある場合。
... and now the send direction: Alice indicates that she can (in the image processing algorithms) rescale the image for sample aspect ratios in the range 1.0 to 1.3. She can also provide a number of different image sizes (in pixels) ranging from 400x320 to 800x640. Bob inspects the offered sar and image sizes and responds with the modified image attribute.
...、現在の送信方向：アリスは1.3の範囲1.0のサンプルアスペクト比のために画像を再スケーリング（画像処理アルゴリズムに）彼女ができることを示しています。彼女はまた、400x320から800x640の範囲（ピクセル）は、異なる画像サイズの数を提供することができます。ボブは、提供SARと画像サイズを検査し、修正された画像の属性で応答します。
a=imageattr:97 \ recv [x=464,y=384,sar=1.15] \ send [x=800,y=600,sar=1.1]
A = imageattr：97 \のrecv [Y、X = 464、= 384、SAR = 1.15] \送る[X = 800、Y = 600、SAR = 1.1]
Alice will (in order to satisfy Bob's request) need to rescale the image from her video camera from 534x384 (534=464*1.15) to 464x384.
アリス意志464x384に534x384（534 = 464 * 1.15）からの彼女のビデオカメラから画像を再スケーリングする必要があります（Bobの要求を満たすために）。
Following the guidelines in [RFC4566], the IANA is requested to register one new SDP attribute:
[RFC4566]のガイドラインに従って、IANAは、一つの新しいSDP属性を登録するように要求されます。
Attribute name: imageattr
imageattr：属性名
Long form name: Image attribute
ロングフォーム名：イメージの属性
Type of attribute: Media-level
属性の種類：メディアレベル
Subject to charset: No
文字セットの件名：いいえ
Purpose: This attribute defines the ability to negotiate various image attributes such as image sizes. The attribute contains a number of parameters which can be modified in an offer/answer exchange.
目的：この属性は、このような画像サイズなどの各種画像の属性を交渉する能力を定義します。属性には、オファー/アンサー交換で変更できるパラメータの数が含まれています。
Appropriate values: See Section 3.1.1 of RFC 6236
適切な値：RFC 6236のセクション3.1.1を参照してください。
Contact name: Authors of RFC 6236
担当者名：RFC 6236の作者
The image attribute and especially the parameters that denote the image size can take on values that may cause memory or CPU exhaustion problems. This may happen either as a consequence of a mistake by the sender of the SDP or as a result of an attack issued by a malicious SDP sender. This issue is similar to the case where the a=fmtp line(s) may take on extreme values for the same reasons outlined above.
画像属性とメモリやCPUの枯渇問題を引き起こす可能性の値を取ることができる画像サイズを表し、特にパラメータ。これは、SDPの送信者のミスの結果として、または悪質なSDPの送信者によって発行された攻撃の結果として起こるかもしれません。この問題は、A =のfmtp線（s）は上に概説したのと同じ理由のために極値をとることができる場合と同様です。
A receiver of the SDP containing the image attribute MUST ensure that the parameters have values that are reasonable and that the device can handle the implications in terms of memory and CPU usage. Failure to do a sanity check on the parameters may result in memory or CPU exhaustion.
画像属性を含むSDPの受信機は、パラメータが妥当な値を持っていることを確認しなければならないとデバイスは、メモリとCPU使用率の点で影響を扱うことができます。パラメータの健全性チェックを怠ると、メモリやCPUの枯渇をもたらすことができます。
In principle, for some SDPs containing the image attribute and for some deployments, it could be the case that simply checking the parameters is not sufficient to detect all potential Denial-of-Service (DoS) problems. Implementers ought to consider whether there are any potential DoS attacks that would not be detected by simply checking parameters.
原則的には、画像の属性を含む、いくつかのSDPのために、いくつかの展開のために、それは単にパラメータをチェックすると、すべての潜在的なサービス拒否（DoS）問題を検出するのに十分でない場合である可能性があります。実装者は、単純にパラメータをチェックすることにより、検出されない任意の潜在的なDoS攻撃があるかどうかを検討するべきです。
The authors would like to thank the people who have contributed with objections and suggestions to this document and provided valuable guidance in the amazing video-coding world. Special thanks to Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Thanks also to Robert Sparks and Paul Kyzivat for the help with the last fixes to get the attribute to work well with the offer/answer model.
作者はこのドキュメントへの異議や提案に貢献し、驚くべきビデオ・コーディングの世界で貴重なガイダンスを提供してきた人たちに感謝したいと思います。クリントンPriddle、ロニでも、ランデルジェサップ、ダンウィングに感謝します。オファー/アンサーモデルとうまく動作するように属性を取得するには、最後の修正のヘルプにもロバート・スパークスとポールKyzivatに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[RFC5583] Schierl、T.とS.ベンゲル監督、 "セッション記述プロトコルにおけるシグナリングメディアのデコード依存（SDP）"、RFC 5583、2009年7月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]キャマリロ、G.およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）グループ化フレームワーク"、RFC 5888、2010年6月。
[H.263] ITU-T, ITU-T Recommendation H.263 (2005): "Video coding for low bit rate communication".
[H.263] ITU-T、ITU-T勧告H.263（2005）： "低ビットレート通信用ビデオ符号化"。
[H.264] ITU-T, ITU-T Recommendation H.264: "Advanced video coding for generic audiovisual services", <http://www.itu.int/rec/T-REC-H.264-200711-S/en>.
[264] ITU-T、ITU-T勧告H.264： "一般的な視聴覚サービスのための高度なビデオコーディング"、<http://www.itu.int/rec/T-REC-H.264-200711- S / EN>。
[MPEG-4] ISO/IEC, ISO/IEC 14496-2:2004: "Information technology - Coding of audio-visual objects - Part 2: Visual".
[MPEG-4] ISO / IEC、ISO / IEC 14496-2：2004： "情報技術 - オーディオビジュアルオブジェクトのコーディング - パート2：ビジュアル"。
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. Kimata, "RTP Payload Format for MPEG-4 Audio/ Visual Streams", RFC 3016, November 2000.
[RFC3016]菊池、Y.、野村、T.、福永、S.、松井、Y.、およびH.木全、 "MPEG-4オーディオ/ビジュアルストリームのためのRTPペイロードフォーマット"、RFC 3016、2000年11月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007.
でも、[RFC4629]オット、H.、ボルマン、C.、サリバン、G.、ウェンガー、S.、およびR.、 "ITU-T勧告のためのRTPペイロードフォーマット"、RFC 4629、2007年1月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]とAndreasen、F.、 "セッション記述プロトコル（SDP）能力ネゴシエーション"、RFC 5939、2010年9月。
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6184]王、Y.、でも、R.、クリステンセン、T.、およびR.ジェサップ、 "H.264ビデオのためのRTPペイロードフォーマット"、RFC 6184、2011年5月。
[SDPMedCapNeg] Gilman, R., Even, R., and F. Andreasen, "SDP Media Mapabilities Negotiation", Work in Progress, February 2011.
[SDPMedCapNeg]ギルマン、R.、でも、R.、およびF.アンドレア、 "SDPメディアMapabilities交渉"、進歩、2011年2月での作業。
Authors' Addresses
著者のアドレス
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Luleae SWEDEN
インゲマル・ヨハンソン、エリクソンAB研究所グランド11 SE-971 28 Luleae SWEDEN
Phone: +46 73 0783289 EMail: ingemar.s.johansson@ericsson.com
電話：+46 73 0783289 Eメール：ingemar.s.johansson@ericsson.com
Kyunghun Jung Samsung Electronics Co., Ltd. Dong Suwon P.O. Box 105 416, Maetan-3Dong, Yeongtong-gu Suwon-city, Gyeonggi-do Korea 442-600
Kyunghunユングサムスン電子株式会社ドン水原私書箱韓国442から600 Maetan-3Dong、霊通区水原市は、京畿道105 416を、箱
Phone: +82 10 9909 4743 EMail: kyunghun.jung@samsung.com
電話：+82 10 9909 4743 Eメール：kyunghun.jung@samsung.com