[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         J. Spittka
Internet-Draft                                                 H. Astrom
Intended status: Informational                                    K. Vos
Expires: January 7, 2010                         Skype Technologies S.A.
                                                            July 6, 2009


  RTP Payload Format and File Storage Format for SILK Speech and Audio
                                 Codec
                 draft-spittka-silk-payload-format-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.







Spittka, et al.          Expires January 7, 2010                [Page 1]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


Abstract

   This document defines the Real-time Transport Protocol (RTP) payload
   format and file storage format for packetization of SILK encoded
   speech and audio data that is essential to implement SILK in the most
   compatible way.  Further, media type registrations are described for
   the RTP payload format and the file storage format.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions, Definitions and Acronyms used in this document  .  4
   3.  SILK Codec . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Adaptive Network Bit Rate  . . . . . . . . . . . . . . . .  6
     3.2.  Discontinuous Transmission (DTX) . . . . . . . . . . . . .  6
     3.3.  Forward Error Correction (FEC) . . . . . . . . . . . . . .  7
   4.  SILK RTP Payload Format  . . . . . . . . . . . . . . . . . . .  8
     4.1.  RTP Header Usage . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Payload Structure  . . . . . . . . . . . . . . . . . . . .  8
   5.  SILK Storage Format  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Storage Header Structure . . . . . . . . . . . . . . . . .  9
     5.2.  Storage Block Structure  . . . . . . . . . . . . . . . . .  9
   6.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  SILK Media Type Registration . . . . . . . . . . . . . . . 12
     7.2.  Mapping to SDP Parameters  . . . . . . . . . . . . . . . . 14
       7.2.1.  Offer-Answer Model Considerations for SILK . . . . . . 15
       7.2.2.  Declarative SDP Considerations for SILK  . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20


















Spittka, et al.          Expires January 7, 2010                [Page 2]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


1.  Introduction

   SILK is a speech and audio codec developed internally at Skype which
   is used as the new default codec for all Skype to Skype calls.  It is
   highly scalable in terms of audio bandwidth, network bit rate, and
   complexity, making it the codec of choice for multiple modes and
   applications.

   Skype encourages 3rd party partners to adopt SILK for applications
   that may or may not be able to inter-operate with the Skype network.
   Therefore, this document defines the Real-time Transport Protocol
   (RTP) [RFC3550] payload format and file storage format for
   packetization of SILK encoded speech and audio data that is essential
   to implement SILK in the most compatible way.  Further, media type
   registrations are described for the RTP payload format and the file
   storage format.  More information about SILK can be obtained at
   https://developer.skype.com/silk.


































Spittka, et al.          Expires January 7, 2010                [Page 3]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


2.  Conventions, Definitions and Acronyms used in this document

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

   CPU:  Central Processing Unit
   IP:  Internet Protocol
   PSTN:  Public Switched Telephone Network
   Samples:  Speech or audio samples
   SDP:  Session Description Protocol








































Spittka, et al.          Expires January 7, 2010                [Page 4]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


3.  SILK Codec

   The SILK speech and audio codec is highly scalable in terms of audio
   bandwidth, network bit rate, and complexity.

   SILK supports four different audio bandwidths, narrowband at 8000 Hz
   sampling frequency, mediumband at 12000 Hz sampling frequency,
   wideband at 16000 Hz sampling frequency, and super wideband at 24000
   Hz sampling frequency.  Narrowband mode SHOULD only be used to
   interface to PSTN networks or on low end devices that do not support
   greater than 8000 Hz sampling frequency.  Mediumband mode SHOULD be
   used for lower end devices that do not support greater than 12000 Hz
   sampling frequency or are under severe network bandwidth constrains
   (e.g. wireless devices).  Wideband mode SHOULD be used for all-IP
   platforms that do not support greater than 16000 Hz sampling
   frequency.  Super wideband mode SHOULD be used on all platforms that
   support 24000 Hz and greater sampling frequency.

   The network bit rate is adaptive within the range specified in
   Table 1 for corresponding audio bandwidths.  The average network bit
   rate can be defined and modified in real-time while the actual bit
   rate will be dependent on the input signal and change over time.

                 +----------------+---------+-----------+
                 |                | fs (Hz) | BR (kbps) |
                 +----------------+---------+-----------+
                 |   Narrowband   |   8000  |   6 - 20  |
                 |                |         |           |
                 |   Mediumband   |  12000  |   7 - 25  |
                 |                |         |           |
                 |    Wideband    |  16000  |   8 - 30  |
                 |                |         |           |
                 | Super Wideband |  24000  |  12 - 40  |
                 +----------------+---------+-----------+

   fs specifies the audio sampling frequency in Hertz (Hz); BR specifies
        the adaptive bit rate range in kilobits per second (kbps).

                                  Table 1

   Complexity can be scaled to optimize for CPU resources in real-time,
   mostly in trade-off to network bit rate.

   The internal frame size of SILK is 20 ms.  The SILK Encoder can be
   set to bundle up to five internal frames into a single frame output,
   allowing for 20, 40, 60, 80, or 100 ms frames of encoded speech or
   audio data.




Spittka, et al.          Expires January 7, 2010                [Page 5]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


   Table 2 below shows the number of samples contained in one frame of
   speech or audio, for the various frame sizes and sampling rates.

      +------------------------+------+------+------+------+-------+
      |       Frame size       | 20ms | 40ms | 60ms | 80ms | 100ms |
      +------------------------+------+------+------+------+-------+
      |   Narrowband samples   |  160 |  320 |  480 |  640 |  800  |
      |                        |      |      |      |      |       |
      |   Mediumband samples   |  240 |  480 |  720 |  960 |  1200 |
      |                        |      |      |      |      |       |
      |    Wideband samples    |  320 |  640 |  960 | 1280 |  1600 |
      |                        |      |      |      |      |       |
      | Super Wideband samples |  480 |  960 | 1440 | 1920 |  2400 |
      +------------------------+------+------+------+------+-------+

       Samples contained in one frame, for different frame sizes and
                              sampling rates.

                                  Table 2

   SILK operates at a very low algorithmic delay, consisting of
   packetization delay, i.e. 20, 40, 60, 80, or 100ms, plus 5ms look-
   ahead delay.

3.1.  Adaptive Network Bit Rate

   The SILK Encoder can be set to output encoded speech or audio data at
   a defined average bit rate.  Since the achieved bit rate for each
   frame varies with the complexity and perceptual importance of the
   input audio or speech signal, the specified average bit rate is for
   an active, i.e. non-silent, signal.  The average bit rate can be
   adjusted on a per frame basis.  This allows support for congestion
   control and network load management.  To do this efficiently,
   information about the capacity of a channel or storage device has to
   be available.  There are various methods to obtain this information
   that are outside the scope of this document.

3.2.  Discontinuous Transmission (DTX)

   The SILK codec is, as described in Section 3.1 of this document, a
   codec with adaptive bit rate.  The bit rate will automatically be
   reduced for certain input signals like periods of silence.  During
   continuous transmission mode the bit rate will be reduced, when the
   input signal allows to do so, but the transmission to the receiver
   itself is not interrupted.  Therefore, the received signal will
   maintain the same high level of quality over the full duration of a
   transmission while minimizing the average bit rate over time.




Spittka, et al.          Expires January 7, 2010                [Page 6]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


   In cases where the average bit rate of SILK needs to be reduced even
   further, the SILK encoder may be set to use a discontinuous
   transmission mode (DTX), where parts of the encoded signal that
   correspond to periods of silence in the input speech or audio signal
   are not transmitted to the receiver.

   On the receiving side, the non-transmitted parts will be handled by a
   frame loss concealment unit in the SILK decoder which generates a
   comfort noise signal to replace the non transmitted parts of the
   speech or audio signal.

   The DTX mode of SILK will have a slightly lower speech or audio
   quality than the continuous mode.  Therefore, it is RECOMMENDED to
   use SILK in the continuous mode unless restraints of network
   bandwidth are severe.

3.3.  Forward Error Correction (FEC)

   TBD
































Spittka, et al.          Expires January 7, 2010                [Page 7]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


4.  SILK RTP Payload Format

   The payload format for SILK consists of the RTP header and SILK
   payload data.

4.1.  RTP Header Usage

   The format of the RTP header is specified in [RFC3550].  The SILK
   payload format uses the fields of the RTP header consistent with this
   specification.

   The payload length of SILK is a multiple number of octets and
   therefore no padding is required.  The payload MAY be padded by an
   integer number of octets according to [RFC3550].

   The marker bit (M) of the RTP header has no function in combination
   with SILK and MAY be ignored.

   The RTP payload type for SILK has not been assigned statically and is
   expected to be assigned dynamically.

   The receiving side MUST be prepared to receive duplicates of RTP
   packets.  Only one of those payloads MUST be provided to the SILK
   decoder for decoding and others MUST be discarded.

   Depending on what mode of sampling frequency is used for SILK, 8000,
   12000, 16000, or 24000 Hz, the RTP timestamp clock frequency has to
   be adjusted accordingly and is the same as the sampling frequency.
   The unit for the timestamp is samples.  The RTP timestamp corresponds
   to the sample time of the first encoded sample in the encoded frame.
   Therefore, the timestamp is increased by the number of samples
   provided in Table 2, depending on the sampling frequency and frame
   size.

4.2.  Payload Structure

   The SILK encoder can be set to output encoded frames representing 20,
   40, 60, 80, or 100 ms of speech or audio data.  Only one frame output
   from the encoder MUST be used as the payload.  Figure 1 shows the
   structure combined with the RTP header.

   +----------+--------------+
   |RTP Header| SILK Payload |
   +----------+--------------+

                Figure 1: Payload Structure with RTP header





Spittka, et al.          Expires January 7, 2010                [Page 8]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


5.  SILK Storage Format

   The SILK storage format allows to store SILK encoded data into e.g. a
   file or an email attachment.  The storage format consists of a header
   and a series of blocks containing encoded speech or audio frames.
   The storage format closely mimics the real-time payload format.

   Figure 2 shows an example of a SILK encoded file.  Note that due to
   the adaptive bit rate and therefore variable frame length of SILK no
   fixed block size can be defined for blocks containing encoded data.

   +------------------+
   | Header           |
   +-----------+------+
   | block 1   |
   +-----------+--+
   | block 2      |
   +--------------+--+
   : ...             :
   +--------------+--+
   | block n         |
   +-----------------+

   Figure 2: Example of SILK file storage format showing different block
                 lengths due to adaptive bit rate of SILK

5.1.  Storage Header Structure

   A SILK storage header contains the following ASCII character string
   as a magic number:

   "#!SILK\n" (hexadecimal: 0x23 0x21 0x53 0x49 0x4C 0x4B 0x0A)

5.2.  Storage Block Structure

   Following the storage header, blocks of encoded data are stored in
   consecutive order in time according to Figure 2.  Each block contains
   a block header followed by a payload according to Figure 3.

   The block header contains information that, for an RTP-based session,
   can be derived from the IP and RTP headers: SILK sample rate, the
   number of octets contained in the subsequent payload and the RTP time
   stamp.

   The sample rate is specified by three bits with the following bit
   convention:





Spittka, et al.          Expires January 7, 2010                [Page 9]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


      000: SILK Narrowband 8000 Hz
      001: SILK Mediumband 12000 Hz
      010: SILK Wideband 16000 Hz
      011: SILK Super Wideband 24000 Hz

   Other values are reserved for future use and blocks where these
   appear MUST be discarded.

   Further, the number of octets in the payload is represented by 13
   bits and the timestamp is specified by 32 bits.  For the first block,
   the timestamp MAY be a random number.  For the following blocks, the
   timestamp MUST be incremented according to the way timestamps are
   incremented when SILK payloads are transmitted over RTP.

   0    3              16                           48
   +----+--------------+----------------------------+-----------------
   |Mode| # of octets  |        Timestamp           |  Payload
   +----+--------------+----------------------------+-----------------

                 Figure 3: Storage block header structure

   The payload of each block in Figure 2 represents one frame of SILK
   encoded data representing 20, 40, 60, 80, or 100 ms speech or audio
   data.

   During the usage of DTX no blocks are stored when the channel is
   inactive.  Timestamps MUST be used to reassemble the decoded signal
   in a time-aligned way.























Spittka, et al.          Expires January 7, 2010               [Page 10]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


6.  Congestion Control

   The adaptive nature of the SILK codec allows for an efficient
   congestion control.

   The average bit rate of SILK is dependent on the input signal and
   will especially decrease during silent periods.  The average bit rate
   can be controlled on a per frame basis and therefore the amount of
   payload data can be controlled.

   Furthermore, 20, 40, 60, 80, or 100 ms of speech or audio data can be
   combined in a single RTP payload, and the transmission rate is
   inversely proportional to these frame sizes.  A lower packet
   transmission rate reduces the amount of header overhead but at the
   same time increases latency and error sensitivity and should be done
   with care.

   It is RECOMMENDED that congestion control is applied during the
   transmission of SILK encoded data.
































Spittka, et al.          Expires January 7, 2010               [Page 11]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


7.  IANA Considerations

   One media subtype (audio/SILK) has been defined and registered as
   described in the following section.

7.1.  SILK Media Type Registration

   Media type registration is done according to [RFC4288] and [RFC4855].


   Type name: audio


   Subtype name: SILK


   Required parameters:

   rate:  RTP timestamp clock rate that is equal to the sampling
      frequency in Hertz (Hz) of the represented media in a packet.
      Possible values are 8000, 12000, 16000, and 24000.

   Optional parameters:

   maxptime:  the decoder's maximum length of time in milliseconds (ms)
      represented by the media in a packet that can be encapsulated in a
      received packet according to Section 6 of [RFC4566].  Possible
      values are 20, 40, 60, 80, and 100 as defined in Section 4 and
      Section 5 of this document.  If no value is specified, 100 is
      assumed as default.

   ptime:  the decoder's recommended length of time in milliseconds (ms)
      represented by the media in a packet according to Section 6 of
      [RFC4566].  Possible values are 20, 40, 60, 80, or 100 as defined
      in Section 4 and Section 5 of this document.  If no value is
      specified, 20 is assumed as default.  If ptime is greater than
      maxptime, ptime MUST be ignored.  This parameter MAY be changed
      during a session.

   minptime:  the decoder's minimum length of time in milliseconds (ms)
      represented by the media in a packet that SHOULD be encapsulated
      in a received packet according to Section 6 of [RFC4566].
      Possible values are 20, 40, 60, 80, and 100 as defined in
      Section 4 and Section 5 of this document.  If no value is
      specified, 20 is assumed as default.






Spittka, et al.          Expires January 7, 2010               [Page 12]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


   maxaveragebitrate:  specifies the maximum average receive bit rate of
      a session in bits per second (bps).  The actual value of the bit
      rate may vary as it is dependent on the characteristics of the
      media in a packet.  Note that the maximum average bit rate MAY be
      modified dynamically during a session.  Any positive integer is
      allowed but values outside the range specified in Table 1 of this
      document will be ignored.  If no value is specified, the maximum
      value specified in Table 1 for the corresponding clock rate will
      be the default.

   usedtx:  specifies if the decoder prefers the use of DTX.  Possible
      values are 1 and 0.  If no value is specified, usedtx is assumed
      to be 0.


   Encoding considerations:


      SILK media type is framed and consists of binary data according to
      Section 4.8 in [RFC4288].

   Security considerations:

      See Section 8 of this document.

   Interoperability considerations: none


   Published specification: none


   Applications that use this media type:

      Any application that requires the transport or storage of speech
      or audio data may use this media type.  Some examples are, but not
      limited to, audio and video conferencing, Voice over IP, voice
      recording, media streaming, voice messaging.

   Additional information:

      For storage transfer methods the following applies:

      Magic number:"#!SILK\n" (hexadecimal: 0x23 0x21 0x53 0x49 0x4C
      0x4B 0x0A)







Spittka, et al.          Expires January 7, 2010               [Page 13]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


      File extension(s): sil, SIL

      Macintosh file type code(s): "silk"

   Person & email address to contact for further information:

      SILK Support silksupport@skype.net

   Intended usage: COMMON


   Restrictions on usage:


      For transfer over RTP, the RTP payload format (Section 4 of this
      document) SHALL be used.  For storage usage, the storage format
      (Section 5 of this document) SHALL be used.

   Author:

      Julian Spittka julian.spittka@skype.net

      Henrik Astrom henrik.astrom@skype.net

      Koen Vos koen.vos@skype.net


   Change controller: Skype

7.2.  Mapping to SDP Parameters

   The information described in the media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [RFC4566], which is commonly used to describe RTP sessions.  When SDP
   is used to specify sessions employing the SILK codec, the mapping is
   as follows:

   o  The media type ("audio") goes in SDP "m=" as the media name.
   o  The media subtype ("SILK") goes in SDP "a=rtpmap" as the encoding
      name.  The RTP clock rate in "a=rtpmap" MUST be mapped to the
      required media type parameter "rate".
   o  The optional media type parameters "ptime" and "maxptime" are
      mapped to "a=ptime" and "a=maxptime" attributes, respectively, in
      the SDP.
   o  All remaining media type parameters are mapped to the "a=fmtp"
      attribute in the SDP by copying them directly from the media type
      parameter string as a semicolon-separated list of parameter=value
      pairs (e.g. maxaveragebitrate=20000).



Spittka, et al.          Expires January 7, 2010               [Page 14]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


   Below are some examples of SDP session descriptions for SILK:

   Example 1: Standard session with 12000 Hz clock rate


       m=audio 54312 RTP/AVP 101
       a=rtpmap:101 SILK/12000


   Example 2: 16000 Hz clock rate, maximum packet size of 40 ms,
   recommended packet size of 40 ms, maximum average bit rate of 20000
   bps, DTX is not allowed


       m=audio 54312 RTP/AVP 101
       a=rtpmap:101 SILK/16000
       a=fmtp:101 maxaveragebitrate=20000; usedtx=0
       a=ptime:40
       a=maxptime:40


7.2.1.  Offer-Answer Model Considerations for SILK

   When using the offer-answer procedure described in [RFC3264] to
   negotiate the use of SILK, the following considerations apply:

   o  SILK supports several clock rates.  Every supported clock rate
      MUST be announced separately in the "m=audi o" line.  It is
      RECOMMENDED to list the highest clock rate with highest priority
      and lower clock rates with lower priority in decreasing order.
      The answer will only keep the payload types that are supported by
      the answerer and the conversation will be performed with the
      payload type of the first, and, thus, highest common clock rate.
      An example is shown below:


           m=audio 54312 RTP/AVP 100 101 102 103
           a=rtpmap:100 SILK/24000
           a=rtpmap:101 SILK/16000
           a=rtpmap:102 SILK/12000
           a=rtpmap:103 SILK/8000


   o  The parameters "ptime" and "maxptime" are unidirectional receive-
      only parameters and typically will not compromise
      interoperability; however, dependent on the set values of the
      parameters the performance of the application may suffer.
      [RFC3264] defines the SDP offer-answer handling of the "ptime"



Spittka, et al.          Expires January 7, 2010               [Page 15]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


      parameter.  The "maxptime" parameter MUST be handled in the same
      way.
   o  The parameter "maxaveragebitrate" is a unidirectional receive-only
      parameter that reflects limitations of the local receiver.  The
      sender of the other side MUST NOT send with an average bit rate
      higher than "maxaveragebitrate" as it might overload the network
      and/or receiver.  The parameter "maxaveragebitrate" typically will
      not compromise interoperability; however, dependent on the set
      value of the parameter the performance of the application may
      suffer and should be set with care.
   o  If the parameter "maxaveragebitrate" is below the range specified
      in Table 1 the session MUST be rejected.
   o  The parameter "usedtx" is a unidirectional receive-only parameter.
   o  Any unknown parameter in an offer MUST be ignored by the receiver
      and MUST be removed from the answer.

7.2.2.  Declarative SDP Considerations for SILK

   For declarative use of SDP such as in Session Announcement Protocol
   (SAP), [RFC2974], and RTSP, [RFC2326], for SILK, the following needs
   to be considered:

   o  The values for "maxptime", "ptime", and "maxaveragebitrate" should
      be selected carefully to ensure that a reasonable performance can
      be achieved for the participants of a session.
   o  All parameters of the payload format configuration are declarative
      and a participant MUST use the configurations that are provided
      for the session.  More than one configuration may be provided if
      necessary by declaring multiple RTP payload types; however, the
      number of types should be kept small.





















Spittka, et al.          Expires January 7, 2010               [Page 16]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


8.  Security Considerations

   All RTP packets using the payload format defined in this
   specification are subject to the general security considerations
   discussed in the RTP specification [RFC3550] and any profile from
   e.g.  [RFC3711] or [RFC3551].

   This payload format transports SILK encoded speech or audio data,
   hence, security issues include confidentiality, integrity protection,
   and authentication of the speech or audio itself.  The SILK payload
   format does not have any built-in security mechanisms.  Any suitable
   external mechanisms, such as SRTP [RFC3711], MAY be used.

   This payload format and the SILK encoding do not exhibit any
   significant non-uniformity in the receiver-end computational load and
   thus are unlikely to pose a denial-of-service threat due to the
   receipt of pathological datagrams.


































Spittka, et al.          Expires January 7, 2010               [Page 17]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


9.  Acknowledgements

   The authors like to thank Soren Skak Jensen and Jason Fischl for
   their invaluable input.















































Spittka, et al.          Expires January 7, 2010               [Page 18]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 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.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

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

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.
















Spittka, et al.          Expires January 7, 2010               [Page 19]

Internet-Draft      RTP Payload Format for SILK Codec          July 2009


Authors' Addresses

   Julian Spittka
   Skype Technologies S.A.
   2145 Hamilton Ave.
   San Jose, CA  95125
   US

   Email: julian.spittka@skype.net


   Henrik Astrom
   Skype Technologies S.A.
   2145 Hamilton Ave.
   San Jose, CA  95125
   US

   Email: henrik.astrom@skype.net


   Koen Vos
   Skype Technologies S.A.
   2145 Hamilton Ave.
   San Jose, CA  95125
   US

   Email: koen.vos@skype.net
























Spittka, et al.          Expires January 7, 2010               [Page 20]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/