►
From YouTube: WEBRTC WG Virtual Interim March 30, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
well,
this
is
the
April
meeting
of
the
WebRTC
working
group.
We
started
it
a
little
bit
early
since
it's
only
March
30th
just
to
reminder
of
the
w3c
IP.
Our
policy
we
abide
by
it,
and
only
people
in
companies
listed
on
that
webpage
are
allowed
to
make
substantive
contributions
to
the
WebRTC
specs.
A
So
today,
we're
gonna
hope
to
make
progress
on
features
at
risk.
Privacy
concerns,
and
we
also
have
some
new
work
relating
to
audio
acquisition,
which
Sam
will
be
talking
about
a
little
bit
about
the
meeting.
This
is
the
basic
info.
We
have
a
link
to
the
slides
on
the
wiki.
We
do
need
a
scribe
for
today
do
we
have
a
volunteer.
A
Okay,
so
here's
what
we're
gonna
try
to
do
today,
so
we'll
talk
a
little
bit
about
the
features
at
risk.
I'll
cover
that
two
issues
from
Weber
to
CPC.
Then
we
have
media
capture
and
streams
and
Sam
will
present
an
audio
acquisition
and
we'll
have
some
other
privacy
issues.
So
that's
the
agenda
for
today.
A
Okay,
so
let's
talk
about
what
you
see
PC
first
and
uncle
on
the
features
at
risk.
So
there
are
a
few
unimplemented
editors
that
are
not
yet
marked
as
features
at
risk,
but
probably
should
be
on
the
three
issues
Sam
has
filed
relating
to
that
the
first
one
is
the
voice
activity
Lag.
You
may
recall
this
as
exposed
in
the
RTC
OTP
synchronization
source,
but
as
far
as
I
know,
nobody
implements
it.
So
do
we
have
agreement
from
the
group
that
this
should
be
marked
at
risk?
I
didn't
see.
Any
objections
in
the
issue
sounds.
A
So
we'll
mark
that
one,
the
second
is
I,
think
we
have
one
unimplemented,
MTI
stat,
which
is
partial
frames
lost.
There
were
a
couple
at
daum
put
in
this
issue:
24
97
that
have
been
moved
elsewhere.
So
that's
why
they
didn't
get
picked
up.
I
think
that's
accurate
right!
Henrik
only
just
won
the
partial
frames
lost,
yeah.
A
A
D
A
C
C
F
A
E
D
E
C
D
C
The
the
meet
of
the
implementation,
the
extra
logic
is
there,
it's
just
being
exposed
in
the
wrong
object,
which
we
obviously
obviously
have
to
fix
that.
But
it's
it's
not
one
of
those
not
implemented.
It's
just
need
to
move
it.
It's
not
lacking
proof
of
concept
right.
It's
not
liking
the
proof
of
concept.
Okay,.
E
D
A
So
I
think
we
have
consensus
to
just
remove
the
MTI
designation
on
partial
frames
lost.
Is
that
correct?
Yes,
okay
and
the
last
one
is
2498,
which
is
multiple
DD
TLS
certificates.
The
wte
test
fails
because
I
don't
think
any
browser
implements
this
and
it's
not
a
particularly
high
priority
I
think
that's
an
accurate
statement
of
where
we
are
so
not
likely
to
get
get
this
implemented
anywhere
anytime
soon.
You.
D
D
C
A
A
C
A
E
B
A
C
A
D
G
So
I
think
the
wasn't
the
background
of
this,
that
you
could
have
multiple
kinds
of
certificate
and
you
didn't
have
to
support.
Like
you
know,
you
didn't
have
support
ECD
age,
so
you're
you
could
offer
more
than
one
and
then
whatever
the
far
end
could
deal
with
it
would
take
I
mean
I,
don't
think
anybody's
doing
and
I
don't
think
it's
relevant,
but
I
thought
I.
Think
that
was
the
background.
Well.
A
D
Alright,
thank
you
so
so
this
is
a
problem
that
came
up
while
writing
a
web
platform
tests
for
perfect
negotiation.
But
it's
really
more.
A
criticism
of
the
API
itself
and-
and
you
know,
web
platform
test
is
often
where
we
first
try
to
use
these
api's
and
try
to
use
it
in
a
deterministic
manner.
So
it
with
so
just
to
back
up
a
little
bit
perfect
negotiations.
Is
this
a
pattern
we
recommend
now
in
the
spec,
where
we
take
full
advantage
of
the
negotiation
needed
event
which
lets
an
application?
D
Excuse
me
which
less
than
an
application
abstract
away
the
negotiation
logic
from
the
rest
of
its
application,
so
that
you
can
do
modification
methods
on
peerconnection
objects
on
both
sides
and
expect
them
to
be
just
negotiated.
So
how
so?
You
can
call
PC
dot,
add
transceiver,
for
example,
to
add
a
video
transceiver,
and
then
you
can
just
wait
a
while,
or
you
know
at
some
point.
D
This
will
be
in
and
the
benefit
here
is
that
perfect
negotiation
takes
care
of
glare
and
negotiation
can
get
complicated
because
it's
an
asymmetric,
stateful
exchange
that
happens
between
two
peers
network
involved.
So
it
can
actually
be
quite
complicated
to
know
when
negotiation
has
actually
happened,
and
when
you,
your
new
transceiver,
has
not
just
a
direction
which
is
application
input.
The
current
direction
is
actually
has
been
negotiated
and
that
you
know
that
the
other
peer
also
has
system
this
transceiver
now
in
the
new
state.
D
D
So
another
problem:
why
I
think
this
is
a
problem,
but
it's
because
this
is
getting
this
right
in
application
code
can
be
quite
difficult
and
I
suspect
a
lot
of
people
just
like
what
perfect
negotiation
was
trying
to
solve
was
to
avoid
people
writing
racy
code
because
mentio
she
isn't
it
so
complicated.
The
obvious
approach
is
racy
outside
of
highly
control
cases,
so
the
point
was
made
on
list
yeah
well
in
web
platform.
Tests
are
highly
controlled
cases,
so
this
is
not.
This
is
less
about
web
platform
test.
D
This
is
more
about
writing,
api's
that
are
not
racy
and
having
good
api's
and
in
fact
this
particular
web
platform
test.
Does
it's
a
bit
of
as
somewhat
tests
that
are
kind
of
like
stress
tests,
to
make
sure
that
and
they're
not
always
how
you
deterministic,
because
you
want
to
make
sure
that,
for
instance,
a
transceiver
can
be
called
at
any
point
and
negotiation
will
never
be
missed
in
there
because
a
couple
negotiation.
D
So,
if
you
had
like
a
button
with
onclick
and
then
you
did
an
ad
transceiver,
you
have
to
imagine
that
you
should
be
able
to
click
this
button
at
any
time
and
which
cute
ask
you
end
up
in
between
you
and
make
sure
that
nothing
goes
wrong
and
nothing
is
missed.
And
you
don't
produce
any,
and
this
is
their
errors,
so
also
we
could
have
just
missed
a
negotiation
previously
the
negotiation
train
right,
so
you
call
a
transceiver
once
and
then
some
time
passes
and
the
negotiation
needed
to
depend
fires.
D
It
starts
now
you're,
suddenly
preparing
an
offer
or
you're
in
you're,
not
in
a
stable
signalling
state,
and
then
you
hit
the
button
again
and
now
you
add
a
second
transceiver
that
transceiver.
Then
it's
going
to
require
negotiation,
but
it
just
missed
a
negotiation
train
that
left
the
station.
So
if
you
then
do
a
wait
for
stable
state
you're
going
to
arrive
at
stable
state
sooner
then
when
you're
and
your
transceiver
is
not
gonna
be
negotiated.
D
So
you
wait,
you
have
to
wait
for
the
next
train,
so
next
slide
so
I
try
to
so
you
can
write
you.
Can
you
can
work
around
us?
You
can
do
a
spin
tests,
but
those
are
specific
to
the
the
action
that
you're
doing
all
my
examples.
Series
use
a
transceiver,
but
the
same
could
be
said
for
create
state
or
channel
or
we
start
ice
or
any
other
method.
You
want
to
do
so.
D
Having
to
write
action,
specific
tests,
so
basically,
while
loop,
you
do
a
transceiver
and
then,
while
I
don't
have
the
result,
I
want
I,
wait
and
the
bad
thing
about
that
is
that
you
know
you
don't
know
either
it
works
or
you
timeout.
Basically,
and
that's
that's
bad
for
tests,
but
that's
also
bad
in
general.
Next
slide.
D
My
side,
which
means
all
my
stuff,
will
be
up
to
date
up
to
a
point,
so
that
takes
care
of
all
back
and
and
remote
offers
and
next
slide
and
now
I
can
do,
but
but
we
still
have
to
account
for
a
missing
local
train.
So
this
is
slightly
better
in
that
we
don't
have
a
while
loop
anymore,
but
we
still
have
we
had
transceiver.
We
await
a
negotiated
event
that
we
just
created,
and
then
we
checked
current
direction
once
so.
It's
bill
is
still
action
specific,
but
it's
not
a
spin
loop
anymore.
D
So
and
if
we
didn't
get
the
result,
we
have
to
wait
one
more
train.
So
it's
you
know,
that's
as
good
as
I
could
get
a
next
light,
but
it's
still
not
good
enough.
So
can
we
do
better
so
I
have
three
proposals
and
I
should
also
say
that
in
in
finding
out
when
negotiation
need
is
needed
is
actually
complete
can
be
tricky
because,
let's
say
you
click
this
button.
Often
you
might
Creek
at
create,
add
transceivers
many
times
and
it
could
take
a
while,
especially
not
on
the
local
machine,
but
on
a
real
network.
D
It
might
actually
take
a
while
to
negotiate,
and
so
getting
this
right
seems
tricky
so
proposal
a
fire
negotiation
complete
event,
I'm
set
remote
subscription
answer
only
if
renegotiation
isn't
needed.
As
you
may
recall,
we
have
in
such
remote
description.
We
have
this
code
that
once
we
go
back
to
stable,
we
check
if,
if
negotiation
isn't
needed
still
needed,
and
if
it
is,
we
queue
a
task
to
fire
another
round
of
negotiation
so
somewhere
in
there
we
would
add
logic
to
to
fire
a
negotiation
complete
event.
D
If
we're
really
complete
and
there's
no
more
negotiation
needed-
and
it's
simple
one
downside
is
that
subject:
subsequent
actions
may
delay
this
event.
I
mentioned
earlier.
If
you
had
an
transceiver
called
in
the
middle
of
this,
they
would
not
need
another
round
of
negotiation.
That's
also
going
to
delay
this
event.
So
that's
it's
simple,
but
it
still
has
a
lot
of
problems
because
it
can
lead
to
further
delays.
Now
these
are
cutting.
You
could
argue.
These
are
edge
cases.
We
don't
care
that
much
proposal
next
slide.
D
Please
proposal
B
is
similar
is
to
expose
an
ago
she
needed
boolean
attribute
and
then,
instead
of
receiving
an
event,
you
can
sort
of
do
the
dance
you
can
do
a
while
loop,
but
specifically
on
the
APC
negotiation
needed
events.
So
you
come
back
to
stable
and
you
check
yourself
in
JavaScript.
It's
negotiation
still
needed.
Then
I
have
to
wait
for
another
train.
D
This
is
the
benefit
that
it's
not
action.
Specific.
You
can
use
this
to
create
a
general
Cipolla
and
so
forth.
One
complication
for
writing
this
into
the
spec
is
that
we
have
to
be
a
little
careful
in
implementations,
because
once
you
expose
this
boolean
to
JavaScript,
we
then
must
fire
the
negotiation
needed
then
later
the
way
we
have
it
right
now
we're
cueing
a
chain.
D
So
this
is
proposal
C
it's
explosive
and
they
go
she's
in
complete
promise
attribute.
We
haven't
had
these
accept
and
yet
identity
spec,
where
we
had
a
PR
identity
where
it's
actually
an
attribute
on
the
PC.
That
is
a
promise
object,
and
so
you
do
the
same
thing.
You
do
add
transceiver
and
then
you'll
wait.
D
This
negotiation
complete
promise-
and
this
is
better
than
the
previous
proposals,
because
this
fulfillment
of
this
new
promise
would
not
be
delayed
by
subsequent
actions
and
the
way
we
would
accomplish
that
internally
is
a
bit
convoluted,
but
users
shouldn't
have
to
worry.
Basically,
we
would.
The
browser
would
replace
the
attribute
with
a
new
promise.
Each
time
a
negotiation
treated
train
leaves
the
station.
D
C
Question
if
you
go
back
to
two
slides
to
proposal
a
that's
the
same
except
you
don't
have
this
yeah
the
Train
thing
right
here.
You
you
fire
an
event
when
you're
completed-
and
you
say
one
downside
is
the
subsequent
accidents
may
delay
the
event
this
refers
to
when
you
you,
you
missed
the
Train
and
you
and
an
ongoing
negotiation
will
happen
before
you
know
that
you're
completed.
D
C
D
C
Yeah,
okay,
don't
I
understand
it's
great
I,
like
proposal
a
more
than
proposal
C,
because
I
think
the
important
thing
like
I
want
to
know
when
am
I
not
good
like
basically
enough
I,
don't
hate
to
use
the
word
stable,
but
a
stable
state
like
I,
don't
have
to
do
any
more
negotiation,
whereas,
if
I
care
about
something
partial
like
has
this
specific
transceiver
been
negotiate.
That
I
can
add
logic
for
that
specific
thing.
Well,.
B
B
Have
this
problem,
because
this
nice
open
event
that
fires
men
when
I
went
in
areas
decided
that
is
open,
so
I
will
claim
that
the
example
given
far
in
a
transceiver
is
if
we
want
to
solve
it.
Oh
I
mean
I
I,
don't
like
that
in
new
API
ever
at
this
point,
but
if
we
want
to
solve
that
at
all,
we
should
think
about
this
chance
serious
now
connected
to
you
to
use
usable
channel.
D
Right
so
I
think
for
yes,
it
is
an
option
that
you
could
say
you
call
a
transceiver
or
you
set
direction,
and
you
you
ask
when
this
is
done.
I,
don't
care
it'll
just
happen.
The
problem
is,
it
can
actually
take
a
while
to
happen.
So
if
we're
assuming
that
application
code,
there's
no
application
code
out
there
that's
written
to
care
about
when
it
actually
happens
or
if
it
ever
happens,
we
we
probably
don't
need
this
I,
would
question
that.
B
If
you,
if
you
fire,
five,
had
transceivers
yeah,
then
what
you
care
for
each
transceiver
is
that
is
that
it's
usable
and
so
that's
a
transceiver
lately
the
demand
not
negotiation.
You're
later
than
that
negotiation
is
right
right.
The
background
note
is
made
to
make
the
chassis
racism
so
you'd
learn
writing
that
that
if
we
want
to
have
empty
here,
we
should
be
thinking
about
adding
adding
a
as
they
changed
or
direction
change.
Zero.
B
G
So
the
other
thing
you
could
do
is
take
proposal
C
and
then
just
add
some
sort
of
property
which
says
what
is
what's
now
complete.
So
you
know
when
you,
when
you
get
this
information
when
you
get
this
event
or
what
it
or
promise
whatever
we
end
up
doing,
you
know
which
transceiver
it
is
that's
now
good
and
you
can
then
display
it
or
display
it
or
whatever
it
is
you're
gonna
do
with
the
UI
I
tend
to
agree
with
Harold
that
you
want
to
know
what
it
is
that
you've
just
got
well.
D
G
B
Right
JavaScript:
in
the
case,
we
have
fire
five
at
receivers,
three
other
keppra
first
plane
and
to
an
occasional
strain
in
this
in
propose
receipt.
You
would
fire
the
event
after
or
erase
all
promise
after
number
five
spin.
Then
it's
translated,
while
in
let's
call
it
proposal
II,
you
will
fire
my
events,
one
for
a
transceiver.
Exactly
one
is
that.
D
D
D
C
D
C
It's
just
that
this
is
a
nice
to
have
I
think
when
you're
writing
tests
and
if
you're
gonna
even
want
to
debug
like
hey
my
applications
broking
what's
going
on,
it
were
very
useful
to
know
whether
or
not
there
is
any
negotiation
that
is
needed.
I
think
it's
a
nice
to
have,
but
I
don't
think
it
solves
a
problem
that
isn't
already
solvable
with
the
existing
api's
I.
D
Would
disagree
there
excuse
me
so
you're
saying
that
we
could
polyfill
this
and
I.
Don't
actually
think
that
we
can.
The
problem
is
that
we
now
queue
a
negotiation
needed
which
means
that
I
think
before
we
did
that
you
could
make
a
case
if,
if
you
came
back
to
stable
and
then
you
queued
a
task
and
then
you
checked
whether
you've
gotten
negotiation
needed
or
not,
if
you
didn't,
you
would
know
for
sure
that
negotiation
either
was
not
needed.
D
However,
now
we
queue
negotiation
needed
firing
on
the
cube
negotiation
needed,
which
means
that
it
could
get
stuck
on
the
peerconnection
queue
behind
multiple
all
the
methods
coming
in
a
turn
at
iced
candidate,
other
negotiation
methods.
So
you
know
so
you
have
to
wait
longer
and
but
there's
no
way
to
know
how
long
you
have
to
wait.
Well,.
D
C
For
each
thing
you
want
to
know:
if
it's
not
negotiated
you
can
you
can
just
you
make
a
change
like
add
transceiver
you
so
you
know
something's
needed,
and
then
you
know
the
conditions
that
will
have
occurred
once
this
has
been
negotiated.
So
you
can
manually
do
some.
Some
tinkering
and
you'll
know
that
that
thing
is
done.
If
you
do
that
for
all
the
possible
things
that
you
could
negotiate,
you
would
have
this.
It
would
be
a
much
more
code.
It
would
be
different
code
for
different
use.
C
Cases
like
add
transceiver,
maybe
just
what
you
care
about
is
the
direction.
But
what,
if
you
do
set
streams
well
set
stream
or
or
ice
restart?
You
wouldn't
need
some
different
logic
like
okay.
If
I
do
an
ice,
restart
I
need
to
know
that
I've,
you
know
done
one
exchange
without
rolling
back,
that's
happened,
I,
don't
let
cetera
so.
C
So
now
my
point
my
point
is:
is
this
is
a
night
if
we
want
to
do
do
this,
this
is
a
nice
guy
that
does
it
for
you,
but
I
just
wanted
a
it's.
If
we
want
just
to
test
something
or
the
big,
the
debug,
something
specific
I,
don't
think
it's
needed,
I
think
it's
nice,
but
I
don't
think
it's
needed
well,.
D
That's
a
good
example:
you
brought
up
set
streams.
We
don't
currently
have
a
way
to
observe,
set
streams
locally
right.
So
let's
say
I
want
to
set
these
new
streams
and
then
I
want
to
negotiate
and
then
out
of
a
band
I
want
to
send
a
signaling
message
to
the
other
side
and
say
you
know,
look
at
your
these.
A
C
D
H
D
C
A
A
D
Right
I
have
a
general
question.
Err.
How
much
time
do
we
have
is
this
sounds
like
well,
we
covered
in
930,
no
I
meant
I
meant
in
November
to
see
working
group
because
it
sounds
like
some
of
us
are
working
on
the
assumption
that
every
time
to
address
these
things
in
the
future
and
at
the
same
time
our
charter
isn't
necessarily
extended
for
a
full
year,
even
on.
E
The
process
bit
so
the
Charter
is
expanded
extended
until
September
only
because
so
we
were
planning
initially,
as
you
may
recall,
from
tip
back,
we
are
planning
to
prepare
each
other.
Given
the
upcoming
changes
in
the
diversity
process,
we
thought
it
was
better
to
wait
until
the
new
process
was
a
very.
E
The
plan
is
once
that
you
process
available.
We
go
through
a
proper.
We
charter
for
Assad
I
can
tell
you
two
years
new
charter.
So
that's
for
the
formal
beats
real
beats
is
that
we
continue
as
long
as
there
are
people
ready
to
to
do
the
work
I
mean
I,
can't
imagine
an
API
as
rich
and
complex
as
were
about.
Is
he
as
being
done?
There
is
a
ratio
cost-benefit
that
we
have
to
evaluate
on
each
other's
evaluate
in
terms
of
participating
or
not?
C
So
issue,
when
are
the
effects
of
the
in
parallel
stuff
surfaced?
This
might
sound
like
a
silly
question,
because
this
back
is
written
to
say
like
in
parallel.
Do
the
thing
and
then,
when
the
thing
is
done,
you
cue
a
task
and
you
update
things
according
links
are,
for
example,
in
parallel,
apply
the
SDP
according
to
the
J
sub
rules,
and
then
it's
successful.
You
cue
a
task
and
you
update
the
set
of
receivers
and
internal
slots
accordingly,
so
it
seems
like
that's.
When
things
become
observable
right.
C
Well,
then,
there
we
have
a
ad
track,
so
in
J
sub
assess
and
if
the
peer
connection
isn't
have
very
much
offer
state
and
the
track
will
be
attached
to
the
first
compatible
transceiver
that
has
been
created
in
the
most
recent
settlement.
Description
call:
that's
that's
not
like
it.
If
you
have
a
compatible
transceiver
that
may
have
been
created
by
cetera
my
description,
you
can
reuse
that,
instead
of
creating
a
new
transceiver,
those
things
do
you
know
JavaScript,
supposedly
single-threaded
and
in
the
the
peer
connection,
has
this
internal
slots
and
they're
updated
in
tasks.
C
They
have
a
set
of
transceivers
and
a
signaling
state
that
they're
not
technically
the
finest
internal
slots
and
I
looked
at
the
spec,
but
they
have
a
definition
that
says
that
when
the
connection
is
created
and
you
look
at
through
the
entire
spec,
it's
it's
get
and
set
the
specific
points
on
the
JavaScript
thread.
But
then
we
have
signaling
Fred
and
transceivers
this
concept
that
accepts
existing
Jessup
as
well.
So
are
these
the
same
states
or
are
they
different
next
slide?
C
So
the
question
is
this
like,
if
I
do
add
track
like
I,
do
separate
remote
description
with
an
SDP
that
would
have
created
a
transceiver
that
is
compatible
and
I
do
add
track
after
that,
without
a
waiting
in
between
well
a
new
transfer
be
created
or
not
so
yeah
has
it
has
a
compatible
chance.
You've
been
created
when
that
track
is
executed
and
I.
Think
there's
two
options
like
if
add
track
operates
on
WebRTC,
pcs
definition
of
signaling
state
and
set
of
transceivers,
and
the
answer
is
clearly
no.
I
C
C
Right
and
I
would
say
no
because
it's
sir
than
PC
that
signaling
state
and
PC
dot
concurrency
VIRs
our
race
EAP
is,
and
you
could
do
a
while.
You
know
you
couldn't
even
loop
through
get
transceivers
using
indexes,
because
the
said
that
the
number
of
transceivers
could
change
in
the
middle
of
your
loop,
because
III
think.
C
Not
true
so,
but
still,
you
know,
might
might
add,
track
surface,
etc.
My
description
traded,
Jacek
transceivers
to
JavaScript,
even
if
you
know
so.
What
do
we
do
today
and
in
chrome
said
from
a
description,
will
always
create
a
transceiver
first
and
then
add
track
will
expose
this,
and
while
it's
well
defined
the
this
means
that
JavaScript
thread
is
blocked
on
in
parallel
work.
So
it's
not
truly
in
parallel.
C
I
think
this
is
incorrect,
but
that's
what
we
do
and
in
Firefox
correct
me
if
I'm
wrong,
but
we
have
mutexes
and
you
know
I
share
set
of
objects.
So
if
I
understand
things
correctly,
what
happens?
Is
you
have
both
of
these?
You
have
the
JavaScript
thread
and
the
background
thread
and
there
could
be
racist,
so
add
track,
may
expose
the
transceiver
it's
it's
non-blocking,
but
it's
racy
so
problem
one
is
this
compatibility
issues
and
problem?
C
Two
is
races
and
you
know
problem
three
is
the
six
is
exposing
the
fact
that
JavaScript
isn't
single-threaded
that
a
concern?
It's
it's
a
principle
that
we
generally
don't
violate.
So
next
slide
so
proposal.
A
yes
did,
whether
or
not
add,
track
should
be
cycle
or
transceiver
or
create
a
new
one
should
be
at
the
session
that
is
performed
on
the
JavaScript
thread
so
on
the
Jas,
the
WebRTC
pcs
set
of
transceivers.
C
If
we
do,
this,
then
add
track
is
not
dependent
on
J,
sub
States,
and
so
there's
no
risk
of
surfacing
these
in
parallel,
created,
object.
I
believe
that
this
is
already
about
the
spec.
Yes,
because
we
reduce
it's
well
defined
when
we
add
and
remove
from
these
set
of
transceivers,
so
I
think
it
what's
necessary
is
to
clarify
this.
A
problem,
though,
is
that
both
Chrome
and
Firefox
are
non-compliant.
According
to
this,
the
alternative
proposal
to
you
know
mix.
C
These
states
would
be
to
update
the
spec
to
allow
the
add
track
message
to
a
add
a
truth.
Javascript
set
of
transceiver,
you
add
a
transceiver
that
has
been
created
in
jessup,
so
you're
exposing
something
that
happened
in
parallel,
but
in
the
synchronous
API.
But
then
we
would
have
to
make
it
clear
that
that
this
could
be
racy
implementation-specific,
which
transceiver
you
get,
and
that
this
we're
violating
this
non
single
threaded
design
principle
on
purpose.
D
Well
so
I'm
not
sure
which
is
proposal
and
which
ones
be
ax
from
your
descriptions,
but
I
agreed
that
we
have
racy
behavior
there
and
I.
Think
I
opened
an
issue
earlier
as
well:
JSF
being
racy
the
problem
taking
a
step
back,
Jacek
was
written
without
thinking
about
threads
at
all,
yeah
and
then
web
RTC
PC
comes
along
and
says
basically
we're
going
to
run
jasa
entirely
in
parallel
and
then.
A
D
We
changed,
we
updated
and
that
used
I
think
maybe
in
the
past
there
might
have
been
a
time
where
that
was
okay,
because
all
the
information
was
basically
serialized
through
the
description,
but
then
I
think
at
some
point
maybe
JSF
gruesome.
We
added
these
add
track
Kluge's
and
it
ends
up
referring
to
peer
connection
state
from
a
background
thread,
and
that
is
inherently
racy
and
I.
D
Would
the
reason
I'm
confused
is
that
because
it's
not
less
about
whether
it's
on
the
JavaScript
thread
or
not,
because
once
we
trigger
something
in
parallel,
that
means
we
return
the
JavaScript
and
JavaScript
finishes.
And
then
you
know
you
might
have
another
cue
task
from
button
click
or
something
where
you
call
add
track,
or
maybe
you
call
at
track
immediately,
you're
still
updating
that
might
update
your
our
listener,
the
vertices
pcs
set
of
transceivers
so
and
that
could
still
race
with
JSF.
C
And
I
think
that's
what
like
I
think
I
say
my
in
my
head:
we
have
web
RTC,
PC,
JavaScript
objects
and
there's
these
shallow
objects
that
refer
to
something
that
exists
somewhere
else
on
JSF
level.
And
so
you
can,
you
can
add
transceiver,
and
you
know
the
Jessop
is
going
to
create
the
transceiver.
You
don't
have
to
wait
for
it
all.
The
other
thing
you're
exposing
to
javascript
is
synchronously
available,
because
you
know
it's
just
gonna
be
a
transceiver
that
has
these
initial
values.
That's
find.
C
The
only
problem
is
with
an
track
because
an
track
says
hey,
you
might
want
to
recycle
a
transceiver.
So
then
you
have
to
know,
will.
Is
there
a
transceiver
to
recycle
the
current
spec
examining,
examines
the
WebRTC
PC
set
of
transceivers,
which
does
not
contain
any
taeseop
created
transceivers
until
this
cute
task,
so
I
would
say
that
if
the
add
track
would
make
it
would
say,
oh
I
have
no
transceiver
to
to
recycle,
so
I'll
create
a
new
one,
and
then
we
did
ask.
C
D
So
clearly,
the
hygienic
thing
we
would
leap
to
almost
instinctively
would
be
to
I
said
I
think
when
we
invoke
JSF
in
parallel,
first
copy
off
state
and
basically
write
something
that
said,
you
know
for
the
purposes
of
JSF.
Look
at
these
things,
these
copies
and
don't
don't
you
know,
keep
J
stuff
away
from
our
real
set
of
transceivers
that
might
change
to
avoid
races.
That's
that's
a
typical
way
to
solve
racing.
I
use
copying,
for
example,
I.
Don't.
C
D
Alright,
one
more
I
think
yeah
that
one
you
concept
room
with
description,
an
ad
check.
The
question
is
what
what
is
the
desired
behavior
now,
if
we
were
hygienic
we're
gonna,
we
would
say
that
this
this
new
transceivers
should
not
be
picked
up
by
the
set
remote
description.
Correct.
That's
that's
my
proposal.
Yes,
the
dad
it
would
be
clean.
The
only
downside
is
that
might
leave
a
hole
yeah.
D
C
D
But
think
of
a
perfect
negotiation
needing
them,
so
that
track
is
a
high
level
application
method
and
you
shouldn't
need
to
know
about
we're
in
the
negotiation
process.
You
are
so
you
call
add
track.
Is
that
track
always
going
to
be
picked
up?
It's
either
gonna
be
picked
up
on
this
negotiation
cycle
or
the
next
one
and
that's
fine.
What
I'm
worrying
about
is
there's
a
tiny
hole
now
where
it
won't
be
picked
up
by
either
of
them.
C
B
C
Worried
with
this
problem,
there's
this
hole
and
by
hole
it
means
hey.
We
didn't
attach
to
an
existing
transceiver,
so
we'll
have
to
create
a
new
one,
so
imperfectly
you'll
need
another
additional,
possibly
an
additional
round
of
negotiation.
If
you're
unlucky.
My
point
is:
if
we
are
in
this
situation,
then
we
already
have
a
race
you're,
trying
to
optimize
what
if
we
get
lucky
I
think
I,
don't.
D
C
B
C
C
C
B
F
C
B
D
F
D
C
I
C
We
so
whether
or
not
the
spec
says
what
we
wanted
to
say.
Can
we
add
the
the
consensus
that
we
can
note
probably,
is
that
we
do
not
want,
you
know,
get
transceivers
to
be
racy
like
we
shouldn't
expose
and
if
I
call
get
transceivers
in
a
loop
in
JavaScript
I
shouldn't
suddenly
see
a
new
transceiver
object
pop
up
right.
Okay,.
D
C
A
J
Hi
everyone,
my
name
is
Sam
I'm,
an
engineer
at
Microsoft
working
on
the
HTML
platform,
and
so
the
this
is
basically
a
kind
of
a
mixture
of
a
feature
twice
slash
issue
that
we
found
with
the
spec.
We
got
an
ask
for
basically,
as
the
specification
stands
today,
it's
kind
of
hard
for
developers
to
differentiate
between
streams
that
are
men
for
speech,
recognition
and
for
communication,
and
so
we're
we're
aware
of
the
current
content
and
specification
that
has
different
categories.
J
Currently,
it
seems
like
the
current
implementations
are
geared
a
little
bit
towards
communications,
but
in
general,
communications
can
actually
hurt
speech,
recognition
and
so
and
vice
versa.
So
when
something
is
made
for
communications,
often
there
can
be
things
like.
You
know:
noise
added
to
the
communication
to
make
it
sound
a
little
bit
better
to
the
ear
and
that
can
kind
of
distract
if
you
have
a
speech
recognition
engine
on
the
other
side,
trying
to
listen
to
the
signal
itself.
J
So
here
are
some
of
the
kind
of
differences
that
we
found
between
communications,
audio
and
audio
for
speech
recognition,
and
so
these
are
coming
from
specs
from
Etsy,
and
so
you
can
read
through
them,
but
the
basic
idea
is
that
you
can
see
like
ambient.
Noise
is
different
in
speech.
Recognition,
you're
cutting
all
of
it
out
and
communications
you're
trying
to
make
it
sound
good.
So
next
slide-
and
these
are
more
examples-
the
differences
gained
control
is
also
mentioned,
so
next
slide,
and
so
so
something
that
was
also
something
that
was
mentioned.
J
So
the
first
proposal
is,
let's
add,
a
new
constraint
called
category
and
then
the
specific
name
is
kind
of
open,
but
that
allows
you
to
specify
kind
of
specific
category
values
of
defaults,
raw
communication
or
speech
or
maybe
speech
recognition,
and
so
this
kind
of
like
fits
well
into
the
existing
constraint
model.
It
also
has
very
straightforward
translation
to
implementation
on
multiple
platforms.
We
did
some
research
and
Windows
iOS
Android
all
have
very
similar
kind
of
categories
like
this.
J
So
if
you
wanted
to
get
streams
from
the
device
that
had
these
different
constraints
happens
to
them,
I
would
be
pretty
easy
to
do
the
problem.
Is
it
just
kind
of
competes
with
existing
content
hint
draft
in
a
way,
that's
a
little
bit
confusing
the
content
and
seems
to
be
like
centered
around
setting
different
constraints
or
defaults
for
constraints
and
then
also
providing
hints
to
consumers
of
streams,
whereas
this
is
a
little
bit
is
again
geared
towards
setting
optimizations
on
the
stream
itself.
J
Things
more
like
more
specific,
like
different
levels
of
an
echo
cancellation
so
next
slide.
Our
second
proposal
is
modifying
constraints,
like
echo
cancellation,
to
be
a
little
bit
more
specific,
and
so
they
would
follow
some
of
the
differences
that
were
outlined
in
the
original,
the
slide,
the
previous
slides
and
then
from
there.
J
We
would
be
able
to
add
new
hints
to
the
content
in
draft
which
can
use
these
more
specific
labels
for
echo
cancellation,
and
so
the
pros
for
this
one
are
that
it
fits
in
well
with
the
existing
content
in
drafts,
and
they
could
allow
for
more
developer
freedom.
But
the
implementation
route
is
like
currently
not
as
clear
for
the
the
first
proposal.
It's
easy
is
setting
a
flag
of
this.
One
I
have
to
dive
in
a
little
bit
deeper.
J
But
there
might
be
more
to
do
here,
so
those
are
those
are
my
thoughts
and
so
I
guess.
The
ask
here
is
kind
of
to
get
like
consensus,
that
there
is
a
sort
of
issue
here
for
developers
who
might
want
to
differentiate
between
these
two
types
of
streams
and
then
kind
of
get
a
better
idea
of
what
might
be
the
right
way
to
move.
C
J
Like
more
specific,
more
specificity
here,
but
for
like
echo,
if
you
see
difference,
there's
like
a
difference
kind
of
like
tolerance,
level
of
echo
cancellation,
and
so
it
would,
it
would
be
changing
it
to
kind
of
have
these
different
tolerances
cuz
right
right.
Now,
it's
a
boolean
right,
it's
on
or
it's
all.
B
B
Right,
24
that
your
proposal
for
new
constraints
fits
in
well
with
the
existing
shape
model
and
I,
don't
understand
how
it
fits
well,
given
that
you
are
saying
that
if
we
have
this
new
constraints,
then
then
that
should
affect
a
number
of
things
that
are
controlled
by
other
constraints
and
non-obvious
ways.
So
what
do.
B
D
That's
actually
not
possible
in
any
implementation,
with
all
your
constraints
as
I
know,
like
all
your
constraints
like
any,
you
don't
really
want
to
pick
microphone,
I
mean
you
could
do
that,
but
I
don't
think
anyone
implements
it
because
most
people
implement
echo
cancellation
and
software
noise
suppression
in
software
I.
Don't
think
anyone
supports.
You
know:
hardware,
noise,
cancellation
control
through
these
constraints,
for
example,
the
guys
been.
D
J
They
mentioned
that
currently
Amazon
is
kind
of
rolling
their
own
for
EE
for
their
version
of
this,
so
they're
kind
of
doing
the
same.
The
thing
that
you
mentioned,
where
they're
turning
off
everything
and
then
adding
their
own
optimizations
for
speech,
recognition
and
so
I
guess
the
it
you
write
that
you
can
already
Condit.
You
can
already
do
that
right.
You
can
turn
everything
off
in
the
natural
optimizations
kind
of
the
idea
here
is
to
allow
there
to
be
optimizations
already
there
so
that
you
not
everyone,
has
to
do
their
own
thing.
J
H
J
J
C
C
Way,
I
see
things
is
like
with
echo
suppression
you,
the
only
control
knob
is
on
or
off
if
there
was
a
way
to
actually
control
it
more
specifically,
you'd
probably
just
do
that
and
then
write
the
benefit
of
saying
having
this
category
is
that
the
vagueness,
the
vagueness
means
you
can
probably
try
it
out
and
try
to
just
tweak
the
implementation
to
support
your
use
case,
but
the
downside
of
it
is
when
it's
a
hint
is
left.
Well,
it's
just
a
hint.
So
it's
it's
not
very
well
defined,
like
you
can
say,
yeah
this
stream.
C
B
C
The
way
I
I
mean
the
path
towards
like.
Ideally,
everything
should
just
see
like
this
is
the
thing
you're
tweaking
and
when
you
tweak
that
it
has
this
behavior
and
whenever
possible,
that's
the
direction
we
should
go.
But
if
something
is
very
hard
to
describe-
and
it's
very
implementation
specific
how
you
do
it,
then
it's
hard
to
hard
to
propose
something
that
it
doesn't
sound
like
a
hint
or
you
know
true
or
false,
and
then
so.
D
I
think
what's
true
here,
is
that
it's
a
good
observation
that
parent
implementations
of
echo
cancellation,
those
cancellation
and
autogain-
our
vendors-
have
implemented
them
to
work
with
communication
in
mind.
I
think
that's
fair
to
say:
I,
don't
know
that
we're
gonna
get
commitments
from
browser
implementers
to
implement
different
new
forms
of
echo
cancellation
for
the
purposes
of
speech
right
are.
We
is
that
what
this
is
asking
for.
I
J
B
B
What
you
want
here
is
it's,
preserving
the
artifacts
that
that's
recognized
as
trigger
of
and,
as
you
know,
to
them
echoes
with
vendors.
Switching
these
are
different
for
remote
about
humans.
Do
so
we
so
you
you
want
to
have
processing
that
is
different
from
different
from
what
what
the
processing
is
the
speech
in
general,
we
also
have
music,
which
is
has
its
own
set
of
set
of
requirements
like
one
of
the
major
points,
the
music
is
that
you
definitely
don't
want
time
very
frequency.
The
wow
sounds
that
you're
frequently
get
with
over
here.
Peter
buffers.
C
If
you
want
to
sort
it
week,
things
even
more
I
think.
If,
if
you
want
the
same
successful
story
where
you
add
something,
and
then
everyone
implements
something
like
that,
you
need
to
either
make
I
think
even
make
it.
So,
like
well-defined
enough,
where
you
can
say
this
is
passes
or
fails
like
this
is
the
parameter
and
or
you
need
like
commitment
where
people
are
actively
trying
to
solve
this
problem.
I
guess
otherwise.
G
In
one
kind
of
other
category
here
that
is
kind
of
getting
more
interesting,
which
is
broadcast
so
so
you've
got
two
categories:
their
communications
and
speech
rec,
but
but
I
think
there's
a
third
one,
which
is
you
know,
audio,
that's
subsequently
gonna
get
broadcast
and
that
that's
getting
trendy
at
the
moment.
There's
a
lot
of
it
going
on
so
I
think
I
think
making
this
like
a
switch
at
two
states
which
would
be
the
wrong
solution.
G
It
needs
to
be
something
that
has
like
multiple
possible
states
and
and
right,
certainly
you're
kind
of
doing
that
we've
been
doing
stuff
with
with
podcast
recording
and
and
what
you
want
from
the
audio
from
that
is
different.
I.
Don't
have
a
table
entry
like
this,
but
there's
a
different
set
of
things
that
you
want
to
do.
If
you're
recording
podcast
over
over
this.
H
Would
also
look
at
the
various
implementation
of
no
it's
or
echo
cancellation
and
if
they
are
open
source
ones
and
you
find
like
parameters,
high
level
parameters
but
are
somehow
consistent
between
the
different
implementation.
Maybe
that's
a
good
start
think
about
that
parameters
and
whether
they
can
be
defined
somehow
and
then.
J
A
C
I
guess
it
would
depend
on
the
thing
you
plan
to
change
like
this
I
think
the
first
proposal
was
a
bit
of
a
catch-all.
My
stream
is
gonna,
be
used
for
this
and
then
it's
a
table
of
things
changes
but
I
think
you'd
have
to
go
through
the
list
and
say
is
this
something
where
it's
can
be
expressed
as
like
decibel
or
it's
just
something
where
Vanina
makes
sense?
I,
don't
think
I'm
well-versed
enough
to
have
an
opinion
there.
E
And
I
guess
part
of
the
feedback
I'm
hearing
as
well
is:
maybe
you
should
be
done
in
New,
Zealand,
first
with
Web,
Audio
of
assembly
and
stuff,
and
once
we
see
enough
patterns
emerge
enough,
optimization
that
can
be
done
at
the
browser
level.
Then
maybe
you
will
have
a
better
sense
of
what
the
right
API
the
right
shape
of
the
API
should
be
a
guess.
E
D
A
D
B
A
B
B
D
D
We
should
similarly
think
about
adding
speech,
specific
new
constraints
and
some
extensions
back
otherwise
I
worried
that.
How
are
you
gonna
write
your
application?
Otherwise
it's
gonna
be
like
you
know.
If
Chrome
then
we're
going
to
trust
that
this
constraint
gives
us,
oh
I,
guess
you
would
use
exact
constraints
then,
and
you
would
look
for
over
constrained
error.
Is
that
yet
thinking.
B
F
D
A
H
I
think
that
consensus,
that
should
we
have
to
design
get
to
the
media.
Now
we
would
probably
add
the
same
restriction
now.
We
could
try
to
do
that
and
that
would
break
websites
and
there
will
not
be
happy.
We
cannot
do
it
in
this
matter,
so
the
question
I'm
asking
very
housing
transition
to
do
that
restriction.
Are
there
measures
that
would
allow
it
to
creatively
and
host
your
addiction
and
make
websites
migrate
to
respecting
that
restriction
that
get
to
the
media
should
be
called
beta.
H
H
The
second
thing
is
that
in
patron
case,
or
over
non
user
gesture
cases,
we
could
add
a
prompt
in
cases
where
get
user
media
wouldn't
that
prompt
typically.
So
in
that
case
we
would
not
deny
initially
get
you
in
VR.
If
you
scroll
from
you
the
gesture
we
will,
we
would
uncross
the
prompt
that
would
give
some
incentive
for
websites
you
actually
start
applying
the
user.
Kjetil
restriction,
I
looked
at
a
few
websites,
so,
for
instance,
where
buy.com
is
a
good
example.
Where
you
apply
restriction,
nothing
is
breaking,
nothing
is
changing
if
the
same
workflow.
H
So
our
thinking
that
we
could
try
to
try
24
to
do
the
sections
I'm
mentioning
meaning
that
we
start
implementing
user
gesture
required
on
after
page
Road.
Basically-
and
also
you
know,
then
you
need
to
show
from
basically
I
I.
Think
I,
like
your
kid
back
there,
whether
that's
something
that
could
be
done
and
I
would
be
also
interested.
If
there's
interest
in
the
working
group,
maybe
to
talk
a
little
bit
with
some
WebRTC
websites
in
the
road
birth
to
to
hear
what
they
think
about
it.
C
So
good
is
the
requirement
I,
if
you,
sir
gesture,
is
not
happened
as
the
requirement
do
not
like
to
reject
the
promise
or
is
the
requirement
that
you
prompt,
like
you,
have.
H
H
H
Ingestion
of
you
click
and
then
for
a
few
seconds,
maybe
just
one
second,
for
instance,
there
will
be
a
huge
gesture,
for
instance,
it's
it's
a
heuristic
country
and
it's
not
crossbar
as
we're
consistent,
but
there's
only
code
there
to
try
to
define
it
and
I
have
something
there.
But
for
sure,
if
you
are
thinking,
if
you're
synchronously
calling
something
based
on
the
gesture,
it
will
work,
it's
not
synchronous,
then
it
might
fail.
C
E
C
C
H
You
try
to
get
a
video
feed,
it's
not
the
camera,
it's
the
screen
that
leaves
roughly
equivalent.
Then
we
apply
user
gesture
in
shooting
with
Safari
and
all
web
sites.
I
believe
are
supporting
it.
So
it's
true
that,
for
instance,
initially
it
was
film
on
some
websites
and
very
trying
to
do
it
and
they
were
waiting
a
little
bit
and
then
it
was
failing,
but
they
found
solution.
D
D
Yeah
you
have
where
someone
could
gain
a
camera
access
now
through
navigation,
because
you
can
set
window
location
and
you
know
I-
could,
for
instance,
until
a
couple
of
days
ago
for
jsfiddle
jsfiddle
used
star
and
its
analyst,
which
means
it
grants
camera
to
do
anything
that
it
iframes.
So
you
could
actually
from
my
malicious
site
I.
D
Could,
when
the
users,
when
I
know
the
users
not
looking
I,
could
navigate
to
my
own
fiddle
in
jail
to
my
own
jsfiddle
and
that
would
basically
escalate
me
up
to
get
camera
microphone
permission
by
redirecting
back
to
my
site
in
an
iframe
at
Jay's,
Phil
and
then
I'm
able
to
access
the
camera.
So
I
think
the
the
so
I
think
this
is
quite
necessary
to
go
this
direction
and
I
like
the
idea
of
starting
with
prompting,
because
I
would
I
would
mitigate
the
immediate
problems.
D
I
think
without
too
much
discussion,
I
think
whether
we
get
to
denying
requests
outright
I
think
that's
a
long-term
goal.
I,
don't
know
how
I
feel
about
that
at
the
moment.
There's
a
counter
case
where
and
also
I'm
wondering
if
we
could,
how
specific
the
spec
needs
to
be,
because
I'm
also
wondering
whether
browsers
user
agents
could
detect
whether
a
navigation
happens
across
origin,
so
that
I
think
Carl
mentioned
the
case
where
there
might
be
websites
that
actually
invoke
page
navigation
within
their
own
site
in
order
to
jump
into
a
room
and
maybe
be
unfortunate.
B
So
my
big
worry
about
everything
like
this
is
how
much
how
much
legitimate
use
is
very
great,
so
I
would
say
that
before
we
progress
this
any
further,
someone
should
have
a
browser
in
the
field
with
a
with
a
counter
unit,
saying
how
much?
How
much
usage
do
we
have
of
Gettys
media?
Well,
a
doesn't
use
gesture
and
how
much
do
we
have
with
a
you
suggest
presents
I
would
I
mean
if,
if
it's
99%
of
one
man,
one
percent
of
the
other
there's
no
big
deal?