idnits 2.17.1 draft-ietf-avt-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 115 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 61 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...working docum...' == Line 15 has weird spacing: '...t other group...' == Line 20 has weird spacing: '...e. It is no...' == Line 21 has weird spacing: '...rial or to ci...' == Line 24 has weird spacing: '...e check the I...' == (41 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 15, 1992) is 11454 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'TBD' on line 182 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio-Video Transport Working Group 3 INTERNET-DRAFT H. Schulzrinne 4 AT&T Bell Laboratories 5 December 15, 1992 6 Expires: 5/1/93 8 Sample Profile for the Use of RTP for Audio and Video Conferences with 9 Minimal Control 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working documents 14 of the Internet Engineering Task Force (IETF), its Areas, and its Working 15 Groups. Note that other groups may also distribute working documents as 16 Internet Drafts). 18 Internet Drafts are draft documents valid for a maximum of six months. 19 Internet Drafts may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as reference 21 material or to cite them other than as a "working draft" or "work in 22 progress." 24 Please check the I-D abstract listing contained in each Internet Draft 25 directory to learn the current status of this or any other Internet Draft. 27 Distribution of this document is unlimited. 29 Abstract 31 This note describes a profile for the use of the real-time 32 transport protocol (RTP) within audio and video multiparticipant 33 conferences with minimal control. It provides interpretations of 34 generic fields within the RTP specification suitable for audio and 35 video conferences. In particular, this document defines a set of 36 default mappings from content index to encodings. 38 1 Introduction 40 This profile defines aspects of RTP left unspecified in the RTP protocol 41 definition. This profile is intended for the use within audio and video 42 conferences with minimal session control. In particular, no support for 43 the negotiation of parameters or admission control is provided. Other 44 profiles may make different choices for the items specified here. The 45 profile specifies the use of RTP over unicast and multicast UDP as well as 46 ST-II. For unicast UDP and ST-II, references to multicast addresses are to 47 be ignored. The use of this profile is indicated by the use of a well-known 48 port number. 50 2 Multiplexing and Demultiplexing 52 Packets sharing the same multicast group address, the same destination port 53 number and the same flow value belong to the same conference. Within a 54 conference, a packet is mapped to a site (state) through its synchronization 55 address and network source port. 57 3 CDESC 59 The content field within the CDESC option describes the media encoding 60 used. The four octets contain one of the encodings defined by the Internet 61 Assigned Numbers Authority (IANA) or an encoding agreed upon by mutual 62 consent of all conference participants. The names are defined in Figures 1 63 and 2 and encoded in US-ASCII. Case is significant. If the name is shorter 64 than four characters, it is padded with one or more space characters (ASCII 65 32 decimal). 67 The encodings are identified as follows: 69 Bolt: refers to the proprietary Bolter video coding algorithm. 71 dvc: the BBN video coding algorithm. 73 DVI: refers to the Intel DVI/ADPCM audio encoding, specified in the 74 `Recommended Practices for Enhancing Digital Audio Compatibility 75 in Multimedia Systems'', published by the Interactive Multimedia 76 Association (IMA), Annapolis, MD. 78 1016: refers to the Federal Standard 1016, which uses code-excited linear 79 prediction. 81 G721: refers to the ADPCM encoding defined by CCITT Recommendation G.721 at 82 a rate of 32 kb/s. 84 G723: refers to the ADPCM encoding defined by CCITT Recommendation G.723 at 85 a rate of 24 kb/s. 87 G722: is defined in CCITT Recommendation G.722 and denotes a subband coded 88 ADPCM algorithm with an audio bandwidth of 7 kHz. 90 GSM: denotes the European GSM 06.10 provisional standard for full-rate 91 speech transcoding, prI-ETS 300 036, based on residual pulse excitation 92 with long term prediction (RPE/LTP). 94 H261: refers to CCITT Recommendation H.261 and defines a video codec based 95 on discrete-cosine transforms. 97 nv: Xerox Parc video coding algorithm. 99 PCMU: is a subset of CCITT Recommendation G.711, referring to a mu-law 100 companded PCM encoding. 102 PCMA: is a subset of CCITT Recommendation G.711, referring to an A-law 103 companded PCM encoding. 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |F| CFDESC | length |0|0| content | MBZ | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | return port number | clock quality | MBZ | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | name of encoding | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | channels | sampling rate (Hz) | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 ... encoding specific parameters ... 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Figure 1: CDESC for Audio 121 For audio encodings, the index into the table of encodings is followed by 122 a field containing a channel count and a sample rate field, measured in 123 samples per second.(1) A channel count of zero is considered invalid. 125 For video encodings, a one-octet numeric version identifier further 126 describes the encoding. 127 ------------------------------ 128 1. Fractional samples per second was considered excessive as the typical 129 crystal accuraccy of 100 ppm translates into about one Hz or more of 130 sampling rate inaccuracy. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |F| CFDESC | length |0 0 content | MBZ | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | return port number | clock quality | MBZ | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | name of encoding | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | version | encoding-specific parameters | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 ... encoding-specific parameters ... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 2: CDESC for Video 148 4 Standard Encodings 150 Unless specified with the CDESC option, the mapping between the content 151 field in an RTP packet and encodings, sampling rates and channel counts is 152 specified by Tables 1 and 2. Values of 31 and below cannot be redefined by 153 CDESC options. In other words, only values of 32 and above are valid in the 154 content field within an CDESC option. The receiver is expected to discard 155 RTP packets containing media data with unknown content field values. Sites 156 are expected to keep the mapping between content and encoding constant, so 157 that lost packets containing CDESC options do not lead the receiver to 158 misinterpret media data. 160 index encoding sampling rate channels 161 ________name______(kHz)___________________ 162 0 PCMU 8 1 163 1 1016 8 1 164 2 G721 8 1 165 3 GSM 8 1 166 4 G723 8 1 167 5 DVI 8 1 168 6 L16 16 1 169 _____7__L16_______44.1_________________2__ 171 Table 1: Default Audio Encodings 172 _number__name_ 173 31 H261 174 30 Bolt 175 29 dvc 176 28 nv 178 Table 2: Default Video Encodings 180 5 Port Assignments and Miscellaneous 182 UDP port [TBD] is to be used as the destination for multicast real-time data 183 carried by RTP. Unicast connections may use the this or a set of mutually 184 agreed-upon port numbers. ST-II connections use port 3456. 186 The framing field is to be used only when RTP protocol data units are 187 carried over a network or transport protocol that does not provide framing 188 (e.g., TCP). 190 6 Address of Author 192 Henning Schulzrinne 193 AT&T Bell Laboratories 194 MH 2A244 195 600 Mountain Avenue 196 Murray Hill, NJ 07974 197 telephone: 908 582-2262 198 electronic mail: hgs@research.att.com