* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Avtcore Status Pages

Audio/Video Transport Core Maintenance (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2011-Jan-26 —  
Chairs
 
 


IETF-101 avtcore minutes

Session 2018-03-22 1330-1530: Park Suite - Audio stream - avtcore chatroom

Minutes

minutes-101-avtcore-00 minute



          Audio/Video Transport Core Maintenance (avtcore) Working Group
          
          ======================================================
          CHAIRS:  Jonathan Lennox
                    Rachel Huang
          
          AGENDA
          
          Thursday, 22 March 2018 at 13:30-14:15 (Park Suite)
          -------------------------------------------------
          
          1. Note Well, Note Takers, Agenda Bashing - (Chairs, 13:30, 5 min)
          
          Note takers: Bo Burman, Bernard Aboba
          Jabber: Magnus Westerlund
          
             Status of working group drafts:
          
                draft-ietf-avtcore-multi-media-rtp-session-13
                draft-ietf-avtcore-rtp-multi-stream-optimisation-12
                draft-ietf-avtext-rid-09
                draft-ietf-avtext-lrr-07
                      [RFC Editor Queue: MISSREF: Bundle]
          
                draft-ietf-avtcore-mprtp (expired)
                  Jonathan: Suggest taking it off the milestones
                  Bernard: Don't think that we have an option. Part of the issue
                  is that this is not only multi-path RTP, it is multi-path ICE.
                  Colin: These are presumably separable parts, but you need both.
                  Jonathan: As individual I think it would make sense to take
                  multi-path ICE to either ice or dispatch WG
                  Ben (as AD): IETF is contribution-driven.
                  Bernard: If you don't charter it to be successful, it will not
                  be.
                  Ben (as AD): Would not object to any multi-path contribution.
                  Colin: Think the suggestion is to drop it unless someone brings
                  more work.
                  Jonathan: Will bring this decision to the list. Encourage to do
                  appropriate work.
          
                draft-ietf-avtcore-multiplex-guidelines
                  Colin: That work stalled. Roni decided it was important, but
                  then it stalled again. Not sure there is real value.
                  Roni: Volunteered to do it and will continue with that.
                  Magnus: There was an update before last meeting, but more editing
                  is needed.
          
                draft-ietf-avtext-framemarking-06
                  Mo: There were some comments, mostly editorial. Didn't see a hard
                  need to do something differently or specify in a certain way.
                  Jonathan: I think as receiver you need to know.
                  Mo: We can add some clarification text. For the I bit, do you
                  want to prohibit I bit on layers when base layers have it. The
                  conclusion was that it is per layer. Will add clarifying text
                  why things can be one way or the other. There is also a new IPR
                  declaration with FRAND terms.
                  Ben: Please see to that the IPR disclosure gets to the list.
          
          2. RMCAT Feedback Message Work Status (Colin Perkins, 13:35, 20 min)
          
             draft-ietf-avtcore-cc-feedback-message-01
          
             Colin: Any concerns with using 1/1024 of a second for Arrival Time?
             Jonathan (as individual): Could you get rounding errors, e.g. when
             comparing to send times that could typically be in microsecoonds?
             Colin: Probably, but may not be significant.
             Jonathan (as individual): What if you have reordering on the wire,
             could you derive "later" from RTCP?
             Colin: Tend to think it is not worth it because it would be too late
             for congestion control to work with it.
             Jonathan (as individual): What if something has been off for a long
             time, what to do when it comes back?
             Colin: Suspect that is ambiguous and would have to be clarified.
             Jonathan (as individual): You should send feedback for every source
             that supports congestion control; how do you know?
             Colin: Suspect that there would be parameters in SDP, but that is
             probably all we need. We will need to specify some signaling, but
             the rest would be congestion control algorithms.
             Jonathan: Can anyone volunteer? Harald, Bernard and Magnus volunteers.
             Zahed: We have a github if anyone wants to provide editorials. Can
             send link to the list.
             Jonathan: Bring any technical issues to the list.
             Harald: Hope we can have WGLC before IETF 102.
          
          3. Frame Priority Marking RTP Header Extension  (Roni Even, 13:55,
          15 min)
          
            draft-even-avtcore-priority-markings-01
          
            Roni: Have tested it in WiFi routers and it provides good results for
            non-scalable streams.
            Colin: No objection to opt in the work. The issue has been how you
            do the marking. Have not seen anything in the draft how you consider
            doing that.
            Roni: It marks within a single stream.
            Colin: Don't think that works. Which marking is which priority, if
            you have equipment from different vendors.
            Roni: Marking is done by the encoder.
            Jonathan: What would be the typical ratios of how much is marked and
            how much is not?
            Magnus proxying for Tom Petersen from Jabber: Should the spec consider
            streams that may have FEC or is it out of scope?
            Roni: You can probably use it to mark the FEC stream too.
            Bernard: FEC is typically hop-by-hop, so a middlebox would not forward
            it but re-create it. Probably not so frequently implemented by the
            video people I know.
            Jonathan: Streaming ecosystem is different.
            Mo: This can applied to video, audio or FEC if it is inband FEC.
            Jonathan: Is there interest?
            Mo: Have no objection, but there is coupling between components and
            it could be hard to standardize the understanding needed to set good
            percentages for marking. Not clear to an arbitrary vendor or receiver
            what to mark.
            Jonathan: If a receiver could specify the expected marking ratios,
            would that help?
            Mo: If there is no coupling between sender and receiver, don't see
            how it could work.
          
          4. Next steps and open mic - (Chairs, 14:10, 5 min)
          
          No topics.
          
          



Generated from PyHt script /wg/avtcore/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -