draft-ietf-avt-rtp-gsm-hr-00.txt   draft-ietf-avt-rtp-gsm-hr-01.txt 
Network Working Group X. Duan Network Working Group X. Duan
Internet-Draft S. Wang Internet-Draft S. Wang
Intended status: Standards Track China Mobile Communications Intended status: Standards Track China Mobile Communications
Expires: October 17, 2009 Corporation Expires: March 27, 2010 Corporation
M. Westerlund M. Westerlund
K. Hellwig K. Hellwig
I. Johansson I. Johansson
Ericsson AB Ericsson AB
Apr 15, 2009 Sept 23, 2009
RTP Payload format for GSM-HR RTP Payload format for GSM-HR
draft-ietf-avt-rtp-gsm-hr-00 draft-ietf-avt-rtp-gsm-hr-01
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 37 skipping to change at page 1, line 37
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 October 17, 2009. This Internet-Draft will expire on March 27, 2010.
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
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies the RTP payload format for packetization of This document specifies the RTP payload format for packetization of
the GSM Half-Rate speech codec. the encoded output of the GSM Half-Rate speech codec .
Requirements Language Requirements Language
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 43 skipping to change at page 2, line 43
6.1. 3 frames . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. 3 frames . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. 3 Frames with lost frame in the middle . . . . . . . . . . 10 6.2. 3 Frames with lost frame in the middle . . . . . . . . . . 10
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 11 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 11
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 12
7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 13 7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 13
7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 13 7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 14 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15
10.2. Authentication and Integrity . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Informative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies the payload format for packetization of GSM This document specifies the payload format for packetization of GSM
Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the
Real-time Transport Protocol (RTP) [RFC3550]. The payload format Real-time Transport Protocol (RTP) [RFC3550]. The payload format
supports transmission of multiple frames per payload and packet loss supports transmission of multiple frames per payload and packet loss
robustness methods using redundancy. robustness methods using redundancy.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
specified in Section 5. Examples can be found in Section 6. The specified in Section 5. Examples can be found in Section 6. The
media type and its mappings to SDP, usage in SDP offer/answer is then media type and its mappings to SDP, usage in SDP offer/answer is then
specified. The document ends with considerations around congestion specified. The document ends with considerations around congestion
control and security. control and security.
This document registers a media type (audio/gsm-hr-08) for the Real- This document registers a media type (audio/gsm-hr-08) for the Real-
time Transport protocol (RTP) payload format for the GSM-HR codec. time Transport protocol (RTP) payload format for the GSM-HR codec.
Note: This format is not compatible with the one that was drafted Note: This format is not compatible with the one that was drafted
back in 1999 to 2000 in the Internet drafts: back in 1999 to 2000 in the Internet drafts:
draft-ietf-avt-profile-new-05 to draft-ietf-avt-profile-new-09. A draft-ietf-avt-profile-new-05 to draft-ietf-avt-profile-new-09. A
later version of profile draft was published as RFC 3551 without any later version of the AVP profile draft was published as RFC 3551
specification of the GSM-HR payload format. To avoid a possible without any specification of the GSM-HR payload format. To avoid a
conflict with this older format, the media type of the payload format possible conflict with this older format, the media type of the
specified in this document has a media type name that is different payload format specified in this document has a media type name that
from (audio/gsm-hr). is different from (audio/gsm-hr).
2. Conventions 2. Conventions
This document uses the normal IETF bit-order representation. Bit This document uses the normal IETF bit-order representation. Bit
fields in figures are read left to right and then down. The left fields in figures are read left to right and then down. The left
most bits in each field is the most significant. The numbering most bit in each field is the most significant. The numbering starts
starts on 0 and ascends, where bit 0 will be the most significant. from 0 and ascends, where bit 0 will be the most significant.
3. GSM Half Rate 3. GSM Half Rate
The Global System for Mobile Communication (GSM) network provides The Global System for Mobile Communication (GSM) network provides
mobile communication services for nearly 3 billion users (status with mobile communication services for nearly 3 billion users (status
2008). The GSM Half Rate Codec (GSM-HR) is one of the speech codecs 2008). The GSM Half Rate Codec (GSM-HR) is one of the speech codecs
that are used in GSM networks. GSM-HR denotes the Half-Rate speech that are used in GSM networks. GSM-HR denotes the Half-Rate speech
codec as specified in [TS46.002]. codec as specified in [TS46.002].
Note: for historical reasons these 46-series specifications are Note: for historical reasons these 46-series specifications are
internally referenced as 06-series. A simple mapping applies, for internally referenced as 06-series. A simple mapping applies, for
example 46.020 is referenced as 06.20 and so on. example 46.020 is referenced as 06.20 and so on.
The GSM-HR codec has a frame length of 20 ms, with narrowband speech The GSM-HR codec has a frame length of 20 ms, with narrowband speech
sampled at 8 kHz, i.e. 160 samples per frame. Each speech frame is sampled at 8 kHz, i.e. 160 samples per frame. Each speech frame is
skipping to change at page 6, line 50 skipping to change at page 6, line 50
The complete payload consists of a payload table of contents (ToC) The complete payload consists of a payload table of contents (ToC)
section, followed by speech data representing one or more speech section, followed by speech data representing one or more speech
frames, SID frames or No_Data frames. The following diagram shows frames, SID frames or No_Data frames. The following diagram shows
the general payload format layout: the general payload format layout:
+-------------+------------------------- +-------------+-------------------------
| ToC section | speech data section ... | ToC section | speech data section ...
+-------------+----------------------- +-------------+-----------------------
Figure 2: General payload format layout Figure 2: General payload format layout
Each ToC is one octet and corresponds to one speech frame, the number Each ToC element is one octet and corresponds to one speech frame,
of ToC's is thus equal to the number of speech frames (including SID the number of ToC elements is thus equal to the number of speech
frames and No_Data frames). Each ToC entry represents a consecutive frames (including SID frames and No_Data frames). Each ToC entry
speech or SID or No_Data frame. The timestamp value for ToC entry represents a consecutive speech or SID or No_Data frame. The
(and corresponding speech frame data) N within the payload is (RTP timestamp value for ToC element (and corresponding speech frame data)
timestamp field + (N-1)*160) mod 2^32 . The format of the ToC octet N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32 .
is as follows. The format of the ToC element is as follows.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F| FT |R R R R| |F| FT |R R R R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: The TOC element Figure 3: The TOC element
F: Follow flag, 1 denotes that more ToC's follow, 0 denotes the last F: Follow flag, 1 denotes that more ToC elements follow, 0 denotes
ToC. the last ToC element.
R: Reserved bits, MUST be set to zero and MUST be ignored by R: Reserved bits, MUST be set to zero and MUST be ignored by
receiver. receiver.
FT: Frame type FT: Frame type
000 = Good Speech frame 000 = Good Speech frame
001 = Reserved 001 = Reserved
010 = Good SID frame 010 = Good SID frame
011 = Reserved 011 = Reserved
100 = Reserved 100 = Reserved
skipping to change at page 9, line 14 skipping to change at page 9, line 14
6. Examples 6. Examples
A few examples to highlight the payload format. A few examples to highlight the payload format.
6.1. 3 frames 6.1. 3 frames
A basic example of the aggregation of 3 consecutive speech frames A basic example of the aggregation of 3 consecutive speech frames
into a single frame. into a single frame.
The first 24 bits are ToC fields. The first 24 bits are ToC elements.
Bit 0 is '1' as another ToC field follow. Bit 0 is '1' as another ToC element follow.
Bits 1..3 is 000 = Good speech frame Bits 1..3 is 000 = Good speech frame
Bits 4..7 is 0000 = Reserved Bits 4..7 is 0000 = Reserved
Bits 8 is '1' as another ToC field follow. Bits 8 is '1' as another ToC element follow.
Bits 9..11 is 000 = Good speech frame Bits 9..11 is 000 = Good speech frame
Bits 12..15 is 0000 = Reserved Bits 12..15 is 0000 = Reserved
Bit 16 is '0', no more ToC follows Bit 16 is '0', no more ToC element follows
Bits 17..19 is 000 = Good speech frame Bits 17..19 is 000 = Good speech frame
Bits 20..23 is 0000 = Reserved Bits 20..23 is 0000 = Reserved
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8| |1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40| |b9 Frame 1 b40|
+ + + +
skipping to change at page 10, line 11 skipping to change at page 10, line 11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112| |b105 b112|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
6.2. 3 Frames with lost frame in the middle 6.2. 3 Frames with lost frame in the middle
An example of payload carrying 3 frames where the middle one is An example of payload carrying 3 frames where the middle one is
No_Data, for example due to loss prior to transmission by the RTP No_Data, for example due to loss prior to transmission by the RTP
source. source.
The first 24 bits are ToC fields. The first 24 bits are ToC elements.
Bit 0 is '1' as another ToC field follow. Bit 0 is '1' as another ToC element follow.
Bits 1..3 is 000 = Good speech frame Bits 1..3 is 000 = Good speech frame
Bits 4..7 is 0000 = Reserved Bits 4..7 is 0000 = Reserved
Bits 8 is '1' as another ToC field follow. Bits 8 is '1' as another ToC element follow.
Bits 9..11 is 111 = No_Data frame Bits 9..11 is 111 = No_Data frame
Bits 12..15 is 0000 = Reserved Bits 12..15 is 0000 = Reserved
Bit 16 is '0', no more ToC follows Bit 16 is '0', no more ToC element follows
Bits 17..19 is 000 = Good speech frame Bits 17..19 is 000 = Good speech frame
Bits 20..23 is 0000 = Reserved Bits 20..23 is 0000 = Reserved
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8| |1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40| |b9 Frame 1 b40|
+ + + +
skipping to change at page 11, line 29 skipping to change at page 11, line 29
Subtype name: GSM-HR-08 Subtype name: GSM-HR-08
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
max-red: The maximum duration in milliseconds that elapses between max-red: The maximum duration in milliseconds that elapses between
the primary (first) transmission of a frame and any redundant the primary (first) transmission of a frame and any redundant
transmission that the sender will use. This parameter allows a transmission that the sender will use. This parameter allows a
receiver to have a bounded delay when redundancy is used. Allowed receiver to have a bounded delay when redundancy is used. Allowed
values are between 0 (no redundancy will be used) and 65535. If values are integers between 0 (no redundancy will be used) and
the parameter is omitted, no limitation on the use of redundancy 65535. If the parameter is omitted, no limitation on the use of
is present. redundancy is present.
ptime: see [RFC4566]. ptime: see [RFC4566].
maxptime: see [RFC4566]. maxptime: see [RFC4566].
Encoding considerations: Encoding considerations:
This media type is framed and binary, see section 4.8 in RFC4288 This media type is framed and binary, see section 4.8 in RFC4288
[RFC4288]. [RFC4288].
skipping to change at page 14, line 35 skipping to change at page 14, line 35
overhead constraints. Packetizing more frames in each RTP payload overhead constraints. Packetizing more frames in each RTP payload
can reduce the number of packets sent and hence the header overhead, can reduce the number of packets sent and hence the header overhead,
at the expense of increased delay and reduced error robustness. If at the expense of increased delay and reduced error robustness. If
forward error correction (FEC) is used, the amount of FEC-induced forward error correction (FEC) is used, the amount of FEC-induced
redundancy needs to be regulated such that the use of FEC itself does redundancy needs to be regulated such that the use of FEC itself does
not cause a congestion problem. not cause a congestion problem.
10. Security Considerations 10. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in RTP are subject to the security considerations discussed in the RTP
[RFC3550] and any applicable profile such as AVP [RFC3551] or SAVP specification [RFC3550] , and in any applicable RTP profile. The
[RFC3711]. As this format transports encoded audio, the main main security considerations for the RTP packet carrying the RTP
security issues include confidentiality, integrity protection, and payload format defined within this memo are confidentiality,
data origin authentication of the audio itself. The payload format integrity and source authenticity. Confidentiality is achieved by
itself does not have any built-in security mechanisms. Any suitable encryption of the RTP payload. Integrity of the RTP packets through
external mechanisms, such as SRTP [RFC3711], MAY be used. suitable cryptographic integrity protection mechanism. Cryptographic
system may also allow the authentication of the source of the
payload. A suitable security mechanism for this RTP payload format
should provide confidentiality, integrity protection and at least
source authentication capable of determining if an RTP packet is from
a member of the RTP session or not.
This payload format and the GSM-HR decoder do not exhibit any Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signalling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable
the usage of SRTP [RFC3711] is recommended. Other mechanism that may
be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
also other alternatives may exist.
This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data. denial-of-service threat due to the receipt of pathological data.
The payload format or the codec data does not contain any type of Nor does the RTP payload format contain any active content.
active content such as scripts.
10.1. Confidentiality
In order to ensure confidentiality of the encoded audio, all audio
data bits MUST be encrypted. There is less need to encrypt the
payload header or the table of contents since they only carry
information about the frame type. This information could also be
useful to a third party, for example, for quality monitoring.
10.2. Authentication and Integrity
To authenticate the sender of the audio-stream, an external mechanism
MUST be used. It is RECOMMENDED that such a mechanism protects both
the complete RTP header and the payload (audio and data bits). Data
tampering by a man-in-the-middle attacker could replace audio content
and also result in erroneous depacketization/decoding that could
lower the audio quality.
11. Acknowledgements 11. Acknowledgements
The author would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky The author would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky
Wang and Ying Zhang for their initial work in this area. Many thanks Wang and Ying Zhang for their initial work in this area. Many thanks
also go to Tomas Frankkila, Karl Hellwig for useful input and also go to Tomas Frankkila for useful input and comments.
comments.
12. References 12. References
12.1. Informative References 12.1. Normative References
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
12.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.
[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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 17, line 5 skipping to change at page 16, line 13
[TS46.002] [TS46.002]
3GPP, "Specification : 3GPP TS 46.002 http://www.3gpp.org/ 3GPP, "Specification : 3GPP TS 46.002 http://www.3gpp.org/
ftp/Specs/archive/46_series/46.002/46002-700.zip", ftp/Specs/archive/46_series/46.002/46002-700.zip",
June 2007. June 2007.
[TS46.020] [TS46.020]
3GPP, "Specification : 3GPP TS 46.020 http://www.3gpp.org/ 3GPP, "Specification : 3GPP TS 46.020 http://www.3gpp.org/
ftp/Specs/archive/46_series/46.002/46020-700.zip", ftp/Specs/archive/46_series/46.002/46020-700.zip",
June 2007. June 2007.
12.2. Informative References
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Xiaodong Duan Xiaodong Duan
China Mobile Communications Corporation China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District 53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053 Beijing, 100053
P.R. China P.R. China
Phone: Phone:
Fax: Fax:
 End of changes. 25 change blocks. 
93 lines changed or deleted 91 lines changed or added

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