Duplicating RTP Streams
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, avtext mailing list <firstname.lastname@example.org>, avtext chair <email@example.com> Subject: Protocol Action: 'Duplicating RTP Streams' to Proposed Standard (draft-ietf-avtext-rtp-duplication-06.txt) The IESG has approved the following document: - 'Duplicating RTP Streams' (draft-ietf-avtext-rtp-duplication-06.txt) as Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/
Technical Summary Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. Working Group Summary The document went through a working group last call. There were comments and the document was updated to resolve all comments. The work was originally presented in the AVTCORE working group, but following chair and AD discussion was adopted as a work item of the AVTEXT group instead. Document Quality The document got good reviews from several AVText members, notably Magnus Westerlund, who brought up several important topics about the document's congestion control, and limitations of its source-association mechanisms, which were resolved during working group last call. Ali Begen says that Cisco uses duplicated streams "more or less" according to the guidelines in this document, as do several other implementations from the SMPTE community. Personnel The Document Shepherd is Jonathan Lennox. The Responsible Area Director is Gonzalo Camarillo.