1. Next steps in Real Time Communications
W3C TPAC
Next steps in Real Time Communications

2. QUIC Potential benefits What work is ongoing in IETF to support this?
Improvements in signaling (e.g. reduction in loss rates, delay reduction)
Reduction in data channel setup time (e.g. due to removal of SCTP connection setup)
Potential throughput improvements (e.g. for a file transfer over the data channel) due to transport improvements
What work is ongoing in IETF to support this?
QUIC BOF: largely focused on HTTP over QUIC
What W3C API support do we already have?
XMLHttpRequest: Support for QUIC can be determined based on HTTP response, so servers can “opt in” to QUIC without an API change.
What if an application knows that the server supports QUIC? Is there a way to send an HTTP over QUIC request?
What additional work could be done in W3C?
Support for RTCQuicTransport
Similar to RTCDtlsTransport
RTCDataChannel using RTCQuicTransport
Could reduce data channel setup time
RtpSender/Receiver utilizing RTCQuicTransport
Assume this involves QUIC-based key management of SRTP rather than RTP over QUIC
Major advantage is convenience (e.g. a single QUIC transport versus QUIC and Dtls transports)
Initial assessment: requires substantial work items in both IETF and W3C

3. Mobility Potential benefits
Reduction in time to ICE “connected” state
Seamless switching between interfaces (e.g. WLAN -> cellular) and back.
What work is ongoing in IETF to support this?
TRAM WG: TURN mobility
ICE WG: RFC 5245bis, Trickle ICE, Dual Stack Fairness, passive aggressive nomination, proposals that are not yet WG work items (e.g. network cost, renomination, candidate removal)
What W3C API support do we already have?
Existing ICE APIs already enable a wide range of functionality: RFC 5245bis, Trickle ICE, Dual Stack Fairness, Oauth, TURN mobility, etc.
What additional work could be done in W3C?
Tweaks to support potential new work in ICE WG (e.g. candidate removal, network cost)
Tweaks to support additional functionality (e.g. extended gather policies to reduce candidates)
Initial assessment: most work in IETF, API tweaks in W3C.

4. Scalable Video Encoding
Potential benefits
More robust video
Ability to adjust video framerate and resolution to device characteristics
What work is ongoing in IETF?
PAYLOAD WG: definition of RTP payload support for codecs supporting temporal and spatial scalability (e.g. H.264/SVC, VP8, VP9, etc.)
AVTEXT WG: Layer Refresh Request (LRR) feedback message (to support spatial scalability)
NETVC WG: next generation codec
What W3C API support do we already have?
Decoders (e.g. VP8, VP9) that can decode anything an encoder can send can already decode scalable video streams without additional WebRTC API support
ORTC also supports encoding of SVC (but probably requires too much developer expertise)
What additional work could be done in W3C?
Simple support for SVC encoding (e.g. “enable temporal and spatial scalability” or “enable only temporal scalability” or “no SVC encoding”).
Initial assessment: most work in other SDOs, API tweaks in W3C