rfc2508.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,348 行 · 第 1/4 页
TXT
1,348 行
RFC 2508 Compressing IP/UDP/RTP Headers February 1999 0 1 2 3 4 5 6 7 +...............................+ : msb of session context ID : (if 16-bit CID) +-------------------------------+ | lsb of session context ID | +---+---+---+---+---+---+---+---+ | M | S | T | I | link sequence | +---+---+---+---+---+---+---+---+ : : + UDP checksum + (if nonzero in context) : : +...............................+ : : + "RANDOM" fields + (if encapsulated) : : +...............................+ : M'| S'| T'| I'| CC : (if MSTI = 1111) +...............................+ : delta IPv4 ID : (if I or I' = 1) +...............................+ : delta RTP sequence : (if S or S' = 1) +...............................+ : delta RTP timestamp : (if T or T' = 1) +...............................+ : : : CSRC list : (if MSTI = 1111 : : and CC nonzero) : : +...............................+ : : : RTP header extension : (if X set in context) : : : : +-------------------------------+ | | | RTP data | / / / / | | +-------------------------------+ : padding : (if P set in context) +...............................+ When more than one IPv4 header is present in the context as initialized by the FULL_HEADER packet, then the IP ID fields of encapsulating headers MUST be sent as absolute values as described inCasner & Jacobson Standards Track [Page 13] RFC 2508 Compressing IP/UDP/RTP Headers February 1999 [3]. These fields are identified as "RANDOM" fields. They are inserted into the COMPRESSED_RTP packet in the same order as they appear in the original headers, immediately following the UDP checksum if present or the MSTI byte if not, as shown in the diagram. Only if an IPv4 packet immediately precedes the UDP header will the IP ID of that header be sent differentially, i.e., potentially with no bits if the second difference is zero, or as a delta IPv4 ID field if not. If there is not an IPv4 header immediately preceding the UDP header, then the I bit MUST be 0 and no delta IPv4 ID field will be present.3.3.3. COMPRESSED_UDP packet format If there is a change in any of the fields of the RTP header that are normally constant (such as the payload type field), then an uncompressed RTP header MUST be sent. If the IP and UDP headers do not also require updating, this RTP header MAY be carried in a COMPRESSED_UDP packet rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP packet except that the M, S and T bits are always 0 and the corresponding delta fields are never included: 0 1 2 3 4 5 6 7 +...............................+ : msb of session context ID : (if 16-bit CID) +-------------------------------+ | lsb of session context ID | +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | I | link sequence | +---+---+---+---+---+---+---+---+ : : + UDP checksum + (if nonzero in context) : : +...............................+ : : + "RANDOM" fields + (if encapsulated) : : +...............................+ : delta IPv4 ID : (if I = 1) +-------------------------------+ | UDP data | : (uncompressed RTP header) : Note that this constitutes a form of IP/UDP header compression different from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is to allow reaching the target of two bytes when UDP checksums are disabled, as IPv4 allows. The protocol in [3] does not use differential coding for UDP packets, so in the IPv4 case, twoCasner & Jacobson Standards Track [Page 14] RFC 2508 Compressing IP/UDP/RTP Headers February 1999 bytes of IP ID, and two bytes of UDP checksum if nonzero, would always be transmitted in addition to two bytes of compression prefix. For IPv6, the COMPRESSED_NON_TCP packet type MAY be used instead.3.3.4. Encoding of differences The delta fields in the COMPRESSED_RTP and COMPRESSED_UDP packets are encoded with a variable-length mapping for compactness of the more commonly-used values. A default encoding is specified below, but it is RECOMMENDED that implementations use a table-driven delta encoder and decoder to allow negotiation of a table specific for each session if appropriate, possibly even an optimal Huffman encoding. Encodings based on sequential interpretation of the bit stream, of which this default table and Huffman encoding are examples, allow a reasonable table size and may result in an execution speed faster than a non- table-driven implementation with explicit tests for ranges of values. The default delta encoding is specified in the following table. This encoding was designed to efficiently encode the small changes that may occur in the IP ID and in RTP sequence number when packets are lost upstream from the compressor, yet still handling most audio and video deltas in two bytes. The column on the left is the decimal value to be encoded, and the column on the right is the resulting sequence of bytes shown in hexadecimal and in the order in which they are transmitted (network byte order). The first and last values in each contiguous range are shown, with ellipses in between: Decimal Hex -16384 C0 00 00 : : -129 C0 3F 7F -128 80 00 : : -1 80 7F 0 00 : : 127 7F 128 80 80 : : 16383 BF FF 16384 C0 40 00 : : 4194303 FF FF FF For positive values, a change of zero through 127 is represented directly in one byte. If the most significant two bits of the byte are 10 or 11, this signals an extension to a two- or three-byteCasner & Jacobson Standards Track [Page 15] RFC 2508 Compressing IP/UDP/RTP Headers February 1999 value, respectively. The least significant six bits of the first byte are combined, in decreasing order of significance, with the next one or two bytes to form a 14- or 22-bit value. Negative deltas may occur when packets are misordered or in the intentionally out-of-order RTP timestamps on MPEG video [5]. These events are less likely, so a smaller range of negative values is encoded using otherwise redundant portions of the positive part of the table. A change in the RTP timestamp value less than -16384 or greater than 4194303 forces the RTP header to be sent uncompressed using a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The IP ID and RTP sequence number fields are only 16 bits, so negative deltas for those fields SHOULD be masked to 16 bits and then encoded (as large positive 16-bit numbers).3.3.5. Error Recovery Whenever the 4-bit sequence number for a particular context increments by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP packet, the decompressor MUST invalidate that context and send a CONTEXT_STATE packet back to the compressor indicating that the context has been invalidated. All packets for the invalid context MUST be discarded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for that context to re- establish consistent state (unless the "twice" algorithm is used as described later in this section). Since multiple compressed packets may arrive in the interim, the decompressor SHOULD NOT retransmit the CONTEXT_STATE packet for every compressed packet received, but instead SHOULD limit the rate of retransmission to avoid flooding the reverse channel. When an error occurs on the link, the link layer will usually discard the packet that was damaged (if any), but may provide an indication of the error. Some time may elapse before another packet is delivered for the same context, and then that packet would have to be discarded by the decompressor when it is observed to be out of sequence, resulting in at least two packets lost. To allow faster recovery if the link does provide an explicit error indication, the decompressor MAY optionally send an advisory CONTEXT_STATE packet listing the last valid sequence number and generation number for one or more recently active contexts (not necessarily all). For a given context, if the compressor has sent no compressed packet with a higher sequence number, and if the generation number matches the current generation, no corrective action is required. Otherwise, the compressor MAY choose to mark the context invalid so that the next packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode (FULL_HEADERCasner & Jacobson Standards Track [Page 16] RFC 2508 Compressing IP/UDP/RTP Headers February 1999 is required if the generation doesn't match). However, note that if the link round-trip-time is large compared to the inter-packet spacing, there may be several packets from multiple contexts in flight across the link, increasing the probability that the sequence numbers will already have advanced when the CONTEXT_STATE packet is received by the compressor. The result could be that some contexts are invalidated unnecessarily, causing extra bandwidth to be consumed. The format of the CONTEXT_STATE packet is shown in the following diagrams. The first byte is a type code to allow the CONTEXT_STATE packet type to be shared by multiple compression schemes within the general compression framework specified in [3]. The contents of the remainder of the packet depends upon the compression scheme. For the IP/UDP/RTP compression scheme specified here, the remainder of the CONTEXT_STATE packet is structured as a list of blocks to allow the state for multiple contexts to be indicated, preceded by a one-byte count of the number of blocks. Two type code values are used for the IP/UDP/RTP compression scheme. The value 1 indicates that 8-bit session context IDs are being used: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 = IP/UDP/RTP with 8-bit CID | +---+---+---+---+---+---+---+---+ | context count | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | session context ID | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | 0 | generation | +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | session context ID | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | 0 | generation | +---+---+---+---+---+---+---+---+ The value 2 indicates that 16-bit session context IDs are being used. The session context ID is sent in network byte order (most significant byte first):Casner & Jacobson Standards Track [Page 17] RFC 2508 Compressing IP/UDP/RTP Headers February 1999 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 2 = IP/UDP/RTP with 16-bit CID| +---+---+---+---+---+---+---+---+ | context count | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | + session context ID + | | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | 0 | generation | +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | | + session context ID + | | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | 0 | generation | +---+---+---+---+---+---+---+---+ The bit labeled "I" is set to one for contexts that have been marked invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be transmitted. If the I bit is zero, the context state is advisory. The I bit is set to zero to indicate advisory context state that MAY be sent following a link error indication. Since the CONTEXT_STATE packet itself may be lost, retransmission of one or more blocks is allowed. It is expected that retransmission will be triggered only by receipt of another packet, but if the line is near idle, retransmission MAY be triggered by a relatively long timer (on the order of 1 second). If a CONTEXT_STATE block for a given context is retransmitted, it may cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended to refresh that context. In that case, the compressor MAY choose to ignore the error indication. In the case where UDP checksums are being transmitted, the decompressor MAY attempt to use the "twice" algorithm described in section 10.1 of [3]. In this algorithm, the delta is applied more than once on the assumption that the delta may have been the same on the missing packet(s) and the one subsequently received. Success isCasner & Jacobson Standards Track [Page 18] ⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?