IETF 85 Atlanta - 7th of November 2012 Minutes of AVTEXT WG Meeting Chairs: Keith Drage and Magnus Westerlund Minute Takers: Bill VerSteeg and Xavier Marjou Note Well, Agenda and WG status The chairs presented the WG status slides, including Note Well, Agenda and Milestone Status. Finished up with the status of the draft-ietf-avtext- rtpduplication-00 WG document. The current open issues are its dependency on draft-westerlund-avtext-rtcp-sdes-srcname-02 as well as on the SDP signaling documents in MMUSIC draft-ietf-mmusic-duplication-grouping-00 and draft-ietf- mmusic-delayed-duplication-00. Content Splicing for RTP Sessions draft-ietf-avtext-splicing-for-rtp-11 Magnus Westerlund presented on Jin Wei's behalf. The current status is that the document been through its 2nd IESG telechat. This resulted in some new issues by IESG. There was still two issues; Discuss from Stewart Bryant on "rtp payload security mechanism" and new text is proposed to address this. Pete Resnick raised three issues where one is resolved and the other two has received proposed text. AD (Gonzalo Camarillo) commented this seems perfect to him. The WG Chairs asked the WG if there was any concern over the changes? (no one objects). The group thinks this is the right approach, ok for WGLC. RTP Media Stream Pause and Resume http://www.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-03.txt Slides presented by Bo Burman. Bo reminded the WG about the IPR on the draft. Bo's Goal is to get consensus on suitability of the proposed item. Provided an overview of the proposed solution. A mechanism for pausing and resuming media stream, based on RFC 5104 CCM messages. The new version -03 explains better temporal dependencies. Provided the relation to CCM. TMMBR and TMMBN as described are not suitable, especially when it comes to resume semantics. Roni Even commented that TMMBR is already used for pause/resume, restriction for multicast only. Magnus Westerlund (as individual) responded that the restriction does not go away when unicast, semantics of specification is violated. Roni followed up that this is being used today, other mechanism will cause interoperability problems. Maybe the way forward is to change the TMMBR/TMMBN specification. Magnus (as individual) commented that you said you would write a draft at last meeting, you didn't. Roni committed to write a draft describing the changes to TMMBR within one month. Colin Perkins commented that Bo's proposal clearly work, the issue is interoperability. Bringing something new with interop issue is not desirable, support a draft on TMMBR. Stephen Botzko also supported the creation of a based TMMBR draft. Magnus (as individual) stated that there are differences between the 2 approaches. Everyone says TMMBR works without producing a draft so that it can't be evaluated against our solution. Also the presented solution contains additional functionality like indication from which packets the pause will occur. Charles Eckel commented that he would be interested to see the TMMBR approach, very nice path forward to avoid interop issues. Chair (Keith Drage) asked the WG: Does anybody think there is not a problem to solve? (No objections or comments) Keith stated: So people think new doc is needed. Roni will propose a new draft within the next month. With an additional draft on the table, people can compare the 2 docs and discuss them. RTCP SDES Item SRCNAME to Label Individual Sources (15 min) http://www.ietf.org/id/draft-westerlund-avtext-rtcp-sdes-srcname-02.txt Slides presented by Bo Burman. Bo reminded the WG about the IPR disclosure on this Internet Draft. An overview of the issue is the situation when one has multiple streams. And there is a relation at the RTP level itself (not in SDP), for example FEC or redundancy. SDP Grouping is not always sufficient. When you use an SSRC, you cannot use that as group identifier, as it may change, and info not always available in media path. Harald aksed if Bo want to comment on Ericsson's licensing? IETF prefers solutions for which there's no licensing. Wondering, whether there is a way to work around it so that the IPR can be avoided. Bo responded that the offered terms are RAND, see disclosure. Harald Alvestrand requested Bo to describe the relationship with MSID name? MSID can groups SSRC on the same level. Bo: here we have a hierarchical way of references; MSID is a set of streams of the same level. Justin Uberti wondered if we can't merge with MSID to solve the issues. The Presentation moved on to the Relation example (Slide 7) to better answer questions. In this figure CNAME is root of hierarchical tree. Blue one conceptual nodes, Green ones are actual RTP media streams. For example, to reference all of the (video) streams, you refer to a.video. Harald asked if the graph is a Directed Acyclic Graph (DAG) or a tree? Bo responded that he is not sure. Harald commented that it seems it's most of MISD + SSRC grouping. Justin asked what is FEC here? Bo: you can have per stream FEC, such as a.video.hi-res.fec. Or outer level FEC, that covers a set of streams (a.video.fec). Roni Even and Justin remarked about terminology confusion. We need a draft that discusses the different terminology. Justin further remarked that this is useful work, but there is a good chance to express this grouping constraint with MSID. Justin would like to see: Here is SDP and what I put in .. avoid having separate documents. Chair (Keith) commented that MSID is in MMUSIC WG. Jonathan Lennox stated that his understanding is "I make up random stream and hope you understand what I mean, unless I use your implementation". Bo responded this is a separate problem. Jonathan replied that a hierarchy without semantics is not useful. Bo reflected that it has to be signaled in signalling sessions. Jonathan can't see how you determine which one stream one want to display on the screen (out of the set) of random strings. The receiver doesn't know. Magnus Westerlund (as individual) stated that for FEC and similar mechanisms it is self-describing by the RTP payload types. And in the case of simulcast, our draft in Avtcore (draft-westerlund-avtcore-rtp-simulcast-01) defines that. Jonathan responded that he would rather have the semantics described. Kevin Gross commented that there is a need to label the streams. What we need is a single way to label them, not 3 or 4 of them. Harald stated that SRCNAME and MISD have conceptual difference. MSID solves a problem. SRCNAME is a tool. It would be interesting if we could the SRCNAME to solve the MSID problem. But at the moment, I cannot evaluate, because I don't have a purpose. What is the purpose? Magnus commented that simulcast is one the purposes. Justin discussed semantics clash between describing flows and sub components, mixing in SSRC and MSID. It becomes a mix of free-form and fixed- meaning components. Paul Kyzivat commented that you are interested in trees. Names map onto trees. Is there any reason to have hierarchical names? If we have to go to a different source to define meaning, this structure can point us to the source. Names map to semantics elsewhere, but we use this construct to map to the semantic definition. Bo responded it should be possible to relate streams on several layers, for instance between streams and multiple FEC streams, in single and aggregate combinations. Add in simulcast and it drives these use cases. Magnus followed up that SRCNAME have several purposes. We started with simulcast and then got FEC and retransmission. Then we got the feedback regarding the subset and the hierarchical relation of FEC and RTP retransmission. Colin Perkins asked if this group should be defining "the way of conveying semantics from upper level" (like CLUE or RTCWEB) or should this group "define semantics", there is confusion. Roni commented that FEC grouping RFC takes a different approach to avoid the complexities; This was done using a group at SDP level. Bo responded that grouping for FEC used the SDP grouping mechanism, and so does our simulcast proposal. But this draft is not SDP, it's for relaying on RTP level information. Jonathan thinks this does a good job for simulcast, but for others... We may get into trouble doing similar things to SDP in RTP, as they are not doing exactly the same things, details may be fairly different. Magnus commented that he is very interested to solve multiple relationships in a compact form, otherwise this become quite bulky in RTP. Paul stated that we have simulcast, RTCWEB/MSID, CLUE, FEC. We all need to express some relationships between these things. It is silly to build as many mechanisms as there are relationships, but not sure we can get to one solution. Go back to requirements and see if a single one is possible, or not. Jonathan agreed, but it is not just requirements, but need to document the different cases. Chair (Keith) so we need one more document, an overview of the story, across groups, and it depends on the cannel you use to share the relations. A common factor is probably RTP SSRCs, thus maybe avtcore. The actual WG or target for this document will be identified later. Colin commented that the actual mechanisms for conveying things are pretty trivial. The important things are what the labels and their semantics. Thinks we need to come up to the meaning of what we want to convey, the rest will be easy. Chair(Keith) concluded that the interested need to write a doc with the group of key people. An agreement was reached to meet after the AVTEXT session to take the first steps. Support for Multiple Clock Rates in an RTP Session (10 min) Where are we? http://www.ietf.org/id/draft-ietf-avtext-multiple-clock-rates-06.txt Slides presented by Glen Zorn. Glen reported that the draft has been updated according to reviews, with the exception that the table suggested was not added. Somebody needs to say where and how to added it. Marc commented that he does not like to have example in a normative section; so in appendix. Xavier Majrou asked if this draft changes something for DTMF (RFC4733)? DTMF of RFC4733 must always use same timestamps and clock rate than other audio payload when in same RTP session. Colin Perkins responded that DTMF is like other audio format, it changes nothing for this document. Charles Eckel stated that RFC4733 mandates the use of the same SSRC for DTMF and audio. Xavier responded that it's precisely not explicitly written that the clock rates must be the same. Magnus Westerlund commented that RFC4733 was written in the way it was to avoid this multiple clock-rate problem. If text not fully clear, RFC4733 needs to be updated. Chair asked if there are other issues before WGLC? (no other issue raised). The authors will update the draft and if nothing else is brought up, there will be a WGLC. End of Session