draft-ietf-avt-crtp-enhance-01.txt   draft-ietf-avt-crtp-enhance-02.txt 
Audio/Video Transport Working Group Tmima Koren
Audio/Video Transport Working Group Stephen Casner Internet Draft Cisco Systems
Internet Draft Packet Design July 16, 2001 Stephen Casner
November 17, 2000 Van Jacobson Expires March 2002 Packet Design
Expires June 2001 Packet Design draft-ietf-avt-crtp-enhance-02.txt John Geevarghese
draft-ietf-avt-crtp-enhance-01.txt Tmima Koren Telseon
Bruce Thompson Bruce Thompson
Dan Wing
Patrick Ruddy Patrick Ruddy
Alex Tweedly
Cisco Systems Cisco Systems
John Geevarghese
Telseon
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Compressing IP/UDP/RTP headers on links with high delay,
packet loss and reordering
Status of this memo Status of this memo
This document is an Internet Draft and is in full conformance with all This document is an Internet Draft and is in full conformance with
provisions of Section 10 of RFC 2026. Internet Drafts are working documents of all provisions of Section 10 of RFC 2026. Internet Drafts are
the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. working documents of the Internet Engineering Task Force (IETF), its
Note that other groups may also distribute working documents as Internet Drafts. Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months. Internet Internet Drafts are draft documents valid for a maximum of six
Drafts may be updated, replaced, or obsolete by other documents at any time. It months. Internet Drafts may be updated, replaced, or obsolete by
is not appropriate to use Internet Drafts as reference material or to cite them other documents at any time. It is not appropriate to use Internet
other than as "work in progress". Drafts as reference material or to cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.txt http://www.ietf.org/shadow.txt
This draft is being submitted as a possible work item to the IETF Audio/Video This draft is a work item of the IETF Audio/Video Transport working
Transport working group. To subscribe to the mailing list send a message to group. The working group mailing list is avt@ietf.org. Subscribe via
rem-conf-request@es.net with the line "subscribe" in the body of the message. the web at http://www.ietf.org/mailman/listinfo/avt.
Archives are available from:
ftp://ftp.es.net/pub/mail-archive/rem-conf
Copyright Notice
Copyright (C) The Internet Society (1999-2000). All Rights Reserved. Copyright (C) The Internet Society (1999-2001). All Rights Reserved.
Abstract Abstract
This document describes a method for compressing the headers of This document describes a header compression scheme for point to
IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. point links with packet loss and long delays. It is based on CRTP,
In many cases, all three headers can be compressed to 2-4 bytes. the IP/UDP/RTP header compression described in [RFC2508]. CRTP does
not perform well on such links: packet loss results in context
Comments are solicited and should be addressed to the working group corruption and due to the long delay, many more packets are
mailing list rem-conf@es.net and/or the author(s). discarded before the context is repaired. To correct the behavior of
CRTP over such links, a few extensions to the protocol are specified
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", here. The extensions aim to reduce context corruption by changing
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this the way the compressor updates the context at the decompressor:
document are to be interpreted as described in RFC 2119. updates are repeated and include updates to full and differential
context parameters. With these extensions, CRTP performs well over
1. Introduction links with packet loss, packet reordering and long delays.
Since the Real-time Transport Protocol was published as an RFC [1],
there has been growing interest in using RTP as one step to achieve
interoperability among different implementations of network
audio/video applications. However, there is also concern that the
12-byte RTP header is too large an overhead for 20-byte payloads when
operating over low speed lines such as dial-up modems at 14.4 or 28.8
kb/s. (Some existing applications operating in this environment use
an application-specific protocol with a header of a few bytes that
has reduced functionality relative to RTP.)
Header size may be reduced through compression techniques as has been
done with great success for TCP [2]. In this case, compression might
be applied to the RTP header alone, on an end-to-end basis, or to the
combination of IP, UDP and RTP headers on a link-by-link basis.
Compressing the 40 bytes of combined headers together provides
substantially more gain than compressing 12 bytes of RTP header alone
because the resulting size is approximately the same (2-4 bytes) in
either case. Compressing on a link-by-link basis also provides
better performance because the delay and loss rate are lower.
Therefore, the method defined here is for combined compression of IP,
UDP and RTP headers on a link-by-link basis.
This document defines a compression scheme that may be used with
IPv4, IPv6 or packets encapsulated with more than one IP header,
though the initial focus is on IPv4. The IP/UDP/RTP compression
defined here is intended to fit within the more general compression
framework specified in [3] for use with both IPv6 and IPv4. That
framework defines TCP and non-TCP as two classes of transport above
IP. This specification creates IP/UDP/RTP as a third class extracted
from the non-TCP class.
2. Assumptions and Tradeoffs
The goal of this compression scheme is to reduce the IP/UDP/RTP
headers to two bytes for most packets in the case where no UDP
checksums are being sent, or four bytes with checksums. It is
motivated primarily by the specific problem of sending audio and
video over 14.4 and 28.8 dialup modems. These links tend to provide
full-duplex communication, so the protocol takes advantage of that
fact, though the protocol may also be used with reduced performance
on simplex links. This compression scheme performs best on local
links with low round-trip-time.
This specification does not address segmentation and preemption of
large packets to reduce the delay across the slow link experienced by
small real-time packets, except to identify in Section 4 some
interactions between segmentation and compression that may occur.
Segmentation schemes may be defined separately and used in
conjunction with the compression defined here.
It should be noted that implementation simplicity is an important
factor to consider in evaluating a compression scheme.
Communications servers may need to support compression over perhaps
as many as 100 dial-up modem lines using a single processor.
Therefore, it may be appropriate to make some simplifications in the
design at the expense of generality, or to produce a flexible design
that is general but can be subsetted for simplicity. Higher
compression gain might be achieved by communicating more complex
models for the changing header fields from the compressor to the
decompressor, but that complexity is deemed unnecessary. The next
sections discuss some of the tradeoffs listed here.
2.1. Simplex vs. Full Duplex
In the absence of other constraints, a compression scheme that worked
over simplex links would be preferred over one that did not.
However, operation over a simplex link requires periodic refreshes
with an uncompressed packet header to restore compression state in
case of error. If an explicit error signal can be returned instead,
the delay to recovery may be shortened substantially. The overhead
in the no-error case is also reduced. To gain these performance
improvements, this specification includes an explicit error
indication sent on the reverse path.
On a simplex link, it would be possible to use a periodic refresh
instead. Whenever the decompressor detected an error in a particular
packet stream, it would simply discard all packets in that stream
until an uncompressed header was received for that stream, and then
resume decompression. The penalty would be the potentially large
number of packets discarded. The periodic refresh method described
in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex
links or links with high delay as well as to other non-TCP packet
streams.
2.2. Links with high bit error rate and long round trip delay
IP/UDP/RTP header compression may be used in scenarios where a compressed link
could extend over a long physical distance and involve multiple layer-2
switching points. An example of such a link is RTP transport over ATM AAL5,
where the "link" would actually traverse through multiple layer-2 switching
points on the path from the CRTP transmitter (compressor) to the CRTP receiver
(decompressor). Another example is a wireless link. Such links may experience
significant packet loss and/or long round trip delays. Contexts get invalidated
due to packet loss, but the CRTP error recovery mechanism using CONTEXT_STATE
messages is not efficient due to the long round trip delay.
In scenarios such as this, it is desirable to minimize context invalidation. A
set of enhancements is defined for error prevention and recovery. The
enhancements make CRTP more robust and resilient to packet loss, which in turn
will reduce context invalidation.
2.3. Segmentation and Layering
Delay induced by the time required to send a large packet over the
slow link is not a problem for one-way audio, for example, because
the receiver can adapt to the variance in delay. However, for
interactive conversations, minimizing the end-to-end delay is
critical. Segmentation of large, non-real-time packets to allow
small real-time packets to be transmitted between segments can reduce
the delay.
This specification deals only with compression and assumes
segmentation, if included, will be handled as a separate layer. It
would be inappropriate to integrate segmentation and compression in
such a way that the compression could not be used by itself in
situations where segmentation was deemed unnecessary or impractical.
Similarly, one would like to avoid any requirements for a reservation
protocol. The compression scheme can be applied locally on the two
ends of a link independent of any other mechanisms except for the
requirements that the link layer provide some packet type codes, a
packet length indication, and good error detection.
Conversely, separately compressing the IP/UDP and RTP layers loses
too much of the compression gain that is possible by treating them
together. Crossing these protocol layer boundaries is appropriate
because the same function is being applied across all layers.
3. The Compression Algorithm
The compression algorithm defined in this document draws heavily upon
the design of TCP/IP header compression as described in RFC 1144 [2].
Readers are referred to that RFC for more information on the
underlying motivations and general principles of header compression.
3.1. The basic idea
In TCP header compression, the first factor-of-two reduction in data
rate comes from the observation that half of the bytes in the IP and
TCP headers remain constant over the life of the connection. After
sending the uncompressed header once, these fields may be elided from
the compressed headers that follow. The remaining compression comes
from differential coding on the changing fields to reduce their size,
and from eliminating the changing fields entirely for common cases by
calculating the changes from the length of the packet. This length
is indicated by the link-level protocol.
For RTP header compression, some of the same techniques may be
applied. However, the big gain comes from the observation that
although several fields change in every packet, the difference from
packet to packet is often constant and therefore the second-order
difference is zero. By maintaining both the uncompressed header and
the first-order differences in the session state shared between the
compressor and decompressor, all that must be communicated is an
indication that the second-order difference was zero. In that case,
the decompressor can reconstruct the original header without any loss
of information simply by adding the first-order differences to the
saved uncompressed header as each compressed packet is received.
Just as TCP/IP header compression maintains shared state for multiple
simultaneous TCP connections, this IP/UDP/RTP compression SHOULD
maintain state for multiple session contexts. A session context is
defined by the combination of the IP source and destination
addresses, the UDP source and destination ports, and the RTP SSRC
field. A compressor implementation might use a hash function on
these fields to index a table of stored session contexts. The
compressed packet carries a small integer, called the session context
identifier or CID, to indicate in which session context that packet
should be interpreted. The decompressor can use the CID to index its
table of stored session contexts directly.
Because the RTP compression is lossless, it may be applied to any UDP
traffic that benefits from it. Most likely, the only packets that
will benefit are RTP packets, but it is acceptable to use heuristics
to determine whether or not the packet is an RTP packet because no
harm is done if the heuristic gives the wrong answer. This does
require executing the compression algorithm for all UDP packets, or
at least those with even port numbers (see section 3.4).
Most compressor implementations will need to maintain a "negative
cache" of packet streams that have failed to compress as RTP packets
for some number of attempts in order to avoid further attempts.
Failing to compress means that some fields in the potential RTP
header that are expected to remain constant most of the time, such as
the payload type field, keep changing. Even if the other such fields
remain constant, a packet stream with a constantly changing SSRC
field SHOULD be entered in the negative cache to avoid consuming all
of the available session contexts. The negative cache is indexed by
the source and destination IP address and UDP port pairs but not the
RTP SSRC field since the latter may be changing. When RTP
compression fails, the IP and UDP headers MAY still be compressed.
Fragmented IP Packets that are not initial fragments and packets that
are not long enough to contain a complete UDP header MUST NOT be sent
as FULL_HEADER packets. Furthermore, packets that do not
additionally contain at least 12 bytes of UDP data MUST NOT be used
to establish RTP context. If such a packet is sent as a FULL_HEADER
packet, it MAY be followed by COMPRESSED_UDP packets but MUST NOT be
followed by COMPRESSED_RTP packets.
3.2. Header Compression for RTP Data Packets
In the IPv4 header, only the total length, packet ID, and header
check-sum fields will normally change. The total length is redundant
with the length provided by the link layer, and since this
compression scheme must depend upon the link layer to provide good
error detection (e.g., PPP's CRC [4]), the header checksum may also
be elided. This leaves only the packet ID, which, assuming no IP
fragmentation, would not need to be communicated. However, in order
to maintain lossless compression, changes in the packet ID will be
transmitted. The packet ID usually increments by one or a small
number for each packet. (Some systems increment the ID with the
bytes swapped, which results in slightly less compression.) In the
IPv6 base header, there is no packet ID nor header checksum and only
the payload length field changes.
In the UDP header, the length field is redundant with the IP total
length field and the length indicated by the link layer. The UDP
check-sum field will be a constant zero if the source elects not to
generate UDP checksums. Otherwise, the checksum must be communicated
intact in order to preserve the lossless compression. Maintaining
end-to-end error detection for applications that require it is an
important principle.
In the RTP header, the SSRC identifier is constant in a given context
since that is part of what identifies the particular context. For
most packets, only the sequence number and the timestamp will change
from packet to packet. If packets are not lost or misordered
upstream from the compressor, the sequence number will increment by
one for each packet. For audio packets of constant duration, the
timestamp will increment by the number of sample periods conveyed in
each packet. For video, the timestamp will change on the first
packet of each frame, but then stay constant for any additional
packets in the frame. If each video frame occupies only one packet,
but the video frames are generated at a constant rate, then again the
change in the timestamp from frame to frame is constant. Note that
in each of these cases the second-order difference of the sequence
number and timestamp fields is zero, so the next packet header can be
constructed from the previous packet header by adding the first-order
differences for these fields that are stored in the session context
along with the previous uncompressed header. When the second-order
difference is not zero, the magnitude of the change is usually much
smaller than the full number of bits in the field, so the size can be
reduced by encoding the new first-order difference and transmitting
it rather than the absolute value.
The M bit will be set on the first packet of an audio talkspurt and
the last packet of a video frame. If it were treated as a constant
field such that each change required sending the full RTP header,
this would reduce the compression significantly. Therefore, one bit
in the compressed header will carry the M bit explicitly.
If the packets are flowing through an RTP mixer, most commonly for
audio, then the CSRC list and CC count will also change. However,
the CSRC list will typically remain constant during a talkspurt or
longer, so it need be sent only when it changes.
3.3. The protocol
The compression protocol must maintain a collection of shared
information in a consistent state between the compressor and
decompressor. There is a separate session context for each
IP/UDP/RTP packet stream, as defined by a particular combination of
the IP source and destination addresses, UDP source and destination
ports, and the RTP SSRC field. The number of session contexts to be
maintained MAY be negotiated between the compressor and decompressor.
Each context is identified by an 8- or 16-bit identifier, depending
upon the number of contexts negotiated, so the maximum number is
65536. Both uncompressed and compressed packets MUST carry the
context ID and a 4-bit sequence number used to detect packet loss
between the compressor and decompressor. Each context has its own
separate sequence number space so that a single packet loss need only
invalidate one context.
The shared information in each context consists of the following
items:
o The full IP, UDP and RTP headers, possibly including a CSRC
list, for the last packet sent by the compressor or
reconstructed by the decompressor.
o The first-order difference for the IPv4 ID field, initialized to
1 whenever an uncompressed IP header for this context is
received and updated each time a delta IPv4 ID field is received
in a compressed packet.
o The first-order difference for the RTP timestamp field,
initialized to 0 whenever an uncompressed packet for this
context is received and updated each time a delta RTP timestamp
field is received in a compressed packet.
o The last value of the 4-bit sequence number, which is used to
detect packet loss between the compressor and decompressor.
o The current generation number for non-differential coding of UDP
packets with IPv6 (see [3]). For IPv4, the generation number
may be set to zero if the COMPRESSED_NON_TCP packet type,
defined below, is never used.
o A context-specific delta encoding table (see section 3.3.4) may
optionally be negotiated for each context.
In order to communicate packets in the various uncompressed and
compressed forms, this protocol depends upon the link layer being
able to provide an indication of four new packet formats in addition
to the normal IPv4 and IPv6 packet formats:
FULL_HEADER - communicates the uncompressed IP header plus any
following headers and data to establish the uncompressed header
state in the decompressor for a particular context. The FULL-
HEADER packet also carries the 8- or 16-bit session context
identifier and the 4-bit sequence number to establish
synchronization between the compressor and decompressor. The
format is shown in section 3.3.1.
COMPRESSED_UDP - communicates the IP and UDP headers compressed to
6 or fewer bytes (often 2 if UDP checksums are disabled), followed
by any subsequent headers (possibly RTP) in uncompressed form,
plus data. This packet type is used when there are differences in
the usually constant fields of the (potential) RTP header. The
RTP header includes a potentially changed value of the SSRC field,
so this packet may redefine the session context. The format is
shown in section 3.3.3.
COMPRESSED_RTP - indicates that the RTP header is compressed along
with the IP and UDP headers. The size of this header may still be
just two bytes, or more if differences must be communicated. This
packet type is used when the second-order difference (at least in
the usually constant fields) is zero. It includes delta encodings
for those fields that have changed by other than the expected
amount to establish the first-order differences after an
uncompressed RTP header is sent and whenever they change. The
format is shown in section 3.3.2.
CONTEXT_STATE - indicates a special packet sent from the
decompressor to the compressor to communicate a list of context
IDs for which synchronization has or may have been lost. This
packet is only sent across the point-to-point link so it requires
no IP header. The format is shown in section 3.3.5.
When this compression scheme is used with IPv6 as part of the general
header compression framework specified in [3], another packet type
MAY be used:
COMPRESSED_NON_TCP - communicates the compressed IP and UDP
headers as defined in [3] without differential encoding. If it
were used for IPv4, it would require one or two bytes more than
the COMPRESSED_UDP form listed above in order to carry the IPv4 ID
field. For IPv6, there is no ID field and this non-differential
compression is more resilient to packet loss.
Assignments of numeric codes for these packet formats in the Point-
to-Point Protocol [4] are to be made by the Internet Assigned Numbers
Authority.
3.3.1. FULL_HEADER (uncompressed) packet format
The definition of the FULL_HEADER packet given here is intended to be
the consistent with the definition given in [3]. Full details on
design choices are given there.
The format of the FULL_HEADER packet is the same as that of the
original packet. In the IPv4 case, this is usually an IP header,
followed by a UDP header and UDP payload that may be an RTP header
and its payload. However, the FULL_HEADER packet may also carry IP
encapsulated packets, in which case there would be two IP headers
followed by UDP and possibly RTP. Or in the case of IPv6, the packet
may be built of some combination of IPv6 and IPv4 headers. Each
successive header is indicated by the type field of the previous
header, as usual.
The FULL_HEADER packet differs from the corresponding normal IPv4 or
IPv6 packet in that it must also carry the compression context ID and
the 4-bit sequence number. In order to avoid expanding the size of
the header, these values are inserted into length fields in the IP
and UDP headers since the actual length may be inferred from the
length provided by the link layer. Two 16-bit length fields are
needed; these are taken from the first two available headers in the
packet. That is, for an IPv4/UDP packet, the first length field is
the total length field of the IPv4 header, and the second is the
length field of the UDP header. For an IPv4 encapsulated packet, the
first length field would come from the total length field of the
first IP header, and the second length field would come from the
total length field of the second IP header.
As specified in Sections 5.3.2 of [3], the position of the context ID
(CID) and 4-bit sequence number varies depending upon whether 8- or
16-bit context IDs have been selected, as shown in the following
diagram (16 bits wide, with the most-significant bit is to the left):
For 8-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For 16-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 | seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit in the first length field indicates the length of the
CID. The length of the CID MUST either be constant for all contexts
or two additional distinct packet types MUST be provided to
separately indicate COMPRESSED_UDP and COMPRESSED_RTP packet formats
with 8- and 16-bit CIDs. The second bit in the first length field is
1 to indicate that the 4-bit sequence number is present, as is always
the case for this IP/UDP/RTP compression scheme.
The generation field is used with IPv6 for COMPRESSED_NON_TCP packets
as described in [3]. For IPv4-only implementations that do not use
COMPRESSED_NON_TCP packets, the compressor SHOULD set the generation
value to zero. For consistent operation between IPv4 and IPv6, the
generation value is stored in the context when it is received by the
decompressor, and the most recent value is returned in the
CONTEXT_STATE packet.
When a FULL_HEADER packet is received, the complete set of headers is
stored into the context selected by the context ID. The 4-bit
sequence number is also stored in the context, thereby
resynchronizing the decompressor to the compressor.
When COMPRESSED_NON_TCP packets are used, the 4-bit sequence number
is inserted into the "Data Field" of that packet and the D bit is set
as described in Section 6 of [3]. When a COMPRESSED_NON_TCP packet
is received, the generation number is compared to the value stored in
the context. If they are not the same, the context is not up to date
and MUST be refreshed by a FULL_HEADER packet. If the generation
does match, then the compressed IP and UDP header information, the
4-bit sequence number, and the (potential) RTP header are all stored
into the saved context.
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.
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:
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.
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
[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
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-byte
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_HEADER
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):
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 is
indicated by a checksum match. For the scheme defined here, the
difference in the 4- bit sequence number tells number of times the
delta must be applied. Note, however, that there is a nontrivial
risk of an incorrect positive indication. It may be advisable to
request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the
"twice" algorithm succeeds.
Some errors may not be detected, for example if 16 packets are lost
in a row and the link level does not provide an error indication. In
that case, the decompressor will generate packets that are not valid.
If UDP checksums are being transmitted, the receiver will probably
detect the invalid packets and discard them, but the receiver does
not have any means to signal the decompressor. Therefore, it is
RECOMMENDED that the decompressor verify the UDP checksum
periodically, perhaps one out of 16 packets. If an error is
detected, the decompressor would invalidate the context and signal
the compressor with a CONTEXT_STATE packet.
3.4. Compression of RTCP Control Packets
By relying on the RTP convention that data is carried on an even port
number and the corresponding RTCP packets are carried on the next
higher (odd) port number, one could tailor separate compression
schemes to be applied to RTP and RTCP packets. For RTCP, the
compression could apply not only to the header but also the "data",
that is, the contents of the different packet types. The numbers in
Sender Report (SR) and Receiver Report (RR) RTCP packets would not
compress well, but the text information in the Source Description
(SDES) packets could be compressed down to a bit mask indicating each
item that was present but compressed out (for timing purposes on the
SDES NOTE item and to allow the end system to measure the average
RTCP packet size for the interval calculation).
However, in the compression scheme defined here, no compression will
be done on the RTCP headers and "data" for several reasons (though
compression SHOULD still be applied to the IP and UDP headers).
Since the RTP protocol specification suggests that the RTCP packet
interval be scaled so that the aggregate RTCP bandwidth used by all
participants in a session will be no more than 5% of the session
bandwidth, there is not much to be gained from RTCP compression.
Compressing out the SDES items would require a significant increase
in the shared state that must be stored for each context ID. And, in
order to allow compression when SDES information for several sources
was sent through an RTP "mixer", it would be necessary to maintain a
separate RTCP session context for each SSRC identifier. In a session
with more than 255 participants, this would cause perfect thrashing
of the context cache even when only one participant was sending data.
Even though RTCP is not compressed, the fraction of the total
bandwidth occupied by RTCP packets on the compressed link remains no
more than 5% in most cases, assuming that the RTCP packets are sent
as COMPRESSED_UDP packets. Given that the uncompressed RTCP traffic
consumes no more than 5% of the total session bandwidth, then for a
typical RTCP packet length of 90 bytes, the portion of the compressed
bandwidth used by RTCP will be no more than 5% if the size of the
payload in RTP data packets is at least 108 bytes. If the size of
the RTP data payload is smaller, the fraction will increase, but is
still less than 7% for a payload size of 37 bytes. For large data
payloads, the compressed RTCP fraction is less than the uncompressed
RTCP fraction (for example, 4% at 1000 bytes).
3.5. Compression of non-RTP UDP Packets
As described earlier, the COMPRESSED_UDP packet MAY be used to
compress UDP packets that don't carry RTP. Whatever data follows the
UDP header is unlikely to have some constant values in the bits that
correspond to usually constant fields in the RTP header. In
particular, the SSRC field would likely change. Therefore, it is
necessary to keep track of the non-RTP UDP packet streams to avoid
using up all the context slots as the "SSRC field" changes (since
that field is part of what identifies a particular RTP context).
Those streams may each be given a context, but the encoder would set
a flag in the context to indicate that the changing SSRC field should
be ignored and COMPRESSED_UDP packets should always be sent instead
of COMPRESSED_RTP packets.
4. Enhancements for links with high bit error rate and long round trip delay
4.1 The negative cache stream flag
Certain streams, known or suspected to not be RTP, can be placed in a "negative
cache" at the compressor, so only the IP and UDP headers are compressed. It is
beneficial to notify the decompressor that the compressed stream is in the
negative cache: for such streams the context is shorter - there is no need to
include the RTP header, and all RTP-related calculations can be avoided.
In this enhancement, a new flag bit "N" is added to the FULL_HEADER packet that
initializes a context at the decompressor. The bit occupied by the new flag was
previously always set to zero. If the N flag is set to 1, this indicates that
no COMPRESSED_RTP packets will be transmitted in this context. This flag is
only an optimization and the decompressor may choose to ignore it.
Format of the FULL_HEADER length fields with the negative cache flag:
For 8-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IPCP option 'IP header compression' (described in RFC 2509) is
| 0 |N| seq | Second length field also extended to negotiate using the extended CRTP.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream
For 16-bit context ID: 1.0 Introduction
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP header compression (CRTP) as described in RFC 2508 was designed
|1|1| Generation| 0 |N| seq | First length field to reduce the header overhead of IP/UDP/RTP datagrams by compressing
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream the three headers. The IP/UDP/RTP headers are compressed to 2-4
bytes most of the time.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CRTP was designed for reliable point to point links with short
| CID | Second length field delays. It does not perform well over links with high rate of packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ loss, packet reordering and long delays.
4.2 Reject a new compressed stream An example of such a link is a PPP session that is tunneled using an
IP level tunneling protocol such as L2TP. Packets within the tunnel
are carried by an IP network and hence may get lost and reordered.
The longer the tunnel, the longer the round trip time.
In a point to point link the two nodes can agree on the number of compressed Another example is an IP network that uses layer 2 technologies such
sessions they are prepared to support for this link. In an end-to-end scheme a as ATM and Frame Relay for the access portion of the network. Layer
host may have compressed sessions with many hosts and eventually may run out of 2 transport networks such as ATM and Frame Relay behave like point
resources. When the end-to-end tunnel is negotiated, the number of contexts to point serial links in that they do not reorder packets. In
needed may not be predictable. This enhancement allows the negotiated number of addition, Frame Relay and ATM virtual circuits used as IP access
contexts to be larger than could be accommodated if many tunnels are technologies often have a low bit rate associated with them. These
established. Then, as context resources are consumed, an attempt to set up a virtual circuits differ from low speed serial links in that they may
new context may be rejected. span a larger physical distance than a point to point serial link.
The compressor initiates a compression of a stream by sending a FULL_HEADER Speed of light delays within the layer 2 transport network will
packet. Currently if the decompressor has insufficient resources to decompress result in higher round trip delays between the endpoints of the
the new stream, it can send a CONTEXT_STATE packet to invalidate the newly circuit. In addition, congestion within the layer 2 transport
compressed stream. The compressor does not know the reason for the invalidation: network may result in an effective drop rate for the virtual circuit
usually this happens when the decompressor gets out of synchronization due to which is significantly higher than error rates typically experienced
packet loss. The compressor will most likely reattempt to compress this stream on point to point serial links.
by sending another FULL_HEADER.
This enhancement specifies that the decompressor may reject the compression of a
stream by sending a REJECT message to the compressor. A REJECT message tells the
compressor to stop compressing this stream.
The REJECT message is a CONTEXT_STATE message with an additional flag:
Type code = 1 :CONTEXT_STATE for 8-bit CID streams CRTP is widely deployed and has relatively low computational
Type code = 2 : CONTEXT_STATE for16-bit CID streams complexity. It is desirable to extend its usage over such links.
This can be achieved with a few simple extensions to the protocol.
Here is the format of CONTEXT_STATE packets with REJECT flags: 1.1 CRTP Operation
0 1 2 3 4 5 6 7 During compression of an RTP stream, a session context is defined.
+---+---+---+---+---+---+---+---+ For each context, the session state is established and shared
|Type code=1: CS, 8-bit CID | between the compressor and the decompressor. Once the context state
+---+---+---+---+---+---+---+---+ is established, compressed packets may be sent.
| context count |
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
. . .
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 The context state consists of the full IP/UDP/RTP headers, a few
+---+---+---+---+---+---+---+---+ first order differential values, a link sequence number, a
|Type code=2: CS, 16-bit CID| generation number and a delta encoding table.
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
. . .
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| 1 |R=1| 0 | 0 | sequence | R is the REJECT flag
+---+---+---+---+---+---+---+---+
| 0 | 0 | generation |
+---+---+---+---+---+---+---+---+
The session CID, sequence and generation are taken from the FULL_HEADER. The headers part of the context is set by the FULL_HEADER packet
that always starts a compression session. The first order
differential values (delta values) are set by sending COMPRESSED_RTP
packets that include updates to the delta values.
The compressor may decide to wait for a while before attempting to compress The context state must be synchronized between compressor and
additional streams destined to the rejecting host. decompressor for successful decompression to take place. If the
context gets out of sync, the decompressor is not able to restore
the compressed headers accurately. The decompressor invalidates the
context and sends a CONTEXT_STATE packet to the compressor
indicating that the context has been corrupted. To resume
compression, the compressor must reestablish the context.
4.3 Including IP ID in the UDP checksum During the time the context is corrupted, the decompressor discards
all the packets received for that context. Since the context repair
mechanism in CRTP involves feedback from the decompressor, context
repair takes at least as much time as the round trip time of the
link. If the round trip time of the link is long, and especially if
the link bandwidth is high, many packets will be discarded before
the context is repaired. On such links it is desirable to minimize
context invalidation.
A UDP checksum can be used by the decompressor to verify validity of the packet 1.2 How do contexts get corrupted?
it reconstructed, especially when the 'twice' algorithm is used. When the
'twice' algorithm was defined in RFC 2507 and subsequently incorporated into RFC
2508, the fact that the IP ID field is not included in the checksum was
overlooked. Since the IP ID field is conveyed with a delta value, accurate
reconstruction of the IP ID field cannot be verified using the current
specifications.
This enhancement modifies the function of the UDP checksum to include the IP ID As long as the fields in the combined IP/UDP/RTP headers change as
value, but only between the compressor and decompressor. That is, when a UDP expected for the sequence of packets in a session, those headers can
checksum is present (nonzero), the compressor will 1's complement subtract the be compressed, and the decompressor can fully restore the compressed
IP ID value from the UDP checksum before compression and the decompressor will headers using the context state. When the headers don't change as
1's complement add the IP ID value to the UDP checksum after any validation expected it's necessary to update some of the full or the delta
operations and before delivering the packet further downstream. values of the context. For example, the RTP timestamp is expected to
increment by delta RTP timestamp (dT). If silence suppression is
used, packets are not sent during silence periods. Then when voice
activity resumes, packets are sent again, but the RTP timestamp is
incremented by a large value and not by dT. In this case an update
must be sent.
4.4 CRTP Headers Checksum If a packet that includes an update to some context state values is
lost, the state at the decompressor is not updated. The shared state
is now different at the compressor and decompressor. When the next
packet arrives at the decompressor, the decompressor will fail to
restore the compressed headers accurately since the context state at
the decompressor is different than the state at the compressor.
When a UDP checksum is not present (has value zero) in a stream, the compressor 1.3 Preventing context corruption
MAY replace it with a 16-bit headers checksum (HDRCKSUM). The HDRCKSUM can be
used to validate the IP ID and all the headers in the reconstructed packet.
Hence it can be used by the decompressor to validate reconstructed packets when
'twice' is used, and to validate every 16'th packet as recommended in RFC2508,
Section 3.3.5.
A new flag in the FULL_HEADER packet, as specified below, indicates when set Note that the decompressor fails not when a packet is lost, but when
that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will the next compressed packet arrives. If the next packet happens to
have HDRCKSUM inserted. If a packet in the same stream subsequently arrives at include the same context update as in the lost packet, the context
the compressor with a UDP checksum present, then a new FULL_HEADER packet must at the decompressor may be updated successfully and decompression
be sent with the flag cleared to re-establish the context. may continue uninterrupted. If the lost packet included an update to
a delta field such as the delta RTP timestamp (dT), the next packet
can't compensate for the loss since the update of a delta value is
relative to the previous packet which was lost. But if the update is
for an absolute value such as the full RTP timestamp or the RTP
payload type, this update can be repeated in the next packet
independently of the lost packet. Hence it is useful to be able to
update the absolute values of the context.
The HDRCKSUM is calculated in the same way as a UDP checksum, but includes only The next chapter describes several extensions to CRTP that add the
the pseudo-IP header (as defined for UDP), the IP ID (as in Section 2.3), the capability to selectively update absolute values of the context,
UDP header and for COMPRESSED_RTP packets, the fixed part of the RTP header rather than sending a FULL_HEADER packet, in addition to the
(first 12 bytes). The extended part of the RTP header and the RTP data will not existing updates of the delta values. This enhanced version of CRTP
be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or is intended to minimize context invalidation and thus improve the
COMPRESSED_RTP packets where a UDP checksum would have been. performance over lossy links with a long round trip time.
The decompressor MUST zero out the UDP checksum field in the reconstructed
packets.
The HDRCKSUM does not validate the RTP data. If the link layer is configured to 1.4 Specification of Requirements
deliver packets without checking for errors, errors in the RTP data will not be
detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP
checksum is not present, and the decompressor SHOULD validate each reconstructed
packet to make sure that at least the headers are correct. This ensures that the
packet will be delivered to the right destination. If only HDRCKSUM is
available, the RTP data will be delivered even if it includes errors.
This might be a desirable feature for applications that can tolerate errors in
the RTP data. Same holds for the extended part of the RTP header.
Here is the format of the FULL_HEADER length fields with the new flag that The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
indicates that a header checksum will be added in COMPRESSED_UDP and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
COMPRESSED_RTP packets: document are to be interpreted as described in [RFC2119].
For 8-bit context ID: 2. Enhanced CRTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This chapter specifies the changes in this enhanced version of CRTP.
|0|1| Generation| CID | First length field They are:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Extensions to the COMPRESSED_UDP packet to allow updating the
| 0 |C|N| seq | Second length field differential RTP values in the decompressor context and to
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added selectively update the absolute IP ID and RTP values. This
allows context sync to be maintained even with some packet
loss.
For 16-bit context ID: - A 'headers checksum' to be inserted by the compressor and
removed by the decompressor when the UDP checksum is not
present so that validation of the decompressed headers is
still possible. This allows the decompressor to verify that
context sync has not been lost after a packet loss.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An algorithm is then described to use these changes with repeated
|1|1| Generation| 0 |C|N| seq | First length field updates to achieve robust operation over links with packet loss and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added long delay.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1 Extended COMPRESSED_UDP packet
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5 Enhancement to COMPRESSED_UDP packet format (CU*) It is possible to accommodate some packet loss between the
compressor and decompressor using the "twice" algorithm in RFC 2508
so long as the context remains in sync. This requires reliably
communicating both the absolute value and the delta value whenever
the delta value changes. For many environments, sufficient
reliability can be achieved by repeating the update with each of
several successive packets.
The COMPRESSED_UDP packet includes the whole RTP header, so it can restore all The COMPRESSED_UDP packet satisfies the need to communicate the
RTP-related parameters at the decompressor. It is also specified to reset the absolute values of the differential RTP fields, but it is specified
delta RTP timestamp to zero and the delta RTP sequence number to zero.It can in RFC 2508 to reset the delta RTP timestamp. That limitation can be
also convey a new value for the delta IP ID. removed with the following simple change: RFC 2508 describes the
format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except
that the M, S and T bits are always 0 and the corresponding delta
fields are never included. This enhanced version of CRTP changes
that specification to say that the T bit may be nonzero to indicate
that the delta RTP timestamp is included explicitly rather than
being reset to zero.
It is possible to accommodate some packet loss between the compressor and A second change adds another byte of flag bits to the COMPRESSED_UDP
decompressor using the "twice" algorithm in RFC 2508, but this requires reliably packet to allow only selected individual uncompressed fields of the
communicating the absolute values and the deltas for the differential fields. RTP header to be included in the packet rather than carrying the
The reliability of communication of the absolute values in the RTP header can be full RTP header as part of the UDP data. The additional flags do
increased by sending a COMPRESSED_UDP packet repeatedly, but this resets the increase computational complexity somewhat, but the corresponding
delta timestamp. increase in bit efficiency is important when the differential field
RFC 2508 describes the format of COMPRESSED_UDP as being the same as updates are communicated multiple times in successive COMPRESSED_UDP
COMPRESSED_RTP except that the M, S and T bits are always 0 and the packets. With this change, there are flag bits to indicate
corresponding delta fields are never included. This enhancement changes that inclusion of both delta values and absolute values, so the flag
specification to say that the T bit may be nonzero to indicate that the RTP nomenclature is changed. The original S, T, I bits which indicate
timestamp delta is included explicitly rather than being reset to zero. the inclusion of deltas are renamed dS, dT, dI, and the inclusion of
absolute values is indicated by S, T, I. The M bit is absolute as
before. A new flag P indicates inclusion of the absolute RTP payload
type value and, as in the COMPRESSED_RTP packet, a four-bit CC field
copies the absolute value of the CC field in the RTP header.
Sometimes it is necessary to change just a few fields of the RTP header. A The last of the three changes to the COMPRESSED_UDP packet deals
second part of this enhancement adds more flag bits to the COMPRESSED_UDP packet with updating the IP ID field. For this field, the COMPRESSED_UDP
to select individual uncompressed fields of the RTP header to be included in the packet as specified in RFC 2508 can already convey a new value for
packet. Since there are flag bits to indicate inclusion of both delta values the delta IP ID, but not the absolute value which is only conveyed
and absolute values, the flag nomenclature is changed. The original S,T,I bits by the FULL_HEADER packet. Therefore, a new flag I is added to the
which indicate the inclusion of deltas are renamed dS, dT, dI, and the inclusion COMPRESSED_UDP packet to indicate inclusion of the absolute IP ID
of absolute values is indicated by S,T,I. The M bit is absolute as before. value. The I flag replaces the dS flag which is not needed in the
COMPRESSED_UDP packet since the delta RTP sequence number always
remains 1 in the decompressor context and hence does not need to be
updated.
The format of the flags/sequence byte for the original COMPRESSED_UDP packet is The format of the flags/sequence byte for the original
shown here for reference: COMPRESSED_UDP packet is shown here for reference:
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |dI | link sequence | | 0 | 0 | 0 |dI | link sequence |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
The new definition of the flags/sequence byte plus an extension flags byte is as The new definition of the flags/sequence byte plus an extension
follows, where the new F flag indicates the inclusion of the extension flags flags byte for the COMPRESSED_UDP packet is as follows, where the
byte: new F flag indicates the inclusion of the extension flags byte:
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence | | F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
: M : S : T :pt : CC : (if F = 1) : M : S : T : P : CC : (if F = 1)
+...+...+...+...+...............+ +...+...+...+...+...............+
dI = delta IP ID dI = delta IP ID
dT = delta RTP timestamp dT = delta RTP timestamp
I = absolute IP ID I = absolute IP ID
F = additional flags byte F = additional flags byte
M = marker bit M = marker bit
S = absolute RTP sequence number S = absolute RTP sequence number
T = absolute RTP timestamp T = absolute RTP timestamp
pt = RTP payload type P = RTP payload type
CC = number of CSRC identifiers CC = number of CSRC identifiers
When F=0, there is only one flags byte, and the only available flags
are: dI, dT and I. In this case the packet includes the full RTP
header. As in RFC 2508, if dI=0, the decompressor does not change
deltaI. If dT=0, the decompressor sets deltaT to 0.
Some short notations: Some example packet formats will illustrate the use of the new
flags. First, when F=0, the 'traditional' COMPRESSED_UDP packet
FH FULL_HEADER which carries the full RTP header as part of the UDP data:
CR COMPRESSED_RTP
CR+ COMPRESSED_RTP with delta fields
CU COMPRESSED_UDP
CU* enhanced COMPRESSED_UDP
When F=0, there is only one flags byte, and the only available flags are: dI, dT
and I.
In this case the packet includes the full RTP header
If dT=0, the decompressor sets deltaT to 0
If dI=0, the decompressor sets deltaI to 1
Some example packet formats will illustrate the use of the new flags. First, a
'traditional' COMPRESSED_UDP with full RTP header, when F=0:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+...............................+ +...............................+
: msb of session context ID : (if 16-bit CID) : msb of session context ID : (if 16-bit CID)
+-------------------------------+ +-------------------------------+
| lsb of session context ID | | lsb of session context ID |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|F=0| I |dT |dI | link sequence | |F=0| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
: : : :
skipping to change at line 1256 skipping to change at line 306
+...............................+ +...............................+
: delta RTP timestamp : (if dT = 1) : delta RTP timestamp : (if dT = 1)
+...............................+ +...............................+
: : : :
+ IPv4 ID + (if I = 1) + IPv4 ID + (if I = 1)
: : : :
+...............................+ +...............................+
| UDP data | | UDP data |
: (uncompressed RTP header) : : (uncompressed RTP header) :
When F=1, there is an additional flags byte and the available flags are: dI, dT, When F=1, there is an additional flags byte and the available flags
I, M, S, T, pt, CC. In this case the packet does not include the full RTP are: dI, dT, I, M, S, T, P, CC. In this case the packet does not
header, but includes selected fields from the RTP header as specified by the include the full RTP header, but includes selected fields from the
flags. The delta values of the context are not reset even if they are not RTP header as specified by the flags. As in RFC 2508, if dI=0 the
specified in the packet: decompressor does not change deltaI. However, in contrast to RFC
If dT=0, the decompressor KEEPS THE CURRENT deltaT 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the
(and DOES NOT set the deltaT to 0) context (DOES NOT set deltaT to 0).
If dI=0, the decompressor KEEPS THE CURRENT deltaI
(and DOES NOT set the the deltaI to 1)
A CU* packet is similar in contents and behavior to a CR packet, but it has more An enhanced COMPRESSED_UDP packet is similar in contents and
flag bits, some of which correspond to absolute values for RTP header fields. behavior to a COMPRESSED_RTP packet, but it has more flag bits, some
of which correspond to absolute values for RTP header fields.
COMPRESSED_UDP with individual RTP fields, when F=1 : COMPRESSED_UDP with individual RTP fields, when F=1 :
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+...............................+ +...............................+
: msb of session context ID : (if 16-bit CID) : msb of session context ID : (if 16-bit CID)
+-------------------------------+ +-------------------------------+
| lsb of session context ID | | lsb of session context ID |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|F=1| I |dT |dI | link sequence | |F=1| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
: M : S : T :pt : CC : | M | S | T | P | CC |
+...+...+...+...+...............+ +---+---+---+---+---------------+
: : : :
+ UDP checksum + (if nonzero in context) + UDP checksum + (if nonzero in context)
: : : :
+...............................+ +...............................+
: : : :
: "RANDOM" fields : (if encapsulated) : "RANDOM" fields : (if encapsulated)
: : : :
+...............................+ +...............................+
: delta IPv4 ID : (if dI = 1) : delta IPv4 ID : (if dI = 1)
+...............................+ +...............................+
skipping to change at line 1309 skipping to change at line 358
: : : :
+...............................+ +...............................+
: : : :
+ + + +
: : : :
+ RTP timestamp + (if T = 1) + RTP timestamp + (if T = 1)
: : : :
+ + + +
: : : :
+...............................+ +...............................+
: RTP payload type : (if pt = 1) : RTP payload type : (if P = 1)
+...............................+ +...............................+
: : : :
: CSRC list : (if CC > 0) : CSRC list : (if CC > 0)
: : : :
+...............................+ +...............................+
: : : :
: RTP header extension : (if X set in context) : RTP header extension : (if X set in context)
: : : :
+-------------------------------+ +-------------------------------+
| | | |
/ RTP data / / RTP data /
/ / / /
| | | |
+-------------------------------+ +-------------------------------+
: padding : (if P set in context) : padding : (if P set in context)
+...............................+ +...............................+
Usage for the enhanced COMPRESSED_UDP packet:
Usage for the CU* packet: It is useful for the compressor to periodically refresh the state of
the decompressor to avoid having the decompressor send CONTEXT_STATE
It is useful for the compressor to periodically refresh the state of the messages in the case of unrecoverable packet loss. Using the flags
decompressor to avoid having the decompressor send CONTEXT_STATE messages in the F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the
case of unrecoverable packet loss. context parameters.
Using the flags F=0 I dI dT, this CU* packet refreshes all the context
parameters.
When compression is done over a lossy link with a long round trip delay, we want
to minimize context invalidation. If the delta values are changing frequently,
the context might get invalidated often. In such cases the compressor may choose
to include absolute values in the CRTP packets instead of delta values, using
CU* packets with the flags: F=1, and any of S, T, I as necessary.
4.6 Acknowledgement packet (ACK packet)
The ACK packet will be sent from decompressor to compressor to indicate receipt
of a compressed packet with the ACK'd RTP sequence number.
It's a CONTEXT_STATE packet with type codes 4 and 5. The ACK packet is to be
used in a separately negotiated mode of operation as described in the next
section.
Type code = 4 : ACK a packet of a context with 8-bit CID
Type code = 5 : ACK a packet of a context with 16-bit CID
The format for the ACK packet is:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Type code=4: ACK, 8-bit CID |
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| |
+ RTP sequence number +
| |
+---+---+---+---+---+---+---+---+
. . .
+---+---+---+---+---+---+---+---+
| session context ID |
+---+---+---+---+---+---+---+---+
| |
+ RTP sequence number +
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Type code=5: ACK, 16-bit CID |
+---+---+---+---+---+---+---+---+
| context count |
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| |
+ RTP sequence number +
| |
+---+---+---+---+---+---+---+---+
. . .
+---+---+---+---+---+---+---+---+
| |
+ session context ID +
| |
+---+---+---+---+---+---+---+---+
| |
+ RTP sequence number +
| |
+---+---+---+---+---+---+---+---+
4.6.1 CRTP operation in ACK mode
This mode of operation is optional and must be negotiated per link.
4.6.1.1 Description of the ACK mode
The ACK mode is a mode of operation in which the compressor and decompressor When compression is done over a lossy link with a long round trip
continuously verify that their context states are synchronized. The compressor delay, we want to minimize context invalidation. If the delta values
repeatedly notifies the decompressor about changes in the context state, until are changing frequently, the context might get invalidated often. In
the decompressor acknowledges reception of the changes by sending ACK packets to such cases the compressor may choose to always send absolute values
the decompressor. and never delta values, using COMPRESSED_UDP packets with the flags
This effort of synchronizing the context states helps minimize context F=1, and any of S, T, I as necessary.
invalidation.
The context state shared between the compressor and decompressor includes all 2.2 CRTP Headers Checksum
the fields of the uncompressed headers and the first order differences (delta
fields) of the fields that change by a constant value from packet to packet.
Each field follows its known change pattern: either stays constant or is
incremented by its corresponding delta field. Fields that follow their change
pattern are compressed. They are reconstructed by the decompresor from the
context state at the decompressor. Correct decompression of a packet depends on
whether the context state at the compressor when the packet is compressed and
sent is identical to the context state at the decompressor when that packet is
received and decompressed.
When a field changes in a way that is different from its change pattern, the RFC 2508, in Section 3.3.5, describes how the UDP checksum may be
compressor assigns a new value to the field, and stores it in the context state used to validate header reconstruction periodically or when the
at the compressor side. The decompressor must be informed about the change so 'twice' algorithm is used. When a UDP checksum is not present (has
that it can update the state on its side to match the state at the compressor. value zero) in a stream, such validation would not be possible. To
The compressor notifies the decompressor about such changes by including cover that case, this enhanced CRTP provides an option whereby the
information about the changed field in the compressed packet. (for example if dT compressor MAY replace the null UDP checksum with a 16-bit headers
was assigned a new value, the compressor can send a CR+ packet that includes checksum (HDRCKSUM) which is subsequently removed by the
dT). The context is not synchronized until the decompressor receives the packet decompressor after validation.
that includes the changed field and updates its state accordingly.
The decompressor indicates reception of the change by sending an ACK packet to A new flag C in the FULL_HEADER packet, as specified below,
the compressor. The ACK packet includes the RTP sequence number of the packet indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP
that it is ACK'ing, so the compressor can identify which packet is ACK'd. The packets sent in that context will have HDRCKSUM inserted. The
compressor can't assume that the decompressor received the change until the ACK compressor MAY set the C flag when UDP packet carried in the
packet is received. FULL_HEADER packet originally contained a checksum value of zero.
If the C flag is set, the FULL_HEADER packet itself MUST also have
the HDRCKSUM inserted. If a packet in the same stream subsequently
arrives at the compressor with a UDP checksum present, then a new
FULL_HEADER packet MUST be sent with the flag cleared to re-
establish the context.
Depending on the round trip delay of the link, the compressor might have to send The HDRCKSUM is calculated in the same way as a UDP checksum except
a few more packets before the ACK from the decompressor arrives. In this case that it does not cover all of the UDP data. That is, the HDRCKSUM is
the compressor must repeat the change in all subsequent packets. Reception of the 16-bit one's complement of the one's complement sum of the
the ACK is an indication that the decompressor updated its context with the pseudo-IP header (as defined for UDP), the UDP header, and the first
changed value. Now that their contexts are synchronized again, the compressor 12 bytes of the UDP data which are assumed to hold the fixed part of
can stop including the changed field in the compressed packets. an RTP header. The extended part of the RTP header and the RTP data
will not be included in the HDRCKSUM. The HDRCKSUM is placed in the
COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would
have been. The decompressor MUST zero out the UDP checksum field in
the reconstructed packets.
The decompressor must be able to recognize the repeat packets (the packets that For a non-RTP context, there may fewer than 12 UDP data bytes
repeat the same change and were sent while the compressor was waiting for the present. The IP and UDP headers may still be compressed into a
ACK packet). Those repeat packets don't require an ACK. COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated
over the pseudo-IP header, the UDP header, and the UDP data bytes
that are present. If the number of data bytes is odd, then a zero
padding byte is appended for the purpose of calculating the
checksum, but not transmitted.
If in the process of changing some fields additional changes are required, the The HDRCKSUM does not validate the RTP data. If the link layer is
compressor will switch to send packets that include all changes. The configured to deliver packets without checking for errors, then
decompressor must ACK one of the packets that include all the changes. errors in the RTP data will not be detected. Over such links, the
compressor SHOULD add the HDRCKSUM if a UDP checksum is not present,
and the decompressor SHOULD validate each reconstructed packet to
make sure that at least the headers are correct. This ensures that
the packet will be delivered to the right destination. If only
HDRCKSUM is available, the RTP data will be delivered even if it
includes errors. This might be a desirable feature for applications
that can tolerate errors in the RTP data. The same holds for the
extended part of the RTP header.
The compressor and decompressor must be in full agreement about which packets Here is the format of the FULL_HEADER length fields with the new
must be ACK'd: packets that include changes are larger in size, and if they are flag C to indicate that a header checksum will be added in
not ACK'd, the changes are repeated in all subsequent packets, and bandwidth is COMPRESSED_UDP and COMPRESSED_RTP packets:
wasted.
Let's summarize which packets require an ACK: For 8-bit context ID:
1. A Packet that assigns a value to any context state field must be ACK'd. This +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
includes FH and CU packets because they initialize fields in the context |0|1| Generation| CID | First length field
state. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. Repeat packets don't require an ACK
How are repeat packets identified? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |C| seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
A packet is considered to be a repeat packet if: For 16-bit context ID:
1. It updates the same fields as the previous packet
2. Each field is updated by a value that is equal to the one assigned to this
field in the previous packet plus the corresponding delta for this field,
when applicable.
4.6.1.2 The Random IP ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |C| seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
The IP ID change pattern is to be incremented by dI. In some implementations, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the IP ID counter is shared across multiple streams, so as a result of the | CID | Second length field
varying mix of packets the increment for any particular stream is not constant. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When compressing such a stream, the compressor must include in each packet
either dI or I. It is recommended to include I rather then dI because a loss of
a packet that includes a new delta value dI will invalidate the context.
According to the rules set above, each packet will have to be ACK'd.
To correct this we'll define a new change pattern for the IP ID: random value. 2.3 CRTP operation in 'N' mode
The IP ID assumes this change pattern when dI is set to be 0.
We add a rule to the ACK rules: The 'N' mode is a method of operation where the compressor tries to
3. When the value of dI is 0, packets that update only the IP ID field don't keep the decompressor in sync by sending changes multiple times. The
require an ACK. 'N' is a number that represents the quality of the link between the
hosts, and it means that the probability of more than N adjacent
packets getting lost on this link is small. For every change in a
full value or a delta value, if the compressor includes the change
in N+1 consecutive packets, there is a very good chance that the
compressor and decompressor can stay in sync using the 'twice'
algorithm. CONTEXT_STATE packets should also be repeated N+1 times
(using the same sequence number). It is up to the implementation to
find a scheme to derive an appropriate N for a link.
And add to rule 2 of the repeat packet rules: This scheme may be used at any time and does not require
2. Each field is updated by a value that is equal to the one assigned to this negotiation.
field in the previous packet plus the corresponding delta for this field, when
applicable. An exception to this rule is the IP ID field: if the value of dI is
0, the IP ID may be assigned any value.
4.6.1.3 Implementation hints when using the ACK scheme Some short notations:
1. When a delta field is updated, add the matching absolute field too (dT and T, FH FULL_HEADER
dI and I). Loss of a packet that updates only the delta value can easily CR COMPRESSED_RTP
cause context invalidation. CU COMPRESSED_UDP
2. Set dI=0 when the IP ID is changing randomly, and include I in all packets.
3. If you ACK'd a packet, but the number of repeat packets exceed your estimate,
ACK again (your previous ACK was probably lost)
Here is an example to demonstrate the usage of the ACK scheme. Here is an example to demonstrate the usage of the N scheme.
In this stream the audio codec sends a sample every 10 msec In this stream the audio codec sends a sample every 10 milliseconds
The first talk spurt is 1 second long. Then there are 2 seconds silence, then The first talkspurt is 1 second long. Then there are 2 seconds of
another talk spurt. silence, then another talkspurt. We also assume in this example that
the IP ID field does not increment at a constant rate because the
host is generating other uncorrelated traffic streams at the same
time and therefore the delta IP ID changes for each packet.
When there is no loss on the link, we can use the following sequence: When there is no loss on the link, we can use COMPRESSED_RTP packets
(The deltaID is not constant so we send deltaID in each packet) in the following sequence:
seq# Time pkt type seq Time pkt updates and comments
# type
1 10 FH 1 10 FH
2 20 CR+ dI dT=10 2 20 CR dI dT=10
3 30 CR+ dI 3 30 CR dI
4 40 CR+ dI 4 40 CR dI
... ...
100 1000 CR+ dI 100 1000 CR dI
101 3010 CR+ dI dT=2010 101 3010 CR dI dT=2010
102 3020 CR+ dI dT=10 102 3020 CR dI dT=10
103 3030 CR+ dI 103 3030 CR dI
104 3040 CR+ dI 104 3040 CR dI
... ...
In the above sequence if a packet is lost, we cannot recover ('twice' will not
work due to the random IP ID) and the context must be invalidated.
Here is the same sequence using the ACK scheme(CU* is the enhanced CU): In the above sequence, if a packet is lost we cannot recover
('twice' will not work due to the unpredictable IP ID) and the
context must be invalidated.
seq# Time pkt type flags Here is the same example in 'N' mode, when N=2. Note that the
1 10 FH FH must be ACK'd compressor only sends the absolute IP ID (I) and not the delta IP ID
2 20 FH repeat (dI).
ACK 1
3 30 CU* 1 I dT dI M 0 T 0 I T=30 dT=10 dI=0 dI,dT changed seq Time pkt CU flags updates and comments
(packet 3 was lost) (I and T sent too) # type F I dT dI M S T P
4 40 CU* 1 I dT dI M 0 T 0 I T=40 dT=10 dI=0 repeat 1 10 FH
5 50 CU* 1 I dT dI M 0 T 0 I T=50 dT=10 dI=0 repeat 2 20 FH repeat constant fields
6 60 CU* 1 I dT dI M 0 T 0 I T=60 dT=10 dI=0 repeat 3 30 FH repeat constant fields
ACK 4 == got new dI=0 and dT=10 at T=40. 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10
dI was set to 0, so I does not require an ACK. 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT
No need to ACK 5 and 6: repeat packets 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT
7 70 CU* 1 I 0 0 M 0 0 0 I 7 70 CU 1 1 0 0 M 0 0 0 I
8 80 CU* 1 I 0 0 M 0 0 0 I 8 80 CU 1 1 0 0 M 0 0 0 I
... ...
100 1000 CU* 1 I 0 0 M 0 0 0 I 100 1000 CU 1 1 0 0 M 0 0 0 I
101 3010 CU* 1 I 0 0 M 0 T 0 I T=3010 T changed, keep deltas! 101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas
102 3020 CU* 1 I 0 0 M 0 T 0 I T=3020 repeat 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T
ACK 101 == got new T at sequence 101 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T
No need to ACK packet 102 because 3010 + dT = 3020 104 3040 CU 1 1 0 0 M 0 0 0 I
If 101 is lost, 102 will be ACK'd 105 3050 CU 1 1 0 0 M 0 0 0 I
103 3030 CU* 1 I 0 0 M 0 0 0 I
104 3040 CU* 1 I 0 0 M 0 0 0 I
... ...
The same sequences, when delta IP ID is constant: This second example is the same sequence, but assuming the delta IP
ID is constant. First the basic CRTP for a lossless link:
seq# Time pkt type seq Time pkt updates and comments
# type
1 10 FH 1 10 FH
2 20 CR+ dI dT=10 2 20 CR dI dT=10
3 30 CR 3 30 CR
4 40 CR 4 40 CR
... ...
100 1000 CR 100 1000 CR
101 3010 CR+ dT=2010 101 3010 CR dT=2010
102 3020 CR+ dT=10 102 3020 CR dT=10
103 3030 CR
104 3040 CR
...
seq# Time pkt type flags
1 10 FH FH must be ACK'd
2 20 FH repeat
ACK 1
3 30 CU* 1 I dT dI M 0 T 0 I dI T=30 dT=10 dI,dT changed
(packet 3 was lost) (I and T sent too)
4 40 CU* 1 I dT dI M 0 T 0 I dI T=40 dT=10 repeat
5 50 CU* 1 I dT dI M 0 T 0 I dI T=50 dT=10 repeat
6 60 CU* 1 I dT dI M 0 T 0 I dI T=60 dT=10 repeat
ACK 4 == got new dI and dT=10 at T=40.
No need to ACK 5 and 6: no changes
7 70 CR
8 80 CR
...
100 1000 CR
101 3010 CU* 1 0 0 0 M 0 T 0 T=3010 T changed, keep deltas!
102 3020 CU* 1 0 0 0 M 0 T 0 T=3020 repeat
ACK 101 == got new T at sequence 101
No need to ACK packet 102 because 3010 + dT = 3020
If 101 is lost, 102 will be ACK'd
103 3030 CR 103 3030 CR
104 3040 CR 104 3040 CR
... ...
4.7 Accept a new compressed stream For the equivalent sequence in 'N' mode, the more efficient
COMPRESSED_RTP packet can still be used once the deltas are all
Lack of any feedback from the decompressor might indicate either that everything established:
goes well (the stream is decompressed successfully), or that nothing goes well
(the link is down, the decompressor is not functioning, the decompressor is out
of sync but there is no back channel). The compressor initiates a compression of
a stream by sending a FULL_HEADER packet. This enhancement specifies that the
decompressor SHOULD acknowledge the reception of the FULL_HEADER packet by
sending an ACK packet (see 2.6) with the sequence number of the FULL_HEADER
packet. This reassures the compressor that the new compressed stream is received
and decompressed. It also indicates that a back channel exists.
4.8 CRTP operation in 'N' mode
This scheme is similar to the ACK scheme in that the compressor tries to keep
the decompressor in sync by sending changes multiple times. The 'N' is a number
that represents the quality of the link between the hosts, and it means that the
probability of more than 'N' adjacent packets getting lost on this link is
small. For every change in a base value or a delta value, if the compressor
includes the change in N+1 consecutive packets, there is a very good chance that
the compressor and decompressor can stay in sync using the 'twice' algorithm.
CONTEXT_STATE packets should also be repeated N+1 times (using the same sequence
number).
It is up to the implementation to find a scheme to derive an appropriate N for a
link.
This scheme may be used at any time and does not require negotiation.
Here is the same example in 'N' mode, when N=2 and deltaID is constant:
seq# Time pkt type flags seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH 1 10 FH
2 20 FH repeat constant fields 2 20 FH repeat constant fields
3 30 FH repeat constant fields 3 30 FH repeat constant fields
4 40 CU* 1 I dT dI M 0 T 0 I dI T=40 dT=10 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10
5 50 CU* 1 I dT dI M 0 T 0 I dI T=50 dT=10 repeat delta 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates
6 60 CU* 1 I dT dI M 0 T 0 I dI T=60 dT=10 repeat delta 6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates
7 70 CR 7 70 CR
8 80 CR 8 80 CR
... ...
100 1000 CR 100 1000 CR
101 3010 CU* 1 0 0 0 M 0 T 0 T=3010 T changed, keep deltas! 101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas
102 3020 CU* 1 0 0 0 M 0 T 0 T=3020 repeat updated T 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T
103 3030 CU* 1 0 0 0 M 0 T 0 T=3030 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T
104 3040 CR 104 3040 CR
105 3050 CR 105 3050 CR
... ...
4.9 Select mode of operation 3. Negotiating usage of enhanced-CRTP
As link conditions change, it might be necessary to change the mode of operation
from N mode to ACK mode and vice versa. Mode changes are initiated by the
compressor and acknowledged by the decompressor. When acknowledging a request to
move to N mode, the decompressor may suggest a different N to use (for example
based on loss patterns seen by the decompressor).
The decompressor may send multiple acknowledgement packets to one request
packet, e.g. send an ACK-Nmode packet when the decompressor suggests to change
the N that is currently being used.
The compressor determines the N to be used, and it MAY be different than the
value of the parameter N in the REQ-Nmode and ACK-Nmode packets exchanged
between the compressor and decompressor.
If the compressor receives an ACK packet that does not match the current mode,
the compressor SHOULD send another REQ packet to set the right mode. Hence the
compressor can use any of the ACK packets to verify the current mode: if the ACK
does not match the current mode, the compressor will send a REQ to set the mode.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+---+---+
| Type code=6: Select operation mode |
+---+---+---+---+---+---+---+---+---+---+
| Opcode |
+---+---+---+---+---+---+---+---+---+---+
: Parameter :
+.......................................+
Opcode Mnemonic Description Parameter
1 REQ-Nmode Request to move to N mode N to be used
2 ACK-Nmode Acknowledge move to N mode N to be used
3 REQ-ACKmode Request to move to ACK mode none
4 ACK-ACKmode Acknowledge move to ACK mode none
4.10 Negotiating usage of enhanced-CRTP and ACK scheme
RFC 2509 [IPCPHP] specifies how the use of CRTP is negotiated on PPP links using RFC 2509 [IPCPHC] specifies how the use of CRTP is negotiated on PPP
the IP Compression Protocol option of IPCP: links using the IP Compression Protocol option of IPCP:
IPCP option 2: IP compression protocol IPCP option 2: IP compression protocol
protocol 0x61 indicates RFC 2507 header compression protocol 0x61: indicates RFC 2507 header compression
sub-option 1 enables use of COMPRESSED_RTP, COMPRESSED_UDP and sub-option 1: enables use of COMPRESSED_RTP, COMPRESSED_UDP
CONTEXT_STATE as specified in RFC 2508 and CONTEXT_STATE as specified in RFC 2508
For the enhancements defined in this document, two new sub-options are added:
sub-option 2 (length=2) : enables use of CRTP with
enhancements 4.1 - 4.5 and 4.7
(all except ACK mode)
sub-option 3 (length=2) : enables use of CRTP with
enhancements 4.1 - 4.7 (ACK scheme)
5. Interaction With Segmentation
A segmentation scheme may be used in conjunction with RTP header
compression to allow small, real-time packets to interrupt large,
presumably non-real-time packets in order to reduce delay. It is
assumed that the large packets bypass the compressor and decompressor
since the interleaving would modify the sequencing of packets at the
decompressor and cause the appearance of errors. Header compression
should be less important for large packets since the overhead ratio
is smaller.
If some packets from an RTP session context are selected for
segmentation (perhaps based on size) and some are not, there is a
possibility of re-ordering. This would reduce the compression
efficiency because the large packets would appear as lost packets in
the sequence space. However, this should not cause more serious
problems because the RTP sequence numbers should be reconstructed
correctly and will allow the application to correct the ordering.
Link errors detected by the segmentation scheme using its own
sequencing information MAY be indicated to the compressor with an
advisory CONTEXT_STATE message just as for link errors detected by
the link layer itself.
The context ID byte is placed first in the COMPRESSED_RTP header so
that this byte MAY be shared with the segmentation layer if such
sharing is feasible and has been negotiated. Since the compressor
may assign context ID values arbitrarily, the value can be set to
match the context identifier from the segmentation layer.
6. Negotiating Compression
The use of IP/UDP/RTP compression over a particular link is a
function of the link-layer protocol. It is expected that such
negotiation will be defined separately for PPP [4], for example. The
following items MAY be negotiated:
o The size of the context ID.
o The maximum size of the stack of headers in the context.
o A context-specific table for decoding of delta values.
o Using CRTP enhancements.
7. Acknowledgments
Several people have contributed to the design of this compression
scheme and related problems. Scott Petrack initiated discussion of
RTP header compression in the AVT working group at Los Angeles in
March, 1996. Carsten Bormann has developed an overall architecture
for compression in combination with traffic control across a low-
speed link, and made several specific contributions to the scheme
described here. David Oran independently developed a note based on
similar ideas, and suggested the use of PPP Multilink protocol for
segmentation. Mikael Degermark has contributed advice on integration
of this compression scheme with the IPv6 compression framework.
8. References: To use the enhanced CRTP defined in this document, a new sub-option
2 is added. The new sup-option 2 is negotiated instead of, not in
addition to, sub-option 1.
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: Description
A Transport Protocol for real-time applications", RFC 1889,
January 1996.
[2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", Enable use of Protocol Identifiers COMPRESSED_RTP and
RFC 1144, February 1990. CONTEXT_STATE as specified in RFC 2508 plus COMPRESSED_UDP with
additional flags as defined in this document, and enable use of
the C flag with the FULL_HEADER Protocol Identifier as defined in
this document to indicate use of HDRCKSUM with COMPRESSED_RTP and
COMPRESSED_UDP packets.
[3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for 0 1
IPv6", RFC 2507, February 1999. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC Type
1661, July 1994. 2
[5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Length
Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. 2
9. Security Considerations 4. Security Considerations
Because encryption eliminates the redundancy that this compression Because encryption eliminates the redundancy that this compression
scheme tries to exploit, there is some inducement to forego scheme tries to exploit, there is some inducement to forego
encryption in order to achieve operation over a low-bandwidth link. encryption in order to achieve operation over a low-bandwidth link.
However, for those cases where encryption of data and not headers is However, for those cases where encryption of data and not headers is
satisfactory, RTP does specify an alternative encryption method in satisfactory, RTP does specify an alternative encryption method in
which only the RTP payload is encrypted and the headers are left in which only the RTP payload is encrypted and the headers are left in
the clear. That would allow compression to still be applied. the clear. That would allow compression to still be applied.
A malfunctioning or malicious compressor could cause the decompressor A malfunctioning or malicious compressor could cause the
to reconstitute packets that do not match the original packets but decompressor to reconstitute packets that do not match the original
still have valid IP, UDP and RTP headers and possibly even valid UDP packets but still have valid IP, UDP and RTP headers and possibly
check-sums. Such corruption may be detected with end-to-end even valid UDP check-sums. Such corruption may be detected with
authentication and integrity mechanisms which will not be affected by end-to-end authentication and integrity mechanisms which will not be
the compression. Constant portions of authentication headers will be affected by the compression. Constant portions of authentication
compressed as described in [3]. headers will be compressed as described in [IPHCOMP].
No authentication is performed on the CONTEXT_STATE control packet No authentication is performed on the CONTEXT_STATE control packet
sent by this protocol. An attacker with access to the link between sent by this protocol. An attacker with access to the link between
the decompressor and compressor could inject false CONTEXT_STATE the decompressor and compressor could inject false CONTEXT_STATE
packets and cause compression efficiency to be reduced, probably packets and cause compression efficiency to be reduced, probably
resulting in congestion on the link. However, an attacker with resulting in congestion on the link. However, an attacker with
access to the link could also disrupt the traffic in many other ways. access to the link could also disrupt the traffic in many other
ways.
A potential denial-of-service threat exists when using compression A potential denial-of-service threat exists when using compression
techniques that have non-uniform receiver-end computational load. techniques that have non-uniform receiver-end computational load.
The attacker can inject pathological datagrams into the stream which The attacker can inject pathological datagrams into the stream which
are complex to decompress and cause the receiver to be overloaded and are complex to decompress and cause the receiver to be overloaded
degrading processing of other streams. However, this compression and degrading processing of other streams. However, this
does not exhibit any significant non-uniformity. compression does not exhibit any significant non-uniformity.
A security review of this protocol found no additional security 5. Acknowledgements
considerations.
10. Authors' Addresses The authors would like to thank Van Jacobson, co-author of RFC 2508,
and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and
Stephen Pink. The authors would also like to thank Dana Blair,
Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama,
Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, and
Dan Wing.
Stephen L. Casner 6. References
Packet Design, Inc.
66 Willow Place
Menlo Park, CA 94025
United States of America
Email: casner@acm.org [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC2508, February 1999.
Van Jacobson [IPHCOMP] M. Degermark, B. Nordgren, S. Pink,
Packet Design, Inc. "IP Header Compression", RFC2507, February 1999.
66 Willow Place
Menlo Park, CA 94025
United States of America
EMail: van@packetdesign.com [IPCPHC] M. Engan, S. Casner, C. Bormann,
"IP Header Compression over PPP", RFC2509, February 1999.
[KEYW] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP 14, March 1997.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC1889,
January 1996.
7. Authors' Addresses
Tmima Koren Tmima Koren
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
United States of America United States of America
Email: tmima@cisco.com Email: tmima@cisco.com
Stephen L. Casner
Packet Design
2465 Latham Street, Third Floor
Mountain View, CA 94040
United States of America
Email: casner@acm.org
John Geevarghese John Geevarghese
Telseon Inc, Telseon Inc.
480 S. California 480 S. California
Palo-Alto, CA-94306 Palo Alto, CA 94306
United States of America
Email: geevjohn@hotmail.com Email: geevjohn@hotmail.com
Bruce Thompson Bruce Thompson
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
United States of America United States of America
Email: brucet@cisco.com Email: brucet@cisco.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Email: dwing@cisco.com
Patrick Ruddy Patrick Ruddy
Cisco Systems, Inc. Cisco Systems, Inc.
3rd Floor, 96 Commercial Street 3rd Floor, 96 Commercial Street
Edinburgh Edinburgh
EH6 6LX EH6 6LX
Scotland Scotland
Email: pruddy@cisco.com Email: pruddy@cisco.com
Alex Tweedly 8. Copyright
Cisco Systems, Inc.
3 The Square, Stockley Park
Uxbridge, Middlesex
UB11 1BN
United Kingdom
Email: agt@cisco.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society 1999-2001. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/