Audio/Video Transport WG Meeting Report
			 21-Nov-91, Santa Fe

1. Scope of this working group

In the Teleconferencing BOF two days earlier, several areas of
interest were identified.  One area was deemed ready for a working
group: the Audio/Video Transport WG was formed to specify protocols
for real-time transmission of audio and video over UDP and IP
multicast, and this kickoff meeting was scheduled.

The purpose of this working group is to foster interoperation among
several packet audio/video experiments already underway using UDP.
Many hosts on the Internet have the capability now to do 64Kb/s PCM
audio, and many could inexpensively add frame-grabbers and simple
software compression for low-frame-rate video.  We want to enable
desktop teleconferencing among these hosts.  Therefore, the focus of
the WG is short-term: our goal is to have the protocols defined and
experimental implementations running by the July 1992 IETF meeting.

UDP transmission of audio/video is only sufficient for small-scale
experiments over fast portions of the Internet.  Scaling up will
require network resource management and more sophisticated connection
management; these are subjects of current research that we will defer
to later working groups.


2. Who might contribute

Our first step will be to solicit contributions of potential protocols
from those projects that are already experimenting with packet audio
and video.  From these contributions we will distill the appropriate
protocol features.  Many projects are working on "multimedia", but
that is a wide topic.  We are particularly interested in those who are
working on packet transmission of real-time media.  Some 25-30
projects were suggested as candidates by meeting participants.


3. Brief descriptions of some existing protocols

Of the projects represented by the participants, three have audio and/or
video protocols already in use.

  - Paul Milazzo from BBN described the protocol used in the Desktop
    Video Conference program.  DVC uses the low-cost VideoPix
    frame-grabber card for SPARCstations plus software compression to
    generate video at about 5 frames per second.  The DVC protocol
    communicates sequences of video subimage blocks over either TCP or
    UDP.

  - Hans Eriksson from SICS described the PicturephoneTalk program.
    It uses TCP connections to carry uncompressed images from the
    VideoPix card and 64Kb/s PCM audio from the built-in audio device.
    The protocols include timestamps to allow synchronization of the
    streams at the receiver.

  - Steve Casner from ISI described the Network Voice Protocol (NVP)
    and Packet Video Protocol (PVP) that have been in use for several
    years in the multimedia conferencing system operating on the
    TWBnet, and more recently on DARTnet.  The data packet formats
    that are part of these protocols are fairly simple.  They have
    been used over both ST (Stream Protocol) and UDP.

Short descriptions will be prepared for each of these three protocols
to serve as models in the solicitation for contributions from other
projects.


4. Issues to be addressed

A number of protocol issues have already been identified from
differences among the protocols known to the participants.  In this
first session, we did not get to any serious discussion of these
issues, but some are included here to start your thinking:

  - Are there functions needed for both audio and video that should be
    extracted into a lightweight real-time transport protocol layer?
    One candidate might be timestamp information for synchronization.

  - Should timestamps be based on the media sample clock or on real
    time? 

  - Should sequence numbers count packets or smaller units such as
    samples? 

  - What should be the expected lifetime of the protocols produced by
    this working group?  Are they only to be used in the short term
    with UDP, or perhaps later directly over a real-time internet
    protocol? 

  - NVP and PVP include checksums over the header because they run
    over ST which provides no checksum.  Should such a feature be
    included in our new protocols in anticipation of their use over
    protocols other than UDP?

  - The CCITT recommendation G.764 Packetized Voice Protocol includes
    a field that records the cumulative variable queueing delays
    experienced by a packet in traversing the network.  This may be
    useful for deadline-scheduling of packet forwarding, but is it
    practical to expect Internet routers to update this field?

  - The Xerox PARC Phoenixphone protocol includes an "energy" value
    for each data packet; should this be included?

  - Should we provide a mechanism for communicating control functions
    within data packets?

It is expected that additional issues will be identified when
additional protocols are contributed.  Further discussion will occur
in subsequent teleconference meetings and by e-mail.


6. Next meeting

We've set an ambitious goal to hold the next meeting of the working
group by packet audio teleconference in mid-January.  The initial plan
is to use the UDP packet audio software for SPARCstations now used on
DARTnet, and to employ DARTnet as an IP Multicast backbone.  From
DARTnet end nodes we can use IP Multicast Tunneling to other WG member
sites.  We need to begin immediately to test whether network
performance on these potential tunnel paths is sufficient.

It is unlikely that all WG members will be able to participate by
packet audio.  It will be possible to set up a telephone conference
call for some sites and to patch that into the packet audio
conference.  We may also face the problem of too much timezone spread
among the interested parties (Oz to Europe) to be able to include
everyone.

The topic for the teleconference meeting will be a discussion of the
protocol issues listed above plus others that arise as we learn more
about additional existing protocols that should be considered in the
design process.  The solicitation for descriptions of these potential
contributing protocols will be sent to the WG mailing list
(rem-conf@es.net) and individually to contacts for each of the 25-30
projects already identified, in case they are not on the list.
Anyone wishing to make a contribution is invited to send a short note
to the chair (casner@isi.edu) requesting the solicitation.