Last IETF meeting in Prague was a really unusual one for WebRTC. Right off the bat, both the RTCWEB group meeting and the MMUSIC group meeting were cancelled. Additionally, many of the ‘usual suspects’ were absent, particularly from Google. In short, it was a fairly quiet week for WebRTC.
Before I list the few items of interest, it’s worth explaining why the week was so quiet. The meeting cancellations and individual absences were definitely correlated, although which one caused the other is not so clear. There are disagreements about just how much work is left to do on the core WebRTC 1.0 related specs, but there is general agreement that mainly what needs to happen now is work on the specs rather than discussions of new topics. Unfortunately, some of the security topics appear to need more work from authors who are busy dealing with some significant challenges in the new-ish TLS 1.3 drafts.
Closing the specs will bring more stability and allow to work on the next things for WebRTC.
Final steps to close the specs
Video Delivery in Hybrid Network
a BoF session proposing a new group to figure out what standards or standards modifications might be needed to support the virtual network constructs in 5G wireless. This is interesting because of its potential implications for control over network quality for mobile devices. See the agenda and slides.
The group trying to figure out how to encrypt media end-to-end in the face of intermediates such as SFUs, may have had a breakthrough. When doing double encryption a la https://datatracker.ietf.org/doc/draft-ietf-perc-double , one of the questions was about how to deal with repair packets (such as FlexFEC, RTX, or RED). The key issue has been whether the media distributor, such as an SFU, can also do repair, and not just the endpoint. The dispute has been around how to do this. Cullen’s slides give the background and proposal, but briefly the proposal is to move the OHB into the payload before the second encryption. This allows hop-by-hop processors to access it and do repair. This was the consensus in the room, to be verified on the list. By the way, Cullen’s final slide proposing that the bitfield value for the new combined payload be added to the DTLS EKT message was NOT adopted. Rather, room agreement was that the Double draft will now define protection profiles to represent all of the bitfield possibilities.
There was a discussion of interest to WebRTC with respect to what priority information should be included with the Frame Marking RTP Header Extension (see slides). There is now a “discard” priority field that is used to indicate which temporal or spatial layers to discard. There was an inordinately long discussion on how much information should be provided to help the SFU make a priority decision, with most commenters believing this to be a slippery slope since different SFUs and/or endpoints may prioritize in different ways. There was *not* support for a priority bit at this time.