2.7.1 Audio/Video Transport (avt)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 11-Oct-99


Stephen Casner <casner@cisco.com>
Colin Perkins <c.perkins@cs.ucl.ac.uk>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Mailing Lists:

General Discussion:rem-conf@es.net
To Subscribe: rem-conf-request@es.net
Archive: ftp://ftp.es.net/pub/mail-archive/rem-conf/

Description of Working Group:

The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over UDP and IP multicast. This is the Real-time Transport Protocol, RTP, together with its associated profile for audio/video conferences and payload format documents.

The current goals of the working group are to revise the main RTP specification and the RTP profile ready for advancement to draft standard stage (including the sampling algorithms for use with very large groups, which have been broken out into a separate document), to complete the RTP MIB, to produce a guidelines document for future developers of payload formats and to continue development of new payload formats.

The payload formats currently under discussion include a number of media specific formats (MPEG-4, DTMF, PureVoice) and FEC techniques applicable to multiple formats (parity FEC, Reed-Solomon coding).

Goals and Milestones:

Feb 99


Post RTP implementation checklist draft

Feb 99


Working group last call on guidelines for payload format writers (BCP)

Feb 99


Post revised draft on PureVoice (qcelp) payload format to address WG last call comments

Feb 99


Post payload format for MPEG-4 based on MPEG/IETF joint meetings

Feb 99


Working group last call on parity FEC draft (standards track)

Feb 99


Post revised RTP MIB and issue working group last call (stds track)

Feb 99


Post revised DTMF payload format draft, ready for WG last call

Feb 99


Post revised RTP membership (SSRC) sampling draft

Feb 99


Post revised Reed-Solomon draft

Feb 99


Post revised RTP spec and audio/video profile

Feb 99


Post revised RTP spec and audio/video profile

Mar 99


Submit RTP MIB to IESG for publication as Proposed Standard RFC

Mar 99


New working group last call on PureVoice payload format

Mar 99


Submit guidelines for payload format writers for publication as a BCP

Apr 99


Working group last call on revised SSRC sampling draft (experimental)

Apr 99


Post final revision of RTP spec and A/V profile drafts

Apr 99


Analysis/simulation of multiplexing payload format proposals

Jun 99


Revise MPEG-4 payload format document after implementation experience

Jul 99


Prepare MPEG4 implementation results ready for WG last call

Jul 99


Decide how to proceed with multiplexing protocol: one generic payload format or a number of application specific formats

Jul 99


Working group last call on RTP and A/V profile (for Draft Standard)

Oct 99


Post final revisions of selected multiplexing protocol draft(s)

Nov 99


Working group last call on multiplexing payload format (stds track)


Request For Comments:







RTP: A Transport Protocol for Real-Time Applications



RTP Profile for Audio and Video Conferences with Minimal Control



RTP payload format for H.261 video streams



RTP Payload Format of Sun's CellB Video Encoding



RTP Payload Format for H.263 Video Streams



RTP Payload for Redundant Audio Data



RTP Payload Format for MPEG1/MPEG2 Video



RTP Payload Format for Bundled MPEG



Options for Repair of Streaming Media



RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)



RTP Payload Format for BT.656 Video Encoding



RTP Payload Format for JPEG-compressed Video



Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

Current Meeting Report

Audio/Video Transport Working Group Minutes

Reported by Colin Perkins and Steve Casner

The audio/video transport working group held two full sessions in Washington DC. The first session discussed the ongoing revision to the RTP specification and audio/video profile, together with a number of payload formats. The second session dealt with transport of MPEG-4 and multiplexing. In addition, a design team met to discuss the transport of MPEG-4.

The meeting started with a review of work in progress and the status of the working group's documents. The RTP payload format for generic FEC (draft-ietf-avt-fec-08.txt) has been approved for publication as a proposed standard, and the guidelines for writers of RTP payload format specifications (draft-ietf-avt-rtp-format-guidelines-04.txt) has been approved for publication as a BCP. At the time of writing, neither of these RFCs have been issued yet.

The RTP MIB (draft-ietf-avt-rtp-mib-07.txt) has been sent to the IESG for consideration as a proposed standard. The draft on sampling group membership in RTP (draft-ietf-avt-rtpsample-05.txt) was published as an Experimental RFC after the meeting. In addition, the payload format for DTMF and related tones (draft-ietf-avt-tones-02.txt) was noted as having completed working group last call and will be submitted for publication after a final revision is posted.

An update on the the RTP specification and audio/video profile was presented by Steve Casner. The recent changes to the RTP specification include:

There are three open issues with this specification:

The recent changes to the audio/video profile include:

Once again, there are a number of minor open issues:

The question of how to deal with proposed enhancements to the comfort noise payload format to include spectral shape parameters was raised. This work is ongoing in the ITU-T SG16, but will take time to complete - we don't want to wait for this, before we advance RTP. There are a number of options:

The chairs proposed taking this latter option, but this raised a number of questions about the status of the revised comfort noise draft (which is in use in a number of products) and the ability of the profile to reference it. After some discussion, a hybrid of these options was chosen: the comfort noise payload format will be extracted from the audio/video profile and submitted as a proposed standard RFC, referenced by the profile. Steve Casner will do this as part of editing the profile. The ITU-T will extend this, in the same manner as any other payload format is extended, with the expectation that it will cycle at proposed standard.

The MIME registration for the payload types defined in the audio/video profile has been updated (draft-ietf-avt-rtp-mime-01.txt). The changes include clarification of the mapping from MIME parameters to SDP "a=fmtp" attributes and the addition of the RED (redundant audio) payload and "type" parameter for MPEG. It was noted that the payload format for generic FEC, which is already in the hands of the RFC editor, did not include a MIME registration for the name "parityfec"; Jonathan Rosenberg volunteered to write a separate draft for this.

This meeting marked the completion of working group last call on the set of drafts that have been prepared for advancement of RTP specification and A/V profile to Draft Standard status. The working group accepted the changes that had been made in the drafts posted for last call as well as the few changes proposed in response to comments received during the last call. With those changes, the working group agreed that the following drafts should be submitted for IESG Last Call:
draft-ietf-avt-rtp-new-05.txt (Draft standard)
draft-ietf-avt-profile-new-06.txt (Draft standard)
draft-ietf-avt-rtp-mime-00.txt (Proposed standard)
draft-ietf-avt-rtcp-bw-00.txt (Proposed standard)

This will be done immediately.

The need for interoperability statements from implementors was noted. Implementors, both academic and vendors, are strongly encouraged to study draft-ietf-avt-rtp-interop-02.txt and draft-ietf-avt-profile-interop-00.txt, and to submit a statement of interoperability to the group. Scott Bradner (the transport area co-director) noted that it is okay for a neutral third party to present the results, hiding the identity of the vendors if they do not wish to make this information available. The chairs will set up a web page, summarizing the results of interoperability tests conducted.

The next topic was a potential new task for AVT: a unicast RTCP-based retransmission scheme, presented by Matthew Podolsky. The motivation for this work (draft-podolsky-avt-rtprx-00.txt) is that there are a number of proprietry retransmission schemes in use, hindering interoperability, and no standard currently exists.

Why unicast? Because unicast retransmission schemes are widely used, and because they are well understood, unlike multicast retransmission schemes which are difficult to make work in a scalable and timely manner. Further, reliable multicast is outside the scope of this working group.

The proposal is for a new RTCP packet type, the "multipurpose ACK", which can be used to ACK or NACK a packet with a particular sequence number and up to 16 surrounding packets. This is flexible, specifying a basic framework for requests which can be modified or extended by a protocol subtype field.

A number of items were raised for discussion:

Mark Handley noted that there is an urgent need to deploy congestion controlled RTP to prevent problems in the wide area network. If the group is going to work on a new unicast RTP profile including retransmission, it would be advisable if we could also include congestion control. In a discussion after the AVT session, the transport area directors agreed that it was appropriate for AVT to undertake this work, but that congestion management must be included. Since the ECM working group won't have output right away, Mark Handley and Sally Floyd agreed to write an informational document that the work on retransmission can refer to.

The remainder of the first day was spent in a discussion of various RTP payload formats. The first was an update on the payload format for Real Time Pointers was presented by Reha Civanlar. The new draft resolves the issues raised at the previous meeting, and also adds the ability to convey an indication of the pointer icon (the mapping from code-points to icons is to be specified out of band). This is now ready for working group last call.

The RTP payload formats for DV audio (draft-ietf-avt-dv-audio-00.txt) and video (draft-ietf-avt-dv-video-01.txt) were presented by Katsushi Kobayashi. Changes relating to the audio format include:

The DV video payload has seen the addition of support for D-7 and D-9 "professional" formats, a simplification of the SDP description and the removal of IEEE1394 specific timestamp issues to an appendix, since the D-7 and D-9 formats suppose a different interface. The MIME registration has yet to be done. Two interoperable implementations exist (from the WIDE project and KTH). These drafts are believed ready for working group last call.

The payload format for MPEG2 AAC was presented by Jim Snyder (standing in for Mathias Kretschmer who was ill). Changes have been made relating to

This payload format has not yet been implemented, but this is in progress (probably not be done by next meeting, but by the one after). The draft is not yet ready for last call, since the authors need to do more development and testing, and desire feedback from the group (especially relating to MPEG-4).

Ross Finlayson presented an update to the more loss-tolerant payload format for MP3 audio (draft-ietf-avt-rtp-mp3-01.txt). This payload format is more robust to packet loss than RFC2250, but implies more knowledge of MP3. Recent additions to the draft include a specification of how to handle streams containing a mix of layer I or II frames with layer III (this is an uncommon situation) and pseudo-code to convert between "MP3 frames" and "ADU frames" as required by this format. A plea was made for the group to check the pseudo- code, since it's somewhat complex. More information, including a performance comparison with RFC2250, is available from http://www.live.com/rtp-mp3/. Dave Singer noted that this is a great idea, but doesn't go far enough: maybe it should include support for interleaving too? His group has demonstrated improved performance with interleaving, reusing the MPEG sync byte so no overhead is added (though doing this precludes mixing in layer I or II frames). The addition of interleaving will be considered before the draft is progressed.

An extension to the payload format for MPEG-2 transport streams (draft-ietf-avt-rtp-mp2t-00.txt) was presented by Humphrey Liu. The issue here is that MP2T is a packet- based transport format which can contain multiple programs with an aggregate bandwidth which can be as high as 50-60Mbps (=40Kpps). The 90KHz RTP timestamp clock defined in RFC2250 does not have sufficient resolution (about two ticks per packet), so this draft recommends a 27MHz clock, as defined by MPEG-2. In fact, RTP with MP2T does not provide much value compared to UDP for single-program transport streams (at lower data rates for which 90kHz is appropriate), but the RTP timestamp does add value for multiple-program transport streams given sufficient resolution.

Why is so much resolution needed? For faster clock recovery, for calculation of piece-wise CBR bitrate interpolating the timestamp for every MPEG packet multiplexed into the RTP-encapsulation transport stream, and in order to regenerate the exact timing for re-insertion of each packet into a native MPEG-2 transport stream. No change to the actual payload format in RFC2250 is required, just a change in the RTP timestamp clock rate. For applications which use SDP, this can be accomplished by specifying a clock rate of 27000000 in the a=rtpmap attribute.

The payload for text conversation (draft-ietf-avt-rtp-text-02.txt) was presented by Ian Rytina. The issues resolved since Oslo include:

Allison Mankin presented some new work on an RTP payload format for HDTV, motivated by the start of commercial HTDV broadcasts in the US and the proliferation of formats. The bandwidth of HDTV streams ranges from 176Mbps to 1.49Gbps uncompressed, and compresses down to around 20-40Mbps for broadcast. These media formats are under standardisation by the ATSC (http://www.atsc.org) and DVB (http://www.dvb.org) but with major differences in transmission technology (COFDM vs 8VSB) and payload (eg: DVB uses MPEG audio, ATSC uses AC-3 Dolby). The payload for compressed HDTV is mostly covered by RFC2250. The uncompressed format is related to BT.656 with the addition of 4.2.0 colour sub- sampling and a 1080 line mode (versus 525/625 lines for BT.656). One question is whether the BT.656 payload format can just be extended for HDTV, but here again the RTP timestamp resolution may be an issue. A payload is also needed for AC3 audio. This is an early "heads up" on the work, which is ongoing, and further drafts are expected in future.

The major issue discussed on the second day was the transport of MPEG-4 media. Colin Perkins started this by summarising the design team meeting held earlier in the week. There are three proposals for discussion:

It is also expected that there will be a fourth proposal for a packetization based on MPEG FlexMux. A number of open issues were identified with these proposals:

Following this summary, brief presentations were made on the individual proposals.

The discussion of MPEG-4 was concluded by Colin Perkins, who outlined the chairs' view on future activity in this area.

An a postscript to the MPEG-4 discussion, Dave Singer provided an overview of draft-singer-rtp-qtfile-01.txt, the QuickTime file format and hint track specification. This was presented for information and comments, it is not intended to be published on the standards track.

The next subject was RTP multiplexing. The first presentation in this area was by Bruce Thompson on extensions to CRTP and RTP multiplexing using tunnels. The original work has was draft-wing-avt-tcrtp-00 which was submitted to the Oslo meeting. This was been broken into three parts: IP tunneling, PPP multiplexing, and enhancements to CRTP.

Three independent enhancements to CRTP are described in draft-koren-avt-crtp-enhance-00.txt. The first is the ability to include a delta-timestamp in COMPRESSED_UDP packets to restore the state at the decompressor in the event of packet loss. This makes CRTP more robust to packet loss and also lets you refresh state and send it multiple times efficiently without the delay of error feedback. Concern was expressed about the need to send the absolute value of IPv4 ID, which could be addressed by using the COMPRESSED_NON_TCP packet instead except that doesn't include the delta-T. The second extension is to add a NonRTP stream flag to the FULL_HEADER packet to notify the decompressor that the compressor will never send COMPRESSED_RTP packets for a particular context so that the decompressor does not have to maintain context for the RTP header. The third extension is to define a reject packet to allow a decompressor to reject the use of a new compression context when it is out of resources.

An overview of how this enhanced CRTP can be used for tunneling to provide a transparent and efficient multiplexing solution was also provided. RTP packets are encapsulated end-to-end for multiplexing, consisting of

The application runs RTP with no knowledge of the tunnel/compression: CRTP and muxing take place at layer 2, independent of the application. It was noted that it is also possible to compress away the IP header on a per link basis, if desired. An informational document is to be produced, describing how these pieces fit together to provide the complete solution.

Steve Casner noted that this approach to the entire muxing problem is clean and moves the multiplexing down to the IP layer where it is more appropriate, keeping the RTP semantics tidy. Input from the group was solicited on the changes for CRTP.

The final presentation was by Colin Perkins, for Alexander Tulai who was unable to attend, on a dynamic Nx64 payload format (draft-tulai-avt-dynamic-nx64-00.txt), for multiplexing PCM coded audio streams (eg: transport of a T1 line). The consensus of the group was that this draft is too narrowly focused, but a payload format for general circuit emulation may make sense.

The meeting concluded with a discussion of the working group charter. The main goal of the group has been the development of RTP; once this is done we have concluded most of our work. We also have steps in the charter for MPEG-4 and multiplexing, but we expect to complete these and our other remaining actions over the course of the next couple of meeting. This will leave only the continuing evolution of payload formats - these don't necessarily need AVT to meet everytime, since much of this work can be done on the mailing list.

There are a number of options for the future of the group: one possibility is that we may go into hibernation, meeting occasionally when there is sufficient work. It was suggested that we could separate the RTP protocol itself from the payload question: payloads don't necessarily have to be done in the RTP working group (although AVT - or its successor - may review such payload formats), and we could recharter AVT to do extensions of the core RTP protocol/profile only.Another option would be to recharter to study new profiles for unicast RTP retransmission and/or congestion control. Input from the working group is solicited.


None received.