RTCP-based Feedback: Concepts and Message Timing Rules
draft-wenger-avt-rtcp-feedback-02
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Stephan Wenger , Joerg Ott | ||
| Last updated | 2009-02-24 (Latest revision 2001-03-08) | ||
| Replaced by | RFC 4585 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-avt-rtcp-feedback | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Real-time media streams are not resilient against packet losses. RTP [1] provides all the necessary mechanisms to restore ordering and timing to properly reproduce a media stream at the recipient. RTP also provides continuous feedback about the overall reception quality from all receivers -- thereby allowing the sender(s) in the mid-term (in the order of several seconds to minutes) to adapt their coding scheme and transmission behavior to the observed network QoS. However, except for a few payload specific mechanisms [2], RTP makes no provision for timely feedback that would allow a sender to repair the media stream immediately: through retransmissions, retro-active FEC, or media-specific mechanisms such as reference picture selection.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)