[要約] RFC 6236は、SDPでの一般的な画像属性の交渉に関する規格です。その目的は、SDPセッションでの画像属性の交換と適切な処理を可能にすることです。
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)
セッション説明プロトコル（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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（352x288）画像全体をエンコードする必要はありません。
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 = 1.0（1：1）などでSDPオファー（100x200、200x100、および100x100）で3つの解像度を提案する場合、受信機は受信機画面に最適なオプションを選択できます。
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.
再スケーリングが実装されていない場合（たとえば、H.264 [H.264]で実装するのに再スケーリングが必須ではありません）、画像属性の表示は、属性がエンコーダーにAを与えるため、帯域幅の最適な使用を提供する可能性があります。とにかく、どの画像サイズが好まれるかについてのより良い兆候は、不必要に大きな解像度でエンコードすることにより帯域幅を無駄にするのを避けるのに役立ちます。
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]、[H.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：SDPエンドポイントが受け取りまたは送信したいという画像属性の1つ以上のセットの表示をサポートします。各画像属性セットには、特定の画像サイズを含める必要があります。
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：[H.264]のSprop-Parameter-Setsや[MPEG-4]の構成などのコーデック固有のパラメーターと相互運用します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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イメージ属性「ImageAttr」を定義します。これは、さまざまな画像属性パラメーターを示すためにSDPオファー/回答交換で使用できます。このドキュメントでは、次の画像属性パラメーターを定義します：画像解像度、サンプルアスペクト比（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つの部分に分割されています。1つ目は構文の全体的なビューを示し、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)
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
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
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
qvalue = ( "0" "." 1*2DIGIT )
/ ( "1" "." 1*2("0") )
; Values between 0.00 and 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」キーワードが含まれます。これらは、セッションの送信者の観点からそれぞれセッションがセットアップされた後、セッションがセットアップされた後、メディアの設定を指定します。キーワードの1つ（ "send"または "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-list）は、画像属性ごとに1回以上発生してはなりません。
o The "recv" keyword and corresponding attribute list (attr-list) MUST NOT occur more than once per image attribute.
o 「recv」キーワードと対応する属性リスト（属性リスト）は、画像属性ごとに1回以上発生してはなりません。
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ストリームの場合、SDPにはSENDおよびRECVの両方の方向が存在する必要があります。
o For inactive streams it is RECOMMENDED that both of the send and recv directions are present in the SDP.
o 非アクティブなストリームの場合、SDPにはSENDおよびRECVの両方の方向が存在することが推奨されます。
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）：画像属性は、ペイロードタイプ番号によって特定のコーデックに結合されます。ペイロードタイプ番号にワイルドカード（*）を指定して、メディアの説明内のすべてのペイロードタイプに適用されることを示すことができます。たとえば、さまざまなビデオコーデックの代替案について、いくつかの画像属性を定義できます。ただし、これには、ペイロードタイプの数値が異なる必要があります。属性はコーデックに関連付けられていることに注意してください。たとえば、SDPオファーはペイロードタイプ番号101を指定する場合がありますが、回答は102を指定する場合があります。これがどのように解決されるかについての議論と推奨については、セクション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はとして与えられます
par=[ratio_min-ratio_max]
par = [ratio_min-ratio_max]
where ratio_min and ratio_max are the min and max allowed picture aspect ratios.
ここで、Ratio_MinとRatio_MaxはMinであり、最大値は画像のアスペクト比です。
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:
* 画像属性を使用する理由がないと思われるデバイスには、SendおよびRecvの方向に対して、とにかく属性リストにワイルドカード（*）の属性が含まれることをお勧めします。この例は次のように見えます：
a=imageattr:97 send * 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.
上記の理由により、画像属性を使用する理由を見ないデバイスには、Sendおよび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-Lineがメディアペイロードタイプ番号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回答の2つの部分に分割されます。たとえば、SDPの申し出（この議論の関心のある部分のみ）は次のように見えます。
m=video 49154 RTP/AVP 99 a=imageattr:99 send ... recv ...
M =ビデオ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.
画像属性は非対称性をサポートしていますが、いくつかの制限があります。1つの重要な制限は、使用されているコーデックが特定のプロファイルレベルの特定の最大解像度のみをサポートできることです。
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.
例として、プロファイルレベル1.2のH.264 [H.264]は、352x288（CIF）よりも高い解像度をサポートしていません。オファー/回答ルールは、同じプロファイルレベルを両方向に使用する必要があることを意味します。これは、アリスが580x360の画像サイズを望んでおり、ボブが150x120を望んでいる非対称シナリオでは、プロファイルレベル1が一方向で十分であっても、プロファイルレベル2.2が両方向に必要であることを意味します。
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.
方向属性a = sendonlyまたはa = 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]
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.
受信機ディスプレイに平方ピクセルがある場合、720x576の画像を、たとえば792x576または720x524に再スケーリングする必要があります。これは、実際には、この文書の精神に反して、レシーバー側で再スケーリングを実行する必要があることを意味します。
To avoid this problem Alice may specify a range of values for the sar parameter like:
この問題を回避するために、Aliceは次のようなSARパラメーターの値の範囲を指定する場合があります。
a=imageattr:97 send [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]]
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]]
...
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.
H.263は（FMTP行で）画像サイズのリストと、提供者が受信できる最大フレームレート（プロファイル）を定義します。回答者はこのリストを変更することは許可されておらず、サポートされていないプロファイルを含むペイロードタイプを拒否する必要があります。カスタムプロファイルは画像サイズのネゴシエーションに使用される場合がありますが、非対称性のサポートには、Sendonly/Recvonly属性を使用して2つの単方向メディア説明の指定が必要です。
The payload format for H.264 [H.264] is described in [RFC6184].
H.264 [H.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行の画像サイズに関連する情報を定義します。仕様によると、1つのペイロードタイプに対していくつかのSPROPパラメーターセットを定義できます。SPROP-Parameter-Setsは、オファーがストリームで送信する画像サイズ（その他）を記述し、完全である必要はありません。これは、Sprop-Parameter-Setsが交渉を表しておらず、答えがSprop-Parameterセットを変更することを許可されていないことを意味します。
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は、FMTP行の構成パラメーターを定義します。これは、MPEG-4視覚構成情報の16進表現です。この構成は交渉を表すものではなく、答えはパラメーターを変更することは許可されていません。
It is not possible to change the configuration using inband signaling.
Inbandシグナル伝達を使用して構成を変更することはできません。
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 2番目のセッション全体のオファー/回答ラウンド：2番目のオファー/回答では、コーデックペイロード形式に固有のパラメーターは、「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
a = imageattr：ptはattr-list recv attr-listを送信します
or
また
a=imageattr:PT send attr-list 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:
Bobが送信属性リストとオファーのRECVアトリストで与えられたXおよびY範囲の少なくとも1つでXとYの解像度をサポートしている場合、ボブからの答えは次のようになります。
a=imageattr:PT send attr-list recv attr-list
a = imageattr：ptはattr-list recv attr-listを送信します
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.
そして、申し出/回答の交渉が行われます。アットリストはおそらく答えに剪定されることに注意してください。オファーには多くの異なる代替品が含まれている可能性がありますが、最終的には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:
BOBが、送信属性リストまたはRECVアトリストに与えられた提供された送信またはRECV範囲の1つでxおよびyの解像度をサポートしていない場合、対応する部分は完全に削除されます。たとえば、ボブがオファーのRECVアットリストで提供されている代替案のいずれをサポートしていない場合、ボブからの答えは次のようになります。
a=imageattr:PT recv attr-list
a = imageattr：pt recv attr-list
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.
800x640で2つの画像解像度の代替品が提供され、SAR = 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]
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]
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.
レシーバー（BOB）がエンコーダー（アリス側）にサンプルアスペクト比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]]
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）に最も近い有効な画像サイズを選択し、2回目のオファー/回答を実行できます。
a=imageattr:97 send [x=800,y=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]
Two image resolution sets are offered with the first having a higher preference (q=0.6).
2つの画像解像度セットが提供され、最初は優先度が高くなります（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 *
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軸の解像度は、16ピクセルのステップで値480〜800、8ピクセルのステップで176〜208を取得できます。PARパラメーターは、800x640（比率= 1.25）が有効な組み合わせであり、720x608（比= 1.18）または800x608（比= 1.31）が無効な組み合わせであるため、可能なXとYの画面解像度の組み合わせのセットを制限します。
For the recv direction (Bob->Alice), Bob is requested to provide a list of supported image sizes.
RECV方向（Bob-> Alice）の場合、ボブはサポートされている画像サイズのリストを提供するように要求されます。
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]
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-Parameter-Setsは、送信方向で提供される最大の画像サイズである320x240の解像度に対して定義されます。これは、320x240が選択されている場合、追加のオファー/回答が必要ないことを意味します。受信方向では、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]
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.
画像サイズが両方向に320x240であることを（この例で）示します。オファーは受信方向に272x224を好みましたが、回答者は272x224を提供できないか、異なる画像サイズのビデオのエンコードとデコードを同時に許可しない可能性があります。回答者は、320x240の制限条件と画像サイズで指示を送信および受信するために構築された新しいSprop-Parameter-Setsを設定します。
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.
また、ペイロードタイプ数はexwnerによって変更されるため、セクション3.2.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]
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の方向を検討します。Offerer（Alice）は、画面解像度800x600を受け取ることを希望することを明示的に述べています。しかし、彼女はまた、ディスプレイの画面が平方ピクセルを使用していないことも示しています。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要件を満たしたい場合、画像処理アルゴリズムは880x600ピクセル画像（880 = 800*1.1）から800x600ピクセル（他の方法で行うことができます）を再スケーリングする必要があります。
... 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.0〜1.3の範囲のサンプルアスペクト比の画像を再販売できることを示しています。また、400x320から800x640の範囲のさまざまな画像サイズ（ピクセル）を提供することもできます。ボブは、提供されているSARと画像サイズを検査し、修正された画像属性で応答します。
a=imageattr:97 \
recv [x=464,y=384,sar=1.15] \
send [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.
アリスは（ボブのリクエストを満たすために）534x384（534 = 464*1.15）から464x384までのビデオカメラから画像を再スケーリングする必要があります。
Following the guidelines in [RFC4566], the IANA is requested to register one new SDP attribute:
[RFC4566]のガイドラインに従って、IANAは1つの新しいSDP属性を登録するように要求されます。
Attribute name: imageattr
属性名：ImageAttr
Long form name: Image attribute Type of attribute: Media-level
長いフォーム名：画像属性属性のタイプ：メディアレベル
Subject to charset: No
charsetの対象：いいえ
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行が上記と同じ理由で極端な値をとる場合がある場合に似ています。
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.
著者は、この文書に異議と提案に貢献した人々に感謝し、驚くべきビデオコーディングの世界で貴重なガイダンスを提供したいと思います。クリントン・プリドル、ロニ・イヴ・イヴ・ランデル・ジェサップ、ダン・ウィングに感謝します。ロバート・スパークスとポール・キジバトにも感謝します。最後の修正の助けを借りて、オファー/回答モデルでうまく機能する属性を取得します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、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. Wenger、「セッション説明プロトコル（SDP）のシグナリングメディアデコード依存関係」、RFC 5583、2009年7月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、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>.
[H.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] Kikuchi、Y.、Nomura、T.、Fukunaga、S.、Matsui、Y.、およびH. kimata、「MPEG-4オーディオ/ビジュアルストリームのRTPペイロード形式」、RFC 3016、2000年11月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、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] Ott、H.、Bormann、C.、Sullivan、G.、Wenger、S。、およびR.
[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] Wang、Y.、Even、R.、Kristensen、T。、およびR. Jesup、「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] Gilman、R。、Even、R。、およびF. Andreasen、「SDP Media Mapabilities Negotiation」、Work in Progress、2011年2月。
Authors' Addresses
著者のアドレス
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Luleae SWEDEN
Ingemar Johansson Ericsson AB LaboratorieGrand 11 SE-971 28 Luleae Sweden
Phone: +46 73 0783289
EMail: 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 Jung Samsung Electronics Co.、Ltd。Dong Suwon P.O.Box 105 416、Maetan-3dong、Yeongtong-Gu Suwon-City、Gyeonggi-Do Korea 442-600
Phone: +82 10 9909 4743
EMail: kyunghun.jung@samsung.com