idnits 2.17.1 draft-ietf-avt-crtp-enhance-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: ---------------------------------------------------------------------------- ** 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 Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 1) being 1960 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.) ** There are 205 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1467 has weird spacing: '...e field must ...' == Line 1520 has weird spacing: '...# Time pkt t...' == Line 1538 has weird spacing: '...# Time pkt t...' == Line 1566 has weird spacing: '...# Time pkt t...' == Line 1580 has weird spacing: '...# Time pkt t...' == (2 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1763 looks like a reference -- Missing reference section? '2' on line 1767 looks like a reference -- Missing reference section? '3' on line 1795 looks like a reference -- Missing reference section? '4' on line 1773 looks like a reference -- Missing reference section? '5' on line 1776 looks like a reference -- Missing reference section? 'IPCPHP' on line 1690 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group Stephen Casner 3 Internet Draft Packet Design 4 November 17, 2000 Van Jacobson 5 Expires June 2001 Packet Design 6 draft-ietf-avt-crtp-enhance-01.txt Tmima Koren 7 Bruce Thompson 8 Dan Wing 9 Patrick Ruddy 10 Alex Tweedly 11 Cisco Systems 12 John Geevarghese 13 Telseon 15 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links 17 Status of this memo 19 This document is an Internet Draft and is in full conformance with all 20 provisions of Section 10 of RFC 2026. Internet Drafts are working documents of 21 the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. 22 Note that other groups may also distribute working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six months. Internet 25 Drafts may be updated, replaced, or obsolete by other documents at any time. It 26 is not appropriate to use Internet Drafts as reference material or to cite them 27 other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.txt 35 This draft is being submitted as a possible work item to the IETF Audio/Video 36 Transport working group. To subscribe to the mailing list send a message to 37 rem-conf-request@es.net with the line "subscribe" in the body of the message. 38 Archives are available from: 39 ftp://ftp.es.net/pub/mail-archive/rem-conf 41 Copyright Notice 43 Copyright (C) The Internet Society (1999-2000). All Rights Reserved. 45 Abstract 47 This document describes a method for compressing the headers of 48 IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. 49 In many cases, all three headers can be compressed to 2-4 bytes. 51 Comments are solicited and should be addressed to the working group 52 mailing list rem-conf@es.net and/or the author(s). 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 1. Introduction 60 Since the Real-time Transport Protocol was published as an RFC [1], 61 there has been growing interest in using RTP as one step to achieve 62 interoperability among different implementations of network 63 audio/video applications. However, there is also concern that the 64 12-byte RTP header is too large an overhead for 20-byte payloads when 65 operating over low speed lines such as dial-up modems at 14.4 or 28.8 66 kb/s. (Some existing applications operating in this environment use 67 an application-specific protocol with a header of a few bytes that 68 has reduced functionality relative to RTP.) 70 Header size may be reduced through compression techniques as has been 71 done with great success for TCP [2]. In this case, compression might 72 be applied to the RTP header alone, on an end-to-end basis, or to the 73 combination of IP, UDP and RTP headers on a link-by-link basis. 74 Compressing the 40 bytes of combined headers together provides 75 substantially more gain than compressing 12 bytes of RTP header alone 76 because the resulting size is approximately the same (2-4 bytes) in 77 either case. Compressing on a link-by-link basis also provides 78 better performance because the delay and loss rate are lower. 79 Therefore, the method defined here is for combined compression of IP, 80 UDP and RTP headers on a link-by-link basis. 82 This document defines a compression scheme that may be used with 83 IPv4, IPv6 or packets encapsulated with more than one IP header, 84 though the initial focus is on IPv4. The IP/UDP/RTP compression 85 defined here is intended to fit within the more general compression 86 framework specified in [3] for use with both IPv6 and IPv4. That 87 framework defines TCP and non-TCP as two classes of transport above 88 IP. This specification creates IP/UDP/RTP as a third class extracted 89 from the non-TCP class. 91 2. Assumptions and Tradeoffs 93 The goal of this compression scheme is to reduce the IP/UDP/RTP 94 headers to two bytes for most packets in the case where no UDP 95 checksums are being sent, or four bytes with checksums. It is 96 motivated primarily by the specific problem of sending audio and 97 video over 14.4 and 28.8 dialup modems. These links tend to provide 98 full-duplex communication, so the protocol takes advantage of that 99 fact, though the protocol may also be used with reduced performance 100 on simplex links. This compression scheme performs best on local 101 links with low round-trip-time. 103 This specification does not address segmentation and preemption of 104 large packets to reduce the delay across the slow link experienced by 105 small real-time packets, except to identify in Section 4 some 106 interactions between segmentation and compression that may occur. 107 Segmentation schemes may be defined separately and used in 108 conjunction with the compression defined here. 110 It should be noted that implementation simplicity is an important 111 factor to consider in evaluating a compression scheme. 112 Communications servers may need to support compression over perhaps 113 as many as 100 dial-up modem lines using a single processor. 114 Therefore, it may be appropriate to make some simplifications in the 115 design at the expense of generality, or to produce a flexible design 116 that is general but can be subsetted for simplicity. Higher 117 compression gain might be achieved by communicating more complex 118 models for the changing header fields from the compressor to the 119 decompressor, but that complexity is deemed unnecessary. The next 120 sections discuss some of the tradeoffs listed here. 122 2.1. Simplex vs. Full Duplex 124 In the absence of other constraints, a compression scheme that worked 125 over simplex links would be preferred over one that did not. 126 However, operation over a simplex link requires periodic refreshes 127 with an uncompressed packet header to restore compression state in 128 case of error. If an explicit error signal can be returned instead, 129 the delay to recovery may be shortened substantially. The overhead 130 in the no-error case is also reduced. To gain these performance 131 improvements, this specification includes an explicit error 132 indication sent on the reverse path. 134 On a simplex link, it would be possible to use a periodic refresh 135 instead. Whenever the decompressor detected an error in a particular 136 packet stream, it would simply discard all packets in that stream 137 until an uncompressed header was received for that stream, and then 138 resume decompression. The penalty would be the potentially large 139 number of packets discarded. The periodic refresh method described 140 in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex 141 links or links with high delay as well as to other non-TCP packet 142 streams. 144 2.2. Links with high bit error rate and long round trip delay 146 IP/UDP/RTP header compression may be used in scenarios where a compressed link 147 could extend over a long physical distance and involve multiple layer-2 148 switching points. An example of such a link is RTP transport over ATM AAL5, 149 where the "link" would actually traverse through multiple layer-2 switching 150 points on the path from the CRTP transmitter (compressor) to the CRTP receiver 151 (decompressor). Another example is a wireless link. Such links may experience 152 significant packet loss and/or long round trip delays. Contexts get invalidated 153 due to packet loss, but the CRTP error recovery mechanism using CONTEXT_STATE 154 messages is not efficient due to the long round trip delay. 156 In scenarios such as this, it is desirable to minimize context invalidation. A 157 set of enhancements is defined for error prevention and recovery. The 158 enhancements make CRTP more robust and resilient to packet loss, which in turn 159 will reduce context invalidation. 161 2.3. Segmentation and Layering 163 Delay induced by the time required to send a large packet over the 164 slow link is not a problem for one-way audio, for example, because 165 the receiver can adapt to the variance in delay. However, for 166 interactive conversations, minimizing the end-to-end delay is 167 critical. Segmentation of large, non-real-time packets to allow 168 small real-time packets to be transmitted between segments can reduce 169 the delay. 171 This specification deals only with compression and assumes 172 segmentation, if included, will be handled as a separate layer. It 173 would be inappropriate to integrate segmentation and compression in 174 such a way that the compression could not be used by itself in 175 situations where segmentation was deemed unnecessary or impractical. 176 Similarly, one would like to avoid any requirements for a reservation 177 protocol. The compression scheme can be applied locally on the two 178 ends of a link independent of any other mechanisms except for the 179 requirements that the link layer provide some packet type codes, a 180 packet length indication, and good error detection. 182 Conversely, separately compressing the IP/UDP and RTP layers loses 183 too much of the compression gain that is possible by treating them 184 together. Crossing these protocol layer boundaries is appropriate 185 because the same function is being applied across all layers. 187 3. The Compression Algorithm 189 The compression algorithm defined in this document draws heavily upon 190 the design of TCP/IP header compression as described in RFC 1144 [2]. 191 Readers are referred to that RFC for more information on the 192 underlying motivations and general principles of header compression. 194 3.1. The basic idea 196 In TCP header compression, the first factor-of-two reduction in data 197 rate comes from the observation that half of the bytes in the IP and 198 TCP headers remain constant over the life of the connection. After 199 sending the uncompressed header once, these fields may be elided from 200 the compressed headers that follow. The remaining compression comes 201 from differential coding on the changing fields to reduce their size, 202 and from eliminating the changing fields entirely for common cases by 203 calculating the changes from the length of the packet. This length 204 is indicated by the link-level protocol. 206 For RTP header compression, some of the same techniques may be 207 applied. However, the big gain comes from the observation that 208 although several fields change in every packet, the difference from 209 packet to packet is often constant and therefore the second-order 210 difference is zero. By maintaining both the uncompressed header and 211 the first-order differences in the session state shared between the 212 compressor and decompressor, all that must be communicated is an 213 indication that the second-order difference was zero. In that case, 214 the decompressor can reconstruct the original header without any loss 215 of information simply by adding the first-order differences to the 216 saved uncompressed header as each compressed packet is received. 218 Just as TCP/IP header compression maintains shared state for multiple 219 simultaneous TCP connections, this IP/UDP/RTP compression SHOULD 220 maintain state for multiple session contexts. A session context is 221 defined by the combination of the IP source and destination 222 addresses, the UDP source and destination ports, and the RTP SSRC 223 field. A compressor implementation might use a hash function on 224 these fields to index a table of stored session contexts. The 225 compressed packet carries a small integer, called the session context 226 identifier or CID, to indicate in which session context that packet 227 should be interpreted. The decompressor can use the CID to index its 228 table of stored session contexts directly. 230 Because the RTP compression is lossless, it may be applied to any UDP 231 traffic that benefits from it. Most likely, the only packets that 232 will benefit are RTP packets, but it is acceptable to use heuristics 233 to determine whether or not the packet is an RTP packet because no 234 harm is done if the heuristic gives the wrong answer. This does 235 require executing the compression algorithm for all UDP packets, or 236 at least those with even port numbers (see section 3.4). 238 Most compressor implementations will need to maintain a "negative 239 cache" of packet streams that have failed to compress as RTP packets 240 for some number of attempts in order to avoid further attempts. 241 Failing to compress means that some fields in the potential RTP 242 header that are expected to remain constant most of the time, such as 243 the payload type field, keep changing. Even if the other such fields 244 remain constant, a packet stream with a constantly changing SSRC 245 field SHOULD be entered in the negative cache to avoid consuming all 246 of the available session contexts. The negative cache is indexed by 247 the source and destination IP address and UDP port pairs but not the 248 RTP SSRC field since the latter may be changing. When RTP 249 compression fails, the IP and UDP headers MAY still be compressed. 251 Fragmented IP Packets that are not initial fragments and packets that 252 are not long enough to contain a complete UDP header MUST NOT be sent 253 as FULL_HEADER packets. Furthermore, packets that do not 254 additionally contain at least 12 bytes of UDP data MUST NOT be used 255 to establish RTP context. If such a packet is sent as a FULL_HEADER 256 packet, it MAY be followed by COMPRESSED_UDP packets but MUST NOT be 257 followed by COMPRESSED_RTP packets. 259 3.2. Header Compression for RTP Data Packets 261 In the IPv4 header, only the total length, packet ID, and header 262 check-sum fields will normally change. The total length is redundant 263 with the length provided by the link layer, and since this 264 compression scheme must depend upon the link layer to provide good 265 error detection (e.g., PPP's CRC [4]), the header checksum may also 266 be elided. This leaves only the packet ID, which, assuming no IP 267 fragmentation, would not need to be communicated. However, in order 268 to maintain lossless compression, changes in the packet ID will be 269 transmitted. The packet ID usually increments by one or a small 270 number for each packet. (Some systems increment the ID with the 271 bytes swapped, which results in slightly less compression.) In the 272 IPv6 base header, there is no packet ID nor header checksum and only 273 the payload length field changes. 275 In the UDP header, the length field is redundant with the IP total 276 length field and the length indicated by the link layer. The UDP 277 check-sum field will be a constant zero if the source elects not to 278 generate UDP checksums. Otherwise, the checksum must be communicated 279 intact in order to preserve the lossless compression. Maintaining 280 end-to-end error detection for applications that require it is an 281 important principle. 283 In the RTP header, the SSRC identifier is constant in a given context 284 since that is part of what identifies the particular context. For 285 most packets, only the sequence number and the timestamp will change 286 from packet to packet. If packets are not lost or misordered 287 upstream from the compressor, the sequence number will increment by 288 one for each packet. For audio packets of constant duration, the 289 timestamp will increment by the number of sample periods conveyed in 290 each packet. For video, the timestamp will change on the first 291 packet of each frame, but then stay constant for any additional 292 packets in the frame. If each video frame occupies only one packet, 293 but the video frames are generated at a constant rate, then again the 294 change in the timestamp from frame to frame is constant. Note that 295 in each of these cases the second-order difference of the sequence 296 number and timestamp fields is zero, so the next packet header can be 297 constructed from the previous packet header by adding the first-order 298 differences for these fields that are stored in the session context 299 along with the previous uncompressed header. When the second-order 300 difference is not zero, the magnitude of the change is usually much 301 smaller than the full number of bits in the field, so the size can be 302 reduced by encoding the new first-order difference and transmitting 303 it rather than the absolute value. 305 The M bit will be set on the first packet of an audio talkspurt and 306 the last packet of a video frame. If it were treated as a constant 307 field such that each change required sending the full RTP header, 308 this would reduce the compression significantly. Therefore, one bit 309 in the compressed header will carry the M bit explicitly. 311 If the packets are flowing through an RTP mixer, most commonly for 312 audio, then the CSRC list and CC count will also change. However, 313 the CSRC list will typically remain constant during a talkspurt or 314 longer, so it need be sent only when it changes. 316 3.3. The protocol 318 The compression protocol must maintain a collection of shared 319 information in a consistent state between the compressor and 320 decompressor. There is a separate session context for each 321 IP/UDP/RTP packet stream, as defined by a particular combination of 322 the IP source and destination addresses, UDP source and destination 323 ports, and the RTP SSRC field. The number of session contexts to be 324 maintained MAY be negotiated between the compressor and decompressor. 325 Each context is identified by an 8- or 16-bit identifier, depending 326 upon the number of contexts negotiated, so the maximum number is 327 65536. Both uncompressed and compressed packets MUST carry the 328 context ID and a 4-bit sequence number used to detect packet loss 329 between the compressor and decompressor. Each context has its own 330 separate sequence number space so that a single packet loss need only 331 invalidate one context. 333 The shared information in each context consists of the following 334 items: 336 o The full IP, UDP and RTP headers, possibly including a CSRC 337 list, for the last packet sent by the compressor or 338 reconstructed by the decompressor. 340 o The first-order difference for the IPv4 ID field, initialized to 341 1 whenever an uncompressed IP header for this context is 342 received and updated each time a delta IPv4 ID field is received 343 in a compressed packet. 345 o The first-order difference for the RTP timestamp field, 346 initialized to 0 whenever an uncompressed packet for this 347 context is received and updated each time a delta RTP timestamp 348 field is received in a compressed packet. 350 o The last value of the 4-bit sequence number, which is used to 351 detect packet loss between the compressor and decompressor. 353 o The current generation number for non-differential coding of UDP 354 packets with IPv6 (see [3]). For IPv4, the generation number 355 may be set to zero if the COMPRESSED_NON_TCP packet type, 356 defined below, is never used. 358 o A context-specific delta encoding table (see section 3.3.4) may 359 optionally be negotiated for each context. 361 In order to communicate packets in the various uncompressed and 362 compressed forms, this protocol depends upon the link layer being 363 able to provide an indication of four new packet formats in addition 364 to the normal IPv4 and IPv6 packet formats: 366 FULL_HEADER - communicates the uncompressed IP header plus any 367 following headers and data to establish the uncompressed header 368 state in the decompressor for a particular context. The FULL- 369 HEADER packet also carries the 8- or 16-bit session context 370 identifier and the 4-bit sequence number to establish 371 synchronization between the compressor and decompressor. The 372 format is shown in section 3.3.1. 374 COMPRESSED_UDP - communicates the IP and UDP headers compressed to 375 6 or fewer bytes (often 2 if UDP checksums are disabled), followed 376 by any subsequent headers (possibly RTP) in uncompressed form, 377 plus data. This packet type is used when there are differences in 378 the usually constant fields of the (potential) RTP header. The 379 RTP header includes a potentially changed value of the SSRC field, 380 so this packet may redefine the session context. The format is 381 shown in section 3.3.3. 383 COMPRESSED_RTP - indicates that the RTP header is compressed along 384 with the IP and UDP headers. The size of this header may still be 385 just two bytes, or more if differences must be communicated. This 386 packet type is used when the second-order difference (at least in 387 the usually constant fields) is zero. It includes delta encodings 388 for those fields that have changed by other than the expected 389 amount to establish the first-order differences after an 390 uncompressed RTP header is sent and whenever they change. The 391 format is shown in section 3.3.2. 393 CONTEXT_STATE - indicates a special packet sent from the 394 decompressor to the compressor to communicate a list of context 395 IDs for which synchronization has or may have been lost. This 396 packet is only sent across the point-to-point link so it requires 397 no IP header. The format is shown in section 3.3.5. 399 When this compression scheme is used with IPv6 as part of the general 400 header compression framework specified in [3], another packet type 401 MAY be used: 403 COMPRESSED_NON_TCP - communicates the compressed IP and UDP 404 headers as defined in [3] without differential encoding. If it 405 were used for IPv4, it would require one or two bytes more than 406 the COMPRESSED_UDP form listed above in order to carry the IPv4 ID 407 field. For IPv6, there is no ID field and this non-differential 408 compression is more resilient to packet loss. 410 Assignments of numeric codes for these packet formats in the Point- 411 to-Point Protocol [4] are to be made by the Internet Assigned Numbers 412 Authority. 414 3.3.1. FULL_HEADER (uncompressed) packet format 416 The definition of the FULL_HEADER packet given here is intended to be 417 the consistent with the definition given in [3]. Full details on 418 design choices are given there. 420 The format of the FULL_HEADER packet is the same as that of the 421 original packet. In the IPv4 case, this is usually an IP header, 422 followed by a UDP header and UDP payload that may be an RTP header 423 and its payload. However, the FULL_HEADER packet may also carry IP 424 encapsulated packets, in which case there would be two IP headers 425 followed by UDP and possibly RTP. Or in the case of IPv6, the packet 426 may be built of some combination of IPv6 and IPv4 headers. Each 427 successive header is indicated by the type field of the previous 428 header, as usual. 430 The FULL_HEADER packet differs from the corresponding normal IPv4 or 431 IPv6 packet in that it must also carry the compression context ID and 432 the 4-bit sequence number. In order to avoid expanding the size of 433 the header, these values are inserted into length fields in the IP 434 and UDP headers since the actual length may be inferred from the 435 length provided by the link layer. Two 16-bit length fields are 436 needed; these are taken from the first two available headers in the 437 packet. That is, for an IPv4/UDP packet, the first length field is 438 the total length field of the IPv4 header, and the second is the 439 length field of the UDP header. For an IPv4 encapsulated packet, the 440 first length field would come from the total length field of the 441 first IP header, and the second length field would come from the 442 total length field of the second IP header. 444 As specified in Sections 5.3.2 of [3], the position of the context ID 445 (CID) and 4-bit sequence number varies depending upon whether 8- or 446 16-bit context IDs have been selected, as shown in the following 447 diagram (16 bits wide, with the most-significant bit is to the left): 449 For 8-bit context ID: 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |0|1| Generation| CID | First length field 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | 0 | seq | Second length field 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 For 16-bit context ID: 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |1|1| Generation| 0 | seq | First length field 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | CID | Second length field 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 The first bit in the first length field indicates the length of the 470 CID. The length of the CID MUST either be constant for all contexts 471 or two additional distinct packet types MUST be provided to 472 separately indicate COMPRESSED_UDP and COMPRESSED_RTP packet formats 473 with 8- and 16-bit CIDs. The second bit in the first length field is 474 1 to indicate that the 4-bit sequence number is present, as is always 475 the case for this IP/UDP/RTP compression scheme. 477 The generation field is used with IPv6 for COMPRESSED_NON_TCP packets 478 as described in [3]. For IPv4-only implementations that do not use 479 COMPRESSED_NON_TCP packets, the compressor SHOULD set the generation 480 value to zero. For consistent operation between IPv4 and IPv6, the 481 generation value is stored in the context when it is received by the 482 decompressor, and the most recent value is returned in the 483 CONTEXT_STATE packet. 485 When a FULL_HEADER packet is received, the complete set of headers is 486 stored into the context selected by the context ID. The 4-bit 487 sequence number is also stored in the context, thereby 488 resynchronizing the decompressor to the compressor. 490 When COMPRESSED_NON_TCP packets are used, the 4-bit sequence number 491 is inserted into the "Data Field" of that packet and the D bit is set 492 as described in Section 6 of [3]. When a COMPRESSED_NON_TCP packet 493 is received, the generation number is compared to the value stored in 494 the context. If they are not the same, the context is not up to date 495 and MUST be refreshed by a FULL_HEADER packet. If the generation 496 does match, then the compressed IP and UDP header information, the 497 4-bit sequence number, and the (potential) RTP header are all stored 498 into the saved context. 500 The amount of memory required to store the context will vary 501 depending upon how many encapsulating headers are included in the 502 FULL_HEADER packet. The compressor and decompressor MAY negotiate a 503 maximum header size. 505 3.3.2. COMPRESSED_RTP packet format 507 When the second-order difference of the RTP header from packet to 508 packet is zero, the decompressor can reconstruct a packet simply by 509 adding the stored first-order differences to the stored uncompressed 510 header representing the previous packet. All that need be 511 communicated is the session context identifier and a small sequence 512 number (not related to the RTP sequence number) to maintain 513 synchronization and detect packet loss between the compressor and 514 decompressor. 516 If the second-order difference of the RTP header is not zero for some 517 fields, the new first-order difference for just those fields is 518 communicated using a compact encoding. The new first-order 519 difference values are added to the corresponding fields in the 520 uncompressed header in the decompressor's session context, and are 521 also stored explicitly in the context to be added to the 522 corresponding fields again on each subsequent packet in which the 523 second-order difference is zero. Each time the first-order 524 difference changes, it is transmitted and stored in the context. 526 In practice, the only fields for which it is useful to store the 527 first-order difference are the IPv4 ID field and the RTP timestamp. 528 For the RTP sequence number field, the usual increment is 1. If the 529 sequence number changes by other than 1, the difference must be 530 communicated but does not set the expected difference for the next 531 packet. Instead, the expected first-order difference remains fixed 532 at 1 so that the difference need not be explicitly communicated on 533 the next packet assuming it is in order. 535 For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or 536 COMPRESSED_UDP packet is sent to refresh the RTP state, the stored 537 first-order difference is initialized to zero. If the timestamp is 538 the same on the next packet (e.g., same video frame), then the 539 second-order difference is zero. Otherwise, the difference between 540 the timestamps of the two packets is transmitted as the new first- 541 order difference to be added to the timestamp in the uncompressed 542 header stored in the decompressor's context and also stored as the 543 first-order difference in that context. Each time the first-order 544 difference changes on subsequent packets, that difference is again 545 transmitted and used to update the context. 547 Similarly, since the IPv4 ID field frequently increments by one, the 548 first-order difference for that field is initialized to one when the 549 state is refreshed by a FULL_HEADER packet, or when a 550 COMPRESSED_NON_TCP packet is sent since it carries the ID field in 551 uncompressed form. Thereafter, whenever the first-order difference 552 changes, it is transmitted and stored in the context. 554 A bit mask will be used to indicate which fields have changed by 555 other than the expected difference. In addition to the small link 556 sequence number, the list of items to be conditionally communicated 557 in the compressed IP/UDP/RTP header is as follows: 559 I = IPv4 packet ID (always 0 if no IPv4 header) 560 U = UDP checksum 561 M = RTP marker bit 562 S = RTP sequence number 563 T = RTP timestamp 564 L = RTP CSRC count and list 566 If 4 bits are needed for the link sequence number to get a reasonable 567 probability of loss detection, there are too few bits remaining to 568 assign one bit to each of these items and still fit them all into a 569 single byte to go along with the context ID. 571 It is not necessary to explicitly carry the U bit to indicate the 572 presence of the UDP checksum because a source will typically include 573 check-sums on all packets of a session or none of them. When the 574 session state is initialized with an uncompressed header, if there is 575 a nonzero checksum present, an unencoded 16-bit checksum will be 576 inserted into the compressed header in all subsequent packets until 577 this setting is changed by sending another uncompressed packet. 579 Of the remaining items, the L bit for the CSRC count and list may be 580 the one least frequently used. Rather than dedicating a bit in the 581 mask to indicate CSRC change, an unusual combination of the other 582 bits may be used instead. This bit combination is denoted MSTI. If 583 all four of the bits for the IP packet ID, RTP marker bit, RTP 584 sequence number and RTP timestamp are set, this is a special case 585 indicating an extended form of the compressed RTP header will follow. 586 That header will include an additional byte containing the real 587 values of the four bits plus the CC count. The CSRC list, of length 588 indicated by the CC count, will be included just as it appears in the 589 uncompressed RTP header. 591 The other fields of the RTP header (version, P bit, X bit, payload 592 type and SSRC identifier) are assumed to remain relatively constant. 593 In particular, the SSRC identifier is defined to be constant for a 594 given context because it is one of the factors selecting the context. 595 If any of the other fields change, the uncompressed RTP header MUST 596 sent as described in Section 3.3.3. 598 The following diagram shows the compressed IP/UDP/RTP header with 599 dotted lines indicating fields that are conditionally present. The 600 most significant bit is numbered 0. Multi-byte fields are sent in 601 network byte order (most significant byte first). The delta fields 602 are often a single byte as shown but may be two or three bytes 603 depending upon the delta value as explained in Section 3.3.4. 605 0 1 2 3 4 5 6 7 606 +...............................+ 607 : msb of session context ID : (if 16-bit CID) 608 +-------------------------------+ 609 | lsb of session context ID | 610 +---+---+---+---+---+---+---+---+ 611 | M | S | T | I | link sequence | 612 +---+---+---+---+---+---+---+---+ 613 : : 614 + UDP checksum + (if nonzero in context) 615 : : 616 +...............................+ 617 : : 618 + "RANDOM" fields + (if encapsulated) 619 : : 620 +...............................+ 621 : M'| S'| T'| I'| CC : (if MSTI = 1111) 622 +...............................+ 623 : delta IPv4 ID : (if I or I' = 1) 624 +...............................+ 625 : delta RTP sequence : (if S or S' = 1) 626 +...............................+ 627 : delta RTP timestamp : (if T or T' = 1) 628 +...............................+ 629 : : 630 : CSRC list : (if MSTI = 1111 631 : : and CC nonzero) 632 : : 633 +...............................+ 634 : : 635 : RTP header extension : (if X set in context) 636 : : 637 : : 638 +-------------------------------+ 639 | | 640 | RTP data | 641 / / 642 / / 643 | | 644 +-------------------------------+ 645 : padding : (if P set in context) 646 +...............................+ 648 When more than one IPv4 header is present in the context as 649 initialized by the FULL_HEADER packet, then the IP ID fields of 650 encapsulating headers MUST be sent as absolute values as described in 651 [3]. These fields are identified as "RANDOM" fields. They are 652 inserted into the COMPRESSED_RTP packet in the same order as they 653 appear in the original headers, immediately following the UDP 654 checksum if present or the MSTI byte if not, as shown in the diagram. 655 Only if an IPv4 packet immediately precedes the UDP header will the 656 IP ID of that header be sent differentially, i.e., potentially with 657 no bits if the second difference is zero, or as a delta IPv4 ID field 658 if not. If there is not an IPv4 header immediately preceding the UDP 659 header, then the I bit MUST be 0 and no delta IPv4 ID field will be 660 present. 662 3.3.3. COMPRESSED_UDP packet format 664 If there is a change in any of the fields of the RTP header that are 665 normally constant (such as the payload type field), then an 666 uncompressed RTP header MUST be sent. If the IP and UDP headers do 667 not also require updating, this RTP header MAY be carried in a 668 COMPRESSED_UDP packet rather than a FULL_HEADER packet. The 669 COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP 670 packet except that the M, S and T bits are always 0 and the 671 corresponding delta fields are never included: 673 0 1 2 3 4 5 6 7 674 +...............................+ 675 : msb of session context ID : (if 16-bit CID) 676 +-------------------------------+ 677 | lsb of session context ID | 678 +---+---+---+---+---+---+---+---+ 679 | 0 | 0 | 0 | I | link sequence | 680 +---+---+---+---+---+---+---+---+ 681 : : 682 + UDP checksum + (if nonzero in context) 683 : : 684 +...............................+ 685 : : 686 + "RANDOM" fields + (if encapsulated) 687 : : 688 +...............................+ 689 : delta IPv4 ID : (if I = 1) 690 +-------------------------------+ 691 | UDP data | 692 : (uncompressed RTP header) : 694 Note that this constitutes a form of IP/UDP header compression 695 different from COMPRESSED_NON_TCP packet type defined in [3]. The 696 motivation is to allow reaching the target of two bytes when UDP 697 checksums are disabled, as IPv4 allows. The protocol in [3] does not 698 use differential coding for UDP packets, so in the IPv4 case, two 699 bytes of IP ID, and two bytes of UDP checksum if nonzero, would 700 always be transmitted in addition to two bytes of compression prefix. 701 For IPv6, the COMPRESSED_NON_TCP packet type MAY be used instead. 703 3.3.4. Encoding of differences 705 The delta fields in the COMPRESSED_RTP and COMPRESSED_UDP packets are 706 encoded with a variable-length mapping for compactness of the more 707 commonly-used values. A default encoding is specified below, but it 708 is RECOMMENDED that implementations use a table-driven delta encoder 709 and decoder to allow negotiation of a table specific for each session 710 if appropriate, possibly even an optimal Huffman encoding. Encodings 711 based on sequential interpretation of the bit stream, of which this 712 default table and Huffman encoding are examples, allow a reasonable 713 table size and may result in an execution speed faster than a non- 714 table-driven implementation with explicit tests for ranges of values. 716 The default delta encoding is specified in the following table. This 717 encoding was designed to efficiently encode the small changes that 718 may occur in the IP ID and in RTP sequence number when packets are 719 lost upstream from the compressor, yet still handling most audio and 720 video deltas in two bytes. The column on the left is the decimal 721 value to be encoded, and the column on the right is the resulting 722 sequence of bytes shown in hexadecimal and in the order in which they 723 are transmitted (network byte order). The first and last values in 724 each contiguous range are shown, with ellipses in between: 726 Decimal Hex 728 -16384 C0 00 00 729 : : 730 -129 C0 3F 7F 731 -128 80 00 732 : : 733 -1 80 7F 734 0 00 735 : : 736 127 7F 737 128 80 80 738 : : 739 16383 BF FF 740 16384 C0 40 00 741 : : 742 4194303 FF FF FF 744 For positive values, a change of zero through 127 is represented 745 directly in one byte. If the most significant two bits of the byte 746 are 10 or 11, this signals an extension to a two- or three-byte 747 value, respectively. The least significant six bits of the first 748 byte are combined, in decreasing order of significance, with the next 749 one or two bytes to form a 14- or 22-bit value. 751 Negative deltas may occur when packets are misordered or in the 752 intentionally out-of-order RTP timestamps on MPEG video [5]. These 753 events are less likely, so a smaller range of negative values is 754 encoded using otherwise redundant portions of the positive part of 755 the table. 757 A change in the RTP timestamp value less than -16384 or greater than 758 4194303 forces the RTP header to be sent uncompressed using a 759 FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The 760 IP ID and RTP sequence number fields are only 16 bits, so negative 761 deltas for those fields SHOULD be masked to 16 bits and then encoded 762 (as large positive 16-bit numbers). 764 3.3.5. Error Recovery 766 Whenever the 4-bit sequence number for a particular context 767 increments by other than 1, except when set by a FULL_HEADER or 768 COMPRESSED_NON_TCP packet, the decompressor MUST invalidate that 769 context and send a CONTEXT_STATE packet back to the compressor 770 indicating that the context has been invalidated. All packets for 771 the invalid context MUST be discarded until a FULL_HEADER or 772 COMPRESSED_NON_TCP packet is received for that context to re- 773 establish consistent state (unless the "twice" algorithm is used as 774 described later in this section). Since multiple compressed packets 775 may arrive in the interim, the decompressor SHOULD NOT retransmit the 776 CONTEXT_STATE packet for every compressed packet received, but 777 instead SHOULD limit the rate of retransmission to avoid flooding the 778 reverse channel. 780 When an error occurs on the link, the link layer will usually discard 781 the packet that was damaged (if any), but may provide an indication 782 of the error. Some time may elapse before another packet is 783 delivered for the same context, and then that packet would have to be 784 discarded by the decompressor when it is observed to be out of 785 sequence, resulting in at least two packets lost. To allow faster 786 recovery if the link does provide an explicit error indication, the 787 decompressor MAY optionally send an advisory CONTEXT_STATE packet 788 listing the last valid sequence number and generation number for one 789 or more recently active contexts (not necessarily all). For a given 790 context, if the compressor has sent no compressed packet with a 791 higher sequence number, and if the generation number matches the 792 current generation, no corrective action is required. Otherwise, the 793 compressor MAY choose to mark the context invalid so that the next 794 packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode (FULL_HEADER 795 is required if the generation doesn't match). However, note that if 796 the link round-trip-time is large compared to the inter-packet 797 spacing, there may be several packets from multiple contexts in 798 flight across the link, increasing the probability that the sequence 799 numbers will already have advanced when the CONTEXT_STATE packet is 800 received by the compressor. The result could be that some contexts 801 are invalidated unnecessarily, causing extra bandwidth to be 802 consumed. 804 The format of the CONTEXT_STATE packet is shown in the following 805 diagrams. The first byte is a type code to allow the CONTEXT_STATE 806 packet type to be shared by multiple compression schemes within the 807 general compression framework specified in [3]. The contents of the 808 remainder of the packet depends upon the compression scheme. For the 809 IP/UDP/RTP compression scheme specified here, the remainder of the 810 CONTEXT_STATE packet is structured as a list of blocks to allow the 811 state for multiple contexts to be indicated, preceded by a one-byte 812 count of the number of blocks. 814 Two type code values are used for the IP/UDP/RTP compression scheme. 815 The value 1 indicates that 8-bit session context IDs are being used: 817 0 1 2 3 4 5 6 7 818 +---+---+---+---+---+---+---+---+ 819 | 1 = IP/UDP/RTP with 8-bit CID | 820 +---+---+---+---+---+---+---+---+ 821 | context count | 822 +---+---+---+---+---+---+---+---+ 823 +---+---+---+---+---+---+---+---+ 824 | session context ID | 825 +---+---+---+---+---+---+---+---+ 826 | I | 0 | 0 | 0 | sequence | 827 +---+---+---+---+---+---+---+---+ 828 | 0 | 0 | generation | 829 +---+---+---+---+---+---+---+---+ 830 ... 831 +---+---+---+---+---+---+---+---+ 832 | session context ID | 833 +---+---+---+---+---+---+---+---+ 834 | I | 0 | 0 | 0 | sequence | 835 +---+---+---+---+---+---+---+---+ 836 | 0 | 0 | generation | 837 +---+---+---+---+---+---+---+---+ 839 The value 2 indicates that 16-bit session context IDs are being used. 840 The session context ID is sent in network byte order (most 841 significant byte first): 843 0 1 2 3 4 5 6 7 844 +---+---+---+---+---+---+---+---+ 845 | 2 = IP/UDP/RTP with 16-bit CID| 846 +---+---+---+---+---+---+---+---+ 847 | context count | 848 +---+---+---+---+---+---+---+---+ 849 +---+---+---+---+---+---+---+---+ 850 | | 851 + session context ID + 852 | | 853 +---+---+---+---+---+---+---+---+ 854 | I | 0 | 0 | 0 | sequence | 855 +---+---+---+---+---+---+---+---+ 856 | 0 | 0 | generation | 857 +---+---+---+---+---+---+---+---+ 858 ... 859 +---+---+---+---+---+---+---+---+ 860 | | 861 + session context ID + 862 | | 863 +---+---+---+---+---+---+---+---+ 864 | I | 0 | 0 | 0 | sequence | 865 +---+---+---+---+---+---+---+---+ 866 | 0 | 0 | generation | 867 +---+---+---+---+---+---+---+---+ 869 The bit labeled "I" is set to one for contexts that have been marked 870 invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be 871 transmitted. If the I bit is zero, the context state is advisory. 872 The I bit is set to zero to indicate advisory context state that MAY 873 be sent following a link error indication. 875 Since the CONTEXT_STATE packet itself may be lost, retransmission of 876 one or more blocks is allowed. It is expected that retransmission 877 will be triggered only by receipt of another packet, but if the line 878 is near idle, retransmission MAY be triggered by a relatively long 879 timer (on the order of 1 second). 881 If a CONTEXT_STATE block for a given context is retransmitted, it may 882 cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet 883 intended to refresh that context. In that case, the compressor MAY 884 choose to ignore the error indication. 886 In the case where UDP checksums are being transmitted, the 887 decompressor MAY attempt to use the "twice" algorithm described in 888 section 10.1 of [3]. In this algorithm, the delta is applied more 889 than once on the assumption that the delta may have been the same on 890 the missing packet(s) and the one subsequently received. Success is 891 indicated by a checksum match. For the scheme defined here, the 892 difference in the 4- bit sequence number tells number of times the 893 delta must be applied. Note, however, that there is a nontrivial 894 risk of an incorrect positive indication. It may be advisable to 895 request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the 896 "twice" algorithm succeeds. 898 Some errors may not be detected, for example if 16 packets are lost 899 in a row and the link level does not provide an error indication. In 900 that case, the decompressor will generate packets that are not valid. 901 If UDP checksums are being transmitted, the receiver will probably 902 detect the invalid packets and discard them, but the receiver does 903 not have any means to signal the decompressor. Therefore, it is 904 RECOMMENDED that the decompressor verify the UDP checksum 905 periodically, perhaps one out of 16 packets. If an error is 906 detected, the decompressor would invalidate the context and signal 907 the compressor with a CONTEXT_STATE packet. 909 3.4. Compression of RTCP Control Packets 911 By relying on the RTP convention that data is carried on an even port 912 number and the corresponding RTCP packets are carried on the next 913 higher (odd) port number, one could tailor separate compression 914 schemes to be applied to RTP and RTCP packets. For RTCP, the 915 compression could apply not only to the header but also the "data", 916 that is, the contents of the different packet types. The numbers in 917 Sender Report (SR) and Receiver Report (RR) RTCP packets would not 918 compress well, but the text information in the Source Description 919 (SDES) packets could be compressed down to a bit mask indicating each 920 item that was present but compressed out (for timing purposes on the 921 SDES NOTE item and to allow the end system to measure the average 922 RTCP packet size for the interval calculation). 924 However, in the compression scheme defined here, no compression will 925 be done on the RTCP headers and "data" for several reasons (though 926 compression SHOULD still be applied to the IP and UDP headers). 927 Since the RTP protocol specification suggests that the RTCP packet 928 interval be scaled so that the aggregate RTCP bandwidth used by all 929 participants in a session will be no more than 5% of the session 930 bandwidth, there is not much to be gained from RTCP compression. 931 Compressing out the SDES items would require a significant increase 932 in the shared state that must be stored for each context ID. And, in 933 order to allow compression when SDES information for several sources 934 was sent through an RTP "mixer", it would be necessary to maintain a 935 separate RTCP session context for each SSRC identifier. In a session 936 with more than 255 participants, this would cause perfect thrashing 937 of the context cache even when only one participant was sending data. 939 Even though RTCP is not compressed, the fraction of the total 940 bandwidth occupied by RTCP packets on the compressed link remains no 941 more than 5% in most cases, assuming that the RTCP packets are sent 942 as COMPRESSED_UDP packets. Given that the uncompressed RTCP traffic 943 consumes no more than 5% of the total session bandwidth, then for a 944 typical RTCP packet length of 90 bytes, the portion of the compressed 945 bandwidth used by RTCP will be no more than 5% if the size of the 946 payload in RTP data packets is at least 108 bytes. If the size of 947 the RTP data payload is smaller, the fraction will increase, but is 948 still less than 7% for a payload size of 37 bytes. For large data 949 payloads, the compressed RTCP fraction is less than the uncompressed 950 RTCP fraction (for example, 4% at 1000 bytes). 952 3.5. Compression of non-RTP UDP Packets 954 As described earlier, the COMPRESSED_UDP packet MAY be used to 955 compress UDP packets that don't carry RTP. Whatever data follows the 956 UDP header is unlikely to have some constant values in the bits that 957 correspond to usually constant fields in the RTP header. In 958 particular, the SSRC field would likely change. Therefore, it is 959 necessary to keep track of the non-RTP UDP packet streams to avoid 960 using up all the context slots as the "SSRC field" changes (since 961 that field is part of what identifies a particular RTP context). 962 Those streams may each be given a context, but the encoder would set 963 a flag in the context to indicate that the changing SSRC field should 964 be ignored and COMPRESSED_UDP packets should always be sent instead 965 of COMPRESSED_RTP packets. 967 4. Enhancements for links with high bit error rate and long round trip delay 969 4.1 The negative cache stream flag 971 Certain streams, known or suspected to not be RTP, can be placed in a "negative 972 cache" at the compressor, so only the IP and UDP headers are compressed. It is 973 beneficial to notify the decompressor that the compressed stream is in the 974 negative cache: for such streams the context is shorter - there is no need to 975 include the RTP header, and all RTP-related calculations can be avoided. 977 In this enhancement, a new flag bit "N" is added to the FULL_HEADER packet that 978 initializes a context at the decompressor. The bit occupied by the new flag was 979 previously always set to zero. If the N flag is set to 1, this indicates that 980 no COMPRESSED_RTP packets will be transmitted in this context. This flag is 981 only an optimization and the decompressor may choose to ignore it. 983 Format of the FULL_HEADER length fields with the negative cache flag: 985 For 8-bit context ID: 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |0|1| Generation| CID | First length field 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | 0 |N| seq | Second length field 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream 995 For 16-bit context ID: 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 |1|1| Generation| 0 |N| seq | First length field 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | CID | Second length field 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 4.2 Reject a new compressed stream 1007 In a point to point link the two nodes can agree on the number of compressed 1008 sessions they are prepared to support for this link. In an end-to-end scheme a 1009 host may have compressed sessions with many hosts and eventually may run out of 1010 resources. When the end-to-end tunnel is negotiated, the number of contexts 1011 needed may not be predictable. This enhancement allows the negotiated number of 1012 contexts to be larger than could be accommodated if many tunnels are 1013 established. Then, as context resources are consumed, an attempt to set up a 1014 new context may be rejected. 1015 The compressor initiates a compression of a stream by sending a FULL_HEADER 1016 packet. Currently if the decompressor has insufficient resources to decompress 1017 the new stream, it can send a CONTEXT_STATE packet to invalidate the newly 1018 compressed stream. The compressor does not know the reason for the invalidation: 1019 usually this happens when the decompressor gets out of synchronization due to 1020 packet loss. The compressor will most likely reattempt to compress this stream 1021 by sending another FULL_HEADER. 1022 This enhancement specifies that the decompressor may reject the compression of a 1023 stream by sending a REJECT message to the compressor. A REJECT message tells the 1024 compressor to stop compressing this stream. 1025 The REJECT message is a CONTEXT_STATE message with an additional flag: 1027 Type code = 1 :CONTEXT_STATE for 8-bit CID streams 1028 Type code = 2 : CONTEXT_STATE for16-bit CID streams 1030 Here is the format of CONTEXT_STATE packets with REJECT flags: 1032 0 1 2 3 4 5 6 7 1033 +---+---+---+---+---+---+---+---+ 1034 |Type code=1: CS, 8-bit CID | 1035 +---+---+---+---+---+---+---+---+ 1036 | context count | 1037 +---+---+---+---+---+---+---+---+ 1038 | session context ID | 1039 +---+---+---+---+---+---+---+---+ 1040 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 1041 +---+---+---+---+---+---+---+---+ 1042 | 0 | 0 | generation | 1043 +---+---+---+---+---+---+---+---+ 1044 . . . 1045 +---+---+---+---+---+---+---+---+ 1046 | session context ID | 1047 +---+---+---+---+---+---+---+---+ 1048 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 1049 +---+---+---+---+---+---+---+---+ 1050 | 0 | 0 | generation | 1051 +---+---+---+---+---+---+---+---+ 1053 0 1 2 3 4 5 6 7 1054 +---+---+---+---+---+---+---+---+ 1055 |Type code=2: CS, 16-bit CID| 1056 +---+---+---+---+---+---+---+---+ 1057 | context count | 1058 +---+---+---+---+---+---+---+---+ 1059 | | 1060 + session context ID + 1061 | | 1062 +---+---+---+---+---+---+---+---+ 1063 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 1064 +---+---+---+---+---+---+---+---+ 1065 | 0 | 0 | generation | 1066 +---+---+---+---+---+---+---+---+ 1067 . . . 1068 +---+---+---+---+---+---+---+---+ 1069 | | 1070 + session context ID + 1071 | | 1072 +---+---+---+---+---+---+---+---+ 1073 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 1074 +---+---+---+---+---+---+---+---+ 1075 | 0 | 0 | generation | 1076 +---+---+---+---+---+---+---+---+ 1078 The session CID, sequence and generation are taken from the FULL_HEADER. 1080 The compressor may decide to wait for a while before attempting to compress 1081 additional streams destined to the rejecting host. 1083 4.3 Including IP ID in the UDP checksum 1085 A UDP checksum can be used by the decompressor to verify validity of the packet 1086 it reconstructed, especially when the 'twice' algorithm is used. When the 1087 'twice' algorithm was defined in RFC 2507 and subsequently incorporated into RFC 1088 2508, the fact that the IP ID field is not included in the checksum was 1089 overlooked. Since the IP ID field is conveyed with a delta value, accurate 1090 reconstruction of the IP ID field cannot be verified using the current 1091 specifications. 1093 This enhancement modifies the function of the UDP checksum to include the IP ID 1094 value, but only between the compressor and decompressor. That is, when a UDP 1095 checksum is present (nonzero), the compressor will 1's complement subtract the 1096 IP ID value from the UDP checksum before compression and the decompressor will 1097 1's complement add the IP ID value to the UDP checksum after any validation 1098 operations and before delivering the packet further downstream. 1100 4.4 CRTP Headers Checksum 1102 When a UDP checksum is not present (has value zero) in a stream, the compressor 1103 MAY replace it with a 16-bit headers checksum (HDRCKSUM). The HDRCKSUM can be 1104 used to validate the IP ID and all the headers in the reconstructed packet. 1105 Hence it can be used by the decompressor to validate reconstructed packets when 1106 'twice' is used, and to validate every 16'th packet as recommended in RFC2508, 1107 Section 3.3.5. 1109 A new flag in the FULL_HEADER packet, as specified below, indicates when set 1110 that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will 1111 have HDRCKSUM inserted. If a packet in the same stream subsequently arrives at 1112 the compressor with a UDP checksum present, then a new FULL_HEADER packet must 1113 be sent with the flag cleared to re-establish the context. 1115 The HDRCKSUM is calculated in the same way as a UDP checksum, but includes only 1116 the pseudo-IP header (as defined for UDP), the IP ID (as in Section 2.3), the 1117 UDP header and for COMPRESSED_RTP packets, the fixed part of the RTP header 1118 (first 12 bytes). The extended part of the RTP header and the RTP data will not 1119 be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or 1120 COMPRESSED_RTP packets where a UDP checksum would have been. 1121 The decompressor MUST zero out the UDP checksum field in the reconstructed 1122 packets. 1124 The HDRCKSUM does not validate the RTP data. If the link layer is configured to 1125 deliver packets without checking for errors, errors in the RTP data will not be 1126 detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP 1127 checksum is not present, and the decompressor SHOULD validate each reconstructed 1128 packet to make sure that at least the headers are correct. This ensures that the 1129 packet will be delivered to the right destination. If only HDRCKSUM is 1130 available, the RTP data will be delivered even if it includes errors. 1131 This might be a desirable feature for applications that can tolerate errors in 1132 the RTP data. Same holds for the extended part of the RTP header. 1134 Here is the format of the FULL_HEADER length fields with the new flag that 1135 indicates that a header checksum will be added in COMPRESSED_UDP and 1136 COMPRESSED_RTP packets: 1138 For 8-bit context ID: 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 |0|1| Generation| CID | First length field 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | 0 |C|N| seq | Second length field 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 1148 For 16-bit context ID: 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 |1|1| Generation| 0 |C|N| seq | First length field 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | CID | Second length field 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 4.5 Enhancement to COMPRESSED_UDP packet format (CU*) 1160 The COMPRESSED_UDP packet includes the whole RTP header, so it can restore all 1161 RTP-related parameters at the decompressor. It is also specified to reset the 1162 delta RTP timestamp to zero and the delta RTP sequence number to zero.It can 1163 also convey a new value for the delta IP ID. 1165 It is possible to accommodate some packet loss between the compressor and 1166 decompressor using the "twice" algorithm in RFC 2508, but this requires reliably 1167 communicating the absolute values and the deltas for the differential fields. 1168 The reliability of communication of the absolute values in the RTP header can be 1169 increased by sending a COMPRESSED_UDP packet repeatedly, but this resets the 1170 delta timestamp. 1171 RFC 2508 describes the format of COMPRESSED_UDP as being the same as 1172 COMPRESSED_RTP except that the M, S and T bits are always 0 and the 1173 corresponding delta fields are never included. This enhancement changes that 1174 specification to say that the T bit may be nonzero to indicate that the RTP 1175 timestamp delta is included explicitly rather than being reset to zero. 1177 Sometimes it is necessary to change just a few fields of the RTP header. A 1178 second part of this enhancement adds more flag bits to the COMPRESSED_UDP packet 1179 to select individual uncompressed fields of the RTP header to be included in the 1180 packet. Since there are flag bits to indicate inclusion of both delta values 1181 and absolute values, the flag nomenclature is changed. The original S,T,I bits 1182 which indicate the inclusion of deltas are renamed dS, dT, dI, and the inclusion 1183 of absolute values is indicated by S,T,I. The M bit is absolute as before. 1185 The format of the flags/sequence byte for the original COMPRESSED_UDP packet is 1186 shown here for reference: 1188 +---+---+---+---+---+---+---+---+ 1189 | 0 | 0 | 0 |dI | link sequence | 1190 +---+---+---+---+---+---+---+---+ 1192 The new definition of the flags/sequence byte plus an extension flags byte is as 1193 follows, where the new F flag indicates the inclusion of the extension flags 1194 byte: 1196 +---+---+---+---+---+---+---+---+ 1197 | F | I |dT |dI | link sequence | 1198 +---+---+---+---+---+---+---+---+ 1199 : M : S : T :pt : CC : (if F = 1) 1200 +...+...+...+...+...............+ 1202 dI = delta IP ID 1203 dT = delta RTP timestamp 1204 I = absolute IP ID 1205 F = additional flags byte 1206 M = marker bit 1207 S = absolute RTP sequence number 1208 T = absolute RTP timestamp 1209 pt = RTP payload type 1210 CC = number of CSRC identifiers 1212 Some short notations: 1214 FH FULL_HEADER 1215 CR COMPRESSED_RTP 1216 CR+ COMPRESSED_RTP with delta fields 1217 CU COMPRESSED_UDP 1218 CU* enhanced COMPRESSED_UDP 1220 When F=0, there is only one flags byte, and the only available flags are: dI, dT 1221 and I. 1222 In this case the packet includes the full RTP header 1223 If dT=0, the decompressor sets deltaT to 0 1224 If dI=0, the decompressor sets deltaI to 1 1226 Some example packet formats will illustrate the use of the new flags. First, a 1227 'traditional' COMPRESSED_UDP with full RTP header, when F=0: 1229 0 1 2 3 4 5 6 7 1230 +...............................+ 1231 : msb of session context ID : (if 16-bit CID) 1232 +-------------------------------+ 1233 | lsb of session context ID | 1234 +---+---+---+---+---+---+---+---+ 1235 |F=0| I |dT |dI | link sequence | 1236 +---+---+---+---+---+---+---+---+ 1237 : : 1238 + UDP checksum + (if nonzero in context) 1239 : : 1240 +...............................+ 1241 : : 1242 + "RANDOM" fields + (if encapsulated) 1243 : : 1244 +...............................+ 1245 : delta IPv4 ID : (if dI = 1) 1246 +...............................+ 1247 : delta RTP timestamp : (if dT = 1) 1248 +...............................+ 1249 : : 1250 + IPv4 ID + (if I = 1) 1251 : : 1252 +...............................+ 1253 | UDP data | 1254 : (uncompressed RTP header) : 1256 When F=1, there is an additional flags byte and the available flags are: dI, dT, 1257 I, M, S, T, pt, CC. In this case the packet does not include the full RTP 1258 header, but includes selected fields from the RTP header as specified by the 1259 flags. The delta values of the context are not reset even if they are not 1260 specified in the packet: 1261 If dT=0, the decompressor KEEPS THE CURRENT deltaT 1262 (and DOES NOT set the deltaT to 0) 1263 If dI=0, the decompressor KEEPS THE CURRENT deltaI 1264 (and DOES NOT set the the deltaI to 1) 1266 A CU* packet is similar in contents and behavior to a CR packet, but it has more 1267 flag bits, some of which correspond to absolute values for RTP header fields. 1269 COMPRESSED_UDP with individual RTP fields, when F=1 : 1271 0 1 2 3 4 5 6 7 1272 +...............................+ 1273 : msb of session context ID : (if 16-bit CID) 1274 +-------------------------------+ 1275 | lsb of session context ID | 1276 +---+---+---+---+---+---+---+---+ 1277 |F=1| I |dT |dI | link sequence | 1278 +---+---+---+---+---+---+---+---+ 1279 : M : S : T :pt : CC : 1280 +...+...+...+...+...............+ 1281 : : 1282 + UDP checksum + (if nonzero in context) 1283 : : 1284 +...............................+ 1285 : : 1286 : "RANDOM" fields : (if encapsulated) 1287 : : 1288 +...............................+ 1289 : delta IPv4 ID : (if dI = 1) 1290 +...............................+ 1291 : delta RTP timestamp : (if dT = 1) 1292 +...............................+ 1293 : : 1294 + IPv4 ID + (if I = 1) 1295 : : 1296 +...............................+ 1297 : : 1298 + RTP sequence number + (if S = 1) 1299 : : 1300 +...............................+ 1301 : : 1302 + + 1303 : : 1304 + RTP timestamp + (if T = 1) 1305 : : 1306 + + 1307 : : 1308 +...............................+ 1309 : RTP payload type : (if pt = 1) 1310 +...............................+ 1311 : : 1312 : CSRC list : (if CC > 0) 1313 : : 1314 +...............................+ 1315 : : 1316 : RTP header extension : (if X set in context) 1317 : : 1318 +-------------------------------+ 1319 | | 1320 / RTP data / 1321 / / 1322 | | 1323 +-------------------------------+ 1324 : padding : (if P set in context) 1325 +...............................+ 1327 Usage for the CU* packet: 1329 It is useful for the compressor to periodically refresh the state of the 1330 decompressor to avoid having the decompressor send CONTEXT_STATE messages in the 1331 case of unrecoverable packet loss. 1332 Using the flags F=0 I dI dT, this CU* packet refreshes all the context 1333 parameters. 1335 When compression is done over a lossy link with a long round trip delay, we want 1336 to minimize context invalidation. If the delta values are changing frequently, 1337 the context might get invalidated often. In such cases the compressor may choose 1338 to include absolute values in the CRTP packets instead of delta values, using 1339 CU* packets with the flags: F=1, and any of S, T, I as necessary. 1341 4.6 Acknowledgement packet (ACK packet) 1343 The ACK packet will be sent from decompressor to compressor to indicate receipt 1344 of a compressed packet with the ACK'd RTP sequence number. 1345 It's a CONTEXT_STATE packet with type codes 4 and 5. The ACK packet is to be 1346 used in a separately negotiated mode of operation as described in the next 1347 section. 1349 Type code = 4 : ACK a packet of a context with 8-bit CID 1350 Type code = 5 : ACK a packet of a context with 16-bit CID 1352 The format for the ACK packet is: 1354 0 1 2 3 4 5 6 7 1355 +---+---+---+---+---+---+---+---+ 1356 | Type code=4: ACK, 8-bit CID | 1357 +---+---+---+---+---+---+---+---+ 1358 | context count | 1359 +---+---+---+---+---+---+---+---+ 1360 | session context ID | 1361 +---+---+---+---+---+---+---+---+ 1363 | | 1364 + RTP sequence number + 1365 | | 1366 +---+---+---+---+---+---+---+---+ 1367 . . . 1368 +---+---+---+---+---+---+---+---+ 1369 | session context ID | 1370 +---+---+---+---+---+---+---+---+ 1372 | | 1373 + RTP sequence number + 1374 | | 1375 +---+---+---+---+---+---+---+---+ 1377 0 1 2 3 4 5 6 7 1378 +---+---+---+---+---+---+---+---+ 1379 | Type code=5: ACK, 16-bit CID | 1380 +---+---+---+---+---+---+---+---+ 1381 | context count | 1382 +---+---+---+---+---+---+---+---+ 1383 | | 1384 + session context ID + 1385 | | 1386 +---+---+---+---+---+---+---+---+ 1388 | | 1389 + RTP sequence number + 1390 | | 1391 +---+---+---+---+---+---+---+---+ 1392 . . . 1393 +---+---+---+---+---+---+---+---+ 1394 | | 1395 + session context ID + 1396 | | 1397 +---+---+---+---+---+---+---+---+ 1399 | | 1400 + RTP sequence number + 1401 | | 1402 +---+---+---+---+---+---+---+---+ 1404 4.6.1 CRTP operation in ACK mode 1406 This mode of operation is optional and must be negotiated per link. 1408 4.6.1.1 Description of the ACK mode 1410 The ACK mode is a mode of operation in which the compressor and decompressor 1411 continuously verify that their context states are synchronized. The compressor 1412 repeatedly notifies the decompressor about changes in the context state, until 1413 the decompressor acknowledges reception of the changes by sending ACK packets to 1414 the decompressor. 1415 This effort of synchronizing the context states helps minimize context 1416 invalidation. 1418 The context state shared between the compressor and decompressor includes all 1419 the fields of the uncompressed headers and the first order differences (delta 1420 fields) of the fields that change by a constant value from packet to packet. 1421 Each field follows its known change pattern: either stays constant or is 1422 incremented by its corresponding delta field. Fields that follow their change 1423 pattern are compressed. They are reconstructed by the decompresor from the 1424 context state at the decompressor. Correct decompression of a packet depends on 1425 whether the context state at the compressor when the packet is compressed and 1426 sent is identical to the context state at the decompressor when that packet is 1427 received and decompressed. 1429 When a field changes in a way that is different from its change pattern, the 1430 compressor assigns a new value to the field, and stores it in the context state 1431 at the compressor side. The decompressor must be informed about the change so 1432 that it can update the state on its side to match the state at the compressor. 1433 The compressor notifies the decompressor about such changes by including 1434 information about the changed field in the compressed packet. (for example if dT 1435 was assigned a new value, the compressor can send a CR+ packet that includes 1436 dT). The context is not synchronized until the decompressor receives the packet 1437 that includes the changed field and updates its state accordingly. 1439 The decompressor indicates reception of the change by sending an ACK packet to 1440 the compressor. The ACK packet includes the RTP sequence number of the packet 1441 that it is ACK'ing, so the compressor can identify which packet is ACK'd. The 1442 compressor can't assume that the decompressor received the change until the ACK 1443 packet is received. 1445 Depending on the round trip delay of the link, the compressor might have to send 1446 a few more packets before the ACK from the decompressor arrives. In this case 1447 the compressor must repeat the change in all subsequent packets. Reception of 1448 the ACK is an indication that the decompressor updated its context with the 1449 changed value. Now that their contexts are synchronized again, the compressor 1450 can stop including the changed field in the compressed packets. 1452 The decompressor must be able to recognize the repeat packets (the packets that 1453 repeat the same change and were sent while the compressor was waiting for the 1454 ACK packet). Those repeat packets don't require an ACK. 1456 If in the process of changing some fields additional changes are required, the 1457 compressor will switch to send packets that include all changes. The 1458 decompressor must ACK one of the packets that include all the changes. 1460 The compressor and decompressor must be in full agreement about which packets 1461 must be ACK'd: packets that include changes are larger in size, and if they are 1462 not ACK'd, the changes are repeated in all subsequent packets, and bandwidth is 1463 wasted. 1465 Let's summarize which packets require an ACK: 1467 1. A Packet that assigns a value to any context state field must be ACK'd. This 1468 includes FH and CU packets because they initialize fields in the context 1469 state. 1470 2. Repeat packets don't require an ACK 1472 How are repeat packets identified? 1474 A packet is considered to be a repeat packet if: 1475 1. It updates the same fields as the previous packet 1476 2. Each field is updated by a value that is equal to the one assigned to this 1477 field in the previous packet plus the corresponding delta for this field, 1478 when applicable. 1480 4.6.1.2 The Random IP ID 1482 The IP ID change pattern is to be incremented by dI. In some implementations, 1483 the IP ID counter is shared across multiple streams, so as a result of the 1484 varying mix of packets the increment for any particular stream is not constant. 1485 When compressing such a stream, the compressor must include in each packet 1486 either dI or I. It is recommended to include I rather then dI because a loss of 1487 a packet that includes a new delta value dI will invalidate the context. 1488 According to the rules set above, each packet will have to be ACK'd. 1490 To correct this we'll define a new change pattern for the IP ID: random value. 1491 The IP ID assumes this change pattern when dI is set to be 0. 1493 We add a rule to the ACK rules: 1494 3. When the value of dI is 0, packets that update only the IP ID field don't 1495 require an ACK. 1497 And add to rule 2 of the repeat packet rules: 1498 2. Each field is updated by a value that is equal to the one assigned to this 1499 field in the previous packet plus the corresponding delta for this field, when 1500 applicable. An exception to this rule is the IP ID field: if the value of dI is 1501 0, the IP ID may be assigned any value. 1503 4.6.1.3 Implementation hints when using the ACK scheme 1505 1. When a delta field is updated, add the matching absolute field too (dT and T, 1506 dI and I). Loss of a packet that updates only the delta value can easily 1507 cause context invalidation. 1508 2. Set dI=0 when the IP ID is changing randomly, and include I in all packets. 1509 3. If you ACK'd a packet, but the number of repeat packets exceed your estimate, 1510 ACK again (your previous ACK was probably lost) 1512 Here is an example to demonstrate the usage of the ACK scheme. 1513 In this stream the audio codec sends a sample every 10 msec 1514 The first talk spurt is 1 second long. Then there are 2 seconds silence, then 1515 another talk spurt. 1517 When there is no loss on the link, we can use the following sequence: 1518 (The deltaID is not constant so we send deltaID in each packet) 1520 seq# Time pkt type 1521 1 10 FH 1522 2 20 CR+ dI dT=10 1523 3 30 CR+ dI 1524 4 40 CR+ dI 1525 ... 1526 100 1000 CR+ dI 1528 101 3010 CR+ dI dT=2010 1529 102 3020 CR+ dI dT=10 1530 103 3030 CR+ dI 1531 104 3040 CR+ dI 1532 ... 1533 In the above sequence if a packet is lost, we cannot recover ('twice' will not 1534 work due to the random IP ID) and the context must be invalidated. 1536 Here is the same sequence using the ACK scheme(CU* is the enhanced CU): 1538 seq# Time pkt type flags 1539 1 10 FH FH must be ACK'd 1540 2 20 FH repeat 1541 ACK 1 1542 3 30 CU* 1 I dT dI M 0 T 0 I T=30 dT=10 dI=0 dI,dT changed 1543 (packet 3 was lost) (I and T sent too) 1544 4 40 CU* 1 I dT dI M 0 T 0 I T=40 dT=10 dI=0 repeat 1545 5 50 CU* 1 I dT dI M 0 T 0 I T=50 dT=10 dI=0 repeat 1546 6 60 CU* 1 I dT dI M 0 T 0 I T=60 dT=10 dI=0 repeat 1547 ACK 4 == got new dI=0 and dT=10 at T=40. 1548 dI was set to 0, so I does not require an ACK. 1549 No need to ACK 5 and 6: repeat packets 1550 7 70 CU* 1 I 0 0 M 0 0 0 I 1551 8 80 CU* 1 I 0 0 M 0 0 0 I 1552 ... 1553 100 1000 CU* 1 I 0 0 M 0 0 0 I 1555 101 3010 CU* 1 I 0 0 M 0 T 0 I T=3010 T changed, keep deltas! 1556 102 3020 CU* 1 I 0 0 M 0 T 0 I T=3020 repeat 1557 ACK 101 == got new T at sequence 101 1558 No need to ACK packet 102 because 3010 + dT = 3020 1559 If 101 is lost, 102 will be ACK'd 1560 103 3030 CU* 1 I 0 0 M 0 0 0 I 1561 104 3040 CU* 1 I 0 0 M 0 0 0 I 1562 ... 1564 The same sequences, when delta IP ID is constant: 1566 seq# Time pkt type 1567 1 10 FH 1568 2 20 CR+ dI dT=10 1569 3 30 CR 1570 4 40 CR 1571 ... 1572 100 1000 CR 1574 101 3010 CR+ dT=2010 1575 102 3020 CR+ dT=10 1576 103 3030 CR 1577 104 3040 CR 1578 ... 1580 seq# Time pkt type flags 1581 1 10 FH FH must be ACK'd 1582 2 20 FH repeat 1583 ACK 1 1584 3 30 CU* 1 I dT dI M 0 T 0 I dI T=30 dT=10 dI,dT changed 1585 (packet 3 was lost) (I and T sent too) 1586 4 40 CU* 1 I dT dI M 0 T 0 I dI T=40 dT=10 repeat 1587 5 50 CU* 1 I dT dI M 0 T 0 I dI T=50 dT=10 repeat 1588 6 60 CU* 1 I dT dI M 0 T 0 I dI T=60 dT=10 repeat 1589 ACK 4 == got new dI and dT=10 at T=40. 1590 No need to ACK 5 and 6: no changes 1591 7 70 CR 1592 8 80 CR 1593 ... 1594 100 1000 CR 1596 101 3010 CU* 1 0 0 0 M 0 T 0 T=3010 T changed, keep deltas! 1597 102 3020 CU* 1 0 0 0 M 0 T 0 T=3020 repeat 1598 ACK 101 == got new T at sequence 101 1599 No need to ACK packet 102 because 3010 + dT = 3020 1600 If 101 is lost, 102 will be ACK'd 1601 103 3030 CR 1602 104 3040 CR 1603 ... 1605 4.7 Accept a new compressed stream 1607 Lack of any feedback from the decompressor might indicate either that everything 1608 goes well (the stream is decompressed successfully), or that nothing goes well 1609 (the link is down, the decompressor is not functioning, the decompressor is out 1610 of sync but there is no back channel). The compressor initiates a compression of 1611 a stream by sending a FULL_HEADER packet. This enhancement specifies that the 1612 decompressor SHOULD acknowledge the reception of the FULL_HEADER packet by 1613 sending an ACK packet (see 2.6) with the sequence number of the FULL_HEADER 1614 packet. This reassures the compressor that the new compressed stream is received 1615 and decompressed. It also indicates that a back channel exists. 1617 4.8 CRTP operation in 'N' mode 1619 This scheme is similar to the ACK scheme in that the compressor tries to keep 1620 the decompressor in sync by sending changes multiple times. The 'N' is a number 1621 that represents the quality of the link between the hosts, and it means that the 1622 probability of more than 'N' adjacent packets getting lost on this link is 1623 small. For every change in a base value or a delta value, if the compressor 1624 includes the change in N+1 consecutive packets, there is a very good chance that 1625 the compressor and decompressor can stay in sync using the 'twice' algorithm. 1626 CONTEXT_STATE packets should also be repeated N+1 times (using the same sequence 1627 number). 1628 It is up to the implementation to find a scheme to derive an appropriate N for a 1629 link. 1631 This scheme may be used at any time and does not require negotiation. 1633 Here is the same example in 'N' mode, when N=2 and deltaID is constant: 1635 seq# Time pkt type flags 1636 1 10 FH 1637 2 20 FH repeat constant fields 1638 3 30 FH repeat constant fields 1639 4 40 CU* 1 I dT dI M 0 T 0 I dI T=40 dT=10 1640 5 50 CU* 1 I dT dI M 0 T 0 I dI T=50 dT=10 repeat delta 1641 6 60 CU* 1 I dT dI M 0 T 0 I dI T=60 dT=10 repeat delta 1642 7 70 CR 1643 8 80 CR 1644 ... 1645 100 1000 CR 1647 101 3010 CU* 1 0 0 0 M 0 T 0 T=3010 T changed, keep deltas! 1648 102 3020 CU* 1 0 0 0 M 0 T 0 T=3020 repeat updated T 1649 103 3030 CU* 1 0 0 0 M 0 T 0 T=3030 repeat updated T 1650 104 3040 CR 1651 105 3050 CR 1652 ... 1654 4.9 Select mode of operation 1656 As link conditions change, it might be necessary to change the mode of operation 1657 from N mode to ACK mode and vice versa. Mode changes are initiated by the 1658 compressor and acknowledged by the decompressor. When acknowledging a request to 1659 move to N mode, the decompressor may suggest a different N to use (for example 1660 based on loss patterns seen by the decompressor). 1661 The decompressor may send multiple acknowledgement packets to one request 1662 packet, e.g. send an ACK-Nmode packet when the decompressor suggests to change 1663 the N that is currently being used. 1664 The compressor determines the N to be used, and it MAY be different than the 1665 value of the parameter N in the REQ-Nmode and ACK-Nmode packets exchanged 1666 between the compressor and decompressor. 1667 If the compressor receives an ACK packet that does not match the current mode, 1668 the compressor SHOULD send another REQ packet to set the right mode. Hence the 1669 compressor can use any of the ACK packets to verify the current mode: if the ACK 1670 does not match the current mode, the compressor will send a REQ to set the mode. 1672 0 1 2 3 4 5 6 7 1673 +---+---+---+---+---+---+---+---+---+---+ 1674 | Type code=6: Select operation mode | 1675 +---+---+---+---+---+---+---+---+---+---+ 1676 | Opcode | 1677 +---+---+---+---+---+---+---+---+---+---+ 1678 : Parameter : 1679 +.......................................+ 1681 Opcode Mnemonic Description Parameter 1682 -------------------------------------------------------------------------------- 1683 1 REQ-Nmode Request to move to N mode N to be used 1684 2 ACK-Nmode Acknowledge move to N mode N to be used 1685 3 REQ-ACKmode Request to move to ACK mode none 1686 4 ACK-ACKmode Acknowledge move to ACK mode none 1688 4.10 Negotiating usage of enhanced-CRTP and ACK scheme 1690 RFC 2509 [IPCPHP] specifies how the use of CRTP is negotiated on PPP links using 1691 the IP Compression Protocol option of IPCP: 1693 IPCP option 2: IP compression protocol 1694 protocol 0x61 indicates RFC 2507 header compression 1695 sub-option 1 enables use of COMPRESSED_RTP, COMPRESSED_UDP and 1696 CONTEXT_STATE as specified in RFC 2508 1698 For the enhancements defined in this document, two new sub-options are added: 1700 sub-option 2 (length=2) : enables use of CRTP with 1701 enhancements 4.1 - 4.5 and 4.7 1702 (all except ACK mode) 1703 sub-option 3 (length=2) : enables use of CRTP with 1704 enhancements 4.1 - 4.7 (ACK scheme) 1706 5. Interaction With Segmentation 1708 A segmentation scheme may be used in conjunction with RTP header 1709 compression to allow small, real-time packets to interrupt large, 1710 presumably non-real-time packets in order to reduce delay. It is 1711 assumed that the large packets bypass the compressor and decompressor 1712 since the interleaving would modify the sequencing of packets at the 1713 decompressor and cause the appearance of errors. Header compression 1714 should be less important for large packets since the overhead ratio 1715 is smaller. 1717 If some packets from an RTP session context are selected for 1718 segmentation (perhaps based on size) and some are not, there is a 1719 possibility of re-ordering. This would reduce the compression 1720 efficiency because the large packets would appear as lost packets in 1721 the sequence space. However, this should not cause more serious 1722 problems because the RTP sequence numbers should be reconstructed 1723 correctly and will allow the application to correct the ordering. 1725 Link errors detected by the segmentation scheme using its own 1726 sequencing information MAY be indicated to the compressor with an 1727 advisory CONTEXT_STATE message just as for link errors detected by 1728 the link layer itself. 1730 The context ID byte is placed first in the COMPRESSED_RTP header so 1731 that this byte MAY be shared with the segmentation layer if such 1732 sharing is feasible and has been negotiated. Since the compressor 1733 may assign context ID values arbitrarily, the value can be set to 1734 match the context identifier from the segmentation layer. 1736 6. Negotiating Compression 1738 The use of IP/UDP/RTP compression over a particular link is a 1739 function of the link-layer protocol. It is expected that such 1740 negotiation will be defined separately for PPP [4], for example. The 1741 following items MAY be negotiated: 1743 o The size of the context ID. 1744 o The maximum size of the stack of headers in the context. 1745 o A context-specific table for decoding of delta values. 1746 o Using CRTP enhancements. 1748 7. Acknowledgments 1750 Several people have contributed to the design of this compression 1751 scheme and related problems. Scott Petrack initiated discussion of 1752 RTP header compression in the AVT working group at Los Angeles in 1753 March, 1996. Carsten Bormann has developed an overall architecture 1754 for compression in combination with traffic control across a low- 1755 speed link, and made several specific contributions to the scheme 1756 described here. David Oran independently developed a note based on 1757 similar ideas, and suggested the use of PPP Multilink protocol for 1758 segmentation. Mikael Degermark has contributed advice on integration 1759 of this compression scheme with the IPv6 compression framework. 1761 8. References: 1763 [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 1764 A Transport Protocol for real-time applications", RFC 1889, 1765 January 1996. 1767 [2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", 1768 RFC 1144, February 1990. 1770 [3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for 1771 IPv6", RFC 2507, February 1999. 1773 [4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1774 1661, July 1994. 1776 [5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP 1777 Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. 1779 9. Security Considerations 1781 Because encryption eliminates the redundancy that this compression 1782 scheme tries to exploit, there is some inducement to forego 1783 encryption in order to achieve operation over a low-bandwidth link. 1784 However, for those cases where encryption of data and not headers is 1785 satisfactory, RTP does specify an alternative encryption method in 1786 which only the RTP payload is encrypted and the headers are left in 1787 the clear. That would allow compression to still be applied. 1789 A malfunctioning or malicious compressor could cause the decompressor 1790 to reconstitute packets that do not match the original packets but 1791 still have valid IP, UDP and RTP headers and possibly even valid UDP 1792 check-sums. Such corruption may be detected with end-to-end 1793 authentication and integrity mechanisms which will not be affected by 1794 the compression. Constant portions of authentication headers will be 1795 compressed as described in [3]. 1797 No authentication is performed on the CONTEXT_STATE control packet 1798 sent by this protocol. An attacker with access to the link between 1799 the decompressor and compressor could inject false CONTEXT_STATE 1800 packets and cause compression efficiency to be reduced, probably 1801 resulting in congestion on the link. However, an attacker with 1802 access to the link could also disrupt the traffic in many other ways. 1804 A potential denial-of-service threat exists when using compression 1805 techniques that have non-uniform receiver-end computational load. 1806 The attacker can inject pathological datagrams into the stream which 1807 are complex to decompress and cause the receiver to be overloaded and 1808 degrading processing of other streams. However, this compression 1809 does not exhibit any significant non-uniformity. 1811 A security review of this protocol found no additional security 1812 considerations. 1814 10. Authors' Addresses 1816 Stephen L. Casner 1817 Packet Design, Inc. 1818 66 Willow Place 1819 Menlo Park, CA 94025 1820 United States of America 1822 Email: casner@acm.org 1824 Van Jacobson 1825 Packet Design, Inc. 1826 66 Willow Place 1827 Menlo Park, CA 94025 1828 United States of America 1830 EMail: van@packetdesign.com 1832 Tmima Koren 1833 Cisco Systems, Inc. 1834 170 West Tasman Drive 1835 San Jose, CA 95134-1706 1836 United States of America 1838 Email: tmima@cisco.com 1840 John Geevarghese 1841 Telseon Inc, 1842 480 S. California 1843 Palo-Alto, CA-94306 1845 Email: geevjohn@hotmail.com 1847 Bruce Thompson 1848 Cisco Systems, Inc. 1849 170 West Tasman Drive 1850 San Jose, CA 95134-1706 1851 United States of America 1853 Email: brucet@cisco.com 1855 Dan Wing 1856 Cisco Systems, Inc. 1857 170 West Tasman Drive 1858 San Jose, CA 95134-1706 1859 United States of America 1861 Email: dwing@cisco.com 1863 Patrick Ruddy 1864 Cisco Systems, Inc. 1865 3rd Floor, 96 Commercial Street 1866 Edinburgh 1867 EH6 6LX 1868 Scotland 1870 Email: pruddy@cisco.com 1872 Alex Tweedly 1873 Cisco Systems, Inc. 1874 3 The Square, Stockley Park 1875 Uxbridge, Middlesex 1876 UB11 1BN 1877 United Kingdom 1879 Email: agt@cisco.com 1881 10. Full Copyright Statement 1883 Copyright (C) The Internet Society (1999). All Rights Reserved. 1885 This document and translations of it may be copied and furnished to 1886 others, and derivative works that comment on or otherwise explain it 1887 or assist in its implementation may be prepared, copied, published 1888 and distributed, in whole or in part, without restriction of any 1889 kind, provided that the above copyright notice and this paragraph are 1890 included on all such copies and derivative works. However, this 1891 document itself may not be modified in any way, such as by removing 1892 the copyright notice or references to the Internet Society or other 1893 Internet organizations, except as needed for the purpose of 1894 developing Internet standards in which case the procedures for 1895 copyrights defined in the Internet Standards process must be 1896 followed, or as required to translate it into languages other than 1897 English. 1899 The limited permissions granted above are perpetual and will not be 1900 revoked by the Internet Society or its successors or assigns. 1902 This document and the information contained herein is provided on an 1903 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1904 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1905 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1906 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1907 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.