IETF 73 AVT Minutes Many thanks to Stephan Wenger and David Oran for taking notes. The AVT Working Group met twice, on Monday and Tuesday afternoon, Nov. 17 and 18, under the chairmanship of Roni Even and Tom Taylor . About 60 people attended the first session and 40 people attended the second one. In addition, there was an informal session on fast synchronization held on Tuesday morning. Meeting slides are at http://www3.ietf.org/proceedings/08nov/slides/avt-x.pdf where x runs from 0 through 12 as indicated below. Introduction and Status Update Chairs ========================================== Slides in avt-0.pdf. The session started at 15:25. The Working Group expressed their thanks to Colin Perkins , who stepped down after 10 years as AVT Chair. Colin was not present physically but was on Jabber. Agenda bash -- no changes. The usual Note Well charts were presented. Document status: Published RFC5371 & RFC5372. Three drafts in RFC editor queue, two in AD evaluation, 1 publication requested, 2 waiting for AD, 1 waiting for revision (rtcp-ssm). For further details, see the slides. Roni gave a short update on avt-seed-srtp-06. New draft 07 will be submitted after the meeting, addressing comments from David McGrew . The authors hope that this next revision will be ready for WGLC. Eric Rescorla suggested that David McGrew be given an opportunity for a one week review before WGLC. Roni accepted the suggestion. 15:35 RTP Payload Format for SVC Video Thomas Schierl ======================================================== draft-ietf-avt-rtp-svc-15 Slides in avt-1.pdf Slide 4: Changes from version 13 - New Packet Types David Oran suggested that one of the packet types now in the normal numbering space should be deliberately numbered in the extension space to provide a clear example for others and ensure implementations do this right on day 1. Slide 8: sprop-operation-point-info example Thomas Schierl asked the meeting whether the usage of scalable-layer-id in the offer-answer example shown on the slide was correct. Roni expressed a belief that it was OK. Jonathan Lennox had a concern about bidirectional operation, but the concern was resolved satisfactorily. Roni pointed out that if the answer refers to the same sprop-operation-point as the offer, this shows willingness to receive it, which is the desired result. Slide 10: Changes - Update of existing parameters With the feedback received, more work is required now. Slide 13: Open issues Stephan Wenger suggested that this chart be reviewed point by point, with the room suggesting an opinion on each point. Agreed that more SDP usage examples are needed. Rule on scalable-layer-ID: got feedback. The authors should clarify usage of scalable-layer-ID in all usage forms: send only, receive only, and send-receive. sprop-ssrc was a new parameter in 3984, should it be superseded by draft-lennox-avt-h264-source-fmtp-00? Discussion was deferred to the 3984bis presentation (see below). Roni issued a request for volunteers unconnected with the design team to review both SVC and 3984bis for readability to get in touch with him. The two drafts should be last-called together because of dependencies. The target is a new version and WGLC within two to three weeks. RTP Payload Format for H.264 Video Ye-Kui Wang ================================================ draft-ietf-avt-rtp-rfc3984bis-01 Slides in avt-2.pdf Roni presented on behalf of Ye-Kui. He noted that Ye-Kui did most of the work. Two open issues left - reference update, and sprop-ssrc. Should it be superseded by draft-lennox-avt-h264-source-fmpt-00? Jonathan Lennox noted that the issue was his. Rather than having SSRC-based parameters specific to H.264, define them in a generic way (in MMUSIC). Define at least the SPROP parameter sets in the FMTP line rather than here. Roni said he would discuss the way forward with Ye-Kui. Multi-Session and Multi-source transmission Thomas Schierl ============================================================== draft-schierl-avt-rtp-multi-session-transmission-00 Slides in avt-3.pdf. The basic problem is time synchronization between samples in multiple streams. In layered schemes, exact matching of time periods is required to decode correctly. This draft considers alternative means to achieve the objective. The following discussion took place at chart 4. Joerg Ott asked what order of magnitude of time imprecision the draft was talking about. The answer was errors in the order of 10s of milliseconds. Magnus Westerlund said the worst he had observed with Windows was a clock skew of 15 ms. David Oran expressed his confusion at this point -- one can get to the system clock in modern systems, thereby achieving an inaccuracy of less than a microsecond. Was the problem that of matching the system clock to NTP? In any event, if the clock is subject to skew, isn't this problem fundamental, and not related to multi-session or multi-source? Magnus Westerlund agreed: one should use the same reference clock for all the sessions/sources. Thomas responded that if the different sessions become active at different times, you get different rates, and hence different skews. Magnus: that's not how you do it. You have a single reference clock. Use that where it belongs. Jonathan Lennox remarked that this seems to be counter to RFC3550. Magnus disagreed. Take one reference point, sample against the system clock, then you can take clock reference, see how much has run since then, and do this consistently across the layers/sources, you don't have a problem. [There was further discussion, but it was not captured in the notes.] At chart 9, David Oran questioned whether timestamp alignment can be done without signalling. Thomas Schierl indicated that signalling would be implicit, through use of payload types. Roni ruled that the authors should provide a problem statement and examples to the list so we can see if there is a problem or not. Xavier Marjou spoke a final word in favour of the authors' proposal, saying that timestamp alignment is simple and effective, and is important to his company. Rapid synch of RTP Sessions (Jörg Ott standing in for Colin Perkins) ==================================================================== draft-perkins-avt-rapid-rtp-sync-00 Slides in avt-4.pdf This deals with a different aspect of the problem of time synchronization. The basic RTCP mechanism is to provide the correlation between CNAME, SSRC, and NTP. This draft deals with the part of the problem that correlates CNAME with SSRC. Chart 3: speed with which unicast flows can be synchronized. The chart suggests that SSM source can behave like unicast when sending the sender report. Jonathan Lennox remarked that the chart overlooks the case of N to N unicast conferencing. Chart 6: proposed feedback message David Oran worried about a potential feedback implosion at NATs. He noted that the feedback target may differ from the source. In that case, how does the source know to send the SR? This was left as an undefined process. Roni suggested that the previous draft authors address requirements once more, then discuss the relationship of their work with this draft. Unicast-Based Rapid Synchronization with RTP Multicast Sessions Bill VerSteeg =============================================================== draft-versteeg-avt-rapid-synchronization-for-rtp-01 Slides for this specific draft in avt-6.pdf. Roni Even presented a preliminary comparison of this and the next draft, since they are competing approaches to the same topic. See avt-5.pdf. The problem being dealt with is reducing synchronization time when an RTP receiver joins a multicast stream at a random point in time. The Versteeg draft was already presented in Dublin. Both Cisco and Microsoft have provided related IPR disclosures. Following the presentation of avt-6.pdf, Joerg Ott commented that the draft reads with an implicit assumption that you can always prime in real time. Presenter replied that there is no need to send the priming information faster in unicast than it is being broadcast in multicast. There were further comments with reference to an IEEE paper. Roni remarked on the need to address all the issues such as congestion. RTCP Feedback Mechanism for Burst Streaming Orit Levin =========================================== draft-levin-avt-rtcp-burst-00 Slides in avt-7.pdf The presentation was interrupted by questions, many of which were relevant to and referred to both draft-levin-avt-rtcp-burst-00 and draft-versteeg-avt-rapid-synchronization-for-rtp-01. Joerg Ott asked how often the information on bandwidth constraints was updated. Orit referred to slides still to come. Joerg was skeptical that this aspect of the solution was generally feasible -- it assumes managed services. Magnus Westerlund, as Transport AD, remarked that any proposal needs to have a solid story how this works in generic cases. Stephen Casner wondered if the solution took account of the possibility of multiple simultaneous joins. Slide 7: Receiver Driven Burst Mechanism Ali Begen asked what happens if the SCI message terminating the initial burst is lost. Orit replied that the message can be retransmitted. Roni couldn't see how the client could know that it had to do so. The IGMP join is before RTCP. Here, you lose RTCP, and then send the join. Orit said the Join is not sent immediately, but is sent under client control. This makes the solution scalable. Ali Begen remarked that if the delay between client and server is 50 ms, you have 100 ms roundtrip. David Oran suggested that the deterministic stability of this process is quite tricky with the potential lags involved. He would like to see proof that it is stable, as Cisco draft contains proof that their solution is stable. Joerg Ott asked: since the server is waiting for explicit termination, what happens when a set-top box crashes? Orit indicated a timeout would operate to close the session. Roni called for people interested in an ad hoc session to be held Tuesday morning to please see the chairs. The meeting was held, and a report sent to the list. 16:50 RTP Payload Format for Bluetooth's SBC audio codec Hoene draft-hoene-avt-rtp-sbc-00 Postponed to the next session for lack of time. 17:00 End ================================================================================ ================================================================================ AVT Tuesday, 18 November 2008 at 17:10-18:10 (Salon AB) Roni Even repeated the standard IETF Note Well advice. RTP Payload Format for Bluetooth's SBC audio codec Christian Hoene =================================================== draft-hoene-avt-rtp-sbc-00 Slides in avc-8.pdf David Oran asked about the compatibility between any patents associated with the codec and open source development. The presenter indicated that there is some contract between Bluetooth SIG and Philips about this, but the presenter cannot comment on the details. Roni asked the WG to review on draft, then decide on WG status. RTCP XR Clark ============================================== draft-ietf-avt-rtcp-xr-*cp-xr Slides in avt-9.pdf. Geoff Hunt presented. Slide 2 Joerg Ott noted an IPR disclosure against the old draft. To which of the new drafts does the old disclosure apply? Geoff Hunt indicated that he should ask Cisco. David Oran thought that it was v-factor [??]. He will double check, but not soon. Stephen Casner noted that SR reports provide for some time of feedback. Geoff Hunt replied that "in the wild" there is a problem. Stephen asked if this was because there was only one participant. [Further remarks not captured.] 17:30 RTP Payload format for Application and Desktop Sharing Omer Boyaci ============================================================ draft-boyaci-avt-app-sharing-00 Slides in avt-10.pdf. Stephen Casner remarked that large parts of the presentation were irrelevant for the WG. Omer Boyaci asked him to wait for the end of the presentation. Colin Perkins remarked (by email) that similar work was brought in before. Group didn't feel that this was AVT work. Dan York agreed this was perhaps perhaps not in the right group. There would be a tangle up with HIP (Host Identification Protocol in IETF namespace). Who is going to use it? Raphael Coeffic stated that there is value for this work, though maybe not in this WG. There are lots of commercial applications for this, but to his knowledge not so many inter-workable open clients. It would be a good idea to have this capability. Joerg Ott remarked that there are quite a few clients for mac (vnc). He has had no need to use it. Omer suggested classroom style presentations, where one needs multicast. Joerg replied that there are things that are kind of open. Are they sufficient? Just because we come back to this every other year, does not mean that this makes it better. Where is the big company interest? Boyaci: there is interest from a certain commercial company. 17:50 SRTP Store and Forward Rolf Blom ==================================== draft-mattsson-srtp-store-and-forward-01 Slides in avt-11.pdf. Jonathan Lennox asked whether the packet index on chart 7 is the RTP sequence number? Is the derivation shown backwards in the slide? Rolf agreed that the slide was unclear. Eric Rescorla mused that in the voicemail context, the issue seems to be around where the key comes from. Rolf said it could be a ticket based key management system. He noted that the system has to work without key exchange. Richard Barnes pursued the matter, saying that they need a section in the draft on key management. Putting thing into crypto which are normally not there makes things difficult for certification and such. Rolf clarified that the nonce is an analogue to the SSRC, not literally the SSRC itself. Key management is out of scope here as it is in SRTP. Dan Wing said he was looking forward to adding this information [Dan, check this!]. RTP/RTCP Overlays Joerg Ott ============================== draft-ott-avt-rtcp-overlay-00.txt Slides in avt-12.pdf. David Oran noted that conveniently, there is no loop in sight in the picture. Joerg assured him that the draft contains loop discussions as well. Roni asked if this was intended to lead to an RTP profile. Joerg replied that they had in mind a BCP defining how to put RTCP over a multicast overlay. There would also be a protocol specification limiting the spread of RTCP packets to certain regions. Roni asked if it works with all the existing profiles. Joerg said it did. Roni asked who had read the draft. Very few had done so. Roni concluded that it was interesting, but needed more review. _______________________