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

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

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.

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