Minutes IETF103: avtcore
Audio/Video Transport Core Maintenance
||Minutes IETF103: avtcore
AVTCORE Audio/Video Transport Core Maintenance WG Meeting
Date and Time: Tuesday, November 6, 2018 - Morning Session I, 11:20 - 12:20
Chairs: Jonathan Lennox / Rachel Huang
1. Note Well, Note Takers, Agenda Bashing - (Chairs)
Note takers : Roni and Bo
There were a few last-minute agenda changes in adding the RMCAT feedback
Status of working group drafts:
[RFC Editor Queue: MISSREF: Bundle]
The authors should talk and report back to the WG.
Mo: updtaed all feedback on 08 - should include all comments. Ready
for next step. Tl0picidix =0 omit if unknown, clarified open issue on
LRR temporal layer refresh. Jonathan: plase explain on the list since
not clear. It is not clear whether this solves all needed problems to
be useful. Mo: will send to the list.
2. draft-ietf-avtcore-cc-feedback-message-02 - Colin
Jonathan implemented in the Hackathon. sent comments
no space for reoprt count
Jonathan - put it in the last octet Nils Ohlmeier agrees.
Timing - need to specify which clock to use.
Jonathan : requires a stable clock, more stable than the typical Posix wall
clock that is subject to adjustments. Magnus: recommend to use a stable
clock and provide suggestions. Jonathan: is there a need to corralate this
clock withe the RTCP clock? Colin: Not that I know of right now. Colin: what
is the point of having the report timestamp have highre precision than the
arrival time offset> action: no action, leave as is
Colin: What value should be used for arrival timestamp offset for packets
that arrived after report timestamp. need to calrify that they are not
received. Colin: it's not claer what precise semantics "the time instance
when report packet was generated" has. Jonathan: "This is the state of the
world at this time". When the reporting interval is really long, more than 8
seconds, largest time offset doesn't fit and you must create multiple
reports. Colin: We have to do the right thing with all report packets.
Overlapping reoprts: need to clarify this case, for example when there wsa
Reporting on duplicates: Report on last copy, even if creating overlap in
sequence number. Mo: Are any of these decisions imacting the congestion
control algorithms? These numbers are used to estimate the bandwidth. Colin:
We should probably bring this to RMCAT, e.g. handling of duplicates. Mo: For
duplicates, it is probably the earliest one that makes most sense.
signaling: limiting on specific subset of payload type.
Colin: maybe on audio payload no need to reoprt
Nils: This should apply to the entire RTP transport, not only a specific
codec. Jonathan: You should not exclude a number of bits that are actually
sent. Harald: Excluding certain payload types would severely complicate the
congestion control and strongly recommend to report on everything. The
receiver should not have any other option than to report on everything. The
use case we should definitely support is to report on the whole transport.
Nils: It should be rtcp-fb:*, i.e., all payload types. Mo: So all FEC and
retransmission repair formats also have to report? Jonathan: Yes, you want
to have feedback.
3. QUIC multiplexing discussion (Bernard Aboba)
QUIC is potentially atractive as a transpot for peer to peer data tranfer
for webrtc applications.
non requirements : TURN and ZRTP
Mo: Wouldn't the QUIC version field overlap with RTP TS = 0, which is a
valid TS? Bernard: Yes. Mo: The discussion to squeeze the TURN range never
resulted in anything. Jonathan: TURN must be demultiplexed from STUN, but
otherwise you know that this comes from your TURN server. Mo: There may be
several entities that have to demultiplex this and those then need to know
what the TURN server is. It is better to have this unambiguous. I thought
that the TURN range was squezzed down. Jonathan: What is the QUIC wire image
, should we talk with Martin Thompson Bernard: undewrstands that there is no
garantuee. There might also be changes to the TLS content registry that we
might have to account for.
call for action: document quic multiplexing in RFC7983bis. Bernard will do.
Colin may support.
4. RTP and Quic - (Jorg Ott)
no i-d. conference paper document sent to the QUIC mailing list.
5. Next steps and open mic - (Chairs)