draft-ietf-mmusic-image-attributes-10.txt   draft-ietf-mmusic-image-attributes-11.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: June 18, 2011 Samsung Electronics Co., Ltd. Expires: August 22, 2011 Samsung Electronics Co., Ltd.
Dec 15, 2010 Feb 18, 2011
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-10 draft-ietf-mmusic-image-attributes-11
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 June 18, 2011. This Internet-Draft will expire on August 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.2.10. Addition of parameters . . . . . . . . . . . . . . . . 16 3.2.10. Addition of parameters . . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 16 4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 16
4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 17 4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 20 4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document proposes a new attribute to make it possible to This document proposes a new SDP attribute to make it possible to
negotiate different image attributes such as image size. The term negotiate different image attributes such as image size. The term
image size is defined here as it may differ from the physical screen image size is defined here as it may differ from the physical screen
size of for instance a hand-held terminal. As an example it may be size of for instance a hand-held terminal. As an example it may 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.
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:
skipping to change at page 3, line 50 skipping to change at page 3, line 50
In cases where rescaling is not implemented (for example, rescaling In cases where rescaling is not implemented (for example, rescaling
is not mandatory to implement in H.264 [H.264]), the indication of is not mandatory to implement in H.264 [H.264]), the indication of
the image attributes may still provide an optimal use of bandwidth the image attributes may still provide an optimal use of bandwidth
because the attribute will anyway give the encoder a better because the attribute will anyway give the encoder a better
indication about what image size is preferred and will thus help to indication about what image size is preferred and will thus help to
avoid wasting bandwidth by encoding with an unnecessarily large avoid wasting bandwidth by encoding with an unnecessarily large
resolution. resolution.
For implementers that are considering rescaling issues, it is worth For implementers that are considering rescaling issues, it is worth
notice that there are several benefits to do it on the sender side: to notice that there are several benefits to do 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, without the image attribute, not know which format to choose as, without the image attribute,
it does not know the receiver's performance or preference. it does not know the receiver's performance or preference.
skipping to change at page 8, line 16 skipping to change at page 8, line 16
MUST NOT occur more than once per image attribute. MUST NOT occur more than once per image attribute.
o The "recv" keyword and corresponding attribute list (attr-list) o The "recv" keyword and corresponding attribute list (attr-list)
MUST NOT occur more than once per image attribute. MUST NOT occur more than once per image attribute.
o PT is the payload type number, it MAY be set to "*" (wild card) to o PT is the payload type number, it MAY be set to "*" (wild card) to
indicate that the attribute applies to all payload types in the indicate that the attribute applies to all payload types in the
media description. media description.
o For sendrecv streams both of the send and recv directions SHOULD o For sendrecv streams both of the send and recv directions SHOULD
BE present in the SDP. be present in the SDP.
o For inactive streams it is RECOMMENDED that both of the send and o For inactive streams it is RECOMMENDED that both of the send and
recv directions are present in the SDP. recv directions are present in the SDP.
3.1.1.1. Parameter rules 3.1.1.1. Parameter rules
For the parameters the following rules apply. For the parameters the following rules apply.
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. This however requires that the payload type numbers
Note that the attribute is associated to the codec(s), for differ. Note that the attribute is associated to the codec(s),
instance an SDP offer may specify payload type number 101 while for instance an SDP offer may specify payload type number 101
the answer may specify 102, this may make it troublesome to while the answer may specify 102, this may make it troublesome to
specify a payload type number with the 'imageattr' attribute. See specify a payload type number with the 'imageattr' attribute. See
Section 3.2.2 for a discussion and recommendation how this is Section 3.2.2 for a discussion and recommendation how this is
solved. solved.
Preference (q): The preference for each set is 0.5 by default, Preference (q): The preference for each set is 0.5 by default,
setting the optional q parameter to another value makes it setting the optional q parameter to another value makes it
possible to set different preferences for the sets. A higher possible to set different preferences for the sets. A higher
value gives a higher preference for the given set. value gives a higher preference for the given set.
sar: The sar parameter specifies the sample aspect ratio associated sar: The sar (storage aspect ratio) parameter specifies the sample
to the given range of x and y values. The sar parameter is aspect ratio associated to the given range of x and y values. The
defined as dx/dy where dx and dy is the physical size of the sar parameter is defined as dx/dy where dx and dy is the physical
pixels. Square pixels gives a sar=1.0. The parameter sar MAY be size of the pixels. Square pixels gives a sar=1.0. The parameter
expressed as a range or as a single value. sar MAY be expressed as a range or as a single value.
If this parameter is not present a default sar value of 1.0 is If this parameter is not present a default sar value of 1.0 is
assumed. assumed.
The interpretation of sar differs between the send and the receive The interpretation of sar differs between the send and the receive
directions. directions.
* In the send direction it defines a specific sample aspect ratio * In the send direction it defines a specific sample aspect ratio
associated to a given x and y image size (range). associated to a given x and y image size (range).
* In the recv direction sar expresses that the receiver of the * In the recv direction sar expresses that the receiver of the
given medium prefers to receive a given x and y resolution with given medium prefers to receive a given x and y resolution with
skipping to change at page 9, line 38 skipping to change at page 9, line 38
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 sample aspect ratio that the receiver actually uses If sar and the sample aspect ratio that the receiver actually uses
in the display are the same (or close), the relation between the x in the display are the same (or close), the relation between the x
and y pixel resolution and the physical size of the image is and y pixel resolution and the physical size of the image is
straightforward. If however sar differs from the sample aspect straightforward. If however sar differs from the sample aspect
ratio of the receiver display this must be taken into ratio of the receiver display this must be taken into
consideration when the x and y pixel resolution alternatives are consideration when the x and y pixel resolution alternatives are
sorted out. sorted out. See Section 4.2.4 for an example of this.
3.1.1.2. Offer/answer rules 3.1.1.2. Offer/answer rules
In accordance with [RFC3264], offer answer exchange of the image In accordance with [RFC3264], offer answer exchange of the image
attribute is as follows. attribute is as follows.
o Offerer sending the offer: o Offerer sending the offer:
* The offerer must be able to support the image attributes that * The offerer must be able to support the image attributes that
it offers. The exception is if the offerer has expressed a it offers, unless the offerer has expressed a wild card (*) in
wild card (*) in the attribute list. the attribute list.
* It is recommended that a device which sees no reason to use the * It is recommended that a device 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. The use of wild cards introduces a risk that the preferences. The use of wild cards introduces a risk that the
skipping to change at page 11, line 29 skipping to change at page 11, line 29
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".
For the above reasons it is RECOMMENDED that a device which sees no For the above reasons it is RECOMMENDED that a device which sees no
reason to use the image attribute, anyway includes the attribute with reason to use the image attribute, anyway includes the attribute with
wild cards (*) in the attribute lists for the send and recv wild cards (*) in the attribute lists for the send and recv
directions. directions.
3.2.2. Different payload type numbers in offer and answer 3.2.2. Different payload type numbers in offer and answer
In some cases the answer may pick a different media payload type In some cases the answer may specify a different media payload type
number than the offer. As an example the offer SDP may have the number than the offer. As an example the offer SDP may have the
m-line m-line
---- ----
m=video 49154 RTP/AVP 99 m=video 49154 RTP/AVP 99
---- ----
While the answer SDP may have the m-line While the answer SDP may have the m-line
---- ----
m=video 49154 RTP/AVP 100 m=video 49154 RTP/AVP 100
---- ----
skipping to change at page 12, line 25 skipping to change at page 12, line 25
The answer SDP looks like: The answer SDP looks like:
---- ----
m=video 49154 RTP/AVP 100 m=video 49154 RTP/AVP 100
a=imageattr:99 send ... a=imageattr:99 send ...
a=imageattr:100 recv ... a=imageattr:100 recv ...
---- ----
This alternative does not pose any drawbacks. Moreover it allows This alternative does not pose any drawbacks. Moreover it allows
to specify different image attributes if more than one payload to specify different image attributes if more than one payload
type is specified in the offer SDP. type is specified in the offer SDP.
Of the alternatives listed above, the last one is RECOMMENDED to be Of the alternatives listed above, the last one MUST be used as it is
used if the media payload type number changes in the SDP answer. the most safe. The other alternatives MUST NOT be used.
3.2.3. Asymmetry 3.2.3. Asymmetry
While the image attribute supports asymmetry there are some While the image attribute supports asymmetry there are some
limitations to this. One important limitation is that the codec limitations 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 [H.264] with profile level 1.2 does not support As an example H.264 [H.264] with profile level 1.2 does not support
higher resolution than 352x288 (CIF). The offer/answer rules imply higher resolution than 352x288 (CIF). The offer/answer rules imply
skipping to change at page 14, line 40 skipping to change at page 14, line 40
H.263 defines (on the fmtp line) a list of image sizes and their H.263 defines (on the fmtp line) a list of image sizes and their
maximum frame rates (profiles) that the offerer can receive. The maximum frame rates (profiles) that the offerer can receive. The
answerer is not allowed to modify this list and must reject a payload answerer is not allowed to modify this list and must reject a payload
type that contains an unsupported profile. The CUSTOM profile may be type that contains an unsupported profile. The CUSTOM profile may be
used for image size negotiation but support for asymmetry requires used for image size negotiation but support for asymmetry requires
the specification of two unidirectional media descriptions using the the specification of two unidirectional media descriptions using the
sendonly/recvonly attributes. sendonly/recvonly attributes.
3.2.7.2. H.264 3.2.7.2. H.264
The payload format for H.264 [H.264] is described in [RFC3984] and The payload format for H.264 [H.264] is described in [RFC3984bis].
updated in [RFC3984bis].
H.264 defines image size related information in the fmtp line by H.264 defines image size related information in the fmtp line by
means of sprop-parameter-sets. According to the specification means of sprop-parameter-sets. According to the specification
several sprop-parameter-sets may be defined for one payload type. several sprop-parameter-sets may be defined for one payload type.
The sprop-parameter-sets describe the image size (+ more) that the The sprop-parameter-sets describe the image size (+ more) that the
offerer sends in the stream and need not be complete. This means offerer sends in the stream and need not be complete. This means
that this does not represent any negotiation. Moreover an answer is that this does not represent any negotiation. Moreover an answer is
not allowed to change the sprop-parameter-sets. not allowed to change the sprop-parameter-sets.
This configuration may be changed later inband if for instance image This configuration may be changed later inband if for instance image
skipping to change at page 15, line 36 skipping to change at page 15, line 36
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
already itself cost up to two offer/answer rounds. Also the already itself cost up to two offer/answer rounds. Also the
conflict between the 'imageattr' negotiation and the payload conflict between the 'imageattr' negotiation and the payload
format specific parameters is still present after the first offer/ format specific parameters is still present after the first offer/
anser round and a fuzzy/buggy implementation may start media answer round and a fuzzy/buggy implementation may start media
before the second offer/answer is completed with unwanted results. before the second offer/answer is completed with unwanted results.
o 2nd session-wide offer/answer round only for video: This is o 2nd session-wide offer/answer round only for video: This is
similar to the alternative above with the exception that set up similar to the alternative above with the exception that set up
time for audio is not increased, moreover the port number for time for audio is not increased, moreover the port number for
video is set to 0 during the 1st offer answer round to avoid that video is set to 0 during the 1st offer answer round to avoid that
media flows. media flows.
This has the effect that video will blend in some time after the This has the effect that video will blend in some time after the
audio is started (up to 2 seconds delay). This alternative is audio is started (up to 2 seconds delay). This alternative is
likely the most clean-cut and failsafe alternative. The drawback likely the most clean-cut and failsafe alternative. The drawback
skipping to change at page 16, line 20 skipping to change at page 16, line 20
A very likely scenario is that a user switches to another phone A very likely scenario is that a user switches to another phone
during a video telephony call or plugs a cellphone into an external during a video telephony call or plugs a cellphone into an external
monitor. In both cases it is very likely that a renegotiation is monitor. In both cases it is very likely that a renegotiation is
initiated using the SIP-REFER or SIP-UPDATE methods. It is initiated using the SIP-REFER or SIP-UPDATE methods. It is
RECOMMENDED to negotiate the image size during this renegotiation. RECOMMENDED to negotiate the image size during this renegotiation.
3.2.9. Use with layered codecs 3.2.9. Use with layered codecs
As the image attribute is a media level attribute, its use with As the image attribute is a media level attribute, its use with
layered codecs cause some concern. If the layers are transported in layered codecs causes some concern. If the layers are transported in
different RTP streams the layers are specified on different media different RTP streams the layers are specified on different media
descriptions and the relation is specified using the grouping descriptions and the relation is specified using the grouping
framework [RFC5888] and the depend attribute [RFC5583]. As it is not framework [RFC5888] and the depend attribute [RFC5583]. As it is not
possible to specify only one image attribute for several media possible to specify only one image attribute for several media
descriptions the solution is either to specify the same image descriptions the solution is either to specify the same image
attribute for each media description, or to only specify the image attribute for each media description, or to only specify the image
attribute for the base layer. attribute for the base layer.
3.2.10. Addition of parameters 3.2.10. Addition of parameters
skipping to change at page 17, line 29 skipping to change at page 17, line 29
In the first alternative the recv direction may be a full list of In the first alternative the recv direction may be a full list of
desired image size formats. It may however (and most likely) just be desired image size formats. It may however (and most likely) just be
a list with one alternative for the preferred x and y resolution. a list with one alternative for the preferred x and y resolution.
If Bob supports an x and y resolution in at least one of the X and Y If Bob supports an x and y resolution in at least one of the X and Y
ranges given in the send attr-list and in the recv attr-list of the ranges given in the send attr-list and in the recv attr-list of the
offer, the answer from Bob will look like: offer, the answer from Bob will look like:
---- ----
a=imageattr:PT send attr-list recv attr-list a=imageattr:PT send attr-list recv attr-list
---- ----
And the offer answer negotiation is done. Worth notice here is that And the offer answer negotiation is done. Worth noticing here is
the attr-list will likely be pruned in the answer. While it may 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 many different alternatives in the offer it may in the end
contain just one or two alternatives. contain just one or two alternatives.
If Bob does not support any x and y resolution in one of the provided If Bob does not support any x and y resolution in one of the provided
send or recv ranges given in the send attr-list or in the recv attr- send or recv ranges given in the send attr-list or in the recv attr-
list, the corresponding part is removed completely. For instance, if list, the corresponding part is removed completely. For instance, if
Bob doesn't support any of the offered alternatives in the recv attr- Bob doesn't support any of the offered alternatives in the recv attr-
list in the offer, the answer from Bob would look like: list in the offer, the answer from Bob would look like:
---- ----
a=imageattr:PT recv attr-list a=imageattr:PT recv attr-list
skipping to change at page 20, line 33 skipping to change at page 20, line 33
We set up a session between Alice and Bob, Alice is the offerer of We set up a session between Alice and Bob, Alice is the offerer of
the session. The offer (from Alice) contains the image attribute the session. The offer (from Alice) contains the image attribute
below: below:
---- ----
a=imageattr:97 \ a=imageattr:97 \
send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] \ send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] \
recv [x=800,y=600,sar=1.1] recv [x=800,y=600,sar=1.1]
---- ----
First we consider the recv direction: The offerer (Alice) explicitly First we consider the recv direction: The offerer (Alice) explicitly
states that she wish to receive the screen resolution 800x600, states that she wishes to receive the screen resolution 800x600,
however she also indicates that the screen on her display does not however she also indicates that the screen on her display does not
use square pixels, the sar value=1.1 means that Bob must (preferably) use square pixels, the sar value=1.1 means that Bob must (preferably)
compensate for this. compensate for this.
So.. If Bob's video camera produces square pixels, and wish to So.. If Bob's video camera produces square pixels, and wishes to
satisfy Alice's sar requirement, the image processing algorithm must satisfy Alice's sar requirement, the image processing algorithm must
rescale a 880x600 pixel image (880=800*1.1) to 800x600 pixels (could rescale a 880x600 pixel image (880=800*1.1) to 800x600 pixels (could
be done other ways). be done other ways).
... and now the send direction: Alice indicates that she can (in the ... and now the send direction: Alice indicates that she can (in the
image processing algorithms) rescale the image for sample aspect image processing algorithms) rescale the image for sample aspect
ratios in the range 1.0 to 1.3. She can also provide with a number ratios in the range 1.0 to 1.3. She can also provide with a number
of different image sizes (in pixels) ranging from 400x320 to 800x640. of different image sizes (in pixels) ranging from 400x320 to 800x640.
Bob inspects the offered sar and image sizes and responds with the Bob inspects the offered sar and image sizes and responds with the
modified image attribute modified image attribute
---- ----
a=imageattr:97 \ a=imageattr:97 \
recv [x=464,y=384,sar=1.15] \ recv [x=464,y=384,sar=1.15] \
send [x=800,y=600,sar=1.1] send [x=800,y=600,sar=1.1]
---- ----
Alice will, in order to satisfy Bob's request, need to rescale the Alice will (in order to satisfy Bob's request) need to rescale the
image from her video camera from 534x384 (534=464*1.15) to 464x384. image from her video camera from 534x384 (534=464*1.15) to 464x384.
Neither part is required to rescale like this (sar may be ignored),
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:
Attribute name: imageattr Attribute name: imageattr
Long form name: Image attribute Long form name: Image attribute
Type of attribute: Media-level Type of attribute: Media-level
skipping to change at page 21, line 39 skipping to change at page 21, line 36
Appropriate values: See Section 3.1.1 of RFCXXXX Appropriate values: See Section 3.1.1 of RFCXXXX
Contact name: Authors of RFCXXXX Contact name: Authors of RFCXXXX
Note to RFC Editor: please replace "RFCXXXX" above with the RFC Note to RFC Editor: please replace "RFCXXXX" above with the RFC
number of this document, and remove this note. 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 The image attribute and especially the parameters that denote the
those already existing with currently specified offer/answer image size can take on values that may cause memory or CPU exhaustion
procedures. problems. This may happen either as a consequence of a mistake by
the sender of the SDP or as a result of an attack issued by a
malicious SDP sender. This issue is similar to the case where the
a=fmtp line(s) may take on extreme values for the same reasons as
outlined above.
A receiver of the SDP containing the image attribute MUST ensure that
the parameters have values that are reasonable and that the device
can handle the implications in terms of memory and CPU usage.
Failure to do a sanity check on the parameters may result in memory
or CPU exhaustion.
In principle, for some SDPs containing the image attribute and for
some deployments, it could be the case that simply checking the
parameters is not sufficient to detect all potential DoS problems.
Implementers ought to consider whether there are any potential DoS
attacks that would not be detected by simply checking parameters.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the people who has contributed with The authors would like to thank the people who 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. Thanks also Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Thanks also
to Robert Sparks and Paul Kyzivat for the help with the last fixes to to Robert Sparks and Paul Kyzivat for the help with the last fixes to
get the attribute work well with the offer/answer model. get the attribute work well with the offer/answer model.
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 -10 to WG -11
* Changes after IESG review
From WG -09 to WG -10 From WG -09 to WG -10
* Further clarified the issue that offer and answer may use * Further clarified the issue that offer and answer may use
different PT numbers, additional section added. different PT numbers, additional section added.
* Additional typos fixed. * Additional typos fixed.
From WG -08 to WG -09 From WG -08 to WG -09
* Clarified the issue that offer and answer may use different PT * Clarified the issue that offer and answer may use different PT
skipping to change at page 24, line 41 skipping to change at page 25, line 20
[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".
[MPEG-4] ISO/IEC, "ISO/IEC 14496-2:2004: "Information technology - [MPEG-4] ISO/IEC, "ISO/IEC 14496-2:2004: "Information technology -
Coding of audio-visual objects - Part 2: Visual"". Coding of audio-visual objects - Part 2: Visual"".
[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.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video",
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/".
[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.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010. Capability Negotiation", RFC 5939, September 2010.
 End of changes. 26 change blocks. 
44 lines changed or deleted 57 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/