Internet DRAFT - draft-lennox-avt-recoverable-packets
draft-lennox-avt-recoverable-packets
Audio/Video Transport J. Lennox
Internet-Draft Layered Media
Expires: December 21, 2006 June 19, 2006
Marking and Selectively Retransmitting High-Priority Packets in the
Real-Time Transport Protocol (RTP)
draft-lennox-avt-recoverable-packets-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its 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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In some circumstances, it is useful and desirable for the sender of
an RTP stream to be able to deliver a subset of its RTP packets
reliably. One example of this is a video codec which can encode a
video stream such that decoder state can be maintained using just a
subset of the packets encoded. However, existing RTP reliability
mechanisms only define mechanisms which retransmit all the packets of
an RTP stream.
Lennox Expires December 21, 2006 [Page 1]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
This document describes a mechanism by which the sender of an RTP
stream can mark a subset of the packets of an RTP stream as high-
priority recoverable packets, and by which the receiver of the stream
can request retransmission of the high-priority packets.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use of R Packets With Video Streams . . . . . . . . . . . . . 4
5. RTP Header Extension to Indicate R Packets . . . . . . . . . . 5
6. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Analysis of Alternate Approaches . . . . . . . . . . 12
B.1. Generic NACK . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Generic NACK with Codec knowledge . . . . . . . . . . . . 12
B.3. Codec-Specific NACK . . . . . . . . . . . . . . . . . . . 13
B.4. Multiple streams . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Lennox Expires December 21, 2006 [Page 2]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
1. Introduction
In many circumstances, it is useful to allow a subset of the packets
in a Real-Time Transport Protocol (RTP) [RFC3550] media stream to be
transmitted reliably (i.e. that they be retransmitted if they are
lost). However, current mechanisms require either that any lost
packet be retransmitted, or that none are. There is no way for the
sender of an RTP stream to select some packets of a stream to be
retransmittable.
For example, modern flexible video codecs such as H.264
[ITU.H264.2005] allow video streams to be encoded flexibly. Unlike
in earlier video codecs, inter-picture image prediction may be based
not just on an immediately preceding picture, but optionally instead
on earlier pictures transmitted in the video stream. As a result, it
is possible for a video encoder to encode its stream such that in
high packet loss situations, stream state can be maintained or re-
established using only a fraction of the RTP packets transmitted in
the stream. If a media stream experiences transient packet loss, a
decoder can avoid reporting all lost packets, and an encoder does not
need to retransmit all the missed packets, in order for the decoder
to fully re-establish state.
To achieve this desirable property, however, a decoder must be able
to determine, based only on the packets it has received, whether a
packet it has missed was one that it needed to receive reliably to
reestablish stream state. This document describes a payload-format
independent mechanism by which a receiver (or intermediate media-
aware network entity) can quickly determine whether essential packets
have been lost and can request their retransmission.
The mechanism described by this document is also applicable to other
application scenarios -- for example, DTMF [RFC2833] tones in an
audio stream -- in which it is useful for some, but not all, of the
packets in an RTP stream to be transmitted reliably.
Appendix A lists the requirements for this protocol, and Appendix B
evaluates some alternate approaches to the problem described.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
Lennox Expires December 21, 2006 [Page 3]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
3. Overview
When sending a stream of RTP packets, a media sender may choose to
mark a subset of the stream's packets as high-reliability packets.
This subset of the RTP packets is named "R packets," for
"recoverable" packets. Other packets are called "Non-R packets".
An RTP stream can contain several independent series of R packets.
(A given R packet can belong to only one series of R packets). Every
R packet is identified with an R packet sequence number (RSeq),
unique (modulo 2^16) within its series. R packets within a series
are numbered in order, and a receiver detects missing R packets by
noting gaps in the R packet sequence numbers. R packets sequence
numbers are identified using an RTP header extension element, defined
in Section 5.
This header extension element is also used in non-R packets, to
identify the RTP stream's most recently transmitted R packet in each
series. Thus, receivers can detect missing R packets based on non-R
packets as well as R packets. Since R packets can be sent at a
fairly low rate relative to the overall packet sending rate of the
RTP stream, this allows receivers to detect missing R packets much
more quickly. If multiple series of R packets are being sent, R
packet from one series can also identify the most recently sent R
packets from the other active series.
When a receiver detects that it has missed an R packet, it sends an R
packet NACK message (RNACK), described in Section 6, using the RTCP
feedback (AVPF) [I-D.ietf-avt-rtcp-feedback] mechanism. On receiving
an RNACK message, the sender can then retransmit the missing packet.
If a sender determines that some R packets, sent in the past, are no
longer needed by the receiver, it can send a new R packet indicating
that the earlier ones are no longer needed. This R packet is called
a superseding R packet, as receipt of a superseding R packet
indicates that earlier R packets need not be requested by a receiver.
The first R packet of an RTP stream is always encoded such that it
supersedes all the previous (non-existent) R packets in the stream.
4. Use of R Packets With Video Streams
For several video formats, it is possible for a video encoder to
encode and packetize its media so that a subset of the packets of an
RTP [RFC3550] stream are sufficient for a stream decoder to fully
reestablish the correct decoding state.
In order to take advantage of R packets, an encoder periodically
Lennox Expires December 21, 2006 [Page 4]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
encodes a frame (or other unit of the media data) in a way that
either depends on no previous data (an intra-encoded R frame) or that
depends only on previously transmitted R packets (a P-encoded R
frame). Frames transmitted in non-R packets can then reference the
frames encoded in R packets. If transient packet loss occurs, a
decoder need only request retransmission of the R packets it has
missed in order to re-establish decoder state; missed non-R packets
can be safely ignored. Missed R packets are useful (and necessary)
for maintaining the continuity of the media stream. In some cases
even if retransmissions of R packets arrive at the decoder too late
to be played out, the decoder can "fast-forward" through a subset of
the stream in order to catch up to the stream's current playout
point.
It is not necessary to receive every R packet ever transmitted on a
media stream in order to reestablish the stream state. As mentioned,
while some R packets (P frames) depend on previous data transmitted
in a stream, others (intra frames) depend on no previous data and
imply full stream state. Thus, the R packets carrying intra frames
are encoded such that they supersede all the R packets prior to the
first packet of the intra frame.
Furthermore, when an encoder receives a report about a lost R packet,
it is possible for it to decide to encode a fresh R frame (based only
on R frames it believes have been received correctly) rather than
retransmitting the lost packet. This frame's R packets are then
marked as superseding the R packets of the frames which are no longer
used for dependency tracking.
In layered encodings, there can be more than one series of required
packets, e.g. a base-layer I-frame eliminates the need for previous
base-layer long-term reference frames, but not for enhancement-layer
long-term reference frames. In this case, each layer's R frames are
identified by a different R packet series.
5. RTP Header Extension to Indicate R Packets
This section describes the RTP header extension element used to
indicate R packets.
In an RTP stream containing R packets, packets are marked with an RTP
header extension element using the Named RTP Header Extension
mechanism [I-D.ietf-avt-rtp-hdrext].
The R packet header extension element identifies both R packets
themselves and previously-sent R packets. This header extension
element has the name "org.ietf.avt.r-packet/200606". Every R packet
Lennox Expires December 21, 2006 [Page 5]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
includes, and every non-R packet SHOULD include, at least one header
extension element of this form. It MAY occur multiple times in a
header extension if multiple R packet series are in use, but MUST
occur only once for any given series.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len |R| MBZ | SER | RSEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUPERSEDE_START [opt] | SUPERSEDE_END [opt] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: R packet header extension element
The structure of this header extension element is illustrated in
Figure 1. Its fields are defined as follows:
ID: 4 bits The local identifier negotiated for this header extension
element, as defined in [I-D.ietf-avt-rtp-hdrext].
Length (len): 4 bits The length minus one of the data bytes of this
header extension element, not counting the header byte (ID and
len), as defined in [I-D.ietf-avt-rtp-hdrext]. This will have the
value 6 if the second word (the superseded range) is present, and
2 if it is not. Its value MUST either be 2 or 6.
R: 1 bit A bit indicating that the packet containing this header
extension element is an R packet. If this bit is set (1), this
header extension element identifies the current packet as an R
packet in series SER with R sequence number RSEQ. If it is not
set (0), this header extension element instead indicates that the
media stream's most recent R packet in series SER had R sequence
number RSEQ. (This latter case is known as a "mark element".) An
R packet is a packet where exactly one header extension element
has the R bit set, whereas a non-R packet is a packet where no
header header extension element has the R bit set. If this bit is
not set, the superseded range SHOULD NOT be present for that
header extension element (i.e. the len field SHOULD be 2) and MUST
be ignored if present.
Reserved, Must Be Zero (MBZ): 3 bits Reserved bits. These MUST be
set to zero on transmit and ignored on receive.
Series ID (SER): 4 bits An identifier of which series of R packets is
being described by this header extension element. If a media
encoder is describing only a single series of R packets, this
SHOULD have the value 0.
Lennox Expires December 21, 2006 [Page 6]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
R Packet Sequence Number (RSEQ): 16 bits An unsigned sequence number
indicating the number of this R packet within the series SER.
This value is incremented by 1 (modulo 2^16) for every R packet
sent in a given series. RSEQ values for separate series are
independent.
Start of Superseded Range (SUPERSEDE_START): 16 bits The R sequence
number of the earliest R packet, inclusive, superseded by this R
packet, calculated modulo 2^16. (Since this value uses modulo
arithmetic, the value RSEQ + 1 MAY be used for SUPERSEDE_START to
indicate that all R packets prior to the end of the superseded
range have been superseded.) This field is optional, and is only
present when len=6.
End of Superseded Range (SUPERSEDE_END): 16 bits The R sequence
number of the final R packet, inclusive, superseded by this R
packet, calculated modulo 2^16. This value MUST lie in the closed
range [SUPERSEDE_START .. RSEQ] modulo 2^16. This field is
optional, and is only present when len=6.
An RTP packet MAY contain multiple R packet mark elements, so long as
each of these elements has a different value for SER. However, an
RTP MUST NOT contain more than one of these header extension elements
with the R bit set, i.e. an R packet may not belong to more than one
series.
All RTP packets in a media stream using R packets SHOULD include a
mark element for all active series.
When the second word of this header extension element is present, it
indicates that this R packet supersedes some previously-received R
packets, meaning that these packets are no longer necessary in order
to reconstruct stream state. This second word MUST only appear in a
header extension element which has its R bit set.
An R packet can only supersede R packets in the series identified by
the element's SER field. R packets cannot supersede packets in other
series.
It is valid for a supersede element to have SUPERSEDE_END=RSEQ. This
indicates that the R packet supersedes itself, i.e. that this R
packet immediately becomes irrelevant to the stream state. The most
common reason to do this would be to end a series; this can be done
by sending an empty packet (e.g. an RTP No-op
[I-D.ietf-avt-rtp-no-op] packet) with the superseded range
(SUPERSEDE_START, SUPERSEDE_END) = (RSEQ+1, RSEQ), so that the series
no longer contains any non-superseded packets.
The first R packet sent in a series SHOULD be sent with a superseded
range such that SUPERSEDE_START = RSEQ+1, to make it clear that no
Lennox Expires December 21, 2006 [Page 7]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
previous R packets are present in the range.
R packets MAY redundantly include already-superseded packets in their
range of packets to be superseded. If a group of superseding R
packets are sent together (e.g., if a number of packets together
encode an intra frame), they SHOULD all be marked as superseding the
same range of R packets.
6. RTCP Feedback Messages
This section describes the RTCP feedback message used to indicate
that R packets have been lost.
The R Packet Negative Acknowledgement (RNACK) Message is an RTCP
Feedback (AVPF) [I-D.ietf-avt-rtcp-feedback] message identified by
PT=RTPFB and FMT=4 (value tentatively chosen). The FCI field MUST
contain at least one and MAY contain more than one RNACK.
The RNACK packet is used to indicate the loss of one or more R
packets. The lost packet(s) are identified by means of a packet
sequence number, the series identifier, and a bit mask.
The structure and semantics of the RNACK message are similar to that
of the AVPF Generic NACK message.
The RNACK Feedback Control Information (FCI) field has the following
syntax Figure 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSEQ | SER | BLR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Feedback Control Information for R Packet Negative
Acknowledgment (RNACK)
R Packet Sequence Number (RSEQ): 16 bits The RSEQ field indicates a
RSEQ value that the receiver has not received.
Series ID (SER): 4 bits An identifier of which series of R packets is
being described as being lost by this header extension element.
Bitmask of following Lost R Packets (BLR): 12 bits The BLR allows for
reporting losses of any of the 12 R Packets packets immediately
following the RTP packet indicated by RSEQ. Denoting the BLP's
least significant bit as bit 1, and its most significant bit as
bit 12, then bit i of the bit mask is set to 1 if the receiver has
not received R packet number (RSEQ+i) in the series SER (modulo
Lennox Expires December 21, 2006 [Page 8]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
2^16) and indicates this packet is lost; bit i is set to 0
otherwise. Note that the sender MUST NOT assume that a receiver
has received an R packet because its bit mask was set to 0. For
example, the least significant bit of the BLR would be set to 1 if
the packet corresponding to RSEQ and the following R packet in the
series had been lost. However, the sender cannot infer that
packets RSEQ+2 through RSEQ+16 have been received simply because
bits 2 through 15 of the BLR are 0; all the sender knows is that
the receiver has not reported them as lost at this time.
When a receiver detects that it has not received a non-superseded R
packet, it sends an RNACK message as soon as possible, subject to the
rules of RTCP feedback [I-D.ietf-avt-rtcp-feedback]. (In multipoint
scenarios, this includes listening for RNACK packets from other
receivers and not sending an RNACK for a lost R packet that has
already been reported.)
When a sender receives an RNACK packet, it checks whether the packet
has been superseded. If it has not, it retransmits the packet for
which an RNACK was sent (using, e.g., the RTP retransmission payload
[I-D.ietf-avt-rtp-retransmission]). If the packet has been
superseded, it retransmits the most recent packet whose R packet
element indicated a superseded packet range including the packet
requested.
A sender MAY choose to generate and send a new R packet superseding
the one requested in an RNACK, rather than retransmitting a packet
that has been sent previously.
If, after some period of time, a receiver has not received either a
retransmission of the R packet for which an RNACK was sent, or an R
packet superseding that packet, it SHOULD retransmit the RNACK
message. A receiver MUST NOT send RNACK messages more often than
permitted by AVPF. It SHOULD perform estimation of the round-trip
time to the sender, if possible, and SHOULD NOT send RNACK messages
more often than once per round-trip time. (If the receiver is also
acting as an RTP sender, and the sender is sending RTCP reception
reports for the receiver's stream, round-trip times can be inferred
from the sender report's LSR and DLSR fields.) If the round-trip
time is not available, receivers SHOULD NOT send RNACK messages more
often than once per 100 milliseconds. [TODO: this value is a
complete guess.]
7. Security Considerations
All security considerations of RTP [RFC3550] apply here as well.
Lennox Expires December 21, 2006 [Page 9]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
A receiver MUST NOT assume that an R packet bitstream it receives
actually provides complete decoder state; the bitstream MUST still be
validated.
8. IANA Considerations
This document defines an org.ietf RTP header extension element:
'org.ietf.r-packet/200606'. Its format is defined in Section 5 .
This header extension element should be registered by IANA as
described in [I-D.ietf-avt-rtp-hdrext].
This document defines an RTCP transport-layer feedback message:
'RNACK'. Its format is defined in Section 6. It should be defined
in the RTPFB FMT as follows:
Name: RNACK
Long name: R Packet Negative Acknowledgment
Value: 4 (tentatively chosen)
Reference: RFC XXXX.
9. References
9.1. Normative References
[I-D.ietf-avt-rtcp-feedback]
Ott, J. and S. Wenger, "Extended RTP Profile for RTCP-
based Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-11
(work in progress), August 2004.
[I-D.ietf-avt-rtp-hdrext]
Singer, D., "A general mechanism for RTP Header
Extensions", draft-ietf-avt-rtp-hdrext-03 (work in
progress), June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
9.2. Informative References
[I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005.
Lennox Expires December 21, 2006 [Page 10]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
[I-D.ietf-avt-rtp-retransmission]
Rey, J., "RTP Retransmission Payload Format",
draft-ietf-avt-rtp-retransmission-12 (work in progress),
September 2005.
[I-D.ietf-avt-ulp]
Li, A., "RTP Payload Format for Generic Forward Error
Correction", draft-ietf-avt-ulp-17 (work in progress),
March 2006.
[ITU.H264.2005]
International Telecommunications Union, "Advanced video
coding for generic audiovisual services", ITU-
T Recommendation H.264 (2005), ISO Standard 14496-10:2005,
March 2005.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833,
May 2000.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005.
Appendix A. Requirements
This appendix describes the requirements motivating the design of the
protocol described in the rest of this document. (This appendix is
not normative; it thus does not use the formal upper-case versions of
the RFC 2119 [RFC2119] terms for its requirements.)
An encoder must be able to indicate a subset of the packets in a
generated RTP stream as being high-priority (R) packets.
A decoder must be able to determine when it has lost R packets,
whenever any packet of the stream is received, and regardless of the
dependency structure of the encoded stream.
Similarly, a decoder must be able to determine that it has not lost
any R packets as of the latest packet that has been received,
regardless of how many other non-R packets have been lost.
An encoder must be able to split a frame into any number of R
packets, either in a codec-aware manner (e.g. H.264 [ITU.H264.2005]
slices) or a codec-unaware manner (e.g. RFC 3984 [RFC3984]
fragmentation units).
Lennox Expires December 21, 2006 [Page 11]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
An encoder must be able to state that an R packet supersedes previous
R packets, i.e. that some previous R packets are no longer necessary
in order to establish the stream state. This includes both being
able to state that all R packets before a given one have been
superseded, and that a range of R packets are superseded.
It must be possible for an encoder to apply forward error correction
[I-D.ietf-avt-ulp] to its media stream, either to all packets or
selectively only to R packets, in a way that allows R packet state to
be recovered from the FEC stream.
An encoder must be able to describe multiple separate series of R
packets, such that an R packet may supersede all previous R packets
of one series without altering the need for other series. It must
also be able to describe the most recent R packet of multiple series.
Appendix B. Analysis of Alternate Approaches
This appendix describes some alternate approaches that could be
considered to provide a reliable substream of a media stream. It
describes how they fail to satisfy the requirements listed in
Appendix A.
B.1. Generic NACK
This approach uses the Generic NACK mechanism [I-D.ietf-avt-rtcp-
feedback]. A receiver of a stream sends a Generic NACK for every RTP
packet it misses. The stream sender then re-sends only those packets
it knows are needed for the reliable subset of the stream.
In addition to causing many more NACK messages to be sent than are
necessary for the stream, this approach's primary difficulty is that
there is no way for a receiver to know when it should stop sending
NACK messages for those packets which it will not receive.
B.2. Generic NACK with Codec knowledge
This approach is like the previous one, except that decoders track
codec-specific dependency state to infer whether a missed packet was
an R packet or not, and they only send Generic NACK messages for the
packets that they conclude were R packets.
This conclusion is not in general possible, if a receiver misses both
an R packet and a subsequent non-R packet directly dependent on it.
Additionally, if an R frame is fragmented or sliced, a decoder can't
determine which packets were part of the sliced or fragmented R
frame.
Lennox Expires December 21, 2006 [Page 12]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
B.3. Codec-Specific NACK
This approach is also like the previous one, except that decoders
send codec-specific NACK messages (in RPSI messages) listing specific
parts of frames that have been missed.
It is not in general possible to tell whether a missed frame was an R
packet, and the layering mechanisms don't support media-independent
fragmentation (for example RFC 3984 [RFC3984] fragmentation units).
B.4. Multiple streams
In this approach, R packets are sent on a separate RTP session than
the the non-R packets. RTP NACK messages are sent for packets on the
R packet session only.
This approach has the drawback that receipt of a non-R packet does
not trigger a NACK request for a missed R packet; only the next R
packet does that, unless the receiver has knowledge of the sender's
timing of R packets and thus can pro-actively send a NACK for a
packet it does not actually know it has missed. Since R packets tend
to be spaced far apart, this can greatly delay stream recovery.
Lennox Expires December 21, 2006 [Page 13]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
Author's Address
Jonathan Lennox
Layered Media, Inc.
350 W. Passaic St
Fourth Floor
Rochelle Park, NJ 07662
US
Email: jonathan at layeredmedia.com
Lennox Expires December 21, 2006 [Page 14]
Internet-Draft Recoverable High-Priority RTP Packets June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lennox Expires December 21, 2006 [Page 15]