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
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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 最佳纵横比：支持的图像大小和纵横比指示允许接收器根据其重缩放功能和所需渲染选择最合适的组合。例如，如果发送方在其SDP报价中提出三种分辨率（100x200、200x100和100x100），sar=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.
在未实施重缩放的情况下（例如，在H.264[H.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
o 在发送器/编码器端重新缩放可能更容易，因为与相机相关的软件/硬件已经包含
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.
缩放/裁剪/修剪/锐化视频信号的必要功能。此外，重缩放通常在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端点希望接收或发送的一组或多组图像属性。每个图像属性集必须包含特定的图像大小。
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参数集或[MPEG-4]中的config。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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”属性是媒体级属性。本节分为两部分：第一部分给出语法的总体视图，第二部分描述如何使用语法。
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]
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)
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
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
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
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
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 该属性通常包含一个“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 对于每个图像属性，“发送”关键字和相应的属性列表（属性列表）不得出现一次以上。
o The "recv" keyword and corresponding attribute list (attr-list) MUST NOT occur more than once per image attribute.
o 对于每个图像属性，“recv”关键字和相应的属性列表（attr list）不得出现一次以上。
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中同时存在发送和接收方向。
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
有效负载类型编号（PT）：图像属性通过有效负载类型编号绑定到特定编解码器。可以为有效负载类型编号指定通配符（*），以指示它适用于介质描述中的所有有效负载类型。可以定义多个图像属性，例如用于不同的视频编解码器备选方案。然而，这要求有效负载类型编号不同。请注意，该属性与编解码器相关联，例如，SDP提供可以指定有效负载类型编号101，而应答可以指定102，这可能会使以下操作变得麻烦：
specify a payload type number with the 'imageattr' attribute. See Section 3.2.2 for a discussion and recommendation how this is solved.
使用“imageattr”属性指定有效负载类型编号。有关如何解决此问题的讨论和建议，请参见第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.
如果此参数不存在，则假定默认sar值为1.0。
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=[比率\最小比率\最大比率]
where ratio_min and ratio_max are the min and max allowed picture aspect ratios.
其中，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:
* 建议认为没有理由使用图像属性的设备在发送和接收方向的属性列表中包含带有通配符（*）的属性。这方面的一个例子如下所示：
a=imageattr:97 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.
* 对于其接收和发送方向，应答者可以包括一个或多个条目，它可以从报价中提议的条目集合中支持这些条目。
* 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.
出于上述原因，建议认为没有理由使用图像属性的设备在发送和接收方向的属性列表中包含带有通配符（*）的属性。
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 ...
m=视频49154 RTP/AVP 99 a=图像属性：99发送。。。记录。。。
The answer SDP looks like:
SDP的答案如下所示：
m=video 49154 RTP/AVP 100 a=imageattr:99 send ... a=imageattr:100 recv ...
m=视频49154 RTP/AVP 100 a=图像属性：99发送。。。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.
这种替代方案没有任何缺点。此外，如果在offer 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.
例如，配置文件级别为1.2的H.264[H.264]不支持高于352x288（CIF）的分辨率。报价/应答规则意味着必须在两个方向上使用相同的配置文件级别。这意味着，在Alice希望图像大小为580x360而Bob希望图像大小为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].
目前，这个问题的唯一解决方案是指定两个单向介质描述。然而，请注意，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=recvoOnly，则当然不需要为两个方向指定图像属性。因此，可以省略属性中的一个方向。然而，如果在稍后阶段针对两个方向上的媒体更新会话，则最好在两个方向上进行图像属性协商。
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]
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]]
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.
这意味着Alice可以使用任何提到的示例纵横比进行编码，让Bob决定他更喜欢哪一个。
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]]
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]] ...
... a=mcap:1视频H264/90000 a=acap:1图像属性：%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]] ...
... a=mcap:1视频H264/90000 a=mscap:1图像属性发送[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].
[RFC4629]中描述了H.263[H.263]的有效负载格式。
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/RecvoOnly属性指定两个单向媒体描述。
The payload format for H.264 [H.264] is described in [RFC6184].
[RFC6184]中描述了H.264[H.264]的有效负载格式。
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].
[RFC3016]中描述了MPEG-4[MPEG-4]的有效载荷格式。
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视觉配置信息的十六进制表示形式。此配置不代表任何协商，不允许答案更改参数。
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”协商本身可能会花费多达两轮的报价/应答。此外，“imageattr”协商和特定于有效负载格式的参数之间的冲突在第一轮报价/应答后仍然存在，模糊/错误实现可能在第二轮报价/应答完成之前启动媒体，并产生不必要的结果。
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]指定关系。由于无法为多个媒体描述仅指定一个图像属性，因此解决方案是为每个媒体描述指定相同的图像属性，或者仅为基本层指定图像属性。
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.
假设Alice希望与Bob建立会话，并且Alice采取了第一个主动。删除了语法空白分隔符（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
在报价中，Alice提供了发送和接收（recv）方向的信息。对于发送方向，Alice提供了一个列表，回答者可以从中选择。对于接收方向，Alice可以立即指定所需的图像大小范围，或者用*指示Bob回复Bob可以支持发送的图像大小列表。使用整体高级语法，图像属性可能看起来像
a=imageattr:PT send attr-list recv attr-list
a=imageattr:PT发送属性列表recv属性列表
or
或
a=imageattr:PT send attr-list recv *
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分辨率的备选方案。
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在报价的send attr列表和recv attr列表中给出的至少一个x和y范围内支持x和y分辨率，Bob的回答如下所示：
a=imageattr:PT send attr-list recv attr-list
a=imageattr:PT发送属性列表recv属性列表
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列表可能会被删除。虽然报价中可能包含许多不同的备选方案，但最终可能只包含一个或两个备选方案。
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在send attr列表或recv attr列表中提供的发送或接收范围之一中不支持任何x和y分辨率，则会完全删除相应的部分。例如，如果Bob不支持报价中recv attr列表中提供的任何备选方案，Bob的回答如下：
a=imageattr:PT recv attr-list
a=imageattr:PT recv attr列表
This section gives a few detailed examples. It is assumed where needed that Alice initiates a session with Bob.
本节给出了几个详细的示例。假设Alice在需要的地方启动与Bob的会话。
Two image resolution alternatives are offered with 800x640 with sar=1.1 having the highest preference.
800x640和sar=1.1提供了两种图像分辨率备选方案，具有最高的首选。
It is also indicated that Alice wishes to display video with a resolution of 330x250 on her display.
还表明Alice希望在其显示器上显示分辨率为330x250的视频。
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
recv [x=330,y=250]
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
如果Bob接受“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] \
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）希望编码器（在Alice侧）补偿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]”。如果是这种情况，Bob可能会完全删除此部分，或者用支持的图像大小列表替换它。
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] \
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.
然后，Alice可以选择一个最接近最初所需图像大小（336x256）的有效图像大小，并执行第二次提供/回答。
a=imageattr:97 send [x=800,y=640,sar=1.1] \
recv [x=336,y=256]
a=imageattr:97 send [x=800,y=640,sar=1.1] \
recv [x=336,y=256]
Bob replies with:
Bob回答说：
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] \
send [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 \
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参数限制了可能的X和Y屏幕分辨率组合的集合，使得800×640（比率＝1.25）是有效的组合，而720x608（比率＝1.18）或800×608（比率＝1.31）是无效组合。
For the recv direction (Bob->Alice), Bob is requested to provide a list of supported image sizes.
对于recv方向（Bob->Alice），要求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=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.
在发送方向上，定义了分辨率为320x240的sprop参数集，这是发送方向上提供的最大图像大小。这意味着，如果选择320x240，则无需额外报价/答复。在接收方向上，提供了四种可选图像尺寸，其中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=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或不允许同时对不同图像大小的视频进行编码和解码。应答器设置新的sprop参数集，该参数集在受限条件和320x240图像大小下为发送和接收方向构建。
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:
我们在Alice和Bob之间安排了一次会议；艾丽斯是这次会议的发起者。报价（来自Alice）包含以下图像属性：
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]
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方向：提供器（爱丽丝）明确地表示她希望接收屏幕分辨率800×600。然而，她也指出，她显示器上的屏幕不使用方形像素；sar值=1.1意味着Bob必须（最好）对此进行补偿。
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).
因此，如果Bob的摄像机产生方形像素，并且Bob希望满足Alice的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.
... 现在是发送方向：Alice表示她可以（在图像处理算法中）根据1.0到1.3范围内的样本纵横比重新缩放图像。她还可以提供从400x320到800x640的多种不同图像大小（以像素为单位）。Bob检查提供的sar和图像大小，并使用修改后的图像属性进行响应。
a=imageattr:97 \
recv [x=464,y=384,sar=1.15] \
send [x=800,y=600,sar=1.1]
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.
Alice（为了满足Bob的要求）需要将摄像机中的图像从534x384（534=464*1.15）重新缩放到464x384。
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
联系人姓名：RFC6236的作者
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.
作者要感谢那些对本文档提出异议和建议的人，他们在令人惊叹的视频编码世界中提供了宝贵的指导。特别感谢克林顿·普里德尔、甚至罗尼、兰德尔·杰苏普和丹·温。还要感谢Robert Sparks和Paul Kyzivat提供的帮助，帮助他们进行最后的修复，使属性能够与提供/应答模型很好地工作。
[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：会话描述协议”，RFC4566，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]菊口，Y.，野村，T.，福永，S.，松井，Y.，和H.Kimata，“MPEG-4音频/视频流的RTP有效载荷格式”，RFC3016，2000年11月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，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.偶，“ITU-T Rec的RTP有效载荷格式”，RFC 46292007年1月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年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]吉尔曼，R.，伊恩，R.，和F.安德里亚森，“SDP媒体可映射性谈判”，正在进行的工作，2011年2月。
Authors' Addresses
作者地址
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Luleae SWEDEN
英格玛·约翰逊·爱立信AB实验室和瑞典卢利埃11 SE-971 28
Phone: +46 73 0783289
EMail: ingemar.s.johansson@ericsson.com
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三星电子有限公司Dong Suwon邮政信箱105 416，韩国京畿道延通谷水原市Maetan-3Dong 442-600
Phone: +82 10 9909 4743
EMail: kyunghun.jung@samsung.com
Phone: +82 10 9909 4743
EMail: kyunghun.jung@samsung.com