[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-gentric-avt-profile) 00 01 02 03 04 05 06 RFC 1890

Internet Engineering Task Force      Audio-Video Transport Working Group
Internet Draft                                            H. Schulzrinne
ietf-avt-profile-04.txt                                        GMD Fokus
                                                          March 24, 1995
                                                         Expires: 9/1/95


    RTP Profile for Audio and Video Conferences with Minimal Control

STATUS OF THIS MEMO

     This document is an  Internet-Draft.  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''.

     To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt''  listing  contained  in the Internet-Drafts Shadow
Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
ftp.isi.edu (US West Coast).

     Distribution of this document is unlimited.

                                ABSTRACT


      This note describes a profile for the use of  the  real-time
      transport  protocol  (RTP) and the associated control proto-
      col, RTCP, within audio and video  multiparticipant  confer-
      ences  with  minimal control. It provides interpretations of
      generic fields within the  RTP  specification  suitable  for
      audio  and  video  conferences. In particular, this document
      defines a set of default mappings from payload type  numbers
      to  encodings.   The  document  also describes how audio and
      video data may be carried within RTP. It defines  a  set  of
      standard  encodings  and  their  names when used within RTP.
      However, the definitions are independent of  the  particular
      transport  mechanism used. The descriptions provide pointers
      to reference implementations  and  the  detailed  standards.
      This  document is meant as an aid for implementors of audio,
      video and other real-time multimedia applications.




H. Schulzrinne                                          [Page 1]


Internet Draft                 AV Profile                 March 24, 1995


1.  Introduction

     This profile defines aspects of RTP left  unspecified  in  the  RTP
     protocol definition (RFC TBD). This profile is intended for the use
     within audio and video conferences with minimal session control. In
     particular, no support for the negotiation of parameters or member-
     ship control is provided. Other profiles may make different choices
     for  the items specified here. The profile specifies the use of RTP
     over unicast and multicast UDP. (This does not preclude the use  of
     these  definitions  when RTP is carried by other lower-layer proto-
     cols.)  (Ed.: How to indicate usage of the  profile?  Port  numbers
     are not likely to be well-defined.)

2.  RTP and RTCP Packet Forms and Protocol Behavior

     This profile follows the default and/or recommended aspects of  the
     RTP specification for these items: (Ed.: Maybe the main spec should
     number these items, so that they can be easily aligned between spec
     and profile?)

     o  The standard format of the fixed RTP data header  is  used  (one
       marker bit).

     o  No additional fixed fields are appended to the RTP data header.

     o  The suggested constants are to  be  used  for  the  RTCP  report
       interval calculation.

     o  No extension section is defined for the RTCP SR or RR packet.

     o  No additional RTCP packet types  are  defined  by  this  profile
       specification.

     o  The RTP default security services are  also  the  default  under
       this profile.

      o  The  standard  mapping  of  RTP  and  RTCP  to  transport-level
       addresses is used.

     o  No encapsulation of RTP packets is specified.

     o  No RTP header extensions are defined, but applications operating
       under  this  profile  may use such extensions. Thus, applications
       should not assume that the RTP header X bit is  always  zero  and
       should  be  prepared  to  ignore the header extension. Extensions
       should register the content of  the  first  16  bits  with  IANA.
       (Ed.: Yet another IANA space? Other ideas?)




H. Schulzrinne                                          [Page 2]


Internet Draft                 AV Profile                 March 24, 1995


     o  Applications may use any of the SDES items described.
     New encodings are to  be  registered  with  the  Internet  Assigned
     Numbers  Authority.  When registering a new encoding, the following
     information should be provided:

     o  name and description of encoding, in particular the  RTP  times-
       tamp clock rate;

     o  indication of who has change  control  over  the  encoding  (for
       example, CCITT/ITU, other international standardization bodies, a
       consortium or a particular company or group of companies);

     o  any operating parameters;

     o  a reference to a further description, if available, for  example
       (in order of preference) an RFC, a published paper, a patent fil-
       ing, a technical report or a computer manual;

     o  for proprietary encodings, contact information (postal and email
       address).

     o  the payload type value for this profile.

3.  Audio



3.1.  Encoding-independent recommendations

     The following recommendations  are  default  operating  parameters.
Applications should be prepared to handle other values. The ranges given
are meant to give guidance to application writers,  allowing  a  set  of
applications  conforming  to  these  guidelines  to interoperate without
additional negotiation. These guidelines are not  intended  to  restrict
operating  parameters  for  applications  that  can  negotiate  a set of
interoperable parameters, e.g., through a conference  control  protocol.
For  packetized  audio, the default packetization interval should have a
duration of 20 ms, unless otherwise noted when describing the  encoding.
The  packetization  interval  determines  the  minimum end-to-end delay;
longer packets introduce less header overhead but higher delay and  make
packet  loss  more  noticeable. For non-interactive applications such as
lectures or links with severe bandwidth constraints, a higher packetiza-
tion  delay  may  be appropriate. For N-channel encodings, each sampling
period (say, 1/8000 of a second) generates N samples. (This  terminology
is standard, but somewhat confusing, as the total number of samples gen-
erated per second is then the sampling rate times  the  channel  count.)
If  multiple  audio  channels  are  used, channels are numbered left-to-
right, starting at one. In RTP audio packets,  information  from  lower-



H. Schulzrinne                                          [Page 3]


Internet Draft                 AV Profile                 March 24, 1995


numbered  channels precedes that from higher-numbered channels. For more
than two channels, the convention followed by the  AIFF-C  audio  inter-
change  format  should  be  followed  [1].  For  two-channel stereo, the
numbering sequence is left, right;  for  three  channels,  left,  right,
center;  for  quadrophonic  systems, front left, front right, rear left,
rear right; for four-channel systems, left, center, right, and  surround
sound;  for  six-channel systems left, left center, center, right, right
center and surround sound. All channels belonging to a  single  sampling
instance  must be within the same packet.  The sampling frequency should
be drawn from the set: 8000, 11025, 16000, 22050, 44100  and  48000  Hz.
(The  Apple Macintosh computers have native sample rates of 22254.54 and
11127.27, which can be converted to  22050  and  11025  with  acceptable
quality by dropping 4 or 2 samples in a 20 ms frame.)  A receiver should
accept packets representing between 0  and  200  ms  of  audio  data.[1]
Receivers  should  be  prepared  to  accept multi-channel audio, but may
choose to only play a single channel.

3.2.  Guidelines for Sample-Based Audio Encodings

     In sample-based encodings, each audio sample is  represented  by  a
fixed  number of bits. Within the compressed audio data, codes for indi-
vidual samples may span octet boundaries. An RTP audio packet  may  con-
tain  any  number  of  audio samples, subject to the constraint that the
number of bits per sample times the number of samples per packet  yields
an  integral  octet  count.  Fractional  encodings produce less than one
octet per sample.  For sample-based  encodings  producing  one  or  more
octets  per  sample,  samples from different channels, but the same sam-
pling instant are consecutive. For example, for a two-channel  encoding,
the  octet  sequence  is  (left  channel, first sample), (right channel,
first sample), (left channel, second  sample),  (right  channel,  second
sample),  .... For multi-octet encodings, octets are transmitted in net-
work byte order (i.e., most significant octet first).  The packing order
for  fractional  encodings is that described for the IMA Wave types [2].
For audio encodings yielding four bits per sample, eight such compressed
samples  from  channel  1  are  packet into one 32-bit word, followed by
eight compressed samples from channel 2, until all  channels  have  been
accomodated  and  the  packing resumes at channel 1. For audio encodings
yielding three bits per sample, 32 such compressed samples at three bits
each  from  channel  1 are packed into 12 octets, followed by 32 samples
from channel 2, etc.



_________________________

  [1] This restriction allows reasonable buffer  sizing
for the receiver.




H. Schulzrinne                                          [Page 4]


Internet Draft                 AV Profile                 March 24, 1995


3.3.  Guidelines for Frame-Based Audio Encodings


     Frame-based encodings encode a fixed-length  block  of  audio  into
another  block  of  compressed data, typically also of fixed length. For
frame-based encodings, the sender may choose  to  combine  several  such
frames into a single message. The receiver can tell the number of frames
contained in a message since the frame duration is defined  as  part  of
the  encoding.  For frame-based codecs, the channel order is defined for
the whole block. That is, for two-channel audio, right and left  samples
are  coded  independently,  with  the encoded frame for the left channel
preceding that for the right channel.  All frame-oriented  audio  codecs
should  be able to encode and decode several consecutive frames within a
single packet. Since the frame size for  the  frame-oriented  codecs  is
given,  there  is  no  need  to  use a separate designation for the same
encoding, but with different number of frames per packet.

3.4.  Audio Encodings



         encoding     sample/frame     bits/sample     ms/frame
         ______________________________________________________
         1016         frame            N/A             30
         G721         sample           4
         G723         sample           3
         GSM          frame            N/A             20
         IDVI         sample           4
         LPC          frame            N/A             20
         L8           sample           8
         L16          sample           16
         MPA          frame            N/A
         PCMU         sample           8
         PCMA         sample           8



Table 1: Properties of Audio Encodings

     1016: Encoding 1016 is a frame based  encoding  using  code-excited
          linear  prediction (CELP) and is specified in Federal Standard
          FED-STD 1016 [3,4,5,6].  The U. S. DoD's Federal-Standard-1016
          based 4800 bps code excited linear prediction voice coder ver-
          sion 3.2 (CELP 3.2) Fortran and C simulation source codes  are
          available  for  worldwide  distribution  at  no charge (on DOS
          diskettes, but configured to compile on  Sun  SPARC  stations)
          from:  Bob  Fenichel, National Communications System, Washing-
          ton, D.C. 20305, phone +1-703-692-2124,  fax  +1-703-746-4960.
          and


H. Schulzrinne                                          [Page 5]


Internet Draft                 AV Profile                 March 24, 1995


                  ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z

     G721: G721 is specified  in  ITU  recommendation  G.721.  Reference
          implementations  for  G.721 and G.723 are available as part of
          the CCITT/ITU-T Software Tool Library (STL) from the ITU  Gen-
          eral  Secretariat,  Sales  Service,  Place du Nations, CH-1211
          Geneve 20, Switzerland. The library is covered  by  a  license
          and is available at

           ftp://gaia.cs.umass.edu/pub/hgschulz/ccitt/ccitt_tools.tar.Z

     G723: G721 is specified in ITU recommendation G.723. See  G721  for
          information about a reference implementation.

     GSM: GSM (group speciale mobile) denotes  the  European  GSM  06.10
          provisional standard for full-rate speech transcoding, prI-ETS
          300  036,  which  is  based   on   RPE/LTP   (residual   pulse
          excitation/long  term prediction) coding at a rate of 13 kb/s.
          A reference implementation was written by Carsten  Borman  and
          Jutta Degener (TU Berlin, Germany) and is available at

               ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/

     IDVI: IDVI is specified, with reference implemention, in [2].  Each
          packet  contains  a  single  DVI block.  The "header" word for
          each channel has the following structure:


                    int16  valpred;  /* previous predicted value, network byte order */
                    u_int8 index;    /* index into stepsize table */



          Header words for all channels  precede  the  compressed  data.
          Note  that the first 16 bits differ in definition from the IMA
          and Microsoft DVI ADPCM Wave type [7].  There,  the  first  16
          bits  contain  the  first  (uncompressed)  sample.  (Ed.: This
          discrepancy is unfortunate, creating  all  kinds  of  problems
          with hardware-based codecs common with PCs.)

     L8:  L8 denotes linear audio data, using 8-bits of  precision  with
          an offset of 128, that is, the most negative signal is encoded
          as 0.

     L16: L16 denotes  uncompressed  audio  data,  using  16-bit  signed
          representation   with  65535  equally  divided  steps  between
          minimum and maximum  signal  level,  ranging  from  -32768  to
          32767.  The  value is represented in two's complement notation



H. Schulzrinne                                          [Page 6]


Internet Draft                 AV Profile                 March 24, 1995


          and network byte order.

     MPA: MPA denotes MPEG-I or MPEG-II audio encapsulated as elementary
          streams.  The  encoding  is  defined  in ISO standards ISO/IEC
          11172-3 and 13818-3. The encapsulation  is  specified  in  RFC
          TBD,  Section 4. Sampling rate and channel count are contained
          in the payload.

     PCMU: PCMU is specified in CCITT/ITU-T recommendation G.711.  Audio
          data  is  encoded  as eight bits per sample, after companding.
          Code to convert between linear and mu-law  companded  data  is
          available in [2].

     PCMA: PCMA is specified in CCITT/ITU-T recommendation G.711.  Audio
          data  is  encoded  as eight bits per sample, after companding.
          Code to convert between linear and  A-law  companded  data  is
          available in [2].

     LPC: LPC designates  an  experimental  linear  predictive  encoding
          written by Ron Frederick, Xerox PARC, available from

                ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z

     VDVI: VDVI is a variable-rate version of IDVI, yielding speech  bit
          rates  of  between 10 and 25 kbps. It is specified for single-
          channel operation only. It uses the following encoding:


                        IDVI codeword     VDVI bit pattern
                                    0     00
                                    1     010
                                    2     1100
                                    3     11100
                                    4     111100
                                    5     1111100
                                    6     11111100
                                    7     11111110
                                    8     10
                                    9     011
                                   10     1101
                                   11     11101
                                   12     111101
                                   13     1111101
                                   14     11111101
                                   15     11111111






H. Schulzrinne                                          [Page 7]


Internet Draft                 AV Profile                 March 24, 1995


     TSP0: TSP0 designates the  proprietary  variable-rate,  frame-based
          encoding  called  True  Speech.  The encoding is defined for a
          sampling rate of 7200 Hz and has an average data rate of  7200
          bits  per second. Further information is available by contact-
          ing VocalTec (see VSC encoding) or the  address:   DSP  Group,
          Inc.
          email: tsplayer@dsgp.com

     VSC: VSC designates the proprietary variable-rate  encoding  called
          Vocaltec  Software  Compression. The encoding is defined for a
          sampling rate of 5500 Hz and has an average data rate  of  963
          bytes per second. Further information is available by contact-
          ing Alon Cohen
          VocalTec Ltd.
          Maskit 1, Herzliya
          Israel
          phone: +972-9-5612121
          email: alon@vocaltec.com
     The standard audio encodings and their payload types are listed  in
     Table 5.

4.  Video

     The following video encodings are  currently  defined,  with  their
     abbreviated names used for identification:

     CelB: The CELL-B encoding is a proprietary encoding proposed by Sun
          Microsystems. The byte stream format is described in RFC TBD.

     CPV: This proprietary encoding, "Compressed Packet Video is  imple-
          mented by Concept, Bolter, and ViewPoint Systems video codecs.
          For further information, contact:  Glenn Norem, President
          ViewPoint Systems, Inc.
          2247 Wisconsin Street, Suite 110
          Dallas, TX 75229-2037
          United States
          Phone: +1-214-243-0634

     JPEG: The encoding  is  specified  in  ISO  Standards  10918-1  and
          10918-2. The RTP payload format is as specified in RFC TBD.

     H261: The encoding is specified in CCITT/ITU-T standard H.261.  The
          packetization and RTP-specific properties are described in RFC
          TBD.

     HDCC: The HDCC encoding is a proprietary encoding used  by  Silicon
          Graphics. [TBD: Need contact information.]




H. Schulzrinne                                          [Page 8]


Internet Draft                 AV Profile                 March 24, 1995


     MPV: MPV designates the use MPEG-I and MPEG-II video encoding  ele-
          mentary  streams  as  specified in ISO Standards ISO/IEC 11172
          and 13818-2, respectively. The RTP payload format is as speci-
          fied in RFC TBD, Section 4.

     MP2T: MP2T designates the use of  MPEG-II  transport  streams,  for
          either  audio  or video. The encapsulation is described in RFC
          TBD, Section 3.

     nv:  The encoding is implemented in the program 'nv'  developed  at
          Xerox PARC by Ron Frederick.

     CUSM: The encoding is implemented in the program CU-SeeMe developed
          at  Cornell  University by Dick Cogger, Scott Brim, Tim Dorcey
          and John Lynn.

     PicW: The encoding is  implemented  in  the  program  PictureWindow
          developed at Bolt, Beranek and Newman (BBN).

     RGB8: 8-bit encoding of RGB values, sequenced TBD.  Each pixel  can
          assume  values  from  0  to  255.  Each frame is prefixed by a
          header containing TBD.

5.  Payload Type Definitions

     Table 5 defines the static payload type values to be carried in the
     PT  field of the RTP data header when this profile is in use. Addi-
     tional static payload type values marked 'unassigned' in the  table
     may  be defined by RTP Payload Format specifications and registered
     with IANA. In addition, payload type values in  the  range  96--127
     may  be  defined  dynamically through a conference control protocol
     which is beyond the scope of this document.  Note that  the  single
     name  space  does  not  imply in any sense that changes between all
     such encodings are useful. In particular, a single RTP  session  is
     likely to carry either video or audio, but not both. It is not per-
     missible to use distinct payload types to multiplex  several  media
     concurrently  onto a single RTP session (e.g., to concurrently send
     PCMU audio and CelB video over the same RTP session). Some  payload
     types  may  designate  a  combination of both audio and video, both
     within the same packet or differentiated by information within  the
     payload.  Currently,  the  MPEG Transport encapsulation is the only
     such payload type. The payload type  range  marked  'reserved'  has
     been  set  aside  so that RTCP and RTP packets can be reliably dis-
     tinguished (see Section XXX of  the  RTP  protocol  specification).
     Audio  applications  operating under this profile should at minimum
     be able to send and receive payload types  0  and  5.  This  allows
     interoperability  without format negotiation and successful negota-
     tion with a conference control protocol.  (Ed.: Is this helpful? It



H. Schulzrinne                                          [Page 9]


Internet Draft                 AV Profile                 March 24, 1995


     does  give  guidance  to  application  writers and reflects current
     practice of widest-use encodings.  Should  the  same  be  done  for
     video? It would be nice if saying that application FOO is compliant
     with RTP and profile RFC TBD, they could interoperate.  This  seems
     similar to requiring certain minimum IPv6 security mechanisms.)  If
     there is no strong technical reason to the contrary,  video  encod-
     ings  typically use a timestamp frequency of 65536 Hz. The standard
     video encodings and their payload types are listed in Table 5.


     PT         encoding       audio/video     clock rate     channels
                name           (A/V)           (Hz)           (audio)
     ___________________________________________________________________
     0          PCMU           A               8000           1
     1          1016           A               8000           1
     2          G721           A               8000           1
     3          GSM            A               8000           1
     4          G723           A               8000           1
     5          IDVI           A               8000           1
     6          IDVI           A               16000          1
     7          LPC            A               8000           1
     8          unassigned     A
     9          unassigned     A
     10         L16            A               44100          2
     11         L16            A               44100          1
     12         TSP0           A               7200           1
     13         VSC            A               5500           1
     14         MPA            A               90000          (see text)
     15--22     unassigned     A
     23         RGB8           V               65536          N/A
     24         HDCC           V               65536          N/A
     25         CelB           V               65536          N/A
     26         JPEG           V               65536          N/A
     27         CUSM           V               65536          N/A
     28         nv             V               65536          N/A
     29         PicW           V               65536          N/A
     30         CPV            V               65536          N/A
     31         H261           V               65536          N/A
     32         MPV            V               90000          N/A
     33         MP2T           A/V             90000          N/A
     33--71     unassigned     V               65536          N/A
     72--76     reserved       N/A             N/A            N/A
     77--95     unassigned     ?
     96--127    dynamic        ?                              N/A



Table 2: Payload types (PT) for standard audio and video encodings



H. Schulzrinne                                         [Page 10]


Internet Draft                 AV Profile                 March 24, 1995


6.  Port Assignment

     As specified in the RTP protocol definition, RTP data is to be car-
     ried  on an even UDP port number and the corresponding RTCP packets
     are to be carried on the next higher (odd) port  number.   Applica-
     tions  operating under this profile may use any such UDP port pair.
     For example, the port pair may be allocated randomly by  a  session
     management  program.  A  single  fixed  port  number pair cannot be
     required because  multiple  applications  using  this  profile  are
     likely  to  run on the same host, and there are some operating sys-
     tems that do not allow multiple processes to use the same UDP  port
     with different multicast addresses.  However, port numbers 5004 and
     5005 have been registered for  use  with  this  profile  for  those
     applications  that choose to use them as the default pair. Applica-
     tions that operate under multiple profiles may use this  port  pair
     as  an indication to select this profile if they are not subject to
     the constraint of the previous  paragraph.  Applications  need  not
     have  a  default  and  may require that the port pair be explicitly
     specified. The particular port numbers were chosen to  lie  in  the
     range  above  5000  to  accomodate  port number allocation practice
     within the Unix operating system, where port numbers below 1024 can
     only  be used by privileged processes and port numbers between 1024
     and 5000 are automatically assigned by the operating system.

7.  Address of Author

     Henning Schulzrinne
     GMD Fokus
     Hardenbergplatz 2
     D-10623 Berlin
     Germany


     electronic mail:
     hgs@fokus.gmd.de
















H. Schulzrinne                                         [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/