AVTCORE IETF 124

Spencer suggested that we schedule an interim before IETF 125, to
make progress. Jonathan suggested a possible date in January.
Spencer requested Jonathan and Gurtej (both had previously
volunteered) to look through the draft now, to help identify new
issues that AVTCORE needs to address. Other reviewers are invited,
of course.
Does RoQ need to be a first class transport?
- But what does it mean to be first class transport?
- Harald: we don't need to update RTCWeb (in the IETF) to use RoQ,
  and we don't need to update the WebRTC specification to use RoQ
  (transport protocol decisions are under RTCWeb control). If we
  do want to allow WebRTC applications to use QUIC feedback, that
  would require W3C API work, but that's a long way down the road.
- Spencer: agrees. We said we needed implementation and deployment
  experience before we can make recommendations about using QUIC
  feedback to supplement or replace RTCP feedback, so that would
  be prerequisite for sharing QUIC feedback using WebRTC API
- Harald and Nils: defining RoQ as ICE candidates appears to be
  the easiest path forward.
- Write text for ICE RoQ candidates and then figure out if it goes
  into the this draft or a new separate draft.

Nils: even with a SDP format you still need mundge SDP
Harald: the existing API for codecs in browsers should be enough to
read the fmtp line
Altanai: what happens if the other side doesn't support this new
extension
- Fallback to regular, non multistream Opus
Jean-Marc: the draft should follow all the families from the Opus
(Ogg?) specifications
Tim: clarify "down-conversion"
- If multiopus is request that should have the highest priority
Jonathan: the draft should clarify which RTP payload format gets
used
will take the feedback and work on that as next step