Web Real-Time Communications Working Group Teleconference

12 Apr 2018



Vivien_Lacourba, Stefan_Hakansson, Bernard_Aboba, Harald_Alvestrand, Angelina_Gambo, Cullen_Jennings, Alexandre_Gouaillard, Jan-Ivar_Bruaroey, Lennart_Grahl, Suhas_Nandakumar, Taylor_Brandstetter, Nils_Ohlmeier, Patrick_Rockhil, Soares_Chen, Randell_Jesup
Stefan_Hakansson, Bernard_Aboba, Harald_Alvestrand


June F2F

(discussions about holding this meeting in the US following previously agreed meeting location algorithm or do a virtual meeting)

<lgrahl> No matter where the meeting takes place, possibility to participate remotely would be appreciated (since I can't afford attending to pretty much anything at the moment)

WebRTC WG Charter

<vivien> Draft Charter

BA: Charter has been extended.
... some items were added since last interim
... clarification on items that would be dropped depending on how many implementations are available

HTA: all features, regardless on they being optional or not, need two implemntations

fluffy: let's take it to the lists my memory is that every time we bring it on, the answer is different

ba: two open issues for current, and some other for 2.0 and object models
... we probably need to bring those to the list as well, but we need to converge quickly

WebRTC-PC - Issue 1813: Simulcast makes no sense for Audio (Bernard)

<vivien> Issue 1813

Q: do we need simulcast audio?

Q: what s behaviour when too many simulcast encoding are requested

BA: my position is that RED is better than simulcast for audio.

fluffy: the question is shall we remove simulcast for audio?

jib: no browser implement it, and we need two implementation to keep it along. We need to decide what it means/takes to be compliant today. and what is the behaviour if one does not support it?

hta: we need to specify how the client can detect that only 1 layer of simulcast is supported, at the API level.

the API can be supported by saying that you support only 1 layer of simulcast.

jib: but then we need to advertise how many layers you support.

BA: yeah, it s tricky, audio and video can be different, it can also be different per codec, ..... an error could be easier.

jib: an error is not exactly better, but .....
... an other approach would be to go for best effort
... make an error makes web developper to code against this error, and if they don t some browsers are left unsupported.

BA: say someone ask for 5, and the browser can only do 3, then what happens? we have not even defined what get parameter would return?

hta: we should make it clear, no matter what.

stefan: it depends also on what the answerer says, so it s tricky.

Nils: 1 is not a nice answer, because you still have the simulcast overhead of RID and signalling ..... if i don t support it, i just say 0, and don t get overhead.

jib: i like the idea to use get parameters. it s better than an error.

BA: what about you do the best you can, and then getparmeter will tell you the best it could do. Does that seem reasonable?

jib: superficially it looks ok, but get parameter today is supposed to return only what is set. so ....

BA: exactly! there might be dragons.

nils: you can only know after negotiation for simulcast settings.

ba: supposedly get parameters is independent of negotiation, and now, we would wait for after the negotiation to call it, to know what the result of "best effort" was

hta: i suggest that jib draft something without an error.

jib: accepted.

WebRTC-PC - Issue 1174: ssrc in RTCRtpEncodingParameters (Bernard)

<vivien> Issue 1174

BA: not having access to the SSRC might be a problem for SFU vendors when transitioning to unified plan
... shall we put it back? taylor?

TB: shouldn't we put it in the SDP?

hta: in theory SSRC can change .....

stefan: we would need an event, right?

BA: it's been implemented. it happens. but it happens so rarely that most people ignore it.

nils: i know that some people do that to switch streams. so you need to have an event to tell people that what was exchanged in the SDP has changed.

hta: that s why it should not be in the SDP.

BA: are you suggesting we should explore putting it in stats?

the: it s already in stats, but i think we should put it also in whichever object makes sense.

nils can we wait after everybody switched to unified plan

BA: it s actually blocking unified plan
... the problem is that depending on the object there is no event, and we need to know when ssrc changes

hta: SSRC mapping should get inferred from the wire

BA: do we have at least a consensus that we need to address this?
... next step is to come up with something more specific

WebRTC-PC - Issue 1706: Should rollback fire addtrack/removetrack events? (Jan-Ivar)

<vivien> Issue 1706

WebRTC-PC - Issue 1775: RTCPeerConnection lacks identity marker beyond current process (Harald)

<vivien> Issue 1775

consensus is that what jib proposed for rollback makes sense

discussion about wether this is a generic need, or a chrome internal implementation detail.

Jesup: we need a use case.
... if it s chrome only, it s not enough to make it part of the standard.

WebRTC-PC - Issue 1826: No way to add stream associations to a transceiver (Jan-Ivar)

<vivien> Issue 1826

consensus is that the proposal is good.

mediacapture-screen-share - Issue 29: Powerpoint is special (Suhas)

<vivien> Issue 29

mediacapture-screen-share - Issue 31: Define behavior of existing constraints in screen sharing (Jan-Ivar)

<vivien> Issue 31

propsal for a list, mandatory to implement.

hta: and if someone really want to do cropping ....

jib: the screen sharing spec could be a living document.
... note on cropping, it makes sense for cam, just not for screensharing

ba: you are on the hook for the PR

mediacapture-screen-share - Issue 39: Non-top-level browsing contexts (Jan-Ivar)

<vivien> Issue 39

consensus is on using feature-policy

mediacapture-screen-share - Issue 43: Disable local playback during audio sharing (Martin)

<vivien> Issue 43

BA: it was agreed that we would not do it.

mediacapture-screen-share - Issue 49: Bring back constraints for downscaling (Jan-Ivar)

<vivien> Issue 49

mediacapture-screen-share - Issue 51: Browser tab sharing (Suhas)

<vivien> Issue 51

BA: consensus for option 2

mediacapture-screen-share - Issue 55: Why does getDisplayMedia live on navigator and not navigator.mediaDevices? (Suhas)

<vivien> Issue 55

jib: the question is: do the Api need to fire an event, if that s the case i can NOT be on navigator.

hta: the consequences are not huge, except that edge already ship it like that.

consensus: stay like it is (on navigator)

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/04/13 08:03:11 $