IETF WG Presentation1 Urooj Rab Audio/Video Transport

IETF WG Presentation2 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 Presentation3 EXPECTATIONS: 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 Presentation4 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 Presentation5 Chair: Stephen Casner Transport Area Directors: Scott Bradner Allyn Romanow Transport Area Adviser: Allyn Romanow

IETF WG Presentation6 Mailing Lists Mailing Lists General Discussion: To subscribe: Archive: ftp://nic.es.net/pub/mailing -lists/mail-archive/rem-conf URL: avt-charter.html

IETF WG Presentation7 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 Presentation8 PROBLEMS 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 Presentation9 PROPOSITION 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 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 Presentation11 PROPOSITION 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 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 Presentation13 PROPOSITION 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 Presentation14 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 Presentation15 INTRODUCTION Users must perceive the quality of multimedia conferencing to be sufficiently good. PROBLEMS PROBLEMS A number of problems have been identified that impair the quality of conferences. Most significant is packet loss.

IETF WG Presentation16 SOLUTIONS 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 Presentation17 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 Presentation18 42nd IETF Meeting March 30 - April 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