►
From YouTube: WebRTC Working Group Virtual Interim May 2, 2017
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
Pushing
it
I,
don't
think
there
is
a
deadline.
I
think
this
works
either
done
or
not
done,
but
I
think
that
what
we
need
to
do
that's
different
than
previous
times
is
I.
Think
we
need
to
find
some
people
and
find
out
when
they
can
have
it
done
by
and
have
a
plan
here
versus
a
witch.
What
we've
had
before
is
I
wish
to
a
list
that
no
one
reads,
because
it's
flooded
with
github
traffic.
C
You
you
can
also
ask
you,
can
also
ask
on
the
list
saying
you
know
we,
you
know
I,
we
see
people
over
in
filing
issues
who
here,
like
we
asked
in
this
meeting.
Who
here
has
read
the
document
in
its
entirety
and
reviewed
it?
You
can
ask
that
question
on
the
list,
and
so
then
you
had,
then
you
know
whether
they're
getting
it
just
because
of
implementation
or
you're
getting
it
because
you're
actually
looking
at
it
I
mean.
D
I
can
look
to
the
chairs
like,
like
we
have
experience
doing
this.
This
all
the
time
90s
and
the
way
you
selves
problem
is
that
in
this
meeting
right
here,
we
identify
tool
two
to
four
people
who
commit
to
reading
it
by
a
given
time
and
in
producing
real
reviews.
And
then,
when
we
have
those
reviews
at
those
reviews
are
positive.
Then
we
know
we
are
good.
D
If
the
rows
are
negative,
then
we
keep
working
and
like
on
since
I'm,
actually
do
something
I
prefer
to
college
every
one
of
those
people,
especially
now
that
have
JSF
done
so
I'm
like
now
that
those
blocked
out
with
that
so
and
as
far
as
you
know,
that's
any
way
to
actually
proceed.
If
you
actually
give
a
about
in
the
document
like
he'll,
be
good
as
opposed
to
distress
as
opposed
to
starting
up
the
process.
E
I'm
hearing
slight
one
thing:
I'm,
hearing
free
column
and
I
think
in
particular,
is
is
about
readability
and
I.
Think
that
it
feels
to
me
like
that's
something
you
could
separate
off
from
being
stability,
but
not
meeting
the
standard
item
you
know,
meeting
our
requirements.
I
think
the
readability
is
is
something
that
we
should
be
doing.
But
if
you
do
it
too
early
then
like
when
you,
when
you
do
add
the
fixes
that
will
inevitably
come,
you
screw
up
the
readability,
so
I
think
you
can
do
the
readability
stuff
too
early
I'm.
A
Fine
with
that
I
only
meant
to
imply
I
wish
to
review,
did
it
meet
our
technical
requirements
and,
like
you
notice,
the
Barnard's
question
earlier,
like
my
experience,
w3c
documents
is
no,
they
aren't
adding,
is
very
rare
to
add
a
new
API
or
a
new
feature
or
to
two
things
during
CR,
but
it
might
be
very
common
to
clarify
the
explanation
of
how
something
works.
I
want
to
do
it.
I
I'm,
not
asking
for
a
editorially,
perfect
ring,
really
just
asking
for
people
to
have
read
it.
That's
it
hi.
F
This
is
Yana
boy.
This
comment
on
Dom
comment
about
implementation,
I
think
it's
true.
We
have
changed
our
API
so
on
the
API
load,
I
think
there's
at
least
three
times:
we've
changed
it
to
a
negotiation
where
I
would
call
the
real
1.0
was
probably
a
scream,
and
then
we
could
move
to
that
track
and
then
we
have
transceivers
so
I
think
we.
We
have
multiple
of
limitations
but
they're,
currently
implementing
different
API.
So
pick
some
of
the
issues
file
today
as
they
are
based
on
implementation
and
we're
finding.
G
B
H
Know
yeah
I
guess.
My
question
is:
if,
when
we
asked
for
the
review,
I
I
personally
think
it's
inevitable
that
we're
going
to
get
a
ton
of
bugs
filed?
Do
we
then
go
back
and
classify
which
ones
are?
You
know
CR
limiting
and
have
to
be
finished,
and
when
we
finish,
those
we
go
to
CR.
Is
that
with
the
processes.
H
G
Do
another
round
of
with
you?
We
need
to
be
asking
specifically
for
we
live
out
whether
or
not
we
are
meeting
or
technical
requirements
and,
of
course,
as
people
with
you
enter,
and
they
will
also
find
a
bugs
and
other
kind
of
issues,
but
those
I
think
should
be
treated
as
part
of
the
post,
your
handling,
unless,
of
course,
we
manage
some
handle
them
before
this
year,
which
would
be
great
but
I.
D
You
know
I
can
live
without
it,
I
mean
the
way
I
would
phrase.
This
is
that
we
do
these
reviews
and
then
we
classify
and
then
we
address
the
central
issues
that
are
raised
and
then,
if
those
set
of
our
changes
are
moderate
and
people
agree
they're
self-contained,
then
we
don't
need
a
second
round
of
like
full
reviews,
but
I've
got
many
variations
or
changes
when
the
second
round
before
viewing
this.
D
The
way
this
I
mean
this
is
I
mean
it
is
just
like
any
piece
of
you
know
any
piece
of
it
during
you
have
to
go
over
all
the
way,
acacia
something
I
guess:
yes,
I
think
if
it
is
if
it
is
or
if
this
stuff
is
ready,
if
the
people
who
want
to
put
it
in
CR
now
think
it
is,
then
when
people
didn't
review,
they
shouldn't
find
very
much
and
fixmestick
should,
when.
B
D
D
G
G
B
H
B
H
B
H
B
B
D
D
B
H
H
A
So
if
there
was
not
going
to
be
two
implementations
of
identity,
I
mean
I
think
there
will
be
two
implementations
of
identity,
but
I,
don't
think
it
should
be
marked
at
risk.
Think
it's
at
risks
of
being
removed,
I
think
the
draft
the
specification
maybe
risk
it
not
moving
to
PR.
A
A
I
mean
even
if
there's
zero
implementations
of
this,
which
there's
not
I,
don't
think
it
should
be
removed.
It's
critical
to
the
privacy
and
security
of
this
document,
and
it
also
is
required
by
the
IETF
that
we
would
need
to
get
consensus
in
idea
to
also
remove
it
and
I.
Don't
think
that
we
meet
our
w3c
privacy
and
security,
gold
or
the
IGF
privacy
and
security
goals
of
who
remove
this.
In.
C
G
Of
what
I
understood
as
the
implantation
ceman
but
hearing
what
current
say,
I
think
marking
it
does
risk
is
probably
the
wrong
thing
to
do
now
that
I
think
more
about
it,
because,
given
that
it
is
indeed
a
requirement
that
we
agreed
to
tackle,
we
should
not
allow
yourself
to
move
to
PR
without
going
another
wide
review
cycle.
If
you
were
to
remove
it,
because
this
would
be
a
change
of
requirements,
so
I
guess
I'm
revisiting
my
perspective
on
this
and
I'm.
G
Sorry
for
that,
but
I
think
it
would
not
be
logical
for
us
to
to
market
at
risk
and
we
I
think
no
matter
what
we
need
to
call
attention
to
the
community
on
the
fact
that,
right
now
there
is
no
clear
plan
on
getting
a
second
implementation,
and
that
was
one
of
my
goal
with
marking
it
at
risk,
but
I
think
from
a
process
perspective.
It
the
wrong
thing
to
do.
H
H
H
D
Not
just
pro
and
then
I,
don't
care
very
strongly
about
that,
but
I'm
surprised
for
price
people
want
to
work
that
at
risk,
because
I
mean
I'm.
Not
so
I
really
haven't
implemented
it
yet,
but
I'm
surprised,
like
I'm
surprised
you
wanna,
remove
it
so
I
thought
was
I
mean
this
without
really
a
formal
thing,
because
I
did
I.
I
thought
Google
wanted
that
and
we
wanted
that.
E
H
D
I
acted
but
I
wasn't
paying
for
systems.
I
should
have
been
I
guess
my
tension
is
did
if
you
know
if
our
standard
was
actually
features
which
were
in,
which
were
both
brought
returned.
You
know
two
or
three
years
of
three
browsers,
I,
think
about
25
senators
back
of
your
risk,
but
you
know
that's
different
for
the
question
of
which
features
like
no
one
is
in
the
attention.
You're
doing
it
as
opposed
to
you
know,
fun
sweet
shot
got
around
to
me.
H
B
E
A
On
this,
this
implementation
issue,
like
talking
to
I've,
gone
talk
to
more
people
WWC
about
the
general
to
implementation
thing
and
I
mean
our
goal
is
to
make
sure
that
the
spec
is
implementable
is
one
of
the
key
one
of
the
key
reasons
for
this
am
I
worried
here
really.
Is
that
huge
portions
of
the
spec
there's
actually
only
one
implementation
up?
It's
a
shared
implementation.
A
That's
that's
used
widely
across
three
browsers,
but
I
think
that
we
might
want
to
rethink
how
how
sticky
exactly
we
are
on
the
one
implementation,
when
our
ten
implementations,
when
the
one
implementation
we're
talking
about,
is
open
source
that
can
be
used
by
anyone
to
help
them
implement
the
spec,
and
you
know
AIDS
I
mean
our
goal.
Here
is
interoperability
in
the
end,
not
jumping
through
some
series
of
Hoops,
so
I
mean
how
are
other
people
been
looking
at
this?
How
many
implementations
issue.
E
A
A
E
So,
sir
and
I
think
it's
an
important
distinction.
They've
just
run
out
there
because
there
are
I,
can
tell
you
I
know
of
a
couple
of
implementations
which
are
not
based
on
the
same
protocol
implementations,
but
that
doesn't
necessarily
go
all
the
way
back
up
to
the
API,
because
they're
not
sitting
in
browsers.
So
it's
not
as
far
as
the
w3c
hat
that
doesn't
like
it
doesn't
play.
But
as
far
as
the
ITF
protocol
layer
yeah
there,
there
are
several
on.
B
I
B
I
G
G
Sake
of
clarity,
at
least,
if
we
are
looking
at
the
formal
question
in
WCC,
we
will
be
looking
at
independent
implementations
of
the
API
and
with
those
gendering
protocol
strategies.
The
same
anat
is
not
necessarily
directly
relivin
telling
me
we
could
put
on
ourselves
an
additional
constraint
that
we
want
to
show
two
widely
deployed
brothers
with
completely
different
underlying
stacks
yeah,
but
we
don't
have
to
I.
Don't.
H
Have
a
special
deal
of
stuff
is
that,
at
least
from
the
w3c
perspective,
I'm
told
that
there's
no
intent
to
really
try
to
produce
the
protocol
coverage.
That
would
give
us
any
assurance
of
interoperability.
I
mean
if
I'm
the
w3c
perspective
emails
that
people
might
try
to
test
various
things,
but
I
believe
that
that
is
UC,
considers
that
out
of
scope
and
so
I'm
not
sure
how
we
would
ever
get
there
like.
Even
if
you're
trying
to
test
every
feature
of
ice
I,
don't
I,
don't
think
we
have
that
rich.
Today,.
A
So
I
mean
if
what
we're
going
to
test
in
the
browsers
is
there's
an
API
and
you
don't
get
a
segfault
when
you
call
it,
you
know
that
that's
no
problem,
if
what
we're
going
to
test
is
it
does
what
this
document
says
will
happen
when
you
call
those
things
then
we're
talking
about
then
I,
don't
know,
I,
don't
know
where
you
separate
from
the
API
to
the
protocol
stack
I'm
unlost.
Maybe
you
guys
can
explain
to
me
with
the
differences
yeah.
H
A
So
I
think
what
I'm
forcing
a
little
bit
towards
is.
Actually
our
testing
back
should
be
a
little
bit
more
relaxed
so
that
you
know
there's
more
than
one
browser,
regardless
of
implementations
where
you
can
take
some
of
this,
where
you
can
write
JavaScript
code,
that
would
be
the
type
of
JavaScript
code
you'd
write
from
the
spec
and
at
least
the
sunny
day
cases
some
won't
work.
I,
don't
think
we're
going
to
get
much
farther
than
that.
I.
G
I'm
not
sure
where
are
you
getting
at
to
then
but
I
mean
in
principle.
What
happens
is
when
we
think
we
have
enough
once
we
think
we
have
a
test
with
the
demonstrate
enough
interoperability.
We
make
the
case
to
the
director
and
in
general,
the
director
will
review
and
approve
that
case.
So,
basically
something
we
should
make
too
little
of
an
effort
in
building
that
test
with.
There
is
a
lot
of
API
sofas
in
web
RTC.
A
C
I'm
not
as
concerned
with
having
two
implementations
all
the
way
to
the
bottom
of
the
of
the
of
the
software
stack,
including
the
compiler
and
standard
libraries
and
all
that
sort
of
stuff.
At
some
point
you
need
to
say
enough:
you
know
that
you
have
that
certainly
did
the
top
layer
of
Dom,
etc
or
J's
code.
These
there
needs
to
be
clear
that
people
that
two
people
have
been
able
to
implement
those
things
and
such
that
you
can
use
them
yeah.
H
H
G
So
I
mean
I,
guess
from
actually
timing
perspective,
I'm,
not
sure
what
we
are
discussing
now.
One
thing
that
is
timely
to
discuss
is
our
CRI
critical
area.
A
one
thing
that
is
very
less
than
timely
to
discuss
is
what
exactly
needs,
what
the
core
idea,
what
a
so
it
needs
to
be,
and
what
what
will
be
tested
in
what
devs,
because
a
lot
of
it
will
happen
organically,
so
I'm
not
sure
what
we're
discussing
are
we
discussing
what
constitutes
an
implementation
or
how
many
of
these
implementations
we
want
to
get?
J
All
right
so
before
this
PR,
the
description
of
gift
parameters
basically
said
it
returns.
The
current
parameters
used
for
sending
or
receiving
and
then
set
parameters
explains
how
those
parameters
will
be
modified,
but
there
wasn't
a
good
explanation
of
how
the
cranberries
get
there
in
the
first
place.
So
it
started
with
the
last
virtual
interim
of
trying
to
figure
out
how
the
send
encodings
primitive
CAD
can
see
the
effects
with
senders
parameter
and
a
sort
now
also.
J
Expanded
on
that
to
more
generally
describe
how
the
sender's
receivers
parameters
are
populated
at
this
point
by
adding
some
pros
to
they
give
parameters.
Description
swinging
up,
want
a
sort
of
formalized
algorithm
more
in
the
future,
so
make
things
actually
being
added,
are
describing
the
bullets
on
the
slide.
So.
J
So
for
a
sender,
the
load
description
will
contain
the
codec
and
Ikey
Heather
extension
parameters
and
for
a
receiver,
that's
in
very
state
come
from
the
vocal
description
for
receiver.
The
SSR
seeds
are
pretty
much
the
only
thing
that
comes
from
the
remote
description
as
something
Bernard
mentions
that
the
remote
description
may
also
remove
some
codecs.
For
example,
if
I
offer
three
codecs,
then
receiver
dog
get
branded
should
return
all
three
of
them
because
I'm
prepared
to
receive
any
of
them,
but
otherwise
I
said
or
mode.
This
description
that
lose
want
them.
H
The
other
question
I
had
Taylor
is
if
a
parameter
has
a
default,
even
if
it
was
not
said
shouldn't
get
parameters
return
that
default,
like
I'm
thinking
of
degradation
preference.
It's
has
a
default
of
balanced.
So,
for
example,
even
before
a
remote
description
is
said,
if
you
call
get
parameters,
wouldn't
it
return
the
default.
J
H
J
J
H
A
H
F
F
I
do
have
some
detail,
questions
I,
don't
know
if
they're
for
the
group,
but
it's
like
all
set
parameters
and
then
I
will
create
offer
and
then
I
called
set
parameters
again
and
then
I
call
great
offer
again.
It
does
that
effect,
I
get
a
different
offer
and
if
so,
what
happens
if
I
then
set
the
old
offer
will
set
local
very
multiscale
ocol
description,
I
mean
it
seems,
like
you
thought,
I
was
sent
here.
J
So
this
is
just
fallout
from
the
last
virtual
interim,
where
the
issue
is
raised,
that
we
get
contributing
sources
returns.
Objects
are
both
represents
episode,
CS
and
TS
RTS,
and
we
decided
to
split
into
two
methods
for
each
and
so
just
for
consistency
with
naming
I
called
the
new
method
get
synchronization
sources.
We
could
call
it
get
CS.
J
Our
storage
APIs
are
keys
with
them
sort
of,
although
you
have
get
contributing
sources,
but
it
spelled
out
and
get
as
star
seeds
with
a
not
spelled
out
so
I'm
going
to
do
some
bike
chain,
but
that's
how
it
is
right
now.
So
then,
the
treating
methods
return
different
air
bases
which
are
pretty
much
the
same
with
some
slight
differences.
D
Ivan
reviewed
this
PR,
but
this
slide
looks
fine
to
me.
You
know
modulo
I'm
sure
I
had
some
nitpicks
about
I'm,
sure
I
should've
mentioned
it
fix
it,
outdated,
liens
or
something.
D
This
something
to
screw
here,
I
just
got
the
wrong
I
see
everyone
I
mean
this
is
what
this
isn't
one.
What
what
is
it
one
moment?
Three,
one
three
is
the
issue.
D
This
is
yeah
okay,.
D
H
Alright,
so
we've
been
talking
about
simulcast
errors
and
what
to
do,
and
so
this
is
a
focus
and
we
fixed
a
bunch
of
things.
But
there
are
many
things
we've
been
talking
about
it
in
encoding,
parameter
errors
and
how
to
figure
out
what
went
wrong
so
in
the
PR,
we're
proposing
to
add
three
new
errors:
invalid
encoding
parameters
too
many
encoding
Zanden
valid
codecs,
because
we
think
those
is
those
are
three
things
but
could
well
happen
so
for
the
invalid
encoding
parameter
case.
That
means
that,
basically,
you
provided
an
invalid.
H
H
Actually,
it
would
be
a
sequence
of
attributes
and
you
would
include
the
name
of
the
parameters
that
were
invalid,
specifically
the
the
attributes
that
that
weren't
right
in
that
in
that
sequence,
for
too
many
encoding
z'.
That's
the
case
where
you
have
to
you
ask
for
too
many
encoding
x'
like
in
a
transceiver.
You
asked
for
five
soundless
to
send
five
simulcast
streams.
You
can't
do
that.
One
thing
that
was
discussed
in
the
PR
was
great.
You
you
asked
for
too
many.
Well,
how
many
you
know
what
was
the
maximum?
The
problem
here
is
I.
H
Think
in
the
discussion
we've
said
that
this
might
be
dynamic,
so
I
could
tell
you
could
get
back
hey
you
could
you
could
have
sent
three
and
then
you
try
to
send
three
and
that
also
returned
because
it
turns
out
at
that
time.
You
could
only
do
two,
because
you
were
you
know
some
other
browsers
ever
something
was
was
consuming
the
resource,
so
not
clear
to
me
that
a
Mac's
booting
attribute
makes
sense.
I'll
tell
you
how
many
do
so.
I
wanted
to
ask
for
feedback
on
that.
A
Regard
I
I
totally
get
the
problem
and
think
we
need
to
write
it
up.
It
was
clear
that
you
know
what
the
max
would
you
use
the
max
that
might
not
work,
but
I
still
think
that
having
the
max
would
be
really
useful
rather
I
mean.
What's
your
alternative,
just
guessin
probe
I
mean
it's
it's
a
mess
so
I
like
the
idea
of
adding
a
max
with
the
limitations.
You
said,
okay.
H
Okay,
so
we'll
go
in
that
direction
and
then
the
last
one
is
invalid.
Codecs,
where
you
you
did
something
weird
like
you
added
a
codec
that
wasn't
in
the
list
or
something
or
you
or
something
got
taken
out,
and
so
you
you
put
in
and
Alatorre
unavailable,
codecs
and
set
parameters
or
set
codec
preferences,
and
so
for
this
case
again,
you
proposal
is
to
and
return
a
sequence
in
the
invalid
codecs
attribute.
That
would
include
the
mime
types
of
the
codecs
that
were
invalid.
To
kind
of
give
you
a
hint
about
what
you
did.
J
So
I
think
we
should
try
to
separate
parameters
that
are
invalid.
According
to
the
specification
versus
planter's
that
aren't
supported
by
the
browser.
So,
for
example,
if
I
try
to
add
a
codec
that
wasn't
there
in
the
first
place,
Oh
pestered,
resulting
in
modification
area
already
or
somebody
tried
to
remove
old
codex,
but
the
lie
wands
and
that
no
give
us
a
hardware
encoder
and
it's
not
no
longer
available.
You
know
that's
when
this
area
was
twenty
BS
Terry
it's
valid,
but
the
balloting
currently
support
it
anymore.
H
He
okay
I
just
a
question,
maybe
for
my
clarification,
because
a
bunch
of
the
things
right,
we're
already
throwing
exceptions
or
rejecting
promises
for
various
things
like
invalid
modification.
Would
you
my
question?
I
guess
is
you
would?
Would
you
also
in
some
of
those
cases,
also
have
an
RTC
error
or
those
kind
of
mutually
exclusive?
Oh.
J
H
H
E
H
Geeky
LS
failures
and
specifically
the
goal,
is
to
try
to
provide
information
on
recoverable
DTLS
errors
and
to
distinguish
them
from
unrecoverable
errors.
So
three
things
were
specifically
mentioned
in
there
in
the
issue
by
various
folks.
One
was
cryptographic,
negotiation
failure
and
this
would
be
a
case
where
a
browser
offers
ECDSA
certificates
by
default
and
for
some
reason
they
encounter.
H
If,
for
some
reason
you
decided
browser
decide,
they
didn't
want
to
allow
DTLS
one
okis
browsers
now
do
at
least
one,
but
again
they
encounter
some
weird
legacy
mobile
thing.
So
I
we've
had
a
little
bit
of
discussion
about
where
these
are
covered
in
the
DTLS
alerts.
So
now
that
we
have
ecker,
we
can
maybe
see
if
we
understand
this
correctly.
The
cryptographic,
negotiation
or
failure
I
think
is
number
43
unsupported
certificate,
as
I
write,
Ecker.
D
We
just
take
a
look
knock
to
myself.
I.
Think
I,
guess
wanting
to
say
is
that
I
guess
there's
a
two
things.
One
is
that
GCLs
implementations
sealed
up
with
these
are
not
incredibly
good
at
sending.
D
Ascending
the
the
deal
or
you
would've
helped
it's
the
first
thing,
I
would
say:
there's
a
it's
pretty
common
to
intent,
handshake
failure
or
just
tell
the
internet
connection
it's
kind
of
stuff
and
remember
the
in
DTLS.
It
works
on
rolls
unreliable,
and
so
don't
you
know
and
as
I
said,
no
parrot
super
delivered
at
all,
and
certainly
on
the
on
the
on
the
guy
who
sends
the
alert
on
is
a
now.
D
The
guy
who
are
going
on
so
I
mean
since
to
give
a
copy
of
the
Qadri
is
that
we
use
indicated
right
on
so
the
clap
and
the
catalog
offers
only
on
you
know,
offers
over
the
RSA
signature,
algorithms
and
the
server
only
have
as
on
ECDSA.
So
the
best-case
scenario
will
happen
will
be.
The
server
will
send
and
support
it.
If
it
get
on
these,
where
you
had
to
go
one
to
ram
okay
or
three
now
and
I
won
three,
that
is
the
one.
D
These
things
are
less
clear
about
what
what
exact
course
endo
think
sports
world
with
no
clear
on
and
then
we've
got
locally.
You
would
return
there
or
they'll
be
like
I.
Couldn't
find
a
certificate
and
you're
actually
you're,
actually
the
one
whose
job
will
be
to
fix
tests
right
in
this
particular
case
now,
I
mean
you
know
it's
of
course
year
was
a
complicated
question.
It
says
it's
the
same
way
back
right,
but
I
mean
it's
the
it's
the.
D
If
T
is
the
browser
that
physio
boards
that
actually
have
more
to
facial,
it's
called
so
I
think
you
are.
If
our
intention
is
to
actually
attempt
to
on
fifteen
live
field
diagnosed
on
I
think
you
know
more
interesting,
perhaps
then
surfacing
the
Lord
is
surfacing
some
effect
effectively
free
for
free
from
JavaScript
things.
D
Tell
you
like
this
is
what
we're
wrong
that
you
would
then
diagnose
on
now,
whether
it's
having
to
standardize
those
is
useful,
not
sure,
but
on
I
mean
so
it's
physically
I'll
tell
you
what
NSS
does
on
NSS
when
you,
when
the
handshake
fails.
Nss
returns
like
one
of
that
two
hundred
error
codes
and
about
you
know,
30
of
those
error,
codes
or
I
received
your
word
X
and
you
know
the
other
170
or
so
I'm,
going
as
a
whole.
D
Without
much
or
something
went
wrong,
and
here
is
like
exactly
they
went
wrong
right
and
so
on.
Rather
the
attempting
to
standard
I
understand
eyes.
This
I
think
I
be
tempted,
given
that
you're
almost
at
the
modify
your
software
to
fix
it
I
think
I'd
be
tempted.
You
just
say
like
here
is
a
free-form
error
with
symbols
they
should
shove
in
and
you
can
interpret
yourself.
All
right
now
would
be
more
useful,
probably
and
boring.
D
You
know
boring
a
cell
using
positives
error,
codes
on
and
any
attempt
in
China
trying
to
hate
those
error
codes,
except
the
particular
words
that
TLS
actually
using
the
wire
or
intended
to
tell
the
other
side
something
about
it,
but
they
were
in
a
really
environment,
very
different,
Bowl
here
now
which
to
say
you
know
one
where
you
didn't
have
to
go
over.
It
I
mean.
A
I
think
the
after
I
get
I,
get
what
you're
saying
that
sort
of
makes
sense,
but
I'd
still
like
to
see
any
broad
class
of
error
code
that
was
repairable
like
you
need
to
use
it
certain
with
a
different
algorithm
or
even
ones
that
were
just
log
a'
belen.
A
consistent
way
by
you
know
a
cloud
system
to
understand
what
was
going
on
from
a
sort
of
analytics
and
metrics
point
of
view.
I'd
rather
see
those
be
reported
in
a
common
form
between
the
various
browsers.
D
In
that
case,
I
think
they're
only
two
real
options.
You
know
what
is
to
say
is
to
have
a.
Maybe
it
is
easier
for
me
to
both
these
one
is
to
say
I
can't
alert.
I
said
this:
lor
I
received
a
solar
right.
What
do
you
want
to
do
both
obviously
on,
and
you
always
never
wanted
to
say?
Oh
it's
always
the
case,
you,
sir.
What
are
you
received?
One?
D
There
are
a
few
X
cases
where
you
send
receive
notes,
but
you
know
that
particular
thing
was
really
really
badly
wrong,
that
you
might
have
match
errors
about
crossing
naturist,
but
on
the
and
then
a
and
then,
if
you
wanted
a
standardized
well
hot
doing
that
things
at
beyond
that.
So
don't
indifferent.
So
they
don't
go
sorry.
D
H
Get
put
down
in
the
minutes
and
correct
correct
maker,
so
there
should
be
something
to
whether
you
sent
it
or
received
it.
That's
additional
information,
that's
not
there
currently
and
in
addition,
I,
don't
think
we
talked
in
this
PR
about
any
of
the
mess
with
the
contents
of
the
message
which
I
guess
might
be
above
and
beyond
the
DTLS
pls.
D
Being
like
you
know
who,
what
the
on,
what
message
cause
you
be
sad
or
or
a
more
detailed
error
words.
It
was
with
a
specific
error
that.
E
No
I,
just
can
say:
I've
had
a
little
bit
of
experience
with
this.
In
the
last
couple
of
weeks,
I
tripped
over
a
chrome
bug
where
you
set
one
of
the
extensions
that's
mandatory
for
WebRTC,
but
not
mandatory
in
general,
India,
TLS
wasn't
being
set,
and
and
in
a
bit
bit
that
under
certain
circumstances.
So
that's
something
that
would
be
nice
to
feel
that,
but
it
won't
be
an
alert.
It
would
be
really
good
those
kinds
of
things
that
might
would
be
good
to
come
kind
of
bubble
up,
hey
I'm,
not
talking
to
this
guy.
D
I
I
believe
that,
yes,
that
I
can
see
have
a
happen.
That
would
be
unfortunate,
so
yeah
I
think
so
I
guess
I
was
just
we
do
both
I
suggest
we
just
that
we
modify
you
alerts
to
be
both
I
send
I
receive,
and
then
we
have
a
slot
for
I
leave
on
basically
tell
you
something
about
what
the
hell
happened
and
I
would
make
it
a
string
and
then
put
this
deliverables
with
that
and
it
at
the
worst
case.
You
don't
have
that
in
the
best
case
you
you
know
it.
D
J
D
Yeah,
that's
really
what
I'm
suggesting
I'm
suggesting
you
know
basically
I'm
suggesting.
Basically
what
we
return
would
be
NSS
error,
and
then
we
prick
I
mean
that
we,
then
we
just
print
out
life.
Do
we
certify
the
name
of
the
error
code?
Come
on?
That's
what
we
have
people
do.
This
would
like
the
oh,
hey
for
God's
sake.
That's
what
Firefox
actually
does
with
the
user.
If
you
like
go
to
some
website
a
gross
scale,
it
roads,
all
us,
it
I.
D
I'm,
indifferent
to
where
that
goes,
I'm
just
saying
that
we,
if
we
actually
are
serious
about
helping
people
to
vote
these
days,
I
think
that
would
be
useful,
but
I
do
firmly
happy
it
kale
at
Taylor.
I
shall
suggest
a
for
me
happy
to
have
a
you
know.
Some
generic
thing
that
was
like
or
just
suggested
like
here
is
essentially
I,
said
a
free
for
review,
no
way
about
what
happened
we
find
so
we.
A
D
Mean
to
be
Oregon
where
we
happy
happy
birthday,
I
think
I
think
the
only
change
we
should
like
have
a
we
should
have
it
be.
They
should
have
a
bit
boy
that
was
like
I
sent
this
lower
core
ever
see
this
one
yeah,
okay,.
H
Okay,
I,
don't
think
Fulop
is
on
the
call.
So
I'll
try
to
explain
this
as
best
as
I
can
we've
been
using
frozen
array
as
a
static,
read-only
attribute,
I,
think
Fulop
objected
to
that
and
I
think
he's
been
saying
it's
illegal
of
IDL
and,
as
a
result
is
proposing
to
replace
these
instances
of
frozen
array
with
a
get
method.
F
Yeah
this
is
gonna
work,
I,
think
it's
to
clarify.
Don't
it's
not
so
much
as
it's
illegal,
but
that
the
freezing
that's
frozen
right
is
shallow.
It's
not
recursive,
so
it's
only
the
array
itself
that
will
be
frozen
and
the
object
you'd
be
returning
would
actually
be
modifiable,
which
limits
their
usefulness
and
I
believe.
In
these
two
cases
it
made
more
sense
to
return
sequence,
which
is
defined
as
a
copy.
F
Every
time
you
get
it
and
that
would
be
like
saner
as
far
as
what
can
happen
in,
if
you
really
you
could
do
a
lot
of
wrong
things
with
the
objects
you
returned.
Otherwise
that
could
cause
action
at
a
distance.
I.
Think
there's
the
PR
here
doesn't
show
it,
but
there's
one
remaining
place
where
we
did
use
same
object,
which
was
in
the
event
where
it
still
made
sense,
because
I
meant
such
a
short-lived
object
that
if
you
trash
this
object,
that's
not
going
to
have
remote
effects
on
the
code.
H
H
F
J
But
basically,
if
you
want
to,
you,
know,
convey
some
information
about
which
track
is
which
you
can't
really
use
the
track.
Ids
your
life
play
anymore.
You
have
been
something
else
like
M,
IDs
or
yeah
M,
section
entities,
so
next
slide.
I
think
we've
sort
of
talked
about
this
informally
had
a
tee
pack
and
at
other
times,
but
it's
continued
to
cause
confusion.
So
I
think
we
should.
J
If
we
decide
to
leave
it
as
it
is,
we
should
probably
document
it
better,
so
people
aren't
surprised
when
track
IDs
don't
match
or
you
care
I
also
consider
doing
something
more
severe
like
routinely
to
track
ID
signaling
altogether.
So
I
don't
know
if
they
beat
you
late
for
this
or
try
to
work
around
the
problem
in
some
way.
For
example,
I
don't
know
if
this
would
work,
but
you
know
with
random
idea.
J
B
C
Main
concern
with
the
track,
ID
stuff,
is
assumptions
that
the
sender
and
the
receiver
share
the
same
tracker
ID
and
which
is
not
necessarily
always
the
case,
and
quite
honestly,
I
don't
see
why
that
should
ever
be
the
case,
because
it
also
confuses
things
when
you
have
things
like
replace
track.
I
think
you
know
any
assumptions.
The
two
of
them
are
linked
should
be
broken.
K
For
kiddie
tracks
that
have
you
sitting
all
together,
yeah
I
mean
frankly,
I
feel
like
yeah,
for
the
reason
like
what
Reynolds
mentioned,
you
know
there
are
many
cases
where
the
ID
signaling
just
doesn't
really
work.
You
know
once
you
get
into
depth,
you
know
if
you
do
replies
track
now.
It's
really
a
coupling
between
the
sender
and
receiver
residents
track,
they
Petrak
the
output
track
and
then
the
input,
the
sender
receiver
identified
by
their
mid-70s,
been
the
main
person
I.
Think
he's
been
pushing
on.
K
A
K
J
K
So
Taylor
where's
the
case
where
this
really
kicks
in
this
is
where
you
create
your
receiver.
You
know
she
was
created
on
the
caller
side
like
immediately
upon
a
transceiver,
and
so,
if
you
go
and
like
inspect
that
track,
you
don't
know
what
the
right
track
of
you
should
be
there
until
you
get
the
right
description,
yeah.
F
F
F
A
Looking
at
reducing
the
amount
of
work
for
editors
and
getting
to
see
our
here,
I
think
I
sort
of
lean
towards
let's
get
rid
of
track,
ID
all
together,
because
the
existing
stuff
that's
going
to
break
is
going
to
break
anyway,
and
this
seems
like
a
really
complicated
and
confusing
people
to
explain
to
explain
to
implement
or
such
that
they
don't
shoot
themselves.
Notebook.
K
A
J
Was
looking
on
that
you're
such
a
rid
of
the
subtract
I'd
be
hard
setting
us
MS
ideas,
media
stream,
ID
and
media
stream.
Stuff
still
works,
so
it
is
tab.
Young
AE,
equal
dem
s,
ID,
with
a
string
ID
for
each
M
section,
and
now
that
we
can
match
tracks
to
two
streams,
if
you're
not
doing
the
early
media
thing,
such
as
the
rights
out
streams
fired
in
the
trap
event
right
now,
it's
like
media
streaming.
K
F
B
F
Floor
in
some
way,
I
mean
removing.
It
doesn't
really
do
anything
other
than
perhaps
clarify,
but
there's
sort
of
a
low-level
thing
and
people
using
yacht
VI
might
still
have
expectations.
So
I
think
we
should
either
remove
all
the
ID
part
or
documented
or
clearly
an
API
or
both.
You
cannot
we're
the
stream
ID
goes
across
the
trackage,
rather
have
to
say
well
exactly
it's
confusing
Cindy.
I
J
B
K
F
Just
adjust
it
speak
to
the
third
bullet
and
that
would
be
sort
of
a
hack.
I
would
call
that
the
observer's
paradox
anti-pattern
since
since
you'd
be
actually
I
mean
you
could
actually.
As
long
as
JavaScript
does
not
ask
for
the
attribute,
it's
still
secret
and
you
could
modify
it
behind
the
scenes.
But
that
leads
to
action
at
a
distance
and
that
some
benign
looking
code
might
think.
It's
totally
innocent
to
get
the
attribute
early
and
then
it
would
actually
cause
the
idea
to
never
update.
So,
basically
one
do
that,
but
don't.
I
F
I
F
K
I
I
F
I
F
K
B
K
K
A
J
J
They
do
reasonable
into
removing
it
from
them
aside.
You
attribute
I
agree
that
we
shouldn't
go
down.
The
third
bullet
point.
It's
kind
of
like
we've
got
some
sharp
edges.
You
can
step
on
or
there's
a
pic.
You
can
fall
in
or
something
and
either
we
document
that
dissipates,
they
don't
walk
over
there
or
we
try
and
make
a
pit
somewhat
smaller
somewhat.
Let's
see
me
to
fall
into,
or
we
just
give
it
up
a
bit
well,.
I
I
was
thinking
of
it
from
one
of
the
save
track.
Id
we
still
have.
We
still
consider
a
new
track
until
you
actually
get
something
on
the
remote
track.
It's
it's
muted,
so
it's
kind
of
a
definitely
to
have
any
source.
Could
we
say
that
as
long
as
as
long
as
it's
muted
and
it's
not
have
any
fingers
backing
backing
it
up,
it
could
be
the
track.
Id
could
be
this
nonsense
and
will
actually
get
a
track
ID,
giving
providing
information
from
the
other
side
until
it's
been
unmuted
for
the
first
time.
B
A
F
So
so,
just
to
be
clear
that
if
we're
talking
about
removing
the
ID
from
the
msid
signaling,
there's
one
edge
case
today,
where
it
still
works,
the
track
ID
is
synchronized
and
that's.
If
you
call
such
remote
description
answer
call
set
on
description
in
that
case,
set
remote
description,
creates
the
most
sent
the
sender
or
the
receiver
on
that
side
and
neck.