draft-ietf-mmusic-image-attributes-08.txt   draft-ietf-mmusic-image-attributes-09.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 18, 2011 Samsung Electronics Co., Ltd. Expires: May 29, 2011 Samsung Electronics Co., Ltd.
Oct 15, 2010 Nov 25, 2010
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-08 draft-ietf-mmusic-image-attributes-09
Abstract Abstract
This document proposes a new generic session set up attribute to make This document proposes a new generic session set up 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 draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is as only the image size that is desired by the receiver is
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 18, 2011. This Internet-Draft will expire on May 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.2.7. Change of display in middle of session . . . . . . . . 15 3.2.7. Change of display in middle of session . . . . . . . . 15
3.2.8. Use with layered codecs . . . . . . . . . . . . . . . 15 3.2.8. Use with layered codecs . . . . . . . . . . . . . . . 15
3.2.9. Addition of parameters . . . . . . . . . . . . . . . . 15 3.2.9. Addition of parameters . . . . . . . . . . . . . . . . 15
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 15 4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 15
4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 16 4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 17 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 18 4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 19 4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 8, line 34 skipping to change at page 8, line 34
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 conditioned that the payload type number differs. alternatives conditioned that the payload type number differs.
Note that the attribute is associated to the codec(s), for Note that the attribute is associated to the codec(s), for
instance an SDP offer may specify payload type number 101 while instance an SDP offer may specify payload type number 101 while
the answer may specify 102, this may make it troublesome to the answer may specify 102, this may make it troublesome to
specify a payload type number with the 'imageattr' attribute. In specify a payload type number with the 'imageattr' attribute. The
such cases it is better to use a wild card (*). only solution that works in this case is to use a wild card (*)
and thus specify that the image attribute applies to all codecs in
a media description.
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 parameter specifies the sample aspect ratio associated sar: The sar parameter specifies the sample aspect ratio associated
to the given range of x and y values. The sar parameter is to the given range of x and y values. The sar parameter is
defined as dx/dy where dx and dy is the physical size of the defined as dx/dy where dx and dy is the physical size of the
pixels. Square pixels gives a sar=1.0. The parameter sar MAY be pixels. Square pixels gives a sar=1.0. The parameter sar MAY be
skipping to change at page 10, line 10 skipping to change at page 10, line 10
wild card (*) in the attribute list. wild card (*) in the attribute list.
* It is recommended that a device which sees no reason to use the * It is recommended that a device which sees no reason to use the
image attribute, anyway includes the attribute with wild cards image attribute, anyway includes the attribute with wild cards
(*) in the attribute lists for the send and recv directions. (*) in the attribute lists 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 to express its
preferences. preferences. The use of wild cards introduces a risk that the
message size can increase in an uncontrolled way. To reduce
this risk these wild cards SHOULD only be replaced by an as
small set as possible.
o Answerer receiving the offer and sending the answer: o 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.
* The answerer may also, for its receive and send direction, * The answerer may also, for its receive and send direction,
replace the entries with a complete new set of entries replace the entries with a complete new set of entries
different from the original proposed by the offerer. The different from the original proposed by the offerer. The
implementor of this feature should however be aware that this implementor of this feature should however be aware that this
may cause extra offer/answer exchanges. may cause extra offer/answer exchanges.
* The answerer may also remove its send direction completely if * The answerer may also remove its send direction completely if
it is deemed that it cannot support any of the proposed it is deemed that it cannot support any of the proposed
entries. entries.
* The answerer should not on its own include an image attribute * The answerer should not include an image attribute in the
in the answer. answer if it was not present in the offer.
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
skipping to change at page 11, line 11 skipping to change at page 11, line 11
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 offerer and answerer. This will avoid the risk on
infinite negotiations. infinite negotiations.
3.2. Considerations 3.2. Considerations
3.2.1. No imageattr in 1st offer 3.2.1. No imageattr in 1st 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 wildcarded parameters if it has no preference. attribute with wildcarded 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 esp. the rules that
apply to "offerer receiving the answer". apply to "offerer receiving the answer".
skipping to change at page 13, line 20 skipping to change at page 13, line 20
---- ----
3.2.6. Interaction with codec parameters 3.2.6. 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 set up, 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 Section 3.2.6.4 they define image-size related information. Section 3.2.6.4 outlines
outlines a few recommended solutions a few possible solutions, but this document does not make any
recommendation for any of them.
3.2.6.1. H.263 3.2.6.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
skipping to change at page 14, line 21 skipping to change at page 14, line 21
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.6.4. Possible solutions 3.2.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, listed below without any
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 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 set up of the entire session (including audio) may be delayed that set up of the entire session (including audio) may be delayed
considerably, especially as the 'imageattr' negotiation can considerably, especially as the 'imageattr' negotiation can
skipping to change at page 20, line 46 skipping to change at page 21, line 5
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
Note to RFC Editor: please replace remove this section in its Note to RFC Editor: please replace remove this section in its
entirety before publication. entirety before publication.
The main changes are: The main changes are:
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 From WG -07 to WG -08
* SHOULD changed to MUST in section "Offer/answer rules" * SHOULD changed to MUST in section "Offer/answer rules"
From WG -05 to WG -06 & -07 From WG -05 to WG -06 & -07
* Update based on AD review comments, no changes to fix issue * Update based on AD review comments, no changes to fix issue
related to RFC2119 keywords related to RFC2119 keywords
* Minor editorial changes * Minor editorial changes
 End of changes. 12 change blocks. 
15 lines changed or deleted 32 lines changed or added

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