AVTEXT working group ==================== Tuesday 14:20 - 15:50 (Regency A) Chairs: Keith Drage / Jonathan Lennox Note takers: Paul Kyzivat & Colin Perkins Jabber Scribe: Bill VerSteeg. 14:20 Agenda bash and status update (10 min) -------------------------------------------- Presenters: Chairs Slides: slides-88-avtext-4.ppt draft-ietf-avtext-multiple-clock-rates-10 - multiple-clock-rates with iesg. draft-ietf-avtext-rtp-duplication-04 - duplicating streams draft completed WG last call, pub req to be sent. unified plan - appid draft in MMUSIC -> Colin Perkins: should be in AVTEXT? chairs: is anything else needed from AVTEXT? Adam Roach: no Chairs to discuss with MMUSIC chairs where appid work should be performed. 14:30 Taxonomy (45 min) ----------------------- Presenter: Bo Burman Slides: slides-88-avtext-2.pptx draft-lennox-raiarea-rtp-grouping-taxonomy-03 Changes since -02 slide should be "changes since last meeting" Keith Drage (cochair): (after question as to whether there was any last input) declared this a WG draft. (It’s been proposed on the list for over a week.) Bo will act as lead editor on the draft. Bo Burman to submit a new version as a WG draft. Roni Even: slide 6 talks about "source packet streams" but the draft only talks about "packet streams"; need to ensure the draft reflects the different types of packet streams. Bo: document has both. Packet Stream is more general – there are three variants. Source Packet Stream is, or should be, in document. Need to fix if not. Chair: Request Roni to post comments about specific defects in document. Mo Zanaty: suggests that this might be too complex; all that really matters is the "SSRC streams" themselves and the relationships between them. the draft has too much detail on the different types of streams. Bo Burman: using "ssrc stream" misses some features we might want to describe, for the purpose of the streams. Harald Alvestrand: disagrees with Mo Zanaty; we need to describe much richer concepts than just SSRCs; supports the current scope of the draft. Mo Zanaty: clarifies that it's the concept of a "sequenced packet stream" that is missing. Do you consider SST and MST two packet streams or one packet stream. Bo Burman: isn't this implicit...? Mo Zanaty: (didn’t get comment – more about his prior comment.) Magnus: if the issue is about the name “Packet Stream”, we can discuss the name. But we need something for this purpose. Keith (cochair): asks for clarity – terminology or technical issue? is the concept fine but the name wrong, or is it that the concept is wrong? Roni: like the structure. Would be good to have and alternate terminologies used elsewhere; can we include a table containing the mapping between the terms here and the terms used elsewhere, so people can look up the name they need? Magnus Westerlund / Bo Burman: the situation isn’t simple enough to put everything in a table. Agree that this would be useful, although the mapping isn't one-to-one, so the mapping has to be done carefully. Bo: a single packet stream has a single SSRC when mapped to RTP. Colin: all the streams are sequenced, not just Sequenced Packet Streams. ???: Section 3 is where to clarify this, if anywhere. Jonathan Lennox: (re Media Transport Detailed) what are these distinctions useful for? (slide 17) Colin Perkins: what's the difference between "transported" and "received"? Magnus: transport is what's on the ethernet; received is after the NIC when the packet's in the OS. Jonathan Lennox: (re Media Transport Detailed) when is the distinction useful? Magnus: might be local loss; bufferbloat in the host stack, etc. Mo zanaty: likes the distinction between sent and transported; fuzzy about the difference between transport and received. Roni: this is end-to-end transport? yes, for whatever the end points are. what is the different between Sent and Transported Packet Stream? Bo: wants to know if the introduction of these is useful. Conclusion that at least one thought so. But some confusion. (slide 20) Colin: does a Participant have a single signaling address? There could be multiple signalling addresses for one participant. Bo: it’s a choice to make the distinction. Harald: there could be multiple addresses for a single participant, but never multiple participants for a single address. Roni: think there should be a distinction between network intermediaries (eg mixers) and participants. Is an RTP mixer an endpoint? Bo: depends on what type of middlebox it is; whether the mixer is addressable. Magnus: an RFC 3550 mixer is an endpoint. Mary Barnes: confused by Roni because in clue we call an MCU an endpoint. Agrees. Colin Perkins: depends on addressibility and type of middlebox: some are clearly endpoints; others are more or less visible, and might not be endpoints according to this definition; might need to clarify. Magnus: if we want additional definitions for middleboxes, please propose text. (slide 25) Colin Perkins / Jonathan Lennox / Drage: this has value, but consider whether it should be in the topologies update draft (i.e., shouldn't the topologies-update use this terminology). Magnus: maybe, but this draft also mentions signalling topologies, so is broader than the topologies draft. Magnus will post something to the list to start discussion of what goes here, what in the topologies draft. Colin: The examples like point-to-point communication are valuable, but maybe belong in some other document. Jonathan: ensure we don’t conflict with topologies draft. Magnus: maybe can look at using the taxonomy to help clarify topology document. Paul Kyzivat: is something corresponding to a CLUE switched capture in the draft? not sure. Bo: not sure – don’t think so. Need to discuss. Jonathan: also maybe nothing corresponding to what an AppId labels. Mary Barnes: suggests waiting a little before sending this to the iesg, to ensure it matches needs of CLUE (e.g., wait until after IETF 89). Magnus: will be okay, provided the CLUE concepts can be defined in terms of the concepts in this topology. Chairs: want to get this to wg last call soon; Want to be sure we have all the necessary concepts; please give feedback. 15:15 RTP Header Extension for RTCP Source Description Items (15 min) --------------------------------------------------------------------- Presenter: Magnus Westerlund Slides: slides-88-avtext-0.pptx draft-westerlund-avtext-sdes-hdr-ext-01 - (slide 7) Bernard Aboba: privacy concerns - don't necessarily want all these (e.g., email). Putting a URN in every packet is a really bad idea. Mo Zanaty: but this is potentially already sent in rtcp. - harald: Thinks the whole thing (putting SDES items in RTP header) is a bad idea. Having redundant data is a bad idea. Should fix unreliability of RTCP. not make the protocol worse by duplicating the info. Cullen Jennings: CNAME privacy is dealt with by having random CNAMES. He agrees with Harald but wants to put it all in RTP, not RTCP. Mo Zanaty: this gives fate sharing between the sdes information and the RTP packet; putting this into rtcp (whether "fixed" rtcp or not) doesn't give that fate sharing. - charles eckel: there's already some precedent for putting some stuff from RTCP into RTP, and this seems appropriate. - harald: (sensible rant about fate sharing). RTP is packets that are processed *fast*. Convoluting it with all this other stuff is making stuff more complicated. He has limited sympathy for people who put RTP and RTCP on different transports. Magnus: that isn’t addressing fate sharing. Harald: a key frame doesn’t fit in one packet. You can lose an RTCP packet or one packet of a key frame. Either case is a problem. Mo Zanaty: argument would be stronger if this was for critical information only (CNAME, SRCNAME) - not email, etc. Maybe this only should be used for something that is critical for decoding. Colin Perkins: but do we want a general mechanism that can be extended if we need, or lots of specific special-case mechanisms. One of the arguments is that we keep designing mechanisms for specific cases. Maybe we should make it more general, for cases where it is appropriate to do. Justin Umberti: thinks this is okay. only thing we really need in the header is the AppId. If we don’t get CNAME right away, tough. Harald: disagrees. Bernard Aboba: important to maintain distinction between data and control planes. Harald: CNAME, AppId, and SyncClock - ???. Magnus: no problem restricting the set of things we register to use this mechanism. But do we want it for those things that need it? Or should be doing something to enhance rtcp. Keith (cochair): we need list discussion on that the scope of this should be, and if we need it at all. 15:30 RTCP Source Description Item SRCNAME to Label Individual Media Sources (15 min): -------------------------------------------------------------------------------------- Slides: slides-88-avtext-1.pptx draft-westerlund-avtext-rtcp-sdes-srcname-03 Not covered due to lack of time (previous discussion overran). 15:45 RTP/RTCP extension for RTP Splicing Notification (5 min) -------------------------------------------------------------- Presenter: Lingli Deng Slides: slides-88-avtext-3.pptx draft-xia-avtext-splicing-notification-02 Keith: in Orlando there was agreement that it was interesting, but not enough interest to work on it. Has that changed? Does anyone else want to work on it. Colin: seems technically reasonable. Keith (cochair): currently he sees one operator who wants it and one vendor who supports. He wants to see more interest. Colin: will review the draft. Keith (cochair): At the current public level of interest no reason why this cannot be an individual submission rather than a WG item. Roni: agrees with Colin that this is straightforward, sees no reason to object to it. Gonzalo Camarillo: we have problems with energy in the WGs. Need evidence of. Colin: this seems like something useful if you have need to do splicing. We have accepted drafts with less support. Jonathan: if we got a request from an industry association, that would help. Keith: this will go to the list. Chairs are happy to go through this again. But are looking for more evidence of people who are interested in working on or using the results of this. 15:50 Close.