doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc6236.txt b/doc/rfc/rfc6236.txt
new file mode 100644
index 0000000..b6355be
--- /dev/null
+++ b/doc/rfc/rfc6236.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      I. Johansson
+Request for Comments: 6236                                   Ericsson AB
+Category: Standards Track                                        K. Jung
+ISSN: 2070-1721                            Samsung Electronics Co., Ltd.
+                                                                May 2011
+
+
+               Negotiation of Generic Image Attributes in
+                 the Session Description Protocol (SDP)
+
+Abstract
+
+   This document proposes a new generic session setup attribute to make
+   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-
+   held terminal to display video without the need to rescale the image,
+   something that may consume large amounts of memory and processing
+   power.  The document also helps to maintain an optimal bitrate for
+   video as only the image size that is desired by the receiver is
+   transmitted.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6236.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 1]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Specification of the 'imageattr' SDP Attribute . . . . . . . .  5
+     3.1.  Attribute Syntax . . . . . . . . . . . . . . . . . . . . .  5
+       3.1.1.  Overall View of Syntax . . . . . . . . . . . . . . . .  5
+     3.2.  Considerations . . . . . . . . . . . . . . . . . . . . . . 11
+       3.2.1.  No imageattr in First Offer  . . . . . . . . . . . . . 11
+       3.2.2.  Different Payload Type Numbers in Offer and Answer . . 11
+       3.2.3.  Asymmetry  . . . . . . . . . . . . . . . . . . . . . . 12
+       3.2.4.  sendonly and recvonly  . . . . . . . . . . . . . . . . 12
+       3.2.5.  Sample Aspect Ratio  . . . . . . . . . . . . . . . . . 13
+       3.2.6.  SDPCapNeg Support  . . . . . . . . . . . . . . . . . . 13
+       3.2.7.  Interaction with Codec Parameters  . . . . . . . . . . 14
+       3.2.8.  Change of Display in Middle of Session . . . . . . . . 16
+       3.2.9.  Use with Layered Codecs  . . . . . . . . . . . . . . . 16
+       3.2.10. Addition of Parameters . . . . . . . . . . . . . . . . 16
+   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     4.1.  A High-Level Example . . . . . . . . . . . . . . . . . . . 16
+     4.2.  Detailed Examples  . . . . . . . . . . . . . . . . . . . . 17
+       4.2.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . . 17
+       4.2.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . 18
+       4.2.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . . 19
+       4.2.4.  Example 4  . . . . . . . . . . . . . . . . . . . . . . 20
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 2]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+1.  Introduction
+
+   This document proposes a new SDP attribute to make it possible to
+   negotiate different image attributes, such as image size.  The term
+   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 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 other info.
+
+   Allowing negotiation of the image size provides a number of benefits:
+
+   o  Less image distortion: Rescaling of images introduces additional
+      distortion, something that can be avoided (at least on the
+      receiver side) if the image size can be negotiated.
+
+   o  Reduced receiver complexity: Image rescaling can be quite
+      computation intensive.  For low-end devices, this can be a
+      problem.
+
+   o  Optimal quality for the given bitrate: The sender does not need to
+      encode an entire CIF (352x288) image if only an image size of
+      288x256 is displayed on the receiver screen.
+
+   o  Memory requirement: The receiver device will know the size of the
+      image and can then allocate memory accordingly.
+
+   o  Optimal aspect ratio: The indication of the supported image sizes
+      and aspect ratio allows the receiver to select the most
+      appropriate combination based on its rescaling capabilities and
+      the desired rendering.  For example, if a sender proposes three
+      resolutions in its SDP offer (100x200, 200x100, and 100x100) with
+      sar=1.0 (1:1) etc., then the receiver can select the option that
+      fits the receiver screen best.
+
+   In cases where rescaling is not implemented (for example, rescaling
+   is not mandatory to implement in H.264 [H.264]), the indication of
+   the image attributes may still provide an optimal use of bandwidth
+   because the attribute will give the encoder a better indication about
+   what image size is preferred anyway and will thus help to avoid
+   wasting bandwidth by encoding with an unnecessarily large resolution.
+
+   For implementers that are considering rescaling issues, it is worth
+   noting that there are several benefits to doing it on the sender
+   side:
+
+   o  Rescaling on the sender/encoder side is likely to be easier to do
+      as the camera-related software/hardware already contains the
+
+
+
+Johansson & Jung             Standards Track                    [Page 3]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+      necessary functionality for zooming/cropping/trimming/sharpening
+      the video signal.  Moreover, rescaling is generally done in RGB or
+      YUV domains and should not depend on the codecs used.
+
+   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,
+      it does not know the receiver's performance or preference.
+
+   o  The quality drop due to digital domain rescaling using
+      interpolation is likely to be lower if it is done before the video
+      encoding rather than after the decoding especially when low
+      bitrate video coding is used.
+
+   o  If low-complexity rescaling operations such as simple cropping
+      must be performed, the benefit with having this functionality on
+      the sender side is that it is then possible to present a miniature
+      "what you send" image on the display to help the user to frame the
+      image correctly.
+
+   Several of the existing standards ([H.263], [H.264], and [MPEG-4])
+   have support for different resolutions at different framerates.  The
+   purpose of this document is to provide for a generic mechanism, which
+   is targeted mainly at the negotiation of the image size.  However, to
+   make it more general, the attribute is named 'imageattr'.
+
+   This document is limited to point-to-point unicast communication
+   scenarios.  The attribute may be used in centralized conferencing
+   scenarios as well but due to the abundance of configuration options,
+   it may then be difficult to come up with a configuration that fits
+   all parties.
+
+1.1.  Requirements
+
+   The design of the image attribute is based on the following
+   requirements, which are listed only for informational purposes:
+
+   REQ-1:  Support the indication of one or more set(s) of image
+      attributes that the SDP endpoint wishes to receive or send.  Each
+      image attribute set must include a specific image size.
+
+   REQ-2:  Support setup/negotiation of image attributes, meaning that
+      each side in the Offer/Answer should be able to negotiate the
+      image attributes it prefers to send and receive.
+
+   REQ-3:  Interoperate with codec-specific parameters such as sprop-
+      parameter-sets in [H.264] or config in [MPEG-4].
+
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 4]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   REQ-4:  Make the attribute generic with as few codec specific
+      details/tricks as possible in order to be codec agnostic.
+
+   Besides the above mentioned requirements, the requirement below may
+   be applicable.
+
+   OPT-1:  The image attribute should support the description of image-
+      related attributes for various types of media, including video,
+      pictures, images, etc.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Specification of the 'imageattr' SDP Attribute
+
+   This section defines the SDP image attribute 'imageattr', which can
+   be used in an SDP Offer/Answer exchange to indicate various image
+   attribute parameters.  In this document, we define the following
+   image attribute parameters: image resolution, sample aspect ratio
+   (sar), allowed range in picture aspect ratio (par) and the preference
+   of a given parameter set over another (q).  The attribute is
+   extensible and guidelines for defining additional parameters are
+   provided in Section 3.2.10.
+
+3.1.  Attribute Syntax
+
+   In this section, the syntax of the 'imageattr' attribute is
+   described.  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, and the second describes how the syntax is used.
+
+3.1.1.  Overall View of Syntax
+
+   The syntax for the image attribute is in ABNF [RFC5234]:
+
+       image-attr = "imageattr:" PT 1*2( 1*WSP ( "send" / "recv" )
+                                         1*WSP attr-list )
+       PT = 1*DIGIT / "*"
+       attr-list = ( set *(1*WSP set) ) / "*"
+         ;  WSP and DIGIT defined in [RFC5234]
+
+       set= "[" "x=" xyrange "," "y=" xyrange *( "," key-value ) "]"
+                  ; x is the horizontal image size range (pixel count)
+                  ; y is the vertical image size range (pixel count)
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 5]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+       key-value = ( "sar=" srange )
+                 / ( "par=" prange )
+                 / ( "q=" qvalue )
+                  ; Key-value MAY be extended with other keyword
+                  ;  parameters.
+                  ; At most, one instance each of sar, par, or q
+                  ;  is allowed in a set.
+                  ;
+                  ; sar (sample aspect ratio) is the sample aspect ratio
+                  ;  associated with the set (optional, MAY be ignored)
+                  ; par (picture aspect ratio) is the allowed
+                  ;  ratio between the display's x and y physical
+                  ;  size (optional)
+                  ; q (optional, range [0.0..1.0], default value 0.5)
+                  ;  is the preference for the given set,
+                  ;  a higher value means a higher preference
+
+       onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
+                  ; Digit between 1 and 9
+       xyvalue = onetonine *5DIGIT
+                  ; Digit between 1 and 9 that is
+                  ; followed by 0 to 5 other digits
+       step = xyvalue
+       xyrange = ( "[" xyvalue ":" [ step ":" ] xyvalue "]" )
+                  ; Range between a lower and an upper value
+                  ; with an optional step, default step = 1
+                  ; The rightmost occurrence of xyvalue MUST have a
+                  ; higher value than the leftmost occurrence.
+               / ( "[" xyvalue 1*( "," xyvalue ) "]" )
+                  ; Discrete values separated by ','
+               / ( xyvalue )
+                  ; A single value
+       spvalue = ( "0" "." onetonine *3DIGIT )
+                  ; Values between 0.1000 and 0.9999
+               / ( onetonine "." 1*4DIGIT )
+                  ; Values between 1.0000 and 9.9999
+       srange =  ( "[" spvalue 1*( "," spvalue ) "]" )
+                  ; Discrete values separated by ','.
+                  ; Each occurrence of spvalue MUST be
+                  ; greater than the previous occurrence.
+               / ( "[" spvalue "-" spvalue "]" )
+                  ; Range between a lower and an upper level (inclusive)
+                  ; The second occurrence of spvalue MUST have a higher
+                  ; value than the first
+               / ( spvalue )
+                  ; A single value
+
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 6]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+       prange =  ( "[" spvalue "-" spvalue "]" )
+                  ; Range between a lower and an upper level (inclusive)
+                  ; The second occurrence of spvalue MUST have a higher
+                  ; value than the first
+
+       qvalue  = ( "0" "." 1*2DIGIT )
+               / ( "1" "." 1*2("0") )
+                  ; Values between 0.00 and 1.00
+
+   o  The attribute typically contains a "send" and a "recv" keyword.
+      These specify the preferences for the media once the session is
+      set up, in the send and receive direction respectively from the
+      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)
+      MUST NOT occur more than once per image attribute.
+
+   o  The "recv" keyword and corresponding attribute list (attr-list)
+      MUST NOT occur more than once per image attribute.
+
+   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
+      media description.
+
+   o  For sendrecv streams, both of the send and recv directions SHOULD
+      be present in the SDP.
+
+   o  For inactive streams it is RECOMMENDED that both of the send and
+      recv directions are present in the SDP.
+
+3.1.1.1.  Parameter Rules
+
+   The following rules apply for the parameters.
+
+   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
+      specified for the payload type number to indicate that it applies
+      to all payload types in the media description.  Several image
+      attributes can be defined, for instance for different video codec
+      alternatives.  This however requires that the payload type numbers
+      differ.  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
+
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 7]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+      specify a payload type number with the 'imageattr' attribute.  See
+      Section 3.2.2 for a discussion and recommendation how this is
+      solved.
+
+   Preference (q):  The preference for each set is 0.5 by default;
+      setting the optional q parameter to another value makes it
+      possible to set different preferences for the sets.  A higher
+      value gives a higher preference for the given set.
+
+   sar:  The sar (storage aspect ratio) parameter specifies the sample
+      aspect ratio associated to the given range of x and y values.  The
+      sar parameter is defined as dx/dy where dx and dy are the physical
+      size of the pixels.  Square pixels gives a sar=1.0.  The parameter
+      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
+      assumed.
+
+      The interpretation of sar differs between the send and the receive
+      directions.
+
+      *  In the send direction, sar defines a specific sample aspect
+         ratio associated to a given x and y image size (range).
+
+      *  In the recv direction, sar expresses that the receiver of the
+         given medium prefers to receive a given x and y resolution with
+         a given sample aspect ratio.
+
+      See Section 3.2.5 for a more detailed discussion.
+
+      The sar parameter will likely not solve all the issues that are
+      related to different sample aspect ratios, but it can help to
+      solve them and reduce aspect ratio distortion.
+
+      The response MUST NOT include a sar parameter if there is no
+      acceptable value given.  The reason for this is that if the
+      response includes a sar parameter it is interpreted as "sar
+      parameter accepted", while removal of the sar parameter is treated
+      as "sar parameter not accepted".  For this reason, it is safer to
+      remove an unacceptable sar parameter altogether.
+
+   par:  The par (width/height = x/y ratio) parameter indicates a range
+      of allowed ratios between x and y physical size (picture aspect
+      ratio).  This is used to limit the number of x and y image size
+      combinations; par is given as
+
+       par=[ratio_min-ratio_max]
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 8]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   where ratio_min and ratio_max are the min and max allowed picture
+   aspect ratios.
+
+   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 and y
+   pixel resolution and the physical size of the image is
+   straightforward.  If however sar differs from the sample aspect ratio
+   of the receiver display, this must be taken into consideration when
+   the x and y pixel resolution alternatives are sorted out.  See
+   Section 4.2.4 for an example of this.
+
+3.1.1.2.  Offer/Answer Rules
+
+   In accordance with [RFC3264], offer/answer exchange of the image
+   attribute is as follows.
+
+   o  Offerer sending the offer:
+
+      *  The offerer must be able to support the image attributes that
+         it offers, unless the offerer has expressed a wild card (*) in
+         the attribute list.
+
+      *  It is recommended that a device that sees no reason to use the
+         image attribute includes the attribute with wild cards (*) in
+         the attribute lists anyway for the send and recv directions.
+         An example of this looks like:
+
+          a=imageattr:97 send * recv *
+
+   This gives the answerer the possibility of expressing its
+   preferences.  The use of wild cards introduces a risk that the
+   message size can increase in an uncontrolled way.  To reduce this
+   risk, these wild cards SHOULD only be replaced by an as small set as
+   possible.
+
+   o  Answerer receiving the offer and sending the answer:
+
+      *  The answerer may choose to keep the image attribute but is not
+         required to do so.
+
+      *  The answerer may, for its receive and send direction, include
+         one or more entries that it can support from the set of entries
+         proposed in the offer.
+
+      *  The answerer may also, for its receive and send direction,
+         replace the entries with a complete new set of entries
+         different from the original proposed by the offerer.  The
+
+
+
+
+Johansson & Jung             Standards Track                    [Page 9]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+         implementor of this feature should however be aware that this
+         may cause extra offer/answer exchanges.
+
+      *  The answerer may also remove its send direction completely if
+         it is deemed that it cannot support any of the proposed
+         entries.
+
+      *  The answerer should not include an image attribute in the
+         answer if it was not present in the offer.
+
+   o  Offerer receiving the answer:
+
+      *  If the image attribute is not included in the SDP answer the
+         offerer SHOULD continue to process the answer as if this
+         mechanism had not been offered.
+
+      *  If the image attribute is included in the SDP answer but none
+         of the entries are usable or acceptable, the offerer MUST
+         resort to other methods to determine the appropriate image
+         size.  In this case, the offerer must also issue a new offer/
+         answer without the image attribute to avoid misunderstandings
+         between the offerer and answerer.  This will avoid the risk of
+         infinite negotiations.
+
+3.2.  Considerations
+
+3.2.1.  No imageattr in First Offer
+
+   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 answer.  The reasons for this are:
+
+   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
+      mind that Section 3.1.1 recommends that the offerer provide the
+      attribute with wild carded parameters if it has no preference.
+
+   o  Inclusion of the image attribute in the answer may come in
+      conflict with the rules in Section 3.1.1.2, especially the rules
+      that apply to "offerer receiving the answer".
+
+   For the above reasons, it is RECOMMENDED that a device that sees no
+   reason to use the image attribute includes the attribute with wild
+   cards (*) in the attribute lists anyway for the send and recv
+   directions.
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 10]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+3.2.2.  Different Payload Type Numbers in Offer and Answer
+
+   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
+   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 the payload type number in the image
+       attribute in the offer SDP.  The answer SDP also uses 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 the 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
+   specification of different image attributes if more than one payload
+   type is specified in the offer SDP.
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 11]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   Of the alternatives listed above, the last one MUST be used as it is
+   the most safe.  The other alternatives MUST NOT be used.
+
+3.2.3.  Asymmetry
+
+   While the image attribute supports asymmetry, there are some
+   limitations.  One important limitation is that the codec being used
+   can only support up to a given maximum resolution for a given profile
+   level.
+
+   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
+   that the same profile level must be used in both directions.  This
+   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
+   directions even though profile level 1 would have been sufficient in
+   one direction.
+
+   Currently, the only solution to this problem is to specify two
+   unidirectional media descriptions.  Note however that the asymmetry
+   issue for the H.264 codec is solved by means of the level-asymmetry-
+   allowed parameter in [RFC6184].
+
+3.2.4.  sendonly and recvonly
+
+   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
+   for both directions.  Therefore, one of the directions in the
+   attribute may be omitted.  However, it may be good to do the image
+   attribute negotiation in both directions in case the session is
+   updated for media in both directions at a later stage.
+
+3.2.5.  Sample Aspect Ratio
+
+   The relationship between the sar parameter and the x and y pixel
+   resolution deserves some extra discussion.  Consider the offer from
+   Alice to Bob (we set the recv direction aside for the moment):
+
+       a=imageattr:97 send [x=720,y=576,sar=1.1]
+
+   If the receiver display has square pixels, the 720x576 image would
+   need to be rescaled to for example 792x576 or 720x524 to ensure a
+   correct image aspect ratio.  This in practice means that rescaling
+   would need to be performed on the receiver side, something that is
+   contrary to the spirit of this document.
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 12]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   To avoid this problem Alice may specify a range of values for the sar
+   parameter like:
+
+       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
+   ratios, leaving Bob to decide which one he prefers.
+
+3.2.6.  SDPCapNeg Support
+
+   The image attribute can be used within the SDP Capability Negotiation
+   [RFC5939] framework and its use is then specified using the "a=acap"
+   parameter.  An example is
+
+       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
+   [SDPMedCapNeg], where it is no longer possible to specify payload
+   type numbers, it is possible to use the parameter substitution rule,
+   an example of this is
+
+      ...
+      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]]
+      ...
+
+   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.7.  Interaction with Codec Parameters
+
+   As the SDP for most codecs already specifies some kind of indication
+   of, for example, the image size, at session setup, measures must be
+   taken to avoid conflicts between the image attribute and this already
+   existing information.
+
+   The following subsections describe the most well known codecs and how
+   they define image-size related information.  Section 3.2.7.4 outlines
+   a few possible solutions, but this document does not make a
+   recommendation for any of them.
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 13]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+3.2.7.1.  H.263
+
+   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
+   maximum frame rates (profiles) that the offerer can receive.  The
+   answerer is not allowed to modify this list and must reject a payload
+   type that contains an unsupported profile.  The CUSTOM profile may be
+   used for image size negotiation but support for asymmetry requires
+   the specification of two unidirectional media descriptions using the
+   sendonly/recvonly attributes.
+
+3.2.7.2.  H.264
+
+   The payload format for H.264 [H.264] is described in [RFC6184].
+
+   H.264 defines information related to image size in the fmtp line by
+   means of sprop-parameter-sets.  According to the specification,
+   several sprop-parameter-sets may be defined for one payload type.
+   The sprop-parameter-sets describe the image size (+ more) that the
+   offerer sends in the stream and need not be complete.  This means
+   that sprop-parameter-sets does not represent any negotiation and the
+   answer is not allowed to change the sprop-parameter-sets.
+
+   This configuration may be changed later inband if for instance image
+   sizes need to be changed or added.
+
+3.2.7.3.  MPEG-4
+
+   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
+   hexadecimal representation of the MPEG-4 visual configuration
+   information.  This configuration does not represent any negotiation
+   and the answer is not allowed to change the parameter.
+
+   It is not possible to change the configuration using inband
+   signaling.
+
+3.2.7.4.  Possible Solutions
+
+   The subsections above clearly indicate that this kind of information
+   must be aligned well with the image attribute to avoid conflicts.
+   There are a number of possible solutions, listed below without any
+   preference:
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 14]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   o  Ignore payload format parameters: This may not work well in the
+      presence of bad channel conditions especially in the beginning of
+      a session.  Moreover, this is not a good option for MPEG-4.
+
+   o  Second session-wide offer/answer round: In the second offer/
+      answer, the parameters specific to codec payload format are
+      defined based on the outcome of the 'imageattr' negotiation.  The
+      drawback with this is that setup of the entire session (including
+      audio) may be delayed considerably, especially as the 'imageattr'
+      negotiation can already itself cost up to two offer/answer rounds.
+      Also, the conflict between the 'imageattr' negotiation and the
+      parameters specific to payload format is still present after the
+      first offer/answer round and a fuzzy/buggy implementation may
+      start media before the second offer/answer is completed with
+      unwanted results.
+
+   o  Second session-wide offer/answer round only for video: This is
+      similar to the alternative above with the exception that setup
+      time for audio is not increased; moreover, the port number for
+      video is set to 0 during the first offer answer round to avoid the
+      flow of media.
+
+      This has the effect that video will blend in some time after the
+      audio is started (up to 2 seconds delay).  This alternative is
+      likely the most clean-cut and failsafe.  The drawback 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 have been
+      possible to start media after the first offer/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 safest way to solve this problem is to use
+      preconditions; this is however outside the scope of this document.
+
+3.2.8.  Change of Display in Middle of Session
+
+   A very likely scenario is that a user switches to another phone
+   during a video telephony call or plugs a cellphone into an external
+   monitor.  In both cases, it is very likely that a renegotiation is
+   initiated using the SIP-REFER [RFC3515] or SIP-UPDATE [RFC3311]
+   methods.  It is RECOMMENDED to negotiate the image size during this
+   renegotiation.
+
+
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 15]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+3.2.9.  Use with Layered Codecs
+
+   As the image attribute is a media-level attribute, its use with
+   layered codecs causes some concern.  If the layers are transported in
+   different RTP streams, the layers are specified on different media
+   descriptions, and the relation is specified using the grouping
+   framework [RFC5888] and the depend attribute [RFC5583].  As it is not
+   possible to specify only one image attribute for several media
+   descriptions the solution is either to specify the same image
+   attribute for each media description, or to only specify the image
+   attribute for the base layer.
+
+3.2.10.  Addition of Parameters
+
+   The image attribute allows for the addition of parameters in the
+   future.  To make backwards adaptation possible, an entity that
+   processes the attribute MUST ignore any unknown parameters in the
+   offer and MUST NOT include them in the answer it generates.  Addition
+   of future parameters that are not understood by the receiving
+   endpoint may lead to ambiguities if mutual dependencies between
+   parameters exist; therefore, addition of parameters must be done with
+   great care.
+
+4.  Examples
+
+   This section gives some more information on how to use the attribute
+   by means of a high-level example and a few detailed examples.
+
+4.1.  A High-Level Example
+
+   Assume that Alice wishes to set up a session with Bob and that Alice
+   takes the first initiative.  The syntactical white-space delimiters
+   (1*WSP) and double-quotes are removed to make reading easier.
+
+   In the offer, Alice provides information for both the send and
+   receive (recv) directions.  For the send direction, Alice provides a
+   list that the answerer can select from.  For the receive direction,
+   Alice may either specify a desired image size range right away or a *
+   to instruct Bob to reply with a list of image sizes that Bob can
+   support for sending.  Using the overall high level syntax the image
+   attribute may then look like
+
+       a=imageattr:PT send attr-list recv attr-list
+
+   or
+
+       a=imageattr:PT send attr-list recv *
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 16]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   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
+   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
+   ranges given in the send attr-list and in the recv attr-list of the
+   offer, the answer from Bob will look like:
+
+       a=imageattr:PT send attr-list recv attr-list
+
+   and the offer/answer negotiation is done.  Note 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 just
+   one or two alternatives.
+
+   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-
+   list, the corresponding part is removed completely.  For instance, if
+   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
+
+4.2.  Detailed Examples
+
+   This section gives a few detailed examples.  It is assumed where
+   needed that Alice initiates a session with Bob.
+
+4.2.1.  Example 1
+
+   Two image resolution alternatives are offered with 800x640 with
+   sar=1.1 having the highest preference.
+
+   It is also indicated that Alice wishes to display video with a
+   resolution of 330x250 on her display.
+
+    a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
+                   recv [x=330,y=250]
+
+   In case Bob accepts the "recv [x=330,y=250]", the answer may look
+   like
+
+    a=imageattr:97 recv [x=800,y=640,sar=1.1] \
+                   send [x=330,y=250]
+
+   indicating that the receiver (Bob) wishes the encoder (on Alice's
+   side) to compensate for a sample aspect ratio of 1.1 (11:10) and
+   desires an image size on its screen of 800x640.
+
+
+
+Johansson & Jung             Standards Track                   [Page 17]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   There is however a possibility that "recv [x=330,y=250]" is not
+   supported.  If the case, Bob may completely remove this part or
+   replace it with a list of supported image sizes.
+
+    a=imageattr:97 recv [x=800,y=640,sar=1.1] \
+                   send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]]
+
+   Alice can then select a valid image size that is closest to the one
+   that was originally desired (336x256) and performs a second offer/
+   answer.
+
+    a=imageattr:97 send [x=800,y=640,sar=1.1] \
+                   recv [x=336,y=256]
+
+   Bob replies with:
+
+    a=imageattr:97 recv [x=800,y=640,sar=1.1] \
+                   send [x=336,y=256]
+
+4.2.2.  Example 2
+
+   Two image resolution sets are offered with the first having a higher
+   preference (q=0.6).
+
+    a=imageattr:97 \
+      send [x=[480:16:800],y=[320:16:640],par=[1.2-1.3],q=0.6] \
+           [x=[176:8:208],y=[144:8:176],par=[1.2-1.3]] \
+      recv *
+
+   The x-axis resolution can take the values 480 to 800 in 16 pixels
+   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
+   800x640 (ratio=1.25) is a valid combination while 720x608
+   (ratio=1.18) or 800x608 (ratio=1.31) are invalid combinations.
+
+   For the recv direction (Bob->Alice), Bob is requested to provide a
+   list of supported image sizes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 18]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+4.2.3.  Example 3
+
+   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
+    a=rtpmap:99 H264/90000
+    a=fmtp:99 packetization-mode=0;profile-level-id=42e011; \
+      sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
+    a=imageattr:99 \
+      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]
+
+   In the send direction, sprop-parameter-sets is defined for a
+   resolution of 320x240, which is the largest image size offered in the
+   send direction.  This means that if 320x240 is selected, no
+   additional offer/answer is necessary.  In the receive direction, four
+   alternative image sizes are offered with 272x224 being the preferred
+   choice.
+
+   The answer may look like:
+
+    m=video 49154 RTP/AVP 100
+    a=rtpmap:100 H264/90000
+    a=fmtp:100 packetization-mode=0;profile-level-id=42e011; \
+      sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
+    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
+   directions.  Although the offerer preferred 272x224 for the receive
+   direction, the answerer might not be able to offer 272x224 or not
+   allow encoding and decoding of video of different image sizes
+   simultaneously.  The answerer sets new sprop-parameter-sets,
+   constructed for both send and receive directions at the restricted
+   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.
+
+
+
+
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 19]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+4.2.4.  Example 4
+
+   This example illustrates in more detail how compensation for
+   different sample aspect ratios can be negotiated with the image
+   attribute.
+
+   We set up a session between Alice and Bob; Alice is the offerer of
+   the session.  The offer (from Alice) contains the image attribute
+   below:
+
+     a=imageattr:97 \
+       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]
+
+   First we consider the recv direction: The offerer (Alice) explicitly
+   states that she wishes to receive the screen resolution 800x600.
+   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)
+   compensate for this.
+
+   So, if Bob's video camera produces square pixels, and if Bob wishes
+   to satisfy Alice's sar requirement, the image processing algorithm
+   must rescale a 880x600 pixel image (880=800*1.1) to 800x600 pixels
+   (could be done other ways).
+
+   ... and now the send direction: Alice indicates that she can (in the
+   image processing algorithms) rescale the image for sample aspect
+   ratios in the range 1.0 to 1.3.  She can also provide a number of
+   different image sizes (in pixels) ranging from 400x320 to 800x640.
+   Bob inspects the offered sar and image sizes and responds with the
+   modified image attribute.
+
+    a=imageattr:97 \
+      recv [x=464,y=384,sar=1.15] \
+      send [x=800,y=600,sar=1.1]
+
+   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.
+
+5.  IANA Considerations
+
+   Following the guidelines in [RFC4566], the IANA is requested to
+   register one new SDP attribute:
+
+   Attribute name:     imageattr
+
+   Long form name:     Image attribute
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 20]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   Type of attribute:  Media-level
+
+   Subject to charset: No
+
+   Purpose:            This attribute defines the ability to negotiate
+                       various image attributes such as image sizes.
+                       The attribute contains a number of parameters
+                       which can be modified in an offer/answer
+                       exchange.
+
+   Appropriate values: See Section 3.1.1 of RFC 6236
+
+   Contact name:       Authors of RFC 6236
+
+6.  Security Considerations
+
+   The image attribute and especially the parameters that denote the
+   image size can take on values that may cause memory or CPU exhaustion
+   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
+   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 Denial-of-
+   Service (DoS) problems.  Implementers ought to consider whether there
+   are any potential DoS attacks that would not be detected by simply
+   checking parameters.
+
+7.  Acknowledgements
+
+   The authors would like to thank the people who have contributed with
+   objections and suggestions to this document and provided valuable
+   guidance in the amazing video-coding world.  Special thanks to
+   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 to work well with the offer/answer model.
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 21]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3264]       Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
+                   Model with Session Description Protocol (SDP)",
+                   RFC 3264, June 2002.
+
+   [RFC4566]       Handley, M., Jacobson, V., and C. Perkins, "SDP:
+                   Session Description Protocol", RFC 4566, July 2006.
+
+   [RFC5234]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                   Specifications: ABNF", STD 68, RFC 5234,
+                   January 2008.
+
+   [RFC5583]       Schierl, T. and S. Wenger, "Signaling Media Decoding
+                   Dependency in the Session Description Protocol
+                   (SDP)", RFC 5583, July 2009.
+
+   [RFC5888]       Camarillo, G. and H. Schulzrinne, "The Session
+                   Description Protocol (SDP) Grouping Framework",
+                   RFC 5888, June 2010.
+
+8.2.  Informative References
+
+   [H.263]         ITU-T, ITU-T Recommendation H.263 (2005): "Video
+                   coding for low bit rate communication".
+
+   [H.264]         ITU-T, ITU-T Recommendation H.264: "Advanced video
+                   coding for generic audiovisual services",
+                   <http://www.itu.int/rec/T-REC-H.264-200711-S/en>.
+
+   [MPEG-4]        ISO/IEC, ISO/IEC 14496-2:2004: "Information
+                   technology - Coding of audio-visual objects - Part 2:
+                   Visual".
+
+   [RFC3016]       Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y.,
+                   and H. Kimata, "RTP Payload Format for MPEG-4 Audio/
+                   Visual Streams", RFC 3016, November 2000.
+
+   [RFC3311]       Rosenberg, J., "The Session Initiation Protocol (SIP)
+                   UPDATE Method", RFC 3311, October 2002.
+
+   [RFC3515]       Sparks, R., "The Session Initiation Protocol (SIP)
+                   Refer Method", RFC 3515, April 2003.
+
+
+
+Johansson & Jung             Standards Track                   [Page 22]
+
+RFC 6236                 Image Attributes in SDP                May 2011
+
+
+   [RFC4629]       Ott, H., Bormann, C., Sullivan, G., Wenger, S., and
+                   R. Even, "RTP Payload Format for ITU-T Rec",
+                   RFC 4629, January 2007.
+
+   [RFC5939]       Andreasen, F., "Session Description Protocol (SDP)
+                   Capability Negotiation", RFC 5939, September 2010.
+
+   [RFC6184]       Wang, Y., Even, R., Kristensen, T., and R. Jesup,
+                   "RTP Payload Format for H.264 Video", RFC 6184,
+                   May 2011.
+
+   [SDPMedCapNeg]  Gilman, R., Even, R., and F. Andreasen, "SDP Media
+                   Mapabilities Negotiation", Work in Progress,
+                   February 2011.
+
+Authors' Addresses
+
+   Ingemar Johansson
+   Ericsson AB
+   Laboratoriegrand 11
+   SE-971 28 Luleae
+   SWEDEN
+
+   Phone: +46 73 0783289
+   EMail: ingemar.s.johansson@ericsson.com
+
+
+   Kyunghun Jung
+   Samsung Electronics Co., Ltd.
+   Dong Suwon P.O. Box 105
+   416, Maetan-3Dong, Yeongtong-gu
+   Suwon-city, Gyeonggi-do
+   Korea 442-600
+
+   Phone: +82 10 9909 4743
+   EMail: kyunghun.jung@samsung.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson & Jung             Standards Track                   [Page 23]
+