1 / 18

IETF Working Group

IETF Working Group. CSCI 344 Spring 1998. Presentation. Urooj Rab Audio/Video Transport. GENERAL DESCRIPTION. Purpose: The Audio/Video Transport Working Group was formed to specify experimental protocols for real-time transmission of audio and video over UDP and IP multicast.

nishi
Télécharger la présentation

IETF Working Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF Working Group CSCI 344 Spring 1998 Presentation Urooj Rab Audio/Video Transport IETF WG Presentation

  2. GENERAL DESCRIPTION Purpose: The Audio/Video Transport Working Group was formed to specify experimental protocols for real-time transmission of audio and video over UDP and IP multicast. The focus of this group is near-term and its purpose is to integrate and coordinate the current AVT efforts of existing research activities. IETF WG Presentation

  3. EXPECTATIONS: • No standards-track protocols • are expected to be produced • because UDP transmission of • audio and video is only • sufficient for small-scale • experiments over fast • portions of the Internet. • The control protocols must handle authentication and key exchange so that the A/V data can be encrypted. • Aim for more sophisticated connection management. IETF WG Presentation

  4. Design independent protocols • specific to each medium, or • extract a common, • lightweight, real-time • transport protocol. • Come up with a form of • timestamps and/or sequence • numbers to be used for • sequencing of packets and • synchronization among streams. IETF WG Presentation

  5. Chair: Stephen Casner casner@precept.com Transport Area Directors: Scott Bradner <sob@harvard.edu> Allyn Romanow <allyn@mci.net> Transport Area Adviser: Allyn Romanow <allyn@mci.net> IETF WG Presentation

  6. Mailing Lists General Discussion: rem-conf-request@es.net To subscribe: rem-conf-request@es.net Archive: ftp://nic.es.net/pub/mailing -lists/mail-archive/rem-conf URL: www.ietf.org/html.charters/ avt-charter.html IETF WG Presentation

  7. Internet Draft Description RTP usage with Layered Multimedia Streams Date:Dec 20th, 1996 ABSTRACT This draft describes how one should make use of RTP when employing layered media streams. IETF WG Presentation

  8. PROBLEMS • 1. Layered Video • Most multimedia applications place • the responsibility of • rate-adaptivity at the source. • This leads to the source not being • able to meet the conflicting • bandwidth requirements of all the • receivers. • This usually leads to the • least-common denominator scenarios • where the smallest pipe in the • network mesh dictates the quality • and fidelity of the overall live • multimedia “broadcast”. IETF WG Presentation

  9. PROPOSITION • Responsibility of rate-adaptation • be placed at the receivers so that • the heterogeneity of such media • transmissions is achievable. • This can be achieved by combining • a layered source-coder with a • layered transmission system. • A source stripes the progressive • layers of a hierarchically • represented signal across multiple • multicast groups. • Receivers can then adapt to network • heterogeneity by controlling their • reception bandwidth though IP • Multicast group membership. IETF WG Presentation

  10. 2. RTP Usage • The RTP specification assumes • that the underlying transport/ • network layer is monolithic. That • is, a single RTP session is carried • on a single underlying • communications layer. • However, the layered transmission • system requires multiple • underlying transport end-points. • This complicates the naming of an • RTP session because we need to • explicitly identify each of the • transport channels that comprise • the overall layered set. IETF WG Presentation

  11. PROPOSITION • Layered applications use a set of • contiguous addresses and ports. • Addresses must be distinct because • multicast routing and group • membership are managed on an • address granularity. • Ports must be distinct because of • a widespread deficiency in • existing operating systems. • For unicast, there is only one • permissible address. So only port • mapping applies in the case of • unicast. IETF WG Presentation

  12. 3.Extension of RTP Semantics • In RTP, each media source is • identified with a randomly • allocated 32-bit source identifier • (SRCID). • Each user is identified with a • variable-length “canonical name” • (CNAME). • Data packets are identified only by • SRCID and each application • broadcasts a binding between its • CNAME and SRCID. • This can readily handle layered • compression formats. • But the “RTP session per layer” • approach adds unnecessary • complexity. • It creates new error recovery • conditions. IETF WG Presentation

  13. PROPOSITION • A single SRCID space is used across • all layers and the core layer be • used for SRCID allocation and • conflict resolution. When a source • discovers that it has collided, it • transmits an RTCP BYE message • on only the base layer. • A participant sends sender • identification (SDES) on only the • base layer. IETF WG Presentation

  14. RFC DESCRIPTION RTP Payload for Redundant Audio Data RFC: 2198 Category: Standards Track Date: September 1997 Abstract Describes a payload format for use with real-time transport protocol (RTP) for encoding redundant audio data. The primary motivation is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone. IETF WG Presentation

  15. INTRODUCTION • Users must perceive the quality of • multimedia conferencing to be • sufficiently good. • PROBLEMS • A number of problems have been • identified that impair the quality • of conferences. • Most significant is packet loss. IETF WG Presentation

  16. SOLUTIONS • The addition of redundancy is • offered as a solution. • If a packet is lost then the • missing information may be • reconstructed at the receiver • from the redundant data that • arrives in the following • packets. • Two essential means by which • redundant audio may be added to • the standard RTP specification. • - A header extension may • hold the redundancy • - Additional payload types • may be defined IETF WG Presentation

  17. There are few disadvantages • involved with header extension. • Therefore, it has been • disregarded. • The RTP profile for audio and • video conferences lists a set • of payload types and provides • for a dynamic range of 32 • encodings that may be defined • through a conference control • protocol. IETF WG Presentation

  18. 42nd IETF Meeting March 30 - April 3 1998 AVT Wednesday, April 1- 9 to 11:30 Thursday, April 2- 3:30 to 5:30 AGENDA April 1 -Introduction and status -Generic Payload type mapping and fragmentation -Options for Repair of Streaming Media April 2 -New RTP payload format proposals -RTP Spec and Profile issues -DMIF for RTP/MPEG4 IETF WG Presentation

More Related