RFC 7198: Duplicating RTP Streams
In plain English — editorial summary, not part of the RFC
Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.
Document record
- Document ID
- RFC7198
- Published
- April 2014
- Authors
- A. Begen; C. Perkins
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- art
- Pages
- 13
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6853DHCPv6 Redundancy Deployment ConsiderationsCurrent
February 2013
- RFC 5584RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) FamilyCurrent
July 2009
- RFC 7197Duplication Delay Attribute in the Session Description ProtocolCurrent
April 2014
- RFC 7195Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)Current
May 2014
- RFC 7205Use Cases for Telepresence MultistreamsCurrent
April 2014
- RFC 7206Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication NetworksCurrent
May 2014
- RFC 7163URN for Country-Specific Emergency ServicesCurrent
March 2014
- RFC 7160Support for Multiple Clock Rates in an RTP SessionCurrent
April 2014
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?