draft-ietf-mmusic-image-attributes-11.txt   rfc6236.txt 
Network Working Group I. Johansson Internet Engineering Task Force (IETF) I. Johansson
Internet-Draft Ericsson AB Request for Comments: 6236 Ericsson AB
Intended status: Standards Track K. Jung Category: Standards Track K. Jung
Expires: August 22, 2011 Samsung Electronics Co., Ltd. ISSN: 2070-1721 Samsung Electronics Co., Ltd.
Feb 18, 2011 May 2011
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in
draft-ietf-mmusic-image-attributes-11 the Session Description Protocol (SDP)
Abstract Abstract
This document proposes a new generic session set up attribute to make This document proposes a new generic session setup attribute to make
it possible to negotiate different image attributes such as image 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- 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, held terminal to display video without the need to rescale the image,
something that may consume large amounts of memory and processing something that may consume large amounts of memory and processing
power. The draft also helps to maintain an optimal bitrate for video power. The document also helps to maintain an optimal bitrate for
as only the image size that is desired by the receiver is video as only the image size that is desired by the receiver is
transmitted. transmitted.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 22, 2011. 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.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Specification of the 'imageattr' SDP Attribute . . . . . . . . 5 3. Specification of the 'imageattr' SDP Attribute . . . . . . . . 5
3.1. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 3.1. Attribute Syntax . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 3.1.1. Overall View of Syntax . . . . . . . . . . . . . . . . 5
3.2. Considerations . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Considerations . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. No imageattr in 1st offer . . . . . . . . . . . . . . 11 3.2.1. No imageattr in First Offer . . . . . . . . . . . . . 11
3.2.2. Different payload type numbers in offer and answer . . 11 3.2.2. Different Payload Type Numbers in Offer and Answer . . 11
3.2.3. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. sendonly and recvonly . . . . . . . . . . . . . . . . 12 3.2.4. sendonly and recvonly . . . . . . . . . . . . . . . . 12
3.2.5. Sample aspect ratio . . . . . . . . . . . . . . . . . 13 3.2.5. Sample Aspect Ratio . . . . . . . . . . . . . . . . . 13
3.2.6. SDPCapNeg support . . . . . . . . . . . . . . . . . . 13 3.2.6. SDPCapNeg Support . . . . . . . . . . . . . . . . . . 13
3.2.7. Interaction with codec parameters . . . . . . . . . . 14 3.2.7. Interaction with Codec Parameters . . . . . . . . . . 14
3.2.8. Change of display in middle of session . . . . . . . . 16 3.2.8. Change of Display in Middle of Session . . . . . . . . 16
3.2.9. Use with layered codecs . . . . . . . . . . . . . . . 16 3.2.9. Use with Layered Codecs . . . . . . . . . . . . . . . 16
3.2.10. Addition of parameters . . . . . . . . . . . . . . . . 16 3.2.10. Addition of Parameters . . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 16 4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 16
4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 17 4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 20 4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document proposes a new SDP attribute to make it possible to This document proposes a new SDP attribute to make it possible to
negotiate different image attributes such as image size. The term negotiate different image attributes, such as image size. The term
image size is defined here as it may differ from the physical screen 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 size of, for instance, a hand-held terminal. As an example, it may
beneficial to display a video image on a part of the physical screen be beneficial to display a video image on a part of the physical
and leave space on the screen for other features such as menus and screen and leave space on the screen for other features such as menus
other info. and other info.
There are a number of benefits with a possibility to negotiate the Allowing negotiation of the image size provides a number of benefits:
image size:
o Less image distortion: Rescaling of images introduces additional o Less image distortion: Rescaling of images introduces additional
distortion, something that can be avoided (at least on the distortion, something that can be avoided (at least on the
receiver side) if the image size can be negotiated. receiver side) if the image size can be negotiated.
o Reduced receiver complexity: Image rescaling can be quite o Reduced receiver complexity: Image rescaling can be quite
computation intensive. For low end devices this can be a problem. computation intensive. For low-end devices, this can be a
problem.
o Optimal quality for the given bitrate: The sender does not need to 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 encode an entire CIF (352x288) image if only an image size of
288x256 is displayed on the receiver screen. This alternatively 288x256 is displayed on the receiver screen.
gives a saving in bitrate.
o Memory requirement: The receiver device will know the size of the o Memory requirement: The receiver device will know the size of the
image and can then allocate memory accordingly. image and can then allocate memory accordingly.
o Optimal aspect ratio: The indication of the supported image sizes o Optimal aspect ratio: The indication of the supported image sizes
and aspect ratio allows the receiver to select the most and aspect ratio allows the receiver to select the most
appropriate combination based on its rescaling capabilities and appropriate combination based on its rescaling capabilities and
the desired rendering. For example, if a sender proposes three the desired rendering. For example, if a sender proposes three
resolutions in its SDP offer, 100x200, 200x100 and 100x100 with resolutions in its SDP offer (100x200, 200x100, and 100x100) with
sar=1.0 (1:1) etc. then the receiver can select the option that sar=1.0 (1:1) etc., then the receiver can select the option that
fits the receiver screen best. fits the receiver screen best.
In cases where rescaling is not implemented (for example, rescaling In cases where rescaling is not implemented (for example, rescaling
is not mandatory to implement in H.264 [H.264]), the indication of is not mandatory to implement in H.264 [H.264]), the indication of
the image attributes may still provide an optimal use of bandwidth the image attributes may still provide an optimal use of bandwidth
because the attribute will anyway give the encoder a better because the attribute will give the encoder a better indication about
indication about what image size is preferred and will thus help to what image size is preferred anyway and will thus help to avoid
avoid wasting bandwidth by encoding with an unnecessarily large wasting bandwidth by encoding with an unnecessarily large resolution.
resolution.
For implementers that are considering rescaling issues, it is worth For implementers that are considering rescaling issues, it is worth
to notice that there are several benefits to do it on the sender noting that there are several benefits to doing it on the sender
side: side:
o Rescaling on the sender/encoder side is likely to be easier to do o Rescaling on the sender/encoder side is likely to be easier to do
as the camera related software/hardware already contains the as the camera-related software/hardware already contains the
necessary functionality for zooming/cropping/trimming/sharpening necessary functionality for zooming/cropping/trimming/sharpening
the video signal. Moreover, rescaling is generally done in RGB or the video signal. Moreover, rescaling is generally done in RGB or
YUV domain and should not depend on the codecs used. YUV domains and should not depend on the codecs used.
o The encoder may be able to encode in a number of formats but may 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, not know which format to choose as, without the image attribute,
it does not know the receiver's performance or preference. it does not know the receiver's performance or preference.
o The quality drop due to digital domain rescaling using o The quality drop due to digital domain rescaling using
interpolation is likely to be lower if it is done before the video interpolation is likely to be lower if it is done before the video
encoding rather than after the decoding especially when low encoding rather than after the decoding especially when low
bitrate video coding is used. bitrate video coding is used.
o If low-complexity rescaling operations such as simple cropping o If low-complexity rescaling operations such as simple cropping
must be performed, the benefit with having this functionality on must be performed, the benefit with having this functionality on
the sender side is that it is then possible to present a miniature 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 target "what you send" image on the display to help the user to frame the
the camera correctly. image correctly.
Several of the existing standards ([H.263], [H.264] and [MPEG-4]) Several of the existing standards ([H.263], [H.264], and [MPEG-4])
have support for different resolutions at different framerates. The have support for different resolutions at different framerates. The
purpose of this document is to provide for a generic mechanism and is purpose of this document is to provide for a generic mechanism, which
targeted mainly at the negotiation of the image size but to make it is targeted mainly at the negotiation of the image size. However, to
more general the attribute is named 'imageattr'. make it more general, the attribute is named 'imageattr'.
This document is limited to point-to-point unicast communication This document is limited to point-to-point unicast communication
scenarios. The attribute may be used in centralized conferencing scenarios. The attribute may be used in centralized conferencing
scenarios as well but due to the abundance of configuration options scenarios as well but due to the abundance of configuration options,
it may then be difficult to come up with a configuration that fits it may then be difficult to come up with a configuration that fits
all parties. all parties.
1.1. Requirements 1.1. Requirements
The design of the image attribute is based on the following The design of the image attribute is based on the following
requirements which are listed only for informational purposes: requirements, which are listed only for informational purposes:
REQ-1: Support the indication of one or more set(s) of image REQ-1: Support the indication of one or more set(s) of image
attributes that the SDP endpoint wish to receive or send. Each attributes that the SDP endpoint wishes to receive or send. Each
image attribute set must include a specific image size. image attribute set must include a specific image size.
REQ-2: Support set up/negotiation of image attributes, meaning that REQ-2: Support setup/negotiation of image attributes, meaning that
each side in the Offer/Answer should be able to negotiate the each side in the Offer/Answer should be able to negotiate the
image attributes it prefers to send and receive. image attributes it prefers to send and receive.
REQ-3: Interoperate with codec specific parameters such as sprop- REQ-3: Interoperate with codec-specific parameters such as sprop-
parameter-sets in [H.264] or config in [MPEG-4]. parameter-sets in [H.264] or config in [MPEG-4].
REQ-4: Make the attribute generic with as few codec specific REQ-4: Make the attribute generic with as few codec specific
details/tricks as possible in order to be codec agnostic. details/tricks as possible in order to be codec agnostic.
Besides the above mentioned requirements, the requirement below may Besides the above mentioned requirements, the requirement below may
be applicable. be applicable.
OPT-1: The image attribute should support the description of image- OPT-1: The image attribute should support the description of image-
related attributes for various types of media, including video, related attributes for various types of media, including video,
pictures, images, etc. pictures, images, etc.
2. Conventions, Definitions and Acronyms 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Specification of the 'imageattr' SDP Attribute 3. Specification of the 'imageattr' SDP Attribute
This section defines the SDP image attribute 'imageattr', which can This section defines the SDP image attribute 'imageattr', which can
be used in an SDP Offer/Answer exchange to indicate various image be used in an SDP Offer/Answer exchange to indicate various image
attribute parameters. In this document, we define the following attribute parameters. In this document, we define the following
image attribute parameters: image resolution, sample aspect ratio image attribute parameters: image resolution, sample aspect ratio
(sar), allowed range in picture aspect ratio (par) and the preference (sar), allowed range in picture aspect ratio (par) and the preference
of a given parameter set over another (q). The attribute is of a given parameter set over another (q). The attribute is
extensible and guidelines for defining additional parameters are extensible and guidelines for defining additional parameters are
provided in Section 3.2.10. provided in Section 3.2.10.
3.1. Attribute syntax 3.1. Attribute Syntax
In this section the syntax of the 'imageattr' attribute is described. In this section, the syntax of the 'imageattr' attribute is
The 'imageattr' attribute is a media-level attribute. The section is described. The 'imageattr' attribute is a media-level attribute.
split up in two parts, the first gives an overall view of the syntax The section is split up in two parts: the first gives an overall view
while the second describes how the syntax is used. of the syntax, and the second describes how the syntax is used.
3.1.1. Overall view of syntax 3.1.1. Overall View of Syntax
The syntax for the image attribute is in ABNF [RFC5234]: The syntax for the image attribute is in ABNF [RFC5234]:
----
image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" ) image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
1*WSP attr-list ) 1*WSP attr-list )
PT = 1*DIGIT / "*" PT = 1*DIGIT / "*"
attr-list = ( set *(1*WSP set) ) / "*" attr-list = ( set *(1*WSP set) ) / "*"
; WSP and DIGIT defined in [RFC5234] ; WSP and DIGIT defined in [RFC5234]
----
----
set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]" set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]"
; x is the horizontal image size range (pixel count) ; x is the horizontal image size range (pixel count)
; y is the vertical image size range (pixel count) ; y is the vertical image size range (pixel count)
key-value = ( "sar=" srange ) key-value = ( "sar=" srange )
/ ( "par=" prange ) / ( "par=" prange )
/ ( "q=" qvalue ) / ( "q=" qvalue )
; Key-value MAY be extended with other keyword ; Key-value MAY be extended with other keyword
; parameters. ; parameters.
; At most one instance each of sar, par, or q ; At most, one instance each of sar, par, or q
; allowed in a set. ; is allowed in a set.
; ;
; sar (sample aspect ratio) is the sample aspect ratio ; sar (sample aspect ratio) is the sample aspect ratio
; associated with the set (optional,MAY be ignored) ; associated with the set (optional, MAY be ignored)
; par (picture aspect ratio) is the allowed ; par (picture aspect ratio) is the allowed
; ratio between the display's x and y physical ; ratio between the display's x and y physical
; size (optional) ; size (optional)
; q (optional, range [0.0..1.0], default value 0.5) ; q (optional, range [0.0..1.0], default value 0.5)
; is the preference for the given set, ; is the preference for the given set,
; a higher value means a higher preference ; a higher value means a higher preference
----
onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
; Digit between 1 and 9 ; Digit between 1 and 9
xyvalue = onetonine *5DIGIT xyvalue = onetonine *5DIGIT
; Digit between 1 and 9 which is ; Digit between 1 and 9 that is
; followed by 0 to 5 other digits ; followed by 0 to 5 other digits
step = xyvalue step = xyvalue
xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" ) xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" )
; Range between a lower and an upper value ; Range between a lower and an upper value
; with an optional step, default step = 1 ; with an optional step, default step = 1
; The rightmost occurrence of xyvalue MUST have a ; The rightmost occurrence of xyvalue MUST have a
; higher value than the leftmost occurrence. ; higher value than the leftmost occurrence.
/ ( "[" xyvalue 1*( "," xyvalue ) "]" ) / ( "[" xyvalue 1*( "," xyvalue ) "]" )
; Discrete values separated by ',' ; Discrete values separated by ','
/ ( xyvalue ) / ( xyvalue )
skipping to change at page 7, line 31 skipping to change at page 6, line 47
spvalue = ( "0" "." onetonine *3DIGIT ) spvalue = ( "0" "." onetonine *3DIGIT )
; Values between 0.1000 and 0.9999 ; Values between 0.1000 and 0.9999
/ ( onetonine "." 1*4DIGIT ) / ( onetonine "." 1*4DIGIT )
; Values between 1.0000 and 9.9999 ; Values between 1.0000 and 9.9999
srange = ( "[" spvalue 1*( "," spvalue ) "]" ) srange = ( "[" spvalue 1*( "," spvalue ) "]" )
; Discrete values separated by ','. ; Discrete values separated by ','.
; Each occurrence of spvalue MUST be ; Each occurrence of spvalue MUST be
; greater than the previous occurrence. ; greater than the previous occurrence.
/ ( "[" spvalue "-" spvalue "]" ) / ( "[" spvalue "-" spvalue "]" )
; Range between a lower and an upper level (inclusive) ; Range between a lower and an upper level (inclusive)
; The second occurrence of spvalue MUST have a higher ; The second occurrence of spvalue MUST have a higher
; value than the first ; value than the first
/ ( spvalue ) / ( spvalue )
; A single value ; A single value
prange = ( "[" spvalue "-" spvalue "]" ) prange = ( "[" spvalue "-" spvalue "]" )
; Range between a lower and an upper level (inclusive) ; Range between a lower and an upper level (inclusive)
; The second occurrence of spvalue MUST have a higher ; The second occurrence of spvalue MUST have a higher
; value than the first ; value than the first
qvalue = ( "0" "." 1*2DIGIT ) qvalue = ( "0" "." 1*2DIGIT )
/ ( "1" "." 1*2("0") ) / ( "1" "." 1*2("0") )
; Values between 0.00 and 1.00 ; Values between 0.00 and 1.00
----
o The attribute typically contains a "send" and a "recv" keyword. o The attribute typically contains a "send" and a "recv" keyword.
These specify the preferences for the media once the session is These specify the preferences for the media once the session is
set up, in the send and receive direction respectively from the set up, in the send and receive direction respectively from the
point of view of the sender of the session description. One of 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 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 and Section 3.2.2 for a description of cases when this may be
appropriate. appropriate.
o The "send" keyword and corresponding attribute list (attr-list) o The "send" keyword and corresponding attribute list (attr-list)
MUST NOT occur more than once per image attribute. MUST NOT occur more than once per image attribute.
o The "recv" keyword and corresponding attribute list (attr-list) o The "recv" keyword and corresponding attribute list (attr-list)
MUST NOT occur more than once per image attribute. MUST NOT occur more than once per image attribute.
o PT is the payload type number, it MAY be set to "*" (wild card) to 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 indicate that the attribute applies to all payload types in the
media description. media description.
o For sendrecv streams both of the send and recv directions SHOULD o For sendrecv streams, both of the send and recv directions SHOULD
be present in the SDP. be present in the SDP.
o For inactive streams it is RECOMMENDED that both of the send and o For inactive streams it is RECOMMENDED that both of the send and
recv directions are present in the SDP. recv directions are present in the SDP.
3.1.1.1. Parameter rules 3.1.1.1. Parameter Rules
For the parameters the following rules apply. The following rules apply for the parameters.
Payload type number (PT): The image attribute is bound to a specific 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 codec by means of the payload type number. A wild card (*) can be
specified for the payload type number to indicate that it applies specified for the payload type number to indicate that it applies
to all payload types in the media description. Several image to all payload types in the media description. Several image
attributes can be defined for instance for different video codec attributes can be defined, for instance for different video codec
alternatives. This however requires that the payload type numbers alternatives. This however requires that the payload type numbers
differ. Note that the attribute is associated to the codec(s), differ. Note that the attribute is associated to the codec(s),
for instance an SDP offer may specify payload type number 101 for instance an SDP offer may specify payload type number 101
while the answer may specify 102, this may make it troublesome to while the answer may specify 102, this may make it troublesome to
specify a payload type number with the 'imageattr' attribute. See specify a payload type number with the 'imageattr' attribute. See
Section 3.2.2 for a discussion and recommendation how this is Section 3.2.2 for a discussion and recommendation how this is
solved. solved.
Preference (q): The preference for each set is 0.5 by default, Preference (q): The preference for each set is 0.5 by default;
setting the optional q parameter to another value makes it setting the optional q parameter to another value makes it
possible to set different preferences for the sets. A higher possible to set different preferences for the sets. A higher
value gives a higher preference for the given set. value gives a higher preference for the given set.
sar: The sar (storage aspect ratio) parameter specifies the sample sar: The sar (storage aspect ratio) parameter specifies the sample
aspect ratio associated to the given range of x and y values. The aspect ratio associated to the given range of x and y values. The
sar parameter is defined as dx/dy where dx and dy is the physical 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 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 MAY be expressed as a range or as a single value.
If this parameter is not present a default sar value of 1.0 is
If this parameter is not present, a default sar value of 1.0 is
assumed. assumed.
The interpretation of sar differs between the send and the receive The interpretation of sar differs between the send and the receive
directions. directions.
* In the send direction it defines a specific sample aspect ratio * In the send direction, sar defines a specific sample aspect
associated to a given x and y image size (range). ratio associated to a given x and y image size (range).
* In the recv direction sar expresses that the receiver of the * In the recv direction, sar expresses that the receiver of the
given medium prefers to receive a given x and y resolution with given medium prefers to receive a given x and y resolution with
a given sample aspect ratio. a given sample aspect ratio.
See Section 3.2.5 for a more detailed discussion. See Section 3.2.5 for a more detailed discussion.
The sar parameter will likely not solve all the issues that are The sar parameter will likely not solve all the issues that are
related to different sample aspect ratios but it can help to solve related to different sample aspect ratios, but it can help to
them and reduce aspect ratio distortion. solve them and reduce aspect ratio distortion.
The response MUST NOT include a sar parameter if there is no The response MUST NOT include a sar parameter if there is no
acceptable value given. The reason to this is that if the acceptable value given. The reason for this is that if the
response includes a sar parameter it is interpreted as "sar response includes a sar parameter it is interpreted as "sar
parameter accepted" while removal of the sar parameter is treated parameter accepted", while removal of the sar parameter is treated
as "sar parameter not accepted", for this reason it is safer to as "sar parameter not accepted". For this reason, it is safer to
remove an unacceptable sar parameter altogether. remove an unacceptable sar parameter altogether.
par: The par (width/height = x/y ratio) parameter indicates a range par: The par (width/height = x/y ratio) parameter indicates a range
of allowed ratios between x and y physical size (picture aspect 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 ratio). This is used to limit the number of x and y image size
combinations, par is given as combinations; par is given as
----
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.
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.
3.1.1.2. Offer/answer rules where ratio_min and ratio_max are the min and max allowed picture
aspect ratios.
In accordance with [RFC3264], offer answer exchange of the image 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.
3.1.1.2. Offer/Answer Rules
In accordance with [RFC3264], offer/answer exchange of the image
attribute is as follows. attribute is as follows.
o Offerer sending the offer: o Offerer sending the offer:
* The offerer must be able to support the image attributes that * The offerer must be able to support the image attributes that
it offers, unless the offerer has expressed a wild card (*) in it offers, unless the offerer has expressed a wild card (*) in
the attribute list. the attribute list.
* It is recommended that a device which sees no reason to use the * It is recommended that a device that sees no reason to use the
image attribute, anyway includes the attribute with wild cards image attribute includes the attribute with wild cards (*) in
(*) in the attribute lists for the send and recv directions. the attribute lists anyway for the send and recv directions.
An example of this looks like: An example of this looks like:
----
a=imageattr:97 send * recv * a=imageattr:97 send * recv *
----
This gives the answerer the possibility to express its This gives the answerer the possibility of expressing its
preferences. The use of wild cards introduces a risk that the preferences. The use of wild cards introduces a risk that the
message size can increase in an uncontrolled way. To reduce message size can increase in an uncontrolled way. To reduce this
this risk these wild cards SHOULD only be replaced by an as risk, these wild cards SHOULD only be replaced by an as small set as
small set as possible. possible.
o Answerer receiving the offer and sending the answer: o Answerer receiving the offer and sending the answer:
* The answerer may choose to keep the image attribute but is not * The answerer may choose to keep the image attribute but is not
required to do so. required to do so.
* The answerer may, for its receive and send direction, include * The answerer may, for its receive and send direction, include
one or more entries that it can support from the set of entries one or more entries that it can support from the set of entries
proposed in the offer. proposed in the offer.
skipping to change at page 10, line 46 skipping to change at page 10, line 23
o Offerer receiving the answer: o Offerer receiving the answer:
* If the image attribute is not included in the SDP answer the * If the image attribute is not included in the SDP answer the
offerer SHOULD continue to process the answer as if this offerer SHOULD continue to process the answer as if this
mechanism had not been offered. mechanism had not been offered.
* If the image attribute is included in the SDP answer but none * If the image attribute is included in the SDP answer but none
of the entries are usable or acceptable, the offerer MUST of the entries are usable or acceptable, the offerer MUST
resort to other methods to determine the appropriate image resort to other methods to determine the appropriate image
size. In this case the offerer must also issue a new offer/ size. In this case, the offerer must also issue a new offer/
answer without the image attribute to avoid misunderstandings answer without the image attribute to avoid misunderstandings
between offerer and answerer. This will avoid the risk on between the offerer and answerer. This will avoid the risk of
infinite negotiations. infinite negotiations.
3.2. Considerations 3.2. Considerations
3.2.1. No imageattr in 1st offer 3.2.1. No imageattr in First Offer
When the initial offer does not contain the 'imageattr' attribute, 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 rules in Section 3.1.1.2 require the attribute to be absent in
the answer. The reasons for this are: the answer. The reasons for this are:
o The offerer of the initial SDP is not likely to understand the 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 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 mind that Section 3.1.1 recommends that the offerer provide the
attribute with wild carded parameters if it has no preference. attribute with wild carded parameters if it has no preference.
o Inclusion of the image attribute in the answer may come in o Inclusion of the image attribute in the answer may come in
conflict with the rules in Section 3.1.1.2 esp. the rules that conflict with the rules in Section 3.1.1.2, especially the rules
apply to "offerer receiving the answer". that apply to "offerer receiving the answer".
For the above reasons it is RECOMMENDED that a device which sees no For the above reasons, it is RECOMMENDED that a device that sees no
reason to use the image attribute, anyway includes the attribute with reason to use the image attribute includes the attribute with wild
wild cards (*) in the attribute lists for the send and recv cards (*) in the attribute lists anyway for the send and recv
directions. directions.
3.2.2. Different payload type numbers in offer and answer 3.2.2. Different Payload Type Numbers in Offer and Answer
In some cases the answer may specify a different media payload type 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 number than the offer. As an example, the offer SDP may have the
m-line m-line
----
m=video 49154 RTP/AVP 99 m=video 49154 RTP/AVP 99
----
While the answer SDP may have the m-line while the answer SDP may have the m-line
----
m=video 49154 RTP/AVP 100 m=video 49154 RTP/AVP 100
----
If the image attribute in the offer specifies payload type number 99, If the image attribute in the offer specifies payload type number 99,
this attribute will then have no meaning in the answerers receive this attribute will then have no meaning in the answerers receive
direction as the m-line specifies media payload type number 100. direction as the m-line specifies media payload type number 100.
There are a few ways to solve this There are a few ways to solve this.
1. Use a wild card "*" as payload type number in the image attribute 1. Use a wild card "*" as the payload type number in the image
in the offer SDP. The answer SDP also use the wild card. The attribute in the offer SDP. The answer SDP also uses the wild
drawback with this approach is that this attribute then applies card. The drawback with this approach is that this attribute
to all payload type numbers in the media description. then applies to all payload type numbers in the media
description.
2. Specify a wild card "*" as payload type number in the image 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 attribute in the answer SDP. The offer SDP may contain a defined
payload type number in the image attribute but the answer SDP payload type number in the image attribute but the answer SDP
replaces this with a wild card. The drawback here is similar to replaces this with a wild card. The drawback here is similar to
what is listed above. what is listed above.
3. The image attribute is split in two parts in the SDP answer. For 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 example the offer SDP (only the parts of interest in this
discussion) looks like: discussion) looks like:
----
m=video 49154 RTP/AVP 99 m=video 49154 RTP/AVP 99
a=imageattr:99 send ... recv ... a=imageattr:99 send ... recv ...
----
The answer SDP looks like: The answer SDP looks like:
----
m=video 49154 RTP/AVP 100 m=video 49154 RTP/AVP 100
a=imageattr:99 send ... a=imageattr:99 send ...
a=imageattr:100 recv ... a=imageattr:100 recv ...
----
This alternative does not pose any drawbacks. Moreover it allows This alternative does not pose any drawbacks. Moreover, it allows
to specify different image attributes if more than one payload specification of different image attributes if more than one payload
type is specified in the offer SDP. type is specified in the offer SDP.
Of the alternatives listed above, the last one MUST be used as it is Of the alternatives listed above, the last one MUST be used as it is
the most safe. The other alternatives MUST NOT be used. the most safe. The other alternatives MUST NOT be used.
3.2.3. Asymmetry 3.2.3. Asymmetry
While the image attribute supports asymmetry there are some While the image attribute supports asymmetry, there are some
limitations to this. One important limitation is that the codec limitations. One important limitation is that the codec being used
being used can only support up to a given maximum resolution for a can only support up to a given maximum resolution for a given profile
given profile level. level.
As an example H.264 [H.264] with profile level 1.2 does not support 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 higher resolution than 352x288 (CIF). The offer/answer rules imply
that the same profile level must be used in both directions. This that the same profile level must be used in both directions. This
means that in an asymmetric scenario where Alice wants an image size 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 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 directions even though profile level 1 would have been sufficient in
one direction. one direction.
Currently, the only solution to this problem is to specify two Currently, the only solution to this problem is to specify two
unidirectional media descriptions. Note however that the asymmetry unidirectional media descriptions. Note however that the asymmetry
issue for the H.264 codec is solved by means of the level-asymmetry- issue for the H.264 codec is solved by means of the level-asymmetry-
allowed parameter in [RFC3984bis]. allowed parameter in [RFC6184].
3.2.4. sendonly and recvonly 3.2.4. sendonly and recvonly
If the directional attributes a=sendonly or a=recvonly are given for 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 a medium, there is of course no need to specify the image attribute
for both directions. Therefore one of the directions in the for both directions. Therefore, one of the directions in the
attribute may be omitted. However it may be good to do the image attribute may be omitted. However, it may be good to do the image
attribute negotiation in both directions in case the session is attribute negotiation in both directions in case the session is
updated for media in both directions at a later stage. updated for media in both directions at a later stage.
3.2.5. Sample aspect ratio 3.2.5. Sample Aspect Ratio
The relationship between the sar parameter and the x and y pixel The relationship between the sar parameter and the x and y pixel
resolution deserves some extra discussion. Consider the offer from resolution deserves some extra discussion. Consider the offer from
Alice to Bob (we set the recv direction aside for the moment): Alice to Bob (we set the recv direction aside for the moment):
----
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 If the receiver display has square pixels, the 720x576 image would
need to be rescaled to for example 792x576 or 720x524 to ensure a need to be rescaled to for example 792x576 or 720x524 to ensure a
correct image aspect ratio. This in practice means that rescaling correct image aspect ratio. This in practice means that rescaling
would need to be performed on the receiver side, something that is would need to be performed on the receiver side, something that is
contrary to the spirit of this draft. contrary to the spirit of this document.
To avoid this problem Alice may specify a range of values for the sar To avoid this problem Alice may specify a range of values for the sar
parameter like: parameter like:
----
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 Meaning that Alice can encode with any of the mentioned sample aspect
ratios, leaving to Bob to decide which one he prefers. ratios, leaving Bob to decide which one he prefers.
3.2.6. SDPCapNeg support 3.2.6. SDPCapNeg Support
The image attribute can be used within the SDP Capability Negotiation The image attribute can be used within the SDP Capability Negotiation
[RFC5939] framework and its use is then specified using the "a=acap" [RFC5939] framework and its use is then specified using the "a=acap"
parameter. An example is parameter. An example is
----
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 For use with SDP Media Capability Negotiation extension
[SDPMedCapNeg], where it is no longer possible to specify payload [SDPMedCapNeg], where it is no longer possible to specify payload
type numbers, it is possible to use the parameter substitution rule, type numbers, it is possible to use the parameter substitution rule,
an example of this is. an example of this is
----
... ...
a=mcap:1 video H264/90000 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=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. where %1% maps to media capability number 1.
It is also possible to use the a=mscap attribute like in the example It is also possible to use the a=mscap attribute like in the example
below. below.
----
... ...
a=mcap:1 video H264/90000 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=mscap:1 imageattr send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
... ...
----
3.2.7. Interaction with codec parameters 3.2.7. Interaction with Codec Parameters
As the SDP for most codecs already specifies some kind of indication As the SDP for most codecs already specifies some kind of indication
of, for example, the image size, at session set up, measures must be of, for example, the image size, at session setup, measures must be
taken to avoid conflicts between the image attribute and this already taken to avoid conflicts between the image attribute and this already
existing information. existing information.
The following subsections describe the most well known codecs and how The following subsections describe the most well known codecs and how
they define image-size related information. Section 3.2.7.4 outlines they define image-size related information. Section 3.2.7.4 outlines
a few possible solutions, but this document does not make any a few possible solutions, but this document does not make a
recommendation for any of them. recommendation for any of them.
3.2.7.1. H.263 3.2.7.1. H.263
The payload format for H.263 [H.263] is described in [RFC4629]. The payload format for H.263 [H.263] is described in [RFC4629].
H.263 defines (on the fmtp line) a list of image sizes and their H.263 defines (on the fmtp line) a list of image sizes and their
maximum frame rates (profiles) that the offerer can receive. The maximum frame rates (profiles) that the offerer can receive. The
answerer is not allowed to modify this list and must reject a payload answerer is not allowed to modify this list and must reject a payload
type that contains an unsupported profile. The CUSTOM profile may be type that contains an unsupported profile. The CUSTOM profile may be
used for image size negotiation but support for asymmetry requires used for image size negotiation but support for asymmetry requires
the specification of two unidirectional media descriptions using the the specification of two unidirectional media descriptions using the
sendonly/recvonly attributes. sendonly/recvonly attributes.
3.2.7.2. H.264 3.2.7.2. H.264
The payload format for H.264 [H.264] is described in [RFC3984bis]. The payload format for H.264 [H.264] is described in [RFC6184].
H.264 defines image size related information in the fmtp line by H.264 defines information related to image size in the fmtp line by
means of sprop-parameter-sets. According to the specification means of sprop-parameter-sets. According to the specification,
several sprop-parameter-sets may be defined for one payload type. several sprop-parameter-sets may be defined for one payload type.
The sprop-parameter-sets describe the image size (+ more) that the The sprop-parameter-sets describe the image size (+ more) that the
offerer sends in the stream and need not be complete. This means offerer sends in the stream and need not be complete. This means
that this does not represent any negotiation. Moreover an answer is that sprop-parameter-sets does not represent any negotiation and the
not allowed to change the sprop-parameter-sets. answer is not allowed to change the sprop-parameter-sets.
This configuration may be changed later inband if for instance image This configuration may be changed later inband if for instance image
sizes need to be changed or added. sizes need to be changed or added.
3.2.7.3. MPEG-4 3.2.7.3. MPEG-4
The payload format for MPEG-4 [MPEG-4] is described in [RFC3016]. The payload format for MPEG-4 [MPEG-4] is described in [RFC3016].
MPEG-4 defines a config parameter on the fmtp line which is a MPEG-4 defines a config parameter on the fmtp line, which is a
hexadecimal representation of the MPEG-4 visual configuration hexadecimal representation of the MPEG-4 visual configuration
information. This configuration does not represent any negotiation information. This configuration does not represent any negotiation
and the answer is not allowed to change the parameter. and the answer is not allowed to change the parameter.
It is not possible to change the configuration using inband It is not possible to change the configuration using inband
signaling. signaling.
3.2.7.4. Possible solutions 3.2.7.4. Possible Solutions
The subsections above clearly indicate that this kind of information The subsections above clearly indicate that this kind of information
must be aligned well with the image attribute to avoid conflicts. must be aligned well with the image attribute to avoid conflicts.
There are a number of possible solutions, listed below without any There are a number of possible solutions, listed below without any
preference: preference:
o Ignore payload format parameters: This may not work well in the o Ignore payload format parameters: This may not work well in the
presence of bad channel conditions especially in the beginning of presence of bad channel conditions especially in the beginning of
a session. Moreover this is not a good option for MPEG-4. a session. Moreover, this is not a good option for MPEG-4.
o 2nd session-wide offer/answer round: In the 2nd offer/answer the o Second session-wide offer/answer round: In the second offer/
codec payload format specific parameters are defined based on the answer, the parameters specific to codec payload format are
outcome of the 'imageattr' negotiation. The drawback with this is defined based on the outcome of the 'imageattr' negotiation. The
that set up of the entire session (including audio) may be delayed drawback with this is that setup of the entire session (including
considerably, especially as the 'imageattr' negotiation can audio) may be delayed considerably, especially as the 'imageattr'
already itself cost up to two offer/answer rounds. Also the negotiation can already itself cost up to two offer/answer rounds.
conflict between the 'imageattr' negotiation and the payload Also, the conflict between the 'imageattr' negotiation and the
format specific parameters is still present after the first offer/ parameters specific to payload format is still present after the
answer round and a fuzzy/buggy implementation may start media first offer/answer round and a fuzzy/buggy implementation may
before the second offer/answer is completed with unwanted results. start media before the second offer/answer is completed with
unwanted results.
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 2nd session-wide offer/answer round only for video: This is
similar to the alternative above with the exception that set up
time for audio is not increased, moreover the port number for
video is set to 0 during the 1st offer answer round to avoid that
media flows.
This has the effect that video will blend in some time after the This has the effect that video will blend in some time after the
audio is started (up to 2 seconds delay). This alternative is audio is started (up to 2 seconds delay). This alternative is
likely the most clean-cut and failsafe alternative. The drawback likely the most clean-cut and failsafe. The drawback is, as the
is, as the port number in the first offer is always zero, the port number in the first offer is always zero, the media startup
media startup will always be delayed even though it would in fact will always be delayed even though it would in fact have been
have been possible to start media already after the first offer/ possible to start media after the first offer/answer round.
answer round.
Note that according to [RFC3264], a port number of zero means that 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 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 same port number should be treated as a completely new stream and
not as an update. The most safe way to solve this problem is to not as an update. The safest way to solve this problem is to use
use preconditions, this is however outside the scope of this preconditions; this is however outside the scope of this document.
document.
3.2.8. Change of display in middle of session 3.2.8. Change of Display in Middle of Session
A very likely scenario is that a user switches to another phone A very likely scenario is that a user switches to another phone
during a video telephony call or plugs a cellphone into an external during a video telephony call or plugs a cellphone into an external
monitor. In both cases it is very likely that a renegotiation is monitor. In both cases, it is very likely that a renegotiation is
initiated using the SIP-REFER or SIP-UPDATE methods. It is initiated using the SIP-REFER [RFC3515] or SIP-UPDATE [RFC3311]
RECOMMENDED to negotiate the image size during this renegotiation. methods. It is RECOMMENDED to negotiate the image size during this
renegotiation.
3.2.9. Use with layered codecs 3.2.9. Use with Layered Codecs
As the image attribute is a media level attribute, its use with As the image attribute is a media-level attribute, its use with
layered codecs causes some concern. If the layers are transported in layered codecs causes some concern. If the layers are transported in
different RTP streams the layers are specified on different media different RTP streams, the layers are specified on different media
descriptions and the relation is specified using the grouping descriptions, and the relation is specified using the grouping
framework [RFC5888] and the depend attribute [RFC5583]. As it is not framework [RFC5888] and the depend attribute [RFC5583]. As it is not
possible to specify only one image attribute for several media possible to specify only one image attribute for several media
descriptions the solution is either to specify the same image descriptions the solution is either to specify the same image
attribute for each media description, or to only specify the image attribute for each media description, or to only specify the image
attribute for the base layer. attribute for the base layer.
3.2.10. Addition of parameters 3.2.10. Addition of Parameters
The image attribute allows for the addition of parameters in the The image attribute allows for the addition of parameters in the
future. To make backwards adaptation possible; an entity that future. To make backwards adaptation possible, an entity that
processes the attribute MUST ignore any unknown parameters in the processes the attribute MUST ignore any unknown parameters in the
offer and MUST NOT include them in the answer it generates. Addition offer and MUST NOT include them in the answer it generates. Addition
of future parameters that are not understood by the receiving of future parameters that are not understood by the receiving
endpoint may lead to ambiguities if mutual dependencies between endpoint may lead to ambiguities if mutual dependencies between
parameters exist, therefore addition of parameters must be done with parameters exist; therefore, addition of parameters must be done with
great care. great care.
4. Examples 4. Examples
This section gives some more information on how to use the attribute This section gives some more information on how to use the attribute
by means of a high-level example and a few detailed examples. by means of a high-level example and a few detailed examples.
4.1. A High-Level Example 4.1. A High-Level Example
Assume that Alice wishes to set up a session with Bob and that Alice Assume that Alice wishes to set up a session with Bob and that Alice
takes the first initiative. The syntactical white-space delimiters takes the first initiative. The syntactical white-space delimiters
(1*WSP) and double-quotes are removed to make reading easier. (1*WSP) and double-quotes are removed to make reading easier.
In the offer Alice provides information for both the send and receive In the offer, Alice provides information for both the send and
(recv) directions. For the send direction Alice provides a list that receive (recv) directions. For the send direction, Alice provides a
the answerer can select from. For the receive direction Alice may list that the answerer can select from. For the receive direction,
either specify a desired image size range right away or a * to Alice may either specify a desired image size range right away or a *
instruct Bob to reply with a list of image sizes that Bob can support to instruct Bob to reply with a list of image sizes that Bob can
for sending. Using the overall high level syntax the image attribute support for sending. Using the overall high level syntax the image
may then look like attribute may then look like
----
a=imageattr:PT send attr-list recv attr-list a=imageattr:PT send attr-list recv attr-list
----
or 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 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 desired image size formats. It may however (and most likely) just be
a list with one alternative for the preferred x and y resolution. a list with one alternative for the preferred x and y resolution.
If Bob supports an x and y resolution in at least one of the X and 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 ranges given in the send attr-list and in the recv attr-list of the
offer, the answer from Bob will look like: offer, the answer from Bob will look like:
----
a=imageattr:PT send attr-list recv attr-list a=imageattr:PT send attr-list recv attr-list
----
And the offer answer negotiation is done. Worth noticing here is and the offer/answer negotiation is done. Note that the attr-list
that the attr-list will likely be pruned in the answer. While it may will likely be pruned in the answer. While it may contain many
contain many different alternatives in the offer it may in the end different alternatives in the offer, it may in the end contain just
contain just one or two alternatives. one or two alternatives.
If Bob does not support any x and y resolution in one of the provided 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- 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 list, the corresponding part is removed completely. For instance, if
Bob doesn't support any of the offered alternatives in the recv attr- Bob doesn't support any of the offered alternatives in the recv attr-
list in the offer, the answer from Bob would look like: list in the offer, the answer from Bob would look like:
----
a=imageattr:PT recv attr-list a=imageattr:PT recv attr-list
----
4.2. Detailed Examples 4.2. Detailed Examples
This section gives a few detailed examples, it is assumed where This section gives a few detailed examples. It is assumed where
needed that Alice initiates a session with Bob needed that Alice initiates a session with Bob.
4.2.1. Example 1 4.2.1. Example 1
Two image resolution alternatives are offered with 800x640 with Two image resolution alternatives are offered with 800x640 with
sar=1.1 having the highest preference sar=1.1 having the highest preference.
It is also indicated that Alice wish to display video with a
resolution of 330x250 on her display It is also indicated that Alice wishes to display video with a
---- resolution of 330x250 on her display.
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
recv [x=330,y=250] recv [x=330,y=250]
----
In case Bob accepts the "recv [x=330,y=250]" the answer may look like In case Bob accepts the "recv [x=330,y=250]", the answer may look
---- like
a=imageattr:97 recv [x=800,y=640,sar=1.1] \ a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=330,y=250] send [x=330,y=250]
----
Indicating that the receiver (Bob) wish the encoder (on Alice's side) indicating that the receiver (Bob) wishes the encoder (on Alice's
to compensate for a sample aspect ratio of 1.1 (11:10) and desires an side) to compensate for a sample aspect ratio of 1.1 (11:10) and
image size on its screen of 800x640. desires an image size on its screen of 800x640.
There is however a possibility that "recv [x=330,y=250]" is not There is however a possibility that "recv [x=330,y=250]" is not
supported. If the case, Bob may completely remove this part or supported. If the case, Bob may completely remove this part or
replace it with a list of supported image sizes. replace it with a list of supported image sizes.
----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \ 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]] send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]]
----
Alice can then select a valid image size which is closest to the one Alice can then select a valid image size that is closest to the one
that was originally desired (336x256) and performs a second offer/ that was originally desired (336x256) and performs a second offer/
answer answer.
----
a=imageattr:97 send [x=800,y=640,sar=1.1] \ a=imageattr:97 send [x=800,y=640,sar=1.1] \
recv [x=336,y=256] recv [x=336,y=256]
----
Bob replies with: Bob replies with:
----
a=imageattr:97 recv [x=800,y=640,sar=1.1] \ a=imageattr:97 recv [x=800,y=640,sar=1.1] \
send [x=336,y=256] send [x=336,y=256]
----
4.2.2. Example 2 4.2.2. Example 2
Two image resolution sets are offered with the first having a higher Two image resolution sets are offered with the first having a higher
preference (q=0.6). preference (q=0.6).
----
a=imageattr:97 \ a=imageattr:97 \
send [x=[480:16:800],y=[320:16:640],par=[1.2-1.3],q=0.6] \ 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]] \ [x=[176:8:208],y=[144:8:176],par=[1.2-1.3]] \
recv * recv *
----
The x-axis resolution can take the values 480 to 800 in 16 pixels 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 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 set of possible x and y screen resolution combinations such that
800x640 (ratio=1.25) is a valid combination while 720x608 800x640 (ratio=1.25) is a valid combination while 720x608
(ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations. (ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations.
For the recv direction (Bob->Alice) Bob is requested to provide with For the recv direction (Bob->Alice), Bob is requested to provide a
a list of supported image sizes list of supported image sizes.
4.2.3. Example 3 4.2.3. Example 3
In this example more of the SDP offer is shown. A complicating In this example, more of the SDP offer is shown. A complicating
factor is that the answerer changes the media payload type number in factor is that the answerer changes the media payload type number in
the offer/answer exchange. the offer/answer exchange.
----
m=video 49154 RTP/AVP 99 m=video 49154 RTP/AVP 99
a=rtpmap:99 H264/90000 a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \ a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \
sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 \ a=imageattr:99 \
send [x=176,y=144] [x=224,y=176] [x=272,y=224] [x=320,y=240] \ 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] 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 In the send direction, sprop-parameter-sets is defined for a
resolution of 320x240 which is the largest image size offered in the resolution of 320x240, which is the largest image size offered in the
send direction. This means that if 320x240 is selected, no send direction. This means that if 320x240 is selected, no
additional offer/answer is necessary. In the receive direction four additional offer/answer is necessary. In the receive direction, four
alternative image sizes are offered with 272x224 being the preferred alternative image sizes are offered with 272x224 being the preferred
choice. choice.
The answer may look like: The answer may look like:
----
m=video 49154 RTP/AVP 100 m=video 49154 RTP/AVP 100
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0;profile-level-id=42e011; \ a=fmtp:100 packetization-mode=0;profile-level-id=42e011; \
sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 send [x=320,y=240] a=imageattr:99 send [x=320,y=240]
a=imageattr:100 recv [x=320,y=240] a=imageattr:100 recv [x=320,y=240]
----
Indicating (in this example) that the image size is 320x240 in both indicating (in this example) that the image size is 320x240 in both
directions. Although the offerer preferred 272x224 for the receive directions. Although the offerer preferred 272x224 for the receive
direction, the answerer might not be able to offer 272x224 or not direction, the answerer might not be able to offer 272x224 or not
allow encoding and decoding of video of different image sizes allow encoding and decoding of video of different image sizes
simultaneously. The answerer sets new sprop-parameter-sets, simultaneously. The answerer sets new sprop-parameter-sets,
constructed for both send and receive directions at the restricted constructed for both send and receive directions at the restricted
conditions and image size of 320x240. conditions and image size of 320x240.
Note also that, because the payload type number is changed by the Note also that, because the payload type number is changed by the
answerer, the image attribute is also split in two parts according to answerer, the image attribute is also split in two parts according to
the recommendation in Section 3.2.2. the recommendation in Section 3.2.2.
4.2.4. Example 4 4.2.4. Example 4
This example illustrates in more detail how compensation for This example illustrates in more detail how compensation for
different sample aspect ratios can be negotiated with the image different sample aspect ratios can be negotiated with the image
attribute. attribute.
We set up a session between Alice and Bob, Alice is the offerer of We set up a session between Alice and Bob; Alice is the offerer of
the session. The offer (from Alice) contains the image attribute the session. The offer (from Alice) contains the image attribute
below: below:
----
a=imageattr:97 \ a=imageattr:97 \
send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] \ 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] recv [x=800,y=600,sar=1.1]
----
First we consider the recv direction: The offerer (Alice) explicitly First we consider the recv direction: The offerer (Alice) explicitly
states that she wishes to receive the screen resolution 800x600, states that she wishes to receive the screen resolution 800x600.
however she also indicates that the screen on her display does not 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) use square pixels; the sar value=1.1 means that Bob must (preferably)
compensate for this. compensate for this.
So.. If Bob's video camera produces square pixels, and wishes to
satisfy Alice's sar requirement, the image processing algorithm must So, if Bob's video camera produces square pixels, and if Bob wishes
rescale a 880x600 pixel image (880=800*1.1) to 800x600 pixels (could to satisfy Alice's sar requirement, the image processing algorithm
be done other ways). must rescale a 880x600 pixel image (880=800*1.1) to 800x600 pixels
(could be done other ways).
... and now the send direction: Alice indicates that she can (in the ... and now the send direction: Alice indicates that she can (in the
image processing algorithms) rescale the image for sample aspect image processing algorithms) rescale the image for sample aspect
ratios in the range 1.0 to 1.3. She can also provide with a number ratios in the range 1.0 to 1.3. She can also provide a number of
of different image sizes (in pixels) ranging from 400x320 to 800x640. different image sizes (in pixels) ranging from 400x320 to 800x640.
Bob inspects the offered sar and image sizes and responds with the Bob inspects the offered sar and image sizes and responds with the
modified image attribute modified image attribute.
----
a=imageattr:97 \ a=imageattr:97 \
recv [x=464,y=384,sar=1.15] \ recv [x=464,y=384,sar=1.15] \
send [x=800,y=600,sar=1.1] send [x=800,y=600,sar=1.1]
----
Alice will (in order to satisfy Bob's request) need to rescale the 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. image from her video camera from 534x384 (534=464*1.15) to 464x384.
5. IANA Considerations 5. IANA Considerations
Following the guidelines in [RFC4566], the IANA is requested to Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute: register one new SDP attribute:
Attribute name: imageattr Attribute name: imageattr
skipping to change at page 21, line 16 skipping to change at page 21, line 4
image from her video camera from 534x384 (534=464*1.15) to 464x384. image from her video camera from 534x384 (534=464*1.15) to 464x384.
5. IANA Considerations 5. IANA Considerations
Following the guidelines in [RFC4566], the IANA is requested to Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute: register one new SDP attribute:
Attribute name: imageattr Attribute name: imageattr
Long form name: Image attribute Long form name: Image attribute
Type of attribute: Media-level Type of attribute: Media-level
Subject to charset: No Subject to charset: No
Purpose: This attribute defines the ability to negotiate Purpose: This attribute defines the ability to negotiate
various image attributes such as image sizes. various image attributes such as image sizes.
The attribute contains a number of parameters The attribute contains a number of parameters
which can be modified in and offer/answer which can be modified in an offer/answer
exchange. exchange.
Appropriate values: See Section 3.1.1 of RFCXXXX Appropriate values: See Section 3.1.1 of RFC 6236
Contact name: Authors of RFCXXXX
Note to RFC Editor: please replace "RFCXXXX" above with the RFC Contact name: Authors of RFC 6236
number of this document, and remove this note.
6. Security Considerations 6. Security Considerations
The image attribute and especially the parameters that denote the The image attribute and especially the parameters that denote the
image size can take on values that may cause memory or CPU exhaustion 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 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 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 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 as a=fmtp line(s) may take on extreme values for the same reasons
outlined above. outlined above.
A receiver of the SDP containing the image attribute MUST ensure that A receiver of the SDP containing the image attribute MUST ensure that
the parameters have values that are reasonable and that the device the parameters have values that are reasonable and that the device
can handle the implications in terms of memory and CPU usage. can handle the implications in terms of memory and CPU usage.
Failure to do a sanity check on the parameters may result in memory Failure to do a sanity check on the parameters may result in memory
or CPU exhaustion. or CPU exhaustion.
In principle, for some SDPs containing the image attribute and for In principle, for some SDPs containing the image attribute and for
some deployments, it could be the case that simply checking the some deployments, it could be the case that simply checking the
parameters is not sufficient to detect all potential DoS problems. parameters is not sufficient to detect all potential Denial-of-
Implementers ought to consider whether there are any potential DoS Service (DoS) problems. Implementers ought to consider whether there
attacks that would not be detected by simply checking parameters. are any potential DoS attacks that would not be detected by simply
checking parameters.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the people who has contributed with The authors would like to thank the people who have contributed with
objections and suggestions to this draft and provided with valuable objections and suggestions to this document and provided valuable
guidance in the amazing video-coding world. Special thanks go to guidance in the amazing video-coding world. Special thanks to
Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Thanks also 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 to Robert Sparks and Paul Kyzivat for the help with the last fixes to
get the attribute work well with the offer/answer model. get the attribute to work well with the offer/answer model.
8. Changes
Note to RFC Editor: please replace remove this section in its
entirety before publication.
The main changes are:
From WG -10 to WG -11
* Changes after IESG review
From WG -09 to WG -10
* Further clarified the issue that offer and answer may use
different PT numbers, additional section added.
* Additional typos fixed.
From WG -08 to WG -09
* Clarified the issue that offer and answer may use different PT
numbers
* Clarified that wild cards in send and recv direction should be
used with care and with total message size in mind
* Typos and unclear language fixe
From WG -07 to WG -08
* SHOULD changed to MUST in section "Offer/answer rules"
From WG -05 to WG -06 & -07
* Update based on AD review comments, no changes to fix issue
related to RFC2119 keywords
* Minor editorial changes
* Added extra example to use of attribute with SDPCapNeg
From WG -04 to WG -05
* Review based on WGLC comments
* ABNF improved
* Change use of RFC2119 keywords (MUST, SHOULD, MAY) to lowercase
in some sections
* Clarification on the directions send and recv in sendrecv,
inactive modes
* Clarification around sar parameter added
From WG -03 to WG -04
* Rearrangement of text
* Clarification of offer/answer rules
* Cleaned IANA section
From WG -02 to WG -03
* Partial update based on review comments from Jean-Francois Mule
From WG -01 to WG -02
* Added extra example that highlights the negotiation of sar
From WG -00 to WG -01
* Added info about future addition of parameters and backwards
compatibility
* Added IANA considerations
From individual -02 to WG -00
* Cleanup of syntax, ABNF form
* Additional example
From -01 to -02
* Cleanup of the sar and par parameters to make them match the
established conventions
* Requirement specification added
* New bidirectional syntax 8. References
* Interoperability considerations with well known video codecs 8.1. Normative References
discussed
9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.1. Normative References [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Requirement Levels", BCP 14, RFC 2119, March 1997. Session Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
with Session Description Protocol (SDP)", RFC 3264, Specifications: ABNF", STD 68, RFC 5234,
June 2002. January 2008.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Description Protocol", RFC 4566, July 2006. Dependency in the Session Description Protocol
(SDP)", RFC 5583, July 2009.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session
Specifications: ABNF", STD 68, RFC 5234, January 2008. Description Protocol (SDP) Grouping Framework",
RFC 5888, June 2010.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 8.2. Informative References
Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [H.263] ITU-T, ITU-T Recommendation H.263 (2005): "Video
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. coding for low bit rate communication".
9.2. Informative References [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.263] ITU-T, "ITU-T Recommendation H.263 (2005): "Video coding [MPEG-4] ISO/IEC, ISO/IEC 14496-2:2004: "Information
for low bit rate communication"". technology - Coding of audio-visual objects - Part 2:
Visual".
[H.264] ITU-T, "ITU-T Recommendation H.264, [RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y.,
http://www.itu.int/rec/T-REC-H.264-200711-I/en". and H. Kimata, "RTP Payload Format for MPEG-4 Audio/
Visual Streams", RFC 3016, November 2000.
[MPEG-4] ISO/IEC, "ISO/IEC 14496-2:2004: "Information technology - [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
Coding of audio-visual objects - Part 2: Visual"". UPDATE Method", RFC 3311, October 2002.
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP)
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Refer Method", RFC 3515, April 2003.
Streams", RFC 3016, November 2000.
[RFC3984bis] [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and
IETF, "RTP Payload Format for H.264 Video, http:// R. Even, "RTP Payload Format for ITU-T Rec",
tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/". RFC 4629, January 2007.
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Even, "RTP Payload Format for ITU-T Rec", RFC 4629, Capability Negotiation", RFC 5939, September 2010.
January 2007.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup,
Capability Negotiation", RFC 5939, September 2010. "RTP Payload Format for H.264 Video", RFC 6184,
May 2011.
[SDPMedCapNeg] [SDPMedCapNeg] Gilman, R., Even, R., and F. Andreasen, "SDP Media
IETF, "SDP media capabilities Negotiation, http:// Mapabilities Negotiation", Work in Progress,
tools.ietf.org/wg/mmusic/ February 2011.
draft-ietf-mmusic-sdp-media-capabilities".
Authors' Addresses Authors' Addresses
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
Laboratoriegrand 11 Laboratoriegrand 11
SE-971 28 Luleae SE-971 28 Luleae
SWEDEN SWEDEN
Phone: +46 73 0783289 Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com EMail: ingemar.s.johansson@ericsson.com
Kyunghun Jung Kyunghun Jung
Samsung Electronics Co., Ltd. Samsung Electronics Co., Ltd.
Dong Suwon P.O. Box 105 Dong Suwon P.O. Box 105
416, Maetan-3Dong, Yeongtong-gu 416, Maetan-3Dong, Yeongtong-gu
Suwon-city, Gyeonggi-do Suwon-city, Gyeonggi-do
Korea 442-600 Korea 442-600
Phone: +82 10 9909 4743 Phone: +82 10 9909 4743
Email: kyunghun.jung@samsung.com EMail: kyunghun.jung@samsung.com
 End of changes. 196 change blocks. 
449 lines changed or deleted 346 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/