2.7.1 Audio/Video Transport (avt)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 16-Oct-00

Chair(s):

Stephen Casner <casner@acm.org>
Colin Perkins <csp@isi.edu>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@east.isi.edu>

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:

Done

  

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

Done

  

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

Done

  

Post revised RTP spec and audio/video profile

Done

  

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

Done

  

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

Done

  

Post RTP implementation checklist draft

Done

  

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

Done

  

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

Done

  

Post revised RTP membership (SSRC) sampling draft

Mar 99

  

New working group last call on PureVoice payload format

Done

  

Submit guidelines for payload format writers for publication as a BCP

Done

  

Submit RTP MIB to IESG for publication as Proposed Standard RFC

Done

  

Analysis/simulation of multiplexing payload format proposals

Done

  

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

Done

  

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

Jun 99

  

Revise MPEG-4 payload format document after implementation experience

Jul 99

  

Prepare MPEG4 implementation results ready for WG last call

Done

  

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

Done

  

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)

Internet-Drafts:

Request For Comments:

RFC

Status

Title

RFC1889

PS

RTP: A Transport Protocol for Real-Time Applications

RFC1890

PS

RTP Profile for Audio and Video Conferences with Minimal Control

RFC2032

PS

RTP payload format for H.261 video streams

RFC2029

PS

RTP Payload Format of Sun's CellB Video Encoding

RFC2190

PS

RTP Payload Format for H.263 Video Streams

RFC2198

PS

RTP Payload for Redundant Audio Data

RFC2250

PS

RTP Payload Format for MPEG1/MPEG2 Video

RFC2343

E

RTP Payload Format for Bundled MPEG

RFC2354

 

Options for Repair of Streaming Media

RFC2429

PS

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

RFC2431

PS

RTP Payload Format for BT.656 Video Encoding

RFC2435

PS

RTP Payload Format for JPEG-compressed Video

RFC2508

PS

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

RFC2733

PS

An RTP Payload Format for Generic Forward Error Correction

RFC2736

 

Guidelines for Writers of RTP Payload Format Specifications

RFC2762

E

Sampling of the Group Membership in RTP

RFC2793

PS

RTP Payload for Text Conversation

RFC2833

PS

RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

RFC2862

PS

RTP Payload Format for Real-Time Pointers

RFC2959

PS

Real-Time Transport Protocol Management Information Base

RFC3009

PS

Registration of parityfec MIME types

RFC3016

PS

RTP payload format for MPEG-4 Audio/Visual streams

Current Meeting Report

Minutes of the Audio/Video Transport working group

Reported by Stephen Casner

The Audio/Video Transport working group met for two full sessions at the 49th IETF in Pittsburgh. In the first session we discussed advancement of the RTP spec and A/V profile to Draft Standard, in particular what should be said about congestion control. We also discussed payload formats for SMPTE 292M, EVRC speech and AMR speech, plus RTCP extensions for backchannel messages and retransmission including a selective retransmission payload format. In the second session we discussed header compression/multiplexing; payload formats for unequal error protection, transport of meta-info with RTP streams, and MPEG4; and RTP encryption and authentication.

The meeting opened with an introduction and status update by Steve Casner. Three drafts have been published as RFCs since the last meeting:

- RTP MIB (RFC 2959)
- Parity FEC MIME registration (RFC 3009)
- MPEG-4 Audio/Visual Streams (RFC 3016)

There are three payload format drafts awaiting publication as RFCs: G.722.1 has been approved for Proposed Standard and is on the RFC Editor's queue; and DV Video and DV Audio are waiting for edits by Steve Casner to clarify the text as requested by the IESG.

Another three documents are earlier in the process. The payload format for Loss-Tolerant MP3 Audio received some comments during working group Last Call. Subsequent to the meeting, the draft was revised to address those comments and is currently in IESG Last Call for publication as a Proposed Standard. Two drafts still need working group last call: RTP Testing Strategies, and the payload format for Comfort Noise. The latter draft specifies an extended packet format beyond the one-byte noise level defined in an earlier draft of the RTP A/V profile. Since the new Comfort Noise payload format will assume the static payload type assignment of the earlier one-byte specification, implementors are warned to speak up if this would cause a backward compatibility problem.

Advancing RTP to Draft Standard

The most important task for AVT is to progress the RTP spec to Draft Standard. This requires two interoperable and independent implementations of each feature and function. This is complete for most features, but not all. Also, as discussed at the previous meeting, we were asked by the Transport Area Directorate to address congestion control in the RTP spec.

A few paragraphs on congestion control were added to the spec and profile drafts before the previous meeting. The RTP specification says that congestion control is required, but that since the requirements are context dependent, the details of the required congestion control should be specified in profiles. The audio/video profile defines two cases:

- Applications using network QoS support should monitor to ensure service was received, and if not, switch to best effort.
- Applications running best-effort should monitor loss and reduce the transmission rate or stop if average throughput is greater than what TCP would get

We thank Mark Handley for this text which was an attempt to capture the sense of the discussion in Adelaide. Although there was some good discussion of the congestion control issue at the last meeting and afterwards on the mailing list, it was not conclusive. Some people thought the text was not explicit enough, while others thought it constrained RTP too much, so perhaps the level is about right. One example where it was claimed RTP shouldn't necessarily be fair to TCP is when a person is watching streaming video and then wants start an FTP in the background. The desired behavior is for the video to come through cleanly while the FTP gets whatever bandwidth is left. However, if the person watching the video shares the network link with a neighbor trying to send in a Internet Draft just before the deadline, the choice may not be the same. The decision can't be simply based on the protocol. Therefore, it is difficult to be specific about the rules.

Henning Schulzrinne asked whether a web browser using four parallel TCP connections should get four times as much bandwidth as a video connection? Reha Civanlar argued that if the text doesn't specify at least the interval over which the data rate is measured, then an implementation can claim compliance by averaging over a very long interval that obscures shorter periods of congestion, so the requirement is meaningless.

Sally Floyd disagreed, saying that the existing paragraphs correctly specify behavior in general terms. Anyone reading the RTP spec should know that RTP is not a complete package; they should not think that if you use it without congestion control you are free to do a massive deployment that competes with TCP traffic in the current Internet, because you are not blessed to do that. Responding to Henning's question, we are talking about an order-of-magnitude comparison to TCP. TCP it is not perfect, but it is reasonably fair with itself. If one wanted to deploy a new kind of traffic that used large amounts of FEC and some different method of congestion control that did not, over some reasonable timescale, compete fairly with TCP by an order of magnitude, then that is not good. It is not overstretching to say that in these documents.

Steve Casner said the decision about which packets should be given priority needs to be indicated in another way, such as IntServ or DiffServ mechanisms. Ultimately the routers will be required to enforce fairness conditions. No matter what we say, some implementors will not pay any attention to it and will send whatever they please. He asked for a "hum" from the meeting participants regarding the appropriateness of the existing wording. The response was fairly strong in the positive and very little in the negative, so we will keep the wording roughly as it is.

Colin Perkins reported on the status of RTP interoperability testing. There has been good progress since last meeting, especially with codecs in the A/V profile. Several people have come forward with implementations, and we thank them. The bad news is that we have not finished yet. See draft-ietf-avt-rtp-interop-05.txt for the list of remaining items.

Dave Singer said his group has implemented several of the codecs still on the list and asked for others to test with. Steve Casner wondered whether extension mechanisms such as SDES PRIV might be allowed without implementations since they may be needed in the future even though they have not been used yet. Another item of particular concern is the RTCP timer reconsideration rules in the RTP spec. The working group spent a lot of time developing these rules, and we don't want to remove them. There are at least two implementations (in RAT and LiveCaster), but testing them thoroughly is difficult because they are intended to handle simultaneous joins or leaves by a large number of participants. Perhaps testing of proper operation on a small scale combined with simulation results for the large scale (as published some time ago) would be sufficient.

In order to proceed with the advancement of the RTP spec and A/V profile, revised versions of these drafts will be issued by January 31 with the incomplete features and codecs removed.

New Payload Formats

Ladan Gharai described the changes in the payload format for SMPTE 292M video since the last meeting. The biggest concern for this payload format is to accommodate the unusually high 1.5Gb/s data rate. The normal 16-bit RTP sequence number is extended to cover more time before wrap-around. The extension field has been increased from 10 to 16 bits, and the field indicating the byte offset within the frame has been removed to make room. Instead, a constant packet size is stipulated so that the offset can be calculated from the sequence number. The "extended sequence number" field in RTCP is specified to be the same as this extended sequence number in RTP. The RTP timestamp clock rate is 10Mhz.

This payload format takes advantage of the change in the RTP spec allowing the minimum RTCP interval to scale down below 5 seconds for high data rate streams so that the statistics can be meaningful. However, this does not avoid the problem of the sender's octet count wrapping in 23 seconds and the 24-bit count of packets lost saturating after 93 seconds worth of packets are lost.

MIME and SDP specifications have been added to the draft. The authors are corresponding with representatives from SMPTE who are concerned about a potential conflict in MIME types. The authors are waiting for last call on this payload format until the implementation is completed.

Before the meeting, two drafts were posted for the EVRC speech payload format, but the authors merged them into draft-3gpp2-avt-evrc-01.txt which was presented by Adam Li. This RTP payload format is needed for video streaming and conferencing services in cdma2000. The combined draft mostly follows the -00 revision, but adds a per-frame header byte to indicate the frame type and to signal a rate reduction request. For native transport of EVRC over the wireless link, the frame size is deduced from the change in channel bit rate per frame time. For RTP this won't work because packet delays may vary, and one packet may contain frames of different types. That means the payload type field cannot indicate the frame type, either.

At the end of the discussion, it was brought to our attention that the December 1, 2000 revision of the ITU-T H.225.0 spec includes an RTP payload format for EVRC that is totally different from this proposal. The authors were unaware of this, but will investigate and report back.

We discussed two presentations on payload formats for AMR audio. One is a WG work item (draft-ietf-avt-rtp-amr-01.txt) that is the result of merging of three drafts discussed in previous meetings. Johan Sjöberg explained the differences from the previous draft which included simple changes to the payload header along with improvements to the text. There are a few minor errors in the text that still need to be corrected. Colin Perkins commented that the text on redundancy was less clear since the merge.

The other proposal draft-xie-avt-et-rtp-amr-02.txt by Qiaobing Xie is similar but adds an optional 8-bit CRC to each codec frame. Both proposals intend to take advantage of link layers that can deliver packets with partial damage, assuming a transport protocol such as UDP-Lite that does not checksum the part of the packet in which damage can be tolerated. The primary difference between the proposals is that the first one specifies that the portions of the audio frames with different error sensitivities will be sorted so that the important parts of all the frames go into the packet first where they can be protected by the transport layer checksum. The second proposal avoids the sorting but spends additional bandwidth on a separate CRC field for each frame plus a bit to indicate whether the CRC is present. The separate CRC's allow damage to be detected separately for the important bits of each frame, whereas the sorting method results in all of the frames being discarded if any has an error in the important bits. However, the authors of the first proposal consider the extra overhead of the per-frame CRC to be unacceptable, especially given the "imperceptible" improvement in sound quality provided. On the other hand, that same improvement is given as the justification in the first proposal for a 'Q' bit in the header to indicate when frames containing errors are gatewayed from a non-packetized link to RTP.

Bruce Thompson questioned whether such links and transports will really exist, so all this may be moot. The primary example is for planned wireless networks. Does it make sense to specialize a payload format for operation on a particular type of link? Over a path with several links, how will endpoints know whether or not it makes sense to add CRC's? We decided the questions weren't likely to be resolved in the meeting. In a separate discussion after the session, the authors of the two proposals agreed to work out a way to fit the CRC indicator bit into the other payload format header.

Low-Delay RTCP Feedback

Jörg Ott presented the results of discussions on RTCP-based feedback and retransmission that were held among the authors of a collection of different proposals after the AVT session at the previous IETF and in the interim. The authors agreed to gather the common requirements in the various proposals and applications into a base spec that defines timing and generic message formats. Then separate extension specs should deal with the specific requirements of particular applications. The base spec would be a new RTP profile that is an extension of the existing RTP A/V profile. The most significant change is the elimination of the five-second minimum interval for RTCP while maintaining the overall bandwidth limit of 5% of the data bandwidth. The timing rules vary with the group size, although the boundaries between modes are not strict. The smallest groups can send feedback messages immediately when events occur; medium-sized groups would only send some events, limited by bandwidth; and above some size, only normal RTCP packets could be sent. The boundaries are not strict, but are based on RTCP bandwidth available.

Open issues include:

- Should there be a SDP parameters to specify the expected group size and what modes of feedback are allowed?
- Is it reasonable to limit damping of responses (implosion suppression) to let sender see that many receivers got an error?
- What are the implications for RTP congestion control?

Henning Schulzrinne expressed concern about how this interacts with timer reconsideration. Correlated loss events could cause excessive feedback. Also, any manually configured (SDP) group size is bound to be wrong; this is very dangerous. When timer reconsideration was being developed, the group size parameter was found to be not very helpful even as an initial estimate. Jörg said more work is needed on these aspects. Also, the timing rules currently specified in draft-wenger-avt-rtcp-feedback-01.txt need to be restructured into an extension of the profile.

Carsten Burmeister presented draft-fukunaga-low-delay-rtcp-01.txt which describes the basic feedback packet formats. Full RTCP packets would be formatted as in the spec, but event feedback packets would be compounded with only a minimal SR/RR packet or perhaps without compounding if that is allowed. Feedback messages would be classified into transport layer messages such as NACK, payload specific messages, and application layer feedback such as NEWPRED for MPEG-4. The different message types would be indicated by different packet type (PT) values.

There was some discussion of how and where congestion control is specified. Jörg said that specifying congestion control for this new profile would be dependent upon the specification of congestion control for RTP in general. Steve Casner responded that the RTP spec was not going to define congestion control any more exactly because it is dependent upon the applications like this RTCP feedback! Steve asked whether we should expect more before the next meeting? Yes.

Sally Floyd commented that for TCP-friendly rate control (equation based rate control), would need feedback messages at a one-per-RTT rate. She and Mark Handley plan to write about this.

Header Compression/Multiplexing

Tmima Koren gave a quick update on four drafts related to RTP header compression:

- CRTP over AAL2 has been generalized to PPP over AAL2, and so has moved to PPPEXT working group.

- Tunneling Multiplexed Compressed RTP (TCRTP) has a new section added to describe the minimum control plane negotiation required. It is proposed that this draft go to working group last call. Steve Casner noted that this draft is AVT's proposal for how multiple RTP streams should be multiplexed, in preference to the application-specific multiplexing proposals that were considered in AVT earlier.

- Enhancements to CRTP (RFC 2508), which are needed for TCRTP to handle the lossy, long delay tunnels. Only one new enhancement since last time, which is a new CONTEXT_STATE packet signaling a change between N mode and ACK mode. The parameter N is suggested in this signaling, but the compressor ultimately makes the decision. This draft also believed ready for last call.

- CRTP over PPP, an extension of RFC2509. New suboptions for the IP Compression Protocol option for the CRTP protocol are needed to indicate which of the enhancements will be used. Steve Casner commented that this needs to be discussed in PPPEXT, as 2509 was.

Carsten Bormann suggested that there be a "changes" section be added to call out the differences relative to the RFC's (this is usually a requirement when revising a standards-track RFC).

Based on advice from Scott Bradner, the plan for advancing RFC 2508 to Draft Standard is to submit it along with the RTP spec and the other related documents, and then the enhancements will be treated as a new version of CRTP with a Proposed Standard status.

Payload formats for unequal error protection

An RTP payload format for Erasure-Resilient Transmission of Progressive Multimedia Streams (draft-lnt-avt-uxp-02.txt) was presented by M. Wagner. This draft was presented at the previous meeting but with a statement that it was not offered in accordance with RFC 2026. That was due to a misunderstanding which has now been corrected. The primary change from the last presentation is that there is now inband signaling of the redundancy profile to allow adaptation to the link conditions. Will be developing by February, 2001 a comparison to the proposal for unequal error protection from Adam Li. This was promised to the ITU SG-16 committee which is considering these proposals for H.323 Annex I and which will be meeting in March. Stephan Wenger commented that neither of the two proposals has real momentum yet, and that in fact the inclusion of Annex I is not assured, so there is no need to rush our consideration of these proposals.

Adam Li presented an RTP payload format for Generic FEC with Uneven Level Protection, draft-ietf-avt-ulp-00.txt. This proposal is an extension to RFC 2733, the payload format for Generic FEC. The only difference in the FEC header is that the E bit (extension) is set to indicate that unequal level protection headers follow. The changes in this revision were primarily editorial plus the addition of examples. Steve Casner recommended that the example be reformed to show field values in a higher radix rather than the binary representation of all the bits as currently shown.

Steve Casner asked about the status of the project. Simulations have been done, but the real implementation is not completed yet. Li asked whether one of the two proposals would be selected or both would advance or alternatively if there would be a push to try to merge them. Steve Casner responded that any of those choices was possible, depending upon whether one performs better than the other or whether there are different situations that favor one or the other. Jonathan Rosenberg requested that an extension bit be added within the header of this extension, to allow the possibility of further chaining to another idea in the future. Colin Perkins asked if this should go forward as an extension of RFC 2733, or to obsolete it -- the former.

Transport of meta-info with RTP streams

Two new payload format proposals were presented for carrying meta information related to an RTP stream, but at different levels. The first, draft-serenyi-avt-rtp-meta-00.txt presented by Denis Serenyi, is to encapsulate and enhance existing payloads by adding payload-independent information. The motivation is to provide additional information such as send timestamps for the packets to facilitate rebroadcast of the stream by caching proxies or reflectors. The structure of the payload is a sequence of type-length-value fields. Some fields are defined in the draft, while others may be defined elsewhere. Use of this payload format requires negotiation through a protocol such as RTSP or SDP, with the introduction of new attributes to give the details of the underlying payload. There are a number of open issues with this proposal.

Steve Casner questioned whether it would make more sense to send the full source file via TCP for the non-live case. For the live case, he questioned whether a send timestamp is really needed since packets would be processed as they were received. Colin Perkins asked about sending this information as a separate stream to avoid fragmentation and backward compatibility problems. Should have a discussion of the pro's and con's in the draft.

Jack Brassil presented the second proposal, a payload format for Program Queues in draft-brassil-avt-cues-00.txt. This proposal does not send information associated with each packet. Instead, it is used to communicate events whose precise timing is significant to receivers. Examples of such events would be signals to control local program recording, ad insertions, and notifications. Similar cue information has been transmitted as an adjunct to traditional broadcast channels. Cues could be inband in a stream distinguished by payload type, or as a separate stream. The payload format would establish some conventions, but would be highly dependent upon the applications. May want to use redundancy or other reliability enhancements being discussed for RTP. There are open issues related to authentication, specification with SDP, etc.

Steve Casner said that sending DTMF inband with an audio stream makes sense because the tone replaces the audio for an interval of time. Here, inserting the program queues into the sequence number space of a media stream may cause problems for packet loss or rate accounting in RTCP. Sending with a separate stream (using a different SSRC) would avoid those problems and would still allow synchronization using the standard RTCP mechanism.

Colin Perkins commented that we should carefully examine how these two proposals for meta information overlap. It may not make sense to combine them, but if both were to exist we'd want to understand how they would interact.

RTP Encryption and Authentication

The existing RTP spec includes a rudimentary encryption method, but defers to underlying layers for authentication. The spec also provides for the possibility that additional security mechanisms may be defined using encrypted payload formats. This latter method is proposed in new drafts presented at this meeting.

Elisabetta Carrara gave a presentation related to two drafts, draft-blom-cmsec-3G-00.txt and draft-blom-rtp-encrypt-00.txt. The first covered requirements arising from the limitations of the 3G wireless link. The requirement to allow header compression leads to the choice of encrypting only the payload and leaving the RTP header in the clear. Similarly, the bandwidth cost of a MAC field leads to a requirement that authentication be optional. Security profiles may be used to find the right tradeoff between cost and security for a particular application.

The specific proposal to provide confidentiality service for the media session uses the "f8 mode of operation with AES". This technique can use information from the RTP header to maintain sync for the block cipher. Adding a MAC per packet remains optional because the cost is deemed unacceptable. Realtime aspects of this use in a conversational mode make attacks difficult, but the primary threat is denial of service by forcing the receiver to decrypt packets at a high rate. Encryption of RTCP has not been addressed yet, and key management is still an open issue.

The second proposal has a number of similarities. As currently specified, it requires authentication which the first group considers too expensive. However, before the meeting, both groups discussed the similarities and differences between their drafts and agreed that it would make sense to merge them.

The second security proposal, draft-mcgrew-avt-srtp-00.txt, was presented by David McGrew. It is named SRTP and is structured to fit into the RTP framework as a profile that extends the existing A/V profile to specify how the MAC is stored in the packet. It uses "AES Counter Mode" rather than f8 mode, but both methods are deemed acceptable. Want to make the process of spurious packets as fast as possible to be resistant to DoS attacks. As currently specified, the encryption begins immediately after the SSRC field (including the CSRC list and header extension), but since this is in conflict with the header compression goal, this can be changed. The four-byte UMAC authentication tag is considered sufficient for voice and would preclude replay attacks such as inserting "yes" in place of "no".

To merge the two proposals, the authentication would be made optional and the cryptographic algorithm selectable. There are open questions of where the encryption should start (before or after header extension) and how keys and initialization vectors should be handled. Steve Casner commented that the use of the RTP header extension is intentionally minimal, e.g., for experimentation. Therefore, it would make sense to move the start point for encryption to the end of the RTP header in full, i.e., the beginning of the payload, to minimize confusion and eliminate any question about what parts of the header may be included in header compression. A related comment was that some protocols for header compression can compress the AMR header octet that comes first in the payload. Therefore, it would be beneficial to have the encryption start point be variable. This would require signaling.

Using a rollover counter on the sequence number as the means to synchronize the stream cipher has the consequence that if 65536 packets in a row are lost then sync is lost. It may be possible to communicate the rollover counter securely in RTCP to guard against this loss of sync.

Steve Casner commented that structuring this security spec as an RTP profile is exactly the right thing to do. It provides a place to specify all the processing rules, in addition to the MAC placement. Are we likely to get pushback on the use of application level security versus IPSec? The motivations are clearly stated, but we should expect some pushback.

MPEG-4

Colin Perkins gave a short status update on MPEG-4 payload formats. In Pittsburgh we resolved to publish the Elementary Streams draft as a proposed standard and publish the two Systems Streams drafts as experimental to gain implementation experience to guide a choice. Through accelerated processing, the Elementary Streams draft was published as RFC 3016 in time to meet the ITU deadline. However, we did not issue last call on the Systems drafts because work in MPEG is leading towards a single Systems payload format and a framework document which were discussed in this meeting.

On the framework document, Dave Singer asked for comments on the MIME
registrations it contains.

Philippe Gentric presented the MPEG work on a Systems payload format. The goal is to handle any Synchronization Layer (SL) stream with a single payload format. The original idea was to map one SL packet to one RTP packet, removing redundancy by mapping SL header fields to RTP header fields. This proposal is the Systems payload format that has been under consideration in AVT for some time.

A problem is that this is too inefficient for very low rate video streams because of the overhead of IP, UDP and RTP. The solution was to allow multiple SL packets to be put into on RTP packet. Upon further examination, other changes were deduced. Another change is that the MPEG-4 sequence number is no longer correlated to the RTP sequence number.

The SL headers from all the packets are concatenated immediately following the RTP header, followed by all the SL payloads concatenated. The SL header provides the length of the SL payloads so they can be parsed. The SL headers use difference values from header to header rather than absolute values to allow a more compact SL header representation. It will also be possible to do interleaving using SL sequence numbers.

There is a rapidly evolving draft based on joint work between MPEG and IETF. The goal is to proceed to IETF standards track as soon as possible. The MPEG committee work is to be completed by January.

Dave Singer gave a brief comment about the Internet Streaming Media Alliance which was recently announced. Some people are concerned that this group may be in competition with IETF. However, ISMA intends to simply coordinate vendor use of standards from IETF and other bodies, and feedback information to those bodies when problems are discovered. The relationship is intended to be one of cooperation, not competition.

The meeting concluded with a recap of the action items and a call for acceptance of new work items. Those present hummed (but not loudly) that all of the new drafts should accepted as working group work items. This needs to be confirmed on the mailing list, however, so anyone who believes any of these proposals are not appropriate for AVT work items is requested to comment on the mailing list.

Slides

RTP Payload Format for Program Cues
Low Delay RTCP Feedback Format
RTP Encryption for 3G Networks
AVT Agenda
MPEG-4 RTP Transport
CRTP Status
An RTP Payload Format for EVRC Speech
An RTP Payload Format for Generic FEC with ULP
The Secure Real Time Protocol
'draft-wenger-avt-rtcp-feedback-01'
MPEG-4 on IP: Status Update
RTP Interoperability Statement
RTP Payload Format for Payload Meta-Information
RTP Payload Format for AMR
An RTP Payload Format for Erasure Resilient Transmission of Progressive Multimedia Streams
Error Tolerant AMR Speech Payload