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"

Automated changes by create-pull-request GitHub action

Automated changes by create-pull-request GitHub action

Automated changes by create-pull-request GitHub action

We do now, fixed in commit fa722fd.

We do now, fixed in commit fa722fd.

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?

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.

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.

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

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

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)

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

Yes so I think we should delete this one?

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

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

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

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.