doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc3557.txt b/doc/rfc/rfc3557.txt
new file mode 100644
index 0000000..7cf50c0
--- /dev/null
+++ b/doc/rfc/rfc3557.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        Q. Xie, Ed.
+Request for Comments: 3557                                Motorola, Inc.
+Category: Standards Track                                      July 2003
+
+
+                         RTP Payload Format for
+European Telecommunications Standards Institute (ETSI) European Standard
+           ES 201 108 Distributed Speech Recognition Encoding
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document specifies an RTP payload format for encapsulating
+   European Telecommunications Standards Institute (ETSI) European
+   Standard (ES) 201 108 front-end signal processing feature streams for
+   distributed speech recognition (DSR) systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xie                         Standards Track                     [Page 1]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+Table of Contents
+
+   1.  Conventions and Acronyms . . . . . . . . . . . . . . . . . . .  2
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       2.1.  ETSI ES 201 108 DSR Front-end Codec. . . . . . . . . . .  3
+       2.2.  Typical Scenarios for Using DSR Payload Format . . . . .  4
+   3.  ES 201 108 DSR RTP Payload Format. . . . . . . . . . . . . . .  5
+       3.1.  Consideration on Number of FPs in Each RTP Packet. . . .  6
+       3.2.  Support for Discontinuous Transmission . . . . . . . . .  6
+   4.  Frame Pair Formats . . . . . . . . . . . . . . . . . . . . . .  7
+       4.1.  Format of Speech and Non-speech FPs. . . . . . . . . . .  7
+       4.2.  Format of Null FP. . . . . . . . . . . . . . . . . . . .  8
+       4.3.  RTP header usage . . . . . . . . . . . . . . . . . . . .  8
+   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  9
+       5.1.  Mapping MIME Parameters into SDP . . . . . . . . . . . . 10
+   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
+   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+       9.1.  Normative References . . . . . . . . . . . . . . . . . . 11
+       9.2.  Informative References . . . . . . . . . . . . . . . . . 12
+   10. IPR Notices. . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
+   12. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 14
+   13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
+
+1.  Conventions 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].
+
+   The following acronyms are used in this document:
+
+   DSR  - Distributed Speech Recognition
+
+   ETSI - the European Telecommunications Standards Institute
+
+   FP   - Frame Pair
+
+   DTX  - Discontinuous Transmission
+
+2.  Introduction
+
+   Motivated by technology advances in the field of speech recognition,
+   voice interfaces to services (such as airline information systems,
+   unified messaging) are becoming more prevalent.  In parallel, the
+   popularity of mobile devices has also increased dramatically.
+
+
+
+Xie                         Standards Track                     [Page 2]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+   However, the voice codecs typically employed in mobile devices were
+   designed to optimize audible voice quality and not speech recognition
+   accuracy, and using these codecs with speech recognizers can result
+   in poor recognition performance.  For systems that can be accessed
+   from heterogeneous networks using multiple speech codecs, recognition
+   system designers are further challenged to accommodate the
+   characteristics of these differences in a robust manner.  Channel
+   errors and lost data packets in these networks result in further
+   degradation of the speech signal.
+
+   In traditional systems as described above, the entire speech
+   recognizer lies on the server.  It is forced to use incoming speech
+   in whatever condition it arrives after the network decodes the
+   vocoded speech.  To address this problem, we use a distributed speech
+   recognition (DSR) architecture.  In such a system, the remote device
+   acts as a thin client, also known as the front-end, in communication
+   with a speech recognition server, also called a speech engine.  The
+   remote device processes the speech, compresses the data, and adds
+   error protection to the bitstream in a manner optimal for speech
+   recognition.  The speech engine then uses this representation
+   directly, minimizing the signal processing necessary and benefiting
+   from enhanced error concealment.
+
+   To achieve interoperability with different client devices and speech
+   engines, a common format is needed.  Within the "Aurora" DSR working
+   group of the European Telecommunications Standards Institute (ETSI),
+   a payload has been defined and was published as a standard [ES201108]
+   in February 2000.
+
+   For voice dialogues between a caller and a voice service, low latency
+   is a high priority along with accurate speech recognition.  While
+   jitter in the speech recognizer input is not particularly important,
+   many issues related to speech interaction over an IP-based connection
+   are still relevant.  Therefore, it is desirable to use the DSR
+   payload in an RTP-based session.
+
+2.1  ETSI ES 201 108 DSR Front-end Codec
+
+   The ETSI Standard ES 201 108 for DSR [ES201108] defines a signal
+   processing front-end and compression scheme for speech input to a
+   speech recognition system.  Some relevant characteristics of this
+   ETSI DSR front-end codec are summarized below.
+
+   The coding algorithm, a standard mel-cepstral technique common to
+   many speech recognition systems, supports three raw sampling rates: 8
+   kHz, 11 kHz, and 16 kHz.  The mel-cepstral calculation is a frame-
+   based scheme that produces an output vector every 10 ms.
+
+
+
+
+Xie                         Standards Track                     [Page 3]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+   After calculation of the mel-cepstral representation, the
+   representation is first quantized via split-vector quantization to
+   reduce the data rate of the encoded stream.  Then, the quantized
+   vectors from two consecutive frames are put into an FP, as described
+   in more detail in Section 4.1.
+
+2.2  Typical Scenarios for Using DSR Payload Format
+
+   The diagrams in Figure 1 show some typical use scenarios of the ES
+   201 108 DSR RTP payload format.
+
+   +--------+                     +----------+
+   |IP USER |  IP/UDP/RTP/DSR     |IP SPEECH |
+   |TERMINAL|-------------------->|  ENGINE  |
+   |        |                     |          |
+   +--------+                     +----------+
+
+     a) IP user terminal to IP speech engine
+
+   +--------+  DSR over      +-------+                +----------+
+   | Non-IP |  Circuit link  |       | IP/UDP/RTP/DSR |IP SPEECH |
+   |  USER  |:::::::::::::::>|GATEWAY|--------------->|  ENGINE  |
+   |TERMINAL|  ETSI payload  |       |                |          |
+   +--------+  format        +-------+                +----------+
+
+     b) non-IP user terminal to IP speech engine via a gateway
+
+   +--------+                  +-------+  DSR over       +----------+
+   |IP USER |  IP/UDP/RTP/DSR  |       |  circuit link   |  Non-IP  |
+   |TERMINAL|----------------->|GATEWAY|::::::::::::::::>|  SPEECH  |
+   |        |                  |       |  ETSI payload   |  ENGINE  |
+   +--------+                  +-------+  format         +----------+
+
+     c) IP user terminal to non-IP speech engine via a gateway
+
+         Figure 1: Typical Scenarios for Using DSR Payload Format.
+
+   For the different scenarios in Figure 1, the speech recognizer always
+   resides in the speech engine.  A DSR front-end encoder inside the
+   User Terminal performs front-end speech processing and sends the
+   resultant data to the speech engine in the form of "frame pairs"
+   (FPs).  Each FP contains two sets of encoded speech vectors
+   representing 20ms of original speech.
+
+
+
+
+
+
+
+
+Xie                         Standards Track                     [Page 4]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+3.  ES 201 108 DSR RTP Payload Format
+
+   An ES 201 108 DSR RTP payload datagram consists of a standard RTP
+   header [RFC3550] followed by a DSR payload.  The DSR payload itself
+   is formed by concatenating a series of ES 201 108 DSR FPs (defined in
+   Section 4).
+
+   FPs are always packed bit-contiguously into the payload octets
+   beginning with the most significant bit.  For ES 201 108 front-end,
+   the size of each FP is 96 bits or 12 octets (see Sections 4.1 and
+   4.2).  This ensures that a DSR payload will always end on an octet
+   boundary.
+
+   The following example shows a DSR RTP datagram carrying a DSR payload
+   containing three 96-bit-long FPs (bit 0 is the MSB):
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                    RTP header in [RFC3550]                    /
+   \                                                               \
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |                                                               |
+   +                                                               +
+   |                         FP #1 (96 bits)                       |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                                                               +
+   |                         FP #2 (96 bits)                       |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                                                               +
+   |                         FP #3 (96 bits)                       |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 2. An example of an ES 201 108 DSR RTP payload.
+
+
+
+
+
+
+
+
+Xie                         Standards Track                     [Page 5]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+3.1 Consideration on Number of FPs in Each RTP Packet
+
+   The number of FPs per payload packet should be determined by the
+   latency and bandwidth requirements of the DSR application using this
+   payload format.  In particular, using a smaller number of FPs per
+   payload packet in a session will result in lowered bandwidth
+   efficiency due to the RTP/UDP/IP header overhead, while using a
+   larger number of FPs per packet will cause longer end-to-end delay
+   and hence increased recognition latency.  Furthermore, carrying a
+   larger number of FPs per packet will increase the possibility of
+   catastrophic packet loss; the loss of a large number of consecutive
+   FPs is a situation most speech recognizers have difficulty dealing
+   with.
+
+   It is therefore RECOMMENDED that the number of FPs per DSR payload
+   packet be minimized, subject to meeting the application's
+   requirements on network bandwidth efficiency.  RTP header compression
+   techniques, such as those defined in [RFC2508] and [RFC3095], should
+   be considered to improve network bandwidth efficiency.
+
+3.2 Support for Discontinuous Transmission
+
+   The DSR RTP payloads may be used to support discontinuous
+   transmission (DTX) of speech, which allows that DSR FPs are sent only
+   when speech has been detected at the terminal equipment.
+
+   In DTX a set of DSR frames coding an unbroken speech segment
+   transmitted from the terminal to the server is called a transmission
+   segment.  A DSR frame inside such a transmission segment can be
+   either a speech frame or a non-speech frame, depending on the nature
+   of the section of the speech signal it represents.
+
+   The end of a transmission segment is determined at the sending end
+   equipment when the number of consecutive non-speech frames exceeds a
+   pre-set threshold, called the hangover time.  A typical value used
+   for the hangover time is 1.5 seconds.
+
+   After all FPs in a transmission segment are sent, the front-end
+   SHOULD indicate the end of the current transmission segment by
+   sending one or more Null FPs (defined in Section 4.2).
+
+
+
+
+
+
+
+
+
+
+
+Xie                         Standards Track                     [Page 6]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+4.  Frame Pair Formats
+
+4.1 Format of Speech and Non-speech FPs
+
+   The following mel-cepstral frame MUST be used, as defined in
+   [ES201108]:
+
+   As defined in [ES201108], pairs of the quantized 10ms mel-cepstral
+   frames MUST be grouped together and protected with a 4-bit CRC,
+   forming a 92-bit long FP:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Frame #1  (44 bits)                      |
+   +                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       |          Frame #2 (44 bits)           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+                       +-+-+-+-+-+-+-+-+
+   |                                               | CRC   |0|0|0|0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The length of each frame is 44 bits representing 10ms of voice. The
+   following mel-cepstral frame formats MUST be used when forming an FP:
+
+   Frame #1 in FP:
+   ===============
+       (MSB)                                     (LSB)
+         0     1     2     3     4     5     6     7
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      :  idx(2,3) |            idx(0,1)               |    Octet 1
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      :       idx(4,5)        |     idx(2,3) (cont)   :    Octet 2
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      |             idx(6,7)              |idx(4,5)(cont)  Octet 3
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+       idx(10,11) |              idx(8,9)             |    Octet 4
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      :       idx(12,13)      |   idx(10,11) (cont)   :    Octet 5
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+                              |   idx(12,13) (cont)   :    Octet 6/1
+                              +-----+-----+-----+-----+
+
+
+
+
+
+
+
+
+
+
+Xie                         Standards Track                     [Page 7]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+   Frame #2 in FP:
+   ===============
+       (MSB)                                     (LSB)
+         0     1     2     3     4     5     6     7
+      +-----+-----+-----+-----+
+      :        idx(0,1)       |                            Octet 6/2
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      |              idx(2,3)             |idx(0,1)(cont)  Octet 7
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      :  idx(6,7) |              idx(4,5)             |    Octet 8
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      :        idx(8,9)       |      idx(6,7) (cont)  :    Octet 9
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      |          idx(10,11)               |idx(8,9)(cont)  Octet 10
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      |                   idx(12,13)                  |    Octet 11
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+
+   Therefore, each FP represents 20ms of original speech.  Note, as
+   shown above, each FP MUST be padded with 4 zeros to the end in order
+   to make it aligned to the 32-bit word boundary.  This makes the size
+   of an FP 96 bits, or 12 octets.  Note, this padding is separate from
+   padding indicated by the P bit in the RTP header.
+
+   The 4-bit CRC MUST be calculated using the formula defined in 6.2.4
+   in [ES201108]. The definition of the indices and the determination of
+   their value are also described in [ES201108].
+
+4.2 Format of Null FP
+
+   A Null FP for the ES 201 108 front-end codec is defined by setting
+   the content of the first and second frame in the FP to null (i.e.,
+   filling the first 88 bits of the FP with 0's).  The 4-bit CRC MUST be
+   calculated the same way as described in 6.2.4 in [ES201108], and 4
+   zeros MUST be padded to the end of the Null FP to make it 32-bit word
+   aligned.
+
+4.3 RTP header usage
+
+   The format of the RTP header is specified in [RFC3550].  This payload
+   format uses the fields of the header in a manner consistent with that
+   specification.
+
+   The RTP timestamp corresponds to the sampling instant of the first
+   sample encoded for the first FP in the packet.  The timestamp clock
+   frequency is the same as the sampling frequency, so the timestamp
+   unit is in samples.
+
+
+
+
+Xie                         Standards Track                     [Page 8]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+   As defined by ES 201 108 front-end codec, the duration of one FP is
+   20 ms, corresponding to 160, 220, or 320 encoded samples with
+   sampling rate of 8, 11, or 16 kHz being used at the front-end,
+   respectively. Thus, the timestamp is increased by 160, 220, or 320
+   for each consecutive FP, respectively.
+
+   The DSR payload for ES 201 108 front-end codes is always an integral
+   number of octets.  If additional padding is required for some other
+   purpose, then the P bit in the RTP in the header may be set and
+   padding appended as specified in [RFC3550].
+
+   The RTP header marker bit (M) should be set following the general
+   rules defined in [RFC3551].
+
+   The assignment of an RTP payload type for this new packet format is
+   outside the scope of this document, and will not be specified here.
+   It is expected that the RTP profile under which this payload format
+   is being used will assign a payload type for this encoding or specify
+   that the payload type is to be bound dynamically.
+
+5.  IANA Considerations
+
+   One new MIME subtype registration is required for this payload type,
+   as defined below.
+
+   This section also defines the optional parameters that may be used to
+   describe a DSR session.  The parameters are defined here as part of
+   the MIME subtype registration.  A mapping of the parameters into the
+   Session Description Protocol (SDP) [RFC2327] is also provided in 5.1
+   for those applications that use SDP.
+
+   Media Type name: audio
+
+   Media subtype name: dsr-es201108
+
+   Required parameters: none
+
+   Optional parameters:
+
+   rate: Indicates the sample rate of the speech.  Valid values include:
+      8000, 11000, and 16000.  If this parameter is not present, 8000
+      sample rate is assumed.
+
+   maxptime: The maximum amount of media which can be encapsulated in
+      each packet, expressed as time in milliseconds.  The time shall be
+      calculated as the sum of the time the media present in the packet
+      represents.  The time SHOULD be a multiple of the frame pair size
+      (i.e., one FP <-> 20ms).
+
+
+
+Xie                         Standards Track                     [Page 9]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+      If this parameter is not present, maxptime is assumed to be 80ms.
+
+      Note, since the performance of most speech recognizers are
+      extremely sensitive to consecutive FP losses, if the user of the
+      payload format expects a high packet loss ratio for the session,
+      it MAY consider to explicitly choose a maxptime value for the
+      session that is shorter than the default value.
+
+   ptime: see RFC2327 [RFC2327].
+
+   Encoding considerations : This type is defined for transfer via RTP
+      [RFC3550] as described in Sections 3 and 4 of RFC 3557.
+
+   Security considerations : See Section 6 of RFC 3557.
+
+   Person & email address to contact for further information:
+      Qiaobing.Xie@motorola.com
+
+   Intended usage: COMMON.  It is expected that many VoIP applications
+      (as well as mobile applications) will use this type.
+
+   Author/Change controller:
+      Qiaobing.Xie@motorola.com
+      IETF Audio/Video transport working group
+
+5.1 Mapping MIME Parameters into SDP
+
+   The information carried in the MIME media type specification has a
+   specific mapping to fields in the Session Description Protocol (SDP)
+   [RFC2327], which is commonly used to describe RTP sessions.  When SDP
+   is used to specify sessions employing ES 201 018 DSR codec, the
+   mapping is as follows:
+
+   o  The MIME type ("audio") goes in SDP "m=" as the media name.
+
+   o  The MIME subtype ("dsr-es201108") goes in SDP "a=rtpmap" as the
+      encoding name.
+
+   o  The optional parameter "rate" also goes in "a=rtpmap" as clock
+      rate.
+
+   o  The optional parameters "ptime" and "maxptime" go in the SDP
+      "a=ptime" and "a=maxptime" attributes, respectively.
+
+
+
+
+
+
+
+
+Xie                         Standards Track                    [Page 10]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+   Example of usage of ES 201 108 DSR:
+
+      m=audio 49120 RTP/AVP 101
+      a=rtpmap:101 dsr-es201108/8000
+      a=maxptime:40
+
+6.  Security Considerations
+
+   Implementations using the payload defined in this specification are
+   subject to the security considerations discussed in the RTP
+   specification [RFC3550] and the RTP profile [RFC3551].  This payload
+   does not specify any different security services.
+
+7.  Contributors
+
+   The following individuals contributed to the design of this payload
+   format and the writing of this document: Q. Xie (Motorola), D. Pearce
+   (Motorola), S. Balasuriya (Motorola), Y. Kim (VerbalTek), S. H. Maes
+   (IBM), and, Hari Garudadri (Qualcomm).
+
+8.  Acknowledgments
+
+   The design presented here benefits greatly from an earlier work on
+   DSR RTP payload design by Jeff Meunier and Priscilla Walther.  The
+   authors also wish to thank Brian Eberman, John Lazzaro, Magnus
+   Westerlund, Rainu Pierce, Priscilla Walther, and others for their
+   review and valuable comments on this document.
+
+9.  References
+
+9.1  Normative References
+
+   [ES201108]   European Telecommunications Standards Institute (ETSI)
+                Standard ES 201 108, "Speech Processing, Transmission
+                and Quality Aspects (STQ); Distributed Speech
+                Recognition; Front-end Feature Extraction Algorithm;
+                Compression Algorithms," Ver. 1.1.2, April 11, 2000.
+
+   [RFC3550]    Schulzrinne, H., Casner, S., Jacobson, V. and R.
+                Frederick, "RTP: A Transport Protocol for Real-Time
+                Applications", RFC 3550, July 2003.
+
+   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
+                3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Xie                         Standards Track                    [Page 11]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+   [RFC2327]    Handley, M. and V. Jacobson, "SDP: Session Description
+                Protocol", RFC 2327, April 1998.
+
+9.2  Informative References
+
+   [RFC3551]    Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+                and Video Conferences with Minimal Control", RFC 3551,
+                July 2003.
+
+   [RFC2508]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+                Headers for Low-Speed Serial Links", RFC 2508, February
+                1999.
+
+   [RFC3095]    Bormann, C., Burmeister, C., Degermark, M., Fukushima,
+                H., Hannu, H., Jonsson, L-E, Hakenberg, R., Koren, T.,
+                Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
+                K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust
+                Header Compression (ROHC): Framework and four profiles",
+                RFC 3095, July 2001.
+
+10.  IPR Notices
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made be made available, or the result of an attempt
+   made to obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+Xie                         Standards Track                    [Page 12]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+11.  Authors' Addresses
+
+   David Pearce
+   Motorola Labs
+   UK Research Laboratory
+   Jays Close
+   Viables Industrial Estate
+   Basingstoke, HANTS, RG22 4PD
+
+   Phone: +44 (0)1256 484 436
+   EMail: bdp003@motorola.com
+
+
+   Senaka Balasuriya
+   Motorola, Inc.
+   600 U.S Highway 45
+   Libertyville, IL 60048, USA
+
+   Phone: +1-847-523-0440
+   EMail: Senaka.Balasuriya@motorola.com
+
+
+   Yoon Kim
+   VerbalTek, Inc.
+   2921 Copper Rd.
+   Santa Clara, CA 95051
+
+   Phone: +1-408-768-4974
+   EMail: yoonie@verbaltek.com
+
+
+   Stephane H. Maes, PhD,
+   Oracle
+   500 Oracle Parkway, M/S 4op634
+   Redwood City, CA 94065 USA
+
+   Phone: +1-650-607-6296.
+   EMail: stephane.maes@oracle.com
+
+
+   Hari Garudadri
+   Qualcomm Inc.
+   5775, Morehouse Dr.
+   San Diego, CA 92121-1714, USA
+
+   Phone: +1-858-651-6383
+   EMail: hgarudad@qualcomm.com
+
+
+
+
+Xie                         Standards Track                    [Page 13]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+12.  Editor's Address
+
+   Qiaobing Xie
+   Motorola, Inc.
+   1501 W. Shure Drive, 2-F9
+   Arlington Heights, IL 60004, USA
+
+   Phone: +1-847-632-3028
+   EMail: Qiaobing.Xie@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xie                         Standards Track                    [Page 14]
+
+RFC 3557         RTP Payload Format for DSR ES 201 108         July 2003
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xie                         Standards Track                    [Page 15]
+