Audio/Video Transport (AVT) Working Group Minutes ================================================= Reported by Colin Perkins The AVT working group met once at the 66th IETF Meeting (Montreal, July 2006). Subjects under discussion included codec control messages, the RTP payload and associated signalling for SVC, generic FEC for video applications, marking and retransmitting high priority RTP packets, the RTP MIB and RTCP XR extensions, time alignment using RTP feedback, and RTP header extensions. The meeting was chaired by Colin Perkins, Magnus Westerlund, Tom Taylor and Roni Even. 70 people signed the blue sheets. Introduction and Status and Charter Update The working group welcomed Roni Even and Tom Taylor as new co-chairs, and thanked Magnus Westerlund for his contributions. Magnus will step down as co-chair effective the end of the meeting to concentrate on his IESG role. The working group has not had any RFCs published since the last meeting, although the RTCP feedback profile (RTP/AVPF) and associated simulations, the revision to RFC 2032, and the H.224 media type registration are due for publication imminently, and the revision to RFC 2429, to obsolete RFC 2190, the EAC3, MIDI and retransmission payload formats, the framing for connection oriented transport, and the T.38 media type registration are with the RFC Editor. The G.729.1 and compact bundled EVRC payload formats, the SAVPF profile, the revisions to RFC 2833 and 3555, the ULP FEC scheme, and the protocol for header compression over MPLS are with the IESG for review. The AMR payload format revision is in working group last call. Rechartering discussion, to include the codec control messages and RTCP XR extensions is ongoing. A new proposal can be expected a few weeks after the meeting. It is proposed to set up an RTP Payload Format Directorate to co-ordinate effective review of payload formats and speed publication. Please contact Tom Taylor or Roni Even to participate, and help speed the group's work. Also, please read and comment on draft-ietf-avt-rtp-howto-00.txt, which aims to provide guidance to authors of new payload formats. Codec Control Messages draft-wenger-avt-avpf-ccm-04.txt Stephan Wenger presented the draft on codec control messages in RTCP. The topologies section has been removed, and will be submitted as a separate draft shortly (draft-wenger-avt-topologies-00.txt). Stephan expressed some concern that this makes the draft less accessible, but Magnus Westerlund and Colin Perkins disagreed, finding the split out draft helpful. This revision to the draft adds the ability to transport H.271 back channel messages. This capability is useful, but there is potential duplication of feedback methods between H.271 and native CCM messages, and H.271 messages might not be multicast aware. The draft includes rules to prefer native CCM methods where available, and to prohibit H.271 use in a multicast environment (Roni Even clarified that this includes multipoint scenarios). Dave Oran asked if there are multicast safe H.271 features: yes, but they are difficult to enumerate, since H.271 is extensible. However, all the multicast safe H.271 messages currently have native CCM counterparts. Colin Perkins wondered if the proposed rules are overly restrictive given some H.271 messages work with multicast: perhaps we should say "don't use this for multicast unless you understand x, y, z" rather than making a blanket prohibition (such guidance will also be needed for future IETF extensions to CCM). Steve Casner agreed that such a statement would be a good idea, and asked that it include examples of acceptance and non-acceptable use. Roni Even also noted that the draft doesn't discuss effects of H.271 feedback on the media stream - need to state "act within congestion control constraints". Stephan asked for the opinion of the working group on the addition of H.271 transport: Colin Perkins and Roni Even spoke in favour, and the sense of the room was to accept this feature. RTP Payload Format for SVC draft-wenger-avt-rtp-svc-02.txt Stephan Wenger discussed the RTP Payload Format for SVC. It was noted that a new patent application may relate to the draft (statement #736 in the IETF IPR database), in addition to the IPR relating to RFC 3984 which is also relevant. Stephan outlined changes since the previous version. These include making DON mandatory for layered multicast, and adding the PACSI NAL unit. Stephan noted that the aim is to align the draft with the latest SVC specification, and any non-alignment in areas applicable to IETF environments is a bug. There was some discussion on the appropriate demuxing point for layers. Steve Casner and Colin Perkins clarified that the preferred approach is to use a separate RTP stream for each separate layer but, if that's not possible, multiplexing based on SSRC is greatly preferable to payload type multiplexing. There was discussion on whether this payload format should include functionality to support middleboxes/MANEs, outside the signalling context, which intercept RTP packets carrying SVC and attempt to thin the stream based only on information available in RTP payload headers. There was very strong push-back against this proposal from the working group. As noted by Dave Oran, Colin Perkins, Steve Casner and Roni Even, a key design feature of RTP is that it relies on out-of-band signalling to negotiate payload format, connection and other parameters. Any device processing RTP streams MUST be within the signalling context in order to work reliably. The concept of a stateless device, outside the signalling context, that can manipulate RTP packets is fundamentally broken, and should not be supported. The issue of how to support fragmentation was left open, due to lack of time. This draft was accepted as an AVT working group item. Signalling of media decoding dependency in SDP draft-schierl-mmusic-layered-codec-00 Thomas Schierl discussed signalling for layered media sessions in SDP, following on from discussion in MMUSIC. Thomas began by outlining the motivation, design principles and mechanism (a new SDP grouping type, and a new SDP media attribute to indicate dependencies), before moving on to open issues for the AVT working group. One open issue is that a receiver that doesn't understand the signalling may try to process a subset of the layered media streams, and the result may be an invalid media stream. This doesn't seem a major problem, as receivers which don't understand the signalling won't understand the codec either. Another issue is whether media related information (e.g. sprop-param for SVC) should be signalled for full layer combination (of all depending media stream) or only the for the layers contained in the media streams. Stephan Wenger noted that this seemed to be an implementation detail and not something we need to specify. Steve Casner noted that pruning the stream is much larger than the work of pruning the SDP, so pruning the SDP is a good idea. There was some discussion on layer multiplexing, with the conclusions from the SVC discussion on the same subject applying. There will be a need to put guidance about layer multiplexing both in this draft and the SVC payload format. A generic payload format for FEC in video applications draft-bsong-avt-rtp-gfec-00.txt Hao Qin presented a generic RTP payload format for unequal FEC with interleaving for video applications. Stephan Wenger noted that one of the lessons learnt from 3GPP MBMS is that interleaving doesn't work with FEC since it assumes a particular loss distribution, and makes things worse in other case. He also noted that 2D interleaving requires large block sizes and can't use a simple FEC code. Dave Oran noted that the capability of putting the FEC in a separate RTP stream is important, but isn't supported by this proposal. Steve Casner noted that we already have a generic FEC payload format, and wondered what is the advantage of this over ULP, or over the work in the FECFRAME working group? In conclusion, there was no interest in pursuing this work in AVT. Any further discussion should happen in the FECFRAME working group. Marking and Retransmitting High-Priority RTP Packets draft-lennox-avt-recoverable-packets-00.txt Jonathan Lennox presented a new draft on marking and retransmitting high-priority RTP packets. He noted that Layered Media has potential IPR relating to this draft (disclosure #726) and are offering to license on the basis of reciprocity. Colin Perkins (speaking as an individual), noted that such license terms are not useful for many users, and that a royalty-free license would be preferable. The idea behind this work is to tag "high priority" packets such that their loss can be detected, and recovery initiated, as soon as possible, and in a media-independent manner. This is done by a named RTP extension header, using the mechanisms in draft-ietf-avt-rtp-hdrext-03.txt. Open questions are: 1) is this a useful problem to solve, 2) is this the best way of solving the problem; and 3) is the working group interested in seeing this developed further? Stephan Wenger noted that many video codecs that let you do this, and that the subject has been discussed extensively before. He considers the idea of media independent marking and retransmission useful only if there is a codec technology where it adds significant values, and where the codec doesn't have support built in. Magnus Westerlund reminded the group of the selective retransmission work we did some years ago (draft-ietf-avt-rtp-selret-05.txt), which included similar ideas in its early versions. Magnus doubt as to the utility of the generic marking and retransmission scheme, since it's possible to report all packet losses to the sender with only minimal extra overhead, allowing the sender to make an intelligent choice what to retransmit. A review of the previous work, and the reasons why it didn't go forward, is needed before this draft can progress. RTP MIB and RTCP XR MIB draft-ietf-avt-mib-rtp-bis-01.txt draft-ietf-avt-rtcp-xr-mib-05.txt Alan Clark outlined a potential restructuring of the RTP MIB and RTCP XR MIB, to address previous comments from Magnus Westerlund. This augments the receiver table with RTCP XR information, instead of the sender table. Steve Casner agreed that this proposal seems to make sense, since the XR information parallels the original RTCP information in the tables. Other feedback was limited, since the group hadn't seen a written proposal to review before the meeting. Alan agreed to send a more detailed outline of the proposed changes to the list, soliciting review, before updating the draft. Steve Casner asked to what extent the original RTP MIB was lacking? Mark Baugher and Roni Even noted that, while some implementations exist, it's not clear that anyone uses the original MIB, therefore it's difficult to comment. Dave Oran agreed, noting that RTCP widespread implementation is also lacking and, without that, MIB take-up is likely to be low. Alan Clark claimed that the original RTP MIB is less than useful, since RTCP statistics are lacking in detail without XR, which this update provides. RTCP HR draft-clark-avt-rtcphr-02.txt Alan Clark presented the RTCP HR audio metric extensions. Major changes from the previous version include an extensive rewrite of the model for handling translators, the addition of a signalling correlation tag and the removal of fields relating to codec type and other parameters (to address the discussion at the last meeting). The discussion mostly centred on the translators section, which Geoff Hunt explained. Colin Perkins thought this useful work, but suggested it better belonged in the topologies draft, that has been split out of the CCM work, to make that more of a general SBC/MCU implementers guide. Steve Casner agreed, noting that this fits with RFC 3550, and the feel of the room was that this is useful. Stephan Wenger disagreed, however, on account that he doesn't want to delay to the CCM work to wait for an expanded topologies draft, although Magnus Westerlund didn't see why any delay would occur, since there would not be a normative reference from CCM to topologies. Colin Perkins suggested the Geoff and Stephan talk, to see if the drafts can sensibly be merged. Alan asked if this could be accepted as a working group draft. The chairs saw no reason why not, although the charter will have to be updated to include it. RTCP XR video draft-clark-avt-rtcpxr-video-02.txt Alan Clark presented an update to the RTCP XR video metrics draft. He noted that there have been various comments relating to the header format, packet level metrics, etc., some in common with the RTCP HR draft. These will be incorporated into the next version. Section 2 will be rewritten to better describe the layered model, reporting model, etc., and many of the 0-50 scale metric will be converted to MOS scores. There was a question on the list about use of the IPPM metrics, but Alan believes the current metrics are more suitable (see graphs in presentation slides). Time Alignment Using RTCP Feedback draft-taylor-avt-time-align-00.txt Tom Taylor presented RTCP extensions for time alignment, noting that there is IPR associated with the work (disclosure #735). There was a lot of discussion of playout models, the ways in which playout can be shifted by the sender, and the degree to which receivers can be expected to manage their own playout. Magnus Westerlund noted that we have long assumed that receivers are smart, and can manage their own playout, and questioned the need for this work. He expressed concern about the brittleness of this proposal to variations in delay and jitter, and doesn't think the complexity of this proposal to be justified for the gain. Flemming Andreasen wondered about the presence of slotted schedulers up-stream, of which the receiver may not be aware. Using time alignment in such a case may break the slotted scheduler. Steve Casner noted that the presence of clock skew would require continual re-alignment, which might not be desirable. Cullen Jennings wondered if this might be most useful when compositing several streams. Colin Perkins summarised by noting that there are clearly mixed opinions on this work: some people think it has value, others don't see the need. There is no obvious harm to the RTP architecture by continuing the work, though, so it can continue to be discussed. Dale Worly noted that tests with real data may help to convince the group that this mechanism is useful. RTP Header Extensions draft-ietf-avt-rtp-hdrext-03.txt Finally, Steve Casner spoke briefly about RTP header extensions (no presentation materials were used). Steve is concerned that making the RTP header extension mechanism easier to use is not necessarily a good idea, and that the aim when RTP was designed was that changes of the sort being proposed for inclusion in header extensions should be better done as new profiles. The draft-ietf-avt-rtp-hdrext-03.txt is reasonable for what it proposes, but Steve doesn't believe this is the right thing to propose. Instead, we must solve the profile negotiation, to make it practical to negotiate new profiles. There was considerable discussion. Stephan Wenger thought it important to open up the header extension mechanism to avoid a profile explosion, due to combinatorial issues when combining features. Steve disagreed, noting that we don't have a problem with making names for new profile combinations, and that it's desirable to review combinations to see if they make sense, rather than allowing arbitrary combination of features. Stephan agreed in the ideal world, but noted that others have started to use arbitrary unstructured extensions already, and ignoring the problem won't stop that. Better to impose some naming and structure. Dave Oran commented that he doesn't find the argument that "we should do X because others will do something worse" persuasive. However, using new profiles here just moves the complexity onto SDP, and doesn't eliminate it. Taking a system level view, there might be less overall complexity to relax the use of RTP header extensions. Flemming Andreasen noted there is a problem with feature interactions, which we've tried to solve with profiles, but that doesn't scale. There should be room to extend existing profiles. Roni Even and Colin Perkins commented that using header extensions won't solve the signalling problem, since header extensions will need to be signalled, since some will be defined that can't be freely ignored. Stephan Wenger suggested a compromise might be to mandate that header extensions be ignored, but Colin didn't think that feasible, citing the current proposals to use header extensions as a signalling channel (e.g. ZRTP). Roni agreed, noting that having to define a new profile is an appropriate safeguard. Colin Perkins concluded by stating that this is a complex, cross area problem, which has system level implications bigger than just for RTP. Cullen Jennings suggested further discussion should take place on the mailing list. - + -