►
From YouTube: WebRTC Working Group Virtual Interim January 11, 2018
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
Result
of
our
looking
into
this
ad
transceiver
with
a
kind
attribute
instead
of
a
track
attribute
and
it
can
be
discussed
if
the
direction
of
that
kind
of
transceiver
should
really
be
sound,
received
the
person
filing
the
issue
thought
it
should
be
receive
only,
and
the
second
question
is
what
is
the
mid
for
that
receiver?
The
mid
question
is
resolved
and
there
is
a
pending
method
creation
which
may
be
overridden
by
the
SDP
answer,
and
we
think
that
was
already
covered
in
the
specification
for
the
direction
question.
A
A
As
I
said
before,
it
has
been
argued
that
the
transceiver
that
is
created
with
the
kind
attribute
instead
of
a
track,
should
have
the
default
Direction
receive
only,
but
then
my
recommendation
would
be
to
keep
send
receive.
It
is
simple
to
have
it
in
the
same
way.
All
the
time
I
haven't
seen
a
very
strong
reason
for
changing
it,
and
if
you
want
something
else,
you
can
easily
do
it.
When
you
create
a
transceiver.
A
C
This
is
the
Oliver
just
a
back
story.
There
they're,
basically
two
use
cases
right
for
this.
One
is
to
do
create,
offered
offer
to
receive
only
to
implement
that
as
a
receive
only
track.
You
just
going
to
receive
audio
and
not
send
it,
and
the
other
one
is
to
negotiate
a
track
that
you
want
to
fight.
You've
won
on
track
to
fire
remotely
so
that
you
can
use
replace
track
later,
and
those
are
it's
a
little
confusing,
maybe
that
we
have
a
single
method
to
do
those
two
things.
A
D
E
E
A
But
I
hear
no
one
saying
we
should
change
this.
So
let's
keep
it
then
they're.
Also
follow-up
question
I
mean:
should
you
be
able
to
do
replace
track
even
if
no
track
was
ever
attached,
I
mean
if
you
create
a
transceiver
with
kind
and
then
do
it
replace
rack,
and
the
conclusion
is
yes
and
in
fact
a
warm
up.
Example
in
the
specification
does
exactly
that.
A
A
Instead
of
the
track
currently
being
sent,
and
in
some
cases
I
mean,
maybe
you
don't
have
a
track
for
maybe
the
transceiver
is
inactives
you're,
not
in
fact
sending
anything
and
then
also
Taylor
brought
up
that
we
need
to
clarify
a
better
direction,
should
not
be
considered
when
you
determine
if
negotiation
is
needed
when
you
do
replace
a
because
you
might
want
to
replace
the
track,
even
though
you're
not
currently
sending.
So
when
you
start
sending
again,
the
new
track
will
be
sent.
C
Jonnie
bargain
speak
that
sentence
the
the
replaced
tract
language
around
whether
negotiations
needed
is,
it
needs
to
be
rewritten
when
it
was
written.
It
only
considers
the
simple
use
case
of
replacing
something
that's
already
sending
and
it
and
it
can
be
missed.
It's
not
clear
what
should
happen
well,
it
should
be
written
to
not.
The
goal
was
always
to
make
sure
that
you
wouldn't
leave
the
system
in
the
failed
in
the
failed
state
where
you
try
to
replace
something
couldn't
be
sent
because
it
had
the
wrong
encoders.
C
C
All
right,
so
this
wasn't
feedback
from
someone
on
our
Daum
team.
Apparently
the
the
best
practice
in
web
IDL
is
to
prefer.
So
this
is
about
a
dictionary
member
in
return
from
RTP
synchronization
source
is
the
voice
activity
flag
for
back
for
breakfast
implements
the
method
now
gets
synchronization
source
we
do
not
implement
yet
the
voice
activity
flag.
That's
quite
a
lot
of
work,
so
the
device
is
too
so
we
right
now.
The
dictionary
member
is
both
required
and
has
inaudible,
and
we
got
feedback.
C
That's
saying
that
you
shouldn't
do
that
unless
you
have
well,
basically
that's
a
combination
you
should
avoid
because
it
leaves
inconsistencies
on
the
web
platform.
If
something
is
missing,
it
should
use
optional,
not
required
and
nullable
it's
sort
of
a
full,
a
full
optional.
If
you
will
so
to
fix
that,
we
propose
that
well,
a
I
would
like
to
allow
implementations
to
not
implement
bugs
activity
flag
like
Firefox
is
currently
doing,
because
that's
the
considerable
piece
of
code,
so
we
recommend
removing
the
required
flag
on
voice
activity
flag.
C
So
that
would
mean
that
if
the
member
is
missing
its
unimplemented,
if
it's
present
but
contains
null,
then
that
means
the
package
had
no
had
their
extensions
marking
telling
you
anything
about
the
voice
activity
flag
and
if
it's
false
or
true,
then
that's
the
value
of
the
voice
activating
flag.
That
is
present.
C
E
C
E
Okay,
I
mean
I
mean
we
have
a
lot
of
you
know,
sort
which
conferencing
stuff
is
relying
on
this
being
implemented
one
way
or
another,
and
it
seems
like
it
should
be
completely
trivial.
So,
okay
I
think
we
should
dig
into
it.
You
know
why
it
might
be
complicated
because
it
might
be
were
we're
talking
about
the
wrong
thing.
I
know
people
have
occasionally
been
confused
investment.
They
had
to
implement
an
algorithm
to
figure
out
what
was
background
noise.
What
was
needed?
E
C
So
it
may
be
that
it
might
still
be
too
late
for
us
to
put
that
in
Firefox
beta,
which
is
coming
up
in
a
week
so
well
in
that
case,
to
go
to
the
second
point
just
to
set
the
precedent
here
is
or
to
describe
the
the
thinking
of
how
to
describe
the
web
idea
in
these
kinds
of
cases.
So
where
implementation
is
required,
like
for
the
audio
level
which
we
have
implemented,
the
idea
would
be
we
would
use
optional
and
not
null,
and
so
it
would
remove
nullable
and
have
a
it
be
optional.
C
So
there
means
it's
the
members
absent.
It
means
there's
either
unimplemented
or
no
header
extension.
But
basically
you
should
implement
this.
So
there's
no
way
in
the
API
to
tell
whether
browser
has
implemented
it
and
from
and
tell
that,
apart
from
there
not
being
a
header
extension,
and
so
the
presence
of
you
remember
means,
there's
a
value
and
then
we
try
to
fix
Firefox
as
soon
as
possible.
C
Right,
so
the
the
difference
here
is
whether
the
API
should
let
JavaScript
do
feature
detection
or
whether
the
presence
of
the
get
synchronization
sources
methods
alone,
guarantees
that
these
are
all
implemented
after
clarify
audio
level
is
implemented.
Firefox.
It's
just
that
there
was
a
question
raised
about
voice
activity
flag,
whether
to
change
that
to
also
follow
the
optional
with
no
nullable,
in
which
case
we
have
a
bug
bit.
In
any
case,
that
seems
to
be.
E
C
E
C
Well,
the
first
version
of
Firefox
would
this
feature
will
probably
not
have
voice
activity
flag
at
this
point,
so
we
have
to
fix
it
soon
after
and
that's
what
the
question
is
whether
the
spec
done
should
reflects
to
some
of
the
limitations
might
not
have
it
or
not
or
if
we
just
chop
it
up
as
a
bug.
So.
A
C
So
this
is
related
about
time
stamps.
So
two
places
you
get
times
time.
Someone
is
get
two
to
bring
sources,
also
get
synchronization
sources
and
separately,
there's
also
time
stamps
and
stats.
So
we
have
already
there's
some
questions
of
issues
filed.
It's
not
possible
to
tell
how
old
some
of
these
data
points
are
like
to
get
contributing
sources
gives
you
data
back
as
old
as
ten
seconds.
There's
no
way
to
compare
it
to
any
clock.
C
The
JavaScript
knows
at
the
moment,
because
it's
not
specified
to
only
sits
local
clock,
so
the
the
discussion
on
the
issue
here,
some
good
points
that
came
up
and
that
I
think
Carl
mentioned
we
might
want
to
define
time
stamp
in
reference
to
the
context,
global
monotonic
clock
right
now.
We
do,
we
don't
say
anything
and
we
also
at
the
same
time
I
think
he
said
he
prefers
to
have
something
like
a
wall
clock
for
logs,
which
is
already
what
it
looks
like
it
gets
that
so
it'll
be
nice
to
be
somewhat.
C
It
would
be
better
backwards,
compatibility
there
and
that
you
get
back
a
number,
that's
reasonably
similar
to
what
it
was
before.
Rather
than
a
totally
different
offset
so
yeah,
we
want
to
be
able
to
compare
time
stamps
from
steps
and
get
some
string
sources
and
get
synchronization
sources.
So
it
sounds
like
we
want
a
time
step,
that's
comparable
to
either
in
JavaScript
comparable
to
the
performance,
timing,
navigation,
start
plus
performance
now
or
performance
time.
Origin
plus
performance
now,
and
the
reason
there
are
two
is
a
little
complicated.
But
two.
C
The
main
difference
is
that
the
first
navigation
start
is
it
clocks,
a
timestamp
on
page
load.
So
when
you
refresh
the
page,
it
will
pick
up
any
kind
of
local
time
changes
like
you
change
your
clock.
The
user
change
their
clock
on
the
machine
versus
time,
origin
which
clocks
a
timestamp
at
the
start
of
the
browser,
and
it's
monotonic
from
then
on.
C
D
D
So
performance,
optimization,
plus
performance
now
will
give
us
will
give
us
a
something-
that's
well
defined
in
terms
of
the
terms
of
performance
interface,
and
it
will
give
us
a
number
that
it's
convenient
for
logging
like
it
like.
It
was
a
task
type
right,
yes,
good,
because
it
should
be
used
to
say
in
same
the
same
thing,
four
steps.
D
G
B
D
H
Looking
for
the
mute
button,
okay,
so
this
is
a
issue
that
we
adopted
from
the
media
capture
main
spec
and
I-
think
it
was
Joanne
who
originally
brought
this
up.
It
was
implementing
for
Safari,
so
it's
really
about
sending
what
the
frame
rate
of
the
blackness
could
be
and
he
discovered
that
a
Chrome
and
Firefox
were
a
duration.
Different
approaches
on
this
and
I
was
looking
through
the
TPAC
minutes
and
a
foreign
elements.
We
decided
that
we
should
advise
in
the
spec.
H
With
that
approach,
and
then
I
found
one
piece
of
text
in
this
back
right
now,
will
we
say
that
if
a
track
is
ended
or
or
muted
it,
she
says
the
silence
or
a
black
frame
in
the
real
case,
so
that
would
be
in
the
spec.
We
actually
have
text
obsessed
if
we
should
only
send
one
at
least
that's
how
I
interpreted,
but.
H
Since
we
became
to
the
conclusion
at
CPAC
that
we
should
keep
the
attract
kind
of
sending
frames,
periodically,
I
think
this
text
that
I've
pasted
here
the
current
inspector
would
update
that
one
or
another
question:
do
we
in
the
case?
Should
we
have
a
different
scenario
when,
when
the
track
is
ended
or
when
it's
used
it
or
disabled,
like
it
to
resend
only
one
frame
when
it's
ended,
or
should
we
send
one
frame,
the
second
when
you're
disabled
or
should
should
that
be
the
same?
C
Two
points
on
that:
what
one
is
that
I
think
we
discussed
a
TPACK,
the
idea
of
sending
one
frame,
and
the
objection
was
what,
if
we
miss
that
frame,
I
would
agreed
Lucetta,
brain,
and
the
second
thing
is
some
background
here.
Just
to
clarify
that
muted
me
means
different
things
now
and
remotely,
so
they
seem
you
to
track
locally
and
I
think
it's
actually
not
muted
remotely.
So
it's
still
active,
however,
if
you
replace
track
null
that
that
actually
stops
sending,
which
is
considered
muted
remotely.
So
it's
a
bit
confusing
because
to
keep
that
yeah.
H
B
The
you
know,
my
opinion
is
that
you
know
certainly
on
ended.
We
should
not
continue
to
be
sending
video,
so
a
single
back
black
frame.
It
would
be
fine
at
that
point,
or
even
not
the
WoW
one
frame,
the
advantage
of
one
frame
per
second,
in
a
case
where
you've,
disabled
or
whatever
or
muted,
depending
on
your
definition
of
mute,
the
advantage
there
would
be
in
a
conference
situation
where
someone
joins
is
that
they
would
eventually
they
would
get
a
black
frame
from
you
and
those
two
not
getting
anything.
B
C
Here's
the
problem
with
that,
though,
and
what
I
just
said,
is
that
when
your
minor
track
is
either
muted
locally
or
even
ends
that
only
really
pauses
a
remote
track,
because
it's
a
mute
because
you
can
still
use
a
place
track
to
to
add
a
different
track
and
which
remotely
would
look
like
thanks
for
picking
back
up
again,
so
it's
still
being
kept
alive
in
a
way.
So
that's
Jim!
That's
what
the
argument
to
sending
a
frame
per
second
I
guess
so
so.
H
E
Keeps
the
net
binding
open
but
you're
talking
to
plays
it
into
a
traditional
imagery.
That's
trying
to
track
wind
participants,
it
just
falls
off
the
world.
They
will
detect
it
as
a
disconnect.
If
you
don't
continue
sending
video
right
at
least
it's
some
periodic
level,
so
I
mean
I'm,
not
arguing
strongly
that
this
really
matters,
and
maybe
this
will
just
break
those
people
but
I
we
for
a
long
time
said
you
should
keep
sending
video
and
remember
a
black
frame
tapes.
Absolutely
no
bandwidth
there.
So
Seattle.
H
B
H
C
I
C
So
this
is
there.
She
was
raised
the
early
to
issues
is
that
browsers,
for
instance,
Chrome
and
Firefox
implement
well
their
first
issues
that
the
constraints
API
excuse
me.
It
doesn't
have
any
defaults
built
into
it.
It's
sort
of
designed
to
unperceived
AFOL
to
implementation
by
externalizing
requirements
to
the
request
ease
at
like
requesters,
so
that
leads
to
some
incompatibility
issues
where
between
browsers
that
support,
downscaling
and
browsers
that
don't
or
browser
to
support
downscaling
but
try
to.
C
Last
TPAC,
then
Peter
Thatcher
brought
up
a
new
constraint,
which
I
think
is
a
good
solution
to
this,
because
the
constraint
model
is
basically,
if
you
care
about
something
you
need
to
constrain
it.
Otherwise,
you're
leaving
it
up
to
the
user
agent,
and
so
I
have
a
PR
here
that
adds
Peters,
resize
mode
constraint,
modulo
box
and
scale.
C
The
reason
I
didn't
add
boxing
scale
was
I
tried
to
and
to
concern
me
a
little
bit.
One
is
that
it
adds
pixels,
which
I
think
we've
previously
said.
We
should
not
do
it's
also
incompatible
with
the
constraints
algorithm,
in
that
the
search
algorithm
considers
this
pool
of
settings
dictionaries,
and
it
you
have
this
algorithm
to
find
the
fitness
distance.
C
So
if
we
had
all
these
box
and
scale
modes
in
there,
which
are
letterbox
tour,
these
would
then
compete
in
the
algorithm
with
crop
and
scale
modes
as
well
as
non
modes,
and
that
would
be
quite
unpredictable
and
desirable.
I
think
and
that
you
might
get
letterboxing
just
regularly
searching
for
if
you
don't
use
the
resize
mode
constraint
at
all
and
you
use
like
width
and
height,
you
might
get
some
letterbox
modes
if
you're,
not
careful,
because
there's
nothing
in
the
algorithm.
C
C
Also
added
a
fingerprinting
may
that
user
agents
may
disguise
concurrent
use
of
the
camera,
meaning
other
tabs
that
have
the
camera
open
by
basically
lying
and
dropping
and
down
scaling
to
mimic
native
air
solutions
in
some
instances
to
obscure
that.
Otherwise,
you
can
detect
quite
well
other
pages,
other
browsers
that
might
use
you
can
detect
its
settings
like
if
the
Facebook
views
a
certain
set
of
resolutions
more.
E
Yeah
I
don't
understand
what
you're
saying
about
the
competing
it
like.
Let's
say
we
had
some
other
modes
here:
I,
don't
really
care
too
much
what
they
are
when
they
just
all
have
fitness
distances
that
were
effectively
infinity
apart,
so
that
they
wouldn't.
If
you
set
one
of
them,
it
wouldn't
really
compete
or
I.
Guess
I'm,
not
following
the
argument
there
well.
C
C
E
One
that
was
okay
but
I
seems
like
we
might
want
to
attack
that
some
other
way
a
little
bit
by
defining
a
fitness
distance
for
right
or
basically
those
pixels
which
will
always
you
know
the
most
pixel.
If
we
always
if
we
defined
a
preference
for
its
most
pixels,
which
I
thought
we
did
at
one
point
in
time,
then
then
it
seems
like
it
would
solve
that
you've
always
taken
on
non
cropped
and
on
mass
travel
right
and.
C
The
other
reason
I
didn't,
that
is
that
would
be
sort
of
a
new
feature
and
currently
no
one's
implemented.
Something
like
this,
but
chrome
has
implemented
Crawford
scale
as
far
as
I
know,
and
it's
not
clear
to
me
that
that's
the
right
height
level
to
introduce
that
kind
of
formatting,
because
prop
and
scale
can
arguably
considered
virtual
cameras
versus
I've,
never
seen
a
camera.
How
pathetic
comes
with
leather,
but
letterboxing
built-in.
C
C
E
E
C
You
don't
you
leave
it
up
to
the
UA,
so
the
last
thing
I
changed
was
the
sentence.
Sse
you
I
should
use
one
with
a
smallest
fitness
distance
as
calculated
in
step
three,
which
was
a
concern
from
the
original
issue
about
what
the
default
should
be
and
then
I
added,
but
may
prefer
one
switch
resize
mode
set
to
none
over
crop
and
scale
as
a
way
to
allow
browsers
like
Firefox
to
have
any
different
default.
I
mean
the
road
isn't
really
that
strong
anyway,
but
it
goes
to.
F
E
C
Up
well,
that's
that's
all
that
you
say
that,
because
why
would
you
come
up
with
the
constraints
algorithm,
the
external
Isis,
all
requests,
which
basically
says
the
UI
can
do
whatever
it
wants
within
the
constraints
that
have
been
given
so
there
it's
inherently
no
default
in
that
in
that
design?
Is
the
problem
so
so
yeah
for
background?
What
we're
thinking
of
doing
and
Firefox
for
downscaling,
which
is
a
features
are
coming
up
for
us,
is
to
I.
C
If
you
use
min
max
an
ideal,
your
easing
your
specifying
a
range
and
you're
saying
I
want
something
within
this
range,
but
without
ideal
you
have
no
way
you're,
saying
I
prefer
the
higher
end
of
this
range
or
the
lower
end
of
this
range,
for
instance.
So
as
a
search
function,
it's
you
full
to
not
have
the
fault
be
well
now
that
we
have
a
carbon
scale.
I
guess
you
can
specify
with
constraints
so
there's
some
more
leeway
of
what
the
default
should
be
so.
D
C
The
writing
problem
here.
If
there
is
a
browser
that
does
not
support
down
scaling,
it's
going
to
be
behaved
very
differently
from
any
of
the
processes
do
and
the
constraints
algorithms
seem
to
be
designed
to
to
let
JavaScript
to
prepare
JavaScript
that
that
can
happen.
But
if
we
end
up
having
the
defaults
always
be,
you
always
get
what
you
want
effectively.
No
one
will
be
prepared
for
such
a
browser.
If
we
think
that's
a
problem.
D
C
So,
being
a
constraint
would
mean
you
could
get
the
settings
where
to
know
whether
this
is
a
resize
mode
or
not,
and
the
other
thing
is
before
you
even
call
getusermedia,
you
can
call
get
capabilities
to
learn
if
the
browser
supports
downscaling
or
not
by
whether
the
sequence
contains
both
none
and
Karpin
scale
or
whether
it
just
contains
none.
It
has
to
get
so.
The
spec
also
says
it
has
to
contend.
C
None
I
think
they
can
edit
that
somewhere,
and
so
our
current
thinking,
Firefox
we're
going
to
experiment
with,
is
to
only
downscale
when
we're
forced
to
so.
If
you
specified
just
a
plain
value
that
would
not
carry
if
you
just
specify
the
plain
value
and
did
not
put
every
size
preference,
we
would
still
look
for
a
good,
the
closest
Nigam
mode,
and
but
if
you
forced
it
with
the
max
or
X
act,
we
would
down
scale
or
over
failing
with
over
constrain
there.
A
C
Think
this
isn't
really
so
much.
This
is
about
offering
up
camera
modes.
You
might
expect
from
some
devices
that
not
all
devices
have
I
think
so,
rather
than
a
full-fledged
crop
and
scale
and
box
type
graphics
tool.
That's
also
why
I
think
we
should
keep
the
names
of
these
things
far
away
from
the
CSS
ones
which
have
similar
meaning
but
are
applied
differently
in
there
you're
talking
about
how
do
I
fit
something
in
an
existing
container
and
in
the
area
or
can
also
scale
up,
which
we
don't
do
here
so.
C
C
I
think
it
matters
more
there
in
that
a
peer
connection
takes
an
existing
source
that
you
might
have
some
expectations
about.
What
should
look
like
and
if
you
look
into
it
here,
we're
getting
a
source
and
a
browser
can
manufacture
virtual
sources
to
its
delight
that
are
either
useful
or
not
useful
and
hopefully
they're
all
useful.
C
C
This
basically
stems
from
this
seems
to
be
two
uses
of
get
stats
and
one
is
live
operational
feedback
where
you
might
use
this
to
detect
it's
the
call
going
well
do
we
need
to
do
something
and
the
other
one
is
accounting
and
that's
sort
of
married
in
different
implementations
seem
to
have
three
points
over
how
this
should
be
implemented.
So
fire
Parks
reports,
snapshots
of
live
objects
that
exist
at
that
time.
C
C
This
boolean
object
deleted
that
moved
to
the
base
class
of
all
stats,
which
means
that
the
stats
can
can
might
be
obsolete
or
be
stale
records,
basically
of
things
too,
in
order
to
track
what
happened,
including
the
last
byte
that
was
sent
for
some
track,
that
was
removed
or
transceiver
those
stopped,
and
it
also
this
complicates
the
API
for
part
for
parsing.
It
I
think
and
also
slows
it
down.
Well,
the
one
concern
is
that
the
ball
of
data
can
grow
over
time.
C
It
also
puts
into
question
the
data
you
find
it
makes
it
harder.
Every
time
you
look
at
piece
of
data,
I
have
to
check
this
boolean
to
see.
Am
I
looking
at
the
right
record?
Is
this
a
live
track,
or
is
this
a
earlier
version
of
the
same
track
that
was
removed
and
riad
'add
and
is
now
a
stale
data
and
what
move
I
could
tell
that
from
the
timestamp?
So
all
these
stuff,
it
becomes
harder
to
naively
look
at
the
stats
for
sure.
C
C
That
would
be
not
only
takes
a
little
more
time
to
an
implementation
to
return,
but
all
for
the
JavaScript
to
to
wade
through
it's
a
repeated
removed
track,
add
track,
would
accumulate,
transceivers
and
related
stats
repeated,
send
a
replace
traffic,
for
instance,
you're
flipping
between
cameras,
front
or
back
on
a
phone
or
security
cameras
on
a
some
kind
of
panel
that
accumulates
track.
Stats,
even
flipping
between
the
same
tracks
back
and
forth
would
create
accumulate
tracks
that
object,
everytime
and
frequent
Isis
restarts
could
also
accumulate
old
ice
candidates.
C
So
I
have
a
SPECT
length,
the
in
the
spec.
It
says
two
things
that
are,
but
there's
always
been
this
line,
that
this
basic
statistics
model
is
that
the
browser
maintains
the
set
of
statistics
referenced
by
a
selector
that
is
sent
or
received
by
the
receiving
by
the
peer
connection,
which
I
guess
is
how
Firefox
interpreted
its
implementation.
So
next
slide.
If
we
have
time
one
proposal
was
we,
then
an
eco,
green
bomb
and
I
came
up
with
was
to
emit.
C
D
D
A
J
K
A
J
So
I'd
like
to
do
the
breath
of
this
first,
so
I'll
try
and
go
really
fast
and
then,
if
there's
something
and
then
come
back
to
the
things
that
we
want
to
talk
about
in
the
priority
order
of
like
most
important
thing
first.
So
when
you're
listening,
please
like
make
a
note
like
I
want
to
come
back
to
a
certain
topic
and
then
we
can
come
back
to
it.
So
I'm
going
to
try
and
go
really
quickly
so
spring
up
a
quick
at
TPAC.
J
We
decided
to
make
an
extension
spec
and
then
decide
if
we'd
like
it.
So
we
did.
Those
are
the
links.
The
general
approach
go
to.
The
next
slide
is
that
we
we're
adding
a
quick
transport
object
which
you
construct
from
a
nice
transport
we'll
get
to
guys
transport
later,
and
then
you
can
create
an
outgoing,
quick
stream
with
they
create
stream
method,
and
then
you
get
an
incoming
quick
stream
from
a
dot
on
stream
method.
Once
you
have
a
quick
struggle,
you
read
from
them
and
write
to
them
using
they.
E
J
There
are
a
number
of
issues
raised
on
the
list,
so
I'll
just
go
quickly
through
each
one
of
these
next
slide.
One
is
whether
we
should
use
sort,
Carter,
I,
think
that'll
come
up
in
the
Charter
discussion
later,
but
I
thought
I'd
just
point
out
here.
Next
slide,
there
was
some
question
of
whether
SCTP
was
sufficient
or
whether
quick
had
good
reasons.
I
pointed
out
a
few
of
them
on
the
list
we
can
come
back
to.
J
This
is
probably
that
we
might
discuss,
but
it's
worth
pointing
out
if
it's
something
that
we
can
discuss
it
once
we've
gone
through
the
breadth
of
this
next
slide,
another
one,
that's
more
pertinent
to
the
actual
design
in
the
specification.
Probably
the
biggest
thing.
That
is
a
question
mark
of
what
the
API
should
look
like
is
how
we
relate
to
what
WD
streams.
J
J
Another
question
was
whether
we
have
nor
unadorned
quick,
which
is
to
say
that
you
have
raw
quick
streams
and
nothing
on
top
of
them.
I
think
that
that's
actually
with
great
benefit,
so
that
vector
provides
the
maximum
flexibility
of
JavaScript.
J
But
Martin
Thompson
didn't
point
out
that
quick
has
this
problem
where,
if
you
want
to
do
two
different
protocols
on
top
of
quick,
that
both
use
lots
of
quick
streams
or
more
particular
quick
stream,
IDs
and
there's
overlap
between
them,
there's
no
way
to
segregate
the
different
quick
streams
to
know
summer
for
one
protocol
and
summer
for
another.
So,
for
example,
if
we
did
data
channel
protocol,
but
then
another
protocol
that
was
like
a
replacement
for
RTP,
how
did
the
quick
streams
overlap
and
right
now,
there's
no
way
to
go.
J
Do
that
and
quick
other
than
to
have
two
different,
quick
connection
IDs,
so
I
really
think
that
if
this
resolved
in
a
generic
fashion,
we
could
integrate
it
into
the
API.
But
it's
not
solved
in
a
current
in
a
generic
fashion
and
I
have
something
I
could
propose
in
the
quick
written
group.
But
it
is
an
open
question
of
how
you
can
do
more
than
one
protocol
within
the
same
quick
connection
and.
F
J
J
Martin,
there's
more
there's
a
lot
more
nuance
or
detail
to
that
topic.
That
I
didn't
cover
because
I'm
kind
of
go
quickly
here,
but
it
is
something
that
we
can
discuss
so
another
one
at
Martin
brought
up
was
a
OPN
which
is
basically
this
value.
That
goes
in
the
client,
hello.
That
says
what
application
protocol
are
you
doing
and
question
is
who
decides
what
application
protocol
you're
doing
on
top
of
quick
and
Martin's
proposal
was
to
let
the
JavaScript
side
and
I
think
that's
that's
a
good
way
to
go
next
slide.
J
There's
question
about
unidirectional
or
bi-directional
streams.
Basically,
when
we
made
the
API,
there
were
no
unidirectional
screams,
and
now
there
are
within
quick
and
I
think
we
can
update
the
API
to
allow
for
both
unidirectional
and
bi-directional
without
major
changes,
depending
on
how
we
go
leaning
more
towards
bi-directional
or
leaning,
more
towards
being
a
directional.
But
it's
something
that
we
could.
It
was
a
follow
up.
We
decided
to
do
this
work
in
the
first
place.
J
J
So
that's
all
about
quick
I
would
like
to
go
through
the
eye
stuff.
Before
we
again,
I
would
like
to
go
through
the
breath
before
we
go
into
depth
about
the
things
that
are
most
important,
so
same
story
for
ice.
We
decided
we
want
to
do
an
extension
spec
and
then
decide
if
we
want
to
proceed
so
we
have
put
those
in
the
github
blanks
there
next
slide.
J
The
basic
approach
is
we're
not
adding
a
new
object.
We
have
an
existing
ice
transport,
but
we
are
extending
it
mainly
with
three
methods
want
to
cuddle
structure.
So
you
don't
need
a
peer
connection
to
make
one
another
one
to
gather
candidates
and
a
third
one
to
start,
which
means
to
be
the
parent
and
it's
actually
reflecting
the
person
itself
and
I
think
it
does
there's
also
on
local
candidate,
which
is
like
a
peer
connection
on
the
prize
candidates
and
add
remote
community
like
typically.
J
J
J
Think
that
it's
better
to
require.
You
call
gather
because
it
encourages
you
to
trickle
ice
rather
than
the
resident
reverse,
but
that's
a
question
we
decided,
which
one's
better
next
slide
related
to
that
our
ice
B
starts
again.
You
need
to
call
close,
because
you
need
to
change
the
local
defrag
and
password
remote
dragon
passwords.
The
remote
one
comes
from
Stark
oops
I
have
a
typo
notice,
as
we
start
essentially
start
and
the
local
one
comes
from
a
call
together.
J
There
are.
There
is
a
case
where
you
would
like
to
gather
more
candidates,
but
not
change
the
local
you
fraggin
password
not
do
a
nice
restart,
for
example,
adding
turn
servers
like
you
can
with
your
connections,
upset
configuration,
so
we
might
need
a
variant
of
gather
that
does
not,
or
you
might
call
it.
You
know
sight
gathering
policy,
something
like
that.
I
think
it's
more
straightforward
to
call
it
gather,
but
have
maybe
a
pool
you
pass
in
or
local
you
pregnant
password
next
slide.
J
Then
this
question
of
stats,
whether
each
object
has
its
own
staff,
so
like
a
noise
transport
has
good
fats
and
a
big
transport
eyes,
get
that
or
whether
there's
like
one
giant
stats
collector.
Were
you
passing
all
the
objects
you
want
stats
about?
We
have
to
decide
which
one
that's
something
we
came
back
to
next
slide.
J
Finally,
I
wanted
to
point
out
that
colon
had
proposed
an
idea,
T
PAC,
about
doing
more
low-level
ice
control
from
from
JavaScript
plant
or
provide
low-level
ice
control
from
the
browser,
and
then
JavaScript
land
can
do
more
of
the
ice
brains
of
the
operation.
More
of
the
iced
agent
implementation.
So
I
give
this
the
name,
slice
for
simple
level
ice
and
I
and
I
wanted
to
just
briefly
point
out
that
it
is
possible.
I
think
that
this
is
an
alternative
that
we
can
consider
so
real,
quick
next
slide.
J
Basically,
Cohen's
idea
is
that
if
you
have
an
ice
agent
with
all
these
things
below
that
do
like
network
enumeration
and
meeting
for
its
season
before
it's
done,
turn
ice
checks,
gathering,
pairing
timing,
etc.
Right
now,
the
line
between
the
application
and
the
ice
agent
is
like
polarization
is
in
the
browser
and
AB
napkin
uses
it
next
slide.
So
clones
idea
is
to
basically
move
this
line
down
a
notch
where
the.
J
Does
a
lot
of
the
gathering
and
the
pairing
and
the
timing
of
the
text
and
so
forth,
but
the
low-level
components
allow
you
to
allocate
UDP
imports,
TCP
ports
done
ports
or
get
stun
addresses,
allocate
turn
ports
and
then
do
I
stick.
So
the
idea
is:
can
we
expose
those
pieces
within
the
JavaScript
and
I
think
we
can
so
I'll
try
and
explain
how
that
works
in
the
later
next
slide?
J
J
This
is
basically
how
it
would
work.
There
are
a
number
of
steps
which
are
basically
implementing
ice.
The
advantage
is
that
the
JavaScript
can
control
when
and
how
these
things
are
done,
which
allows
it
a
lot
more
flexibility.
You
know,
if
you're
interested
in
in
the
details
of
this,
we
can
go
through
it,
but
that's
only
if
you
think
it's
the
most
important
thing
to
come
back
to
next
slide.
J
J
Next
slide
and
then
this
whole
thing
put
together,
which
I
think
really
is
a
good
idea
and
is
possible
to
do,
would
allow
a
lot
of
advantage.
Is
the
app
like
be
able
to
do
things
such
as
turn,
first
control
over
Wi-Fi
or
cell
usage?
Do
continual
gathering
or
make
changes
without
restarts,
have
long
live
candidates
or
backup
candidate
payers
do
variable.
Tech
rates
do
TLS
host
candidates,
which
is
something
people
want
and
maybe
even
do
parallel
forking,
which
there's
no
way
to
do.
Obviously
right
now.
C
J
Do
and
I
want
to
hear
back
from
everybody
else
about
like
what
are
the
important
things
that
we
think
it
needs
discuss
tried
to
pick
something.
Maybe
it
would
be
some
of
the
details
of
quick
around
what
WD
streams
and
unadorned
quick
and
also
the
whether
we
think
slices
were
looking
into
further,
but
how.
J
J
J
Congestion
control,
except
in
the
case
of
ice,
where
you
still
have
throttling,
which
is
part
of
the
I
spec
so
really
just
becomes
a
question
though,
and
you
how
many
ports
can
you
open,
of
course,
in
network
enumeration
would
be
blocked
behind
a
permission
just
like
it
is
now.
But
the
question
of
how
many
ports
you
can
create
is
really
what
it
is,
and
already
I
mean
we
can
put
a
limit
on
there,
but
that's
already.
J
K
K
But
the
quick
thing
is
certainly
something
that
I
know
about
and
I'm
a
little
concerned
where
we're
getting
ahead
of
ourselves
in
the
sense
that
there's
a
lot
of
things
in
quick
that
are
still
changing,
I
hope
the
things
that
affect
the
API
aren't
changing,
but
we're
not
quite
at
that
point
yet
I,
don't
think
quick
side.
So
anything.
E
K
K
How
do
we
use
it
and
if
you
wanted
to
use
it
first
through
other
use
cases,
then
you've
got
a
pretty
long
road
before
you
actually
get
to
the
point
where
you
can
use
it
to
the
point
that
you
find
out
about
these
things
so
princess,
if
you
want
to
do
RTP
on
quick,
I
suspect,
it's
probably
not
going
to
work,
especially
well
with
quick
in
its
current
form,
so
I
expected
to
I
will
probably
reject
those
requirements.
At
this
point.
J
Well,
I
think
maybe
the
discussions
we've
already
had
or
proof
that
talking
about
this
early
on
does
help
the
discussion
within
the
quick
working
group
I
mean,
or
at
least
the
discussion
around
quick.
You
know:
we've
already
brought
up
the
demultiplexing
thing,
and
now
we
you've
brought
up
the
thing
about
having
multiple
protocols.
There
was
this
whole
quick
connection,
so
those.
K
It's
also
the
case
that
the
quick
working
group
has
explicitly
decided
not
to
address
use
cases
outside
of
its
call
1,
and
so,
while
we're
quite
happy
to
engage
on
these
things
to
it
to
a
degree,
we
do
have
a
primary
focus
which
is
getting
HTTP
working.
So
we
have
to
be
careful
that
we
balance
those
needs
and
all
aware
of
where
quicks
going,
at
least
in
the
short
term,
right.
J
K
Full-
and
we
also
need
to
remember
that
quick
is
not
just
one
thing.
Ultimately,
we
will
come
back
to
use
cases
like
the
RTP
of
a
quick
and
quick
chord
change
as
a
result,
and
so
one
thing
that
I
didn't
put
in
my
review
that
I
forgot
was
quick.
Has
this
notion
of
version
negotiation
and
that's
something
that
the
API
might
want
to
expose
because,
for
instance,
there
will
be
different
features
available
in
different
versions,
quick.
E
So
I
think
this
really
highlights
that
important
part
of
this
conversation
would
be
that
what
are
the
advantages
to
doing
it,
quick
eisah
on
all
these
things,
but
let's
let
me
just
focus
on
quick
for
a
second.
What
do
we
get
if
we
did
all
this
stuff
with
quick
that
we
can't
currently
do
with
data
challenge
or
something
I
think
as
we
get
crisper
on?
Why
it
is
we
want
to
do
that?
It'll
suddenly
become
clearer
about
how
much
we
need
to
drive
this
now
versus
later
by.
K
E
Right
well,
I
wasn't
I,
wasn't
criticizing
the
the
approach
of
doing
it
generically
or
anything.
I
was
just
saying,
even
if
we're
doing
it
generically
to
be
able
to
say
crisply.
This
is
why
we're
going
to
go.
Do
this
huge
chunk
of
work,
we'll
make
it
right
much
easier
for
us
to
focus
that's
right,
yeah,
they're,
great,
ok
and
I
and
I.
Might
why
I'm
sorry
driving
that
is
I
suspect
for
me,
the
answer
comes
around
if
I
had
to
say
the
one
reason
that
made
me
interested
about
this.
E
K
E
J
J
K
K
Anthony,
potentially
talking
changes
too
too
quick.
In
order
to
get
that
to
work.
You
can
go
back
to
my
proposal
when
the
group
met
in
stock
on
many
years
ago
about
layering
consent
into
the
the
underlying
protocol.
Quick
does
have
some
concerned
mechanisms,
but
they
may
not
be
appropriate
for
peer
to
peer
use.
J
K
J
J
G
B
G
Though
I'm
thinking
about
I'm
thinking
about
the
way
that
ice,
this
is
currently
you're
right,
that
you're
not
changing
what
we're
currently
doing,
but
there's
a
school
of
thought
which,
starting
to
say
that
what
we're
currently
doing
doesn't
tie
sufficiently
back
to
origin
that
you
can
necessarily
force
be
confident
that
you're
injected
JavaScript
isn't
going
to
screw
you
up
quite
badly,
and
so
that
that's
the
kind
of
issue
that
we're
trying
to
I
think
we
should
be
trying
to
cover
off.
It's
not
an
issue
yet.
G
F
E
D
E
A
K
K
Think
the
strings
I
go
question
is
a
lot
more
fundamental
than
you're,
giving
it
credit
we
got
burned,
pretty
bad
on
the
promises
of
first
callbacks
thing
we
sort
of
committed
to
callbacks,
because
we
needed
something
working
and
promises
weren't
ready.
But
this
is
not
the
case
here.
Streams
are
ready,
they're
implemented
and
this
general
agreement
that
they're
the
right
way
to
do
these
things,
and
also
there
was
a
bug,
there's
a
bug
in
what
you
have
to
minor
one,
but
it's
it's
a
dead,
locking
bug
so.
C
K
J
So
this
is
the
question
I'd
like
to
know
we're
out
of
time,
but
I
would
like
some
free
feedback
on
if
this,
the
direction
that
all
Webber
to
see,
we
are
no
survivors.
W3C
working
groups
are
going
where
they're,
embracing
what
WG
streams
and
like
this
is.
You
know
the
new
big
way,
the
one
true
way
of
doing
I,
Oh,
basically
and
and
so
we're
we
intend
to
embrace
it.
I'm.
K
C
D
D
C
D
F
So,
as
people
know,
we
need
to
reach
out
as
a
group
to
continue.
Charter
is
up
in
and
I
guess
in
the
March.
So
we've
been
gotten
a
charter
proposal
up
on
github
a
few
of
the
changes
that
have
been
made
to
the
previous
charter,
where
the
end
date,
which
is
extended
to
the
31st
of
March
2020.
F
F
So
we've
been
having
a
bunch
of
issues
raised
on
the
list.
I
guess
one
which
we
just
chatted
about
was
the
the
nature
of
the
work
on
quick
in
particular.
Are
we
doing
some
kind
of
general
stream
API
just
trying
to
surface
an
existing
API
like
what
working
with
streams
is
to
work
just
for
quick
or
just
for
su
to
be
exactly
what
what
the
goal
is?
That's
one
set
of
questions.
F
F
E
Everything
I
heard
in
the
conversation
so
far
as
people
are
still
on.
We
could
talk
about
the
details
of
quicker
ice
that
are
very
much
on
the
fence
with
us,
even
really
the
right
time
to
be
doing
this
and
quick
and
I
so
I
mean
maybe
we're
a
little
bit
ahead
of
ourselves
on
the
Charter
here.
Maybe
we
just
need
you
know
we
need
to
have
a
meeting
to
dedicated
about
like
what
should
the
working
group
do
next
and
try
and
collect
that
episode?
E
I,
don't
have
a
real
strong
proposal,
but
I'm,
saying
I
sure
don't
see
consensus
that
there's
a
bunch
of
people
who
are
willing
to
go
do
the
amount
of
work
that
is
going
to
be
required
to
get
any
of
those
things
on
that
slide
done
and
I'm
not
saying
we
won't
get
it
I'm.
Just
saying
I
don't
see
us
there
yet.
J
G
I
mean
I,
think
I
said
this
on
on
the
list,
but
my
feeling
is
that
we
shouldn't
be
specifically
naming
quick
as
a
target.
We
should
be
saying
the
kinds
of
things
we're
trying
to
achieve
with
it
and,
and
that
allows
us
a
bit
more
time
as
Cullen
says,
to
to
allow
the
thing
to
mature
and
if
we,
if
we're
saying
that
that
we
have
the
Charter
in
in
May
in
March,
then
it's
a
lot
of
a
lot
of
hurry
unnecessarily
to
to
nail
down
some
specifics
about
quick
but
I.
G
D
K
Or
it
or
it
could
simply
a
mid
mention
of
it.
Just
like
the
last
charter
did
that
would
work
fine,
it
hasn't
stopped
people
from
working
on
it
and
I.
Don't
think
that
the
current
interaction
model
is
is
broken
in
any
way,
I
mean
the
feedback
that
this
group
has
provided
to.
The
quick
working
group
has
been
pretty
good
and
the
engagement
it's
been
reasonable,
I
hope
so.
K
F
A
F
E
E
We
could
do
whatever
right.
What
we
need
to
do
is
figure
out
what
we're
all
going
to
be
putting
a
huge
amount
of
work
into,
and
and
why
and-
and
this
is
great
I'm-
not
supportive
of
this
operators.
Doing
I
have
I'll
be
I'll,
be
encouraging
of
this,
but
when
we're
still
asking,
though,
what
it
is
that
we're
trying
to
accomplish
and
and
and
come
up
with,
some
thinking
about
what
the
dates
and
timelines
for
these
types
of
things
are,
people
are
going
to
realize.
E
That
wouldn't
you
know,
we
want
extremely
a
lot
of
reason
to
do
quick
and
it's
not
even
something
I
think
we
really
care
very
deeply
about.
We
give
a
crap
about
that
idea
to
the
most
part.
So
so
there's
got
to
be
that
the
reason
we're
discussing
this
can't
be.
We
need
a
stream
API.
So
let's
not
write
a
program,
it
says
we
need
a
stream
API.