Audio/Video Transport (AVT) Working Group Minutes ================================================= Reported by Colin Perkins The Audio/Video Transport working group met twice at the 72nd IETF meeting (Dublin, 27 July - 1 August 2008). Subjects under discussion included the RTP payload formats for SVC and H.264 video, guidelines for extending RTCP, various SRTP extensions, geographical location, synchronisation of multicast sessions, forward error correction, and monitoring architectures. The meeting was chaired by Colin Perkins, Roni Even, and Tom Taylor. Introduction and Status Update The working group chairs introduced the meeting, and reviewed the status of the group. Two drafts have been published as RFCs since the last meeting (RFC 5244 on RTP header extensions and RFC 5285 on Events for Channel-Oriented Telephony Signalling), one is in the final stages of the RFC Editor process (RTP payload format for Vorbis - RFC 5215), and the draft on multiplexing RTP and RTCP on the same port is in the RFC editor queue, but blocked by a normative reference to the RTCP SSM draft. The payload formats for JPEG 2000, ATRAC, Speex, UEMCLIP, G.711 wideband, and the G.729.1 DTX update are with the IESG, as is the RTCP SSM draft, and the RTP header extensions for transmission time offsets and SMPTE time codes. The DTLS SRTP draft is believed complete, and a working group last call will be issued shortly, since the requirements have gone to working group last call in the SIP working group. The chairs presented summary slides on several drafts: - The G.719 audio codec was approved as an ITU-T recommendation in June 2008. The RTP payload format (draft-ietf-avt-rtp-g719-00.txt) looks to be in good shape, and can be expected to go to working group last call in the next few weeks. - The G.718 audio codec was consented in the ITU-T in May 2008, and is expected to be approved as an ITU-T recommendation later this year. The RTP payload format (draft-lakaniemi-avt-rtp-evbr-02.txt) is progressing well, and should be considered for adoption as an AVT working group draft. - The new work item updating RFC 3640 for transport of MPEG-Surround elementary streams is in progress (draft-ietf-avt-rtp-mps-00.txt). Comments are solicited. - The specification for how to use the SEED cipher algorithm with SRTP (draft-ietf-avt-seed-srtp-03) is in progress. The authors have asked that this be considered for working group last call, but extensive comments have been received. The chairs hope these can be addressed quickly, so that the draft can be completed this year (an offline meeting between the chairs and the author discussed ways in which progress can be expedited). - Multiview video coding (MVC) has been finalised at the recent JVT meeting in Hannover. The RTP payload format has not been updated, waiting on the codec work, but a new version is expected shortly, and should be considered for adoption as an AVT working group draft. The chairs also noted that the SVC design team has been holding regular conference calls (minutes have been reported on the mailing list), and will meet in person at this IETF. Any interested parties who are not already involved should contact Roni Even for details on how to join. RTP Payload Format for SVC Video draft-ietf-avt-rtp-svc-13.txt https://datatracker.ietf.org/ipr/832 https://datatracker.ietf.org/ipr/736 https://datatracker.ietf.org/ipr/852 https://datatracker.ietf.org/ipr/910 https://datatracker.ietf.org/ipr/485 https://datatracker.ietf.org/ipr/502 Thomas Schierl presented the RTP payload format for SVC video on behalf of the design team. The draft has been significantly restructured since the last meeting, with the addition of a new packet type, NI-MTAP, and changes to the packetisation modes. The non-interleaved MTAP packet (NI-MTAP), packet type 31, can be used to reduce header overhead by aggregating data into a single packet, or for alignment purposes in multi-session transmission. This packet uses the last available packet type, which is undesirable since it prevents future extension, and so it will be replaced in the next version of the draft by an extension packet type, with subtypes to represent NI-MTAP, and other extensions. The biggest change is in the definition of the packetisation modes. There are two general transport modes: single-session transport (SST) and multi-session transport (MST). SST mode using a single RTP session with the RFC 3984 packetisation modes, using optional PACSI units, and NI-MTAP may be present in non-interleaved mode. MST mode uses multiple RTP sessions and aligns the data between sessions according to three basic sub-modes: - Non-interleaved timestamp based (NI-T) - Non-interleaved CS-DON based (NI-C) - Interleaved CS-DON based (I-C) along with a fourth mode, NI-TC, that satisfies both NI-T and NI-C rules, allowing the receiver to implement decoding order recovery according to either NI-T or NI-C. (It is noted that the design team explicitly considered IPR when developing the various packetisation modes). Dave Oran and Roni Even asked clarifying questions about the various modes, to understand the differences between modes, and if there are mandatory to implement modes. Thomas noted that there are no mandatory to implement packetisation modes. Thomas also summarised changes to signalling and offer/answer usage. Open issues include use of the binary "sprop-scalability-info" with offer/answer, and synchronisation delay (discussed by Jonathan Lennox in draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt later). Session Multiplexing for SVC Video draft-hannuksela-avt-rtp-svc-01 Ye-Kui Wang presented an alternative proposal for session multiplexing for SVC video. This proposal avoids using the CS-DON for compatibility with the single-session non-interleaved mode, and instead proposes two alternatives: an access unit identifier mode (NI-A) and a timestamp difference based mode (NI-TSD). The design team has discussed - and rejected - this proposal; it's being presented to call attention to the ideas and seek wider input. Aside from questions for clarification, there were no comments. It was noted that both Fraunhofer and Nokia believe they might have IPR covering this draft. Appropriate IPR disclosures will be submitted. RTP Payload Format for H.264 Video draft-wang-avt-rfc3984bis-01 https://datatracker.ietf.org/ipr/485 https://datatracker.ietf.org/ipr/502 Ye-Kui Wang presented the revised RTP payload format for H.264 video, outlining the changes to the draft (see slides, and section 17 of the draft) and discussing the open issues. An open issue is the changes to the way parameter sets are negotiated. Roni Even noted the changes might affect the backwards compatibility with RFC 3984, but to the best of his knowledge, the affected mechanism is not used, so there's no practical problem. Jonathan Lennox, however, thought this might be used in some streaming applications, and Stephan Wenger noted that 3GPP includes it in MTSI (although he isn't aware of any implementations). Jonathan Lennox asked why both sides need to negotiate the use of out- of-band sprop-parameter sets, and wondered if this also forbids in-band transmission? Ye-Kui clarified that in-band transmission is allowed. Roni Even agreed that this needs clarification in the draft. The sense of the room was that this draft is appropriate to consider for acceptance as an AVT work item, subject to re-chartering. Guidelines for Extending RTCP draft-ietf-avt-rtcp-guidelines-00.txt Joerg Ott presented the draft on guidelines for extending RTCP. After outlining the aims of the draft, and the changes since the last meeting, he discussed some open issues. The draft strongly encourages RTCP extensions to consider the inherent group communication nature of RTP. Is the guidance appropriate? Stephan Wenger suggested that the overwhelming fraction of RTP use is point to point, and the draft needs a section that provides guidance if you know that you're in a point-to-point session only. Dave Oran commented that he thought this guidance helpful, but noted that many of the guidelines depend on the topologies, and it might be useful to structure the draft around that. Magnus Westerlund noted that it's not hard to make most of the solutions work for small groups, and make them degrade gracefully, so the guidance is appropriate. Joerg summarised his sense that the group thinks the guidance not entirely inappropriate. The draft includes a discussion of appropriate extension points for RTCP and discourages standardisation of RTCP APP packets. Does the working group agree with this aim? Dave Oran noted that the problem is people who wish to experiment, then turn their thing into a standard; some guidance there would be appropriate - should they use an unregistered packet type, or use APP packets and rewrite their code (if the latter, some guidance on transition strategies should be provided). Ingemar Johansson noted that much of the desire to use RTCP APP packets in some other standards bodies comes because one doesn't need to register them with IETF. Joerg understood the appeal, but noted that many of the other extension points can be registered though IANA, directly from a 3GPP (or other) standard, without interacting with the IETF. Colin Perkins noted that it might be appropriate for the draft to highlight this directly. Magnus Westerlund mentioned the issue with collision between RTCP APP packet names, and encouraged registration via other mechanisms to avoid this. Dave Oran wondered about feedback tightly bound to some payload format? Magnus noted that if it's feedback, we have that in AVPF. Other things, need to think what they are to determine an appropriate extension point. The draft notes that "The amount of information going into RTCP reports should primarily target the peer (and thus include information that can be meaningfully reacted upon). Gathering and reporting statistics beyond this is not an RTCP task and should be addressed by out-of-band protocols." and Joerg asked if this is an appropriate choice? Dave Oran tends to agree this is appropriate guidance, but notes that one case where intermediate devices might be acceptable is when acting as receivers to monitor stream quality at a middle-point, and want the information to be semantically the same as end-point RTCP. Joerg agreed that such devices are useful, but wondered why the data should be sent in RTCP? Dave Oran agreed: the data schema should be the same; doesn't care about the transport format (i.e. something like the rtcp-summary draft). Magnus Westerlund noted that the summary draft has problems with time-scales, making it hard to synchronise and find the right time-scales. Alan Clark noted that RTCP XR VoIP metrics were originally designed to be end-to-end. It also happens to work for probes that snoop on it. The rtcp-summary draft is a different model, designed to be send at end of a call. Joerg agreed, noting that RTCP XR is fine, and useful. Geoff Hunt noted that for set-top boxes and VoIP endpoints in customer premises, RTCP is essential, and often the only way to get data out. Joerg agreed, but noted that this limits how fast you can send, etc. He suggested not to limit yourself based on RTCP, and instead use another transport; don't remodel RTCP for network management: there are better ways of doing it, and RTCP will be a burden (infrequent and limited size reports, and big packet sizes, implying slow reporting). Geoff agreed, but wondered about things that do comply with the RTCP rules? Are they deprecated? Joerg isn't saying that, rather "don't design RTCP extensions specifically for monitoring; it's the RTP control protocol". RTCP is designed to allow receivers to inform senders what they should do to improve the session. If it happens to be useful for monitoring, great, but it's not primarily designed for it. Finally, Joerg asked if we should leave this draft around for a while and continually update it to collect further issues and suggestions, or should we aim to fast-track it to working group last call? Magnus Westerlund challenged Joerg to get the draft done by November. Roni Even suggested one more revision, then aim for working group last call. DTLS-SRTP Key Transport draft-wing-avt-dtls-srtp-key-transport-02 Dan Wing presented DTLS-SRTP key transport, an extension to DTLS SRTP to allow efficient SRTP operation for group conferencing and multicast environments. This version incorporates feedback from the Philadelphia meeting, and makes a number of technical improvements including adding logical key hierarchy (LKH) support, and removing the 'your_new_key' primitive (which turned out to be too dangerous for practical use). The use case for the new LKH support is rekeying when a listener joins or leaves an SRTP session. With normal DTLS-SRTP, the new SRTP key is encrypted for distribution once for each active listener, taking time and CPU cycles. LKH allows the new SRTP key to be encrypted once only, irrespective of the number of listeners. The key design consideration then becomes how to deliver that new key to the listeners? There are two options: use EKT (draft-mcgrew-srtp-ekt-03.txt) for rekeying (this is problematic with video switching MCUs - RFC 5117 section 3.5), or invent a new DTLS-SRTP content type to send the LKH message. Feedback was solicited, and Colin Perkins commented that while the EKT option could be made to work (those scenarios where it has problems are not recommended for other reasons), it seems cleaner to put the extension into DTLS (along with the other key management functions). Another use case, briefly outlined, is interworking between DTLS-SRTP and sessions keying using sdescriptions, which can become much more efficient with DTLS-SRTP key transport. Cullen Jennings, Roni Even, and Dan York expressed interested in this work. The group will consider re-chartering to accept this as a work item in future, once the base DTLS-SRTP work has gone to working group last call. SRTP Store and Forward draft-mattsson-srtp-store-and-forward-00 https://datatracker.ietf.org/ipr/966 Rolf Blom presented new work on SRTP store and forward extensions. The aim of this work is to protect content from an honest but curious store and forward middlebox (e.g. an answering machine, or conference bridge) by splitting the content protection into two parts: end-to-end content protection and transport protection. Transport protection is done using current SRTP, end-to-end content protection is provided by a new SRTP transform. When combined, these transforms provide a separation of the two security contexts, with minimal impact of the SRTP framework. Jonathan Lennox noted that it would be interesting for (e.g. SVC) to have a setup where an initial prefix of the payload is in the clear, but most of it is encrypted, and asked if that could that be done with this solution? Rolf replied that this is, in principle, possible, but it's not in the current draft. Roni Even suggested that this work would benefit from referencing RFC 5117 to better understand its applicability. Cullen Jennings, as Area Director, agreed, noting that any work in this area would need careful review from the security area. The chairs expressed interest in seeing how this work develops, continuing as an individual submission for now (until wider security review has been conducted), and then considering it further at a future meeting. RTP Timestamps for Layered Encodings draft-lennox-avt-rtp-layered-encoding-timestamps-00 Jonathan Lennox discussed the issue of synchronisation for layered RTP sessions. RFC 3550 defines a mode where layered encodings are striped across multiple RTP sessions, with associated streaming using the same SSRC, and SSRC collisions being resolved on the base session only (RFC 3550 section 8.3). RFC 3550 says nothing about the timestamps used for each session: this draft proposes to update RFC 3550, to mandate that the same initial (random) RTP timestamp value must be used for every layer. This means that a receiver doesn't need to wait for an RTCP SR to synchronise the streams. Colin Perkins commented that, to the extent the mechanism in RFC 3550 section 8.3 is useful, this draft is a reasonable extension. However, he doesn't believe the mechanism in RFC 3550 section 8.3 is generally useful, since it only works for layered encodings where all layers depend on a common base layer, but this is not the case for modern layered codecs. Thomas Schierl noted that this work would make the SVC NI-T mode simpler, and so supported it, but agreed with Colin that there might not always be a single base layer. Ye-Kui Wang noted that even with SVC, it's possible to have simulcast sessions, where there is no common base layer. Another speaker liked this draft in its current form, since other mechanisms are more complex. There was no conclusion on taking this forward in the working group session. In a side meeting later in the week, it was decided that a new draft would be written to explore the issues and requirements, to inform the discussion going forward (see summary message sent to the AVT mailing list by Jonathan Lennox on 29 July 2008 16:02:43 BDT). Why RTP does not mandate a single security mechanism draft-perkins-avt-srtp-not-mandatory-01 Colin Perkins presented an update to the draft explaining why RTP does not mandate a single security mechanism. Changes since the last version include a new section discussing how RTP meets the requirements of RFC 3365, various editorial clarifications, and the removal of the IPsec example from section 3. This latter was because the authors have been unable to find a definitive reference to 3GPP use of IPsec - help was sought to document this, and Hannes Tschofenig, Rolf Blom, and Stefan Dohla provided information off-line. The draft was accepted as an AVT work item. RTP Payload Format for Geographical Location draft-marjou-geopriv-avt-geoloc-00 Xavier Marjou outlined an RTP payload format for geographical location. The use case here is a moving user who wants to share his/her location with a remote user, necessitating transport of GPS location several times per minute. It is proposed to send this location data in RTP, to provide timing information, and allow synchronisation with other media. A new RTCP SDES item - similar in concept to the existing LOC item - was discounted, since "if there is no other media an empty RTP payload would be needed". Colin Perkins suggested that someone should write up an RTCP SDES item to transport geolocation data - if there is now an accepted format for such data - since it would be generally useful (even if not for this application). Colin also disagreed with the claim that a session with no media would need to send empty RTP payload data in order to use an RTCP SDES geolocation chunk: it is perfectly acceptable for a session to exist where RTCP is sent, but there is no media data. Magnus Westerlund thought RTCP SDES more appropriate than RTP for this. Dave Oran noted that it might be appropriate to send this data in RTP if it needed highly accurate timing, but agreed with Magnus that RTCP SDES was more appropriate for data sent only a few times per minute. Hannes Tschofenig noted that this is the wrong working group for this (presumably suggesting the GEOLOC group instead) and commented that location and RTP don't fit together - a messaging protocol might be more appropriate. Jonathan Lennox noted that, if sent as an RTP payload format, this data would need to be sent in a different RTP session to audio or video data. This would require it to be synchronised with the other sessions using RTCP SR information - in which case the geolocation data might as well be sent in an RTCP SDES packet in the other sessions, piggybacked on a RTCP SR packet. RTP adds no value here. The chairs summarised that there is no interest from the group in using RTP to convey geolocation data (although there is interest in using an RTCP SDES item for this purpose). This doesn't mean that people don't want to convey this information - they just don't think RTP is a good choice for the transport. The area director (Cullen Jennings) agreed: people aren't understanding the requirements for why RTP is to be used. RTCP SSM Joerg Ott briefly discussed an issue found with the RTCP SSM draft in IESG review. This draft has the potential to cause a denial of service if the signalling can be compromised, by directing feedback to a third party who is not expecting it. The security considerations discuss the problem and protective measures, but the IESG review comments noted that - if these measures are somehow circumvented - then the victim would be stuck receiving unwanted feedback information, with no way to determine what is causing it. It's therefore desirable to provide information on the RTP SSM session in the feedback packets, to help troubleshooting. One suggestion for doing this is for the distribution source to send a session context (or debugging) packet containing information - for example an (S, G) address pair, a media channel URI, a phone number to contact, or generally some free text description of the session and a URI for further information. Dave Oran expressed support for the idea, but noted that if this data was sent at low frequency, it might be these packets that got lost. To be effective, he noted that such information needs to be sent in every feedback report. Rapid Synchronization with RTP Multicast Sessions draft-versteeg-avt-rapid-synchronization-for-rtp-00 Bill Ver Steeg outlined a mechanism to allow rapid joins to multicast RTP sessions, for example IPTV channels, using unicast patching. This builds on the RTCP SSM feedback target mechanism, RTP retransmission, and the RTP/AVPF profile. The receiver sends an initial repair request including details of its playout buffer parameters to the server, which replies with a burst description, followed by a unicast repair burst. At present, the request is coded in an AVPF NACK PLI message, while the burst description and other messages are coded in RTCP APP packets. An open issue is whether this is an appropriate transport - from the RTCP guidelines discussion earlier, if RTCP APP packets are not appropriate. Ye-Kui Wang asked if AVPF NACK PLI messages can be used directly, and Stephan Wenger noted that there was a long discussion on the issue of message overloading when CCM was being defined, leading to a strong recommendation to define a new report type. Ye-Kui Wang wondered why the client sends buffering requirements to the server? This is because some clients know their buffering requirements, and the information is helpful to the server. Ye-Kui suggested it be sent from server to client instead: the problem, for the use cases Bill is considering, is that they're trying to be codec independent, so the server can't know the amount of buffering needed. There was some more discussion, with the general consensus to keep the mechanism codec independent. Roni Even concluded by noting that the work should either be general, or purely focussed on one codec (e.g. MPEG-2 transport). Joerg Ott wondered how the burst specifications were defined, and noted that 3GPP may have work in this area. If such work exists, it would be desirable to align with it. Bill also briefly reviewed the SDP signalling for this mechanism. Roni Even noted that the example signalling is missing the "a=group:" line, and wondered what backwards compatibility exists for receivers that don't understand the SDP grouping extension. Bill noted that Cisco have IPR on this draft, and will submit an IPR disclosure, and suggested that Alcatel might also have relevant IPR. Post-Repair Loss RLE Report Block Type for RTCP XR draft-ietf-avt-post-repair-rtcp-xr-00 Ali Begen outlined a post-repair loss RLE block for RTCP XR. The report is identical to the loss RLE report defined in RFC 3611, except that it should be calculated after FEC (or any other repair) has taken place. An RTCP XR block type remains to be chosen, but otherwise this appears ready for working group last call. 1-D Interleaved Parity FEC draft-begen-fecframe-interleaved-fec-scheme-00 Ali Begen discussed a new 1-D interleaved parity FEC scheme. This is a systematic FEC code of decent complexity, providing protection against bursty losses. The draft describes a fully-specified FEC scheme for the 1-D interleaved parity code, and an associated RTP payload format. The FEC scheme adopts the RTP payload format from SMTPE 2022-1, fixing the parts of SMPTE 2022-1 that are not RTP compliant, and forming the base later in the DVB AL-FEC proposal. Colin Perkins noted that while this might fix the issues with SMPTE 2022-1, it doesn't solve the underlying problems with RFC 2733, on which SMPTE 2022-1 is based. These issues, the liaison statement from SMPTE on this subject, and the future direction of this work, will be discussed in the FECFRAME working group. RTCP HR draft-ietf-avt-rtcphr-03.txt Alan Clark outlined the status of the RTCP HR work. There was a side meeting to discuss how to proceed with this draft before the regular working group session, with the conclusion that the draft should be split into individual RTCP XR block types, each in a separate draft, with a new draft (targeting BCP) describing how to combine metrics for a particular application domain. These drafts are expected to be submitted shortly after the meeting. See also the summary message sent to the AVT mailing list by Geoff Hunt on 7 August 2008 11:05:37 BDT. Monitoring Architectures for RTP draft-hunt-avt-monarch-00 Geoff Hunt outlined a new draft on monitoring architectures for RTP. This reviews existing metrics, and provides a taxonomy within which future work on metrics may be positioned, as requested by AVT at the previous meeting. The authors solicited participation, comments, and review, in particular regarding the direction the draft should take. It's the hope of the chairs that a future version of this draft will help structure metrics work, in the manner that RFC 5117 structures discussion of RTP topologies. Ingemar Johansson noted that there is somewhat similar work taking place in 3GPP SA4, which it might be appropriate to consider. - + -