This report provides a summary of discussion which took place in the audio/video transport working group during the 45th IETF meeting, held between 12th and 16th July 1999 in Oslo. It is submitted to satisfy the SCIMITAR funding requirements.
The contents of this document are based on personnal notes taken during the meeting, and DO NOT provide an official record of the meeting. The official minutes are available from the IETF Web Site.
The opinions and interpretations expressed herein are those of the author, and do not necessarily represent those of the IETF, the audio/video transport working group chairs, or other persons mentioned herein. If this document differs in its record of events from the official proceedings of the meeting, then those proceedings should be considered accurate.
The meeting started with a review of the document status. The RTP payload for PureVoice (QCELP) audio has completed last call and is awaiting publication. The RTP MIB, SSRC sampling, generic FEC and guidelines for writers of payload formats drafts were in working group last call (with the exception of the MIB, these have now been sent to the IESG for IETF last call).
The revision of RTP and the audio/video profile is proceeding, and Steve Casner presented the new drafts here. The recent changes to RTP in the latest draft (draft-ietf-avt-rtp-new-04.txt) include:
Recent changes to the audio/video profile (draft-ietf-avt-profile-new- 06.txt) include:
The major limiting factor on the movement of RTP and the audio/video profile to draft standard is the interoperability requirement. Colin Perkins outlined the interoperability requirements placed on protocols advancing to draft standard status (see RFC2026) and presented the first version of an interoperability statement (draft-ietf-avt-rtp-interop- 00.txt).
It was noted that this is not a set of conformance tests: all that is required to demonstrate interoperability for this purpose is a claim from the vendor that implementations X and Y interoperate for a set of features. Vendors are encouraged to study this draft, to test their implementations, and to report back the results so that we can advance the specifications.
Of course, such testing is a difficult business, and it is advantageous if there is a common framework and guidelines for those conducting tests.
Two drafts were presented which aim to provide such a framework: Colin Perkins presented draft-ietf-avt-rtptest-00.txt which deals with RTP, and Jonathan Rosenberg presented draft-ietf-avt-rtcptest-01.txt dealing with RTCP. Once again, we note that these are NOT conformance tests - merely suggested testing strategies.
We plan to merge these two testing drafts into one, to be published as an informational RFC eventually. We note that we also have to produce an interoperability statement for the audio/video profile. This work has yet to begin.
Following the discussion of RTP, Mark Baugher presented the RTP MIB (draft-ietf-avt-rtp-mib-05.txt). This is in last call at present, pending revision to address comments received - a new draft is expected shortly.
Comments on the changes were generally favourable, although Dave Thaler requested additional wording in the draft to reflect which optional bits are useful in which cases, to clarify implementation requirements.
The MIB is referenced form H.341 which is now an ITU-T standard. The means by which changes to the MIB can be incorporated into H.341 are unclear.
Scott Petrack presented the payload for DTMF and other related tones (draft-ietf-avt-tones-00.txt). The remaining open issue is if we need an SDP a=fmtp attribute to signal subsets of the defined encoding sets? The current draft has named groups of tones signalled by the RTP payload type, with applications which support only a subset of these using an a=fmtp attribute to indicate that subset. This wastes namespace, since each group of tones has to be registered in the MIME namespace, and seems complex. An alternative proposal to register a single name for the DTMF codec, and use a=fmtp to indicate exactly which tones are used seems more consistent with other usage and reduces pollution of the MIME namespace.
It was also noted that the DTMF codec seems to allow for overlapping audio, which has not been explicit with other codecs until now. The draft should have a paragraph inserted clarifying this.
With these two minor exceptions, the DTMF drafts is believed ready for working group last call.
The generic FEC draft (draft-ietf-avt-fec-06.txt) was presented by Jonathan Rosenberg. The change this time is to the means by which FEC streams were signalled in SDP, since the previous version was ambiguous in some cases.
The new approach carries an SDP c= line as an a=fmtp attribute, to indicate which address/port is used for the FEC. Anders Klemets noted that this needs clarification for use with RTSP, but otherwise this approach seems sound. A new draft reflecting use with RTSP will be produced, and then last call requested.
Reha Civanlar presented an report on the interim meeting held in New York on the 25th of April to discuss transport of MPEG-4 over IP. The items of discussion at that meeting were: the payload format, timing and buffering models, and multiplexing.
The two payload formats proposed are draft-ietf-avt-rtp-mpeg4-01.txt which is a simple mapping of MPEG-4 SL packets onto RTP, with additional FEC being provided by the standard RTP mechanisms (RFC2198, draft-ietf- avt-fec-06.txt for example) and requiring smart (transport aware) packetisation of MPEG-4 media. The alternative (draft-guillemot-genrtp- 01.txt) relies on a number of extensions to MPEG-4 to accomplish more advanced error protection. The unresolved issues were noted as being:
Following this summary of the interim meeting, Stefan Wesner presented the latest revision to draft-guillemot-genrtp-01.txt (the other proposed payload format, draft-ietf-avt-rtp-mpeg4-01.txt, has not changed recently).
As noted previously, this payload includes more complex error protection mechanisms based on RFC2198, draft-ietf-avt-fec-06.txt, and the Reed Solomon and interleaving drafts previous presented. Unfortunately, these are included by copying them into the new payload, with subtle (and unfortunately incompatible) modifications. In addition it is noted that this payload relies on an extension to MPEG-4 to provide the information needed to use the error protection.
The final presentation on the first day related to the payload for DV audio and video draft-ietf-avt-dv-video-00.txt and draft-kobayashi-dv- audio12-00.txt and was made by Akimichi Ogawa. The video payload format is essentially complete, and an implementation is progressing to verify this. The audio format is new, but appears to be relatively straightforward (although the specification of the necessary SDP parameters to describe some of the more complex modes may take some considerable effort).
The second meeting began with a presentation of a taxonomy of multicast feedback (draft-hnrs-rmt-avt-feedback-00.txt) by Jonathan Rosenberg. This lead into a discussion of a possible new RTP profile for unicast RTCP, lead by Steve Casner. The motivation for producing a new profile is as follows:
The initial proposal was for receivers to unicast their RTCP reports to the source, which forwards them to the group via multicast. The source can, if desired, remove and/or aggregrate SDES and/or RR information to allay privacy concerns. The source must be authenticated, probably by including its address in an authenticated announcement, else we are open to packet bombing. Care must also be taken when receiving BYE packets, since these could be spoofed causing excessive transmission rate.
A second proposal is for the source to send only a new RTCP packet type giving the number of receivers, with the receivers unicasting RTCP to the source as before. Receivers have to limit the rate at which the group membership is allowed to decrease, to prevent packet bombing.
Open issues include: what about sessions with multiple sources? How does it interact with adjustable RTCP bandwidth fractions?
The final question is, of course, should we do this? Deployment of better routing (which doesn't suffer from (S,G) state problems) will take a year or more, but probably so will deployment of a profile such as this. Would this add value in the long run? No consensus was reached in the session, discussion is encouraged on the mailing list.
The major item on the second day was header compression and multiplexing, starting with a presentation on header compression over cellular links by Lars-Erik Jonsson (draft-degermark-crtp-cellular- 00.txt). This presentation noted that the problem with CRTP is not header compression efficiency, but packet loss rate due to context damage and the loss length distribution (often 7-8 packets in a row, due to the long round-trip-time of the cellular links and the need to resynchronize decompressor state). In addition, a solution to this was presented (draft-jonsson-robust-hc-00.txt) along with supporting results. This work clearly solves a real problem with the RTP header compression scheme and loss long-RTT links, but it is presently unclear if AVT is the correct group to work on this, or if the general header compression framework proposed should be progressed in another group.
It was also noted that IPR exists on this work, and the licensing terms are not yet clear. The WG chairs were requested to check on this with Ericsson.
The next presentation was by Irfan Ali and related to PPP multiplexing (draft-pazhyannur-avt-pppmux-00.txt). This proposal alows one to pack multiple IP packets into a single PPP frame, to amortize header overheads.
This work was also presented in the PPPEXT working group, and was adopted as a work item by that group.
Tmima Koren presented tunnelled compressed RTP (draft-wing-avt-tcrtp- 00.txt) a scheme for compressing UDP/RTP headers and multiplexing multiple packets into a single IP packet. This allows end-to-end compression in some cases, in addition to multiplexing, providing a substantial bandwidth saving in some cases.
It was agreed that the TCRTP and Rocco work was important, and should be persued (although it is unclear if Rocco will fall into the scope of AVT). The PPP multiplexing has been adopted by PPPEXT, and need not be worked upon in AVT.
Khalil El-Khatib presented another Multiplexing Scheme for RTP Flows between Access Routers (draft-ietf-avt-multiplexing-rtp-00.txt). This proposal met with considerable criticism: in particular, the concept of RTP switches and application level routing implied by this draft was not well received, the signalling was noted as being poorly specified, the handling of packet loss, and the lack of support for RTCP were noted.
The consensus of the group was that this proposal needs significant work before it can proceed.
We noted that the proposal for a multiplexing scheme made at the last meeting was to adopt GeRM as the AVT multiplex, unless objections were made. Some limited feedback on this issue has been received from the MPEG community, but none from other sources. Anyone having opinions on the suitability or otherwise of GeRM is encouraged to provide feedback to the list.
Mathias Kretschmer presented (draft-kretschmer-mpeg2aac-01.txt) an MPEG- 2 AAC audio payload for RTP. The important aspects of this payload format are the redundancy scheme and priority vector, both of which are designed to make this more error resilient. It was agreed to make this a work item of AVT.
Reha Civanlar presented (draft-civanlar-rtp-pointer-00.txt), an RTP payload format for Real-Time Tele-Pointers. This is simple, encoding x- and y-coordinates and button press indicators. After discussion we noted that encoding position as a fraction of the display (rather than absolute pixel values as currently specified), using a 90kHz clock (to synchronise with video) and allowing for 3 buttons were important changes to make. In addition, it is unclear how to deal with more advanced pointing devices (e.g. the wheel mice now available). This document will be adopted as an AVT work item.
Gunnar Hellström presented an RTP Payload for Text Conversation (draft-hellstrom-avt-rtp-text-00.txt) needed for the ITU T.140 standard. This is a straight-forward payload format, with few complex interactions. The open issues identified are: should the specification of use with T.140 be part of the main specification or an appendix? (an appendix) How is RTCP used with this payload format to indicate the amount of FEC to add? Should this be specified? The format must be complete by February 2000 for the T.140 standard timetable.
Finally, John Stewart presented a brief overview of an RTP payload format for shared virtual worlds (draft-stewart-avt-00.txt). This uses RTP for orientation info, for gestures, clicking, etc. There is some overlap in the uses of this payload with the DIS/HLA community, although this is simpler. It was suggested that we may consider working on a payload format which can encompass both the simple model proposed here, and more complex DIS scenarios, although due to lack of time for discussion we did not come to a conclusion on this.
Finally, a sub-group met in a telephone conference wit the MPEG committe meeting in Vancouver to discuss transport of MPEG-4 on IP. The main area of discussion was the payload formats for MPEG-4 over RTP, with concern being raised that the work needed to complete those areas of the MPEG-4 standard needed to implement draft-guillemot-genrtp-01.txt was not being undertaken, and that the protocol is too complex; and that draft-ietf- avt-mpeg4-01.txt provides insufficient error protection (or if sufficient protection is provided, the overheads are excessive).
The discussion continued for some time, with no consensus being reached. In the end, it was decided to progress both payload formats to experimental status, and in the light of implementation status to progress one or both of them in future.