profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/stefhak/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

fluffy/webrtc-w3c 30

W3C Specification for WebRTC

w3c/webrtc-ice 7

Extension to the RTCIceTransport interface defined in WebRTC 1.0

EricssonResearch/ipso-odm 2

Tools for translating IPSO/LwM2M and OneDM SDF models

stefhak/test-apps 1

test-apps

gaperik/sec_obj_cache 0

Drafting requirements and solutions for 'secure' caching

stefhak/blind-cache-draft 0

This repo is where we work on a framework description of the BC proposal.

stefhak/iswebrtcreadyyet.com 0

Promoting WebRTC support through the clever use of a website with words on it

issue openedEricssonResearch/oscore-edhoc

Option number 13 --> 21

Comment from Christian at IETF 110:

"if 21 also works, please pick 21. it's the same to this use case, but another protocol may make better use of 13"

created time in 7 hours

push eventEricssonResearch/ipso-odm

Petri Laari

commit sha d4e7ffce491de548b00cd923750a72b1fcc2678f

Added create-sdfthing instructions

view details

push time in 13 hours

PR opened w3c/webrtc-priority

updated refs to IETF RFCs
+11 -11

0 comment

1 changed file

pr created time in 15 hours

push eventw3c/webrtc-priority

caribouW3

commit sha 35985330482251a0d2897f78e846da58b7682c6a

updated refs to IETF RFCs

view details

push time in 15 hours

create barnchw3c/webrtc-priority

branch : refs-update

created branch time in 15 hours

push eventw3c/webrtc-pc

henbos

commit sha 7afce60f790f8881e3aaedbc540f7c874380bbec

Update to latest ReSpec version

view details

Dominique Hazael-Massieux

commit sha de74080c5950741acade239ff5467d25bcff6e66

Merge pull request #2627 from w3c/respec-26.1.1 Update to latest ReSpec version

view details

push time in 20 hours

PR merged w3c/webrtc-pc

Update to latest ReSpec version Editorial

Automated changes by create-pull-request GitHub action

+158 -158

0 comment

1 changed file

dontcallmedom

pr closed time in 20 hours

create barnchw3c/webrtc-pc

branch : respec-26.1.1

created branch time in a day

PR opened w3c/webrtc-pc

Update to latest ReSpec version

Automated changes by create-pull-request GitHub action

+158 -158

0 comment

1 changed file

pr created time in a day

create barnchw3c/mediacapture-main

branch : respec-26.1.1

created branch time in a day

PR opened w3c/mediacapture-main

Update to latest ReSpec version

Automated changes by create-pull-request GitHub action

+294 -293

0 comment

1 changed file

pr created time in a day

issue closedEricssonResearch/spindump

We never get change events when IDs change

We do now, fixed in commit fa722fd.

closed time in 4 days

jariarkko

issue openedEricssonResearch/spindump

We never get change events when IDs change

We do now, fixed in commit fa722fd.

created time in 4 days

push eventEricssonResearch/spindump

Jari Arkko

commit sha fa722fd2034a6b79e7211f2f60e0bbf9a671662e

fixed support for changing identifiers, and qlog identifiers

view details

push time in 4 days

push eventEricssonResearch/spindump

Jari Arkko

commit sha b66a39225c4feff75cb5aa951af71da299345db0

improved group_id for Qlog

view details

push time in 4 days

issue commentw3c/mediacapture-main

what is the default channelCount

I sense people thinking that OS defaults are very important, and so that if the OS says that the default is something, then we should listen. So I'm willing to conclude from the discussion that OS defaults are more important than predictability.

So let's only look at when there are no OS defaults for a particular setting. E.g. after constraints processing and knowing which device to pick and filtering out any settings according the constraints processing, you are left with more than a single configuration for the said device, and no OS defaults to tell you which one is better.

Example: After constraints processing you know you're going to open camera X which is capable of being opened in resolution A or B and the default does not say if A or B is better. Both A and B are spec-compliant today. What do you do?

In this case, a "tie-breaker" must be implemented. Question is: should the spec give any guidance here, or should every User Agent come up with their own solution?

fippo

comment created time in 4 days

push eventEricssonResearch/spindump

Jari Arkko

commit sha 7ae628687faa1b6f32e30edda2efbb6b81800443

first version that supports qlog (to some extent)

view details

push time in 4 days

issue commentw3c/mediacapture-main

what is the default channelCount

There is apparently no consensus for channelCount yet. We should acknowledge this and seek for consensus.

To clarify, no consensus is needed today, as it is up to user agents. This ensures defaults can keep up with changing times.

But the OP question is useful, whether it leads to more spec language or not, because it's revealing implementer bugs.

To answer: Firefox defaults to the max a microphone can do, capped at 2. But we've found bugs (1, 2). This represents our desire to promote stereo for users who have stereo (both in audio apps and web conference calls).

But regardless of what the default is, we need to ensure all browsers are able to send and receive stereo, and that they're not wasting bandwidth upsampling mono to stereo. We should ensure we have WPT tests for this.

fippo

comment created time in 4 days

issue commentw3c/webrtc-stats

Map out implementation status of getStats and make a plan

Yes, if the other end doesn't offer mids. We may be synthesizing mids for this case; I'll have to check the specs (and implemenation!) for that.

henbos

comment created time in 4 days

issue commentw3c/webrtc-stats

Map out implementation status of getStats and make a plan

Are you saying it's possible to have negotiated transceivers that don't have a mid attribute?

henbos

comment created time in 5 days

issue commentw3c/webrtc-stats

Map out implementation status of getStats and make a plan

And in the no-mid case, we can't tell which RTP streams are connected to the same media section unless we have transceivers.

henbos

comment created time in 5 days

issue commentw3c/webrtc-stats

Map out implementation status of getStats and make a plan

There are mulitple RTP streams per sender and receiver. I get nervous about trying to represent senders and receivers as implicit objects that only exist as "these RTP streams are all pointing to the same track". If a track is replaced, and the SDP is with a legacy endpoint that doesn't support MID, how do we tell that the RTP stream is still belonging to the same sender as before?

(Receivers are less problematic since the track<->receiver attachment is permanent)

henbos

comment created time in 5 days

push eventEricssonResearch/spindump

Jari Arkko

commit sha 5ac070f6f14939f29a75f9917121749573761b9b

started adding the infrastructure needed for Qlog printing

view details

push time in 5 days

push eventEricssonResearch/ipso-odm

Petri L

commit sha 2e621e7ee23c68878656f378ef0b181f77c8a3a4

First version of create-sdfthing

view details

push time in 5 days

issue commentw3c/webrtc-stats

Map out implementation status of getStats and make a plan

csrc we can get the data from getContributingSources, @karthikbr82 can you confirm this?

Yes so I think we should delete this one?

henbos

comment created time in 5 days

issue commentw3c/webrtc-stats

Map out implementation status of getStats and make a plan

FYI remote-inbound-rtp.totalRoundTripTime, roundTripTimeMeasurements and fractionLost just got implemented by an external contributor :)

henbos

comment created time in 6 days

issue closedEricssonResearch/spindump

Spurious "unable to parse coalesced Google QUIC" errors in trace_quic_rfc_quant_basic

This seems wrong, as no Google QUIC is used in the PCAP, it is all IETF/RFC version QUIC.

Output says:

packet not long enough for QUIC hdr: 0 packet not long enough for QUIC token: 0 packet not long enough for QUIC length: 0 unable to parse coalesced Google QUIC: 2 unrecognised QUIC version: 0 unsupported QUIC message type: 0 unrecognised QUIC message type: 0

closed time in 6 days

jariarkko

issue commentEricssonResearch/spindump

Spurious "unable to parse coalesced Google QUIC" errors in trace_quic_rfc_quant_basic

Solved in the latest commit. There was never any real issue, but the parsing of packets needs to stop at the first short form frame inside one packet

jariarkko

comment created time in 6 days

push eventEricssonResearch/spindump

Jari Arkko

commit sha c249ec4cd958bbcac534e6f88657e56d32511041

fix to issue #231

view details

push time in 6 days

issue commentw3c/mediacapture-main

what is the default channelCount

Using the Lenovo microphone example, if there were some way for the system to indicate to the browser that echo cancellation were on

This example seems to works well with the echoCancellation=false by default rule. If the Lenovo microphone is doing echo cancellation and the User Agent cannot disable it, getCapabilities should show that echoCancellation cannot be false for that device. User Agent will use echoCancellation to true because that is the only value.

The fact that the User Agent does not know whether the microphone is doing echo cancellation or not should be treated more as a bug than as a usecase.

In the case of an observable constraint such as frame width/height, I'd prefer the user agent take whatever the underlying system provides by default.

What happens if there is no default? For instance, on MacOS, if we do not set the width/height, we will most often use what the last application set. This is an issue for two reasons:

  • The application will potentially never get the same resolution.
  • The last application may have used a super low or super high resolution, good for its particular usecase but not good for most cases.
  • The web page gets disclosed to what the last application actually did, which is a small privacy leak for no good reason.
fippo

comment created time in 6 days