►
From YouTube: W3C WebRTC Virtual Interim Jan 2016
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
B
B
How
to
make
a
PR
and
be
a
good
citizen,
I
mean
with
may
mean
it
right.
Then
I
mean
the
thing
that
initiated
this
was
actually
document.
The
j
said
reference
process
bits
more
because
now
you
can
actually
point
to
the
other
JJ
said
link.
You
can
actually
point
to
a
specific
section
of
days
of
so
it
came.
Jumping
it.
Jumping
between
these
presentations
is
much
easier.
I
think
that's
a
really
good
improvement
so
that
that's
documented
in
this
guide
other
than
that,
it's
just
the
Romans
common
sense
stuff.
Just.
D
So
we're
doing
a
lot
before
we
move
on
this.
Can
we
put
because
it's
so
hard
to
review
all
these
things,
particularly
refactoring
text
ones?
We
put
things
that
just
refactor
text,
but
really
change
anything
other
than
just
making
a
huge
dip.
Can
we
put
those
in
a
separate
PR
by
themselves
just
so
easier
for
everyone
to
review
yeah.
B
E
So
it
would
still
be
a
good
thing
for
people
to
start
practicing
line
wrapping
their
changes,
but
I
don't
think
we're
quite
there
yet
for
that
people
and
the
in
general
I
things
are
still
ongoing
discussions
as
to
how
where
we
can
manage
risk
line
working
stuff
why'd.
We
are
on
this
topic
as
a
heads
up
that,
hopefully,
in
the
upcoming
weeks
there
will
be
a
new
way
of
integrating
web
idea
into
the
spec
switching
from
the
existing
so-called
old
school
mode
in
respect
to
the
new
web.
Id
are
contiguous
mode,
so
obviously
I'll.
B
Yeah,
you
can
see
the
doggie
biscuit
is
very
nice,
but
I
mean
this
line
web
being
a
okay
I.
Wasn't
aware
of
that,
we're
not
enforcing
this
on
this
specification
because
I,
my
I
got
one
for
the
person.
If
we
get
user
media
one
of
us
it
and
I,
I
think
my
personal
view
is
that
I
think
doing
automatic
line.
Wrapping
will
make
the
review
process
harder
because
the
the
last
tab,
when
you
you
are
fully
first
time
on
that
combines
all
your
permits.
B
F
D
Yeah
yeah,
my
only
question
was
just
plaskon
people
to
not
know
I,
don't
at
least
put
refactoring
changes
in
separate
PRS,
but
that
would
just
be
my
request
because
it's
just
these
are
so
hard
to
review
as
it
is,
and
the
line
wrapping
as
well
Adam
points
out
makes
him
harder
to
review.
I
wasn't
commenting
on
that.
I
was
just
sort
of
saying
like
let's,
let's
keep
refactoring
things
separate
from
substantial
changes,
things
fever,
yeah.
B
Oh
Alan
go,
you
can
go
and
look
at
the
the
pr.
It's
still
it
still
it's
not
worse
yet,
but
look
at
that.
The
last
point
is
that,
like
a
factory
moving
text,
I
think
there's
some
yeah.
It
says
like
put
it
in
that
and
I
at
least
in
and
separately
or
in
a
separate
folder
festive
yeah.
What
to
tweet
that
text
a
bit
mother.
A
Look
thanks:
okay,
go
on
for
discussion
today
and
I
think
there's
an
extra
for
question
here
that
didn't
make
it
into
the
list
that
we
added
or
late
in
the
day
yesterday.
So
if
anybody
sees
something
that
might
be
missing
as
we're
moving
along
here,
please
speak
up
or
say
something
on
the
IRC
chat,
as
you
see
describe
moving
through
slides
or
if
you
see
this
light,
that
can
you
see
something
missing
key
fetish
ball.
C
B
D
So
at
the
last
interim
eating
or
not
enter
me
last
meeting
on
this
this
you
know
this
seemed
very
simple.
We
were
just
going
to
move
it
to
a
sink.
It
was
really
no
different
than
the
existing
things.
There
was
no
big
deal
and
it
wasn't
really
going
to
you
know
it
was
going
to
be
an
easy
change
was
how
it
sounded
when
we
we
did.
D
This
I
started
doing
this
and
then
Harold
raised
some
some
very
real
issues
on
this
about
timing
issues
that
we
hadn't
discussed,
I
went
back
and
listened
to
recordings,
so
I
think
there's
a
few
things
we
need
to
talk
about
here
and
Harold
might
be
better
addressed
with
me.
But
there
are
the
things
of
largely
we
do
set
parameters
by
doing
a
get
parameters
first
and
then
changing
what
we
wanted
and
in
doing
except
and
it's
setting
those.
So
if
you
had
a
couple
set
parameters
in
flight
at
the
same
time,
how
would
they
interact?
D
How
would
their
timing
you
know?
Would
they
be
queued?
Would
they
be
applied
in
order
how
their
application
apply
to
other
things
that
might
be
changing
in
the
media
staff
from
other
direction,
such
as
the
you
know,
maybe
a
a
rate
control
engine
inside
of
the
browser
trying
to
change
some
of
these
parameters
around
the
same
time
you
were
getting
and
trying
to
set
them,
so
you
know
I,
had
you
know
that?
D
That's
that's
the
premise
of
I
think
what
is
the
open
issue
that
we
need
to
sort
of
resolve
on
this
before
we
know
exactly
what
text
right
and
what
to
put
in
and
Harold.
Since
you
raised
these
issues,
let
me
just
pass
that
to
you
and
say:
do
you
want
to
say
more
about
this
and
explain
topics
or
proposals
yeah.
G
So
what
I
understood
after
separuh
and
was
that
it
was
a
desire
to
have
things
async,
because
we
might
not
be
able
to
tell
within
the
they
say
on
the
same
thread
whether
or
not
you
could
successfully
apply
Parramatta's
knots.
But
when
I
looked
at
this
from
the
users
perspective
and
the
user
kind
of
wants
to
know
that
if
it
changes
the
parameters,
then
that
paramedic
has
changed
and
they
have
escaped
main
loop.
G
Grantee
is
that
if
you
have
get
change
sets,
then
you
can
make
the
simplifying
assumption
that
not
like
nothing
happens
in
between,
but
if
you
have
get
to
change
sets
and
then
the
promised
results
there's
no
guarantee
on
what
on
what
happens
in
between
that?
You
set
the
parameters
on
promised
results
in
particular.
G
If
if
there
are
two
things
that
events
the
trigger
and
both
of
them
cause
you
to
to
do,
they
get
get
get
setting,
then
it
would
be
really
nice
to
have
consistent
behavior
and
you
won't
get
consistent
behavior
unless
you
can
describe
the
behavior
I.
Think
so
I
was
kind
of
wondering.
Is
this
so
complicated
that
to
specify
that
it's
simpler
to
just
stay
with
synchronous
tories
it
to
worth
it
going
I
think
once
what.
C
G
So
the
word
the
there
were
some
discussions
about
if
you
are
changing
the
outgoing
codec
to
a
codec
that
needs
hardware
support
and
the
hardware
has
gone
away
and
discovering
that
the
hardware's
and
for
being
used
by
someone
else
then
discovering
that
the
hardware
has
been
used
by
someone
else
might
be
impossible
to
do
this.
I'm,
not
sure,
if
that,
if
that's
something,
that's
really
an
important
you
use
case
or
whether
we
can
get
away
with
just
saying.
If
you
want
to
offer
hardware
codex,
then
hang
on
to
them.
J
Can't
help
but
think
that
at
some
point
we'll
have
parameters
that
you
can't
immediately
vet
upfront
as
whether
they're
correct
or
not-
and
maybe
not
in
this
incarnation
would
avenge
me
I.
You
know,
maybe
you
can
change
the
bit
rate
or
something
like
that
and
there
might
be
a
to
be
hit
some
value.
That's
the
code.
I
can't
satisfy
or
something.
D
Think
if
we
think
we're
going
to
eventually
get
there,
we
should
design
for
it
now,
yeah,
that's
what
I'm
thinking
and
I.
It
seemed
like
my
intuitive
sit.
I
can't
come
up
with
a
good
example
with
my
intuitive
sense
is
particularly
when
you're
talking
about
hardware
codex
on
mobile
devices
like
if
there's
no
way
you're
going
to
need
a
sink.
So.
H
G
So
it's
so
what
one
possibility,
which
is
a
mechanism
used
by
other
other
tools,
I've
seen,
is
that
when
you
do
get
parameters
you
return
as
if
generate
you
turn
a
conceptual
generation
value
so
and
when
you
set
the
parameters
and
the
generation
value
has
to
be
the
same,
that
is,
nothing
has
changed.
Nothing
else
has
changed
the
parameters
and,
if
the
and,
if
the
and
if
something
else
has
changed
the
parameters,
as
you
got
them,
then
third
parameters
fails.
Always
that
would
give
consistent,
behavior
guaranteed
I.
D
G
H
G
H
You
vote
is
there
when
you
call
get
and
then,
if
you
just
modify
the
parameters
other
than
building
it
out
of
thin
air,
then
when
you
call
said
it's
just
there
right,
if
technically
makes
building
a
thin
air
impossible,
xpm,
except
for
the
maybe
the
first
time
you
might
make
it
optional
if
there's
ten,
but
we
don't
have
a
first
time
right
now
right.
It's.
J
H
D
Well,
what
you're
proposing
their
house
I'm
in
like
that
that
would
work
and
I
don't
see
the
thin
air
problem.
I
mean
it
just
like
it.
If
there's,
if
it's
never
been
set,
and
you
caught
you
for
the.
If
you
want
to
create
something
out
of
thin
air,
you
call
up
for
the
very
first
time
you
call
get
for
the
first
time
and
it
returns
you
something
I,
don't
care
when
it
returns
u-turns
already
know,
and
but
it
gives
you
a
valid
generational
counter
and
then
you
call
set.
B
B
J
Betting
that
that's
worth
considering
as
an
alternative,
like
you
know
the
horror
codec.
Can
I
crap
out,
for
other
reasons
like
I
mean
call
or
other
things
could
fail
on
a
good
call,
exactly
that's
what
I'm
getting
at.
We
talked
about
this
a
t-back
and
decided
not
to
pursue
this
because
we
couldn't
come
up
with.
You
know
a
generic
callback
that
was.
L
L
Are
trying
to
build
essentially
transaction
mechanism
where
you
start
transaction,
do
a
set
of
updates
and
then
do
commit
and
then
commit
to
can
be
featuring.
Some
stored
away,
I
synchronous
result
which
tells
you
whether
the
whole
set
of
updates
which
you've
done
on
this
transaction
object,
succeeded
or
not,
because
that's
most
logical
what
you're
trying
to
implement
with
all
the
generations?
And
it
might
be
cleaner
from
a
user
perspective,
because
they
will
see
clear
place
where
all
the
air
codecs
are
kind
of
go
to.
J
L
C
L
G
H
D
Yes,
I
sort
of
like
how
much
differential
approach
better
that
in
that
I
think
it
might
be.
I
can
imagine
writing
code
that
didn't
involve
offer
answer
at
all.
I
went
over
Just
Cause
different
parts
of
your
program,
all
we're
selling
different
parameters
for
different
reasons
and
that
okay,
it
effectively
at
the
same
time,
you
might
call
this
more
than
once
in
sort
of
weird.
You
know
in
edge
cases.
J
J
G
D
So
just
an
alternate
design
you're
thinking
about
here
is
when
you
call
set
parameters,
it
synchronously
right
then,
and
there
decides
or
well.
If
there's
already,
if
there's
already
a
set
parameters,
I
promised
cued
and
running
or
going
to
run,
then
it
just
instantly
fails
or
ignore
the
instantly
part.
It
fails.
That's
what's.
H
G
A
H
Said
just
be
clear:
we're
going
to
go
ahead
and
try
and
do
is
return,
a
promise.
It
resolves
when
it's
done.
If
you
try
and
set
it
again,
while
the
promise
is
unresolved,
you
fail
and
if
you
get
parameters,
while
it's
unresolved,
you
get
the
previous
one,
not
the
one
that
you
had
just
said
that
crib.
J
Right
I
mean
yeah
and
infra
if
he
thought
that
was
important
together
call
set
multiple
times
without
waiting,
we
could
have
them
stack
the
same
way
that,
like
you
know,
we
have
the
cue
for
the
operations
but
like
yeah,
exactly
okay,
until
something
makes
the
case.
For
that
kind,
pleased
to
say
Jim
example:
we.
D
M
C
So
this,
hopefully,
should
be
quick.
Basically,
there
is
a
proposal
to
add
the
ability
to
access
the
V
flag.
In
addition
to
the
audio
level,
this
is
only
available
in
the
client
mixer
header
extension,
not
mix
for
client.
So
the
use
case
is
basically,
if
you
have
a
peer-to-peer
kind
of
conference,
application
could
show
which
peers
have
voice
activity,
and
so
basically,
it's
just
a
read-only
attribute
of
a
boolean
with
the
V
flag.
But
that's
that's
what
the
pull
request
is
we're
asking
people
think
this
is
a
reasonable
thing
or
not.
Oops.
F
C
So
the
V
flag
is
there
in
client
mixer
to
indicate
if,
if
the
client
believes
there
is
voice
activity,
and
so
it's
set
when
in
theory,
somebody
is
generating
voice,
and
so
you
could,
you
know
it's
only
useful
for
peer-to-peer.
So
if
you
have
pewter
pier
and
somebody
is
this
flag
is
set,
you
can
have
some
UI
or
something
which
shows
that
they're
talking,
but
that
particular
participant
that
was
Michael.
C
N
N
J
J
That
you
know
there
may
be
a
pitch
predictor.
Something
else
has
thought
that
there's
actually
speech
rather
than
noise,
so
I
guess
that
was
dance,
yeah
question,
okay,
yeah
I
mean
we
talked
about
this
at
the
internet
into
pack
and
we
said
not
to
do
it
because
it
doesn't
get
sent
down
for
mixers
to
the
Klan
rally,
and-
and
this
is
the
case
where
it's
peter
pier-
and
I
guess
I
could
see
you
know
some
value
here.
I
guess
seems
like
it's
a
very
dad's
me.
C
H
J
Oh
you
to
put
it
but
I
guess.
The
other
root
problem,
though,
seems,
though,
that
like
you're
going
to
have
access
to
the
actual
bitstream
anyway
it
where
the
mixer
doesn't
so.
The
mixer
needs
like
this
flag,
but
the
the
clients
going
to
play
this
out,
what
I've
access
to
the
actual
audio
stream,
and
so
it
can
do
a
much
more
nuanced
inspection
of
what
the
stream
has.
Rather
than
just
this
big
yeah.
C
J
F
D
C
J
Q
C
C
D
O
D
Look
at
the
moment
I
like
that
better
than
it's
it's
it's!
It's
not
that
there's
a
trinary
value
right,
but
I
don't
false
when
you
have
that
equals
off!
That's
what
I
don't
like
you.
J
G
H
Your
fighter-
yes,
basically
I,
added
it
according
to
how
we
specified
at
tpac
basically
makes
the
next
great
offer
great
answer:
change
the
direction
on
the
m9.
It
looks
like
I
didn't
quite
get
the
right
text
for
saying
that
can
trigger
on
negotiate
needed,
so
Harold
I
think
is
correct,
that
it
should
say
it
will
set.
The
flag
saw
fix
that
so.
A
H
Yeah
so
I
went
to
add
the
some
text
around
what
happens
to
the
mid
of
the
transceiver
uncontrolled
back,
and
somebody
had
already
made
the
mid
nola
bowl
and
put
in
some
text
about
the
fact
that
it
can
go
from
knowable
to
not
according
to
Joseph
rules.
So
I
just
made
it
a
little
more
explicit
that
in
the
in
the
rollback
section
that
this
will
happen
during
a
rollback
and
I
also
put
in
a
J
set
by
e
2.2.
It
wasn't
there
yet.
So
it's
just
a
slightly
more
explicit
from
what
was
already
there.
A
C
Ok,
so
the
issue
here
was
that
Jessup
had
a
public
value
and
didn't
describe
none
and
the
spec
had
none
as
an
RTC
eyes,
transport
policy.
So
what
we
did
was
to
substitute
public
for
none
and
that
raised
some
concerns
about
backward
compatibility
like
existing
browsers,
had
none
and
what
would
happen
there,
as
well
as
future
extensibility
like
if
we're
going
to
add
additional
values.
C
So
Harold
raised
the
question
of
whether
having
RTC
ice
transport
policy
as
an
enum
was
such
a
great
idea
to
begin
with,
and
whether
we
should
either
change
that
or
some
new
thing
to
be
a
dom
string
instead.
So
just
raising
this
to
allow
people
to
express
any
concerns
about
this
change
possible
issues
and
also
to
talk
about
what
we
ought
to
do
about
the
transfer
policies.
I.
G
See
that
the
neva
just
joined
these,
probably
the
expert
on
compatibility
problems
it
well.
C
G
C
J
I,
don't
that
will
cause
us
any
serious
problems,
I'm
just
thinking
about
whether
whether
we
want
to
keep
public
in
jsf
going
forward
now
that
this,
this
overall
issue
has
but
has
been
sort
of
handled
it
like,
but
directly
by
the
new
IP
handling
document,
write
that
kind
of
a
senator
browse
our
control,
rather
than
under
application
control,
which
is
really
what
you
want.
Mm-Hmm
so
make
long
story
short
I'm,
not
sure
I
would
be
on
board
with
the
sort
of
migration
of
the
e
gnomes
as
specified
here
in
the
slide.
G
D
No
yeah
a
nuns
are
broken
in
web
ideal.
Okay,
there
will
be
a
high
better
all
right.
So
maybe
that's
the
answer.
Enums
are
broken.
What
about
you
yeah
so
I
mean
I.
Think
there
should
be
a
string
quite
clearly.
I
think
that's
completely
I
thought
agreed
to
do
that
long
ago
to
replace
all
the
enums
that
were
possibly
extensible
with
what
I
thought
this
was
on
the
list,
but
maybe
not,
but
I
I
get
and
I.
Think
it
totally
into
a
totally
separate
question
is
Justin's
issue
which
is
like
hey.
D
R
This
is
a
yawn
of
our
just
want
to
clarify
the
web
ideal
problem.
If
we
do
want
an
error,
we
can
use
an
enum.
Is
you
actually
get
a
typeerror
automatically,
so
you
think
reasons
to
use
a
string
would
be
if
you
did
not
want
all
the
browser
to
choke
on
a
new
setting,
if
that
makes
sense,
but
you
have
no
choice
because
it's
the
the
web
idea
binding
code
would
fail
the
dictionary
quite
early
on.
R
If
that's
what
you
want,
you
can
using
them.
Thats
came
up
with
constraints,
but
because,
with
constraints
we
had
this
when
you
use
the
old
terminology
mandatory
and
optional,
and
for
mandatory
an
enum
failing
was
great,
but
for
optional
having
it
failed
with
bad.
That's
why
we
went
to
string
there.
J
J
D
I
think
you
guys
still
end
up
in
the
situation
when
you
start
figuring
out
how
to
do
extensibility
into
the
future.
Let's
say
you
make.
We
have
a
new
type
of
sub
type
of
relay,
read
ly
it
relays
and
green
realize
right
and
you
want
to
say
you're
going
to
end
up
into
that
preference
list.
Sort
of
thing
where
you
say:
I
want
red
relays.
But
if
you
don't
know
what
that
means,
just
give
me
relays
you're
going
to
put
you
know,
read
real
a
comma,
real,
a
type
thing
or
something
like
that.
D
J
C
J
J
C
H
C
C
R
B
J
M
J
You
know
surfaced
or
used
for
checking
or
anything
like
that.
It's
not
just
the
gathering.
It's
the
actual
communication
to
the
application.
I
think
that
was
a
concern.
I
and
I.
Maybe
now's,
not
the
right
forum
for
this,
but
I
think
that
if
somebody
wants
to
keep
none,
let's
hear
like
some
rationale
for
it:
the
main
ones
that
I
think
people.
You
know
we
need
our
relay
and
all
it's
not
quite
clear
what
else
ask
your
big
sensor
for
enough.
Ok,.
J
H
Right
so
I
added
a
comment
to
the
discussion,
which
is
basically
in
order
to
see
the
ice.
Transport
does
have
a
close
method.
That's
how
you
stop
a
nice
transport
and
it
goes
into
a
closed
state,
something
like
that's
not
in
Weber
DC,
because
you
don't
close
the
next
transport
directly,
you
let
the
pure
connection.
Do
it
so
I
think
after
you,
close
a
peer
connection
still
make
sense
for
the
ice
transport
below
to
have
a
closed
state.
R
Yeah
I'm
sorry,
this
was
the
issue.
Where
should
we
have
a
state?
That's
closed?
Oh
that
dis
reminded
me.
Maybe
this
is
not
the
right
time.
There
was
another
issue
about
where
the
peer
connection
itself
closes
itself
and
trying
to
think
of
this
issue.
It's
hard
before
we'd
sort
of
figured
out.
If
a
pic
condition
can
close
itself
or
not
I
mean
if
it
can
close
itself,
it
sounds
like
having
a
state,
so
the
user
can
know.
R
B
H
H
G
H
N
H
K
H
H
G
G
A
C
Hey
so
a
tpac
there
was
consensus
for
a
frame
rate,
knob
and
I.
Guess
I
believe
that
those
one
of
it
was
one
or
two
knobs
and
or
the
one
knob
was
max
frame
rate
and
the
other
knob
was
scale
frame
rate
down
by
is
that
accurate
was
a
discussion
of
yet
another
knob
or
though
it's
just
the
Queen
option.
C
You
have
to
discuss
I,
think
it's
just
too
okay,
so
Harrell
then
had
a
consensus
call
produced
only
one
response,
but
if
you
a
bunch
of
questions,
so
I
think
the
difference
between
these
two
knobs
is
scale
frame
rate
down
by
produces
simulcasts,
always
producing
simulcast
dreams
with
different
frame
rates,
because
they're
always
in
the
relationship
of
the
scale
down,
whereas
max
frame
it
produces
streams
always
below
a
maximum
frame
rate.
But
it's
possible.
C
So
maybe
to
help
describe
help
us
figure
out
which
one
of
these
are
both
we
want
here
are
two
use
cases.
One
use
case,
which
I
think
has
been
discussed
on
the
list
is
like
a
screen
sharing
conference
where
you're
trying
to
get
the
screen
shared
of
both
like
a
pc
at
a
mobile
device
which
have
different
screen
sizes
and
maximum
frame
rates.
C
You
could
use
scale
resolution
down
bay
to
generate
the
streams
with
the
different
resolutions,
and
then
you
use
max
frame
rate
to
generate
streams
within
the
device
maximum
frame
rate,
so
the
pc
could,
for
example,
get
the
full
resolution,
so
the
max
frame
rate
of
thirty
and
the
mobile
would
get
scale
resolution
down
by
two.
So
you
decrease
the
width
and
height
by
two
and
a
maximum
frame
rate
of
15.
In
this
particular
case,
it's
possible.
The
frame
rates
would
converge,
but
overall
islamic
s
would
not
would
never
be
the
same,
because
the
resolutions.
C
So
that's
that's
I
think
one
case
that's
been
made
for
for
max
frame
rate,
another
one
which
might
be
where
this
the
scale
frame
rate
down
by
might
be
useful.
As
just
a
video
conference
with
a
speaker
stream
and
thumbnails,
where
the
speaker,
the
single
speaker,
would
get
the
full
resolution
and
the
full
frame
rate
and
then
the
thumbnails
you're
both
making
them
smaller
and
reducing
the
frame
rate.
Because
it's
you
know,
people
aren't
looking
at
that
very
much.
D
You
you,
you
want
to
actually
be
able
to
control
the
user
experience,
and
so
you
want
to
be
able
to
control
on
a
given
stream.
What
the
you
know,
the
frame
rate,
which
is
the
easiest
way
to
well,
is
it
a
very
direct
way
to
do
to
create
a
given
user
experience?
So
this
is,
you
know
everybody
thinks
about.
This
is
a
rate
control
framework
type
thing?
It's
not
it's
a
user
experience
type
thing
I
mean
it
many
times
we're
on
it.
D
If
you're
doing
screen
sharing
of
certain
types
of
applications
like
this
conference
today
it
doesn't
matter,
we
were
all
on
infinite
bandwidth
links.
We
probably
wouldn't
desire
to
send
the
screen
ship
error
at
60
frames
per
second
we'd,
probably
desire
to
send
it
at
set
a
max
of
five
there's
just
no
point
in
swimming
at
about
five
frames
per
second
for
this
type
of
screen
share.
But
when
I
capture
doing
screenshot
animations,
it
might
be
different
right
right,
but
that's
controlled
to
get.
J
User
media
capture
rate
like
that
this
only
comes
into
play
when
we
have
simulcast,
we
want
to
send
two
streams
at
two
different
frame
rates
from
the
same
source:
right
and
I.
To
be
honest,
I
think
this
is
really
like
a
matter
of
taste
in
some
ways
you
know
the
key
thing
they
think
that's
complicated
here
is
that
frame
rate
can
vary
for
reasons
they're,
not
under
application
control.
J
D
F
J
Know,
I
think
that
this
is
a
kind
of
edge
Casey
stuff.
Most
people
won't
set
this
and
I
think
that
max
frame
rates
easiest
to
get
your
head
around
I,
don't
I
think
there
are
cases
like
if
your
frame
rate
dips
15,
you
may
not
want
to
send
7.5
or
3.75,
so
the
scalp
frame
rate
down
by
maybe
a
overly
crude
tool
so
of
these
two,
like
I,
think
max
frame
rate
is
probably
the
simplest
to
specify
an
implant.
Yeah.
C
J
A
O
C
So
probably
Eric,
we
should
probably
time
limit
this
one,
but
but
hopefully
we
can
make
a
little
progress
because
we
want
to
get
on
to
some
other
stuff.
So,
basically,
as
I
understand
this
issue,
it's
how
and
when
this
is
simulcast
send
their
stop,
sending
simulcast
light
layers
a
couple
of
ways.
This
can
happen.
First
of
all,
the
app
can
of
course,
set
encodings
not
active
to
false
if
it
wants
to
stop
anything
on
its
own.
A
second
way
is
that
the
browser
could
conceivably
stop.
C
You
know
there
is
a
mandate
for
congestion
control,
either
circuit
breakers
or
congestion
control
mechanisms,
so
the
circuit
breaker
breaker
could
just
fire
and
stop
something,
there's
a
so
that
you
know
that
is
in
the
ITF
specs.
There
is
a
question
about
how
the
application
knows
that
the
circuit
breaker
is
fired,
but
that's
a
secondary
question
and
then
the
third
way
is
conceivably
the
SF.
C
You
can
can
drive
it
either
by
signaling
through
the
application
to
drop
it,
and
then
the
application
just
sets
active
to
false
or
there
is
this
stream
pause
mechanism
which,
as
far
as
I
know,
no
browser
is
planning
to
implement
or
anything
equivalent.
So
those
are
the
three
ways
it
can
happen.
So
next
slide.
C
So
we
have
two
knobs
right
now
we
have
degradation
preference,
which
is
for
the
resolution
frame
rate
trade-off,
and
then
we
have
priority,
which
is
the
relative
importance
of
encodings,
so
here's
the
announced
for
those
for
those
two
things,
so
you
can
indicate
you
know
in
degradation
whether
you
want
to
focus
on
the
frame
rate
of
the
resolution
of
both
and
then
there's
the
the
priority
types.
Next,
so
just
to
review
degradation
preference
is
for
an
entire
RTP
sender,
because
it's
within
our
DC
RTP
parameters.
C
C
So
the
question
is:
are
these
two
things
enough
to
do
what
we
want
or
not?
So,
as
I
mentioned?
Basically,
the
degradation
preference
discusses
the
priority
of
the
RT,
the
RTC
RGB
sender,
to
maintain
a
resolution
or
the
frame
rate
or
be
balanced.
All
encoding
essentially
have
the
same
value
by
default,
because
it's
not
a
per
encoding
thing
and
then
priority
indicates
relative
importance.
This
determines
the
cross
marking
potentially
of
each
encoding,
so
they
can
be
different.
Like
a
among
simulcast
dreams.
C
There
is
a
question
about
whether
it
also
guides
encoder
behavior,
so,
for
example,
whether
it
indicates
a
preference
of
encodings
to
drop
it
all
cannot
be
sent
simultaneously.
An
example
of
this
would
be
in
simulcast,
say
you
have
your
sending
three
simulcast
dreams.
You
have
kind
of
a
base
of
the
lowest
one.
You
encode
you
mark
that
as
high
priority,
the
medium
resolution,
one
for
example,
marcus
medium
and
then
the
highest
resolution
mark
is
low
and
your
intent
there
would
be
to
have
the
best
encoding
drop.
C
I
think
it's
basically
on
an
SSRC
basis
right.
So,
if
you're
sending
these
things
with
different
SSR
sees
so
you're
sending
three
street
and
all
hell
breaks
loose,
because
it's
you're,
basically
trying
to
send
more
in
the
channel
can
handle
basically
circuit
breakers,
would
tell
you
potentially
kill
all
of
them
right.
I
can.
S
Chime
in
here
Levinson's,
yes,
one
of
the
quarters
of
the
circuit
breaker,
so
I
think
it
allows
you
to
like
the
circuit.
Breaker
algorithm
allows
you
to
like
switch
off
audio
video
or
a
specific
SSRC
before
you
turn
off
everything,
so
it
doesn't,
it
doesn't
require
you
to
like
it's
not
all
or
nothing,
but
basically
you
can
do
it
for
SSR
seas
and
if
you
start
with
detected
before
you
can
turn
off
things
before
it
says
like
triggered,
have
like
clothes
everything,
okay
by.
C
S
C
I
think
the
answer
to
that
is
yes,
because
it's,
for
example,
get
multiple
senders
right
and
everything
in
once,
and
there
is
all
in
coatings,
are
marked
low
and
another
centers
mark
I.
Then
it
would
effectively
tell
you
the
priority
of
the
high
sender
is
higher
than
the
lower
one.
So
yeah,
it's
not
just
within
a
sender.
It's
kind
of
applies
to
all
Sanders
as
well.
G
That
that's
for
the
ITF
transport
draft
to
to
work
out
actually
and
the
way
it's
currently
specified.
It's
specified
as
and
defining
the
reporter
proportion
of
the
app
available
bits
allocated
to
each
priority
level.
So
that's
its
design
not
to
starve
anyone
completely.
But
let's
let
some
bits
true,
yeah.
C
D
Also,
just
to
add
whatever
Harold
saying
here,
because
I
think
we
already
have
I
think
we
sort
of
have
this
salt
actually
just
need.
We
need
to
understand
it.
Is
that
draft
says
here's
how
the
bits
get
allocate
circuit
breakers
tells
you
about.
The
total
number
of
bits
are
going
to
be
able
to
put
into
any
congestion
context
right
and
then
there
this
that
the
transport
draft
sent
you
something
about
how
you
allocate
those
between
the
layers
and
then
this
other
parameter.
I
forget
the
name
of
it,
the
encoding
priority
or
whatever
we
go.
D
That
one
tells
you
tells
the
video
codec
well,
you
know
now
that
you
know
how
many
bits
you
have
this
gives
you
a
hint
of
how
you
should
use
them
of
how
to
degrade
right,
the
balance
thing
or
whatever,
and
maybe
that
should
be
/.
Maybe
that
should
be
set
per
layer
instead
of
set
one
value
across
all
the
layers.
I'm
can
set
it
for
reaching
coating.
C
D
At
possibly
not,
but
the
part
where
it
doesn't
give
them
control,
is
the
transport
draft
very
directly
sort
of
allocates
it
says,
like
here's,
a
suggest
way
to
allocate
the
bits
between
layers,
and
if
you
don't
like
that
allocation,
you
basically
need
to
use
the
max
bitrate
stuff
to
overload
it
and
andrey
control.
That
III
mean
Harold.
Is
that
how
you
view
it
to
that?
That's
that's
the
only
you
know,
yeah.
G
So
the
so
their
location
stuffs
s
how
you,
how
you
proportion
out
the
bits.
It
will
be
completely
logical
whether
way
to
say
that
the
low
the
smallest
to
channel
has
the
highest
priority
so
that
you
at
least
get
something
true
and
then
the
use
and
better
quality
layers
at
a
lower
priority,
because
they
can
be
dropped
first.
C
E
J
You
consider
it
important.
You
here,
I
think
it's
very
hard
to
separate
the
case
from
where
you
have
two
layers
where
you
want
to
send
both,
but
a
portion
bits
equally
or
two
layers
where
you
don't
want
to
send
the
high
resolution
layer
until
you
can
fully
send
the
low-resolution
layer
at
a
quick
q
p,
and
so
it
seems
like
you
know,
we
talked
about
this.
I
think
I
or
can
see
a
little
bit
is
some
notion
of
like
a
minimum
bitrate.
C
D
C
J
Right,
right
and
I
think
that
we
probably
consider
those
two
scenarios:
oh
I,
need
to
send
to
summer
cast
layers
a
you
know,
one
for
mobile
one
for
full
res
and
then
one
where
it
I
don't
want
to
send
the
high
resting
unless
adequately.
You
know,
Senna
these
quality
on
that
high
res,
and
so
there's
some
minimum
QP
and
telling
you
all
the
bits
to
the
full
resolution,
layer
and
I
what
how
what
ap
eyes
will
be
called
I
do
that.
J
C
A
G
J
D
C
G
A
I
This
issue
applies
to
failed
and
completed
states.
They
both
rely
on
this
concept
of
finished
checking,
but
the
issue
is
that
we
could
be
finished
checking
on
the
existing
candidate
pairs,
but
anytime
you
can
call
ahead
eyes,
candidate,
creating
more
candid
hair
days
and
you'll
start
checking
again-
and
you
know
maybe
finish.
I
Checking
currently
is
intended
to
mean
you
know,
fans
checking
all
existing
pairs
and
we're
okay
with
it
flipping
back
and
forth,
but
I
think
that
just
be
clear
in
the
spec,
so
I'm
moving
on
to
the
next
slide,
I
think
the
turquoise
spec
already
sort
of
addresses
this
issue
because
it
has
the
concept
of
an
Indiana
syndication.
So
one
ice
agent
would
send
end
of
candidates
to
the
other
ice
agent
and
that
way
you're
only
in
the
failed
state.
I
If
we've
done
gathering
locally-
and
you
know
that
the
remote
ice
agent
is
done,
gathering
it
as
well,
but
in
WebRTC
there's
no
way
to
trickle
this
end
of
candidates.
Currently,
the
only
way
would
be
easy
on
all
four
answer,
with
eight
goals
in
two
candidates,
and
that
would
be
one
option
I'll
get
to
later,
but
I
don't
think
that's
it's
very
convenient
before
we
talk
about
various
ways
that
we
could
trickle
end
of
cans.
I
think
we
need
to
decide
if
that's
necessary
in
the
first
place.
I
So
the
first
question
I
want
to
answer
is,
should
failed,
only
occur
after
local
and
remote
gathering
is
done.
In
other
words,
do
we
need
to
know
if
remote
gathering
is
done
so
the
advantage
of
doing
this
is
that
failed
would
be
more
definitive
in
that
you
can
only
recover
from
failed.
We
an
IV
start.
The
application
developers
wouldn't
have
to
worry
about
it,
potentially
flipping
from
failed
to
checking
if
they
had
a
new
candidate
and
would
match
died.
I
The
trick
lies
definition
of
failed
then,
and
the
only
real
technical
benefit
I
found
is
that
if
you're
not
doing
aggressive
nomination,
then
signaling
end
of
candidates
spice
agent,
quite
a
lot
faster
because
say
all
you
have
is
a
working
turn
connection
but
you're
waiting
for
a
a
stun
connection.
If
you
get
end
of
candidates-
and
you
know-
that's
not
going
to
happen
so
you
can
go
ahead
and
on
a
determine
10
in
the
case
of
aggressive
nomination
that
doesn't
by
obviously
but
actually
say
on
that
slide.
I
For
what
the
reasons
for
not
doing
this,
it
are
that
if
the
application
doesn't
signal
end
of
candidates,
that
means
they
suddenly
stop
seeing
the
failed
state.
So
it
has
some
significant
backwards,
compatibility
concerns
and
I.
Think
in
the
majority
of
cases,
though,
this
won't
make
a
difference
because
no
chrome
uses
aggressive
nomination,
so
there's
no
technical
benefit
in
that
case,
and
in
most
cases
gathering
is
already
finished
by
the
time
failed
is
reached
so.
I
Basically,
there's
no
way
for
it
to
foot
back
to
checking
in
the
first
place
and
if
application
developers
really
want
to
detect
this
condition,
they
already
could
I.
Just
you
know,
saying:
am
I
failed
and
I
like
signal
end
of
candidates
and
I'll
just
be
something
that
we
love
to
the
application.
If
it
wants
to
do
that.
I
So
basically,
my
recommendation
is
just
to
stay,
failed
means,
you're
done
with
local
gathering
and
and
it
can
flip
back
subscribing.
If
you
had
a
new
candidate,
let.
D
Me
just
ask
about
a
user
experience.
I
want
to
make
sure
that
we
can
deal
with,
which
is
I'm
starting
a
call
of
some
sort
and
in
the
user
interface
of
this
thing
not
want
to
be
able
to
clearly
differentiate
between
I'm
still
trying
to
get
you
a
connection,
but
it
hasn't
worked.
Yet
you
know
I'm,
you
know
trying
to
connect.
Is
the
message
I'm
displaying
right
and
at
some
point
in
time,
I
want
to
be
able
to
display
sorry
can't
connect
to
the
other
person
and.
I
Yeah
that'll
be
my
final
point
that
that
already
is
is
fully
impossible,
because
if
that
location
wants
to
signal
end
of
candidates,
then
can
do
that.
And
you
know
the
logic
could
be
I'm
only
going
to
pop
up
this
failed
message.
If
the
peer
connection,
I
state
has
failed-
and
I
signaled
end
of
candidates
on
my
own,
because
then
I
know
that
you
have
things
that
completely
failed
alligator
action,
so.
D
I
C
C
Is
that
its
end
of
candidates,
right
in
the
event
of
you
know,
bring
the
interfaces
up?
There's
a
question
of
whether
it's
ever
a
final
thing
like
I,
gave
you
everything
all
the
candidates
I
had
at
the
moment.
But
you
know
if
you
can't,
if
you
can't
find
a
connection,
I'm
going
to
go,
bring
up
my
expensive
interface
and
you
know
try
that
yeah.
C
J
100,
it's
pretty
to
be
a
terminal
state.
You
know,
I
think
that
if
we're
trying
to
do
ice
in
you
know
that's
a
time
when
you
should,
we
bring
up
your
interfaces
and
doing
things,
and
you
know
the
application
made
use
or
browse
my
shoes
through
time
out
that
it
needs
to
make
different
decisions.
But
once
you
could
say
what
we've
tried
everything
you
know,
that's,
where
you
end
up
and
failed
nest
journal.
R
This
is
one
of
her
I.
Don't
necessarily
see
a
conflict,
though
between
a
picnic
saying
it's
unfair.
Unless
you
have
another
candidate
to
add
to
give
me
and
then
it
can
go
back,
I
mean
I.
Think
so
I
like
the
idea
of
what
it's
worth
to
to
not
add
this,
because
I
think
it
falls
under
the
minimal
web
RTC
implementation
and
that,
as
was
pointed
out,
you
applications
can
do
this
without
making
a
change
here.
I
J
Well,
so
the
main
thing
is
that
I
failed
is
just
kind
of
any
corrosion
I
used
to
Reuters
timeouts
that
you
know,
we've
tried
to
send
content
each
X
for
X
number
of
seconds.
I
haven't
gotten
response,
so
we're
just
saying
that
okay,
we're
even
is
not
working
like
the
application,
can
see
that
you
know
any
can
say
all
right,
long,
I
think
these
things
work
now
and
do
something
else.
Instead,
I
fail
this
sort
of
like
basically
playing
things
by
the
letter.
J
D
H
H
I
The
browser
has
to
put
those
two
pieces
together
for
that,
like
you're,
forcing
the
application
to
pass
something
into
the
peer
connection,
so
it
spit
something
out,
but
like
browse
application
already,
has
all
that
information,
I'm,
not
sure
I
phone
we
have
cubic
agent
necessarily
have
end
of
candidates.
Well,.
I
M
A
J
I
Most
of
the
questions
depend
on
the
thanks
for
the
first
one.
So,
okay,
except
for
question
3,
which
was
if
you've
been
disconnected
and
a
dice
consent,
as
interval
has
elapsed,
mean
you're
never
going
to
get
out
of
disconnected.
Should
we
define
that
as
fiddled
as
well
and.
I
The
magic
could
be
that
would
tell
you
when
a
nice
restart
is
really
needed,
but
I
would
argue
that
by
the
time
30
seconds
have
passed,
he
probably
should
have
already
done
a
nice
restart.
So
I
don't
see
the
third
movie
scenario.
It's
just
full
consent.
Expiration
is
for
a
pair
right.
Yes,
MF
is
expired
for
all
the
pairs
that
you
have
all.
C
A
C
O
G
C
P
A
J
See
what
we
can
come
up
with
here?
First,
maybe
we
can,
you
know,
come
up
with
a
little
bit
on
the
list.
We
can
everyone
can
sign
it,
how
it's
pretty
good
okay
and
if
not,
then
maybe
we
can
take
it
to
it.
Design,
meeting
yeah.
A
Okay,
unless
anybody
else
that
has
any
other
for
their
comments,
we're
going
to
wrap
it
thanks
for
thanks
for
joining
and
making
this
possible,
google
for
the
hangouts
apologize
for
the
technical
difficulties
going
on
guys,
we'll
try
and
avoid
that
in
the
future,
love
to
hear
your
feedback
in
terms
of
how
you
think
it
went
I'm
not
necessarily
follow
that
post
call.
Anybody
have
any
closing
comments
there
like
that.