2.8.1 Audio/Video Transport (avt)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

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

Done

  

Submit RTP MIB to IESG for publication as Proposed Standard RFC

Done

  

Submit guidelines for payload format writers for publication as a BCP

Mar 99

  

New working group last call on PureVoice payload format

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

Done

  

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

Done

  

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

Jul 99

  

Prepare MPEG4 implementation results ready for WG last call

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

RFC3047

PS

RTP Payload Format for ITU-T Recommendation G.722.1

Current Meeting Report

Audio/Video Transport Working Group Minutes

Reported by Colin Perkins.

The Audio/Video Transport working group met twice at the 50th IETF in Minneapolis. In the first session, we discussed advancement of the RTP specification and audio/video profile to draft standard, also a number of new profiles for secure RTP, unicast RTCP feedback, and low delay RTCP feedback were discussed. In the second session, we discussed RTP payload formats for generic FEC with ULP, AMR, EVRC, Vorbis and MPEG-4.

The meeting opened with a status update by Steve Casner. It was noted that there have been a number of problems with the working group's mailing list <rem-conf@es.net> and it was proposed to move the mailing list to be hosted at ietf.org. Such a move will inevitably be somewhat disruptive, but it was thought that this is better than the current problems, with some messages getting lost, the archive copy to the IETF secretariat not working, and subscription/un-subscription being problematic. Hearing no objection from the group, the chairs plan to transfer the list, and announce the move on the current mailing list and on ietf-announce. Subscription to the new list will NOT be automatic: once it is announced, you will have to manually join (this is because there is no way to get the membership of the current list).

The group has had a single RFC published since the last meeting: the RTP payload format for G.722.1 audio (RFC 3047). The RTP payload format for DV video is with the IESG; the RTP payload for DV audio has been returned to the authors for revision to edit for clarity. In addition, the authors have determined that changes are needed to specify the ordering of bits/samples, to specify a fixed set of compound symbols for the channel order parameters, to describe the handling of 0x8000 in L16 mode (it is an error indication). These revisions are expected to be completed shortly, at which time a brief working group last call will be held before the draft is sent back to the IESG. The more loss tolerant RTP payload format for MP3 audio was sent to the IESG, but withdrawn when implementation work at Apple found some areas which needed clarification. After editorial changes, the draft has now been resubmitted to the IESG for last call.

The Secure Real Time Transport Protocol (draft-ietf-avt-srtp-00.txt) was presented by David McGrew (this draft is the result of a merger between two similar proposals presented at the previous meeting). David started by showing that the performance of the scheme on a 500 MHz Pentium II shows a normal throughput of 106.2 Mbps and a rejection throughput of approximately 7.5 million rejections per second, showing performance is not expected to be an issue.

Regarding the protocol, a couple of interaction with RFC 1889 were noted. Some have suggested that section 9.1 of RFC 1889 should be applied to SRTP, but since the encryption prefix offers no security advantage when used with current SRTP the authors propose that it is not used. It was also noted that selective encryption of RTCP compound packets is specified in RFC 1889, but this is not currently included in SRTP. Should it be included? Steve Casner noted that this depends on the application scenario.

The issue of multiple senders and key reuse was raised. Since the SSRC is used in the encryption context it is necessary to guarantee that the choice of SSRC is unique, or it is necessary to use a different encryption key per sender. Jonathan Lennox noted that, with light-weight multicast sessions, collisions cannot be avoided, and maybe we need wording in the RTP spec that applications should listen during the period before their first RTCP and change their SSRC if the chosen one is heard? [It is already there in section 8.1 of RFC 1889.] This would reduce - but not eliminate - the chance of collisions. David McGrew noted that there's a legitimate chance of a loss of privacy due to this issue.

It was noted that the UMAC message authentication scheme specified may not be widely implementable. Ross Finlayson asked about the Tesla scheme coming from the MSEC working group. Bob Briscoe noted that this draft needs to state its applicability: it doesn't authenticate the source, just the group (this is not stated in the draft). He will suggest wording changes to reflect this concern. Bob Briscoe also asked if Tesla should be included in the spec? Maybe, but he doesn't want to hold up SRTP for this. Ross Finlayson noted that he thinks source authentication should be part of the spec.

The issue of video on demand and multiple keys per SRTP session was raised, as previously discussed on the mailing list. Is there a possibility of changing encryption keys without changing the RTP sessions? It may be necessary to identify each distinct key with a range of packets. Steve Casner noted that we have the notion of changing the SSRC anyway, so the key distribution can indicate that the SSRC will change with the encryption key, hence this shouldn't be a big issue.

SDP parameters need to be defined to signal SRTP and the key to be used. A revised draft will be produced shortly, and it is expected that this will be ready for last call by the time of the next meeting.

Julian Chesterfield presented an RTCP extension for source specific multicast sessions (draft-chesterfield-avt-rtcpssm-00.txt). This allows receivers to unicast their RTCP back to the source, which summarises and then multicasts the information to the group. There are two suggestions for how this summary should be conveyed: 1) an RTCP sender report, modified so that each report block corresponds to a report from a receiver; or 2) a new sender summary report, which is similar but has the RR timestamps removed prior to forwarding, saving 8 bytes per report. The draft also contains a modification to RTCP bandwidth allocation, so the backchannel is included in the allocation (this turns out not to be needed). Considerable interest was expressed in this work, and a number of comments and suggestions were noted:

- When forwarding RTCP data from the sender, multiple reports can be chained into a single packet, hence receivers must be prepared to handle RR data from multiple sources in a single RR packet. The inclusion of SDES packets containing, at least, the CNAME was suggested.

- It is desirable that this is not limited to SSM, hence signaling will be needed (e.g. by SDP). Bob Briscoe asked if any analysis has been done to establish if this is more or less efficient than standard multicast RTCP. Steve Casner answered that it won't be more appropriate for a true multisource application.

- Additional security concerns, such as source address spoofing, need to be considered (packet bombing of the source, etc).

- Is there enough benefit to having a summary sender report? Steve Casner was unconvinced: there are problems with the calculation of the reporting interval if the packets are aggregated (since the bandwidth the receivers see is less than that the sender sees, which leads to an artificially lower reporting interval). Steve also noted that redefining the meaning of an existing report type could lead to problems, and that it is better to define a new packet type (there is no shortage of RTCP payload type identifier).

This work has the potential for wide use and merits further development. The author is working on implementation in the UCL RTP library, and is aware of two other implementations.

The two drafts specifying timing rules and packet formats for a new profile for low-delay RTCP backchannel information were revised for this meeting, but have not yet been merged as was planned at the last meeting. This is to be done in mid-April. The first of these discussed concepts and timing rules (draft-wenger-avt-rtcp-feedback-02.txt) and was presented by Joerg Ott. There have been a number of changes since the last meeting: the timer reconsideration section has been checked, and found mostly okay, various video specifics have been removed into an appendix (which may disappear in future), the group size indication in SDP has been removed, and the need for congestion control is noted (to be dealt with in the feedback usage drafts).

Regarding timer reconsideration, feedback was solicited especially on the numbers for T_dither_max: are these sensible? Steve Casner said that they seem reasonable, but noted the danger in picking arbitrary numbers when the application may scale to a range of scenarios. Colin Perkins asked if the TFRC work had anything appropriate? Experimentation may be needed.

When to send an immediate/early RR was also discussed: need reconsideration in the case where the group size has changed between message scheduling time and the time the message is sent.

The next steps are some editing including aligning variable names with the RTP spec. The the draft will be resubmitted as an AVT WG draft, aiming for last call in April 2001. Feedback is solicited.

The chairs noted that this doesn't make a profile by itself; it needs to be merged with the packet format drafts (discussed later). It also needs simulation to prove the timers work correctly without causing packet storms, congestion, etc.

Carsten Burmeister then led discussion of the RTCP feedback packet format draft (draft-fukunaga-low-delay-rtcp-02.txt). Changes include a new section on reaction to feedback, congestion control recommendations and how a sender should react. The "general feedback behaviour" section has been deleted, since it is covered by Joerg's draft.

Steve Casner thinks thought the words on congestion control and reaction to feedback are too vague and unconvincing. Maybe we can't consider this work complete until we have an algorithm defined and tested? Especially in this case, where we have closed loop congestion control.

Maybe we can go to experimental for now? We should expect pushback from the IESG if we try to go to proposed standard without words on congestion control. Magnus Westerlund noted that the draft defines two types of feedback: one for general applicability, another for specific functions. The specific functions need specific congestion control; the general case can have more general words? Reha Civanlar asked what is the acceptable congestion control so that we don't get pushback from the IESG? RFC 2914 (although we couldn't remember the reference at the time...). Discussion of the correct status continued for a while, with it becoming clear that the authors did not favour experimental. Outcome: complete the documents, and we'll ask the AD's for their opinion.

Carsten Burmeister then presented an RTP Retransmission Payload Format (draft-ietf-avt-rtp-selret-01.txt). Note that IPR exists on this draft. The draft has changed since the last meeting, and now comprises two parts: 1) an RTP payload format for retransmitted packets which implies that retransmissions get a new sequence number from the original space, so their loss can be detected (the original seqnum is sent in the payload header); 2) a low priority payload format with a different sequence number space for the "important" packets which is used to enable receiver to report only important packet losses.

Open issues include: non-constant SN-TS relation when retransmissions occur (but this also occurs due to silence suppression, so this is not a problem), and gaps in the received sequence number space (as seen by the application, not in the RTP packets) once the data has been recovered (this is an application design issue, not a protocol issue).

Since this depends on the RTCP feedback profile, it cannot advance until that is complete. There followed more discussion of the need for congestion control, and where congestion control should be specified. When asked, Joerg Ott noted that it might be better to avoid tying the timing rules draft too closely to the rest of the RTCP feedback profile. Steve Casner noted that many users would want to use them together, so why not a combined document? Joerg noted that there are advantages in allowing the possibility of other timing rules. After some discussion, the consensus emerged that a single profile should be produced, which has explicit discussion of usage of the timing rules, and that the RTP retransmission work should advance as a draft which uses this profile.

The next section of the meeting was devoted to the revision of the RTP specification and audio/video profile, which have now completed a second working group last call. These drafts have been updated with new text on congestion control, to address concerns raised at the last meeting. This now references RFC 2914 for background information, and clarifies that fairness with TCP is measured on a "reasonable" timeframe, and is intended to be "order of magnitude" fairness. The consensus was that this text is "definitely better", and so the spec will be submitted to the IESG with this text as it is.

Regarding the RTP interop matrix, good progress has been made: most items are either tested or have tests promised. Unfortunately, a few were not tested and have been removed from the spec (primarily the following codecs: 1016, G.723, GSM-HR, GSM-EFR, MP2T, H.263, BT.656, MP1S, MP2P, BMPEG). The chairs aim to complete all interop testing by April 15: Colin Perkins and Magnus Westerlund have promised to complete some outstanding tests by that date, others who are testing are also urged to complete their tests by then also (G.723 and H.263 have since been tested and reinstated).

In discussion of the outstanding tests, Jonathan Lennox said that he has a program which converts RTP/UDP into RTP/TCP. If anyone else has an RTP over TCP implementation, he is willing to test with then, to re-instate this feature.

It was noted that Cisco have an implementation of the missing GSM mode(s?), and will do some testing with Magnus Westerlund.

Glenn Parsons asked about the use of audio/32kadpcm (used in VPIM) versus audio/g726-32 (as specified by the A/V profile). Are we tied to the particular name? Yes, use is already established. Steve Casner will edit our registration for G726-32 to make a cross-reference to the other registration (noting the two MIME types imply different transports).

Steve reminded the group of a number of other issues which have been raised during the last call: Harald Alvestrand asked if the RTP spec as written precludes the use of SSM? No, but we have extensions in progress to better support this. Magnus Westerlund noted that the requirement for an SDES CNAME in every RTCP packet was wasteful and insecure in the case where RTCP is split into encrypted and unencrypted packets. The spec will be edited to clarify that it's not needed in both packets.

There are several of companion drafts which are also complete, and last call will to be issued shortly: testing strategies, bandwidth modifiers, comfort noise, and MIME registration. Once the RTP interop results are done, on April 15th, RTP and the A/V profile will be passed to the IESG for last call for draft standard.

Jonathan Lennox asked if there are people interested in a particular payload format, but don't have interop results, can that payload format spec be split out into a separate proposed standard RFC? Yes.

Once the RTP specification has advanced, it is also necessary to advance RTP header compression (RFC 2508) to draft standard. Carsten Bormann noted that moving RFC 2508 to draft standard requires RFC 2507 and RFC 2509 to go forward also. He's not sure that the authors of those drafts would want them to go forward, and wants discussion of ROHC vs CRTP to happen before we set milestones for advancing these. Steve Casner wondered when and where should this be discussed? Carsten also noted the problem that RFC 2507 TCP compression is rapidly becoming historic. Also not all the proposed enhancements to CRTP are needed for TCRTP. We should try to figure out which make sense, and maybe just advance those? No consensus was reached: we need to discuss this further.

Moving into the second day, the RTP payload format for Generic FEC with ULP (draft-ietf-avt-ulp-00.txt) was presented by Adam Li. The author asked for suggestions on how to add the extension flag to facilitate future expansion (e.g. as in RFC 2733), but no spare bit exists in the header. Options are to add an extra byte between FEC header and level zero header, or to shorten one of the fields by one bit. Jonathan Rosenberg seemed to prefer the second approach, but Steve Casner noted that trying to shoe-horn an extension which won't fit is unwise. An alternative is to have a different extension to generic FEC, rather than extending this format. It was agreed to keep this ULP proposal as is.

Simulation results were presented, showing performance of H.263/ULP with with random packet drop and various MTU sizes, using a rate distortion curve to measure the effects of loss. Stephan Wenger said the curves are impressive, but have a systematic problem since adding ULP adds bits, but adding bits give the increased possibility that the protection data gets lost. Jonathan Rosenberg noted that this is included in the data. Colin Perkins asked if random loss was the only loss model they have used, or if more realistic choices have been used? Random loss is the only test (someone suggested the Gilbert model as an alternative).

Luca Martini gave a brief overview of the SONET over RTP proposal, which is under consideration in the PWE3 working group. This is one of the proposals for pseudo-wire emulation in PWE3, but they are also considering other solutions and there is an alternative MPLS-based proposal with reduced headers relative to RTP. Members of the AVT working group are encouraged to follow the work in PWE3, since there could be considerable overlap with RTP (the PWE3 group will have an interim meeting between now and next IETF - possibly end of May.)

Magnus Westerlund presented the combined RTP payload format for AMR and AMR-WB (this is a combination of the two drafts mentioned on the agenda). The motivation is to have the same payload format for AMR-WB and AMR-NB, supporting the frame interleaving for AMR NB as well. After a brief description of the combined solution, Magnus noted that the biggest issue is the split into two modes, bandwidth efficient and octet aligned, which can lead to interop problems: both modes SHOULD be implemented. In addition, robust sorting, CRC and interleaving are OPTIONAL but their support must be signaled, this also has the potential for interop problems.

It was noted that 3GPP is very keen to see this advance to RFC status, and that a new draft was to be produced within a week (since the meeting this has become available as draft-ietf-avt-rtp-amr-06.txt).

Steve Casner asked if it would be better if the X and S bits were sent out of band since the mode is not likely to change during the session, thereby also saving a couple of bits in the payload. Magnus agreed with X but not with S since you may want to switch sorting during the session. Much discussion ensued, with little consensus emerging.

Qiaobing Xie asked about the two tables in the current draft which show mode and rate mapping: those mappings might change in 3GPP, why not refer to that draft? Magnus replied that the 3GPP spec will be approved before this goes to proposed standard, so don't expect this to be a problem. The number of class A bits is also an issue, since this is informational in 3GPP, and left to operator choice. Not sure it can be specified in 3GPP. Steve Casner asked, in that case, why is it reasonable to specify it here? We don't want to specify an aspect of codec operation which is the domain of another standards body. Magnus replied that we need to discuss this with other 3GPP folks. Qiaobing suggested moving the table into an appendix to make it clear that it's not part of our definition? No conclusion was reached.

The RTP payload format for EVRC speech (draft-ietf-avt-evrc-01.txt) was presented by Adam Li. After providing a summary of the codec, Adam noted that it was brought to our attention in San Diego that the ITU has an alternative packetisation. After discussion and consultation with several ITU participants, it was decided to continue here, and take the result to ITU.

There were several changes from the previous version of this payload format. It now states that you SHOULD NOT bundle more frames than would fit into the packet MTU (rather than MUST NOT). The text stating "MUST never set the M bit" has been changed to "It is recommended that the marker bit should not be set". It is unclear what is to be gained by this. Perhaps it would be better to say that applications may choose to not set this bit to help with header compression?

The limit of 10 frames per packet has been relaxed: the number should be flexible, and signaled in SDP. Why does any maximum need to be specified? It is to accommodate buffer limitations on small devices. Steve Casner asked if this is not what the a=ptime SDP parameter is for? Philippe Gentric noted that same problem in exists with MPEG-4. The discussion continued for some time, about the possibility of using ptime instead, no conclusion was reached. The main concern is that ptime only recommends a length, rather than fixing a maximum.

The restriction that the interleaving index can never increase without changing SSRC was relaxed: it can now change as long as it does not exceed the value specified in the SDP (again, due to limited buffer space).

Why only one bit for "reduce rate" when there are multiple modes? Wouldn't you want to signal which mode to switch to? This was in an earlier version, but it was decided that only one of the modes is implemented in most cases, so one bit was sufficient.

The choice between a byte-aligned and non-aligned format was discussed at length, with a number of proposals: 1) reduce the header, so full rate frames fit without padding (but makes the start of payload non-byte aligned); 2) frame headers are shortened to 4 bits each and can be stacked together in a TOC at start of frame, providing a similar bandwidth saving to the first approach; 3) restrict to one frame per packet with no payload header. Steve Casner noted the tradeoff between greater flexibility or constraining to one choice. There is no absolute way to decide this question. Discussion ensued and was eventually curtailed due to lack of time, with the suggestion that it move to the mailing list. If conclusion cannot be reached the authors either have to make a choice and see if it is accepted, or accept that there will be multiple modes and implementers have to choose.

The RTP Payload Format for Vorbis Encoded Audio was presented by Jack Moffitt (draft-moffitt-vorbis-rtp-00.txt). After giving a brief overview of the Vorbis codec and payload format, the author noted that the big issue is transport of the code-books, which are variable size, large (up to 8k), and need to be sent reliably. Whilst it is certainly possible to send them at the beginning of a session, this does not handle changes during the stream (e.g. an Internet radio station is likely to need to send new codebooks when switching between pre-recorded tracks). There are a number of options: carrousel them, request via RTCP and resend, or send a code-book only stream.

Steve Casner noted that sending a separate stream makes most sense: if sent inline, the timestamps and sequence numbers of the data packets will be perturbed, and by sending out of band, we can use a different protocol (e.g. TCP or reliable multicast). He also noted that the M bit definition does not follow the convention for audio, and that there is plenty of room to carry the desired bit in the payload header instead so the M bit could be as usual. Stephan Wenger suggested that if you change codebooks on the fly, it is best to send them in a different transport stream. He asked is there anything in the headers of the data packet saying which codebook to use? How do you associate codebooks with data packets? Steve Casner suggested relating them to the RTP timestamp. Ross Finlayson asked if there is something in the frames which points to which codebook is used? Yes, but that indexes into the table which is updated by the codebooks which are sent, so it doesn't help much. Ross also agreed that using a separate protocol is the correct approach. Marshall Eubanks noted that the trouble with this is that any packet could, in theory, have a different codebook; and this can blow your bandwidth allocation. Steve Casner agreed, but noted that it doesn't matter if these are sent in one stream or two, since this bandwidth is the same in both cases. Henning Schulzrinne asked if there is a finite universe of codebooks, or is it infinite? (If finite, we can just send the index to the well known table and not worry about sending them at run-time). Jack Moffitt replied that the set of codebooks is infinite, so you can't just index into the fixed set. (There are tools to generating optimized codebooks.) Steve Casner noted that this is another reason for separate transmission, so you can cache codebooks or request them in advance.

Catherine Roux presented an initial RTP payload format for MPEG-4 FlexMux (draft-curet-avt-rtp-mpeg4-flexmux-00.txt). This is a very early draft, and there are many issues to be resolved: why is the signaling descriptor using a non-obvious range? Because those numbers are those used in FlexMux already (are other values valid?) The "a=mpeg4-flexmuxinfo:" SDP attribute should be an "a=fmtp:" attribute. The balance between in-band signaling and initialisation signaling has to be resolved. The FlexMux descriptors tag values assignment needs to be resolved. The dynamic FlexMux reconfiguration needs to be resolved. Steve Casner expressed concern about reliability requirements. Stephan Wenger noted that the draft is unclear about one channel with muxed data, or two channels (one for control, one for data). Stephan also noted that FlexMux data has to be an integer number of FlexMux packets and recommended that the authors look at the Gentric draft for fragmentation rules, etc.

The RTP payload format for MPEG-4 SL was presented by Philippe Gentric. He started by noting that a new profile, draft-gentric-avt-profile-00.txt was proposed, but abandoned since the use of additional marker bits broke header compression. Steve Casner said he hoped that header compression can be adapted to work with this sort of thing, since this profile could possibly have made transport more efficient (but these gains are nullified if header compression doesn't work).

Philippe described the other changes to the draft: description of transformation of SL headers into "mapped SL header" and "remaining SL header" portions. This makes the description much cleaner, and separates out those parts for which MPEG systems knowledge is required from those all applications are expected to know about. New SDP parameters are specified and the text clarifies when various SDP parameters are needed, which are optional, etc. This specification has been adapted so that for video streams in single SL mode you can make the packet format be identical on the wire to RFC3016. For multiple-SL mode, the headers are reordered so all mapped headers come before all remaining SL headers; several additional SL parameters were added.

Loss of BIFS packets is noted as being a problem, but a carrousel scheme exists in MPEG-4 (and the BIFS streams have random access points anyway). The draft also mentions reliable transport for the initial data.

Steve Casner noted that he has a couple of pages of editorial comments. The draft is getting there, but it's complex. To proceed: 1) the draft should not mandate use of SDP, instead it should specify the required parameters and give SDP as an example signaling protocol; 2) the scene description and loss discussion is not sufficient (Gentric disagrees, saying this exactly fits the design of the system). Stephan Wenger likes section 5.1 (BIFS) and section 9 (Examples). One technical issue: doesn't like mandating a non-random (zero) initial timestamp. He suggests allowing the initial timestamp to be random, and transmitting the offset in SDP instead? Steve Casner countered that the SDP may come from a different level of the application that has no way to know the initial timestamp. Stephan also asked about section 9.5.1 on inserting OCR: why is this needed? (This seems to be a misunderstanding of the draft - needs clarification).

The MPEG-4 Committee has forwarded a liaison statement saying the payload format for MPEG-4 SL streams is complete. Whilst major progress has been made, it is clear that there are a relatively small number of technical issues to resolve, and a fairly large number of editorial clarifications. We expect this to be completed by the time of the London meeting.

Charter bashing and other work was omitted due to lack of time. A message outlining the issues was sent to the mailing list, and a new charter based on this is under discussion with the area directors.

Slides

Agenda
Low Delay RTCP Feedback Format
Retransmission Payload Formats
MPEG-4 generic (Synch-Layer) RTP payload format
RTCP Extension for Source Specific Multicast
An RTP Payload Format for EVRC Speech
An RTP Payload Format for Generic FEC with Uneven Level Protection (ULP)
IETF/AVT meeting 21/03/2000
RTP payload format for AMR Narrowband and Wideband