draft-ietf-mmusic-image-attributes-03.txt   draft-ietf-mmusic-image-attributes-04.txt 
Network Working Group I. Johansson Network Working Group I. Johansson
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track K. Jung Intended status: Standards Track K. Jung
Expires: April 21, 2010 Samsung Electronics Co., Ltd. Expires: August 21, 2010 Samsung Electronics Co., Ltd.
Oct 18, 2009 Feb 17, 2010
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-03 draft-ietf-mmusic-image-attributes-04
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 draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is
transmitted.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 2010. This Internet-Draft will expire on August 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document proposes a new generic session setup attribute to make described in the BSD License.
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 draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is
transmitted.
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5
3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4 3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 5
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 6
3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 9 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 11
3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 10
3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 11 3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 12
3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 11 3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 12
3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 12 3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 12
3.3.6. Interaction with codec parameters . . . . . . . . . . 12 3.3.6. Interaction with codec parameters . . . . . . . . . . 13
3.3.7. Change of display in middle of session . . . . . . . . 14 3.3.7. Change of display in middle of session . . . . . . . . 15
3.3.8. Use with layered codecs . . . . . . . . . . . . . . . 14 3.3.8. Use with layered codecs . . . . . . . . . . . . . . . 15
3.3.9. Addition of parameters . . . . . . . . . . . . . . . . 14 3.3.9. Addition of parameters . . . . . . . . . . . . . . . . 15
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Syntax description and examples . . . . . . . . . . . . . . . 15
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Informative References . . . . . . . . . . . . . . . . . . 19 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Normative References . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Informative References . . . . . . . . . . . . . . . . . . 22
9.2. Normative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document proposes a new attribute to make it possible to This document proposes a new 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 be
beneficial to display a video image on a part of the physical screen 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 and leave space on the screen for other features such as menus and
other info. other info.
skipping to change at page 3, line 27 skipping to change at page 4, line 27
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 complexity: Image rescaling can be quite computation o Reduced complexity: Image rescaling can be quite computation
intensive. For low end devices this can be a problem. 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 gives 288x256 is displayed on the receiver screen. This alternatively
alternatively a saving in bitrate. 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
skipping to change at page 4, line 33 skipping to change at page 5, line 33
miniature "what you send" image on the display to help the user to miniature "what you send" image on the display to help the user to
target the camera correctly. target the camera 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 and is
targeted mainly at the negotiation of the image size but to make it targeted mainly at the negotiation of the image size but to make it
more general the attribute is named "imageattr". more general the attribute is named "imageattr".
The draft is limited to unicast scenarios in general and more The draft is limited to unicast scenarios in general and more
specific poit-to-point communication. The attribute may be used in specific point-to-point communication. The attribute may be used in
centralized conferencing scenarios as well but due to the abundance centralized conferencing scenarios as well but due to the abundance
of configuration options it may then be difficult to come up with a of configuration options it may then be difficult to come up with a
configuration that fits all parties. configuration that fits all parties.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
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 RFC 2119. document are to be interpreted as described in RFC 2119.
skipping to change at page 6, line 15 skipping to change at page 7, line 15
---- ----
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) ) / "*"
; see below for a definition of set. ; see below for a definition of set.
---- ----
o The attribute typically contains a "send" and a "recv" keyword.
These are interpreted from the senders perspective i.e the sender
of the SDP (either offerer or answerer) specifies the preferences
in its send and receive direction for the media once the session
is setup.
o Maximum one occurrence of the "send" keyword and corresponding o Maximum one occurrence of the "send" keyword and corresponding
attr-list is allowed per image attribute. attribute list (attr-list) is allowed per image attribute.
o Maximum one occurrence of the "recv" keyword and corresponding o Maximum one occurrence of the "recv" keyword and corresponding
attr-list is allowed per image attribute. attr-list is allowed per image attribute.
o PT is the payload type number, it can be set to * to indicate that o PT is the payload type number, it can be set to * to indicate that
the attribute applies to all payload types in the media the attribute applies to all payload types in the media
description. description.
o For sendonly or recvonly streams one of the directions MAY be o For sendonly or recvonly streams one of the directions MAY be
omitted. See Section 3.3.3, moreover the order of the send and omitted. See Section 3.3.3, moreover the order of the send and
recv directions is not important. recv directions is not important.
The syntax for the set is given by: The syntax for the set is given by:
---- ----
set= "[" "x=" range "," "y=" range [ ",sar=" range ] set= "[" "x=" range "," "y=" range [ ",sar=" range ]
[ ",par=" range ] [ ",q=" value ] "]" [ ",par=" range ] [ ",q=" value ] "]"
x is the horizontal image size range
y is the vertical image size range
sar (sample aspect ratio) is the sample aspect ratio associated
with the set (optional and MAY be ignored)
par (picture aspect ratio) is the allowed ratios between the
displays x and y physical size (optional)
q (optional with range [0.0..1.0], default value 0.5)
is the preference for the given set, a higher value means higher
preference from the sender point of view
range is expressed in a few different formats x is the horizontal image size range
1) range= value y is the vertical image size range
a single value sar (sample aspect ratio) is the sample aspect ratio associated
2) range= "[" value1 ":" [ step ":" ] value2 "]" with the set (optional and MAY be ignored)
values between value1 and value2 inclusive, par (picture aspect ratio) is the allowed ratios between the
if step is omitted a stepsize of 1 is implied displays x and y physical size (optional)
3) range= "[" value 1*( "," value ) "]" q (optional with range [0.0..1.0], default value 0.5)
any value from the list of values is the preference for the given set, a higher value means
4) range= "[" value1 "-" value2 "]" a higher preference
any real value between value1 and value2 inclusive
value is a positive integer or real value range is expressed in a few different formats
step is a positive integer or real value 1) range= value
If step is left out in the syntax a stepsize of 1 is implied a single value
Real values are only applicable for the 2) range= "[" value1 ":" [ step ":" ] value2 "]"
sar, par and q parameters values between value1 and value2 inclusive,
Note the use of brackets [..] if more that one value if step is omitted a stepsize of 1 is implied
is specified. 3) range= "[" value 1*( "," value ) "]"
---- any value from the list of values
4) range= "[" value1 "-" value2 "]"
any real value between value1 and value2 inclusive
Some further guidelines for the use of the attribute is given below: value is a positive integer or real value
step is a positive integer or real value
If step is left out in the syntax a stepsize of 1 is implied
Real values are only applicable for the
sar, par and q parameters
Note the use of brackets [..] if more than one value
is specified.
----
o The image attribute is bound to a specific media by means of the 3.2.1.1. Parameter rules
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
conditioned that the payload type number differs.
o The preference for each set is 0.5 by default, setting the For the parameters the following rules apply.
optional q parameter to another value makes it possible to set
Payload type number: The image attribute is bound to a specific
media 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 conditioned that the payload type number differs.
Preference: 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 different preferences for the sets. A higher value gives a higher
preference for the given set. preference for the given set.
o The sar parameter specifies the sample aspect ratio associated to sar: The sar parameter specifies the sample aspect ratio associated
the given range of x and y values. The sar parameter is defined to the given range of x and y values. The sar parameter is
as dx/dy where dx and dy is the size of the pixels. Square pixels defined as dx/dy where dx and dy is the physical size of the
gives a sar=1.0. The parameter sar MAY be expressed as a range. pixels. Square pixels gives a sar=1.0. The parameter sar MAY be
expressed as a range.
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 * In the send direction it defines a specific sample aspect
ration associated to a given x and y image size (range). ration 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 media prefers to receive a given x and y resolution with given media prefers to receive a given x and y resolution with
a given sample aspect ratio. a given sample aspect ratio.
See Section 3.3.4 for a more detailed discussion. See Section 3.3.4 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 solve
them and reduce aspect ratio distortion. them and reduce aspect ratio distortion.
The response MUST NOT include the sar parameter if there is no
acceptable value given.
o The par (width/height = x/y ratio) parameter indicates a range of par: The par (width/height = x/y ratio) parameter indicates a range
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 Where ratio_min and ratio_max are the min and max allowed picture
aspect ratios. aspect ratios.
If sar and the display sample aspect ration is the same (or close) If sar and the display sample aspect ration is the same (or close)
the relation between the x and y pixel resolution and the physical the relation between the x and y pixel resolution and the physical
size of the image is straightforward. If however sar differs from size of the image is straightforward. If however sar differs from
the sample aspect ratio of the receiver display this must be taken the sample aspect ratio of the receiver display this must be taken
into consideration when the x and y pixel resolution alternatives into consideration when the x and y pixel resolution alternatives
are sorted out. are sorted out.
o The offerer MUST be able to support the image attributes that it 3.2.1.2. Offer/answer rules
offers.
o The answerer MAY choose to keep imageattr but is not required to
do so. If the attribute is kept in the SDP answer:
* The answerer MUST for its receive direction only include one or
more valid entries taken from the offer. In other words, the
answerer MUST for its receive direction only pick one or more
valid entries from the multidimensional solution space spanned
by the offer.
* The answerer MAY for its send direction modify the attribute in The following rules apply for the offer/answer exchange.
the sense that new entries other than those presented in the
offer are added. It must however be noted that this may lead
to an extra offer/answer exchange of the added parameters are
not supported by the offerer.
3.2.2. Syntax description o Offerer sending the offer:
In the description of the syntax we here assume that Alice wish to * The offerer MUST be able to support the image attributes that
setup a session with Bob and that Alice takes the first initiative. it offers. The exception is if the offerer has expressed a
The syntactical white-space delimiters (1*WSP) and double-quotes are wild card (*) in the attribute list.
removed to make reading easier.
In the offer Alice provides with information for both the send and * It is RECOMMENDED that a high end device which sees no reason
receive (recv) directions using syntax version 1. For the send to use the image attribute, anyway includes the attribute with
direction Alice provides with a list that the answerer can select wild cards (*) in the attribute lists for the send and recv
from. For the receive direction Alice may either specify a desired directions. An example of this looks like:
image size range right away or a * to instruct Bob to fill with a ----
list of image size that Bob can support to send. Using the overall a=imageattr:97 send * recv *
high level syntax the image attribute may then look like ----
---- This gives the answerer the possibility to express its
a=imageattr:PT send attr-list recv attr-list preferences.
----
or
----
a=imageattr:PT send attr-list recv *
----
In the first alternative the recv direction may be a full list of
desired image size formats. It may however (and most likely) just be
a list with one alternative for the preferred x and y resolution.
If Bob supports an x and y resolution in the given x and y range the o Answerer receiving the offer and sending the answer:
answer from Bob will look like:
----
a=imageattr:PT send attr-list recv attr-list
----
And the offer answer negotiation is done. Worth notice here is 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 in the end.
If Bob does not support any x and y resolution in the given x and y * The answerer MAY choose to keep the image attribute but is not
range in attr-list or a * was given for the recv direction then he required to do so.
MUST either:
o Provide with another list of options (attr-list). The answer from * The answerer MAY, for its receive and send direction, include
Bob may then look like: 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,
a=imageattr:PT recv attr-list send attr-list replace the entries with a complete new set of entries
---- different from the original proposed by the offerer.
In this case the offer/answer negotiation is not quite done. To
complete the offer/answer Alice sends another offer that looks
like:
----
a=imageattr:PT send attr-list recv attr-list
----
Bob MAY send back an answer to complete the 2nd offer/answer but
this is not necessary.
o Remove the corresponding part completely in which case the answer * The answerer MAY also remove its send direction completely if
from bob would look like: it is deemed that it cannot support any of the proposed
---- entries.
a=imageattr:PT recv attr-list
----
Again it is worth notice that the attr-list for each direction is
likely pruned depending on preferred and supported options.
If the 1st offer (from Alice) already defines a desired image size * The answerer SHOULD NOT on its own include an image attribute
for the recv direction the answerer can do one of the following: in the answer.
1. Accept the image size and return it in the answer. o Offerer receiving the answer:
2. Replace with a list of options in the answer. * If the image attribute is not included in the SDP answer the
offerer MUST resort of other methods to determine the
appropriate image size.
3. Remove the corresponding part completely. This may happen if it * If the image attribute is included in the SDP answer but none
is deemed that it is unlikely that the list of options is of the entities are useful or acceptable, the offerer MUST
supported. The answer will then lack a description for the send resort to other methods to determine the appropriate image
direction and will look like: size. It this case the offerer MUST also issue a new offer/
---- answer without the image attribute to avoid misunderstandings
a=imageattr:PT recv attr-list between offerer and answerer.
----
3.3. Considerations 3.3. Considerations
3.3.1. No imageattr in 1st offer 3.3.1. No imageattr in 1st offer
A high end device (Alice) may not see any need for the image A high end device (Alice) may not see any need for the image
attribute as it most likely has the processing capacity to rescale attribute as it most likely has the processing capacity to rescale
incoming video and may therefore not include the attribute in the incoming video and may therefore not include the attribute in the
offer as it otherwise does not see any use for it. The answerer offer as it otherwise does not see any use for it. The answerer
(Bob) MAY include imageattr in the answer. This has two (Bob) SHOULD NOT include imageattr in the answer. The reasons to
implications: this are:
o Longer session setup time due to extra offer/answer exchanges o The offerer of the initial SDP is anyway not likely to understand
o There is a risk that Alice does not recognize or support imageattr the image attribute
and will thus anyway ignore the attribute.
o Inclusion of the image attribute in the answer may come in
conflict with the rules in Section 3.2.1.2 esp. the rules that
apply to "offerer receiving the answer".
For the above reasons it is RECOMMENDED that a high end device which
sees no reason to use the image attribute, anyway includes the
attribute with wild cards (*) in the attribute lists for the send and
recv directions.
3.3.2. Asymmetry 3.3.2. 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 to this. One important limitation is that the codec
being used can only support up to a given maximum resolution for a being used can only support up to a given maximum resolution for a
given profile level. given profile level.
As an example H.264 with profile level 1.2 does not support higher As an example H.264 with profile level 1.2 does not support higher
resolution than 352x288 (CIF). The offer/answer rules essentially resolution than 352x288 (CIF). The offer/answer rules essentially
gives that the same profile level must be used in both directions. gives that the same profile level must be used in both directions.
This means that for an asymmetric scenario where Alice wants an image 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 size of 580x360 and Bob wants 150x120, profile level 2.2 is needed in
both directions even though profile level 1 would have been enough in both directions even though profile level 1 would have been
one direction. sufficient in 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 in [RFC3984bis]. issue for the H.264 codec is solved to some extent in [RFC3984bis].
3.3.3. sendonly and recvonly 3.3.3. 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 media, there is of course no need to specify the image attribute a media, there is of course no need to specify the image attribute
for both directions. Therefore one of directions in the attribute for both directions. Therefore one of the directions in the
MAY be omitted. However it may be good to do the image attribute attribute MAY be omitted. However it may be good to do the image
negotiation in both directions in case the session is updated for attribute negotiation in both directions in case the session is
media in both directions at a later stage. updated for media in both directions at a later stage.
3.3.4. Sample aspect ratio 3.3.4. Sample aspect ratio
The sar parameter in relation to the x and y pixel resolution The sar parameter in relation to the x and y pixel resolution
deserves some extra discussion. Consider the offer from Alice to Bob deserves some extra discussion. Consider the offer from Alice to Bob
(we set the recv direction aside for the moment): (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
skipping to change at page 12, line 4 skipping to change at page 12, line 29
---- ----
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 draft.
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 to Bob to decide which one he prefers.
The response MUST NOT include the sar parameter if there is no
acceptable value given.
3.3.5. SDPCapNeg support 3.3.5. SDPCapNeg support
The image attribute can be used within the SDP Capability Negotiation The image attribute can be used within the SDP Capability Negotiation
[SDPCapNeg] framework and its use is then specified using the [SDPCapNeg] framework and its use is then specified using the
"a=acap" parameter. An example is "a=acap" 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
skipping to change at page 14, line 41 skipping to change at page 15, line 23
3.3.8. Use with layered codecs 3.3.8. Use with layered codecs
As the image attribute is a media line attribute, its use with As the image attribute is a media line attribute, its use with
layered codecs cause some concern. If the layers are transported in layered codecs cause 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 [GROUPING] and the depend attribute [RFC5583]. As it is framework [GROUPING] and the depend attribute [RFC5583]. As it is
not possible to specify only one image attribute for several media not 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. [Ed. note, TBD]. attribute for the base layer.
3.3.9. Addition of parameters 3.3.9. Addition of parameters
The image attribute opens up for the addition of parameters in the The image attribute opens up 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
process the attribute MUST remove parameters that are not recognized process the attribute MUST remove parameters that are not recognized
before returning the attribute in the SDP answer. Addition of future before returning the attribute in the SDP answer. Addition of future
parameters that are not understood by the receiving endpoint may lead parameters that are not understood by the receiving endpoint may lead
to ambiguities if mutual dependencies between parameters exist, to ambiguities if mutual dependencies between parameters exist,
therefore addition of parameters must be done with great care. therefore addition of parameters must be done with great care.
4. Examples 4. Syntax description and examples
A few examples to highlight the syntax, here is assumed where needed This section gives some more information on how to use the attribute
that Alice initiates a session with Bob both in terms of a syntax description and a few detailed examples.
4.1. Example 1 4.1. Description
In the description of the syntax we here assume that Alice wish to
setup 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.
In the offer Alice provides with information for both the send and
receive (recv) directions using syntax version 1. For the send
direction Alice provides with 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 fill with a
list of image size that Bob can support to send. Using the overall
high level syntax the image attribute may then look like
---- ----
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ a=imageattr:PT send attr-list recv attr-list
recv [x=330,y=250] ----
or
----
a=imageattr:PT send attr-list recv *
----
In the first alternative the recv direction may be a full list of
desired image size formats. It may however (and most likely) just be
a list with one alternative for the preferred x and y resolution.
If Bob supports an x and y resolution in the given x and y range the
answer from Bob will look like:
----
a=imageattr:PT send attr-list recv attr-list
----
And the offer answer negotiation is done. Worth notice here is 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 in the end.
If Bob does not support any x and y resolution in the given x and y
range in attr-list or a * was given for the recv direction then he
MUST either:
o Remove the corresponding part completely in which case the answer
from bob would look like:
----
a=imageattr:PT recv attr-list
---- ----
Again it is worth notice that the attr-list for each direction is
likely pruned depending on preferred and supported options.
If the 1st offer (from Alice) already defines a desired image size
for the recv direction the answerer can do one of the following:
1. Accept the image size and return it in the answer.
2. Replace with a list of options in the answer.
3. Remove the corresponding part completely. This may happen if it
is deemed that it is unlikely that the list of options is
supported. The answer will then lack a description for the send
direction and will look like:
----
a=imageattr:PT recv attr-list
----
A few examples to highlight the syntax, here is assumed where needed
that Alice initiates a session with Bob
4.2. Examples
This section gives a few detailed examples
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
The example also indicates that Alice wish to display video with a It is also indicated that Alice wish to display video with a
resolution of 330x250 on her display resolution of 330x250 on her display
----
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 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) wish the encoder (on Alice's side)
to compensate for a sample aspect ratio of 1.1 (11:10) and desires an to compensate for a sample aspect ratio of 1.1 (11:10) and desires an
image size on its screen of 800x640. image size on its screen of 800x640.
skipping to change at page 16, line 5 skipping to change at page 18, line 11
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 (actually not necessary): Bob replies with (actually not necessary):
---- ----
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. Example 2 4.2.2. Example 2
Two image resolution sets are offered with the first having a higher
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 *
---- ----
Two image resolution sets are offered with the first having a higher The x-axis resolution can take the values 480 to 800 in 16 pixels
preference (q=0.6). The x-axis resolution can take the values 480 to steps and 176 to 208 in 8 pixels steps. The par parameter limits the
800 in 16 pixels steps and 176 to 208 in 8 pixels steps. The par set of possible x and y screen resolution combinations such that
parameter limits the set of possible x and y screen resolution 800x640 (ratio=1.25) is a valid combination while 720x608
combinations such that 800x640 (ratio=1.25) is a valid combination (ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations.
while 720x608 (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 with
a list of supported image sizes a list of supported image sizes
4.3. Example 3 4.2.3. Example 3
In this example is defined a complete SDP offer for the video media In this example is defined a complete SDP offer for the video media
part part
---- ----
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] \
skipping to change at page 17, line 13 skipping to change at page 19, line 21
---- ----
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.
4.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 setup a session between Alice and Bob, Alice is the offerer of the We setup a session between Alice and Bob, Alice is the offerer of the
session. The offer (from Alice) contains the image attribute below: session. The offer (from Alice) contains the image attribute below:
---- ----
a=imageattr:97 \ a=imageattr:97 \
send [sar=[1.0-1.3],x=400:16:800],y=[320:16:640],par=[1.2-1.3]] \ send [sar=[1.0-1.3],x=400:16:800],y=[320:16:640],par=[1.2-1.3]] \
skipping to change at page 18, line 10 skipping to change at page 20, line 21
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.
Neither part is required to rescale like this (sar MAY be ignored), Neither part is required to rescale like this (sar MAY be ignored),
the consequence will of course be a distorted image. the consequence will of course be a distorted image.
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:
o Contact name, email address and telephone number: Authors of Attribute name: imageattr
RFCXXXX
o Attribute-name: imageattr Long form name: Image attribute
o Type of attribute: media-level Type of attribute: Media-level
o Subject to charset: no Subject to charset: No
This attribute defines the ability to negotiate various image Purpose: This attribute defines the ability to negotiate
attributes such as image sizes. The attribute contains a number of various image attributes such as image sizes.
parameters which can be modified in and offer/answer exchange. The attribute contains a number of parameters
which can be modified in and offer/answer
exchange.
Note to RFC Editor: please replace "RFC XXXX" above with the RFC Appropriate values: See Section 3.2.1 of RFCXXXX
number of this memo, and remove this note.
Contact name: Authors of RFCXXXX
Note to RFC Editor: please replace "RFCXXXX" above with the RFC
number of this document, and remove this note.
6. Security Considerations 6. Security Considerations
This draft does not add any additional security issues other than This draft does not add any additional security issues other than
those already existing with currently specified offer/answer those already existing with currently specified offer/answer
procedures. procedures.
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 has contributed with
objections and suggestions to this draft and provided with valuable objections and suggestions to this draft and provided with valuable
guidance in the amazing video-coding world. Special thanks go to guidance in the amazing video-coding world. Special thanks go to
Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing.
8. Changes 8. Changes
The main changes are: The main changes are:
From WG -03 to WG -04
* Rearrangement of text
* Clarification of offer/answer rules
* Cleaned IANA section
From WG -02 to WG -03 From WG -02 to WG -03
* Partial update based on review comments from Jean-Francois Mule * Partial update based on review comments from Jean-Francois Mule
From WG -01 to WG -02 From WG -01 to WG -02
* Added extra example that highlights the negotiation of sar * Added extra example that highlights the negotiation of sar
From WG -00 to WG -01 From WG -00 to WG -01
skipping to change at page 21, line 10 skipping to change at page 23, line 30
9.2. Normative References 9.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
Laboratoriegrand 11 Laboratoriegrand 11
SE-971 28 Lulea_ 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
 End of changes. 62 change blocks. 
231 lines changed or deleted 294 lines changed or added

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