5.4 MPV   MPV designates the use MPEG-I and MPEG-II video encoding elementary   streams as specified in ISO Standards ISO/IEC 11172 and 13818-2,   respectively. The RTP payload format is as specified in work in   progress [10], Section 3. See the description of the MPA audio   encoding for contact information.5.5 MP2T   MP2T designates the use of MPEG-II transport streams, for either   audio or video. The encapsulation is described in work in progress,   [10], Section 2. See the description of the MPA audio encoding for   contact information.5.6 nv   The encoding is implemented in the program 'nv', version 4, developed   at Xerox PARC by Ron Frederick. Further information is available from   the author:   Ron Frederick   Xerox Palo Alto Research Center   3333 Coyote Hill Road   Palo Alto, CA 94304   United States   electronic mail: frederic@parc.xerox.com6.  Payload Type Definitions   Table 2 defines this profile's static payload type values for the PT   field of the RTP data header. A new RTP payload format specification   may be registered with the IANA by name, and may also be assigned a   static payload type value from the range marked in Section 3.   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. For example, a session directory could   specify that for a given session, payload type 96 indicates PCMU   encoding, 8,000 Hz sampling rate, 2 channels. The payload type range   marked 'reserved' has been set aside so that RTCP and RTP packets can   be reliably distinguished (see Section "Summary of Protocol   Constants" of the RTP protocol specification).   An RTP source emits a single RTP payload type at any given time; the   interleaving of several RTP payload types in a single RTP session is   not allowed, but multiple RTP sessions may be used in parallel to   send multiple media. The payload types currently defined in thisSchulzrinne                 Standards Track                    [Page 13]RFC 1890                       AV Profile                   January 1996   profile carry either audio or video, but not both. However, it is   allowed to define payload types that combine several media, e.g.,   audio and video, with appropriate separation in the payload format.   Session participants agree through mechanisms beyond the scope of   this specification on the set of payload types allowed in a given   session.  This set may, for example, be defined by the capabilities   of the applications used, negotiated by a conference control protocol   or established by agreement between the human participants.   Audio applications operating under this profile should, at minimum,   be able to send and receive payload types 0  (PCMU)  and 5 (DVI4).   This allows interoperability without format negotiation and   successful negotation with a conference control protocol.   All current video encodings use a timestamp frequency of 90,000 Hz,   the same as the MPEG presentation time stamp frequency. This   frequency yields exact integer timestamp increments for the typical   24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates   and 50, 59.94 and 60 Hz field rates. While 90 kHz is the recommended   rate for future video encodings used within this profile, other rates   are possible. However, it is not sufficient to use the video frame   rate (typically between 15 and 30 Hz) because that does not provide   adequate resolution for typical synchronization requirements when   calculating the RTP timestamp corresponding to the NTP timestamp in   an RTCP SR packet [15]. The timestamp resolution must also be   sufficient for the jitter estimate contained in the receiver reports.   The standard video encodings and their payload types are listed in   Table 2.7.  Port Assignment   As specified in the RTP protocol definition, RTP data is to be   carried on an even UDP port number and the corresponding RTCP packets   are to be carried on the next higher (odd) port number.   Applications 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 systems that do   not allow multiple processes to use the same UDP port with different   multicast addresses.Schulzrinne                 Standards Track                    [Page 14]RFC 1890                       AV Profile                   January 1996      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          unassigned    A              8000          1      5          DVI4          A              8000          1      6          DVI4          A              16000         1      7          LPC           A              8000          1      8          PCMA          A              8000          1      9          G722          A              8000          1      10         L16           A              44100         2      11         L16           A              44100         1      12         unassigned    A      13         unassigned    A      14         MPA           A              90000        (see text)      15         G728          A              8000          1      16--23     unassigned    A      24         unassigned    V      25         CelB          V              90000      26         JPEG          V              90000      27         unassigned    V      28         nv            V              90000      29         unassigned    V      30         unassigned    V      31         H261          V              90000      32         MPV           V              90000      33         MP2T          AV             90000      34--71     unassigned    ?      72--76     reserved      N/A            N/A           N/A      77--95     unassigned    ?      96--127    dynamic       ?   Table 2: Payload types (PT) for standard audio and video encodings   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. Applications 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 operatingSchulzrinne                 Standards Track                    [Page 15]RFC 1890                       AV Profile                   January 1996   system.8. Bibliography   [1] Apple Computer, "Audio interchange file format AIFF-C," Aug.       1991.  (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).   [2] Office of Technology and Standards, "Telecommunications: Analog       to digital conversion of radio voice by 4,800 bit/second code       excited linear prediction (celp)," Federal Standard FS-1016, GSA,       Room 6654; 7th & D Street SW; Washington, DC 20407 (+1-202-708-       9205), 1990.   [3] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The       proposed Federal Standard 1016 4800 bps voice coder: CELP,"       Speech Technology , vol. 5, pp. 58--64, April/May 1990.   [4] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The federal       standard 1016 4800 bps CELP voice coder," Digital Signal       Processing, vol. 1, no. 3, pp. 145--155, 1991.   [5] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The dod 4.8       kbps standard (proposed federal standard 1016)," in Advances in       Speech Coding (B. Atal, V. Cuperman, and A. Gersho, eds.), ch.       12, pp. 121--133, Kluwer Academic Publishers, 1991.   [6] IMA Digital Audio Focus and Technical Working Groups,       "Recommended practices for enhancing digital audio compatibility       in multimedia systems (version 3.00)," tech. rep., Interactive       Multimedia Association, Annapolis, Maryland, Oct. 1992.   [7] M. Mouly and M.-B. Pautet, The GSM system for mobile       communications Lassay-les-Chateaux, France: Europe Media       Duplication, 1993.   [8] J. Degener, "Digital speech compression," Dr. Dobb's Journal,       Dec.  1994.   [9] S. M. Redl, M. K. Weber, and M. W. Oliphant, An Introduction to       GSM Boston: Artech House, 1995.  [10] D. Hoffman and V. Goyal, "RTP payload format for MPEG1/MPEG2       video," Work in Progress, Internet Engineering Task Force, June       1995.  [11] N. S. Jayant and P. Noll, Digital Coding of Waveforms--       Principles and Applications to Speech and Video Englewood Cliffs,       New Jersey: Prentice-Hall, 1984.Schulzrinne                 Standards Track                    [Page 16]RFC 1890                       AV Profile                   January 1996  [12] M. F. Speer and D. Hoffman, "RTP payload format of CellB video       encoding," Work in Progress, Internet Engineering Task Force,       Aug.  1995.  [13] W. Fenner, L. Berc, R. Frederick, and S. McCanne, "RTP       encapsulation of JPEG-compressed video," Work in Progress,       Internet Engineering Task Force, Mar. 1995.  [14] T. Turletti and C. Huitema, "RTP payload format for H.261 video       streams," Work in Progress, Internet Engineering Task Force, July       1995.  [15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A       transport protocol for real-time applications." Work in Progress,       Mar. 1995.9.  Security Considerations   Security issues are discussed in section 2.10.  Acknowledgements   The comments and careful review of Steve Casner are gratefully   acknowledged.11.  Author's Address   Henning Schulzrinne   GMD Fokus   Hardenbergplatz 2   D-10623 Berlin   Germany   EMail: schulzrinne@fokus.gmd.deSchulzrinne                 Standards Track                    [Page 17]RFC 1890                       AV Profile                   January 1996   Current Locations of Related Resources   UTF-8   Information on the UCS Transformation Format 8 (UTF-8) is available   at            http://www.stonehand.com/unicode/standard/utf8.html   1016   An implementation is available at              ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z   DVI4   An implementation is available from Jack Jansen at                ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar   G721   An implementation is available at       ftp://gaia.cs.umass.edu/pub/hgschulz/ccitt/ccitt_tools.tar.Z   GSM   A reference implementation was written by Carsten Borman and Jutta   Degener (TU Berlin, Germany). It is available at            ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/   LPC   An implementation is available at            ftp://parcftp.xerox.com/pub/net-research/lpc.tar.ZSchulzrinne                 Standards Track                    [Page 18]