14:55:49 <RRSAgent> RRSAgent has joined #webrtc
14:55:53 <RRSAgent> logging to https://www.w3.org/2024/03/26-webrtc-irc
14:55:53 <Zakim> Zakim has joined #webrtc
14:56:58 <dom> Meeting: WebRTC March 26 2024 meeting
14:56:58 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/March_26_2024
14:56:58 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2024Mar/att-0005/WEBRTCWG-2024-03-26.pdf
14:56:58 <dom> Chairs: HTA, Jan-Ivar, Bernard
14:59:30 <dom> Present+ Jan-Ivar, SunShin, Dom
15:00:25 <dom> Present+ Youenn
15:00:33 <dom> Present+ Bernard
15:01:18 <dom> Present+ PhilipEliasson
15:02:10 <dom> Present+ PeterThatcher
15:02:14 <dom> Present+ ShridharMajali
15:02:23 <dom> Present+ TonyHerre
15:02:25 <dom> Present+ Carine
15:02:50 <dom> Present+ Florent
15:03:13 <dom> Recording is starting
15:03:34 <dom> Present+ Elad
15:04:15 <dom> s/Recording is starting//
15:04:53 <dom> Present+ Guido
15:05:34 <dom> Recording is starting
15:05:53 <dom> Regrets+ Harald
15:05:59 <dom> s/HTA, //
15:07:46 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/2944 Alternative storage for RTCCertificates neededWebRTC API
15:07:46 <dom> [slide 11]
15:08:18 <dom> [slide 12]
15:08:54 <dom> [slide 13]
15:09:22 <dom> [slide 14]
15:10:04 <dom> [slide 15]
15:11:26 <dom> Youenn: a possible way would be to extract information to store it on the cloud that the Web page can access it on reload; but that's not helping when you're not connected
15:11:49 <dom> ... I would prefer not to expose key materials to JavaScript; it's not clear this would help with this use case anyway
15:12:26 <dom> ... in terms of privacy, if you're allowed to keep it for a longer lifetime, it harms privacy
15:13:12 <dom> Jan-Ivar: +1 to NOT exposing key materials to JS - this shouldn't be a conclusion from the E2E
15:14:18 <dom> Dom: seems hard to reconcile persistent storage with privacy protection
15:14:29 <dom> Youenn: Chrome has a persistent storage API that may help
15:14:56 <dom> ... but it's not implemented in Safari
15:16:14 <dom> -> https://storage.spec.whatwg.org/#dom-storagemanager-persist StorageManager.persist() API
15:16:30 <dom> Dom: +1 on exploring this rather than try to design a new solution in this space from scratch
15:16:42 <dom> Topic: -> https://github.com/w3c/mediacapture-extensions/issues/118 Should web applications be aware of reaction effects added by OS to camera feeds? #118
15:16:42 <dom> [slide 18]
15:17:29 <dom> Youenn: some OS allow users to insert reactions based on user gestures into captured videos
15:17:59 <dom> ... this isn't in control of the app or the browser
15:18:18 <dom> [slide 19]
15:19:49 <dom> [slide 20]
15:20:00 <dom> Present+ TovePetersson
15:21:35 <dom> Youenn: Jan-Ivar made a proposal in PR #141
15:22:25 <dom> Elad: great solution for what is a significant problem
15:22:45 <dom> ... looking forward to having it
15:23:06 <dom> Youenn: there is an API in current MacOS that allows to say whether reactions are one or off
15:23:27 <dom> ... it's not currently possible to disable/enable reactions at this point, but this is under consideration
15:24:15 <dom> Elad: enabling/disabling is what we're most looking forward to
15:25:14 <dom> Youenn: the user is in control of enabling/disabling, so apps could still guide the user toward that as a first step
15:25:36 <dom> ... this proposal is compatible with both level of flexibility
15:26:23 <dom> Elad: practically speaking, I'm skeptical teleconferencing apps would try and guide users, so really hoping we get to the 2nd level
15:26:35 <dom> Jan-Ivar: I'm supportive too; very similar to background blur
15:27:00 <dom> ... adding this API removes an obstacle towards making it available with possible read/write capabilities in the future
15:27:54 <dom> RESOLVED: Proceed with proposal based PR #141, with name bikeshedding left to editors
15:28:24 <dom> Topic: Media Capture Specifications
15:28:24 <dom> Subtopic: -> https://github.com/w3c/mediacapture-main/issues/984 Clarify each source is responsible for specifying mute/unmute/ended and constraints behavior
15:28:24 <dom> [slide 24]
15:29:28 <dom> Jan-Ivar: we agreed on a resolution to #984 at our last meeting - that requires some spec clean up in places where mediastreamtrack sources get defined
15:30:04 <dom> Jan-Ivar: I opened a batch of issues to match:
15:30:05 <dom> -> https://github.com/w3c/mediacapture-screen-share/issues/298 Review mute/unmute/ended and constraints on tracks from getDisplayMedia()
15:30:05 <dom> -> https://github.com/w3c/webrtc-pc/issues/2942 Review mute/unmute/ended and constraints on RTCRtpReceiver's track
15:30:05 <dom> -> https://github.com/w3c/mediacapture-transform/issues/109 Review mute/unmute/ended and constraints on new VideoTrackGenerator().track
15:30:06 <dom> -> https://github.com/w3c/mediacapture-fromelement/issues/98 Review mute/unmute/ended and constraints on tracks from element.captureStream()
15:30:09 <dom> -> https://github.com/w3c/mediacapture-fromelement/issues/99 Review mute/unmute/ended and constraints on tracks from canvas.captureStream()
15:30:12 <dom> -> https://github.com/WebAudio/web-audio-api/issues/2571 Review mute/unmute/ended and constraints on track in audioContext.createMediaStreamDestination().stream
15:30:25 <dom> [slide 26]
15:32:02 <dom> Elad: +1 to closing mediacapture-screen-share/#298
15:32:05 <dom> Youenn: +1 too
15:32:24 <dom> s|/#|#
15:34:08 <dom> [slide 27]
15:35:08 <dom> Youenn: muting tracks on stopped transceivers sound like a webkit bug, indeed; is there a matching WPT test?
15:36:12 <dom> ... re unmuting ahead of RTP - waiting for the RTP could create a race where a frame gets sent while you still think you're muted; how valuable is it to wait for the RTP packet?
15:36:22 <dom> ... since there isn't interop on this yet, there may be room to change/simplify
15:36:44 <dom> Jan-Ivar: I'm not aware that this has creating an issue for FF
15:37:04 <dom> ... an event that fires on main thread will be put potentially on a busy queue
15:37:47 <dom> ... but it may be worth filing an issue to reconsider the current spec'd behavior, ideally with some measures/experiments to back the question
15:38:20 <dom> ... or we leave webrtc-pc#2915 open?
15:38:26 <dom> Youenn: a separate issue sounds good
15:39:08 <dom> ... any input from Chromium crbug 941740
15:40:16 <dom> Guido: that's behavior inherited from old language; we need to look at it to check web compat, but this shouldn't block progress on the spec
15:40:36 <dom> ... I agree with the spec clarification
15:41:22 <dom> youenn: if this isn't web compatible, this would be useful feedback
15:42:24 <dom> RESOLVED: close webrtc-pc#2942 as reviewed and webrtc-pc#2915, open an issue on timing of unmuting on RTC reception
15:42:40 <dom> [slide 28]
15:43:25 <dom> RESOLVED: close mediacapture-transform#109
15:43:27 <dom> [slide 29]
15:44:47 <dom> i/[slide 27]/RESOLVED: close mediacapture-screen-share#298
15:44:57 <dom> RRSAgent, draft minutes
15:44:59 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/26-webrtc-minutes.html dom
15:45:09 <dom> RRSAgent, make log public
15:46:11 <dom> Youenn: AFAIK, this is only implemented in Chrome; we probably should start from what's implemented
15:46:38 <dom> ... when content is tainted, it cannot be untainted except by restarting the streaming (ending the track)
15:47:10 <dom> Jan-Ivar: FF has an implementation (prefixed as mozCaptureStream)
15:48:18 <dom> Youenn: then that would be worth integrating in our analysis as well
15:48:50 <dom> [slide 30]
15:50:08 <dom> Jan-Ivar: mediacapture-fromelement#99 is a dup of mediacapture-fromelement#82
15:50:33 <dom> Youenn: +1; we should look at origin-clean - I think a tainted canvas stay canvas, but I could be wrong
15:50:50 <dom> ... otherwise, we should consider ending the track
15:51:58 <dom> Guido: in Chrome, the muting behavior is based on whether we're sending frames
15:52:20 <dom> Jan-Ivar: what happen when calling captureStream(0) in that situation?
15:52:36 <dom> Guido: it will be muted too
15:52:46 <dom> Jan-Ivar: we should clarify since I don't think there is interop on atm
15:53:12 <dom> Guido: +1 on aligning within web compat
15:53:33 <dom> ... I don't envision big challenges
15:53:54 <dom> RESOLVED: no implementation-defined behavior for mediacapture-fromelement#82; close mediacapture-fromelement#99
15:54:02 <dom> Youenn: we should file tests for this
15:54:14 <dom> ... Safari is not firing events afaict
15:54:39 <dom> ... I'm still not seeing how a tainted canvas can be cleaned - this could be a different issue
15:54:47 <dom> Jan-Ivar: +1 on new clarified issues
15:55:17 <dom> [slide 31]
15:56:09 <dom> Jan-Ivar: this is up to the WebAudio WG, but is there any additional advice we would like to give them?
15:56:56 <dom> Youenn: it makes sense; I wonder about muting when suspending a context? not sure there is a demand for it
15:57:14 <dom> Jan-Ivar: maybe an ended event in case of a terminal action on the audiocontext?
15:57:53 <dom> ... in any case, please chime in on the webaudio issue if interested WebAudio/web-audio-api#2571
15:58:02 <dom> Subtopic: -> https://github.com/w3c/mediacapture-record/issues/194 mimeType ambiguity: "video/webm;codecs=vp8" means?
15:58:02 <dom> [slide 32]
16:00:54 <dom> Youenn: +1 to align the spec with Chrome
16:01:04 <dom> ... the audio codec might depend on the container
16:01:36 <dom> RESOLVED: Align spec with Chrome
16:01:40 <dom> Topic: -> https://github.com/w3c/webrtc-extensions/pull/198 RTCRtpEncodedSource
16:01:40 <dom> [slide 35]
16:01:48 <dom> Present+ TimP
16:01:53 <dom> [TimP joins]
16:04:01 <dom> [slide 36]
16:04:39 <dom> Guido: this is the result of iteration on github, now matching the pattern of encoded transform, with only a writable part
16:06:01 <dom> [slide 37]
16:08:23 <dom> [slide 38]
16:09:45 <dom> [slide 39]
16:12:02 <dom> Guido: having this wouldn't preclude a packet-based API if useful for other use cases
16:12:41 <dom> [slide 40]
16:13:16 <dom> TimP: I like this; some worry that it's not obvious that it's the same frame from multiple sources
16:13:31 <dom> ... not sure how the metadata get preserved in the routing
16:14:22 <dom> Guido: re metadata, this is under control of the overall application - this doesn't have to be solved at the level of that spec
16:15:17 <dom> TimP: right, but I wonder if there is a question the timeline of exposing metadata in the frame
16:15:33 <dom> Tony: the header extension dependency descriptor should help
16:15:40 <dom> TimP: but will that be available in the worker?
16:15:54 <dom> Guido: right - but this can be considered separately
16:16:19 <dom> Youenn: the API shape is fine, the use case as well; there may be some refinement on names
16:16:49 <dom> ... in encoded transform, we're making it hard to trigger errors
16:17:07 <dom> ... here there are many error triggering opportunities, which will need to be signalled in a timely manner to the Web app
16:17:56 <dom> ... this is basically modeling an encoder - we should do that modeling work early on
16:18:20 <dom> Guido: Harald's model with bandwidth congestion etc can help think about these questions
16:18:50 <dom> Youenn: for instance, we should list all the error cases we can think of, and determine how they get handled (signal to the app, drop the data, ignore)
16:18:53 <dom> Guido: +1
16:19:36 <dom> Bernard: so this is an alternative to addTrack/replaceTrack - does that imply additional work where other parts of the system assume it's a track but it's not, e.g. stats?
16:20:01 <dom> Guido: since this is very similar to a track, it's probably a matter of having clarifications in the text
16:20:31 <dom> ... from the point of view of the system, it's very similar to a MediaStreamTrack - we need to identify the parts where they differ (e.g. it's already encoded)
16:21:01 <dom> ... the initial proposal I made had identified a few monkey patches, but they weren't substantial
16:21:51 <dom> Bernard: would track events pass through? are there equivalent to ended events? how would replaceTrack work since it depends on the state of the track?
16:22:19 <dom> Guido: the track signals shouldn't be much of problem
16:23:17 <dom> Youenn: re impact on stats, this would have been more difficult on the initial proposal; in this new API shape, the UA can determine that stats are no op
16:23:45 <dom> Jan-Ivar: thanks for explaining the use case; it looks ambitious, but I like the small step approach
16:24:02 <dom> ... it does raise a number of questions at the model level as we just discussed
16:24:12 <dom> ... I like the API shape
16:25:09 <dom> ... re constructor for RTCEncodedVideoFrame - is there a copy of the arraybuffer when constructing a new frame?
16:25:19 <dom> guido: you should (although it could be optimized for copy on write)
16:25:29 <dom> Jan-Ivar: other potential sources, e.g. WebCodecs?
16:25:36 <dom> Guido: there could be yes
16:26:02 <dom> ... this would require better integrating encoded chunks in rtcencodedframes
16:26:43 <dom> Jan-Ivar: in the fan-out/fan-in example - if one of the nodes has specific encoding capabilities, this may create limitations
16:26:48 <dom> Guido: this is an app decision
16:27:47 <dom> Jan-Ivar: how would you deal with simulcast layers?
16:28:09 <dom> Guido: that's part of the error modeling we need to describe with appropriate signals
16:28:30 <dom> Jan-Ivar: this looks promising to me
16:28:55 <dom> Philip: do you have an example of what kind of metatadata would be passed?
16:29:00 <dom> guido: e.g. consistent frame ids
16:29:51 <dom> ... this is up to the application
16:31:00 <dom> Tony: the RTCEncodedVideoFrameMetadata dictionary expose the frame id via the header extension
16:31:51 <dom> Jan-Ivar: we have to figure how a sender without a track works, how setParameters work, ...
16:32:51 <dom> Youenn: we should definitely rely on WebCodecs
16:33:10 <dom> Guido: I'll explore creating an encoded frame from encoded chunks
16:33:34 <dom> Peter: getting these constructors is a fantastic idea
16:33:55 <dom> Topic: -> https://github.com/w3c/webrtc-nv-use-cases/ WebRTC Extended Use Cases
16:33:55 <dom> Subtopic: PR #118 Bandwidth feedback Speed(Configurable RTCP transmission interval)
16:33:55 <dom> [slide 42]
16:35:17 <dom> [slide 43]
16:35:27 <joachimr> joachimr has joined #webrtc
16:37:26 <dom> [slide 44]
16:38:04 <dom> [slide 45]
16:39:17 <dom> TimP: I understand the need, but I'm bothered by milliseconds; it feels like it should be tied to the frame interval rather than an absolute time
16:39:41 <dom> ... I like the general idea
16:40:53 <dom> Bernard: I'm not sure I understand the need for a control for L4S in the WebRTC API
16:41:19 <dom> Youenn: I had the same question - if the UA knows L4S is in use, it can just do it
16:41:45 <dom> ... it feels like this would be something the UA would want to enable in any case when it's available
16:42:41 <dom> Sun: we think different apps may have different interval configurations
16:43:19 <dom> ... video recovery in loss conditions may also need different parameters
16:44:30 <dom> Bernard: looking at RFC8888 talks about the overhead of the feedback channel
16:46:10 <RRSAgent> RRSAgent has joined #webrtc
16:46:11 <RRSAgent> logging to https://www.w3.org/2024/03/26-webrtc-irc
16:46:16 <dom> Jan-Ivar: Gamestreaming sounds like a good use case to support, but I'm not sure about making some of these under the control of the app vs UA
16:46:20 <dom> ... maybe the requirement can be phrased in a way that avoids imposing a particular model
16:46:36 <dom> Bernard: the goal is to avoid building queues, reduce congestion
16:47:10 <dom> ... I agree a more general statement would work better
16:47:42 <dom> Jan-Ivar: I'm hearing the current configuration of UAs isn't optimized for game streaming - a question if a different configuration would work better for all use cases or only some
16:47:57 <dom> Bernard: part of the challenge is that it is under deployment at the moment
16:48:11 <BurgerBurger> BurgerBurger has joined #webrtc
16:48:27 <dom> Joachim: at Meta, we have also found the need for these APIs
16:48:41 <dom> ... RTCP being restricted to 5% of bandwidth ties our hand
16:48:55 <dom> ... in the game streaming use case, it would be useful to remove that restriction
16:49:22 <dom> Bernard: connections tend to be so asymetric though
16:49:49 <dom> Peter: not limiting RTCP for feedback from congestion control would make sense
16:49:50 <geheimnis`> geheimnis` has joined #webrtc
16:50:00 <dom> Bernard: there can be a huge amount of feedback since the messages are large
16:50:21 <dom> Peter: but you're only doing this to figure out how much you can send - you can allocate more of that for the feedback with lower estimate
16:50:37 <dom> ... this is part of the congestion control mechanism - it's a different category from the rest of RTCP
16:51:03 <dom> TimP: that illustrates why a hint would be useful - there are use cases where this would be detrimental
16:51:19 <dom> ... e.g. in videoconference, you want to optimize the bandwidth for audio, not feedback
16:51:30 <dom> ... in game streaming, this may be a very different trade-off
16:52:53 <dom> Peter: I think it makes sense to let the app to choose between the trade-off of amount of bandwidth and responsive in feedback messages
16:53:06 <dom> Bernard: I like Tim's idea of a hint that lets the UA decide
16:53:15 <dom> ... there is also discussion on the jitter buffer target
16:53:35 <dom> ... I wonder if there is a set of hints that we could describe that covers the needs, without making them settings
16:54:22 <dom> Jan-Ivar: the current N48 req is very specific - maybe it could say the app "must be able to lower the timing…" or have some influence. Would that work?
16:54:25 <dom> Sun: yes
16:54:36 <dom> Subtopic: PR #129 video decoding recovery after packet loss
16:54:36 <dom> [slide 46]
16:54:39 <dom> RRSAgent, draft minutes
16:54:40 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/26-webrtc-minutes.html dom
16:55:46 <dom> Bernard: video recovery would be good - it's more complicated in the confenrecing case; there are a variety of proposals to improve this
16:55:50 <dom> [slide 47]
16:56:41 <bemfmmhhj> bemfmmhhj has joined #webrtc
16:57:14 <dom> [slide 48]
16:59:02 <dom> Peter: it'd be great to have support for LTR frames or support for control of the temporal layer in general
16:59:22 <dom> ... I'd be curious about how much we want to make this a WebRTC encoder API vs WebCodec API, or both
16:59:33 <dom> ... but dependency control is an important API to have
16:59:52 <dom> Bernard: if it was on WebCodec, it would bubble up to us through some of the changes we're discussing
17:00:18 <dom> ... I'd suggest to generalize the requirement about recovery reference control or additional recovery mechanisms
17:00:28 <dom> RRSAgent, draft minutes
17:00:29 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/26-webrtc-minutes.html dom
17:01:10 <bemfmmhhj> bemfmmhhj has joined #webrtc
17:01:10 <geheimnis`> geheimnis` has joined #webrtc
17:01:10 <BurgerBurger> BurgerBurger has joined #webrtc
17:01:10 <slightlyoff> slightlyoff has joined #webrtc
17:01:10 <timeless> timeless has joined #webrtc
17:01:10 <Josh_Soref> Josh_Soref has joined #webrtc
17:02:43 <[old]freshgumbubbles> [old]freshgumbubbles has joined #webrtc
17:04:04 <w3c_modbot> w3c_modbot has joined #webrtc
17:04:29 <meinfuhrer> meinfuhrer has joined #webrtc
17:07:43 <Dalek> Dalek has joined #webrtc
17:08:50 <chainlesslove> chainlesslove has joined #webrtc
17:09:23 <Tobias> Tobias has joined #webrtc
17:09:57 <bigtestaccount> bigtestaccount has joined #webrtc
17:12:18 <SergeyRubanov> SergeyRubanov has joined #webrtc
17:14:53 <iyobro143> iyobro143 has joined #webrtc
17:16:57 <sentinel1975> sentinel1975 has joined #webrtc
17:19:36 <karmaishere> karmaishere has joined #webrtc
17:23:15 <BradIsbell> BradIsbell has joined #webrtc
17:27:07 <OOM> OOM has joined #webrtc
17:27:34 <Mike5Matrix> Mike5Matrix has joined #webrtc
17:29:02 <DirtyHeisenberg> DirtyHeisenberg has joined #webrtc
17:32:34 <SintayewGashaw> SintayewGashaw has joined #webrtc
17:34:35 <Github> Github has joined #webrtc
17:40:56 <MarkF> MarkF has joined #webrtc
17:42:31 <GiorgiGzirishvili> GiorgiGzirishvili has joined #webrtc
17:43:01 <GiorgiGzirishvili> GiorgiGzirishvili has joined #webrtc
17:43:01 <MarkF> MarkF has joined #webrtc
17:43:01 <Github> Github has joined #webrtc
17:43:01 <SintayewGashaw> SintayewGashaw has joined #webrtc
17:43:01 <DirtyHeisenberg> DirtyHeisenberg has joined #webrtc
17:43:01 <Mike5Matrix> Mike5Matrix has joined #webrtc
17:43:01 <OOM> OOM has joined #webrtc
17:43:01 <BradIsbell> BradIsbell has joined #webrtc
17:43:01 <karmaishere> karmaishere has joined #webrtc
17:43:01 <sentinel1975> sentinel1975 has joined #webrtc
17:43:01 <iyobro143> iyobro143 has joined #webrtc
17:43:01 <SergeyRubanov> SergeyRubanov has joined #webrtc
17:43:01 <bigtestaccount> bigtestaccount has joined #webrtc
17:43:01 <Tobias> Tobias has joined #webrtc
17:43:01 <chainlesslove> chainlesslove has joined #webrtc
17:43:01 <Dalek> Dalek has joined #webrtc
17:43:01 <meinfuhrer> meinfuhrer has joined #webrtc
17:43:01 <w3c_modbot> w3c_modbot has joined #webrtc
17:43:01 <[old]freshgumbubbles> [old]freshgumbubbles has joined #webrtc
17:43:01 <bemfmmhhj> bemfmmhhj has joined #webrtc
17:43:01 <geheimnis`> geheimnis` has joined #webrtc
17:43:01 <BurgerBurger> BurgerBurger has joined #webrtc
17:43:01 <slightlyoff> slightlyoff has joined #webrtc
17:43:01 <timeless> timeless has joined #webrtc
17:43:01 <Josh_Soref> Josh_Soref has joined #webrtc
17:45:34 <Hash> Hash has joined #webrtc
17:46:17 <vianka> vianka has joined #webrtc
17:48:27 <manutrivedi> manutrivedi has joined #webrtc
17:49:41 <M0x> M0x has joined #webrtc
17:51:46 <KevinBush> KevinBush has joined #webrtc
17:52:26 <miguelNavarro> miguelNavarro has joined #webrtc
17:53:13 <naseeralshoowk> naseeralshoowk has joined #webrtc
17:56:10 <general_j> general_j has joined #webrtc
17:56:48 <JerryZhang> JerryZhang has joined #webrtc
17:59:11 <sdd> sdd has joined #webrtc
18:04:14 <aswaniaryo> aswaniaryo has joined #webrtc
18:07:42 <fales> fales has joined #webrtc
18:11:03 <SeanDuBois> SeanDuBois has joined #webrtc
18:11:09 <__z__> __z__ has joined #webrtc
18:12:16 <AnthonySpencer> AnthonySpencer has joined #webrtc
18:12:24 <padenot> padenot has joined #webrtc
18:12:40 <joraboi445> joraboi445 has joined #webrtc
18:13:50 <juztinjohnz> juztinjohnz has joined #webrtc
18:14:30 <^_^> ^_^ has joined #webrtc
18:17:19 <Matthewaway> Matthewaway has joined #webrtc
18:18:59 <JustinJenkins> JustinJenkins has joined #webrtc
18:20:13 <hunter_hsbnd> hunter_hsbnd has joined #webrtc
18:22:02 <robjperez> robjperez has joined #webrtc