Network Working Group I. Johansson
Internet-Draft Ericsson AB
Intended status: Standards Track K. Jung
Samsung Electronics Co., Ltd.
Feb 18, 2011

Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-11

Abstract

This document proposes a new generic session set up 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 draft 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

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

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.

There are a number of benefits with a possibility to negotiate the image size:

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 anyway give the encoder a better indication about what image size is preferred 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 to notice that there are several benefits to do it on the sender side:

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'.

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 wish to receive or send. Each image attribute set must include a specific image size.
REQ-2:
Support set up/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].
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, 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 [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 while 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)
       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 
                  ;  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 which 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
       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
       ----

3.1.1.1. Parameter rules

    ----
    par=[ratio_min-ratio_max]
    ----

For the parameters the following rules apply.

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 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 is 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.

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 to 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
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

       ----
       a=imageattr:97 send * recv *
       ----

In accordance with [RFC3264], offer answer exchange of the image attribute is as follows.

3.2. Considerations

3.2.1. No imageattr in 1st 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:

For the above reasons it is RECOMMENDED that a device which sees no reason to use the image attribute, anyway includes the attribute with wild cards (*) in the attribute lists for the send and recv directions.

3.2.2. Different payload type numbers in offer and answer

    ----
    m=video 49154 RTP/AVP 99
    ----
    ----
    m=video 49154 RTP/AVP 100
    ----

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

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.

        ----
        m=video 49154 RTP/AVP 99
        a=imageattr:99 send ... recv ...
        ----
        ----
        m=video 49154 RTP/AVP 100
        a=imageattr:99 send ...
        a=imageattr:100 recv ...
        ----

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:

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 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 [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 [RFC3984bis].

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

    ----
    a=imageattr:97 send [x=720,y=576,sar=1.1]
    ----
    ----
    a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
    ----

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):
To avoid this problem Alice may specify a range of values for the sar parameter like:

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 set up, 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 any recommendation for any of them.

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 [RFC3984bis].

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.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:

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 or SIP-UPDATE methods. It is RECOMMENDED to negotiate the image size during this renegotiation.

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.

    ----
    a=imageattr:PT send attr-list recv attr-list
    ----
    ----
    a=imageattr:PT send attr-list recv *
    ----

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
    ----

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 recv attr-list
    ----

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:

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 wish 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) 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 [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 which 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 with a list of supported image sizes

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.

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.

  ----
  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]
  ----

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:

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 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).

 ----
 a=imageattr:97 \
   recv [x=464,y=384,sar=1.15] \
   send [x=800,y=600,sar=1.1]
 ----

... 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 with 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

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
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 and offer/answer exchange.
Appropriate values:
See Section 3.1.1 of RFCXXXX
Contact name:
Authors of RFCXXXX

Note to RFC Editor: please replace "RFCXXXX" above with the RFC number of this document, and remove this note.

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 as outlined above.

A receiver of the SDP containing the image attribute MUST ensure that the parameters have values that are reasonable and that the device can handle the implications in terms of memory and CPU usage. Failure to do a sanity check on the parameters may result in memory or CPU exhaustion.

In principle, for some SDPs containing the image attribute and for some deployments, it could be the case that simply checking the parameters is not sufficient to detect all potential DoS problems. Implementers ought to consider whether there are any potential DoS attacks that would not be detected by simply checking parameters.

7. Acknowledgements

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. 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

Note to RFC Editor: please replace remove this section in its entirety before publication.

The main changes are:

From WG -10 to WG -11
From WG -09 to WG -10
From WG -08 to WG -09
From WG -07 to WG -08
From WG -05 to WG -06 & -07
From WG -04 to WG -05
From WG -03 to WG -04
From WG -02 to WG -03
From WG -01 to WG -02
From WG -00 to WG -01
From individual -02 to WG -00
From -01 to -02

9. References

9.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.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[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.

9.2. Informative References

[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.
[RFC4629] Ott, H.263Video.J., 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.
[H.264] , , "ITU-T Recommendation H.264, http://www.itu.int/rec/T-REC-H.264-200711-I/en", .
[H.263] , , "ITU-T Recommendation H.263 (2005): "Video coding for low bit rate communication"", .
[MPEG-4] , , "ISO/IEC 14496-2:2004: "Information technology - Coding of audio-visual objects - Part 2: Visual"", .
[SDPMedCapNeg] , , "SDP media capabilities Negotiation, http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities", .
[RFC3984bis] , , "RTP Payload Format for H.264 Video, http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/", .

Authors' Addresses

Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 LuleƄ, 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