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.