idnits 2.17.1 draft-ietf-avt-interleaving-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 5) being 71 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 February 1999) is 9196 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) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '2') (Obsoleted by RFC 3551) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 20 February 1999 4 Colin Perkins 5 University College London 7 RTP Payload Format for Interleaved Media 9 draft-ietf-avt-interleaving-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months and 21 may be updated, replaced, or obsoleted by other documents at any time. It 22 is inappropriate to use Internet-Drafts as reference material or to cite 23 them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Comments are solicited and should be addressed to the author and/or 32 the audio/video transport working group's mailing list rem-conf@es.net. 34 Abstract 36 This memo defines an interleaving scheme for RTP streams. 37 This scheme is derived from the RTP payload format for redundant 38 audio data [4] and hence is targetted primarily at streamed 39 audio, although it may be of use in other scenarios. 41 1 Introduction 43 The need for loss resilient transport of media streams within RTP 44 has been recognised for a number of years, and various channel coding 45 schemes capable of providing such transport have been proposed. These 46 schemes have, to date, focused on the addition of FEC data to media 47 streams, however FEC schemes are not the only form of error resilience 48 which may be employed. This memo focuses on a transport mechanism 49 for interleaved media, providing an alternative which is of use when 50 bandwidth efficiency is required and latency is not an issue. 52 2 Discussion 54 The interleaving process resequences codec frames before transmission, 55 so that originally adjacent frames are separated by a guaranteed 56 distance in the transmitted stream and returned to their original 57 order at the receiver. Interleaving disperses the effect of packet 58 losses. If, for example, frames are 20ms in length and packets 80ms 59 (ie: 4 frames per packet), then the first packet could contain frames 60 1, 5, 9, 13; the second packet would contain frames 2, 6, 10, 14; 61 and so on. An example is illustrated in figure 1. 63 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 64 | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16| Initial 65 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 66 | 67 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ V 68 | 1| 5| 9|13| 2| 6|10|14| 3| 7|11|15| 4| 8|12|16| Reorder 69 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 70 | 71 +--+--+--+--+ +--+--+--+--+ +--+--+--+--+ +--+--+--+--+ V 72 | 1| 5| 9|13| | 2| 6|10|14| | 3| 7|11|15| | 4| 8|12|16| Packetise 73 +--+--+--+--+ +--+--+--+--+ +--+--+--+--+ +--+--+--+--+ 75 Figure 1: The interleaving process 77 It can be seen that the loss of a single packet from an interleaved 78 stream results in multiple small gaps in the reconstructed stream, 79 as opposed to the single large gap which would occur in a non-interleaved 80 stream. The size of the gap is dependent on the degree of interleaving 81 used, and can be made arbitrarily small at the expense of additional 82 latency. In many cases it is easier to reconstruct or repair a stream 83 with such loss patterns, than it is to repair a non-interleaved stream, 84 although this is clearly media and codec dependent. 86 The obvious disadvantage of interleaving is that it increases latency. 87 The major advantage of interleaving is that it provides increased 88 error resilience yet does not increase the bandwidth requirements 89 of a stream. 91 If each RTP packet contains a single codec frame, it is a simple 92 matter for the receiver to reconstruct an interleaved stream; frames 93 are decoded in the order specified by the RTP timestamp. It should 94 be noted that the timestamps of these packets will not be monotonically 95 increasing, an effect which will cause RTP header compression [5] 96 to fail for such a stream. 98 If multiple frames are packed into each RTP packet, the RTP timestamp 99 is not sufficient for the receiver to reconstruct the media stream. 100 It is also necessary to convey the order in which frames are packetised. 101 This information can be communicated explicitly, by timestamping each 102 frame, or implicitly by informing the receiver of the interleaving 103 function by non-RTP means. 105 It is more bandwidth efficient to implicitly transport this information, 106 since this allows frames to be packed into RTP packets with no additional 107 headers. 109 The use of explicit timestamps on each frame allows for the decoder 110 to be unaware of the interleaving function being used, and allows 111 for a common decoder for both redundant and interleaved media. Use 112 of a common payload format also allows for the codec to transparantly 113 change, since the payload type of each frame is conveyed. 115 It is our belief that the benefits of a common decoder model outweigh 116 the bandwidth overhead incurred, hence this document defines a payload 117 format with explicit timestamps on each frame. 119 3 Payload format definition 121 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 122 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to 123 be interpreted as described in [3]. 125 The payload format for redundant audio data [4] provides an efficient 126 means by which multiple frames of audio data may be combined within 127 a single RTP packet. Whilst that payload format was defined to allow 128 transport of media specific FEC data, it is also possible to use 129 it to convey interleaved data. 131 Interleaved frames are packed into an RTP packet using the same payload 132 format as redundant frames. Unlike redundant audio, each frame is 133 sent once only, with the timestamp offset fields in the payload header 134 used to indicate the ordering of interleaved frames. 136 Frames MUST be packed into packets such that the frame with the earliest 137 timestamp takes the place of the primary encoding, with the other 138 frames taking the place of the redundant encodings. This is because 139 the timestamp offset field in the payload header is unsigned and 140 gives the delay relative to the primary encoding. 142 Frames SHOULD be packetised such that each packet contains a frame 143 with the maximum timestamp offset required by the interleaver. If 144 this packet would not ordinarily contain a frame with this offset, 145 a dummy frame with this offset and zero length SHOULD be inserted. 146 This requirement is made to allow simple decoder design: it allows 147 the decoder buffering requirement to be identified with the receipt 148 of any packet. 150 The interleaving function to be used is a function of the encoder 151 only and is not defined here. The decoder does not need to be aware 152 of the interleaving function. 154 The assignment of an RTP payload type for this payload format is 155 outside the scope of this document, and will not be specified here. 156 It is expected that the RTP profile for a particular class of applications 157 will assign a payload type for this format, or if that is not done 158 then a payload type in the dynamic range SHOULD be chosen. 160 4 Example Packet 162 Assume the interleaving function illustrated in figure 1, using the 163 GSM codec with 20ms frames. The format of the packets would be as 164 illustrated in figure 2. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |V=2|P|X| CC=0 |M| PT | sequence number | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | timestamp of initial frame | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | synchronization source (SSRC) identifier | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |1| block PT=3 | timestamp offset (=1920)| block length (=33)| 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |1| block PT=3 | timestamp offset (=1280)| block length (=33)| 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |1| block PT=3 | timestamp offset (=640) | block length (=33)| 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |0| block PT=3 | | 182 +-+-+-+-+-+-+-+-+ + 183 | | 184 / 4 frames of GSM encoded data follow / 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2: Example interleaved packet 190 5 Interaction with redundant audio 192 Whilst the payload format defined in this memo is not the most efficient 193 possible in terms of bandwidth usage for an interleaved stream, the 194 reuse of the payload format for redundant audio data provides a number 195 of advantages which we now describe. 197 A decoder which can separate frames of data from interleaved/redundant 198 media streams and order them according to both timestamp and quality, 199 and which select the frame with the highest quality for a particular 200 time interval should be able to decode both interleaved and redundant 201 media streams with no change. 203 This allows for dual usage: if low-latency transmission is desired, and 204 some bandwidth overhead is acceptable, then the sender should choose 205 redundant transmission. If latency is not an issue interleaving should be 206 chosen. The decoder can render either stream with no change, resulting in 207 a system suitable for both interactive and non-interactive scenarios. 209 In addition, packets are sent with predictable sequence numbers and 210 timestamps, such that RTP header compression works correctly with 211 an interleaved stream using this format. 213 6 Security considerations 215 There are no additional security considerations beyond those noted 216 for RTP [1], the RTP profile for audio/video conferences [2] and 217 the RTP payload format for redundant audio [4]. 219 7 Acknowledgements 221 The author wishes to thank Orion Hodson for his helpful comments. 223 8 Author's addresses 225 Colin Perkins 226 Department of Computer Science 227 University College London 228 Gower Street 229 London WC1E 6BT 230 United Kingdom 232 Email: c.perkins@cs.ucl.c.uk 234 9 References 236 [1] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: 237 A transport protocol for real-time applications'', RFC1889, January 238 1996. 240 [2] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences 241 with Minimal Control'', RFC1890, January 1996. 243 [3] S. Bradner, ``Key words for use in RFCs to indicate requirement 244 levels'', RFC2119, March 1997. 246 [4] C. S. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, 247 J.-C. Bolot, A. Vega-Garcia and S. Fosse-Parisis, ``RTP Payload 248 for Redundant Audio Data'', RFC2198, November 1997. 250 [5] S. Casner and V. Jacobson, ``Compressing IP/UDP/RTP Headers for 251 Low-Speed Serial Links'', RFC2508, February 1999.