The Audio-Video Transport (AVT) Working Group met twice. The originally scheduled meeting was on Tuesday morning, Nov. 7. An additional meeting was necessary to complete the agenda and specifically to consider proposals for transport of keying along the media path. It was held on Thursday afternoon, Nov. 9, from 3:10 to 4:10 pm. Chairs: Colin Perkins , Roni Even , Tom Taylor Tom Taylor reporting 1. Agenda, IPR notice, and status (Colin Perkins) ================================= Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-0.pdf Colin announced that the following presentations would be added: (1) RTP over DCCP (draft-ietf-dccp-rtp-01.txt), Colin Perkins, immediately following WG status. This is shown on the published agenda charts. (2) Steve Casner on RTP design principles, immediately before presentation of draft-ietf-avt-rtp-and-rtcp-mux-00.txt. The IPR Notice was duly displayed and read out. A number of RFCs have been published since the last meeting, with a fair number in queue now. Four documents are currently in IESG review. draft-ietf-avt-ulp-19.txt just went to WG LC. As mentioned at the last meeting, the WG will be forming a payload format directorate. This people will be called upon in rotation to provide expert review to AVT Internet Drafts. Ross Finlayson volunteered already. A number of others will be contacted shortly. 2. RTP and the Datagram Congestion Control Protocol (DCCP) (Colin Perkins) ================================ draft-ietf-dccp-rtp-01.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-1.pdf Colin started with brief description of DCCP. DCCP provides connection-oriented, unicast, congestion-controlled, unreliable transport. The draft defines RTP framing over DCCP along with the associated signalling. The framing of RTP and RTCP in DCCP is straightforward. The interesting part is congestion control. There is additional complexity if transcoding is involved. There are one or two other tricky points, but the task was not too difficult otherwise. Some additional SDP is needed, since the protocol is connection-oriented. Most of this is defined by comedia (RFC 4145), but a new attribute is needed for the DCCP service code. Jonathan Rosenburg asked: how do you fall back to non-DCCP operation? This is an issue for offer/answer signalling. The current suggestion is to have multiple m= lines with alternative transports. This can be modified when MMUSIC moves along on profile negotiation. Steve Casner asked: we should be careful about optimization until we have experience, but where does Colin see the possibility of optimization? Colin thought the first possibility is obvious: multiplex RTP and RTCP, since DCCP is connection-oriented. Colin doesn't see value in sequence number compression because of potential problems at gateways. Colin asks that the WG review the draft to make sure it makes sense from the RTP/RTCP point of view. (Reviewers should look at version -02, which will be submitted shortly after the meeting.) However, comments should be submitted to the DCCP list (dccp@ietf.org). 3. RTCP for Source-specific multicast (Joerg Ott ) ================================ draft-ietf-avt-rtcpssm-12.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-9.pdf Editorial changes were made in the latest version based on reviews. There was one important technical change, to SSRC collision behaviour. The authors also added a mechanism for out-of-band SSRC announcement. After expanding on the latter, Joerg asked whether the ability to signal the SSRC out-of-band (e.g. via SDP) is of more general interest. Steve Casner suggested that they could run into conflict on the role definition (sender) contained in their proposed signalling. There was some discussion over whether the "a=source-filter:" attribute should be at session or media level. Francois Audet wondered whether there are other cases such as MIKEY where similar semantics are being propagated. Joerg pointed out that there was no interaction/negotiation in that case. Francois clarified that his concern was over potential interaction between the mechanisms. Joerg agreed that it was possible particular items would need to be allocated to one or the other mechanism. Allan Johnston cited a different case with similar considerations. Hari Desineni suggested that the role seems to be redundant, and that parameters specific to the sender can be in a new attribute. Brian Stucker pointed out that CNAME could be used to perform correlation between flows when needed. Colin asked whether the draft needs a statement on offer-answer. Jonathan Lennox indicated a need to consider multiple camera angles. Is there an interaction with the RTCP retransmission draft? The rtcp-unicast attribute is session level, would it make sense to describe at stream level? There could be a lot of issues here. Joerg wondered if offer-answer should be discussed, but in a separate draft. Dave Oran remarked that multiple streams imply multiple m-lines. He was corrected; this isn't always so with multicast. In any event, we have to straighten out the semantics of labels [There's that word again! What should it really be?]. He supports their use only for announcements, not offer-answer, in this draft. 4. RTP Payload Format for SVC (Scalable Video Coding) (Stephan Wenger ) ================================ draft-wenger-avt-rtp-svc-03.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-8.pdf Stephan summarized the changes in the draft since the Montreal meeting. Some were editorial, but there was one major technical change: the introduction of SSRC multiplexing. A Nokia IPR notice has been filed for this draft. It will be resubmitted as a WG draft as agreed in Montreal. SSRC multiplexing ----------------- The problem being addressed is a case where H.264 video is being sent by layered multicast to a set of signalling-aware middleboxes (such as wireless base stations) where the streams must be aggregated and sent onward to a single transport address at the user device. Aggregation involves the selection of which layers to transmit if the onward link does not offer enough bandwidth to transmit all of them. One solution would be to have the middleboxes perform as RTP mixers, but this would require them to be in the SRTP security context. To avoid that, the proposal is to use the SSRC as a layer identifier. This can be done by announcing the SSRCs and their associated layers in advance in signalling. That has the useful consequence that receivers can avoid collisions with the announced SSRCs, as in the source-specific multicast draft. Alternatively, the media sender can associate SSRCs with priority values, avoiding the need to include this information in explicit signalling. Specifically, higher SSRCs would denote layers of greater importance. A strategy would be needed to cope with SSRC collisions. [The proposal on the list was to assign a range of SSRC values to each layer, so the sender would have room to choose a new one in case of collision.] Stephan finished some questions for discussion, beginning with the basic premise of the exercise and then looking for views on the right way forward. Comments from the floor ----------------------- Steve Casner, reflecting on the basic premise: the draft authors don't trust the MANE to have keys, but need it to perform services. Is the trust model consistent? Jonathan Lennox: Are the authors assuming that RTCP is unencrypted? Reply: yes. Are they also assuming that it is unauthenticated? Reply: thinking about it -- this may be so. Hari: does the RTCP header have to manipulated? Reply: not in general. A MANE does not tamper with RTCP. Dave Oran: did the authors consider using header extension rather than ordinals? Reply: no. There was the usual worry about overhead. But it is a valid approach. Dave worried about complexity and restrictions involved in manipulating SSRC numbering subspaces, and suggested that the authors could well find that the alternative pays. Jonathan Lennox: are the authors are assuming not only a single sender, but also a single source? Reply: yes. Jonathan asked if they had thought about interaction with RTCP retransmission. Steve Casner: the draft should consider sender SSRC assignments as fixed. Either have a means to avoid collision by other means or don't use SSRC overloading at all. Stephan protested that the sender knows how many layers it has in advance, so it can divide up the SSRC numbering space accordingly. Steve still considered it better to put the onus on the receiver to resolve collisions. Colin Perkins pointed out that dynamic adjustment at the sender gives a high probability of collision. 8000 receivers imply a 50% probability of collision, not a large number for IPTV applications. Dave Oran asked if it would work to define a rule that receivers lose in collision, as a global rule independent of payload type. Stephan replied that header extension would be considered. Colin urged: SSRC is there for the purpose, use it. Steve Casner said that the rule that when a collision occurs, the receiver MAY choose to keep packets from the new source rather than the existing source has already been relaxed in RFC 3550. 5. Signalling Layered and Multidescription Media in SDP (Thomas Schierl ) ================================ draft-schierl-mmusic-layered-codec-01.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-2.pdf The draft contains a number of technical changes from the -00 version, as shown on the first chart. The title has changed to reflect this. Thomas reviewed the details of the proposed new signalling for media dependency. This signalling builds on the media stream grouping mechanism defined in RFC 3388. The present draft introduces the decoding dependency group: 'DDP'. This is complemented by a new media-level attribute 'a=depend:' identifying the type of dependency: 'lay' for layered coding, 'mdc' for multi-description coding, with a list of the streams forming the operating point as additional parameters of these attributes. We decided at IETF 66 that SSRC multiplexing is an acceptable approach for transport of interdependent streams. A new media level attribute 'a=ssrcmux:' has been introduced to signal this usage. The draft proposes implicit association of SSRC values to the individual streams, with higher values assigned to streams of higher importance, in the specific case where the relationship between the streams is strictly hierarchical. (This implicit signalling was one of the two approaches presented by Stephan when discussing the SVC draft.) Implicit association is signalled with another value of the 'a=depend:' attribute, 'a=depend:lay-ssrc'. The draft specifies a requirement that the session description provide the means for an implementation that does not understand the new attributes to pick out a valid subset of the media streams that it can receive and decode successfully. This is needed, for example, to support offer/answer. The draft specifically states that this should be in the form of a separate media description that may point to the same transport address but may otherwise differ in detail. Thomas presented some questions for discussion: 1) Which draft should hold SSRC multiplexing, this draft, the SVC draft or another one? 2) Use implicit or explicit assignment of SSRC to stream? 3) If SSRC multiplexing stays in this draft, should it be generalized to a mechanism that applies for non-RTP transport as well? Colin Perkins saw no point in generalizing beyond SSRC. Stephan Wenger made the distinction between payload-specific properties and considerations that apply to a variety of payload types. He sees value in documentation of SSRC multiplexing separately from the SVC payload type. Hari Desineni noted the limit on number of SSRCs in receiver report packets. Jonathan Lennox preferred that signalling for implicit multiplexing be dealt with in a separate document. 6. RTP Payload format for DV (IEC 61834) Video (Kazuhiro Mishima ) ================================ draft-kobayashi-avt-rfc3189-bis-00.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-3.pdf This draft deals with a new SMPTE 370M format. This is a HD (High Definition) professional encoding format. The new format differs from consumer HD VCR, which is covered by RFC 2250. The major changes from RFC 3189 were to add the new SMPTE 370M format and provide the associated media type registration. The draft also removes support for the SMPTE 306M format, which is already covered by SMPTE 314M. The security considerations were improved to cover prevention of the unexpected source DOS attack using information from the latest IGMP specification (IGMPv3, MLDv2). A number of implementations of RFC 3189 were listed. Steve Casner asked if the listed implementations are using merged or separate audio and video. He and the presenter agreed to discuss this offline. 7. IEEE 802 and QoS: RTP Interactions? (Michael Johas Teener ) ================================ Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-4.pdf Background: the IEEE is trying to merge firewire and 802 transport. The work is being done by the “IEEE 802.1 Audio Video Bridging Task Group”. A detailed presentation of this work was made to TSVArea. The charts for that presentation are available at http://www3.ietf.org/proceedings/06nov/slides/tsvarea-2.pdf The Task Group has four projects: -- Precise time synchronization and clocking serving (802.1AS) -- Registration and reservation for streams (801.Qat) -- Queuing and fwding rules for streams (802.1Qav) -- Establishment of interconnected networks of cooperating devices (802.1ABaw(?)) based on 802.1AB (Logical Link Discovery Protocol). They have the feeling that RTP will be the main customer of the AVB work. Steve Casner pointed a need to be able to signal the new capabilities. Hadriel Kaplan noted a process issue to be worked out, for IETF people to see IEEE drafts. The answer is that interested persons should contact Michael Teener directly for access. Stephan Wenger saw a problem of usage to be solved, spanning the gap between Layer 2 and Layer 7. Hacks are there now. Steve Casner responded that we would need the Layer 4 protocol above IP to synchronize the end points. There is a pile of work to be done. 8. Some RTP design principles (Steve Casner ) =================================== Steve was invited to speak at this point because what he had to say relates to a number of succeeding papers on the agenda. First chart: why is RTCP needed? RFC 3550 says that the primary purpose is to provide feedback on the quality of data distribution. This is related to the congestion and flow control functions of other transport protocols. In addition, a growing number of other uses exist: - RTCP-XR as a vital means of monitoring the quality of VOIP sessions; - CNAME-SSRC mapping, counting participants, dynamic timers, lip sync for multiple media, SDES - more recently, feedback for retransmission, codec control. Colin Perkins remarked: it has all been implemented, for some applications at least. Steve Casner continued: in designing protocols, we have to keep things generally applicable, because we don't know how new features may be used. We need to separate control and data information because they may have different consumers. As one example, for multicast, third-party monitors may observe the RTCP without processing the media. In addition, the network treatment of control and media flows may be different. There is an integrated layer processing argument for reducing the number of multiplexing points. [D. D. Clark and D. L. Tennenhouse. Architectural considerations for a new generation of protocols. In Proc. ACM SIGCOMM '90, pages 200--208, Sept. 1990.] Recognizing other constraints (NATs), Colin has proposed RTP and RTCP multiplexing. Other rules governing RTP and RTCP usage have been changed, demonstrating the possibility for some flexibility going forward: - RTCP timing rules relaxed for feedback - relaxed RTP/RTCP odd/even port rule - added SSRC collision rules for address changes. Principles to keep in mind: - information in the data header should only be there to support processing of the data in that packet - security setup affects the channel, but not the media. Francois Audet: ?? Stephan Wenger: ?? 9. Multiplexing RTP and RTCP on a Single Port (Colin Perkins ) =================================== draft-ietf-avt-rtp-and-rtcp-mux-01.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-5.pdf Colin made two points: - use of separate ports has advantages and disadvantages - can multiplex RTP and RTCP if care is taken with payload type assignments. Jonathan Lennox asked: will we assume RTCP packets start with SR or RR? Colin replied that it is safer to avoid assumptions. Geoff Devine: putting RTP and RTCP in the same stream will completely screw up cable and WiMax resource allocation. When to use? Colin suggested a restriction to unicast sessions. He proposed to signal multiplexing using 'a=rtcp:' to indicate the same port number as on the m= line, falling back to normal odd/even rules if the SDP answer does not contain 'a=rtcp:'. In the case of SIP forking, some replies may show support, some not. Comment: signalling can't fall back if you are using NAT. Colin agreed this will mean problems. Henning Schulzrinne: SIP forking shouldn't be a problem -- extra streams should be CANCELled/BYEd. Hadriel Kaplan: if there is an ALG in the path, it may change m= line but not understand 'a=rtcp:'. You will end up with a changed port on m= line. Colin agreed: no matter what, you can end up with a broken case. Jonathan Rosenberg suggested a way around this: use a vseparate attribute to indicate multiplexing. If this attribute is received and understood, ignore 'a=rtcp:'. The implication is that the 'a=rtcp:' port designation is the fallback. Colin agreed with this suggestion. Colin went on to suggest port multiplexing would be disallowed for any-source multicast (ASM), but allowed for source-specific multicast (SSM). In the case of ASM, NAT is less often a problem in practice and there is more likely to be third-party monitoring of RTCP. Colin's next-to-final chart raised the key questions. Do we actually want to do this? It breaks the architecture, but has positives - removes one argument against use of RTCP. We do need an on-path logically separate control channel. This is preferable to putting control messages into header extensions or shims. Where ports are restricted, the choice comes down to multiplexing RTCP or running a separate control protocol on the same port like STUN. Jonathan Rosenberg commented that this was an interesting, complicated architectural question. We can get RTCP through NAT already with ICE. The latency issue has been fixed. There is a slight decrease in latency doing RTCP multiplexing. The key benefit, however, is that it doubles the capacity of the TURN server. It is not an obvious choice whether or not to permit RTP/RTCP multiplexing. Hadriel Kaplan agreed that the major benefit is to the TURN server. Multiplexing does avoid effort in some configurations. Stephan Wenger noted that port reduction has implications beyond the NAT problem. Eric Rescorla noted a fate sharing advantage. Phil Zimmerman agreed that it does reduce NAT bindings by a factor of 2. It also reduces ICE complication. Jonathan Rosenberg demurred, but Phil insisted that it was definitely helpful. Steve Casner observed that it is important to support separate transmission of RTP and RTCP, and this will be the usual way to do it. Hence we should not simplify ICE specifically on the assumption of RTP/RTCP multiplexing. Colin summarized: There is value here. He will change the details of negotiation as indicated in the above discussion. Jonathan Rosenberg agreed: do it. We should also address the general question of the role of on-path signalling. We need an architectrural discussion of where you should do what. Cullen Jennings responded to this last: RAI is discussing these topics, and is going to figure out how to make it happen, but we need people to stimulate the conversation. 10. Changes in ZRTP (Phil Zimmerman ) =================================== draft-zimmermann-avt-zrtp-02.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-10.pdf. Phil described a number of technical changes in the latest draft. Some of these were made in recognition of new requirements. He reported that a patent filing had been made relating to the work. The basic intent of the patent was defensive. He also indicated (in later discussion) that the patent would be used to enforce details of the implementation viewed as important to the fulfillment of its overall aim. This aim was to provide end-to-end security for communications without any requirement to trust the intervening networks. In passing, Phil noted new SDP attributes required for ZRTP discovery, initialization and authentication. These were the subject of a separate MMUSIC discussion. Eric Rescorla asked for clarification on when the shared secret [? - notes say SS] stream is brought up. Phil described the procedures introduced for sharing the results of the Diffie-Helman procedure over multiple streams. He then went on to describe the disclosure flag. An implementation has to indicate to the remote party if this end has disclosed the session key to another party. Hadriel Kaplan asked if this is signalled in ZRTP or SDP. The answer was ZRTP. Hadriel had further questions about signalling, but these were ruled out of scope. [One Chair at least was becoming impatient with the extent to which discussion of IPR and political aspects at this point was replacing discussion of technical issues that needed to be addressed.] Phil indicated that one can't have ZRTP intermediaries, since they look like man-in-the-middle (MITM) attackers. But an user could engage a ZRTP end point to act on the user's behalf and forward the media to the user's device. Jonathan Lennox asked if that meant ruling out the use of ZRTP with a conference bridge. Phil replied that he recognizes that the security characteristics will be different in a conference. Magnus Westerlund pointed out that there was an architectural issue to be addressed: the best way of getting security information between end points. Phil indicated that he did not want to discuss this now, but rather, wait for list discussion to settle down. =============================================================================== At this point the meeting ran out of time. A second session was scheduled for Thursday afternoon, to address the remaining presentations and the architectural issues they entailed. ================================================================================ Second session Thursday 15:10 to 16:30 Chairs: Colin Perkins, Roni Even, Tom Taylor 1. Agenda and summary of issues (Tom Taylor ) =================================== Charts available at http://www3.ietf.org/proceedings/06nov/slides/avt-12.pdf The agenda was agreed: VoIP shim and DTLS-SRTP, which were leftovers from the earlier agenda, and ZRTP again with focus on the transport issues that have been the subject of discussion on the list. The focus of the meeting was to be on transport issues, not security per se. Tom summarized the issues the Chairs saw in each presentation (see charts). The speakers were requested to address these issues in their presentation. 2. VoIP Shim for RTP Payload Formats (Ingemar Johansson ) =================================== draft-johansson-avt-rtp-shim-01.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-7.pdf The proposal relates to multimedia telephony service (3GPP). EDGE Layer 2 has increasing probability of packet loss with larger packet size. (Could be improved with tweaking.) There is an issue of performance at the cell edge. Depending on the radio technology in use, there is a requirement for adaptation at the cell edge, to reduce the packet rate quickly as transmission becomes weaker. Statement: RTCP is either in use or not, implying (if it is) continuing consumption of bandwidth and battery even when specific signalling need not be present. Ingemar's argument is that bandwidth consumption by RTCP can have significant effect on the performance being measured. Alternatives to consider: various modifications to RTCP. Possibility of compression. Joerg Ott: ?? Stephan Wenger: some of the items in the draft relate only to AMR. The draft actually covers three different topics. Flemming Andreasen: the extension involves bi-directional communications. (Agreed.) How are parties distinguished in a multi-party session? 3. Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) (David McGrew ) =================================== draft-mcgrew-tls-srtp-00.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-6.pdf DTLS is TLS reworked to operate over UDP. The first chart summarizes the procedure. Pre-setup: SDP signalling is used to indicate willingness to use DTLS and provide a fingerprint. Key exchange occurs in the media channel. This allows reuse of DTLS key establishment procedures. An extension to DTLS is used to negotiate SRTP protection profiles. The DTLS master key is used to generate SRTP keys. The next chart presents the TLS handshake extension needed to support SRTP. The chart following shows the message flow, including early media to show how that would work. Subsequent charts showed the various possibilities for transport of the TLS handshake and indicated that the method met all the requirements listed in the rtpsec discussion in Montreal. Roni Even asked how resynchronizing is done in mid-session keying. Since there are just two possibilities for any given packet, David suggested trial and error -- try the old key, if it doesn't work, try the new one. Flemming Andreasen asked how they associated SSRCs with the correct security framework. David provided further clarifications. Setup takes about 2 1/2 round-trip times (varies). Phil Zimmerman asked how initial security is provided? David suggested two options. At this point, discussion was cut off, because these questions dealt with security rather than transport issues, and should therefore be dealt with in rtpsec. 4. ZRTP Transport Requirements (Phil Zimmerman ) =================================== draft-zimmermann-avt-zrtp-02.txt Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-13.pdf Phil indicated that ZRTP involves two message types: - discovery -- need to indicate support for ZRTP while doing no harm - key agreement messages -- sent only between ZRTP endpoints. Flemming Andreasen asked why one would not just signal the keying information. Phil pointed out that the signalling might not necessarily be SIP. His team wants to create a bump in the wire. Dave Oran asked how a bump in the wire knows that it is receiving RTP packets. With further discussion, this requirement turned out to be 'nice-to-have'. Further requirements: - both types of message should be able to traverse the maximum number of types of intermediate boxes - message transport should work for unidirectional or inactive data streams - there should be no need for extensions to signalling protocols - discovery messages must be harmless to non-ZRTP end points - discovery msgs need a lot of retransmission (empirical observation) (may be able to use ICE approach). To ensure correlation, the key agreement messages should be transmitted on same port as the media. Need to make it fast. Stephan Wenger expressed doubt that key agreement could be independent of signalling. Joerg Ott remarked that the requirements just described make a perfect case for RTCP. Rohan Mahy suggested that it would help if Phil could distinguish between protocol requirements and implementation requirements. Phil responded that this distinction is difficult to make. Phil summed up: it seems to be a question of RTP vs. RTCP for the key agreement messages. They are managing now with header extensions, but are willing to look at RTCP. 5. Open discussion =================================== Colin Perkins: the last two presentations are clearly trying to carry similar information. It would be good if they could use the same mechanism. Eric Rescorla: with DTLS, the two ends know both can do it. This differs from ZRTP. Phil Zimmerman: unhappy with the view that signalling is essential. Colin Perkins said he would probably run into trouble without it. Flemming Andreasen: shim is really the same problem. Hari Desineni: in-band is not the answer. They need light-weight RTCP. Stephan Wenger: there is value in an additional RTP profile allowing shimming and light-weight header extension. Shim is really an extension of the CCM draft. It has a very limited use case: point-to-point bidirectional voice using AMR. Regarding encryption: he is hesitant to use RTP packets for control. If you do, you have to set up a separate redundant channel for intermediate boxes. He wants a key mechanism that works and respects the architecture. Roni Even: DTLS can look at signalling possibilities. Steve Casner: shim is solving a very specific problem. Redefine the AMR payload to make it work. Correlation works just as well with two ports of known relationship as one port. But we had to give up the even-odd rule because of NATs. Ingemar Johansson: it would be be good to use RTCP to send only the information you need. Flemming Andreasen: fully against use of RTP to signal. There are problems of directionality and fuzzy semantics. Try to keep it in RTCP. Hari Desineni: RTCP has become quite usable. Colin Perkins: has made it obvious that he is against multiplexing control into the same packets as voice. Comments have been made about the size and timing/persistence of RTCP. We have already made a number of changes, particularly with AVPF. It would be reasonable to allow momentary changes in rate. For RTCP packet size, the obvious fix is to relax the rule on compounding RTCP packets. This is not a change he'd much like, but not terribly evil. Steve Casner: we could reconsider the requirements for RR, SR. The rules for timing were for multicast sessions. We may be able to adjust them for specific circumstances. We might be able to create compression for specific sequences in compound packets. Stephan Wenger: this isn't a final solution. There is still an order of magnitude difference in bit rate between RTP and RTCP. And once RTP and RTCP are mixed on same port the overhead goes up. Hari Desineni: likes idea of just sending the feedback packet. Cullen Jennings summed up. There is a fair amount of consensus on ways DTLS and ZRTP should NOT work. We could do some experimenting. Beyond that, there is no strong consensus here. Take it offline.