Audio/Video Transport (AVT) Working Group Minutes ================================================= Reported by Colin Perkins The Audio/Video Transport working group met twice at the 69th IETF meeting (Chicago, 23-27 July 2007). Subjects under discussion included DTLS extensions for keying SRTP sessions, extended reception quality reports for RTCP, non-compound RTCP, RTP keep alives, source specific media attributes, and various RTP payload formats. The meeting was chaired by Colin Perkins, Roni Even and Tom Taylor. The blue sheets were signed by 94 people in the first session, and 70 in the second session. Introduction and Status Update The working group chairs introduced the meeting, and reviewed the status of the group. Two RFCs have been published since the last meeting (draft- ietf-avt-rtp-amr-bis-06.txt as RFC 4867, and draft-ietf-avt-hc-over-mpls- protocol-08.txt as RFC 4901). The RTP payload formats for EVRC-WB and Vorbis are in IESG review, as is the SAVPF profile, the drafts defining a general RTP header extension mechanism, and the draft on the ULP FEC scheme. The draft on RTP and RTCP multiplexing is in IETF last call. The Codec Control Messages and Topologies drafts have completed working group last call, with some comments being made. The chairs called for reviewers to ensure these specifications can be implemented, and are clearly written, before we request their publication as RFCs. DTLS Extension to Establish Keys for SRTP draft-ietf-avt-dtls-srtp-00 David McGrew presented the DTLS extension to establish keys for SRTP. This is based on draft-mcgrew-tls-srtp-02.txt, which has been discussed extensively in the RTPSEC BoF, and has been adopted as an AVT work item after the discussion at the 68th IETF. It protects point-to-point RTP sessions, using a DTLS handshake on the media path to establish keys, and it defines DTLS SRTP packet processing for RTP and RTCP. Recent changes include a clarification that only one DTLS handshake is needed in the symmetric RTP case, the elimination of a duplicate list of SRTP profiles, and the correction of various editorial nits. There are a number of open issues: Open issue #1 is whether the "TLS extractor" should be used instead of a purpose-built extension to TLS KDF. This would require rewriting section 3.3 of the draft. Hannes Tschofenig queried the status of the extractor in the TLS working group, and Eric Rescorla replied that his impression (without speaking for the TLS working group chairs) was that it would become a TLS work item if there was interest. Hannes also asked if the extractor is general purpose, or limited to use with DTLS SRTP - it is general purpose. Discussion was moved to the mailing list. Open issue #2 is whether we need a symmetry breaking rule (see section 3.6.2.1 of the draft) to define what should happen when a device that sent a clientHello receives a clientHello. This would also handle cases in which the signalling can't tell which device should act as client and which as server. Colin Perkins asked if you can't solve this by defining the SIP offerer as the server, and Eric Rescorla replied that he had thought so initially, but there are call flows where that doesn't work. Roni Even noted that there are MCU-related call flows that require this symmetry breaking, and Jonathan Rosenberg noted that ICE has a similar feature to address this problem. Eric Rescorla asked if the symmetry breaking tag can be included in the SDP - no, it has to be in the media path because you can't do an updated offer until after the media begins to flow, unless you also do reliable provisional responses. Jonathan Rosenberg spoke clearly in favour of including symmetry breaking, and David McGrew agreed to work on this in the TLS working group. Open issue #3 is whether a single DTLS session should be used per SRTP session (appendix B of the draft). The advantages of this are lower computation and latency, and a better match for the SRTP policy model. The disadvantage is that it differs from standard TLS practice. Jonathan Rosenberg asked if this is just for RTP and RTCP flows of a single RTP session, or if it can also work across audio and video RTP sessions. Eric Rescorla replied that it could in theory work across RTP sessions, but isn't currently specified that way. David McGrew noted that this is currently just sharing the DTLS handshake between RTP and RTCP flows. Colin Perkins asked if if might be simpler to mandate multiplexing RTP and RTCP on the same port when DTLS is used? Eric Rescorla and Jonathan Rosenberg enthusiastically supported this, but Flemming Andreasen noted some quality of service issues with multiplexing, and suggested that the correct solution was to encourage multiplexing, avoiding the issues with using a single DTLS session for multiple flows, and to accept that two DTLS handshakes will be required when non-multiplexed flows are used. Jonathan Rosenberg raised the issue that ICE-TCP is currently specified to send DTLS over a TCP connection in parallel to STUN, and asked if this caused any problems? Eric Rescorla explained that there is no issue from the DTLS perspective, provided there is an underlying packet framing protocol used over the TCP connection (which is the case in ICE-TCP). Finally, Colin Perkins noted that while the draft is progressing well technically, it is difficult to read for someone who is not a DTLS security expert. He will provide comments to help improve the draft editorially, and he encouraged others to do the same. Audio and Video Metrics Report Blocks draft-ietf-avt-rtcpxr-video-01 draft-ietf-avt-rtcpxr-audio-00 Alan Clark presented the RTCP XR audio and video metrics drafts. The previous RTCP XR video draft has been split into four parts following the discussion at the Prague IETF meeting; two parts were discussed in the meeting, the other two missed the deadline and will be available shortly. Alan explained that the RTCP XR video draft has aimed for consistency with ATIS IIF WT014 and DSL Forum WT135 definitions (both in final closure). It included an EPSNR metric defined using a packet-based estimation that is being evaluated by ATIS IIF group, and a MOS-V metric defined in ATIS IIF WT014, and zero reference algorithm due to be evaluated by VQEG over the coming months. The RTCP XR audio draft contains PEAQ - ITU BS.1387 and G.1070 metric, along with others being evaluation by VQEG. Steve Casner asked where the ATIS IIF and DSL forum expect their metrics to be used, and Alan replied that he's kept them informed, and this is one of the transports they expect to be used. Kaynam Hedayat reminded Alan that the consensus of the Prague meeting was that we agreed to report raw data, rather than processed metrics, but that the metrics defined here are processed metric, derived from the raw data. Roni Even noted that the group doesn't have the expertise to evaluate metrics, and suggested that the RTCP XR blocks should report metrics defined by other standards bodies, rather than defining any new metrics. Alan Clark noted that there are a number of ITU, and other, standards that exist in this area, but that these evolve, hence the need to include new(er) metrics in the RTCP XR reports. Dave Oran also remembered the agreement from the Prague meeting to transport raw metrics, rather than processed values derived from those raw metrics, noting that, e.g., if there's a standard for computing MOS the RTCP XR reports should transport the information that would allow a monitor to perform that computation, rather than transporting the pre- calculated MOS value. He justified this by noting that raw data is more stable in the long term, since recommended algorithms change. Alan Clark explained that he doesn't think this is possible, since only the end system has the information it needs to compute the metrics. Dave disagreed. There was considerable discussion on the issue, with Cullen Jennings, Joerg Ott, and Tom Taylor supporting the consensus from the Prague meeting to transport raw metrics, for similar reasons. Ravi Raviraj dissented, agreeing with Alan Clark that there is a need for both raw and processed metrics, and commenting that, provided the processed metrics are well defined, he doesn't see an issue with including them. Dave Oran concluded the discussion by noting that he doesn't see this argument coming to closure, and suggested that both raw and computed metrics be transported, but in separate report blocks, with computed metrics being defined only by explicit reference to dated standards produced by other standards bodies. The chairs agreed that this is a reasonable compromise, and emphasised the need for strict separation of raw and processed metrics, and clear, unambiguous, references to the standards defining the processed metrics. Report Block for IPTV Metrics draft-venna-avt-rtcpxr-iptv-01 Nagarjuna Venna presented the draft defining RTCP XR report blocks for IPTV metrics. He summarised the draft, noting that it relates to RTP streams as specified in RFC 2250, and contains sub-blocks for MPEG programme and elementary streams. Feedback was solicited, and it was asked if there was interest in taking this as a working group draft. Colin Perkins, as chair, asked if anyone in the group has read the draft? Cullen Jennings had, but had only trivial comments, but few others seemed to have read the draft. Accordingly, the chairs deferred on taking this as a working group item until there was more interest. Alan Clark asked about alignment with other industry standards, and Roni Even noted that multiple overlapping drafts are not desirable. Kaynam Hedayat noted that this is similar to the MPTS draft, and that the two should perhaps be merged. Someone asked about drafts proposing metrics for scalable video. Colin Perkins noted that there are none yet, but the group will consider them if any are submitted. Stephan Wenger cautioned that such drafts are likely premature, given his understanding of the state of scalable coding work. H.264 Payload optional parameters draft-ietf-avt-rtp-h264-params-00 Tom Kristensen discussed new media parameters for static macroblocks and aspect ratio for the RTP payload format for H.264. This was previously discussed as draft-kristensen-avt-rtp-h264-extension-00.txt in Prague; that has been split into draft-kristensen-avt-rtp-h264-rcdo-00.txt and this draft (the RCDO draft was not discussed). After briefly outlining the contents of the draft, Tom noted that the ITU has ongoing work on video submode control, which will result in additions to this draft. The authors therefore proposed to keep this draft in the working group for now, and to incorporate the additions when the work is complete in ITU. Non-Compound RTCP Packets draft-johansson-avt-rtcp-avpf-non-compound-02.txt Ingemar Johansson presented the draft proposing that non-compound RTCP packets be allowed in some circumstances. He noted that non-compound RTCP has been adopted by 3GPP (in 26.114 section 7.3.5). It can be used with both voice and video, for either RTCP APP packets, generic NACK packets, and for CCM TMMBR and TMMBN packets. The main open issues are how to do the bandwidth computation, and the allow_early flag in AVPF. There are two alternatives for RTCP bandwidth computation: either let both compound and non-compound RTCP packets update avg_rtcp_size, or only allow regular (compound) RTCP to update avg_rtcp_size. The latter is simple to implement, but risks that regular RTCP doesn't get it's fair share of the bandwidth (which can be alleviated using allow_early flag) and, due to the size difference between compound and non-compound packets, requires modification to the 1/16 averaging factor in RFC 3550. The other approach is more complex, but gives an opportunity to ensure that compound RTCP gets its fair share, while still enabling frequent feedback when needed. The allow_early flag (RFC 4585 section 3.4 (k)) limits the potential for using non-compound RTCP as a generic NACK, since it puts a limit on the early non-compound RTCP sending rate. It was suggested to allow this to be overridden, when combined with a robust bandwidth computation algorithm to guarantee the regular RTCP report interval. Joerg Ott noted that RFC 4585 doesn't specify compound RTCP packets, just regularly scheduled packets, so there may not be a need to override allow_early if the RTCP bandwidth is increased (this is option 1 from the slides, for how to do this). Magnus Westerlund agreed that this probably is a solution to this issue, and will do some analysis to confirm. It was asked if the draft might be appropriate to accept as an AVT work item. Steve Casner noted that the purpose of requiring all RTCP packets to be compound packets was for multicast sessions, which are now less widely used, so he thought this reasonable, provided strong guidance is given on when it is appropriate. The sense of the room was in agreement, so the chairs agreed to pursue taking this as a work item (which will need a charter update). RTP Keep Alive draft-ietf-avt-app-rtp-keepalive-00 Xavier Marjou presented the draft on RTP keep alive. This draft gives a list of mechanisms used to keep alive NAT bindings, and details the pros and cons of each. Mechanisms surveyed include 0 byte UDP packet, RTCP multiplexed on the RTP port, STUN packets, RTP packets with incorrect version number, RTP packets with comfort noise, RTP packets with a no-op payload, and RTP packets with unknown payload type. Xavier asked if any other mechanism were known (perhaps RTSP transport of RTP), and if we want to recommend one mechanism. Magnus Westerlund noted that RTSP encapsulation of RTP is TCP-based, so the RTSP session keep-alive over the same TCP connection will maintain NAT bindings, out of the scope of this document. Jonathan Lennox noted that there are often codec specific keep alive mechanisms, in addition to comfort noise. Tom Phelan noted that 0-length DCCP packets may also be used. Jonathan Rosenberg noted that keep alive is only one part of the NAT traversal problem, and it's unclear how this draft relates to the full problem. He believes that some of the recommendations conflict with ICE, and asked that the draft be updated to much more clearly specify how it fits the big picture. Jonathan Rosenberg also noted that multiple options for keeping NAT bindings alive are bad, and requested that rather than keep documenting potential methods, the draft pick one. Xavier agreed with the goal, but noted that there is no consensus on which mechanism to pick. Lars Eggert replied that perhaps this is a sign that the draft is premature. Steve Casner dissented slightly, commenting that a draft which explains why certain mechanisms don't work is valid, and that suggesting a single standard mechanism isn't the only use for this draft. Magnus Westerlund agreed, and commented that the draft needs much more work on the pros and cons of the alternative mechanisms, since some of these clearly should be documented as one "SHOULD NOT do this". RTP Payload Format for SVC Video draft-ietf-avt-rtp-svc-02 Thomas Schierl presented the RTP payload format for SVC video. The SVC codec is now essentially stable and done, as of the Geneva JVT meeting in June 2007, so there is now a need to complete this draft. Thomas summarised the draft, outlined the changes since the -01 version, and the mailing list discussion (see slides). The authors' to-do list includes fixing the packetization rules, adding signalling, and work on the security consideration. A plea for review of the congestion control section was made. Roni Even, Colin Perkins, Stephan Wenger, and Jonathan Lennox discussed the use of NALU type 30, and whether it might clash with future NALU type allocations made by JVT. It will not, since it's in "user space" intended for unregistered allocations, and is private to this payload format. It was requested that some words be added to the draft to explain this status. The main open issue is removal of the DON ordering section, allowing all modes for the base layer, and specifying a re-sequencing algorithm without the DON. This is needed for backwards compatibility with a standard H.264 base layer. Stephan Wenger thinks this is the right thing to do, but cautions that it will make the draft more complex, in a way which will be difficult for non-SVC experts to understand. Roni Even asked some questions about how to ensure backwards compatibility, but had no objections to this approach. Colin Perkins asked if this change will impact the IPR status of the payload format, since the DON ordering was covered by Nokia IPR. Stephan Wenger explained that it would not - the encumbered technology is still present, but is now optional to use. Source-Specific Media Attributes draft-lennox-mmusic-sdp-source-attributes-01 Jonathan Lennox briefly presented the source-specific SDP attributes. This is an MMUSIC draft, and is being presented in AVT to ensure there are no RTP architectural issues or problems that have been missed. Review is solicited. High Resolution VoIP Metrics draft-ietf-avt-rtcphr-01.txt Geoff Hunt presented the RTCP HR VoIP metrics draft, outlining changes since the previous version, and discussing how report multiplexing can be achieved. Colin Perkins suggested that, while the report multiplexing section has value, it is more widely applicable than this draft. He proposed that it would be better split into a separate draft, leaving this to simply define new metrics. Geoff noted that control by SDP is an open issue, especially when talking to middleboxes. Colin Perkins agreed, but suggested MMUSIC and/or SIPPING need to review that, since they have the relevant expertise. Geoff asked about the implications of concatenation of reports, problems with long packets, and the behaviour of HR-unaware translators. Colin Perkins pointed to sections in RFC 3550 describing this, and suggested that the standard behaviour should be sufficient. Using SEED Cipher Algorithm with SRTP (no draft) Seokung Yoon presented a proposal to use the SEED cipher algorithm with SRTP. SEED is a 128 bit symmetric block cipher developed by KISA in 1999 and published in TTAS.KO-12.0004 and JTC1/SC 27 N3979. It is defined for use with IPsec, TLS, etc. (see slides for RFC references). Dan Wing and Magnus Westerlund asked how key exchange is done, and noted that there may be a need for work in MMUSIC to define the appropriate SDP signalling to use this cipher with MIKEY and/or sdescriptions. Hadriel Kaplan noticed that this cipher operates on fixed block sizes, and asked if RTP padding is required to pad packets to the correct size before they can be encrypted. It was asked that the group consider this as a work item. The chairs noted that new modes of operation for SRTP are in scope, so they don't see any problem with taking this as a work item, but requested an individual draft be submitted initially for the group to review. Concluding Remarks After the published agenda had been completed, Qiaobing Xie asked if the draft on forward shifted redundancy could be taken as a working group draft. The chairs were unwilling to make such a call with no time for the group to review the draft, and suggested it be discussed on the list over the coming weeks. - + -