RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    avtext mailing list <avtext@ietf.org>,
    avtext chair <avtext-chairs@ietf.org>
Subject: Protocol Action: 'RTP Stream Pause and Resume' to Proposed Standard (draft-ietf-avtext-rtp-stream-pause-10.txt)

The IESG has approved the following document:
- 'RTP Stream Pause and Resume'
  (draft-ietf-avtext-rtp-stream-pause-10.txt) as Proposed Standard

This document is the product of the Audio/Video Transport Extensions
Working Group.

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/

Ballot Text

Technical Summary

  This document provides a mechanism to use existing RTCP Feedback Codec
  Control Messages (RFC 5104), as well as a group of new messages, to
  pause and resume RTP media streams.

  The document defines two separate mechanism for pausing and
  resuming RTP streams.  One mechanism codifies existing practice of how
  to use RFC 5104 messages to pause and resume streams, but is only
  applicable to a subset of possible RTP topologies.  The other is a new
  mechanism and is generally applicable.  Guidance is provided as to
  when one or the other mechanism should be used.

Working Group Summary

  The two protocol mechanisms were the result of two separate proposals
  as to how to solve the requirement; once the proposals were merged
  into a single document, there were no objections to WG consensus.

Document Quality

  There are existing deployed implementations of the RFC 5104-based
  mechanisms to pause and resume RTP streams.

  Paul Kyzivat performed an SDP directorate review. The review expressed concerns
  about the complexity of configuration. The WG had already considered the suggested
  alternatives and selected the documented method. The authors added additional text
  discussing the interoperability considerations of the various supported configurations.

Personnel

  The Document Shepherd is Jonathan Lennox; the Responsible Area
  Director is Ben Campbell.

RFC Editor Note