Return-Path: Delivery-Date: Wed, 22 Nov 1995 17:12:22 +0100 Received: from osi-west.es.net by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Wed, 22 Nov 1995 17:12:13 +0100 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 22 Nov 1995 07:00:48 -0800 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 Cc: Internet Architecture Board Cc: rem-conf@es.net From: IESG Secretary Subject: Protocol Action: RTP: A Transport Protocol for Real-Time Applications to Proposed Standard Date: Wed, 22 Nov 95 09:59:59 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9511221000.aa11377@IETF.CNRI.Reston.VA.US> X-Received-By: classifyMail The IESG has approved the following two Internet-Drafts for publication as Proposed Standards: 1. RTP: A Transport Protocol for Real-Time Applications 2. RTP Profile for Audio and Video Conferences with Minimal Control 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.