draft-ietf-mmusic-image-attributes-02.txt   draft-ietf-mmusic-image-attributes-03.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: October 18, 2009 Samsung Electronics Co., Ltd. Expires: April 21, 2010 Samsung Electronics Co., Ltd.
Apr 16, 2009 Oct 18, 2009
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-02 draft-ietf-mmusic-image-attributes-03
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 1, line 33
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 October 18, 2009. This Internet-Draft will expire on April 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document proposes a new generic session setup 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 e.g a low-end size. A possible use case is to make it possible for a low-end hand-
hand-held terminal to display video without the need to rescale the held terminal to display video without the need to rescale the image,
image, something that may consume large amounts of memory and something that may consume large amounts of memory and processing
processing power. The draft also helps to maintain an optimal power. The draft also helps to maintain an optimal bitrate for video
bitrate for video as only the image size that is desired by the as only the image size that is desired by the receiver is
receiver is transmitted. transmitted.
Requirements Language Requirements Language
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4
3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4 3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5
3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 8 3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 9
3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 10 3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 10
3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10 3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 11
3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10 3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 11
3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 11 3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 12
3.3.6. Interaction with codec parameters . . . . . . . . . . 11 3.3.6. Interaction with codec parameters . . . . . . . . . . 12
3.3.7. Change of display in middle of session . . . . . . . . 13 3.3.7. Change of display in middle of session . . . . . . . . 14
3.3.8. Addition of parameters . . . . . . . . . . . . . . . . 13 3.3.8. Use with layered codecs . . . . . . . . . . . . . . . 14
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.9. Addition of parameters . . . . . . . . . . . . . . . . 14
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Informative References . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Normative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 e.g a hand-held terminal. For instance it may be beneficial size of for instance a hand-held terminal. As an example it may be
to display a video image on a part of the physical screen and leave beneficial to display a video image on a part of the physical screen
space on the screen for e.g menus and other info. and leave space on the screen for other features such as menus and
other info.
There are a number of benefits with a possibility to negotiate the There are a number of benefits with a possibility to negotiate the
image size: 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 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 gives
alternatively a saving in bitrate. alternatively 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: If rescaling of the image is possible on the o Optimal aspect ratio: The indication of the supported image sizes
receiver side one can imagine that the offer contains three and aspect ratio allows the receiver to select the most
resolutions 100x200, 200x100 and 100x100 with sar=1.0 (1:1). If appropriate combination based on its rescaling capabilities and
the receiver screen has the resolution 200x200 with sar=1 then the the desired rendering. For example, if a sender proposes three
obvious is to select 100x100 and scale the image by a factor 2. resolutions in its SDP offer, 100x200, 200x100 and 100x100 with
If on the other hand the screen has the resolution 100x200 with sar=1.0 (1:1) etc. then the receiver can select the option that
sar=2 (2:1) then the obvious is again to select 100x100 and scale fits the receiver screen best.
the image by a factor 2 in the x-axis.
The cautious reader may however object that the rescaling issue has In cases where rescaling is not implemented (for example, rescaling
been moved to the sender and also that codecs such as H.264 are not is not mandatory to implement in H.264), the indication of the image
mandated to support the rescaling of the video image size. This attributes may still provide an optimal use of bandwidth because the
potentially reduces the number of valid arguments to only 1 (optimal attribute will anyway give the encoder a better indication about what
use of bandwidth). image size is preferred and will thus help to avoid wasting bandwidth
by encoding with an unnecessarily large resolution.
However, what must then be considered is that: For implementers that are considering rescaling issues, it is worth
notice note that there are several benefits to doing it on the sender
side:
o Rescaling on the sender/encoder side is likely to be easier to do 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 domain 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 it, without the image not know which format to choose as it, without the image
attribute, does not know the receivers performance or preference. attribute, does not know the receivers performance or preference.
skipping to change at page 4, line 25 skipping to change at page 4, line 30
o If low-complexity rescaling operations such as cropping only must o If low-complexity rescaling operations such as cropping only must
be performed after all, the benefit with having this functionality be performed after all, the benefit with having this functionality
on the sender side is that it is then possible to present a on the sender side is that it is then possible to present a
miniature "what you send" image on the display to help the user to 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". A problem statement more general the attribute is named "imageattr".
and discussion that gives a motivation to this document can be found
in [S4-080144].
The draft is limited to unicast scenarios in general and more The draft is limited to unicast scenarios in general and more
specific peer to peer situations. The attribute may be used in specific poit-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.
3. Defintion of Attribute 3. Defintion of Attribute
A new image attribute is defined with the name "imageattr". The new This section defines the SDP image attribute "imageattr" that can be
SDP attribute contains a set of image attribute options that the used in an SDP Offer/Answer exchange to indicate various image
offerer can provide. The receiver can then select the desired image attribute parameters. In this document, we define the following
attribute (e.g image size in pixels) and may then have the ability to image attribute parameters: image resolution, sample aspect ratio
avoid costly transformations (e.g rescaling) of the images. In this (sar), allowed range in picture aspect ratio and the preference of a
approach only the image resolution and optionally sample aspect given parameter set over another. The attribute is however
ratio, allowed range in picture aspect ratio and preference is extensible and guidelines for defining extensions are provided in
covered but the framework makes it possible to extend with other Section 3.3.9.
image related attributes that make sense.
3.1. Requirements 3.1. Requirements
The new image attribute should meet the following requirements: The image attribute MUST meet the following requirements:
REQ-1: Support the offer of a specific image size on the receiver REQ-1: Support the indication of one or more set(s) of image
display or in other words, reduce or avoid the need for rescaling attributes that the SDP endpoint wish to receive or send. An
images in the receiver to fit a given portion of the screen. image attribute set MUST include a specific image size.
REQ-2: Support asymmetric setups i.e the very likely scenario where REQ-2: Support setup/negotiation of image attributes, meaning that
Alice prefers an image size of 320x240 for her display while Bob each side in the Offer/Answer SHOULD be able to negotiate the
prefers an image size of 176x144. image attributes if 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 MPEG4. parameter-sets in H.264 or config in MPEG4.
REQ-3: Make the attribute generic with as little codec specific REQ-4: Make the attribute generic with as little codec specific
details/tricks as possible. Ideally the attribute should not care details/tricks as possible in order to be codec agnostic.
about the codec specific features.
OPT-1: Make it possible to use attribute for other purposes than Besides the above mentioned requirements, the requirement below MAY
video. One possible use case may be distributed white-board be applicable.
presentations which are based on transmission of compressed bitmap
images where rescaling often produce very poor results. OPT-1: The image attribute SHOULD support the description of image-
related attributes for various types of media, including video,
pictures, images, etc.
3.2. Attribute syntax 3.2. Attribute syntax
In this section the syntax of the image attribute is described. The In this section the syntax of the image attribute is described. The
section is split up in two parts, the first gives an overall view of image attribute is a media attribute. The section is split up in two
the syntax while the second describes how the syntax is used. parts, the first gives an overall view of the syntax while the second
describes how the syntax is used.
3.2.1. Overall view of syntax 3.2.1. Overall view of syntax
The syntax for the image attribute is in ABNF: The syntax for the image attribute is in ABNF [RFC4234]:
---- ----
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 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. 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:
skipping to change at page 6, line 20 skipping to change at page 7, line 4
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 x is the horizontal image size range
y is the vertical image size range y is the vertical image size range
sar (sample aspect ratio) is the sample aspect ratio associated sar (sample aspect ratio) is the sample aspect ratio associated
with the set (optional and MAY be ignored) with the set (optional and MAY be ignored)
par (picture aspect ratio) is the allowed ratios between the par (picture aspect ratio) is the allowed ratios between the
displays x and y physical size (optional) displays x and y physical size (optional)
q (optional with range [0.0..1.0], default value 0.5) q (optional with range [0.0..1.0], default value 0.5)
is the preference for the given set, a higher value means higher is the preference for the given set, a higher value means higher
preference from the sender point of view preference from the sender point of view
skipping to change at page 7, line 11 skipping to change at page 7, line 44
Note the use of brackets [..] if more that one value Note the use of brackets [..] if more that one value
is specified. is specified.
---- ----
Some further guidelines for the use of the attribute is given below: Some further guidelines for the use of the attribute is given below:
o The image attribute is bound to a specific media by means of the o 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. A wild card (*) can be specified for the
payload type number to indicate that it applies to all payload payload type number to indicate that it applies to all payload
types in the media description. Several image attributes can be types in the media description. Several image attributes can be
defined e.g for different video codec alternatives conditioned defined for instance for different video codec alternatives
that the payload type number differs. conditioned that the payload type number differs.
o The preference for each set is 0.5 by default, setting the o The preference for each set is 0.5 by default, setting the
optional q parameter to another value makes it possible to set 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 o The sar parameter specifies the sample aspect ratio associated to
the given range of x and y values. The sar parameter is defined the given range of x and y values. The sar parameter is defined
as dx/dy where dx and dy is the size of the pixels. Square pixels as dx/dy where dx and dy is the size of the pixels. Square pixels
gives a sar=1.0. The parameter sar MAY be expressed as a range. gives a sar=1.0. The parameter sar MAY be expressed as a range.
skipping to change at page 8, line 40 skipping to change at page 9, line 26
removed to make reading easier. removed to make reading easier.
In the offer Alice provides with information for both the send and In the offer Alice provides with information for both the send and
receive (recv) directions using syntax version 1. For the send receive (recv) directions using syntax version 1. For the send
direction Alice provides with a list that the answerer can select direction Alice provides with a list that the answerer can select
from. For the receive direction Alice may either specify a desired 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 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 list of image size that Bob can support to send. Using the overall
high level syntax the image attribute may then look like high level syntax the image 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 the given x and y range the If Bob supports an x and y resolution in the given x and y range the
answer from Bob will look like: 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 notice here is that 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 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 many different alternatives in the offer it may in the end
contain just one or two alternatives 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 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 range in attr-list or a * was given for the recv direction then he
MUST either: MUST either:
o Provide with another list of options (attr_list). The answer from o Provide with another list of options (attr-list). The answer from
Bob may then look like: Bob may then look like:
---- ----
a=imageattr:PT recv attr_list send attr_list a=imageattr:PT recv attr-list send attr-list
---- ----
In this case the offer/answer negotiation is not quite done. To In this case the offer/answer negotiation is not quite done. To
complete the offer/answer Alice sends another offer that looks complete the offer/answer Alice sends another offer that looks
like: like:
---- ----
a=imageattr:PT send attr_list recv attr_list a=imageattr:PT send attr-list recv attr-list
---- ----
Bob MAY send back an answer to complete the 2nd offer/answer but Bob MAY send back an answer to complete the 2nd offer/answer but
this is not necessary. this is not necessary.
o Remove the corresponding part completely in which case the answer o Remove the corresponding part completely in which case the answer
from bob would look like: from bob would look like:
---- ----
a=imageattr:PT recv attr_list a=imageattr:PT recv attr-list
---- ----
Again it is worth notice that the attr_list for each direction is Again it is worth notice that the attr-list for each direction is
likely pruned depending on preferred and supported options. likely pruned depending on preferred and supported options.
If the 1st offer (from Alice) already defines a desired image size If the 1st offer (from Alice) already defines a desired image size
for the recv direction the answerer can do one of the following: for the recv direction the answerer can do one of the following:
1. Accept the image size and return it in the answer. 1. Accept the image size and return it in the answer.
2. Replace with a list of options in the answer. 2. Replace with a list of options in the answer.
3. Remove the corresponding part completely. This may happen if it 3. Remove the corresponding part completely. This may happen if it
is deemed that it is unlikely that the list of options is is deemed that it is unlikely that the list of options is
supported. The answer will then lack a description for the send supported. The answer will then lack a description for the send
direction and will look like: direction and will look like:
---- ----
a=imageattr:PT recv attr_list a=imageattr:PT recv attr-list
---- ----
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
skipping to change at page 11, line 48 skipping to change at page 12, line 38
... ...
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.
3.3.6. Interaction with codec parameters 3.3.6. Interaction with codec parameters
As most codecs specifies some kind of indication of e.g. the image As most codecs specifies some kind of indication of for example the
size already at session setup some measures must be taken to avoid image size already at session setup, some measures must be taken to
that the image attribute conflicts with this already existing avoid that the image attribute conflicts with this already existing
information. information.
The following subsections describes the most well known codecs and The following subsections describes the most well known codecs and
how they define image-size related information. how they define image-size related information.
3.3.6.1. H.263 3.3.6.1. H.263
The payload format for H.263 is described in [RFC4629]. The payload format for 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
skipping to change at page 13, line 5 skipping to change at page 13, line 43
Currently it is not possible to change the configuration using inband Currently it is not possible to change the configuration using inband
signaling. signaling.
3.3.6.4. Possible solutions 3.3.6.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: There are a number of possible solutions:
o Ignore payload format parameters: This may not work well e.g in o Ignore payload format parameters: This may not work well in the
the presence of bad channel conditions esp. in the beginning of a presence of bad channel conditions especially in the beginning of
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 2nd session-wide offer/answer round: In the 2nd offer/answer the
codec payload format specific parameters are defined based on the codec payload format specific parameters are defined based on the
outcome of the imageattr negotiation. The drawback with this is outcome of the imageattr negotiation. The drawback with this is
that setup of the entire session (including audio) may be delayed that setup of the entire session (including audio) may be delayed
considerably, especially as the imageattr negotiation can already considerably, especially as the imageattr negotiation can already
itself cost up to two offer/answer rounds. Also the conflict itself cost up to two offer/answer rounds. Also the conflict
between the imageattr negotiation and the payload format specific between the imageattr negotiation and the payload format specific
parameters is still present after the first offer/anser round and parameters is still present after the first offer/anser round and
a fuzzy/buggy implementation may start media before the second a fuzzy/buggy implementation may start media before the second
skipping to change at page 13, line 36 skipping to change at page 14, line 26
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 alternative. The drawback
is, as the port number in the first offer is always zero, the is, as the port number in the first offer is always zero, the
media startup will always be delayed even though it would in fact media startup will always be delayed even though it would in fact
have been possible to start media already after the first offer/ have been possible to start media already after the first offer/
answer round. answer round.
3.3.7. Change of display in middle of session 3.3.7. 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 e.g a video telephony call or plugs the cellphone into an during a video telephony call or plugs the cellphone into an external
external monitor. In both cases it is very likely that a monitor. In both cases it is very likely that a renegotiation is
renegotiation is initiated using e.g the SIP-REFER or SIP-UPDATE initiated using the SIP-REFER or SIP-UPDATE methods. It is
methods. It is RECOMMENDED to negotiate the image size during this RECOMMENDED to negotiate the image size during this renegotiation.
renegotiation.
3.3.8. Addition of parameters 3.3.8. Use with layered codecs
As the image attribute is a media line attribute, its use with
layered codecs cause some concern. If the layers are transported in
different RTP streams the layers are specified on different media
descriptions and the relation is specified using the grouping
framework [GROUPING] and the depend attribute [RFC5583]. As it is
not possible to specify only one image attribute for several media
descriptions the solution is either to specify the same image
attribute for each media description, or to only specify the image
attribute for the base layer. [Ed. note, TBD].
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. Examples
skipping to change at page 17, line 43 skipping to change at page 18, line 43
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 -02 to WG -03
* 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
* Added info about future addition of parameters and backwards * Added info about future addition of parameters and backwards
compatibility compatibility
* Added IANA considerations * Added IANA considerations
skipping to change at page 18, line 34 skipping to change at page 19, line 38
* New bidirectional syntax * New bidirectional syntax
* Interoperability considerations with well known video codecs * Interoperability considerations with well known video codecs
discussed discussed
9. References 9. References
9.1. Informative References 9.1. Informative References
[GROUPING]
IETF, "The SDP Grouping Framework, http://tools.ietf.org/
html/draft-ietf-mmusic-rfc3388bis-03".
[H.264] ITU-T, "ITU-T Recommendation H.264, [H.264] ITU-T, "ITU-T Recommendation H.264,
http://www.itu.int/rec/T-REC-H.264-200711-I/en". http://www.itu.int/rec/T-REC-H.264-200711-I/en".
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. [RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Kimata, "RTP Payload Format for MPEG-4 Audio/Visual
Streams", RFC 3016, November 2000. Streams", RFC 3016, November 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video", M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005. RFC 3984, February 2005.
[RFC3984bis] [RFC3984bis]
IETF, "RTP Payload Format for H.264 Video, http:// IETF, "RTP Payload Format for H.264 Video, http://
tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/". tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/".
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
RFC 4587, August 2006. RFC 4587, August 2006.
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R.
Even, "RTP Payload Format for ITU-T Rec", RFC 4629, Even, "RTP Payload Format for ITU-T Rec", RFC 4629,
January 2007. January 2007.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009.
[S4-080144] [S4-080144]
3GPP, "Signaling of Image Size: Combining Flexibility and 3GPP, "Signaling of Image Size: Combining Flexibility and
Low Cost, http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/ Low Cost, http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/
TSGS4_48/Docs/S4-080144.zip". TSGS4_48/Docs/S4-080144.zip".
[SDPCapNeg] [SDPCapNeg]
IETF, "SDP Capability Negotiation, http://tools.ietf.org/ IETF, "SDP Capability Negotiation, http://tools.ietf.org/
wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation". wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation".
[SDPMedCapNeg] [SDPMedCapNeg]
skipping to change at page 19, line 39 skipping to change at page 21, line 10
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 Lulea_
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. 51 change blocks. 
112 lines changed or deleted 144 lines changed or added

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