draft-ietf-mmusic-image-attributes-06.txt   draft-ietf-mmusic-image-attributes-07.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: December 16, 2010 Samsung Electronics Co., Ltd. Expires: April 1, 2011 Samsung Electronics Co., Ltd.
June 14, 2010 Sep 28, 2010
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-06 draft-ietf-mmusic-image-attributes-07
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 December 16, 2010. This Internet-Draft will expire on April 1, 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 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5
3. Specification of the 'imageattr' SDP Attribute . . . . . . . . 5 3. Specification of the 'imageattr' SDP Attribute . . . . . . . . 5
3.1. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 3.1. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 3.1.1. Overall view of syntax . . . . . . . . . . . . . . . . 5
3.2. Considerations . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Considerations . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. No imageattr in 1st offer . . . . . . . . . . . . . . 10 3.2.1. No imageattr in 1st offer . . . . . . . . . . . . . . 11
3.2.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. sendonly and recvonly . . . . . . . . . . . . . . . . 11 3.2.3. sendonly and recvonly . . . . . . . . . . . . . . . . 11
3.2.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 11 3.2.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 12
3.2.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 12 3.2.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 12
3.2.6. Interaction with codec parameters . . . . . . . . . . 12 3.2.6. Interaction with codec parameters . . . . . . . . . . 13
3.2.7. Change of display in middle of session . . . . . . . . 14 3.2.7. Change of display in middle of session . . . . . . . . 15
3.2.8. Use with layered codecs . . . . . . . . . . . . . . . 14 3.2.8. Use with layered codecs . . . . . . . . . . . . . . . 15
3.2.9. Addition of parameters . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 18 4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document proposes a new attribute to make it possible to This document proposes a new attribute to make it possible to
negotiate different image attributes such as image size. The term negotiate different image attributes such as image size. The term
image size is defined here as it may differ from the physical screen image size is defined here as it may differ from the physical screen
size of for instance a hand-held terminal. As an example it may be size of for instance a hand-held terminal. As an example it may be
beneficial to display a video image on a part of the physical screen beneficial to display a video image on a part of the physical screen
and leave space on the screen for other features such as menus and and leave space on the screen for other features such as menus and
other info. other info.
skipping to change at page 4, line 32 skipping to change at page 4, line 32
the sender side is that it is then possible to present a miniature the sender side is that it is then possible to present a miniature
"what you send" image on the display to help the user to target "what you send" image on the display to help the user to target
the camera correctly. the camera correctly.
Several of the existing standards ([H.263], [H.264] and [MPEG-4]) Several of the existing standards ([H.263], [H.264] and [MPEG-4])
have support for different resolutions at different framerates. The have support for different resolutions at different framerates. The
purpose of this document is to provide for a generic mechanism and is purpose of this document is to provide for a generic mechanism and is
targeted mainly at the negotiation of the image size but to make it targeted mainly at the negotiation of the image size but to make it
more general the attribute is named 'imageattr'. more general the attribute is named 'imageattr'.
This document is limited to unicast scenarios in general and more This document is limited to point-to-point unicast communication
specific point-to-point communication. The attribute may be used in scenarios. The attribute may be used in centralized conferencing
centralized conferencing scenarios as well but due to the abundance scenarios as well but due to the abundance of configuration options
of configuration options it may then be difficult to come up with a it may then be difficult to come up with a configuration that fits
configuration that fits all parties. all parties.
1.1. Requirements 1.1. Requirements
The design of the image attribute is based on the following The design of the image attribute is based on the following
requirements which are listed only for informational purposes: requirements which are listed only for informational purposes:
REQ-1: Support the indication of one or more set(s) of image REQ-1: Support the indication of one or more set(s) of image
attributes that the SDP endpoint wish to receive or send. Each attributes that the SDP endpoint wish to receive or send. Each
image attribute set must include a specific image size. image attribute set must include a specific image size.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
3.1.1. Overall view of syntax 3.1.1. Overall view of syntax
The syntax for the image attribute is in ABNF [RFC5234]: The syntax for the image attribute is in ABNF [RFC5234]:
---- ----
image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" ) image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
1*WSP attr-list ) 1*WSP attr-list )
PT = 1*DIGIT / "*" PT = 1*DIGIT / "*"
attr-list = ( set *(1*WSP set) ) / "*" attr-list = ( set *(1*WSP set) ) / "*"
; WSP and DIGIT defined in [RFC5234]
---- ----
---- ----
set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]" set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]"
; x is the horizontal image size range (pixel count) ; x is the horizontal image size range (pixel count)
; y is the vertical image size range (pixel count) ; y is the vertical image size range (pixel count)
key-value = ( "sar=" srange ) key-value = ( "sar=" srange )
/ ( "par=" prange ) / ( "par=" prange )
/ ( "q=" qvalue ) / ( "q=" qvalue )
; Key-value MAY be extended with other keyword parameters. ; Key-value MAY be extended with other keyword
; At most one instance each of sar, par, or q in a set. ; parameters.
; At most one instance each of sar, par, or q
; allowed in a set.
; ;
; sar (sample aspect ratio) is the sample aspect ratio ; sar (sample aspect ratio) is the sample aspect ratio
; associated with the set (optional and MAY be ignored) ; associated with the set (optional,MAY be ignored)
; par (picture aspect ratio) is the allowed ratio ; par (picture aspect ratio) is the allowed
; between the display's x and y physical size (optional) ; ratio between the display's x and y physical
; q (optional with range [0.0..1.0], default value 0.5) ; size (optional)
is the preference for the given set, ; q (optional, range [0.0..1.0], default value 0.5)
a higher value means a higher preference ; is the preference for the given set,
; a higher value means a higher preference
---- ----
onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
; Digit between 1 and 9 ; Digit between 1 and 9
xyvalue = onetonine *5DIGIT xyvalue = onetonine *5DIGIT
; Digit between 1 and 9 which is ; Digit between 1 and 9 which is
; followed by 0 to 5 other digits ; followed by 0 to 5 other digits
step = xyvalue step = xyvalue
xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" ) xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" )
; Range between a lower and an upper value ; Range between a lower and an upper value
skipping to change at page 7, line 30 skipping to change at page 7, line 30
; A single value ; A single value
spvalue = ( "0" "." onetonine *3DIGIT ) spvalue = ( "0" "." onetonine *3DIGIT )
; Values between 0.1000 and 0.9999 ; Values between 0.1000 and 0.9999
/ ( onetonine "." 1*4DIGIT ) / ( onetonine "." 1*4DIGIT )
; Values between 1.0000 and 9.9999 ; Values between 1.0000 and 9.9999
srange = ( "[" spvalue 1*( "," spvalue ) "]" ) srange = ( "[" spvalue 1*( "," spvalue ) "]" )
; Discrete values separated by ','. ; Discrete values separated by ','.
; Each occurrence of spvalue MUST be ; Each occurrence of spvalue MUST be
; greater than the previous occurrence. ; greater than the previous occurrence.
/ ( "[" spvalue "-" spvalue "]" ) / ( "[" spvalue "-" spvalue "]" )
; Range between a lower and an upper level (inclusive). ; Range between a lower and an upper level (inclusive)
; The second occurence of spvalue MUST have a higher ; The second occurence of spvalue MUST have a higher
; value than the first ; value than the first
/ ( spvalue ) / ( spvalue )
; A single value ; A single value
prange = ( "[" spvalue "-" spvalue "]" ) prange = ( "[" spvalue "-" spvalue "]" )
; Range between a lower and an upper level (inclusive). ; Range between a lower and an upper level (inclusive)
; The second occurence of spvalue MUST have a higher ; The second occurence of spvalue MUST have a higher
; value than the first ; value than the first
qvalue = ( "0" "." 1*2DIGIT ) qvalue = ( "0" "." 1*2DIGIT )
/ ( "1" "." 1*2("0") ) / ( "1" "." 1*2("0") )
; Values between 0.00 and 1.00 ; Values between 0.00 and 1.00
---- ----
o The attribute typically contains a "send" and a "recv" keyword. o The attribute typically contains a "send" and a "recv" keyword.
These specify the preferences for the media once the session is These specify the preferences for the media once the session is
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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 conditioned that the payload type number differs.
Note that the attribute is associated to the codec(s), for
instance an SDP offer may specify payload type number 101 while
the answer may specify 102, this may make it troublesome to
specify a payload type number with the 'imageattr' attribute. In
such cases it is better to use a wild card (*).
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 9, line 44 skipping to change at page 9, line 51
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. The exception is if the offerer has expressed a
wild card (*) in the attribute list. wild card (*) in the attribute list.
* It is recommended that a high end device which sees no reason * It is recommended that a device which sees no reason to use the
to use the image attribute, anyway includes the attribute with image attribute, anyway includes the attribute with wild cards
wild cards (*) in the attribute lists for the send and recv (*) in the attribute lists for the send and recv directions.
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.
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.
skipping to change at page 10, line 30 skipping to change at page 10, line 37
* 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 on its own include an image attribute
in the answer. in the answer.
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 resort to other methods to determine the offerer SHOULD continue to process the answer as if this
appropriate image size. 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 usablel or acceptable, the offerer SHOULD of the entries are usable or acceptable, the offerer SHOULD
resort to other methods to determine the appropriate image resort to other methods to determine the appropriate image
size. In this case the offerer must also issue a new offer/ size. In this case the offerer must also issue a new offer/
answer without the image attribute to avoid misunderstandings answer without the image attribute to avoid misunderstandings
between offerer and answerer. between offerer and answerer. This will avoid the risk on
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 answerer MUST NOT then include 'imageattr' in the answer. The the rules in Section 3.1.1.2 require the attribute to be absent in
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".
For the above reasons it is RECOMMENDED that a high end device which For the above reasons it is RECOMMENDED that a device which sees no
sees no reason to use the image attribute, anyway includes the reason to use the image attribute, anyway includes the attribute with
attribute with wild cards (*) in the attribute lists for the send and wild cards (*) in the attribute lists for the send and recv
recv directions. directions.
3.2.2. Asymmetry 3.2.2. Asymmetry
While the image attribute supports asymmetry there are some While the image attribute supports asymmetry there are some
limitations to this. One important limitation is that the codec limitations to this. One important limitation is that the codec
being used can only support up to a given maximum resolution for a being used can only support up to a given maximum resolution for a
given profile level. given profile level.
As an example H.264 [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 12, line 18 skipping to change at page 12, line 31
parameter like: parameter like:
---- ----
a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
---- ----
Meaning that Alice can encode with any of the mentioned sample aspect Meaning that Alice can encode with any of the mentioned sample aspect
ratios, leaving to Bob to decide which one he prefers. ratios, leaving to Bob to decide which one he prefers.
3.2.5. SDPCapNeg support 3.2.5. SDPCapNeg support
The image attribute can be used within the SDP Capability Negotiation The image attribute can be used within the SDP Capability Negotiation
[SDPCapNeg] framework and its use is then specified using the [RFC5939] framework and its use is then specified using the "a=acap"
"a=acap" parameter. An example is parameter. An example is
---- ----
a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
---- ----
For use with SDP Media Capability Negotiation extension For use with SDP Media Capability Negotiation extension
[SDPMedCapNeg], where it is no longer possible to specify payload [SDPMedCapNeg], where it is no longer possible to specify payload
type numbers, it is possible to use the parameter substitution rule, type numbers, it is possible to use the parameter substitution rule,
an example of this is. an example of this is.
---- ----
... ...
a=mcap:1 video H264/90000 a=mcap:1 video H264/90000
a=acap:1 imageattr:%1% send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] a=acap:1 imageattr:%1% send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
... ...
---- ----
Where %1% maps to media capability number 1. Where %1% maps to media capability number 1.
It is also possible to use the a=mscap attribute like in the example
below.
----
...
a=mcap:1 video H264/90000
a=mscap:1 imageattr send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
...
----
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. they define image-size related information. Section Section 3.2.6.4
outlines a few recommended solutions
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 24 skipping to change at page 14, line 50
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
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.
Note that according to [RFC3264], a port number of zero means that
the whole media line is rejected meaning that a new offer for the
same port number should be treated as a completely new stream and
not as an update. The most safe way to solve this problem is to
use preconditions, this is however outside the scope of this
document.
3.2.7. Change of display in middle of session 3.2.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 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.8. Use with layered codecs 3.2.8. 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 cause some concern. If the layers are transported in
different RTP streams the layers are specified on different media different RTP streams the layers are specified on different media
descriptions and the relation is specified using the grouping descriptions and the relation is specified using the grouping
framework [RFC3388] 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.9. Addition of parameters 3.2.9. Addition of parameters
The image attribute allows for the addition of parameters in the The image attribute allows for the addition of parameters in the
future. To make backwards adaptation possible; an entity that future. To make backwards adaptation possible; an entity that
processes the attribute MUST remove parameters that are not processes the attribute MUST ignore any unknown parameters in the
recognized before returning the attribute in the SDP answer. offer and MUST NOT include them in the answer it generates. Addition
Addition of future parameters that are not understood by the of future parameters that are not understood by the receiving
receiving endpoint may lead to ambiguities if mutual dependencies endpoint may lead to ambiguities if mutual dependencies between
between parameters exist, therefore addition of parameters must be parameters exist, therefore addition of parameters must be done with
done with great care. great care.
4. Examples 4. Examples
This section gives some more information on how to use the attribute This section gives some more information on how to use the attribute
by means of a high-level example and a few detailed examples. by means of a high-level example and a few detailed examples.
4.1. A High-Level Example 4.1. A High-Level Example
Assume that Alice wishes to set up a session with Bob and that Alice Assume that Alice wishes to set up a session with Bob and that Alice
takes the first initiative. The syntactical white-space delimiters takes the first initiative. The syntactical white-space delimiters
skipping to change at page 15, line 48 skipping to change at page 16, line 32
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 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. contain just one or two alternatives.
If Bob does not support any x and y resolution in any of of the X and If Bob does not support any x and y resolution in one of the provided
Y ranges given in the send attr-list or in the recv attr-list, the send or recv ranges given in the send attr-list or in the recv attr-
corresponding part is removed completely. In this case the answer list, the corresponding part is removed completely. For instance, if
from Bob would look like: Bob doesn't support any of the offered alternatives in the recv attr-
list in the offer, the answer from Bob would look like:
---- ----
a=imageattr:PT recv attr-list a=imageattr:PT recv attr-list
---- ----
In the above example none of the offered alternatives in the recv
attr-list was supported. Again it is worth notice that the attr-list
for each direction is likely pruned depending on preferred and
supported options.
4.2. Detailed Examples 4.2. Detailed Examples
This section gives a few detailed examples, it is assumed where This section gives a few detailed examples, it is assumed where
needed that Alice initiates a session with Bob needed that Alice initiates a session with Bob
4.2.1. Example 1 4.2.1. Example 1
Two image resolution alternatives are offered with 800x640 with Two image resolution alternatives are offered with 800x640 with
sar=1.1 having the highest preference sar=1.1 having the highest preference
skipping to change at page 17, line 37 skipping to change at page 18, line 16
steps and 176 to 208 in 8 pixels steps. The par parameter limits the steps and 176 to 208 in 8 pixels steps. The par parameter limits the
set of possible x and y screen resolution combinations such that set of possible x and y screen resolution combinations such that
800x640 (ratio=1.25) is a valid combination while 720x608 800x640 (ratio=1.25) is a valid combination while 720x608
(ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations. (ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations.
For the recv direction (Bob->Alice) Bob is requested to provide with For the recv direction (Bob->Alice) Bob is requested to provide with
a list of supported image sizes a list of supported image sizes
4.2.3. Example 3 4.2.3. Example 3
In this example a complete SDP offer is defined. In this example a more of the SDP offer is shown.
---- ----
m=video 49154 RTP/AVP 99 m=video 49154 RTP/AVP 99
a=rtpmap:99 H264/90000 a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \ a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \
sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 \ a=imageattr:99 \
send [x=176,y=144] [x=224,y=176] [x=272,y=224] [x=320,y=240] \ send [x=176,y=144] [x=224,y=176] [x=272,y=224] [x=320,y=240] \
recv [x=176,y=144] [x=224,y=176] [x=272,y=224,q=0.6] [x=320,y=240] recv [x=176,y=144] [x=224,y=176] [x=272,y=224,q=0.6] [x=320,y=240]
---- ----
skipping to change at page 18, line 35 skipping to change at page 19, line 16
This example illustrates in more detail how compensation for This example illustrates in more detail how compensation for
different sample aspect ratios can be negotiated with the image different sample aspect ratios can be negotiated with the image
attribute. attribute.
We set up a session between Alice and Bob, Alice is the offerer of We set up a session between Alice and Bob, Alice is the offerer of
the session. The offer (from Alice) contains the image attribute the session. The offer (from Alice) contains the image attribute
below: below:
---- ----
a=imageattr:97 \ a=imageattr:97 \
send [sar=[1.0-1.3],x=400:16:800],y=[320:16:640],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 [sar=1.1,x=800,y=600] 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 wish 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 wish 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 [sar=1.15,x=464,y=384] \ recv [x=464,y=384,sar=1.15] \
send [sar=1.1,x=800,y=600] 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), Neither part is required to rescale like this (sar may be ignored),
the consequence will of course be a distorted image. the consequence will of course be a distorted image.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 20, line 14 skipping to change at page 20, line 41
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the people who has contributed with The authors would like to thank the people who has contributed with
objections and suggestions to this draft and provided with valuable objections and suggestions to this draft and provided with valuable
guidance in the amazing video-coding world. Special thanks go to guidance in the amazing video-coding world. Special thanks go to
Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing.
8. Changes 8. Changes
Note to RFC Editor: please replace remove this section in its
entirety before publication.
The main changes are: The main changes are:
From WG -05 to WG -06 & -07
* Update based on AD review comments, no changes to fix issue
related to RFC2119 keywords
* Minor editorial changes
* Added extra example to use of attribute with SDPCapNeg
From WG -04 to WG -05 From WG -04 to WG -05
* Review based on WGLC comments * Review based on WGLC comments
* ABNF improved * ABNF improved
* Change use of RFC2119 keywords (MUST, SHOULD, MAY) to lowercase * Change use of RFC2119 keywords (MUST, SHOULD, MAY) to lowercase
in some sections in some sections
* Clarification on the directions send and recv in sendrecv, * Clarification on the directions send and recv in sendrecv,
skipping to change at page 21, line 36 skipping to change at page 22, line 28
9.1. Normative References 9.1. 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.
[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.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009. RFC 5583, July 2009.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
9.2. Informative References 9.2. Informative References
[H.263] ITU-T, "ITU-T Recommendation H.263 (2005): "Video coding [H.263] ITU-T, "ITU-T Recommendation H.263 (2005): "Video coding
for low bit rate communication"". for low bit rate communication"".
[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"".
skipping to change at page 22, line 28 skipping to change at page 23, line 17
Streams", RFC 3016, November 2000. Streams", RFC 3016, November 2000.
[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/".
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
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.
[SDPCapNeg] [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
IETF, "SDP Capability Negotiation, http://tools.ietf.org/ Capability Negotiation", RFC 5939, September 2010.
wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation".
[SDPMedCapNeg] [SDPMedCapNeg]
IETF, "SDP media capabilities Negotiation, http:// IETF, "SDP media capabilities Negotiation, http://
tools.ietf.org/wg/mmusic/ tools.ietf.org/wg/mmusic/
draft-ietf-mmusic-sdp-media-capabilities". draft-ietf-mmusic-sdp-media-capabilities".
Authors' Addresses Authors' Addresses
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
 End of changes. 40 change blocks. 
79 lines changed or deleted 110 lines changed or added

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