(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)
<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
<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.
<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
<vivien> Issue 1706
<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.
<vivien> Issue 1826
consensus is that the proposal is good.
<vivien> Issue 29
<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
<vivien> Issue 39
consensus is on using feature-policy
<vivien> Issue 43
BA: it was agreed that we would not do it.
<vivien> Issue 49
<vivien> Issue 51
BA: consensus for option 2
<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)