idnits 2.17.1 draft-ietf-avt-germ-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-23) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 182: '... of this byte MUST be zero....' RFC 2119 keyword, line 341: '... MUST NOT be done unless the destina...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 11, 1998) is 9295 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? '1' on line 357 looks like a reference -- Missing reference section? '2' on line 358 looks like a reference -- Missing reference section? '3' on line 361 looks like a reference -- Missing reference section? '4' on line 362 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force AVT WG 3 Internet Draft Mark Handley 4 draft-ietf-avt-germ-00.txt ISI 5 November 11, 1998 6 Expires: May, 1999 8 GeRM: Generic RTP Multiplexing 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 This document describes GeRM, an RTP payload format for 33 generic multiplexing of multiple RTP streams. 35 This document is a product of the Audio/Video Transport 36 (AVT) working group of the Internet Engineering Task 37 Force. Comments are solicited and should be addressed to 38 the working group's mailing list at rem-conf@es.net 39 and/or the author. 41 1 Introduction 43 When RTP[1] is used for end-to-end communication, each RTP data 44 stream in a session should be send separately to a different UDP 45 port. This allows heterogeneous treatment of the streams by the 46 network. For example, in a multimedia conference, we may be willing 47 to pay to make an RSVP[2] reservation for the audio, but unable to 48 reserve sufficient bandwidth for the video. Thus in the general case, 49 we argue that multiplexing multiple RTP streams together should be 50 avoided. 52 However, there are circumstances when this general rule may not make 53 a great deal of sense. If a stream is very low bandwidth, but needs 54 low latency, the overhead of RTP packetisation may be too large. On 55 slow modem links this can be overcome by using IP/UDP/RTP header 56 compression [3], but this is a hop-by-hop compression scheme, and so 57 is unsuitable for congested high-speed backbone links. 59 MPEG 4 is an example of a codec that produces multiple elementary 60 streams that comprise a single video stream. Many of these elementary 61 streams are very low bandwidth. It makes little sense to packetise 62 each of these elementary streams separately and send it to its own 63 RTP/UDP port. Instead a network-aware multiplexing layer is required 64 that can combine multiple elementary stream data units into a single 65 RTP packet in a way that does not reduce resilience to packet 66 loss[4]. 68 Another example is that of IP telephony gateways. In such a gateway, 69 incoming PSTN calls are packetised over RTP and transmitted to a 70 remote gateway, where they are turned back into PSTN calls again. 71 Between any pair of gateways there may be many simultaneous telephone 72 calls. If a relatively low bitrate codec is used such as GSM (approx 73 14Kbps), each of these flows then gains its own IP, UDP and RTP 74 headers comprising 40 bytes. With 20ms packetisation, the overhead is 75 over 100%. In this case, many (if not all) of the flows expect the 76 same network service. The header overhead can be significantly 77 reduced if multiple unrelated flows are multiplexed together into a 78 single RTP packet. 80 In both these cases and other similar ones, we can design specific 81 multiplexing protocols that satisfy one particular problem domain. 82 Rather than do this, we propose a multiplexing protocol that attempts 83 to be generic. Any pair of RTP flows with the same source and 84 destination may be multiplexed together. The degree of compression 85 depends on the similarity of the two flows, but the per-flow overhead 86 is always less than a single RTP header (without IP or UDP), and is 87 typically much better. 89 2 Specification 91 The approach taken in GeRM is similar to that taken with IP/UDP/RTP 92 header compression, in that only differences between one packet and 93 the next are encoded. However, unlike IP/UDP/RTP header compression, 94 GeRM does this by only encoding the differences between the RTP 95 headers of the different payloads in the same multiplexed packet, and 96 all RTP header state is reinitialised in each new packet. As a result 97 GeRM can function effectively across multiple network hops. 99 The basic model is that a single IP packet contains multiple RTP 100 headers each followed by its own payload. Each of these RTP headers 101 followed by its payload is referred to as a sub-packet compresses 102 each sub-packet header, so that fields which are predictable between 103 one sub-header and the next sub-header within the same packet are not 104 sent. 106 Each multiplexed RTP packet has a full RTP header which contains the 107 SSRC, Sequence number, Timestamp, etc corresponding to the first 108 sub-packet payload, but the RTP payload type field is set to a value 109 indicating this is a GeRM packet. The first sub-packet header will 110 compress out completely except for the payload-type field and length 111 because the full RTP header and the sub-packet header only differ in 112 the payload-type. 114 The second sub-packet header is then encoded based on predictable 115 differences between the original RTP header for that sub-packet and 116 the original RTP header for the first sub-packet. 118 The third sub-packet header is then encoded off of the original RTP 119 header for the second sub-packet and so forth. 121 A regular RTP header has the following format: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 |V=2|P|X| CC |M| PT | sequence number | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | timestamp | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | synchronization source (SSRC) identifier | 131 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 132 | contributing source (CSRC) identifiers | 133 | .... | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 A GeRM header consists of one byte followed by any RTP fields that 137 are not predictable from the previous header. The parts of the RTP 138 header corresponding to the bits of the GeRM header are as follows: 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | V |P|X| CC |M| PT | sequence number | 142 |0 0|0|0|0 0 0 0|1|2 2 2 2 2 2 2|3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3| 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | timestamp | 145 |4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5| 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | synchronization source (SSRC) identifier | 148 |6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6| 149 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 150 | contributing source (CSRC) identifiers | 151 | not compressed | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The GeRM Header is one byte: 156 0 1 2 3 4 5 6 7 157 +--+--+--+--+--+--+--+--+ 158 |B0|B1|B2|B3|B4|B5|B6|B7| 159 +--+--+--+--+--+--+--+--+ 161 The meaning of these bits is: 163 B0: 165 -zero indicates that the first byte of the original RTP header 166 remains unchanged from the original RTP header in the previous 167 subpacket (or outer RTP header if there's no previous sub- 168 packet in this packet). I.e, V, CC and P are unchanged. 170 -one indicates that the first byte (byte 1) of the original RTP 171 header immediately follows the GeRM header. 173 B1: Contains the marker bit from the sub-packet's RTP header. 175 B2: 177 -zero indicates that the payload type remains unchanged. 179 -one indicates that the payload type field follows the GeRM 180 header and any byte 0 header that may be present. Although PT 181 is a seven bit field, it is added as an eight bit field. Bit 0 182 of this byte MUST be zero. 184 B3: 186 -zero indicates that the sequence number remains unchanged. 188 -one indicates that the 16 bit sequence number field follows the 189 GeRM header and any byte 1 or PT header that may be present. 191 B4: 193 -zero indicates that the timestamp remains unchanged. 195 -one indicates that the 32 bit timestamp field follows the GeRM 196 header and any byte 1, PT or sequence number header that may be 197 present. 199 B5: 201 -zero indicates that the most significant 24 bits of the SSRC 202 remain unchanged. 204 -one indicates that the most significant 24 bits of the SSRC 205 follows the GeRM header and any byte 1, PT, sequence number or 206 timestamp field that may be present. 208 B6: 210 -zero indicates that the least significant 8 bits of the SSRC 211 are one higher than the preceding SSRC. 213 -one indicates that the least significant 8 bits of the SSRC 214 follows the GeRM header and any byte 1, PT, sequence number, 215 timestamp or MSB SSRC header fields that may be present. 217 B7: 219 -zero indicates that the sub-packet length in bytes (ignoring 220 the sub-packet header) is unchanged from the previous sub- 221 packet. 223 -one indicates that the sub-packet length (ignoring the sub- 224 packet header) follows all the other GeRM headers as an 8-bit 225 unsigned integer length field. 227 Any CSRC fields present in the original RTP header then follow the 228 GeRM headers. 230 3 Examples 231 In this section we attempt to characterise the likely behaviour of 232 GeRM in some typical circumstances. 234 3.1 Arbitrary Streams, Same Payload Type 236 Five RTP streams that originate at separate RTP sources (with SSRCs 237 SSRC1 to SSRC5, sequence numbers SEQ1 to SEQ5, and timestamps T1 to 238 T5) are being multiplexed together. They each use GSM compression, 239 and the GSM codec uses fixed size frames. 241 The compound packet is as follows: 243 IP Header 244 UDP Header 245 RTP Header, V=0, P=0, CC=0, PT=>GERM, SEQ=SEQ1, TS=T1, SSRC=SSRC1 246 GeRM Header, B0=0, B1=M1, B2=1, B3=0, B4=0, B5=0, B6=0, B7=1 247 8-bit PT=>GSM 248 8-bit length = length of GSM frame 249 GSM payload 1 250 GeRM Header, B0=0, B1=M2, B2=0, B3=1, B4=1, B5=1, B6=1, B7=0 251 16-bit Sequence Number SEQ2 252 32-bit Timestamp TS2 253 24+8 bit SSRC SSRC2 254 GSM payload 2 255 ... 256 GeRM Header, B0=0, B1=M5, B2=0, B3=1, B4=1, B5=1, B6=1, B7=0 257 16-bit Sequence Number SEQ5 258 32-bit Timestamp TS5 259 24+8 bit SSRC SSRC5 260 GSM payload 5 262 The overhead is 40 bytes (IP+UDP+RTP) + 3 bytes (first sub-header) + 263 11 bytes (each subsequent sub-header), or a total of 87 bytes, as 264 opposed to 200 bytes for separate RTP packets. 266 In some cases, having a multiplex stream sequence number in the outer 267 RTP packet (rather than the first payload sequence number) might be 268 desirable. This might be the case if we wish to add packet-level FEC 269 to the multiplexed stream. In such a case, the sequence number of 270 sub-packet 1 does not compress out, adding a further two bytes 271 overhead. 273 3.2 Cooperating PSTN-IP gateways 275 If several RTP streams coded with the same codec are ordinating at a 276 PSTN->IP gateway and all terminate at the same IP->PSTN gateway, and 277 if we assume that an out-of-band signalling mechanism is used to 278 communicate SSRC information at call setup time, then we can achieve 279 significantly better compression. 281 To do this we algorithmically generate the SSRC rather than 282 allocating it randomly as specified in the RTP specification. This is 283 acceptable in this context because only the remote gateway will ever 284 see the SSRC. 286 As consecutive flows arrive, they are given consecutive SSRCs, which 287 in any event must be communicated as part of the call setup 288 mechanism. All the flows are digitised and compressed at the same 289 time, so they share a common clock and hence common timestamps. If no 290 silence suppression is performed, the sequence numbers can be 291 consecutive too, but we do not assume this. 293 As flows terminate, they will leave gaps in the SSRC space. New flows 294 are then allocated the now unused SSRCs to attempt to keep the SSRC 295 space as contiguous as possible. 297 For the sake of example, we assume we have SSRCs 1 to 3 and 5 to 10 298 in use, and that the flows with SSRC 5, 7 and 8 are being silence 299 suppressed. This leaves us with flows 1,2,3,6,9 and 10 to transmit. 301 IP Header 302 UDP Header 303 RTP Header, V=0, P=0, CC=0, PT=>GERM, SEQ=SEQ1, TS=T1, SSRC=SSRC1 304 GeRM Header, B0=0, B1=M1, B2=1, B3=0, B4=0, B5=0, B6=0, B7=1 305 8-bit PT=>GSM 306 8-bit length = length of GSM frame 307 GSM payload 1 308 GeRM Header, B0=0, B1=M2, B2=0, B3=1, B4=0, B5=0, B6=0, B7=0 309 16-bit Sequence Number SEQ2 310 GSM payload 2 311 GeRM Header, B0=0, B1=M3, B2=0, B3=1, B4=0, B5=0, B6=0, B7=0 312 16-bit Sequence Number SEQ3 313 GSM payload 3 314 GeRM Header, B0=0, B1=M6, B2=0, B3=1, B4=0, B5=0, B6=1, B7=0 315 16-bit Sequence Number SEQ6 316 8-bit LSByte of SSRC 6 317 GSM payload 6 318 GeRM Header, B0=0, B1=M9, B2=0, B3=1, B4=0, B5=0, B6=1, B7=0 319 16-bit Sequence Number SEQ9 320 8-bit LSByte of SSRC 9 321 GSM payload 9 322 GeRM Header, B0=0, B1=M10, B2=0, B3=1, B4=0, B5=0, B6=0, B7=0 323 16-bit Sequence Number SEQ10 325 GSM payload 10 327 Thus the overhead is 40 bytes for the IP/UDP/RTP, 3 bytes for sub- 328 header 1, 4 bytes each for sub-headers 2, 3, and 10, and 5 bytes for 329 sub-headers 6 and 9. This totals 65 bytes against 240 bytes for 330 separate IP/UDP/RTP headers per flow. Typically each new flow being 331 included in the packet will require 4 to 5 bytes of overhead in 332 addition to the compressed data itself. 334 We might envisage ways in which sequence numbers of flows can also be 335 manipulated as a flow returns from silence suppression (step the 336 sequence number to match that of the flow with preceding SSRC) if we 337 are sure that the flow will be removed from RTP at the next 338 destination. This would reduce the per-flow overhead to between 1 and 339 5 bytes depending on the effectiveness of this mapping. Whether this 340 is worth pursuing is an open issue that providers may consider. It 341 MUST NOT be done unless the destination knows to expect such 342 behaviour and not treat it as loss. 344 Appendix A: Author's Address 346 Mark Handley 347 Information Sciences Institute, 348 University of Southern California, 349 c/o MIT Laboratory for Computer Science, 350 545 Technology Square, 351 Cambridge, MA 02139, 352 United States 353 electronic mail: mjh@isi.edu 355 4 Bibliography 357 [1] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson "RTP: A 358 Transport Protocol for Real-Time Applications" RFC 1889. [2] R. 359 Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource 360 ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", 361 RFC 2205 [3] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers 362 for Low-Speed Serial Links", Internet Draft. [4] M. Handley, 363 "Guidelines for writers of RTP payload format specifications", 364 Internet Draft.