AVTEXT - IETF90 - 22 July 2014 - Toronto, ON, Canada Chairs: Keith Drage / Jonathan Lennox Note takers: Stephen Botzko / Roni Even / Mary Barnes 14:20 Agenda bash and status update (10 min) - Chairs Agenda survived the bashing intact. Two RFCs published since previous IETF - RFC 7160, RFC 7198 Two new milestones - RTP Stream Pause & Resume, RTP Splicing Notification 14:25 Taxonomy (30 min) - Bo Burman draft-ietf-avtext-rtp-grouping-taxonomy-02 Review of changes. RFC 6190 Transmission Modes Should SST/MST be a per-media-source encoder property? Colin Perkins - MST-SS language seems to make no sense. Jonathan - agrees that it is a source property Bernard Aboba - SST-MS does make sense. Some debate about SST-MS - "which ’S’ is which?” Colin Perkins - perhaps reuse of SVC terminology is simply a poor choice. Distinction between session and multiple sessions when using multiple streams is perhaps not that important? Bernard - might be helpful to keep this distinction for descriptive purposes Peter Thatcher - Suggest not using acronyms at all, use longer words. Spell out “Single/Multi Stream, Single/Multi Session” Mo Zanaty - Suggest using “Transport” rather than “Session” Colin: Write long descriptions first, and then come up with names/acronyms for them. Outcome: concepts make sense, should be a property of a media source, but a lot of confusion on the specific names/acronyms/wording. List discussion needed; write long dis Media Chain Sender Roni Even: do we need to separate media capture and media source? Bo: Media Source has time information in it, but media capture does not. Stephan Wenger: makes sense to him, there are media formats that can have time information in them, but input from a camera does not. Media Chain Receiver Side: Stephan: would be helpful to simply publish the slides so they can be referenced. Provoked sidebar discussion on ascii art and new RFC format... Dan Burnett: New RFC format is looking for WGs to volunteer to test the new format. Colin Perkins: Slides will be in the proceedings with a long-term stable URL. Stephan: The RFC-to-be should cite the URL in the proceedings, with the picture. Communication Entities Mo - no taxonomy word for the source and sink ("logical endpoint"), and one is needed (Bundle is example) - no taxonomy word for the RTP packet streams flowing between the above. Take this to the list as well. Ready for WG last call? Probably the next version, unless something tells us different. Need review, esp. by mmusic and rtcweb. Stephan: sooner rather than later is better. WGLC induces review. 15:07 RTP/RTCP extension for RTP Splicing Notification (10 min) - Roni Even draft-xia-avtext-splicing-notification-03 Review of Splicing Adopt this as a WG document? No objections (either on the list, or in the room) Agreed - authors should spin new revision as WG document. Will need some technical review once it’s a WG item. 15:10 Negotiating Media Multiplexing Using SDP: Usage of header extensions / RTCP (30 min) - Christer Holmberg draft-ietf-mmusic-sdp-bundle-negotiation-07 RECEIVER-ID Should the mid be signaled as a unique header, or should a generic SDES be used? Plan is to define a unique header for now (BUNDLE), but switch to generic if avtext defines a generic SDES. Magnus's draft is compatible, its just a matter of picking the correct extmap name for the header extension. When should the MID RTP/RTCP be sent? Not in every RTP packet. Soliciting opinions on details of when it should be sent. Colin: Often enough that the receiver gets it...send it when a new SSRC starts sending. Other than that it doesn’t matter. Only need guidelines. Want implementations to be robust to not getting it. Details may not matter, as long as it is sent when the SSRC sending starts. Mo: purpose is to disambiguate 2 m-lines that have the same payload type. General guidance is receiver needs it for dejittering, so it is needed within the jitter buffer interval. Jonathan: Can a mid change for given stream? Should specify. No response. Peter: Need to define what the receiver's behavior is. Christer: thinks that is outside of scope. Bernard: Why not use RTCP receiver reports to tell you when the mid rtp extension was received? Mo: analogous to RTCP CNAME transmission. Mo: thought Jonathan's mid change was allowed. Useful for systems that can support it, doesn't harm systems that can't Paul Kyzviat: agrees that defining receiver behavior is important. In particular, there is an expectation that the receiver is creating an SSRC/MID mapping. Colin: thinks that allowing it to change in a stream might be a problem. Could be hard to tell when it changed. Would rather say that you cannot change MID unless you also change SSRC - simpler, easier to specify, and doesn’t cause synchronization problems. Christer - do we need negotiation for receiving in RTCP only vs RTP and RTCP together? mmusic said no. Colin: You have to send it in RTCP. Sending it in RTP doesn't need negotiation. It may be needed by applications, but it doesn't matter at the RTP level. Keith: what about the Westerlund draft? Mo: authors are still wanting to pursue it. Particularly for CNAME (in addition to mid/receiver ID). Jonathan: do we want to pursue it at this point? Colin: Bundle should proceed as is. Westerlund draft is also a good idea, we should proceed with it. Bernard: may not be much reason for Westerlund draft after this. Outcome: will ask about Westerlund on the list, but it isn't a dependency for Bundle anyway. Bundle WGLC should include AVTEXT. Discussion would happen on mmusic list. 15:55 RTP Stream Pause / Resume (15 min) - Bo Burman draft-ietf-avtext-rtp-stream-pause-01 Review of changes. Should comparison section be reduced? Bernard: I suggest a paragraph should be enough Bernard: Can I send unsolicited pause notifications? Answer: Yes Bernard: Do you know if other end got it? Answer: No. Though RTCP sender/receiver reports could also be sent after you stopped the RTP stream. Bernard: Might be useful to have description of this use in the draft. Ready for WG last call? Start WGLC next Monday, right after new draft posted. 16:03 Close