Audio/Video Transport (AVT) Working Group Minutes ================================================= Reported by Magnus Westerlund and Colin Perkins The AVT working group met once at the 65th IETF Meeting (March 2006, Dallas). Subjects under discussion included management tools for RTP (MIBs and RTCP XR extensions), new payload formats, codec control, RTCP extensions for SSM sessions with unicast feedback, and security parameter negotiation for SRTP. The meeting was chaired by Colin Perkins and Magnus Westerlund, and 132 people signed the blue sheets. Introduction and Status and Charter Update The WG has had 11 RFCs published since last meeting, has eight drafts in the RFC-editor queue, and a further six in various states of AD and IESG review. Colin Perkins expressed the WGs thanks to the RFC-editor, Allison Mankin and the rest of the IESG for their hard work. The chairs briefly reviewed the status of the other working group drafts. Colin Perkins highlighted draft-westerlund-avt-rtp-howto-00.txt which provides guidelines and advice for authors of new RTP payload formats, and solicited comments from the working group. There was strong support for such work, and since this is already a charter item, the document was accepted as a working group draft. The chairs noted that the charter needs updating to include the RTCP XR extensions and codec control messages drafts. Discussions with the area director on a new charter to include these items are ongoing. Colin Perkins announced that Magnus Westerlund will step down as AVT co-chair within a few weeks and thanked him for his contributions. A replacement has not yet been decided, although several candidates are under consideration. In addition to the new co-chair(s), formation of an RTP payload format directorate is being considered. The directorate would help ensure that all payload formats get proper review at least at acceptance as WG item and in WG last call. Volunteers were solicited. RTP MIB and RTCP XR MIB draft-ietf-avt-mib-rtp-bis-00.txt draft-ietf-avt-rtcp-xr-mib-04.txt Alan Clark outlined the structure of the revised MIBs, and highlighted changes in the latest versions of these drafts. Discussion centred on two issues: session identification and inclusion of signalling data in the MIB. On session identification, Colin Perkins noted that the SSRC cannot be used as a unique session or participant identifier, since it may change due to SSRC collisions, and because multiple participants might use the same SSRC at different times within a single session. Magnus Westerlund then noted that it is important for that MIB to cover the full range of scenarios supported by RTP, and explained that an RTP session cannot be identified by a single address, since the session may span several transport connections provided they share a single shared SSRC space. Roni Even agreed, and noted that, to some extent, there is a higher level issue, since signalling knowledge is required to understand which transport connections that comprise an RTP session. On the inclusion of signalling data in the MIB, Colin Perkins noted that the draft RTP MIB includes several fields that relate to signalling, not RTP. Colin suggested the RTP MIB is not the appropriate place to include signalling data, and Magnus Westerlund suggested the SIP MIB as an alternative. Alan disagreed with the use of the SIP MIB, since not all applications use SIP and the main is to provide a general RTP monitoring framework; Roni Even pointed to H.323 systems as an example that could use the RTP MIB but don't use SIP. Mark Baugher and Magnus Westerlund commented that the right approach may be to correlate in the management application somehow, perhaps by including an opaque tag in both RTCP and in the signalling, which could be used to correlate the RTP MIB and the signalling related MIBs. It was clear that fundamental issues remain to be resolved before the new MIB design can be considered stable. RTCP XR Video Metrics draft-clark-avt-rtcpxr-video-01.txt Alan Clark presented the RTCP XR video metrics draft, outlining the metrics conveyed and the scenarios where it is expected to be useful. As with the RTP MIB, discussion centred on duplication of signalling information within RTCP (in the configuration block of the RTCP XR video metrics). Magnus Westerlund asked if a video quality probe can operate without access to the signalling? Alan Clark responded that it is quite easy to detect RTP streams automatically, inferring the type of payload present. Stephan Wenger commented that heuristics for video codecs will get less reliable as the video codecs get more complex, and noted that it seems unwise to use them as the basis for a standard. Steve Casner commented that encryption will also make it difficult to analyse streams unless trusted with access to keying material transported with the signalling. Alan Clark and Rajesh Kumar responded that the goal is to address reasonable scenarios where system monitoring and management are needed today and in the near future, and the combination of heuristics and the inclusion of a limited subset of signalling information within RTCP XR would enable this without significant overheads. Colin Perkins acknowledged the need for management, but disagreed with the need to build a short term solution that duplicates the signalling data in the RTCP XR reports. Colin explained that a general purpose way of correlating the signalling information with the media can be used to build a system that will work in the long term, not only in the short term. There is an architectural model here that intentionally separates the media and the signalling: please do not break that model for some short term benefits. Rajesh Kumar and Alan Clark expressed some concerns that correlation of the full signalling and media data would be expensive and difficult to achieve in real-time, compared to including the signalling information within RTCP XR. There was no conclusion to the debate within the session, but it is clear that there is significant push-back against the current approach of duplicating signalling information within RTCP XR metrics. RTCP XR High Resolution VoIP Metrics Report Blocks draft-clark-avt-rtcphr-01.txt Alan Clark discussed the High Resolution VoIP metrics RTCP XR reports, providing more extensive and accurate monitoring of voice sessions. It was noted that these metric include signalling information within the report blocks, and so have the same issues as discussed for the video metrics. Discussion was limited to a queries on the usefulness of more than 8 bits of resolution for MOS scores, and various terminology questions. SVC Payload Format draft-wenger-avt-rtp-svc-01.txt Stephan Wenger presented the updates on the draft. The current draft has an issue with the signalling, which is under-specified. There has been some mailing list discussion on doing an generic (not codec specific) solution for scalable codecs. The second issue is that the SVC codec needs to decode data in the correct order over the different layers. The proposal is to use decoding order number that uses a common numbers over the different layers and thus RTP session. Nokia claims IPR on the decoding order numbers, see statement. The alternative would be a very complex description on how to determine the order. Codec Control Messages using AVPF draft-wenger-avt-avpf-ccm-03.txt Stephan Wenger thanked the group for their comments on version 02 and presented the updated draft. Colin Perkins commented that it has been suggested to break out the topology section into a separate document. Stephan responded that he would be happy to, as long as he got some help from someone that really understands it. Colin indicated his willingness to review such a document. Colin Perkins also noted that the CCM messages have the ability to turn RTP into general request/response protocol and expressed concern on the potential for abuse this raised. Stephan noted the concern, but pointed to the section of the draft explaining when it is acceptable to use the notifications as a response to requests. Flemming Andreasen commented that this problem already exists, and is not significantly worsened by this proposal. RTCP feedback messages for packet delay adjustments draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt AC Mahendran presented the initial proposal for a packet delay CCM message, to control packet delivery in time varying wireless links. This allows receivers to provide direct feedback to the sender to control packet sending delay. Steve Casner, Joerg Ott and Roni Even noted that sender based delay adaptation is not useful in many scenarios, and that rate adaptation is typically required (i.e. the aim is not to reduce buffering delay at the sender, but rather queuing delay in the network, which can only be done by reducing the sending rate). They noted that it is not clear that the existing measurement reports can't be used to control rate adaptation, and that it's not clear that this mechanism would see any more use for adaptation than existing metrics. AC responded that the delay was the best measurement they had found, and that the existing metrics don't handle handle wireless very well, so he considers this appropriate. Magnus Westerlund disagreed, commented that what we are discussing is congestion control. In that space we need to consider how successful earlier delay based proposals, such as TCP Vegas, have been. In addition we should consider if we should develop to ad-hoc congestion control for RTP, rather than developing general purpose solutions at the transport layer. Steve Casner commented that you don't really care about the delay when what you are changing is the rate. If the rate quickly varies, then service will not be appealing due to frequently occurring rate changes. Instead it is likely that the service will use the lowest available rate and the adaptation will not need to happen. The quality if you adapt will be worse than if you run at the lowest rate constantly available. Joerg Ott expressed concern that the use of AVPF events will not work well with this system: the feedback will be queued in the network and this delay will causing slow response and likely oscillation. He also noted that AVPF is not intended for frequent reporting and congestion control, but instead to report occasional media events. AC responded that not using the feedback to prevent congestion would cause even greater congestion. This is true, but Joerg's point is that better congestion control can be achieved using a protocol designed to provide congestion feedback, rather than trying to retrofit it onto AVPF. Colin Perkins summarised that the proposal got pretty strong push-back. Cullen Jennings commented that if this is to be chartered there would need to be people confident in stating -- with strong evidence to show as justification -- that packet delay would work even if we normally use packet loss to measure congestion. RTCP Extensions for SSM Sessions with Unicast Feedback draft-ietf-avt-rtcpssm-11.txt Joerg Ott presented the changes in the latest version. The major change is the logical split of the distribution source and the feedback target. The changes have result in the need of fixing nits and clarifications. There will be a new version shortly which is expected to be ready for working group last call. ZRTP draft-zimmermann-avt-zrtp-00.txt Philip Zimmermann presented the goals, design, and future steps of ZRTP. One of the main points is that this way one can avoid having the signalling chain know or even care about the use of security and the key-exchange. Steve Casner commented that this is hacking signalling into the media transport to avoid perceived problem with the current signalling layer. Also if one would do this, it is really questionable if using the header-extension is the right way. For example using a different payload type would be a better choice. Philip responded that using a payload type would be fine, there is no special attachment to using the header extension. However the key-exchange is not hacking signalling into the media: the key-exchange should not be considered signalling, and is something that has been done before, for example in the PGP phones over PSTN. In those cases it not a signalling problem. Steve responded that this distinction is not particular clear when everything goes over the same pipe, but that we have a clear separation of media and signalling in RTP which this violates. Alan Johnston commented that so far it has shown to be difficult to do the key-exchange in the signalling due to forking, early media issues. People have tried several other solutions without getting them to work, therefore it seems that putting at least some element into the media path is the solution. Colin Perkins commented that an on-media-path solution doesn't necessarily have to involve RTP: another approach is to setup a signalling channel in parallel to the media, and use that for key exchange. This might be a cleaner approach, avoiding the confusion of media and signalling, and allowing a single control channel to be used for multiple media. Roni Even noted that the Diffie-Hellman exchange is time consuming and processor intensive, and asked if the authors have any proposals to reduce the burden when one has multiple streams? Philip was surprised to find that one actually has different RTP sessions for audio and video. This problem they are going to look into. Several others noted concern over the computational complexity of Diffie-Hellman on low-end devices. Lakshminath Dondeti reminded the group that MIKEY can be both efficient and capable of handling peer-to-peer communication over UDP (independent of the SIP signalling channel). He urged the group not to forget this in a rush to develop new protocols. Further comparison between protocols was deferred to the RAI area meeting. Encrypted Key Transport for SRTP draft-mcgrew-srtp-ekt-00.txt David McGrew presented the encrypted key transport (EKT) for SRTP proposal and gave an IPR notification on this draft (an actual IPR statement was submitted, but didn't appear in time for the meeting). EKT does not solve the initial key establishment problem, instead it provides secure transport of SRTP master keys, rollover counters and other information within SRTCP. This lets SRTP work for decentralised conferences with minimal control, providing group security and handling situations caused by SIP forking and early media. Steve Casner, asked if the distribution of the EKT key was out of scope for this specification. David responded that the draft defines a way of using Security Descriptions to distribute the EKT key. Eric Rescorla found the placement of the master key in the authentication tag "cute". An operational question is if you maintain two different keys at the time of switch over. David responded that yes, you need to and the initial sequence number in the tag tells the receiver when the new key becomes operational. The best way is to keep both of the keys as long as you are in within the window of both keys. RTP over Datagram Transport Layer Security (DTLS) draft-tschofenig-avt-rtp-dtls-00.txt Jason Fischl presented the proposal to use RTP over DTLS. There are many drafts in the complete proposal, see slides for complete list. There had been some off-line discussion between Jason, Eric Rescorla and David McGrew and one proposal was to skip the SRTP compatibility mode and instead simply use DTLS for key-exchange and then use normal SRTP from that point. A draft on this will be submitted later. Kristian Shrediker (?) asked if you need a TCP/TLS for SIP signalling and if that creates a NAT problem. Jason responded that no, it doesn't make the NAT problem worse. Kristian also asked if you need another port for the RTP/DTLS/UDP. You will need also a port for RTCP, so no extra compared to RTP. Flemming Andreasen asked for clarification about if the requirement to get the finger print in signalling back before receiving media if that applies bi-directionally or uni-directional? Eric responded that you can establish the connection. But the media flowing from Bob to Alice isn't authenticated until Alice receives Bob's fingerprint. Colin Perkins asked the security people present, based on that most proposals handle point to point cases, if that is the easy case and if there is something fundamental in the multi-point case that makes it much more difficult to handle? Eric Rescorla responded that it is clearly the simple case. While point to point is taught in classes the multi-point are mostly thought in special cases or not well understood at all. TESLA is one example how one have to jump through hoops to secure multicast. However there are examples like EKT that supports multi-cast transport as soon as you have established the EKT secret unidirectional. David McGrew commented that MIKEY has gone forward in MSEC WG and there is interest for the multi-party RTP cases. The issues with point to point aren't addressed in MSEC and there has been some disconnect due to that. SRTP RCC draft-lehtovirta-srtp-rcc-01 Rolf Blom presented the proposed solution for the ROC initialisation problem. The 3GPP MBMS and OMA BCAST work has already adopted this solution to the ROC problem and like to see the MIKEY code points and extension to be IANA registered and could also be useful in larger context. Colin commented that as this is used we need at least to do the IANA registration. The other things will fall into the general security discussion. Lakshminath Dondeti asked if this is mostly orthogonal to the discussion in RAI. Magnus responded that despite its urgency the general problem should be considered in future discussions. Eric Rescorla asked if there is any advantage in this compared to EKT, or is it simply the problem of it being deployed. Rolf answered that these are having an overlap in functionality, the main difference in regards to the ROC is the transport in RTP packets (RCC) and RTCP (EKT) which makes RCC more robust. Flemming Andreasen commented that RCC's varying packet sizes may not make all access networks very happy. Colin Perkins concluded that the security discussion will continue in the RAI open area meeting in the afternoon. - + -