draft-ietf-mmusic-image-attributes-01.txt   draft-ietf-mmusic-image-attributes-02.txt 
Network Working Group I. Johansson Network Working Group I. Johansson
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track K. Jung Intended status: Standards Track K. Jung
Expires: September 7, 2009 Samsung Electronics Co., Ltd. Expires: October 18, 2009 Samsung Electronics Co., Ltd.
Mar 6, 2009 Apr 16, 2009
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-01 draft-ietf-mmusic-image-attributes-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2009. This Internet-Draft will expire on October 18, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10 3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10
3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10 3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10
3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 11 3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 11
3.3.6. Interaction with codec parameters . . . . . . . . . . 11 3.3.6. Interaction with codec parameters . . . . . . . . . . 11
3.3.7. Change of display in middle of session . . . . . . . . 13 3.3.7. Change of display in middle of session . . . . . . . . 13
3.3.8. Addition of parameters . . . . . . . . . . . . . . . . 13 3.3.8. Addition of parameters . . . . . . . . . . . . . . . . 13
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Informative References . . . . . . . . . . . . . . . . . . 17 9.1. Informative References . . . . . . . . . . . . . . . . . . 18
10.2. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Normative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document proposes a new attribute to make it possible to This document proposes a new attribute to make it possible to
negotiate different image attributes such as image size. The term negotiate different image attributes such as image size. The term
image size is defined here as it may differ from the physical screen image size is defined here as it may differ from the physical screen
size of e.g a hand-held terminal. For instance it may be beneficial 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 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. space on the screen for e.g menus and other info.
skipping to change at page 4, line 30 skipping to change at page 4, line 30
Several of the existing standards ([H.263], [H.264] and [MPEG-4]) Several of the existing standards ([H.263], [H.264] and [MPEG-4])
have support for different resolutions at different framerates. The have support for different resolutions at different framerates. The
purpose of this document is to provide for a generic mechanism and is purpose of this document is to provide for a generic mechanism and is
targeted mainly at the negotiation of the image size but to make it targeted mainly at the negotiation of the image size but to make it
more general the attribute is named "imageattr". A problem statement more general the attribute is named "imageattr". A problem statement
and discussion that gives a motivation to this document can be found and discussion that gives a motivation to this document can be found
in [S4-080144]. in [S4-080144].
The draft is limited to unicast scenarios in general and more The draft is limited to unicast scenarios in general and more
specific peer to peer or client to server situations. The attribute specific peer to peer situations. The attribute may be used in
may be used in centralized conferencing scenarios as well but due to centralized conferencing scenarios as well but due to the abundance
the abundance of configuration options it may then be difficult to of configuration options it may then be difficult to come up with a
come up with a configuration that fits all parties. configuration that fits all parties.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3. Defintion of Attribute 3. Defintion of Attribute
A new image attribute is defined with the name "imageattr". The new A new image attribute is defined with the name "imageattr". The new
skipping to change at page 6, line 29 skipping to change at page 6, line 29
---- ----
set= "[" "x=" range "," "y=" range [",sar="range] set= "[" "x=" range "," "y=" range [",sar="range]
[",par=" range] [",q=" value] "]" [",par=" range] [",q=" value] "]"
x is the horizontal image size range x is the horizontal image size range
y is the vertical image size range y is the vertical image size range
sar (sample aspect ratio) is the sample aspect ratio associated sar (sample aspect ratio) is the sample aspect ratio associated
with the set (optional and MAY be ignored) with the set (optional and MAY be ignored)
par (picture aspect ratio) is the allowed ratios between the par (picture aspect ratio) is the allowed ratios between the
displays x and y physical size (optional) displays x and y physical size (optional)
q (optional with range [0.0..1.0], default value 0.5) q (optional with range [0.0..1.0], default value 0.5)
is the preference for the given set, a higher value means is the preference for the given set, a higher value means higher
higher preference from the sender point of view preference from the sender point of view
range is expressed in a few different formats range is expressed in a few different formats
1) range= value 1) range= value
a single value a single value
2) range= "[" value1 ":" [ step ":" ] value2 "]" 2) range= "[" value1 ":" [ step ":" ] value2 "]"
values between value1 and value2 inclusive, values between value1 and value2 inclusive,
if step is omitted a stepsize of 1 is implied. if step is omitted a stepsize of 1 is implied
3) range= "[" value 1*( "," value ) "]" 3) range= "[" value 1*( "," value ) "]"
any value from the list of values any value from the list of values
4) range= "[" value1 "-" value2 "]" 4) range= "[" value1 "-" value2 "]"
any real value between value1 and value2 inclusive any real value between value1 and value2 inclusive
value is a positive integer or real value value is a positive integer or real value
step 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. If step is left out in the syntax a stepsize of 1 is implied
Real values are only applicable for the Real values are only applicable for the
sar, par and q parameters. sar, par and q parameters
Note the use of brackets [..] if more that one value Note the use of brackets [..] if more that one value
is specified. is specified.
---- ----
Some further guidelines for the use of the attribute is given below: Some further guidelines for the use of the attribute is given below:
o The image attribute is bound to a specific media by means of the 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. A wild card (*) can be specified for the
payload type number to indicate that it applies to all payload payload type number to indicate that it applies to all payload
types in the media description. Several image attributes can be types in the media description. Several image attributes can be
defined e.g for different video codec alternatives conditioned defined e.g for different video codec alternatives conditioned
skipping to change at page 7, line 27 skipping to change at page 7, line 27
o The sar parameter specifies the sample aspect ratio associated to o The sar parameter specifies the sample aspect ratio associated to
the given range of x and y values. The sar parameter is defined 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 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. gives a sar=1.0. The parameter sar MAY be expressed as a range.
If this parameter is not present a default sar value of 1.0 is If this parameter is not present a default sar value of 1.0 is
assumed. assumed.
The interpretation of sar differs between the send and the receive The interpretation of sar differs between the send and the receive
directions. directions.
* In the send direction it defines a specific sample aspect ratio * In the send direction it defines a specific sample aspect
associated to a given x and y image size (range). ration associated to a given x and y image size (range).
* In the recv direction sar expresses that the receiver of the * In the recv direction sar expresses that the receiver of the
given media prefers to receive a given x and y resolution with given media prefers to receive a given x and y resolution with
a given sample aspect ratio. a given sample aspect ratio.
See Section 3.3.4 for a more detailed discussion. See Section 3.3.4 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.
o The par (width/height = x/y ratio) parameter indicates a range of o The par (width/height = x/y ratio) parameter indicates a range of
allowed ratios between x and y physical size (picture aspect allowed ratios between x and y physical size (picture aspect
ratio). This is used to limit the number of x and y image size ratio). This is used to limit the number of x and y image size
combinations, par is given as combinations, par is given as
---- ----
par=[ratio_min-ratio_max] par=[ratio_min-ratio_max]
---- ----
Where ratio_min and ratio_max are the min and max allowed picture Where ratio_min and ratio_max are the min and max allowed picture
aspect ratios. aspect ratios.
If sar and the display sample aspect ratio is the same (or close) 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 the relation between the x and y pixel resolution and the physical
size of the image is straightforward. If however sar differs from size of the image is straightforward. If however sar differs from
the sample aspect ratio of the receiver display this must be taken the sample aspect ratio of the receiver display this must be taken
into consideration when the x and y pixel resolution alternatives into consideration when the x and y pixel resolution alternatives
are sorted out. are sorted out.
o The offerer MUST be able to support the image attributes that it o The offerer MUST be able to support the image attributes that it
offers. offers.
o The answerer MAY choose to keep imageattr but is not required to o The answerer MAY choose to keep imageattr but is not required to
skipping to change at page 10, line 34 skipping to change at page 10, line 34
limitations to this. One important limitation is that the codec limitations to this. One important limitation is that the codec
being used can only support up to a given maximum resolution for a being used can only support up to a given maximum resolution for a
given profile level. given profile level.
As an example H.264 with profile level 1.2 does not support higher As an example H.264 with profile level 1.2 does not support higher
resolution than 352x288 (CIF). The offer/answer rules essentially resolution than 352x288 (CIF). The offer/answer rules essentially
gives that the same profile level must be used in both directions. gives that the same profile level must be used in both directions.
This means that for an asymmetric scenario where Alice wants an image 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 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 both directions even though profile level 1 would have been enough in
one direction. [Ed. Note. This is currently being changed with the one direction.
RFC3984bis draft].
Currently, the only solution to this problem is to specify two Currently, the only solution to this problem is to specify two
unidirectional media descriptions. unidirectional media descriptions. Note however that the asymmetry
issue for the H.264 codec is solved in [RFC3984bis].
3.3.3. sendonly and recvonly 3.3.3. sendonly and recvonly
If the directional attributes a=sendonly or a=recvonly are given for If the directional attributes a=sendonly or a=recvonly are given for
a media, there is of course no need to specify the image attribute a media, there is of course no need to specify the image attribute
for both directions. Therefore one of directions in the attribute for both directions. Therefore one of directions in the attribute
MAY be omitted. However it may be good to do the image attribute MAY be omitted. However it may be good to do the image attribute
negotiation in both directions in case the session is updated for negotiation in both directions in case the session is updated for
media in both directions at a later stage. media in both directions at a later stage.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
H.263 defines (on the fmtp line) a list of image sizes and their H.263 defines (on the fmtp line) a list of image sizes and their
maximum frame rates (profiles) that the offerer can receive. The maximum frame rates (profiles) that the offerer can receive. The
answerer is not allowed to modify this list and must reject a payload answerer is not allowed to modify this list and must reject a payload
type that contains an unsupported profile. The CUSTOM profile may be type that contains an unsupported profile. The CUSTOM profile may be
used for image size negotiation but support for asymmetry requires used for image size negotiation but support for asymmetry requires
the specification of two unidirectional media descriptions using the the specification of two unidirectional media descriptions using the
sendonly/recvonly attributes. sendonly/recvonly attributes.
3.3.6.2. H.264 3.3.6.2. H.264
The payload format for H.264 is described in [RFC3984]. [Ed. Note : The payload format for H.264 is described in [RFC3984] and updated in
This format is currently being changed]. [RFC3984bis].
H.264 defines image size related information in the fmtp line by H.264 defines image size related information in the fmtp line by
means of sprop-parameter-sets. According to the specification means of sprop-parameter-sets. According to the specification
several sprop-parameter-sets may be defined for one payload type. several sprop-parameter-sets may be defined for one payload type.
The sprop-parameter-sets describe the image size (+ more) that the The sprop-parameter-sets describe the image size (+ more) that the
offerer sends in the stream and need not be complete. This means offerer sends in the stream and need not be complete. This means
that this does not represent any negotiation. Moreover an answer is that this does not represent any negotiation. Moreover an answer is
not allowed to change the sprop-parameter-sets. not allowed to change the sprop-parameter-sets.
This configuration may be changed later inband if for instance image This configuration may be changed later inband if for instance image
skipping to change at page 16, line 12 skipping to change at page 16, line 12
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240] a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
---- ----
Indicating (in this example) that the image size is 320x240 in both Indicating (in this example) that the image size is 320x240 in both
directions. Although the offerer preferred 272x224 for the receive directions. Although the offerer preferred 272x224 for the receive
direction, the answerer might not be able to offer 272x224 or not direction, the answerer might not be able to offer 272x224 or not
allow encoding and decoding of video of different image sizes allow encoding and decoding of video of different image sizes
simultaneously. The answerer sets new sprop-parameter-sets, simultaneously. The answerer sets new sprop-parameter-sets,
constructed for both send and receive directions at the restricted constructed for both send and receive directions at the restricted
conditions and image size of 320x240. conditions and image size of 320x240.
5. Issues 4.4. Example 4
Here is listed a few possible issues and observations connected to This example illustrates in more detail how compensation for
the use of the image attribute : different sample aspect ratios can be negotiated with the image
attribute.
o An SDP answer MAY modify the image attribute for the answerers We setup a session between Alice and Bob, Alice is the offerer of the
send direction. Can this cause trouble ? session. The offer (from Alice) contains the image attribute below:
----
a=imageattr:97 \
send [sar=[1.0-1.3],x=400:16:800],y=[320:16:640],par=[1.2-1.3]] \
recv [sar=1.1,x=800,y=600]
----
6. IANA Considerations First we consider the recv direction: The offerer (Alice) explicitly
states that she wish 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 wish 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 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
----
a=imageattr:97 \
recv [sar=1.15,x=464,y=384] \
send [sar=1.1,x=800,y=600]
----
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.
Neither part is required to rescale like this (sar MAY be ignored),
the consequence will of course be a distorted image.
5. IANA Considerations
Following the guidelines in [RFC4566], the IANA is requested to Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute: register one new SDP attribute:
o Contact name, email address and telephone number: Authors of o Contact name, email address and telephone number: Authors of
RFCXXXX RFCXXXX
o Attribute-name: imageattr o Attribute-name: imageattr
o Long-form attribute name: Image attribute
o Type of attribute: media-level o Type of attribute: media-level
o Subject to charset: no o Subject to charset: no
This attribute defines the ability to negotiate various image This attribute defines the ability to negotiate various image
attributes such as image sizes. The attribute contains a number of attributes such as image sizes. The attribute contains a number of
parameters which can be modified in and offer/answer exchange. parameters which can be modified in and offer/answer exchange.
Note to RFC Editor: please replace "RFC XXXX" above with the RFC Note to RFC Editor: please replace "RFC XXXX" above with the RFC
number of this memo, and remove this note. number of this memo, and remove this note.
7. Security Considerations 6. Security Considerations
This draft does not add any additional security issues other than This draft does not add any additional security issues other than
those already existing with currently specified offer/answer those already existing with currently specified offer/answer
procedures. procedures.
8. Acknowledgements 7. Acknowledgements
The authors would like to thank the people who has contributed with The authors would like to thank the people who has contributed with
objections and suggestions to this draft and provided with valuable objections and suggestions to this draft and provided with valuable
guidance in the amazing video-coding world. Special thanks go to guidance in the amazing video-coding world. Special thanks go to
Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing.
9. Changes 8. Changes
The main changes are: The main changes are:
From WG -01 to WG -02
* Added extra example that highlights the negotiation of sar
From WG -00 to WG -01 From WG -00 to WG -01
* Added info about future addition of parameters and backwards * Added info about future addition of parameters and backwards
compatibility compatibility
* Added IANA considerations * Added IANA considerations
From individual -02 to WG -00 From individual -02 to WG -00
* Cleanup of syntax, ABNF form * Cleanup of syntax, ABNF form
skipping to change at page 17, line 41 skipping to change at page 18, line 29
* Cleanup of the sar and par parameters to make them match the * Cleanup of the sar and par parameters to make them match the
established conventions established conventions
* Requirement specification added * Requirement specification added
* New bidirectional syntax * New bidirectional syntax
* Interoperability considerations with well known video codecs * Interoperability considerations with well known video codecs
discussed discussed
10. References 9. References
10.1. Informative References 9.1. Informative References
[H.264] ITU-T, "ITU-T Recommendation H.264, [H.264] ITU-T, "ITU-T Recommendation H.264,
http://www.itu.int/rec/T-REC-H.264-200711-I/en". http://www.itu.int/rec/T-REC-H.264-200711-I/en".
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. [RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Kimata, "RTP Payload Format for MPEG-4 Audio/Visual
Streams", RFC 3016, November 2000. Streams", RFC 3016, November 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video", M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005. RFC 3984, February 2005.
[RFC3984bis]
IETF, "RTP Payload Format for H.264 Video, http://
tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/".
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
RFC 4587, August 2006. RFC 4587, August 2006.
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R.
Even, "RTP Payload Format for ITU-T Rec", RFC 4629, Even, "RTP Payload Format for ITU-T Rec", RFC 4629,
January 2007. January 2007.
skipping to change at page 18, line 37 skipping to change at page 19, line 29
[SDPCapNeg] [SDPCapNeg]
IETF, "SDP Capability Negotiation, http://tools.ietf.org/ IETF, "SDP Capability Negotiation, http://tools.ietf.org/
wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation". wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation".
[SDPMedCapNeg] [SDPMedCapNeg]
IETF, "SDP media capabilities Negotiation, http:// IETF, "SDP media capabilities Negotiation, http://
tools.ietf.org/wg/mmusic/ tools.ietf.org/wg/mmusic/
draft-ietf-mmusic-sdp-media-capabilities". draft-ietf-mmusic-sdp-media-capabilities".
10.2. Normative References 9.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
Laboratoriegrand 11 Laboratoriegrand 11
SE-971 28 Lulea SE-971 28 Lulea
 End of changes. 28 change blocks. 
44 lines changed or deleted 85 lines changed or added

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