draft-ietf-avt-rtp-evrc-nw-05.txt   draft-ietf-avt-rtp-evrc-nw-06.txt 
Network Working Group Z. Fang Network Working Group Z. Fang
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Standards Track October 25, 2011 Intended status: Standards Track February 22, 2012
Expires: April 27, 2012 Expires: August 25, 2012
RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec
(EVRC-NW) (EVRC-NW)
draft-ietf-avt-rtp-evrc-nw-05 draft-ietf-avt-rtp-evrc-nw-06
Abstract Abstract
This document specifies real-time transport protocol (RTP) payload This document specifies real-time transport protocol (RTP) payload
formats to be used for the Enhanced Variable Rate Narrowband-Wideband formats to be used for the Enhanced Variable Rate Narrowband-Wideband
Codec (EVRC-NW). Three media type registrations are included for Codec (EVRC-NW). Three media type registrations are included for
EVRC-NW RTP payload formats. In addition, a file format is specified EVRC-NW RTP payload formats. In addition, a file format is specified
for transport of EVRC-NW speech data in storage mode applications for transport of EVRC-NW speech data in storage mode applications
such as e-mail. such as e-mail.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2012. This Internet-Draft will expire on August 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
6.1. Encoding capability identification in EVRC-NW 6.1. Encoding capability identification in EVRC-NW
interleaved/bundled format . . . . . . . . . . . . . . . . 8 interleaved/bundled format . . . . . . . . . . . . . . . . 8
7. Congestion Control Considerations . . . . . . . . . . . . . . 11 7. Congestion Control Considerations . . . . . . . . . . . . . . 11
8. Storage format for the EVRC-NW Codec . . . . . . . . . . . . . 12 8. Storage format for the EVRC-NW Codec . . . . . . . . . . . . . 12
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 13 9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 13
9.1.1. Registration of Media Type audio/EVRCNW . . . . . . . 13 9.1.1. Registration of Media Type audio/EVRCNW . . . . . . . 13
9.1.2. Registration of Media Type audio/EVRCNW0 . . . . . . . 15 9.1.2. Registration of Media Type audio/EVRCNW0 . . . . . . . 15
9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 16 9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 16
10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 19 10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 19
11. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 20 11. Mode Change Request/Response Considerations . . . . . . . . . 20
12. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 21 12. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 22
13. Declarative SDP Considerations . . . . . . . . . . . . . . . . 23 13. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 23
14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. Declarative SDP Considerations . . . . . . . . . . . . . . . . 25
15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. Security Considerations . . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . . 28 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . . 28 17.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 17.2. Informative References . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document specifies the payload formats for packetization of This document specifies the payload formats for packetization of
EVRC-NW encoded speech signals into the real-time transport protocol EVRC-NW encoded speech signals into the real-time transport protocol
(RTP). It defines support for the header-free, interleaved/bundled (RTP). It defines support for the header-free, interleaved/bundled
and compact bundle packet formats for the EVRC-NW codec as well as and compact bundle packet formats for the EVRC-NW codec as well as
discontinuous transmission (DTX) support for EVRC-NW encoded speech discontinuous transmission (DTX) support for EVRC-NW encoded speech
transported via RTP. The EVRC-NW codec offers better speech quality transported via RTP. The EVRC-NW codec offers better speech quality
than the EVRC and EVRC-B codecs and better capacity than EVRC-WB than the EVRC and EVRC-B codecs and better capacity than EVRC-WB
skipping to change at page 14, line 7 skipping to change at page 14, line 7
dtxmin: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788.
hangover: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788.
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8) and This media type is framed binary data (see RFC 4288, Section 4.8) and
is defined for transfer of EVRC-NW encoded data via RTP using the is defined for transfer of EVRC-NW encoded data via RTP using the
Interleaved/Bundled packet format specified in RFC 3558 [6]. Interleaved/Bundled packet format specified in RFC 3558 [6].
Security considerations: See Section 15. Security considerations: See Section 16.
Interoperability considerations: None Interoperability considerations: None
Published specification: Published specification:
The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer
method with the Interleaved/Bundled packet format via RTP is method with the Interleaved/Bundled packet format via RTP is
specified in RFC 3558 [6]. See Section 6 for details for EVRC-NW. specified in RFC 3558 [6]. See Section 6 for details for EVRC-NW.
Applications that use this media type: Applications that use this media type:
skipping to change at page 15, line 46 skipping to change at page 15, line 46
dtxmin: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788.
hangover: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788.
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8) and This media type is framed binary data (see RFC 4288, Section 4.8) and
is defined for transfer of EVRC-NW encoded data via RTP using the is defined for transfer of EVRC-NW encoded data via RTP using the
Header-Free packet format specified in RFC 3558 [6]. Header-Free packet format specified in RFC 3558 [6].
Security considerations: See Section 15. Security considerations: See Section 16.
Interoperability considertaions: None Interoperability considertaions: None
Published specification: Published specification:
The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer
method with the Header-Free packet format via RTP is specified in RFC method with the Header-Free packet format via RTP is specified in RFC
3558 [6]. 3558 [6].
Applications that use this media type: Applications that use this media type:
skipping to change at page 17, line 32 skipping to change at page 17, line 32
dtxmin: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788.
hangover: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788.
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8) and This media type is framed binary data (see RFC 4288, Section 4.8) and
is defined for transfer of EVRC-NW encoded data via RTP using the is defined for transfer of EVRC-NW encoded data via RTP using the
Compact Bundled packet format specified in RFC 4788. Compact Bundled packet format specified in RFC 4788.
Security considerations: See Section 15 Security considerations: See Section 16
Interoperability considertaions: None Interoperability considertaions: None
Published specification: Published specification:
The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer
method with the Compact Bundled packet format via RTP is specified in method with the Compact Bundled packet format via RTP is specified in
RFC 4788. RFC 4788.
Applications that use this media type: Applications that use this media type:
skipping to change at page 19, line 10 skipping to change at page 19, line 10
Change controller: Change controller:
IETF Payload working group delegated from the IESG. IETF Payload working group delegated from the IESG.
10. SDP mode attributes for EVRC-NW 10. SDP mode attributes for EVRC-NW
'mode-set-recv' can be used by a decoder to inform an encoder of its 'mode-set-recv' can be used by a decoder to inform an encoder of its
preference to operate in a specified subset of modes. Note that preference to operate in a specified subset of modes. Note that
indicating a preference, implicitly indicates support for that indicating a preference, implicitly indicates support for that
capability. Conversely, if mode 0 is not preferred, then there is no capability. If mode 0 is not preferred for media type EVRCNW0 or
indication that mode 0 is supported. EVRCNW1, then there is no indication that mode 0 is supported.
However absence of this parameter or absence of mode 0 in this
parameter for media type EVRCNW shall not preclude mode 0 support
during a call where mode 0 may be requested via the MMM field.
1. To inform the capability of wideband mode support: A decoder can 1. To inform the capability of wideband mode support: A decoder can
always decode all the narrowband modes (modes 1 to 7). Unless always decode all the narrowband modes (modes 1 to 7). Unless
the decoder indicates the support of mode 0 (i.e., preference) in the decoder indicates the support of mode 0 (i.e., preference) in
this parameter or in the MMM mode request field in interleaved/ this parameter or in the MMM mode request field in interleaved/
bundled payload format, an encoder at the other side shall not bundled payload format, an encoder at the other side shall not
operate in mode 0. operate in mode 0.
2. To inform the preference to operate in a subset of modes: A set 2. To inform the preference to operate in a subset of modes: A set
has been defined so that several modes can be expressed as a has been defined so that several modes can be expressed as a
preference in one attempt. For instance, the set {4,5,6,7} preference in one attempt. For instance, the set {4,5,6,7}
signals that the receiver perfers the sender to operate in signals that the receiver prefers the sender to operate in
bandwidth-efficient narrowband modes of EVRC-NW. bandwidth-efficient narrowband modes of EVRC-NW.
Note, during an active call session using the interleaved/bundled Note, during an active call session using the interleaved/bundled
packet format, the MMM mode request received from a communication packet format, the MMM mode request received from a communication
partner complements the mode set information in mode-set-recv. A partner can contain a mode request different than the values in the
mode request with MMM=0 from a communication partner is an implicit last mode-set-recv attribute. The partner's EVRC-NW wideband
indication of the partner's EVRCNW wideband decoding capability and decoding capability is determined by the latest mode-set-recv
preference. An EVRCNW wideband capable node receiving the request attribute or MMM mode request field. For example, a mode request
can operate in wideband mode. A mode request with MMM=1, 2, ..., or with MMM=0 from a communication partner is an implicit indication of
7 from a communication partner is an implicit indication of the the partner's EVRCNW wideband decoding capability and preference. An
partner's EVRCNW narrowband decoding preference. The encoder of an EVRCNW wideband capable node receiving the request can operate in
EVRCNW node receiving the request should honor the request and wideband mode. A mode request with MMM=1, 2, ..., or 7 from a
operate in narrowband mode. communication partner is an implicit indication of the partner's
EVRCNW narrowband decoding preference. The encoder of an EVRCNW node
receiving the request shall honor the request and operate in
narrowband mode.
'sendmode' is used as a SDP mode attribute in EVRC [6], EVRC-B [2] 'sendmode' is used as a SDP mode attribute in EVRC [6], EVRC-B [2]
and EVRC-WB [3]. However it is deprecated in EVRC-NW. and EVRC-WB [3]. However it is deprecated in EVRC-NW.
11. Mapping EVRC-NW media type parameters into SDP 11. Mode Change Request/Response Considerations
The Interleaved/Bundled packet format for the EVRC family of vocoders
supports a 3-bit field (MMM) that a communication node can use to
indicate its preferred compression mode to an opposite node. The
concept of the compression mode (also known as Capacity Operating
Point) was introduced to allow a controlled trade-off between voice
quality and channel capacity. The notion makes it possible to
exercise vocoders at the highest possible (average) bit-rate (hence,
highest voice quality) when the network is lightly loaded.
Conversely, once the network load increases the vocoders can be
requested to operate at lower average bit-rates so as to absorb the
additional network load without causing an undue increase in the
frame-erasure rates; the underlying premise is that while a higher
bit-rate improves the vocoder performance, it also increases the
network loading, risking a sharp decline in voice quality should the
frame-erasure rate be too high. By contrast, a lower bit-rate mode
of operation can result in accommodation of the additional network
load without causing unduly high frame-erasure rates, resulting in
better overall quality despite the inherently lower voice quality of
the lower bit-rate mode of the vocoder.
Accordingly, the MMM field should be used to request the far-end to
transmit compressed-speech using a mode that provides the best
balance between voice quality and capacity. However, in the case of
mobile-mobile calls, for example, there are two wireless sides
involved, each with a potentially different network load level and
hence a different preferred mode. In such cases, achieving optimal
end-to-end performance depends on coherent management of the
operative mode by the two sides. This requires that even if the
local node prefers a higher bit-rate vocoder mode, it should adjust
to a lower bit-rate mode if requested by the far end, in order to
avoid potentially-high frame erasure rates due to heavy load at the
far end network. For similar reasons, in cases where a mode
requested by the far end should not be supported, it might still be
beneficial to consider switching to a supported vocoder mode
corresponding to a lower average bit-rate than requested. It is
recommended that the next lower average bit-rate supported vocoder
mode is used for encoding when a mode requested by the far end is not
supported.
A wideband-capable endpoint can use the information conveyed by the
C-bit of the RTP payload header to determine the optimal mode to
request of the far end. If the far end cannot provide Mode0 packets
(C-bit=1), then the choice of MMM can be based strictly on the local
network load. If the C-bit indicates remote end's Mode0 encoding
capability (C-bit=0), then even if the local network load is not
light, Mode0 can be requested knowing definitively that it will be
supported. This will permit operators to treat wideband-capable
mobiles preferentially, should they wish to adopt such policy.
12. Mapping EVRC-NW media type parameters into SDP
Information carried in the media type specification has a specific Information carried in the media type specification has a specific
mapping to fields in the Session Description Protocol (SDP) [10], mapping to fields in the Session Description Protocol (SDP) [10],
which is commonly used to describe RTP sessions. When SDP is used to which is commonly used to describe RTP sessions. When SDP is used to
specify sessions employing EVRC-NW encoded speech, the mapping is as specify sessions employing EVRC-NW encoded speech, the mapping is as
follows. follows.
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("EVRCNW", "EVRCNW0" or "EVRCNW1") goes in SDP o The media subtype ("EVRCNW", "EVRCNW0" or "EVRCNW1") goes in SDP
skipping to change at page 21, line 5 skipping to change at page 23, line 5
o The optional parameters 'ptime and 'maxptime' (for subtypes o The optional parameters 'ptime and 'maxptime' (for subtypes
EVRCNW, EVRCNW1) go in the SDP "a=ptime" and "a=maxptime" EVRCNW, EVRCNW1) go in the SDP "a=ptime" and "a=maxptime"
attributes, respectively. attributes, respectively.
o Any remaining parameters (for subtypes EVRCNW, EVRCNW0 and o Any remaining parameters (for subtypes EVRCNW, EVRCNW0 and
EVRCNW1) go in the SDP "a=fmtp" attribute by copying them from the EVRCNW1) go in the SDP "a=fmtp" attribute by copying them from the
media type string as a semicolon separated list of parameter=value media type string as a semicolon separated list of parameter=value
pairs. pairs.
12. Offer-Answer Model Considerations for EVRC-NW 13. Offer-Answer Model Considerations for EVRC-NW
The following considerations apply when using the SDP offer-answer The following considerations apply when using the SDP offer-answer
procedures of RFC 3264 [12] to negotiate the use of EVRC-NW payload procedures of RFC 3264 [12] to negotiate the use of EVRC-NW payload
in RTP: in RTP:
o Since EVRC-NW is an extension of both EVRC-B and EVRC-WB, the o Since EVRC-NW is an extension of both EVRC-B and EVRC-WB, the
offerer SHOULD also announce EVRC-B and EVRC-WB support in its offerer SHOULD also announce EVRC-B and EVRC-WB support in its
"m=audio" lines, with EVRC-NW as the preferred codec. This will "m=audio" lines, with EVRC-NW as the preferred codec. This will
allow interoperability with an answerer which supports only EVRC-B allow interoperability with an answerer which supports only EVRC-B
and/or EVRC-WB. and/or EVRC-WB.
skipping to change at page 23, line 5 skipping to change at page 25, line 5
o When using EVRCNW1, the entire session MUST use the same fixed o When using EVRCNW1, the entire session MUST use the same fixed
rate and mode (0-Wideband or 1-Narrowband). rate and mode (0-Wideband or 1-Narrowband).
o For additional rules which MUST be followed while negotiating DTX o For additional rules which MUST be followed while negotiating DTX
parameters, see Section 6.8 in RFC 4788 [2]. parameters, see Section 6.8 in RFC 4788 [2].
o Any unknown parameter in an SDP offer MUST be ignored by the o Any unknown parameter in an SDP offer MUST be ignored by the
receiver and MUST NOT be included in the SDP answer. receiver and MUST NOT be included in the SDP answer.
13. Declarative SDP Considerations 14. Declarative SDP Considerations
For declarative use of SDP in SAP [13] and RTSP [14], the following For declarative use of SDP in SAP [13] and RTSP [14], the following
considerations apply: considerations apply:
o Any 'maxptime' and 'ptime' values should be selected with care to o Any 'maxptime' and 'ptime' values should be selected with care to
ensure that the session's participants can achieve reasonable ensure that the session's participants can achieve reasonable
performance. performance.
o The payload format configuration parameters are all declarative o The payload format configuration parameters are all declarative
and a participant MUST use the configuration(s) that is provided and a participant MUST use the configuration(s) that is provided
for the session. More than one configuration may be provided if for the session. More than one configuration may be provided if
necessary by declaring multiple RTP payload types, however the necessary by declaring multiple RTP payload types, however the
number of types should be kept small. For declarative examples, number of types should be kept small. For declarative examples,
see Section 14. see Section 15.
o The usage of unidirectional receive only parameters, such as o The usage of unidirectional receive only parameters, such as
'mode-set-recv', should be excluded in any declarations, since 'mode-set-recv', should be excluded in any declarations, since
these parameters are meaningless in one-way streaming these parameters are meaningless in one-way streaming
applications. applications.
14. Examples 15. Examples
Some example SDP session descriptions utilizing EVRC-NW encodings Some example SDP session descriptions utilizing EVRC-NW encodings
follow. In these examples, long a=fmtp lines are folded to meet the follow. In these examples, long a=fmtp lines are folded to meet the
column width constraints of this document. The backslash ("\") at column width constraints of this document. The backslash ("\") at
the end of a line and the carriage return that follows it should be the end of a line and the carriage return that follows it should be
ignored. Note that media subtype names are case-insensitive. ignored. Note that media subtype names are case-insensitive.
Parameter names are case-insensitive both in media types and in the Parameter names are case-insensitive both in media types and in the
mapping to the SDP a=fmtp attribute. mapping to the SDP a=fmtp attribute.
Example usage of EVRCNW if wideband mode is supported: Example usage of EVRCNW if wideband mode is supported:
skipping to change at page 27, line 5 skipping to change at page 29, line 5
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6 a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4 a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0 a=fmtp:99 recvmode=0
Answer: Answer:
m=audio 55954 RTP/AVP 98 99 m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
15. Security Considerations 16. Security Considerations
Since compression is applied to the payload formats end-to-end, and Since compression is applied to the payload formats end-to-end, and
the encodings do not exhibit significant non-uniformity, the encodings do not exhibit significant non-uniformity,
implementations of this specification are subject to all the security implementations of this specification are subject to all the security
considerations specified in RFC 3558 [6]. Implementations using the considerations specified in RFC 3558 [6]. Implementations using the
payload defined in this specification are subject to the security payload defined in this specification are subject to the security
considerations discussed in RFC 3558 [6], RFC 3550 [5] and any considerations discussed in RFC 3558 [6], RFC 3550 [5] and any
appropriate profile (for example RFC 3551 [7]). appropriate profile (for example RFC 3551 [7]).
16. References 17. References
16.1. Normative References 17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for [2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for
EVRC Family Codecs", RFC 4788, January 2007. EVRC Family Codecs", RFC 4788, January 2007.
[3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced [3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced
Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype
Updates for EVRC-B Codec", RFC 5188, February 2008. Updates for EVRC-B Codec", RFC 5188, February 2008.
skipping to change at page 28, line 49 skipping to change at page 30, line 49
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[11] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia [11] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia
Files", RFC 4393, March 2006. Files", RFC 4393, March 2006.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
16.2. Informative References 17.2. Informative References
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[14] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [14] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
Author's Address Author's Address
Zheng Fang Zheng Fang
 End of changes. 20 change blocks. 
38 lines changed or deleted 96 lines changed or added

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