- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 17 Jul 2025 10:46:13 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of our July 15 meeting are available at:
https://www.w3.org/2025/07/15-webrtc-minutes.html
I took the opportunity to also complete and publish our June 17 meeting
minutes:
https://www.w3.org/2025/06/17-webrtc-minutes.html
Dom
-----
WebRTC June 2025 meeting
17 June 2025
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/Jun_17_2025
[3] https://www.w3.org/2025/06/17-webrtc-irc
Attendees
Present
Carine, Dom, Elad, Guido, Harald, Jan-Ivar,
KacperWasniowski, PeterThatcher, RichardBarnes, TimP,
Youenn
Regrets
-
Chair
Guido, Jan-Ivar, Youenn
Scribe
dom
Contents
1. [4]Screen capture
1. [5]getDisplayMedia: Distinct “Error” for Cancellation
2. [6]Expose capturer/capturee overlap
2. [7]WebRTC: How to find the remote fingerprint?
3. [8]WebRTC Encoded Transform
1. [9]SFrameTransform mode per-packet vs per-frame
2. [10]SFrame cipher suite #256
3. [11]SFrame RTCEncodedVideoFrame on receiver side
4. [12]Summary of resolutions
Meeting minutes
Recording: [13]https://www.youtube.com/watch?v=T66E24lWLoA
[13] https://www.youtube.com/watch?v=T66E24lWLoA
IFRAME:
[14]https://www.youtube.com/embed/T66E24lWLoA?enablejsapi=1&rel
=0&modestbranding=1
[14]
https://www.youtube.com/embed/T66E24lWLoA?enablejsapi=1&rel=0&modestbranding=1
Slideset: [15]https://docs.google.com/presentation/d/
19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/
edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0
([16]archived PDF copy)
[15]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0
Screen capture [17]🎞︎
[17] https://www.youtube.com/watch?v=T66E24lWLoA#t=136
[18]getDisplayMedia: Distinct “Error” for Cancellation [19]🎞︎
[18] https://github.com/w3c/mediacapture-screen-share/issues/321
[19] https://www.youtube.com/watch?v=T66E24lWLoA#t=136
[20][Slide 10]
[20]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#10
[21][Slide 11]
[21]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#11
[22][Slide 12]
[22]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#12
[23][Slide 13]
[23]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#13
[24][Slide 14]
[24]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#14
[25][Slide 15]
[25]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#15
Jan-Ivar: this seems like a valid use case to solve, if all
browsers implement transient activations
… Firefox already returns a "NotFoundError" when hitting an OS
limitation
… in an iframe with a policy limitation, it does return
NotAllowedError which might indeed be improved
… [NB a mistake with the constraint attribute on slide 14]
… -1 on relying on prototype, would be preferable to have an
additional attribute (e.g. boolean "userInitiated")
Youenn: could we use the Permission API to determine this
already?
… it tells you if the user persistently denied access - which
would be the same situation if denied by iframe policy
… I'm not sure if they need to be distinguished
… I think NotFoundError + persistent denied should be
sufficient
Elad: the permission API can't be used for this: it's
asynchronous, and it requires asking all the time
Youenn: if the user has put a setting to always deny
getDisplayMedia, it will not be "ask" again, it will be
systematically "deny"
Elad: I don't think this is possible in any browser at the
moment, not even sure it should be exposed
… but that's an edge case compared to the majority of cases
… the asynchronous nature of the permission API doesn't allow
to tie a rejection to a specific call of getDisplayMedia
Youenn: the same issue exists with getUserMedia - what is
specific to getDisplayMedia here?
Elad: getDisplayMedia() will always involve a new prompt - each
call has its own state
… getUserMedia can persist in a given session or even across
sessions
… likewise, usually a choice on denying camera is unlikely to
be changed, whereas canceling a screen share can reflect a
temporary decision
Youenn: not seeing a big difference between the two
Harald: you listed 3 sources of failures - that point towards a
string rather than a boolean (e.g. "user-denied",
"internal-failure", "os-disallowed")
Elad: I tried this with mute reason before, but this wasn't too
well received, hence I'm focusing on the narrowest need
Jan-Ivar: +1 to solving the use case; no strong opinion on the
approach, but Youenn's point made sense to consider
Elad: the spec doesn't give any suggestion for persistent
denial at the moment
Jan-Ivar: the Permission API allows to add a track handler
which could probably solve this
Guido: the normal behavior is "always ask" - right after "deny"
it becomes "ask" again
Jan-Ivar: it would have to be set to ask for all situations
that aren't user initiated
Elad: that would still it a lot more complex than integrating
it in the error message
Jan-Ivar: but there is value in not shipping new API surface
TimP: not convinced that synchronous handling is needed in the
examples you gave (stats, prompt strategy)
Elad: one example: getDisplayMedia called from a button -
should that button stay disabled while checking the permission
state?
TimP: doesn't feel like a hard requirement
… I think the simplicity argument is more compelling
Harald: I don't how Youenn's suggestion would work
Youenn: let's explore on github what use cases can or cannot be
addressed with the two approaches
… we need to see which situations would be distinguishable
based on permission/error type
Guido: synchronicity is needed for correctness checking
RESOLUTION: continue discussion on github issue
Expose capturer/capturee overlap [26]🎞︎
[26] https://www.youtube.com/watch?v=T66E24lWLoA#t=1679
[27][Slide 18]
[27]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#18
[28][Slide 19]
[28]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#19
[29][Slide 20]
[29]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#20
[30][Slide 21]
[30]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#21
[31][Slide 22]
[31]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#22
[32][Slide 23]
[32]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#23
[33][Slide 24]
[33]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#24
[34][Slide 25]
[34]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#25
Youenn: in the example with the PiP, the Web app would like to
know the current situation and what would happen with PiP
… PiP might trigger an overlap of its own
Elad: I'll cover this when describing proposal [35]#2
… but note that PiP is only one of the situations you want to
manage
… the first question would be whether PiP has any chance to be
useful - which it can't be if there is no overlap at all
[35] https://github.com/w3c/mediacapture-screen-share/issues/2
[36][Slide 26]
[36]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#26
[37][Slide 27]
[37]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#27
[38][Slide 28]
[38]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#28
Jan-Ivar: leaving aside our current open position on document
PiP
… this feels like a good use case
… re proposal 1, could we expose only the percentages instead
of the values needed to calculate them?
Elad: the absolute values can be recovered from the percentages
Jan-Ivar: but conversely requires exposing fewer attributes
Elad: I can live with either approaches
Jan-Ivar: re initial vs dynamic (slide 28), making it dynamic
could lead to the browser fighting with the user
Elad: this would be a readonly value
Jan-Ivar: but there could be a fight via PiP
Elad: there is no such mechanism at the moment for the Web app
to control the position of the PiP, and if there was, the
problem would exist independently of exposing that dynamic data
Jan-Ivar: I think starting with starting with at "opening" time
would be safer
Elad: the only use case I can imagine is if the web app wants
to offer a better layout based on determining dynamic values
changing, but it's arguably hypothetical
… some activity is already observable through the change of the
captured window sizes
Jan-Ivar: let's focus on open for now, and discuss if/when to
update the values
… I'd support initialPercentage
TimP: I don't see anything problematic in terms of privacy
Youenn: percentage seems fine; I'm wondering whether a hint to
the UA would be sufficient
… Could you file an issue which would illustrate how the
percentage would be used? sometimes what is overlapping is
important
… my primary concern is about managing focus rather than
dealing with PiP
… understanding the PiP use cases better would be important
Jan-Ivar: let's distinguish PiP as a remedy vs PiP as a source
of overlap
Elad: the MVP for me is not to trigger PiP when disruptive,
trigger it when it's clear it would help, and let web app
developers explore the in between
RESOLUTION: agreement on the validity of use case, continue
discussion on to-be-created github issue
WebRTC: How to find the remote fingerprint? [39]🎞︎
[39] https://www.youtube.com/watch?v=T66E24lWLoA#t=3090
[40][Slide 31]
[40]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#31
[41][Slide 32]
[41]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#32
[Elad departs]
[42][Slide 33]
[42]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#33
[43][Slide 34]
[43]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#34
[44][Slide 35]
[44]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#35
[45][Slide 36]
[45]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#36
Peter: re slide 32 - does getRemoteCertificates() return an RTP
certificate?
TimP: it returns a blob
Peter: it could be fixed to return something on which we could
call getFingerprint(); re c), what's your worry about "being
too late"?
TimP: receiving unexpecting RTP, earlier than expected; I'm
keen to not have a connection up if it's not expected, before
any packet exchange. The DLTS handshake is already finished by
the time of getRemoteCertificates()
Peter: there are alternatives (although not great): you could
set up a send-only RTP transceiver, and switch it sendrcv after
the certificate is verified
TimP: you'd still be talking to someone that is likely hostile
- letting this filtered by the upper layer feels weaker
Peter: but the existing API already allows to achieve this?
TimP: I think you can't; this would protect you against a
malicious SCTP ack
Peter: you could wait to negotiate until you've verified the
fingerprint
TimP: I'm trying to make a proper API; getFingerprint() was
defined for IdP which never happened, I'm trying to make better
use of it.
Peter: re slide 36, I like b), but it can only be done if it's
fully bundled - which applies to other options
Harald: I think this is at the wrong level - fingerprints are a
transport attribute, not a connection attribute. I also don't
understand the API here - the fingerprint is what the other end
tells you to verify they are who they say, it shouldn't be set
by you
TimP: the problem we're trying to solve is persistence: imagine
two devices have established trust and stored each other
fingerprints in a trusted context, and want to re-use that
trust relationship when exchanging SDP, à la QUIC zero, even in
a case of a less trusted signaling mechanism
Youenn: is there a github issue to continue this discussion?
TimP: will file one.
Peter: d) would be sufficient to check the remote certificate
is known (without having to manually parse the SDP)
[46]WebRTC Encoded Transform [47]🎞︎
[46] https://github.com/w3c/webrtc-encoded-transform/
[47] https://www.youtube.com/watch?v=T66E24lWLoA#t=3349
SFrameTransform mode per-packet vs per-frame [48]🎞︎
[48] https://www.youtube.com/watch?v=T66E24lWLoA#t=3349
[49][Slide 39]
[49]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#39
[50][Slide 40]
[50]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#40
[51][Slide 41]
[51]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#41
[52][Slide 42]
[52]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#42
Jan-Ivar: why would it be difficult to support per-packet with
ScriptTransform?
Youenn: ScriptTransform generates frame, would make it
difficult to deal with packets. ScriptTransform could not deal
with decryption
Jan-Ivar: ScriptTransform could still be used to deal with
frame manipulation on top of SFrameTransform
Youenn: right, that's not the use case I'm discussing as out of
scope
[53][Slide 43]
[53]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#43
[54][Slide 44]
[54]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#44
Youenn: there could be an option C, per transceiver
Jan-Ivar: the global option feels a bit artificially limiting;
which mode you pick might depend on which SFU you talk to
Harald: if you want to switch from SFrame to JS or the other
way around, you need to add new media lines - that argues
against using RTCCnfiguration, it should be a transceiver
parameter.
Youenn: will there be two m-line section, one using per-packet
and another using per-frame? didn't seem very compelling
Harald: the use case I was thinking of is one using SFrame and
the other not using it at all
Youenn: that's controlled by setting the transform on a
transceiver basis; this is about setting the sframe flavor
Jan-Ivar: it does seem more like a per-transceiver thing; re
slide 42, why an interface for the options?
Youenn: this allows the UA to check whether it's a
scripttransformoptions and thus switch to a difference
processing flow, allowing to have the type as a second
parameter to the constructor
Jan-Ivar: not sure I like that - we can bikeshed that; the
problem is the ambiguity between options and message to the
worker - we had that issue with setting codecs as well. There
are alternatives we could discuss in the PR.
Youenn: the PR uses a 4th option object as a dictionary
Jan-Ivar: that would be preferable from my perspective; let's
discuss in the PR
Youenn: per-transceiver seems fine
Jan-Ivar: Per transform might be better
Youenn: that'll depend on how SDP negotiation happens; last I
heard there would be an sframe a-line per-packet or per-frame
to the m-section. In that case, both ends needs to abide to it.
If this is only "use sframe", senders and receivers could do
different things
Jan-Ivar: why not Transceiver.sframeTransform = true?
Youenn: that's equivalent to option A… Sounds like more
discussion needed, and not clear Option B is getting much
support. This will depend on the SDP negotiation for SFrame on
which I expect progress this month
[55][Slide 45]
[55]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#45
SFrame cipher suite [56]#256 [57]🎞︎
[56] https://github.com/w3c/webrtc-encoded-transform/issues/256
[57] https://www.youtube.com/watch?v=T66E24lWLoA#t=3349
[58][Slide 46]
[58]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#46
Jan-Ivar: LGTM
Harald: nothing to add beyond my comments on the PR
RESOLUTION: move forward with proposal
SFrame RTCEncodedVideoFrame on receiver side [59]🎞︎
[59] https://www.youtube.com/watch?v=T66E24lWLoA#t=3349
[60][Slide 47]
[60]
https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0#47
Youenn: it's for the case where decryption is done via
scripttransform
Peter: if you decrypt yourself, you could look at the payload
format yourself
Youenn: the scripttransform on the receiver side exposes and
rtcencodedvideoframe whose content is encrypted - what should
the type attribute indicates?
Peter: if your job is to decrypt, it's not your job to set
this; this sounds like 2 different stages
Youenn: it's require to expose a value here - it could be
empty, or another value
Peter: saying "unknown" would be better
Youenn: except if that's provided by an RTC Header extension
Peter: likewise for spatialIndex/temporalIndex
Youenn: those are optional; they would only be exposed if the
RTP header extension is present; the spec doesn't say how
they're set in any case at the moment
Jan-Ivar: If I'm using SFrame and ScriptTransform, on the
receiverside, do I get an encrypted or a decrypted frame?
Youenn: the former - it's up to you to decrypt it
Jan-Ivar: that's the old model we have today; why not have the
browser deal with the decryption?
Youenn: you could do that
Jan-Ivar: that'd seem cleaner; you could imagine specifying
separately JS transform and sframe transform since they're
orthogonal
Youenn: When doing SFrame at the frame level and are already
using ScriptTransform, being able to do decryption it as part
of ScriptTransform feels simpler; for instance, you could apply
different algorithms on the Sframe configuration itself based
on inspection of the frame - this couldn't be done with
separate transforms. Separating the two processing can already
be done with the current API.
Jan-Ivar: worth clarifying the use cases on github
TimP: re frame type, it should be "encrypted" or "sframe"
Youenn: is there an RTCEncodedAudioFrame.type? We would also
want the audio frame to know it is encrypted, so maybe this
needs to be a different attribute to signal encryption that
would apply both audio and video frames
Jan-Ivar: what is the use case for ScriptTransforming an
encrypted frame?
Youenn: that's the current way of doing things; ideally, for
ease of migration, we should allow apps to continue using
ScriptTransform using native decryption, via the
SFrameTransform stream writable/readable.
--------
WebRTC July 2025 meeting
15 July 2025
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/Jul_15_2025
[3] https://www.w3.org/2025/07/15-webrtc-irc
Attendees
Present
caribou, Carine, Dom, Guido, Harald, Jan-Ivar,
JasperHugo, PatrickRockhill, PeterT, PhilipEliasson,
SunShin, TimP, Varun
Regrets
Cullen, Elad, Youenn
Chair
Guido, Jan-Ivar
Scribe
dom
Contents
1. [4]Header Extension Control to WebRTC MainSpec
2. [5]RtpTransport
3. [6]DataChannel transfer issues
1. [7]Issue #3063: Data channels in workers get
initialized on wrong thread
2. [8]Issue #3062: Prevent GC of non-closed
RTCDataChannels in workers
3. [9]Issue #3058: Avoid losing data channel events
during transfer
4. [10]WebRTC API
1. [11]Issue #3052: RTCPeerConnectionIceErrorEvent should
not expose STUN reason phrase to JS
2. [12]Issue #3064: RTCError constructor fails the copy
constructor pattern
5. [13]Can we delete webrtc-provisional-stats spec?
6. [14]Summary of resolutions
Meeting minutes
Slideset: [15]https://docs.google.com/presentation/d/
1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/ and [16]archived
PDF copy
[15]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/
[17]Header Extension Control to WebRTC MainSpec
[17] https://github.com/w3c/webrtc-pc/issues/3060
[18][Slide 10]
[18]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#10
[19][Slide 11]
[19]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#11
Jan-Ivar: I don't see any big problem with that; still some
concern about dictionary vs interfaces, but these improvements
can be made in the main spec
… so no objection from me
RESOLUTION: move forward with pull request for [20]#3060
[20] https://github.com/w3c/webrtc-pc/issues/3060
Jan-Ivar: will this help wrt codecs/negotiation?
Harald: some of the same things apply, but this won't help in
the short term
[21]RtpTransport
[21] https://github.com/w3c/webrtc-rtptransport
[22][Slide 14]
[22]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#14
[23][Slide 15]
[23]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#15
[24][Slide 16]
[24]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#16
Peter: SimpleRtpTransport is a working name for this proposal,
can be bikeshed later
[25][Slide 17]
[25]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#17
[26][Slide 18]
[26]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#18
[27][Slide 19]
[27]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#19
[28][Slide 20]
[28]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#20
[29][Slide 21]
[29]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#21
PeterT: it's a peer-to-peer bandwidh-controlled congestion
controlled packet API
[30][Slide 22]
[30]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#22
[31][Slide 23]
[31]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#23
Jan-Ivar: re slide 19, doesn't WebTransport solve this with its
echo server? what's missing?
Peter: P2P, real-time, customized congestion control
Jan-Ivar: a lower level API than WebTransport is not something
I would be excited about
Peter: it doesn't have to be lower level, but allow for custom
bandwidth estimate, P2P and real-time
Jan-Ivar: how about negotating WebTransport over SDP?
… WebTransport has some congestion control, and I/O is solved
with Streams
… having yet another API for P2P feels suboptimal
… and instead catalyze on what we've already solved
… re which WG - there have been efforts on QUIC over WebRTC
which may be worth discussing how to revive them
TimP: stepping back a bit: there are real use cases that can't
be done with WebRTC or WebTransport
… e.g. data out of a LIDAR on a near network that you don't
want to go through a server, not possible in real time
… Peter's requirements are right in that regard
… there is no appetite on implementing the closely related
WebRTC API that would satisfy this
… layering WebTransport and WebRTC together with a bit of QUIC,
I don't see who would implement this
… maybe that's the fundamental question that needs answering
Peter: I understand interest from Google to implement something
like SimpleRtpTransport
Philip: that's correct
Jan-Ivar: I don't think we would be implementing something like
that: it feels too low level, and it's not clear how you would
solve the hard problems
… Quic gives some congestion control and flow control
Peter: my main question is not on specific API shape and
network protocols, but rather move away from piecemeal, and if
so where
Jan-Ivar: we would have to dive into which technical problems
need solving - e.g. WebTransport not being P2P
… send/receive packets methods in JS doesn't feel realistic -
WebTransport solved some of that with streams
… it would be easier with more implementation experience on
WebTransport, but it still feels like the most promising option
… we would be more likely to implement WebTransport over SDP -
QUIC seems quite compatible with ICE
… Web developers who don't need P2P can already make do with
WebTransport and get reasonable real-time preference; they
shouldn't have to use a different API to get P2P
TimP: +1 to pursuing an API in that space; not an expert on the
right place for the work
… although if it starts from ICE, this WG feels reasonable
… otherwise, if it doesn't tie to existing objects, not obvious
it would need to be here
Philip: the proposed work could fit in other groups, but the
motivating factor behind this API feels like a good fit for
this group
… it's RTC focused, with its low latency congestion control
Jan-Ivar: QUIC over ICE would need IETF involvement, on which
we could add an API
… WebTransport is getting close to wide review on level 1.0
… I could discuss with my co-chair over feasability of P2P
connection
Peter: QUIC over ICE isn't complicated - I've written a draft
to describe it
… P2P QUIC could be done without ICE (but ICE-like)
… (distinguishing the ICE packet format vs the ICE approach -
the latter can be done with QUIC packets)
… QuicTransport was just that
… it would still need solving real-time
Jan-Ivar: why would we solve real-time congestion only for P2P?
Peter: this would also solve it for client-server
… I haven't seen an implementation of QUIC with real-time
congestion control on par with what we get with PeerConnection
today
Philip: true real-time communication is different from just
data flows
… doing real-time congestion control is quite different, it
could complicate things quite a bit
Jan-Ivar: part of the question is how much browsers should be
involved in congestion control vs apps
… we would prefer reusing existing approaches as much as
possible
Peter: so if we're making WebTransport real-time and P2P, which
group should it happen in?
Jan-Ivar: either would be fine from my perspective
… it would be good to have an IETF spec to lean on
… a simpler API could also be done by polyfilling on top of SDP
… e.g. what is missing from datachannels?
Peter: there are some downsides to re-using the datachannel API
Jan-Ivar: I was thinking instead of getting WebTransport
streams out of the negotiation
Peter: that's roughly what QuicTransport was
… you don't need SDP for this, but you could build it on top of
SDP
Jan-Ivar: getting rid of SDP would be a large task by itself
Peter: only if you try to build on top of peerconnection
… building an ICE Transport doesn't need to lean on SDP
Jan-Ivar: creating a third API isn't great for developers
Peter: hence the proposal of providing a sample app
Philip: the advantage of a low-level API is that it makes
implementation much simpler, and is also simple to explain
Jan-Ivar: I'm skeptical it's actual simple - it took a very
long time to get where we are today, and it took getting a lot
of details right
TimP: we shouldn't regard developers moving away from
PeerConnection API as a bad thing
… it's not a simple API to learn, and it's not going to get
simpler
… it would be easy to find people interested to use such a new
API - we got a lot of interest
… we definitely would use it - datachannels over SCTP just
doens't work for our use case
… I suspect QUIC might have related problems, but I haven't
tried that yet
… it does feel like if we build it, they will come
Philip: re simple, I agree it's definitely not trivial to
introduce a new transport
… but this API is about removing 98% of PeerConnection
… the main thing that needs solving is the app-level bandwidth
estimation to prevent abuse
Jan-Ivar: I would be supportive to look QUIC over ICE and solve
individual issues
… would be interesting to learn more about implementation
challenges
Harald: congestion-control and encrypted transport needs key
negotiation and feedback format on congestion
… they're not trivial problems; I'm hesitant to give an answer
without a clearer sense of how they would be solved
… IETF has banned "simple" in protocols based on their
experience
Peter: re feedback, if we went with QUIC, we would need the
receivetimestamp extension
… if we want with RTP, we would go with RFC @@@
… re keys negotiation, QUIC partially solves it
Philip: I think there are solutions; feedback format are
technically possible
Peter: but there aren't solutions already out there
Jan-Ivar: solving real-time congestion is inteesting for
WebTransport in general, outside of P2P
… this could be done a separate deliverable to WebTransport 1.0
Peter: solving QUIC to make it real-time would be great
… likewise for P2P
… and I agree they're orthogonal
RESOLUTION: Jan-Ivar to discuss with WebTransport co-chair on
interest; Peter to share details on QUIC over ICE
[32]Peter's expired ICE+QUIC IETF draft:
[32] https://www.ietf.org/archive/id/draft-thatcher-p2p-quic-00.html
[33]DataChannel transfer issues
[33] https://github.com/w3c/webrtc-pc/
Issue [34]#3063: Data channels in workers get initialized on wrong
thread
[34] https://github.com/w3c/webrtc-pc/issues/3063
[35][Slide 27]
[35]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#27
TimP: is that the only property that is mishandled or does that
apply to labels as well?
Jan-Ivar: only id afaict
Guido: Chrome is implementing the spec; before we agree to
change the spec, I would like to take a look at why Chrome is
doing that way, and if changing it would cause any problem -
let continue the discussion
Jan-Ivar: part of the issue is that when SCTP connects, it
queues a task on the main thread and does a lot of
initialization on that thread, which could be an issue with
worker threads
… there is a separate task to announce the channel as open - we
could move id initialization there, but that could be a
breaking change
… an alternative would to change how initialization is done
specifically in workers channel, where id initialization would
come alter
RESOLUTION: continue discussion in issue based on
implementation analysis
Issue [36]#3062: Prevent GC of non-closed RTCDataChannels in workers
[36] https://github.com/w3c/webrtc-pc/issues/3062
[37][Slide 28]
[37]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#28
RESOLUTION: move forward with proposal
Issue [38]#3058: Avoid losing data channel events during transfer
[38] https://github.com/w3c/webrtc-pc/issues/3058
[39][Slide 29]
[39]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#29
Jan-Ivar: more of a heads up for implementors; the spec seems
already correct
RESOLUTION: the issue can be closed since no spec change is
needed
[40]WebRTC API
[40] https://github.com/w3c/webrtc-pc/
Issue [41]#3052: RTCPeerConnectionIceErrorEvent should not expose
STUN reason phrase to JS
[41] https://github.com/w3c/webrtc-pc/issues/3052
[42][Slide 34]
[42]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#34
Harald: I think we should keep errorText, but that it doesn't
need to reflect the error message from the STUN attribute; it
should help with debugging
RESOLUTION: keep errorText but call out risk with STUN reason
Issue [43]#3064: RTCError constructor fails the copy constructor
pattern
[43] https://github.com/w3c/webrtc-pc/issues/3064
[44][Slide 35]
[44]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#35
RESOLUTION: move forward with proposal
[45]Can we delete webrtc-provisional-stats spec?
[45] https://github.com/w3c/webrtc-stats/issues/800
[46][Slide 36]
[46]
https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/#36
Jan-Ivar: I'm supportive of Henrik's proposal
Harald: do we have a list of what's implemented and not in
provisional stats?
Jan-Ivar: not that I know of; I know Firefox hasn't implemented
any of those
Harald: part of the motivation was to allow webrtc-stats move
to PR
Dom: right - we need to look again at what's implemented to
move forward with webrtc-stats
… we could re-import things that have only one implementation
as feature at risk for later integration through amendments
… my recollection was that stats was also used as a collection
of "good ideas" - not sure if that's useful
Varun: +1 on the value of documenting them
… to avoid reinventing the wheel all the time
Dom: this could be done as markdown files under a subfolder in
webrtc-stats
Jan-Ivar: we recently added a stat for PSNR; it took a long
time, but making it through the traditional standardization
process rather than hiding them in provisionign is valuable
Varun: provisional stats has lots of stats that have been
implemented in the stack, but not exposed via getStats() atm
Harald: I would object to the goal on deleting that document
without a clearer process to documenting, evaluating stats over
time
… given that barrier to adding stats to the main document
… I expect triage will end up with a random set moved to main,
with information loss in the process
Varun: moving to markdown with the same information doesn't
feel like progress
… the doc is already marked as unofficial, and makes it easier
to move stats from one doc to another
… it all comes down to process; we should clarify our
expectations for proposing new stats
Guido: we should bring this back when Henrik is around
Harald: FYI: the document hasn't been updated in 2 years, or
looking at issues
RESOLUTION: bring this back when Henrik is available
Received on Thursday, 17 July 2025 08:46:15 UTC