Protocol Action: RTP: A Transport Protocol for Real-Time Applications to Proposed Standard

IESG Secretary <iesg-secretary@CNRI.Reston.VA.US> Wed, 22 November 1995 15:15 UTC

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12363; 22 Nov 95 10:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10182; 22 Nov 95 10:15 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12164; 22 Nov 95 10:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11386; 22 Nov 95 10:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09817; 22 Nov 95 10:00 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11377; 22 Nov 95 10:00 EST
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: rem-conf@es.net
Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
Subject: Protocol Action: RTP: A Transport Protocol for Real-Time Applications to Proposed Standard
Date: Wed, 22 Nov 1995 09:59:59 -0500
X-Orig-Sender: scoya@CNRI.Reston.VA.US
Message-ID: <9511221000.aa11377@IETF.CNRI.Reston.VA.US>

The IESG has approved the following two Internet-Drafts for publication
as Proposed Standards:


 1. RTP: A Transport Protocol for Real-Time Applications
	<draft-ietf-avt-rtp-08.txt, .ps>
 2. RTP Profile for Audio and Video Conferences with Minimal Control
	<draft-ietf-avt-profile-06.txt, .ps>

  These documents are the product of the Audio/Video Transport
  Working Group. The IESG contact person is Allison Mankin.

Technical Summary

   RTP (Real-Time Transport protocol) provides end-to-end network
   transport functions suitable for applications transmitting real-time
   data, such as audio, video or simulation data, over multicast or
   unicast network services. RTP leaves resource reservation and
   quality-of-service to other mechanisms (such as the RSVP protocol).
   RTP provides mechanisms that facilitate the application-specific
   handling of timestamped data, both at user end-points and at
   intermediate application processing nodes, such as audio mixers.

   RTP uses a payload type field and format and application specific
   profile specifications to adapt its transport services to varied
   media. It is flexible in supporting the requirements of media.
   Profiles have been prepared for a wide variety of both proprietary
   and standard encodings (standards submissions are pending for CELLB,
   MPEG, JPEG, and the H.261 specification.

   The RTP Profile for Audio and Video Conferencing with Minimal
   Control specifies the details of RTP (payload format types and other
   parameters) for conferences that in particular do not have parameter
   negotiation, It lists the currently defined encodings and describes
   the method for registering new encodings with the IANA.

   The RTP data transport is augmented by a control protocol (RTCP)
   which has several functions: first, it provides a minimal session
   management facility. The IETF MMUSIC Working Group is currently
   developing a comprehensive session control protocol, but RTCP has
   been used for simple control with good success in the MBONE. Second,
   RTCP is designed to allow monitoring of the data delivery in a
   manner scalable to large multicast networks.  Applications may use
   the Sender and Receiver report functions for control and adaptation,
   and additionally, network managers may monitor the reports in order
   to ensure that multicast routing and other network aspects of the
   multimedia application are functioning properly.

   RTP and RTCP were designed to be independent of the underlying
   transport and network layers. A typical use would be to run them
   over UDP/IP and IP multicast. Operation over UDP/IPv6 will be
   transparent.

   The protocol supports the use of RTP-level translators and mixers.
   This allows such functions as converting a 64 kbps audio conference
   to 9.6 kbps formats for transmission over low bandwidth links to
   residences. On the high end, it could support in future a function
   such as the composition of the video streams from multiple sites
   into one "virtual conference room" image. This aspect of the
   protocol thus supports interesting ways in which Internet multimedia
   may evolve.


Working Group Summary

   The AVT Working group concurs in recommending the advancement of
   these specifications.

   Recently ISO JTC1 SC.29 has reviewed this specification and there is
   an active liaison effort from that body to AVT.

Protocol Quality

   The protocol was reviewed for the IESG by the Transport Area
   Director, Allison Mankin, and by the Transport Area Directorate.
   Its Security Considerations and default methods were reviewed by
   Jeff Schiller, Security AD.

   There are already a number of interoperable implementations from
   this specification draft.