Network Working Group I. Johansson Internet-Draft Ericsson AB Intended status: Standards Track K. Jung Expires: March 23, 2009 Samsung Electronics Co., Ltd. Sep 19, 2008 Negotiation of Generic Image Attributes in SDP draft-johansson-mmusic-image-attributes-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 23, 2009. 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 e.g 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 draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. Johansson & Jung Expires March 23, 2009 [Page 1] Internet-Draft Image Attributes in SDP Sep 2008 Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 7 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 9 3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10 3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10 3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 10 3.3.6. Interaction with codec parameters . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Johansson & Jung Expires March 23, 2009 [Page 2] Internet-Draft Image Attributes in SDP Sep 2008 1. Introduction This document proposes a new 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 e.g a hand-held terminal. For instance it may be beneficial to display a video image on a part of the physical screen and leave space on the screen for e.g menus and other info. There are a number of benefits with a possibility to negotiate the image size: 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 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. This gives alternatively a saving in bitrate. o Memory requirement: The receiver device will know the size of the image and can then allocate memory accordingly. o Optimal aspect ratio: If rescaling of the image is possible on the received side one can imagine that the offer contains three resolutions 100x200, 200x100 and 100x100 with sar=1.0 (1:1). If the receiver screen has the resolution 200x200 with sar=1 then the obvious is to select 100x100 and scale the image by a factor 2. If on the other hand the screen has the resolution 100x200 with sar=2 (2:1) then the obvious is again to select 100x100 and scale the image by a factor 2 in the x-axis. The cautious reader may however object that the rescaling issue has been moved to the sender and also that codecs such as H.264 are not mandated to support the rescaling of the video image size. This potentially reduces the number of valid arguments to only 1 (optimal use of bandwidth). However, what must then be considered is that: o Rescaling on the sender/encoder side is likely to be easier to do as the camera related software/hardware already contains the necessary functionality for zooming/cropping/trimming/sharpening the video signal. Moreover, rescaling is generally done in RGB or Johansson & Jung Expires March 23, 2009 [Page 3] Internet-Draft Image Attributes in SDP Sep 2008 YUV domain and should not depend on the codecs used. o The encoder may be able to encode in a number of formats but may not know which format to choose. 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 esp. when low bitrate video coding is used. o If low-complexity rescaling operations such as cropping only must be performed after all, 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 target his camera 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 and is targeted mainly at the negotiation of the image size but to make it more general the attribute is named "imageattr". A problem statement and discussion that gives a motivation to this document can be found in [S4-080144]. 2. Conventions, Definitions and Acronyms 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 RFC 2119. 3. Defintion of Attribute A new image attribute is defined with the name "imageattr". The image attribute contains a set of different image-resolution options that the offerer can provide. The receiver can then select the desired image attribute (e.g image size) and may then have the ability to avoid costly transformations (e.g rescaling) of the images. In this approach only the image resolution and optionally sample aspect ratio, allowed range in picture aspect ratio and preference is covered but the framework makes it possible to extend with other image related attributes that make sense. 3.1. Requirements The new image attribute should meet the following requirements: Johansson & Jung Expires March 23, 2009 [Page 4] Internet-Draft Image Attributes in SDP Sep 2008 REQ-1: Support the offer of a specific image size on the receiver display or in other words, reduce or avoid the need for rescaling images in the receiver to fit a given portion of the screen. REQ-2: Support asymmetric setups i.e the very likely scenario where Alice prefers an image size of 320x240 for her display while Bob prefers an image size of 176x144. REQ-3: Interoperate with codec specific parameters such as sprop- parameter-sets in H.264 or config in MPEG4. REQ-3: Make the attribute generic with as little codec specific details/tricks as possible. Ideally the attribute should not care about the codec specific features. OPT-1: Make it possible to use attribute for other purposes than video. One possible use case may be distributed white-board presentations which are based on transmission of compressed bitmap images where rescaling often produce very poor results. 3.2. Attribute syntax In this section the syntax of the image attribute is described. The section is split up in two parts, the first gives an overall view of the syntax while the second describes how the syntax is used. 3.2.1. Overall view of syntax The syntax for the image attribute is: ---- a=imageattr:PT 1*WSP send 1*WSP attr_list \ 1*WSP recv 1*WSP attr_list|* attr_list = set *(1*WSP set) see below for a definition of set. ---- o PT is the payload type number, can be set to * . o The backslash '\' is used in this document for formatting reasons only. o For sendonly or recvonly streams one of the directions MAY be omitted. See Section 3.3.3, moreover the order of the send and recv directions is not important. The syntax for the set is given by: Johansson & Jung Expires March 23, 2009 [Page 5] Internet-Draft Image Attributes in SDP Sep 2008 ---- set=[x=range,y=range<,sar=range><,par=range><,q=value>] x is the horizontal image size range y is the vertical image size range sar is the sample aspect ratio associated with the set (optional and MAY be ignored) par is the allowed ratios between the displays x and y physical size a.k.a picture aspect ratio (optional) q (optional with range [0.0..1.0], default value 0.5) is the preference for the given set, a higher value means higher preference from the sender point of view range is expressed in a few different forms 1) range=value 2) range=[value1:value2] (any value between value1 and value2 inclusive) 3) range=[value1:step:value2] (every 'step' value between value1 and value2 inclusive) 4) range=[value1,value2...valueN] (any value from the list of values) 5) range=[value1-value2] (any real value between value1 and value2 inclusive) value is a positive integer or real value step is a positive integer or real value If step is left out in the syntax a stepsize of 1 is implied. Note the use of brackets [..] if more that one value specified. ---- Some guidelines for the use of the syntax is given below: o The image attribute is bound to a specific media 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 e.g for different video codec alternatives conditioned that the payload type number differs. o 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. o The sar 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 is the size of the pixels. Square pixels gives a sar=1.0. The parameter sar MAY be expressed as a range. The interpretation of sar differs between the send and the receive Johansson & Jung Expires March 23, 2009 [Page 6] Internet-Draft Image Attributes in SDP Sep 2008 directions. In the send direction it defines a specific sample aspect ration associated to a given x and y image size (range). In the recv direction sar expresses that the receiver of the given media prefers to receive a given x and y resolution with a given sample aspect ratio. See Section 3.3.4 for a more detailed discussion. o 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] ---- Where ratio_min and ratio_max are the min and max allowed picture aspect ratios. If sar and the display sample aspect ration is 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. o The offerer MUST be able to support the image attributes that it offers. o The answerer MAY choose to keep imageattr but is not required to do so. The answerer MUST in this case only include one or more valid entries taken from the offer in the SDP answer, the exception to this is the case above where the 1st offer defines a desired image size for the receive direction. o The answerer MUST only pick one or more valid entries from the multidimensional solution space spanned by the offer. 3.2.2. Syntax description In the description of the syntax we here assume that Alice wish to setup a session with Bob and that Alice takes the first initiative. The syntactical white-space delimiters (1*WSP) are removed to make reading easier. In the offer Alice provides with information for both the send and receive (recv) directions using syntax version 1. For the send direction Alice provides with 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 fill with a list of image size that Bob can support to send. Using the overall Johansson & Jung Expires March 23, 2009 [Page 7] Internet-Draft Image Attributes in SDP Sep 2008 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 * ---- 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 the given x and y range the answer from Bob will look like (syntax version 2): ---- a=imageattr:PT send attr_list recv attr_list ---- And the offer answer negotiation is done. Worth notice here is that the attr_list will likely be pruned in the answer. While it may contain many different alternatives in the offer it may in the end contain just one or two alternatives in the end. If Bob does not support any x and y resolution in the given x and y range in attr_list or a (*) was given for the recv direction then he MUST either: o Provide with another list of options (attr_list). The answer from Bob may then look like (syntax version 3): ---- a=imageattr:PT recv attr_list send attr_list ---- In this case the offer/answer negotiation is not quite done. To complete the offer/answer Alice sends another offer that looks like: ---- a=imageattr:PT send attr_list recv attr_list ---- Bob MAY send back an answer to complete the 2nd offer/answer but this is not necessary. o Remove the corresponding part completely in which case the answer from bob would look like: ---- a=imageattr:PT recv attr_list ---- Again it is worth notice that the attr_list for each direction is likely pruned depending on preferred and supported options. Johansson & Jung Expires March 23, 2009 [Page 8] Internet-Draft Image Attributes in SDP Sep 2008 If the 1st offer (from Alice) already defines a desired image size for the recv direction the answerer can do one of the following: 1. Accept the image size and return it in the answer. 2. Replace with a list of options in the answer. 3. Remove the corresponding part completely. This may happen if it is deemed that it is unlikely that the list of options is supported. The answer will then lack a description for the send direction and will look like: ---- a=imageattr:PT recv attr_list ---- 3.3. Considerations 3.3.1. No imageattr in 1st offer A high end device (Alice) may not see any need for the image attribute as it most likely has the processing capacity to rescale incoming video and may therefore not include the attribute in the offer as it otherwise does not see any use for it. The answerer (Bob) MAY include imageattr in the answer. This has two implications: o Longer session setup time due to extra offer/answer exchanges o There is a risk that Alice does not recognize or support imageattr and will thus anyway ignore the attribute. 3.3.2. Asymmetry While the image attribute supports asymmetry there are some limitations to this. 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 with profile level 1.2 does not support higher resolution than 352x288 (CIF). The offer/answer rules essentially gives that the same profile level must be used in both directions. This means that for 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 enough in one direction. Currently, the only solution to this problem is to specify two unidirectional media descriptions. Johansson & Jung Expires March 23, 2009 [Page 9] Internet-Draft Image Attributes in SDP Sep 2008 3.3.3. sendonly and recvonly If the directional attributes a=sendonly or a=recvonly are given for a media, there is of course no need to specify the image attribute for both directions. Therefore one of 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.3.4. Sample aspect ratio The sar parameter in relation to 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 [sar=1.1,x=720,y=576] ---- 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 draft. To avoid this problem Alice MAY specify a range of values for the sar parameter like: ---- a=imageattr:97 send [sar=[0.91,1.0,1.09,1.45],x=720,y=576] ---- Meaning that Alice can encode with any of the mentioned sample aspect ratios, leaving to Bob to decide which one he prefers. The response MUST not include the sar parameter if there is no acceptable value given. 3.3.5. SDPCapNeg support T.B.D when the rest is settled. 3.3.6. Interaction with codec parameters As most codecs specifies some kind of indication of eg. the image size already at session setup some measures must be taken to avoid that the image attribute conflicts with this already existing information. The following subsections describes the most well known codecs and how they define image-size related information. Johansson & Jung Expires March 23, 2009 [Page 10] Internet-Draft Image Attributes in SDP Sep 2008 3.3.6.1. H.263 The payload format for 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.3.6.2. H.264 The payload format for H.264 is described in [RFC3984]. This format is subject to change and the update is described in [ref. to RFC3984bis and other H.264 ext drafts] H.264 defines image size related information 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 this does not represent any negotiation. Moreover an 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.3.6.3. MPEG-4 The payload format for 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. Currently it is not possible to change the configuration using inband signaling. 3.3.6.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: Johansson & Jung Expires March 23, 2009 [Page 11] Internet-Draft Image Attributes in SDP Sep 2008 o Ignore payload format parameters: This may not work well e.g in the presence of bad channel conditions esp. in the beginning of a session. Moreover this is not a good option for MPEG-4. o 2nd session-wide offer/answer round: In the 2nd offer/answer the codec payload format specific parameters 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 payload format specific parameters is still present after the first offer/anser round and a fuzzy/buggy implementation may start media before the second offer/answer is completed with unwanted results. o 2nd 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 1st offer answer round to avoid that media flows. 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 alternative. 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 already after the first offer/ answer round. 4. Examples A few examples to highlight the syntax, here is assumed where needed that Alice initiates a session with Bob 4.1. Example 1 ---- a=imageattr:97 send [sar=1.1,x=800,y=640,q=0.6] [x=480,y=320] \ recv [x=330,y=250] ---- Two image resolution alternatives are offered with 800x640 with sar=1.1 having the highest preference The example also indicates that Alice wish to display video with a resolution of 330x250 on her display In case Bob accepts the "recv [x=330,y=250]" the answer may look like Johansson & Jung Expires March 23, 2009 [Page 12] Internet-Draft Image Attributes in SDP Sep 2008 ---- a=imageattr:97 recv [sar=1.1,x=800,y=640] \ send [x=330,y=250] ---- Indicating that the receiver (Bob) wish 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. 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 [sar=1.1,x=800,y=640] \ send [x=[320:16:640],y=[240:16:480],par=[1.2-1.3]] ---- Alice can then select a valid image size which is closest to the one that was originally desired (336x256) and performs a second offer/ answer ---- a=imageattr:97 send [sar=1.1,x=800,y=640] \ recv [x=336,y=256] ---- Bob replies with (actually not necessary): ---- a=imageattr:97 recv [sar=1.1,x=800,y=640] \ send [x=336,y=256] ---- 4.2. Example 2 ---- 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 * ---- Two image resolution sets are offered with the first having a higher preference (q=0.6). 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 with Johansson & Jung Expires March 23, 2009 [Page 13] Internet-Draft Image Attributes in SDP Sep 2008 a list of supported image sizes 5. Issues Here is listed a few possible issues and observations connected to the use of the image attribute : o Sample aspect ratios: Should it be possible to specify several different values for sar? o interlace parameter: It should be possible to include an interlace parameter with the two values true and false for each set. o Change of display during session: There are roughly speaking two scenarios: * The user plugs in an external monitor * The user moves the call to another unit (SIP-REFER) Likely these scenarios involve some kind of renegotiation. o The syntax description may need to be improved. o Image sharpening: In normal cases image sharpening is to be performed after rescaling on the sender side, this also yields the best possible image quality. There may however occur cases where it is preferable to do the sharpening on the receiver side instead. Big question is if this document should worry about this as it has traditionally been up to the sender and/or receiver side to determine if sharpening should be applied. o Multiparty sessions: Currently only point-to-point scenarios is considered, it is however possible that this formulation is used for multiparty sessions with a mixer/transcoding device in the middle. It should be possible to use imageattr for the latter scenario but this must be studied more. 6. IANA Considerations T.B.D 7. Security Considerations This draft does not add any additional security issues other than Johansson & Jung Expires March 23, 2009 [Page 14] Internet-Draft Image Attributes in SDP Sep 2008 those already existing with currently specified offer/answer procedures. 8. Acknowledgements The authors would like to thank the people who has contributed with objections and suggestions to this draft and provided with valuable guidance in the amazing video-coding world. Special thanks go to Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. 9. Changes The main changes are: From -01 to -02 * Cleanup of the sar and par parameters to make them match the established conventions * Requirement specification added * New bidirectional syntax * Interoperability considerations with well known video codecs discussed 10. References 10.1. Informative References [H.264] ITU-T, "ITU-T Recommendation H.264, http://www.itu.int/rec/T-REC-H.264-200711-I/en". [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. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, February 2005. Johansson & Jung Expires March 23, 2009 [Page 15] Internet-Draft Image Attributes in SDP Sep 2008 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006. [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007. [S4-080144] 3GPP, "Signaling of Image Size: Combining Flexibility and Low Cost, http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/ TSGS4_48/Docs/S4-080144.zip". 10.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea 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 Expires March 23, 2009 [Page 16] Internet-Draft Image Attributes in SDP Sep 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Johansson & Jung Expires March 23, 2009 [Page 17]