draft-ietf-mmusic-image-attributes-09.txt   draft-ietf-mmusic-image-attributes-10.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: May 29, 2011 Samsung Electronics Co., Ltd. Expires: June 18, 2011 Samsung Electronics Co., Ltd.
Nov 25, 2010 Dec 15, 2010
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-09 draft-ietf-mmusic-image-attributes-10
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 May 29, 2011. This Internet-Draft will expire on June 18, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Considerations . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. No imageattr in 1st offer . . . . . . . . . . . . . . 11 3.2.1. No imageattr in 1st offer . . . . . . . . . . . . . . 11
3.2.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Different payload type numbers in offer and answer . . 11
3.2.3. sendonly and recvonly . . . . . . . . . . . . . . . . 11 3.2.3. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 12 3.2.4. sendonly and recvonly . . . . . . . . . . . . . . . . 12
3.2.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 12 3.2.5. Sample aspect ratio . . . . . . . . . . . . . . . . . 13
3.2.6. Interaction with codec parameters . . . . . . . . . . 13 3.2.6. SDPCapNeg support . . . . . . . . . . . . . . . . . . 13
3.2.7. Change of display in middle of session . . . . . . . . 15 3.2.7. Interaction with codec parameters . . . . . . . . . . 14
3.2.8. Use with layered codecs . . . . . . . . . . . . . . . 15 3.2.8. Change of display in middle of session . . . . . . . . 16
3.2.9. Addition of parameters . . . . . . . . . . . . . . . . 15 3.2.9. Use with layered codecs . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.10. Addition of parameters . . . . . . . . . . . . . . . . 16
4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 15 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 16 4.1. A High-Level Example . . . . . . . . . . . . . . . . . . . 16
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Detailed Examples . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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 5, line 33 skipping to change at page 5, line 33
3. Specification of the 'imageattr' SDP Attribute 3. Specification of the 'imageattr' SDP Attribute
This section defines the SDP image attribute 'imageattr', which can This section defines the SDP image attribute 'imageattr', which can
be used in an SDP Offer/Answer exchange to indicate various image be used in an SDP Offer/Answer exchange to indicate various image
attribute parameters. In this document, we define the following attribute parameters. In this document, we define the following
image attribute parameters: image resolution, sample aspect ratio image attribute parameters: image resolution, sample aspect ratio
(sar), allowed range in picture aspect ratio (par) and the preference (sar), allowed range in picture aspect ratio (par) and the preference
of a given parameter set over another (q). The attribute is of a given parameter set over another (q). The attribute is
extensible and guidelines for defining additional parameters are extensible and guidelines for defining additional parameters are
provided in Section 3.2.9. provided in Section 3.2.10.
3.1. Attribute syntax 3.1. Attribute syntax
In this section the syntax of the 'imageattr' attribute is described. In this section the syntax of the 'imageattr' attribute is described.
The 'imageattr' attribute is a media-level attribute. The section is The 'imageattr' attribute is a media-level attribute. The section is
split up in two parts, the first gives an overall view of the syntax split up in two parts, the first gives an overall view of the syntax
while the second describes how the syntax is used. while the second describes how the syntax is used.
3.1.1. Overall view of syntax 3.1.1. Overall view of syntax
skipping to change at page 7, line 15 skipping to change at page 7, line 15
---- ----
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
; with an optional step, default step = 1 ; with an optional step, default step = 1
; The rightmost occurence of xyvalue MUST have a ; The rightmost occurrence of xyvalue MUST have a
; higher value than the leftmost occurence. ; higher value than the leftmost occurrence.
/ ( "[" xyvalue 1*( "," xyvalue ) "]" ) / ( "[" xyvalue 1*( "," xyvalue ) "]" )
; Discrete values separated by ',' ; Discrete values separated by ','
/ ( xyvalue ) / ( xyvalue )
; 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 occurrence 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 occurrence 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
set up, in the send and receive direction respectively from the set up, in the send and receive direction respectively from the
point of view of the sender of the session description. point of view of the sender of the session description. One of
the keywords ("send" or "recv") MAY be omitted, see Section 3.2.4
and Section 3.2.2 for a description of cases when this may be
appropriate.
o The "send" keyword and corresponding attribute list (attr-list) o The "send" 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 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 * to indicate that o PT is the payload type number, it MAY be set to "*" (wild card) to
the attribute applies to all payload types in the media indicate that the attribute applies to all payload types in the
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. 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. recv directions are present in the SDP.
o For sendonly or recvonly streams one of the directions MAY be
omitted. See Section 3.2.3.
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 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. The specify a payload type number with the 'imageattr' attribute. See
only solution that works in this case is to use a wild card (*) Section 3.2.2 for a discussion and recommendation how this is
and thus specify that the image attribute applies to all codecs in solved.
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 9, line 12 skipping to change at page 9, line 12
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
a given sample aspect ratio. a given sample aspect ratio.
See Section 3.2.4 for a more detailed discussion. See Section 3.2.5 for a more detailed discussion.
The sar parameter will likely not solve all the issues that are The sar parameter will likely not solve all the issues that are
related to different sample aspect ratios but it can help to solve related to different sample aspect ratios but it can help to solve
them and reduce aspect ratio distortion. them and reduce aspect ratio distortion.
The response MUST NOT include a sar parameter if there is no The response MUST NOT include a sar parameter if there is no
acceptable value given. The reason to this is that if the acceptable value given. The reason to this is that if the
response includes a sar parameter it is interpreted as "sar response includes a sar parameter it is interpreted as "sar
parameter accepted" while removal of the sar parameter is treated parameter accepted" while removal of the sar parameter is treated
as "sar parameter not accepted", for this reason it is safer to as "sar parameter not accepted", for this reason it is safer to
remove an unacceptable sar parameter altogether. remove an unacceptable sar parameter altogether.
skipping to change at page 11, line 16 skipping to change at page 11, line 16
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 wild carded 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 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. Asymmetry 3.2.2. Different payload type numbers in offer and answer
In some cases the answer may pick a different media payload type
number than the offer. As an example the offer SDP may have the
m-line
----
m=video 49154 RTP/AVP 99
----
While the answer SDP may have the m-line
----
m=video 49154 RTP/AVP 100
----
If the image attribute in the offer specifies payload type number 99,
this attribute will then have no meaning in the answerers receive
direction as the m-line specifies media payload type number 100.
There are a few ways to solve this
1. Use a wild card "*" as payload type number in the image attribute
in the offer SDP. The answer SDP also use the wild card. The
drawback with this approach is that this attribute then applies
to all payload type numbers in the media description.
2. Specify a wild card "*" as payload type number in the image
attribute in the answer SDP. The offer SDP may contain a defined
payload type number in the image attribute but the answer SDP
replaces this with a wild card. The drawback here is similar to
what is listed above.
3. The image attribute is split in two parts in the SDP answer. For
example the offer SDP (only the parts of interest in this
discussion) looks like:
----
m=video 49154 RTP/AVP 99
a=imageattr:99 send ... recv ...
----
The answer SDP looks like:
----
m=video 49154 RTP/AVP 100
a=imageattr:99 send ...
a=imageattr:100 recv ...
----
This alternative does not pose any drawbacks. Moreover it allows
to specify different image attributes if more than one payload
type is specified in the offer SDP.
Of the alternatives listed above, the last one is RECOMMENDED to be
used if the media payload type number changes in the SDP answer.
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
that the same profile level must be used in both directions. This that the same profile level must be used in both directions. This
means that in an asymmetric scenario where Alice wants an image size means that in an asymmetric scenario where Alice wants an image size
of 580x360 and Bob wants 150x120, profile level 2.2 is needed in both of 580x360 and Bob wants 150x120, profile level 2.2 is needed in both
directions even though profile level 1 would have been sufficient in directions even though profile level 1 would have been sufficient in
one direction. one direction.
Currently, the only solution to this problem is to specify two Currently, the only solution to this problem is to specify two
unidirectional media descriptions. Note however that the asymmetry unidirectional media descriptions. Note however that the asymmetry
issue for the H.264 codec is solved by means of the level-asymmetry- issue for the H.264 codec is solved by means of the level-asymmetry-
allowed parameter in [RFC3984bis]. allowed parameter in [RFC3984bis].
3.2.3. sendonly and recvonly 3.2.4. sendonly and recvonly
If the directional attributes a=sendonly or a=recvonly are given for If the directional attributes a=sendonly or a=recvonly are given for
a medium, there is of course no need to specify the image attribute a medium, there is of course no need to specify the image attribute
for both directions. Therefore one of the directions in the for both directions. Therefore one of the directions in the
attribute may be omitted. However it may be good to do the image attribute may be omitted. However it may be good to do the image
attribute negotiation in both directions in case the session is attribute negotiation in both directions in case the session is
updated for media in both directions at a later stage. updated for media in both directions at a later stage.
3.2.4. Sample aspect ratio 3.2.5. Sample aspect ratio
The relationship between the sar parameter and the x and y pixel The relationship between the sar parameter and the x and y pixel
resolution deserves some extra discussion. Consider the offer from resolution deserves some extra discussion. Consider the offer from
Alice to Bob (we set the recv direction aside for the moment): Alice to Bob (we set the recv direction aside for the moment):
---- ----
a=imageattr:97 send [x=720,y=576,sar=1.1] a=imageattr:97 send [x=720,y=576,sar=1.1]
---- ----
If the receiver display has square pixels the 720x576 image would If the receiver display has square pixels the 720x576 image would
need to be rescaled to for example 792x576 or 720x524 to ensure a need to be rescaled to for example 792x576 or 720x524 to ensure a
correct image aspect ratio. This in practice means that rescaling correct image aspect ratio. This in practice means that rescaling
would need to be performed on the receiver side, something that is would need to be performed on the receiver side, something that is
contrary to the spirit of this draft. contrary to the spirit of this draft.
To avoid this problem Alice may specify a range of values for the sar To avoid this problem Alice may specify a range of values for the sar
parameter like: parameter like:
---- ----
a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
---- ----
Meaning that Alice can encode with any of the mentioned sample aspect Meaning that Alice can encode with any of the mentioned sample aspect
ratios, leaving to Bob to decide which one he prefers. ratios, leaving to Bob to decide which one he prefers.
3.2.5. SDPCapNeg support 3.2.6. SDPCapNeg support
The image attribute can be used within the SDP Capability Negotiation The image attribute can be used within the SDP Capability Negotiation
[RFC5939] framework and its use is then specified using the "a=acap" [RFC5939] framework and its use is then specified using the "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
skipping to change at page 13, line 4 skipping to change at page 14, line 7
... ...
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 It is also possible to use the a=mscap attribute like in the example
below. below.
---- ----
... ...
a=mcap:1 video H264/90000 a=mcap:1 video H264/90000
a=mscap:1 imageattr send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] 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.7. 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 3.2.6.4 outlines they define image-size related information. Section 3.2.7.4 outlines
a few possible solutions, but this document does not make any a few possible solutions, but this document does not make any
recommendation for any of them. recommendation for any of them.
3.2.6.1. H.263 3.2.7.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
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.6.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 [RFC3984] and
updated 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
sizes need to be changed or added. sizes need to be changed or added.
3.2.6.3. MPEG-4 3.2.7.3. MPEG-4
The payload format for MPEG-4 [MPEG-4] is described in [RFC3016]. The payload format for MPEG-4 [MPEG-4] is described in [RFC3016].
MPEG-4 defines a config parameter on the fmtp line which is a MPEG-4 defines a config parameter on the fmtp line which is a
hexadecimal representation of the MPEG-4 visual configuration hexadecimal representation of the MPEG-4 visual configuration
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.7.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, listed below without any There are a number of possible solutions, listed below without any
preference: 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.
skipping to change at page 15, line 9 skipping to change at page 16, line 9
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 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 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 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 not as an update. The most safe way to solve this problem is to
use preconditions, this is however outside the scope of this use preconditions, this is however outside the scope of this
document. document.
3.2.7. Change of display in middle of session 3.2.8. 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.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 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 [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.9. Addition of parameters 3.2.10. 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 ignore any unknown parameters in the processes the attribute MUST ignore any unknown parameters in the
offer and MUST NOT include them in the answer it generates. Addition offer and MUST NOT include them in the answer it generates. Addition
of future parameters that are not understood by the receiving of future parameters that are not understood by the receiving
endpoint may lead to ambiguities if mutual dependencies between endpoint may lead to ambiguities if mutual dependencies between
parameters exist, therefore addition of parameters must be done with parameters exist, therefore addition of parameters must be done with
great care. great care.
skipping to change at page 18, line 23 skipping to change at page 19, line 23
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 more of the SDP offer is shown. In this example more of the SDP offer is shown. A complicating
factor is that the answerer changes the media payload type number in
the offer/answer exchange.
---- ----
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]
---- ----
In the send direction, sprop-parameter-sets is defined for a In the send direction, sprop-parameter-sets is defined for a
resolution of 320x240 which is the largest image size offered in the resolution of 320x240 which is the largest image size offered in the
send direction. This means that if 320x240 is selected, no send direction. This means that if 320x240 is selected, no
additional offer/answer is necessary. In the receive direction four additional offer/answer is necessary. In the receive direction four
alternative image sizes are offered with 272x224 being the preferred alternative image sizes are offered with 272x224 being the preferred
choice. choice.
The answer may look like: The answer may look like:
---- ----
m=video 49154 RTP/AVP 99 m=video 49154 RTP/AVP 100
a=rtpmap:99 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \ a=fmtp:100 packetization-mode=0;profile-level-id=42e011; \
sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240] a=imageattr:99 send [x=320,y=240]
a=imageattr:100 recv [x=320,y=240]
---- ----
Indicating (in this example) that the image size is 320x240 in both Indicating (in this example) that the image size is 320x240 in both
directions. Although the offerer preferred 272x224 for the receive directions. Although the offerer preferred 272x224 for the receive
direction, the answerer might not be able to offer 272x224 or not direction, the answerer might not be able to offer 272x224 or not
allow encoding and decoding of video of different image sizes allow encoding and decoding of video of different image sizes
simultaneously. The answerer sets new sprop-parameter-sets, simultaneously. The answerer sets new sprop-parameter-sets,
constructed for both send and receive directions at the restricted constructed for both send and receive directions at the restricted
conditions and image size of 320x240. conditions and image size of 320x240.
Note also that, because the payload type number is changed by the
answerer, the image attribute is also split in two parts according to
the recommendation in Section 3.2.2.
4.2.4. Example 4 4.2.4. Example 4
This example illustrates in more detail how compensation for This example illustrates in more detail how compensation for
different sample aspect ratios can be negotiated with the image different sample aspect ratios can be negotiated with the image
attribute. attribute.
We 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:
---- ----
skipping to change at page 20, line 42 skipping to change at page 21, line 48
This draft does not add any additional security issues other than This draft does not add any additional security issues other than
those already existing with currently specified offer/answer those already existing with currently specified offer/answer
procedures. procedures.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the people who has contributed with The authors would like to thank the people who has contributed with
objections and suggestions to this draft and provided with valuable objections and suggestions to this draft and provided with valuable
guidance in the amazing video-coding world. Special thanks go to guidance in the amazing video-coding world. Special thanks go to
Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Thanks also
to Robert Sparks and Paul Kyzivat for the help with the last fixes to
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 -09 to WG -10
* Further clarified the issue that offer and answer may use
different PT numbers, additional section added.
* 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
numbers numbers
* Clarified that wild cards in send and recv direction should be * Clarified that wild cards in send and recv direction should be
used with care and with total message size in mind used with care and with total message size in mind
* Typos and unclear language fixe * Typos and unclear language fixe
 End of changes. 35 change blocks. 
67 lines changed or deleted 132 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/