rfc2508.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,348 行 · 第 1/5 页
TXT
1,348 行
The amount of memory required to store the context will vary
depending upon how many encapsulating headers are included in the
FULL_HEADER packet. The compressor and decompressor MAY negotiate a
maximum header size.
3.3.2. COMPRESSED_RTP packet format
When the second-order difference of the RTP header from packet to
packet is zero, the decompressor can reconstruct a packet simply by
adding the stored first-order differences to the stored uncompressed
header representing the previous packet. All that need be
communicated is the session context identifier and a small sequence
number (not related to the RTP sequence number) to maintain
synchronization and detect packet loss between the compressor and
decompressor.
Casner & Jacobson Standards Track [Page 10]
RFC 2508 Compressing IP/UDP/RTP Headers February 1999
If the second-order difference of the RTP header is not zero for some
fields, the new first-order difference for just those fields is
communicated using a compact encoding. The new first-order
difference values are added to the corresponding fields in the
uncompressed header in the decompressor's session context, and are
also stored explicitly in the context to be added to the
corresponding fields again on each subsequent packet in which the
second-order difference is zero. Each time the first-order
difference changes, it is transmitted and stored in the context.
In practice, the only fields for which it is useful to store the
first-order difference are the IPv4 ID field and the RTP timestamp.
For the RTP sequence number field, the usual increment is 1. If the
sequence number changes by other than 1, the difference must be
communicated but does not set the expected difference for the next
packet. Instead, the expected first-order difference remains fixed
at 1 so that the difference need not be explicitly communicated on
the next packet assuming it is in order.
For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or
COMPRESSED_UDP packet is sent to refresh the RTP state, the stored
first-order difference is initialized to zero. If the timestamp is
the same on the next packet (e.g., same video frame), then the
second-order difference is zero. Otherwise, the difference between
the timestamps of the two packets is transmitted as the new first-
order difference to be added to the timestamp in the uncompressed
header stored in the decompressor's context and also stored as the
first-order difference in that context. Each time the first-order
difference changes on subsequent packets, that difference is again
transmitted and used to update the context.
Similarly, since the IPv4 ID field frequently increments by one, the
first-order difference for that field is initialized to one when the
state is refreshed by a FULL_HEADER packet, or when a
COMPRESSED_NON_TCP packet is sent since it carries the ID field in
uncompressed form. Thereafter, whenever the first-order difference
changes, it is transmitted and stored in the context.
A bit mask will be used to indicate which fields have changed by
other than the expected difference. In addition to the small link
sequence number, the list of items to be conditionally communicated
in the compressed IP/UDP/RTP header is as follows:
Casner & Jacobson Standards Track [Page 11]
RFC 2508 Compressing IP/UDP/RTP Headers February 1999
I = IPv4 packet ID (always 0 if no IPv4 header)
U = UDP checksum
M = RTP marker bit
S = RTP sequence number
T = RTP timestamp
L = RTP CSRC count and list
If 4 bits are needed for the link sequence number to get a reasonable
probability of loss detection, there are too few bits remaining to
assign one bit to each of these items and still fit them all into a
single byte to go along with the context ID.
It is not necessary to explicitly carry the U bit to indicate the
presence of the UDP checksum because a source will typically include
check-sums on all packets of a session or none of them. When the
session state is initialized with an uncompressed header, if there is
a nonzero checksum present, an unencoded 16-bit checksum will be
inserted into the compressed header in all subsequent packets until
this setting is changed by sending another uncompressed packet.
Of the remaining items, the L bit for the CSRC count and list may be
the one least frequently used. Rather than dedicating a bit in the
mask to indicate CSRC change, an unusual combination of the other
bits may be used instead. This bit combination is denoted MSTI. If
all four of the bits for the IP packet ID, RTP marker bit, RTP
sequence number and RTP timestamp are set, this is a special case
indicating an extended form of the compressed RTP header will follow.
That header will include an additional byte containing the real
values of the four bits plus the CC count. The CSRC list, of length
indicated by the CC count, will be included just as it appears in the
uncompressed RTP header.
The other fields of the RTP header (version, P bit, X bit, payload
type and SSRC identifier) are assumed to remain relatively constant.
In particular, the SSRC identifier is defined to be constant for a
given context because it is one of the factors selecting the context.
If any of the other fields change, the uncompressed RTP header MUST
sent as described in Section 3.3.3.
The following diagram shows the compressed IP/UDP/RTP header with
dotted lines indicating fields that are conditionally present. The
most significant bit is numbered 0. Multi-byte fields are sent in
network byte order (most significant byte first). The delta fields
are often a single byte as shown but may be two or three bytes
depending upon the delta value as explained in Section 3.3.4.
Casner & Jacobson Standards Track [Page 12]
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 in
Casner & 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, two
Casner & 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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?