►
From YouTube: WebRTC Working Group Virtual Interim June 7, 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
So
the
CR
review
completed
on
May
31st
107
new
issues
were
filed,
so
everyone's
been
very
busy
and
thank
you
for
all
those
issues
we're
going
to
try
to
target
some
issue
clusters
and
related
areas
today
and
hoping
we
can
get
some
direction
on
those.
We
are
continuing
to
solicit
feedback
from
implementers
on
features
not
on
their
radar
implementation.
I
think
we've
got
most
of
that,
but
there
was
one
thing
left
on
the
agenda
for
today
about
the
virtual
meeting.
A
B
A
A
For
discussion
today,
we've
got
topics
on
relating
to
tracks
and
exact
removals
stuff,
like
that,
the
data
channel
DTLS,
search
and
algorithms
and
then
objects
and
a
few
miscellaneous
things.
Hopefully,
we
can
get
through
all
of
this,
but
we'll
see
I'm
going
to
hand
it
over
to
Taylor.
Now
who's
going
to
deal
with
fields
relating
to
tracks.
C
B
C
So
this
cluster
of
issues
is
basically
to
figure
out
how
tracks
relate
between
the
sender
and
the
receiver.
At
some
point,
there
is
an
asymmetry
where,
if
you,
you
know,
call
a
dragon
on
top,
the
cat
appears
on
other
side
who
call
you
jack
the
retractors
root
on
other
side,
but
with
the
introduction
of
transceivers
and
you're,
the
media-
and
you
know,
sort
of
the
last
major
pivot
to
the
API
on
the
stove
and
occur
anymore,
because
upon
a
remotely
the
keep
track
basically
corresponds.
C
Did
everything
received
the
specific
RTV
sender
which
could
be
multiple
tracks
on
sender,
side
and
the
fury
track
on
the
server-side
media?
Can
still
you
receive
later,
so
it
doesn't
into
track
on
the
receiver
side
anymore,
one
or
remove
it
and
so
see.
I
mentioned
the
bullet
here.
Section
5.1
said
that
when
you
remove
attract
the
end
of
adventure,
fire
on
the
other
side,
but
I
believe
this.
It
just
leftover
text
and
I'll
see
any
reference
towards
that.
C
You're
going
is
actually
fired
and
such
and
so
the
3d
talks
about
the
muse
events
being
fired.
When
you
know
RTP
timeouts
occurs,
but
you
know
this
is
different
than
the
immediate.
You
know
event
that
you
would
get
previously
after
a
new
round
of
signaling.
So
as
I
understand
it
right
now,
the
only
thing
happens
if
you
call
the
move
track
and
you're
out
signaling
on
in
both
sides
that
the
transceivers
direction
changes,
and
so
the
questions
is
acceptable
or
do
we
need.
C
C
D
Yeah,
basically
so
I
think
what
is
in
the
spec
right
now
would
be
quite
a
breaking
change
because
of
Chrome
and
Firefox
today,
use
add
stream
and
that
fires
ended
on
animal
tracks
and
I
would
stop
working
by
the
end
of
the
air.
If
we
implemented
a
spec
and
also
for
Firefox,
you
can
also
use
add
track
and
as
far
as
track
and
the
end
of
the
event
for
Admiral,
basically
and
even
chrome
does,
if
you
use
adaptive
j/s
so
I
see
an
established
pattern
already.
D
That
I
think
could
lead
to
web
combat
if
we
stopped
firing
ended
and
basically
the
background
for
those
read.
The
blog
was
that
in
2014
we
switched
from
streams
to
tracks
basically
and
they
used
to
be
on
add
stream
and
on
remove
stream,
and
we
switched
over
to
a
track
event,
but
instead
of
having
a
track
removed
event
at
that
time
we
said
now
we
don't
need
that,
because
we're
not
firing
ended
on
the
track.
So
that
has
been
in
this
pack
in
some
form,
including
this
leftover
text
ever
since.
D
So
when
transceivers
one
had
it
I,
don't
know
how
obvious
such
personally
I
was
actually
confused
for
a
long
time.
I
didn't
realize
that
the
early
media
meant
that
you
wouldn't
get
remote
signaling
in
a
formally
under
than
event
anymore.
So,
unfortunately,
the
event
leftover
text
test
lingered
for
a
long
time
and
I'm
wondering
it's
honest.
If,
if
that
somehow
undermines
consensus,
because
you
know
people
see
text
in
the
spec,
that
reaffirms
their
own
view
of
things
and
they
say,
like
Frick,
have
to
weed
me
further.
A
D
So
I
also
see
my
issue
final.
Is
this
one?
We
want
to
talk
about
all
the
issues
around
this
at
once
or
because
there's
one
issue
is
to
propose
is
to
to
add
back
the
into
the
vent
the
way
and
we've
a
40-mile.
Basically,
so
then,
as
I
understand
it
and
I
me
know
if
I'm
jumping
ahead,
that
would
mean
that
if
you
set
direction.
D
On
the
remote
end,
if
you
set
direction
in
a
way
that
causes
the
track
to
stop
your
remote
track
to
stop
receiving,
basically,
then
an
ended
event
would
be
fired
on
the
track
and,
basically
later,
if
that's
record
resumes,
so
you
get
a
start
receiving
again.
A
new
track
event
would
fire
that
would
either
have
the
same
track,
ID
or
different
track.
D
D
E
Question
here
I
it's
not
clear
to
me,
and
maybe
you
were
just
getting
in
this
yellow
bar.
It
is
that
when
we
change
direction
or
when
we
set
a
direct
when
we
set
a
given
track
to
be,
you
know
only
flowing
one
way
for
a
little
while
and
then
it's
going
to
go
back
to
two-way
or
something
like
that
right.
E
I
think
it'd
be
nice
for
applications
to
get
information
about
that
happen
in
some
relatively
easy
way,
but
I'm
I
think
I
would
tend
to
view
it
as
an
attribute
on
the
track
and
not
that
we
destroy
the
track
and
create
a
new
track.
If,
when
every
time
the
direction
changes.
A
F
A
Different
from
ended,
so
so,
for
example,
if
you
do
replace
track,
would
know,
then
that
will
result
in
muted
on
the
other
side,
but
at
least
transceiver
dot
stop
results
and
ended
because
it's
permanent,
you
can't
restart
the
receivers
of
the
senders,
and
so
on
the
other
side,
do
you
get
ended?
So
that's
at
least
one
distinction
right
now
is
that
at
least
in
some
of
the
spec
it
may
not
be
consistent.
Is
it
end?
A
E
D
Problem,
though,
with
the
mute
event,
is
that
the
muted
event
can
fire,
for
many
reasons
it's
from
a
media
cat
respect,
and
it
says
that
the
user
agent,
basically
being
called
it
at
any
time.
There
are
also
over
constrained
events
in
them
getting
a
user
spec.
That
would
also
call
it
so
there's
not
much
that
can
be
inferred
from
it
would
be
wrong
for
an
applications
I
think
to
to
do
on
mute
or
them
infer
that
oh,
the
track
has
been
removed
now
so,
but
you
can't.
D
Yes,
that's
true,
I
think
what
this
comes
down
to
is.
If
we
want
to
preserve,
we
still
have
add
track
and
roll
track
in
the
spec
and,
in
addition
to
a
transceiver,
and
they
they
they're
almost
the
same,
but
they
differ
in
how
you
approach
the
same
problem
so
for
people
who
use
a
track
and
remove
track,
we
want
to
preserve
the
existing
expectations
that,
when
you
remove
a
track,
it
actually
ends
remotely
but
also
gets
removed
from
the
stream.
D
That's
the
other
thing
I
want
to
talk
about,
is
add,
track,
introduces
spring
relationships
to
tracks
and
to
remove
track,
presumably
removes
those
again,
and
that
should
hopefully
be
reflected
remotely
that
a
track
that
got
removed
from
the
stream
and
the
peer
connection
would
then
be
removed,
remotely
and
ended,
but
both
ended
and
removed
from
the
remote
stream.
Some
except
I.
D
E
E
C
You
know
being
metal
door
in
this
well,
tell
me
Michael,
you
try
very
hard
and
we
introduced.
You
know
during
media
and
transceiver,
hey
guys,
the
consuming
our
trap,
work
like
it
did
before
and
that's
why
there's
a
bunch
of
special
case
logic
where
we
have
to
say
you
know,
try
to
match.
You
know
the
track
to
existing
transceiver,
recording
these
rules
and
when
saying
your
load
description,
you
know
match
with
transy
was
created
by
at
attract
especially
etc.
C
C
D
So
I
think
what
I,
what
I'm
proposing
is.
Basically
that
I
would
like
to
know
what
the
use
case
is
entire.
Let
me
back
up
so
some
people
who
don't
want
this
behavior
can
already
use
replace
track
and
there's
no
renegotiation
any
mean
if
written
appreciation
happens
after
used
to
replace
track,
say
you
want
to
temporarily
stop
sending
this
video.
You
do
replace
correct
null
and
there's
no
written
renegotiation
needed
to
do
that.
The
sender
just
stops
sending
so
presumably
I.
D
Forget
you
get
black
on
the
other
side
in
that
case,
but
it
should
probably
and
later,
if
you
want
to
turn
the
video
back
on
your
place
tracked
back
in
the
video.
So
it
seems
like
users
who
want
that
behavior
can
just
use
their
place
track.
So
I'm
curious
about
the
difference
in
that
and,
in
addition
to
replace
Technol,
also
setting
the
direction
to
reflect
that
we're
not
sending
its
but.
D
G
C
It
is
someone's
using
the
Train,
T
rear
and
said
director
you
guys
and
they
don't
need
to
be
listening
to
track
events.
You
know
the
first
place.
They
can
write
their
code
entirely
in
transit
or
dates
way.
So
I
mean
this
mainly
about
compatibility
with
people
who
are
right.
You
know,
use
the
track
based
model.
G
C
A
A
D
G
G
C
D
G
C
G
C
D
G
D
The
burden
of
proof
might
also
be
said
with
and
that,
if
we're
going
to
break
that
penalty,
we
should
make
sure
usage
is
low
enough
to
do
that
right.
So
I
was
interested
in
the
set
direction.
What's
the
use
case
where
you
would
need
to
renegotiate
with
and
set
direction
to
temporarily
to
enact
them
for
that
direction,
if
you
will
or
receive
only
what's
the
use
case
there,
that
will
be
broken
by
by
this.
If
you
don't
set
direction,
you
you
just
get
to
keep
your
track
and
transceivers
worked
fine
I.
C
H
I
C
D
Much
I
like
to
think
that
the
the
worms
on
the
other
side
here,
because
the
when
we
switch
from
screens
to
add
to
tracks
part
of
the
reason
for
that
was
to
untangle
tracks
as
a
control
surface
to
the
sender,
and
we
had
sender
and
receiver
objects
instead
and
those
represented
the
sendings
point
and
the
recipient
point
for
the
connection.
So
tracks
are
no
longer
tracks,
are
the
result
and
the
source
of
peer
connection.
So
what's
the
point
I
would
ask:
what's
the
point
of
having
a
receiver
object
and
the
track
is
up
there?
D
One-To-One
I
mean
they
don't
need
to
be
one-to-one,
that's
why
we
have
receiver
dot
track
so,
and
it
seems
that
it's
more
symmetrical
to
me
that
you
would
have
you'll
be
able
to
add
in
a
little
different
tracks
that
may
or
may
not
go
through
the
same
dinner.
You
receive
one
or
more
tracks,
conveyors.
C
C
D
If
you're
adding
tracks,
then
they
get,
then
you
have
a
remote
land
stream
that
you've
attached
to
oh,
say
you're,
playing
it
back
in
an
amiga
element
or
whatever.
Then
those
tracks
get
added
to
that
screen.
If
you
remove
them,
we're
now
we're
now
no
longer
removing
them
from
the
screen
right
and
they
stick
around.
So
you
have
all
these
they're,
not
even
dead
they're,
just
ghost
tracks
that
are
as
far
as
I
am
tested.
D
If
you
do
that
to
a
media
element,
at
least
in
two
browsers,
they
it's
sort
of
a
luck
of
the
draw
if
it
ends
up
playing
the
right
one,
so
I
would
ask
how
is
an
app
supposed
to
to
detect
removal
of
tracks
today,
I
mean
when
we
break
this,
there's
no
there's
no
ready
way
to
do
today
to
write
code
in
JavaScript
today
that
will
not
break
in
the
future.
If.
D
G
D
D
E
E
Please
track
no
that
keeps
sending,
though,
that
key
so
understand
that
there's
couple
things
of
happening,
one
is
controlling
whether
black
sent
or
not.
But
the
other
thing
is
about
bandwidth
usage,
whether
you're
continuing
to
send
packets
or
not.
So
you
need
some
way
to
stop
the
packets
are
being
sent
to
at.
D
E
E
D
B
I'm
really
sitting
now
and
trying
to
make
some
notes,
but
I,
don't
I,
don't
I,
think
I
hear
support
for
no
change
in
dispatch
action,
an
album
from
the
majority
of
people
and
I
guess.
So
someone
has
said
that
if,
if
I
could
add
some
data,
we
could
reconsider.
So
is
there
a
way
to
add
counters
or
something
to
see
if
this
is
well
actual
problem
or
yester
an
edge
case.
G
C
A
C
A
I
C
B
C
G
Think
actually
they're
crazy,
perhaps
to
actually
remove
tracks,
while
thinking
and
it's
probably
going
to
be
very
few
I-
think
most
of
them
just
add
them
and
then
connect
so
they're
done
and
then
out
of
the
ones
that
do
remove
track.
I
think
very
few
are
going
to
have
any
logic
based
on
what
the
remote
set
they
found.
This
need
to
be
ended
event,
or
rather
the
end
of
state.
G
D
Still
seems
confusing
to
me
that
even
for
our
new
users,
that
removing
a
track
from
a
sender
does
not
in
fact
remove
the
remove
track
from
the
screen
since
add
track
was
the
one
that
bound
that
track
to
the
screen.
So
there's
a
very
asymmetrical,
confusing
API
I
think
you
can
add
things.
We
can
never
remove
them
from
the
remote
strain
from.
C
I
will
decide
that,
oh
you
know
a
year
ago
or
no
you're
kind
of
all
the
crazy
ways
to
make
a
track
continue
work
that
we
decided
that
the
track
remove
trash
in
any
work
that
we
should.
You
know,
act
a
metal
work
and
not
just
half
and
I.
Don't
think
this
takes
assume
that
applications
don't
remove
tracks
today.
Anybody
know
I
didn't.
G
D
Well,
I
respect
the
way
it
is
now
we
did
not
say
that
add
track
and
remove
track
is
legacy
right.
So
I
understand
the
viewpoint
that
everyone
should
do
side,
transceiver
and
understand
that
model.
But
that's
not
what
we've
done
in
the
spec.
We
kept
ad
tracking
and
we
will
track
in
there
and
it
is
a
leaky
abstraction
of
sorts.
Why
we're
for
basic
expectations
having
a
remove
track,
not
remove
the
track
animal
stream
when
it
does
that
in
all
the
applications
today,
at
least
to
improvise?
Oh
wow,.
G
:
to
be
clear,
like
we're
talking
about,
ended
event,
not
removing
the
track
from
the
remote
stream.
We
decided
not
to
modify
the
remote
stream
like
way
back
when
we
first
decided
to
move
from
ad
stream
to
add
track.
I,
don't
even
think
that's
on
the
table
at
all.
The
question
is
just
whether
the
remote
track
changes
its
state,
not
whether
it
gets
removed
for
the
the
remote
of.
C
G
Well,
I
mean
right,
chrome
is
up,
chrome
is
not
moved
over
to
add
and
remove
track,
we're
still
an
advocacy,
so
it
makes
no
sense
to
say:
well,
chrome
doesn't
participate,
so
we
should
keep
doing
it.
That
way.
We
need
to
change
the
API
we
have
in
chrome
completely
so
saying
we
should
continue
with
chrome
does
as
no
sharing
in
this
regard.
D
C
D
I
D
D
I
D
D
So
use
usage
of
remove
streams
of
beautiful.
Unfortunately,
a
Mozilla's
telemetry
requires
a
lot
of
lead
countries.
We
have
to
ask
our
questions
to
hand
in
Suchman
so
that
it
would
take
a
while
to
get
answers
that
way.
If
the
process
way
to
scan,
they
should
be
archived
that
might
be
more
fruitful.
I
know,
Philip
has
done
good
work
there
and
detecting
usage.
So.
E
C
D
G
Want
my
car
down
that
path,
like
it's
just
really
timid
cases,
so
well,
here's
one
last
shot.
Here's
one,
my
shotted
to
create
the
idea
before
we
I'm
give
up
and
go
gather
telemetry
or
whatever
with
this.
Would
this
be
too
crazy?
The
first
time
that
the
in
line
goes
inactive
either
because
the
remote
track
or
set
Direction
the
track
gets,
are
moved
from
the
remote
stream,
but
it
was
not
far
the
ended
event.
G
C
G
E
G
Like
a
one-time,
it
gets
removed
from
the
stream
once
it
never
gets.
Added
back
in
for
this
one
time,
because
it's
just
trying
to
reflect
the
fact
that
you
call
the
loop
track.
That
has
the
oddity
that
when
you
call
set
direction
and
active,
it
also
removes
it
from
the
stream.
But
it's
probably
something
that
no
one
would
ever
notice.
So
why
we
have
it's
only
work
for
the
first
cycle
of
a
boot
track
right.
G
Well,
fine,
if
you,
I
guess,
if
we're
calling
add
track
again
and
it
gets
added
again,
then
if
you
call
a
root
track
again
and
we
get
removed
again,
but
but
I'm
saying
that,
should
it
be
determined
by
set
direction,
you
do
if
you
call
set
direction
and
active
set
direction
active.
I
wouldn't
expect
it
to
come
back
in.
A
G
Like
you
know,
if
that
does
happen,
and
that's
what
we
want
to
run
the
text-
maybe
that's
not
too
crazy,
I'm
just
saying.
Instead
of
firing
the
end
of
the
vent
right,
we
use
the
state
of
the
track
in
the
stream
as
indicating
that
it
is
being
tied
to
the
inactivity
in
a
way
that
could
work.
That
would
give
much.
G
C
Well,
I
thought
you
didn't
want
it
because
we're
Kentucky
an
injured
suspect,
but
we're
not
suggesting
that
I
think
we're
just
came
out.
Complexity
is
when
resolving
dings,
oh
no,
that
is
cutting.
This
is
much
like.
You
got
the
one-to-one
relationship
between
the
receipt
of
the
track.
I
got
standing
Street
by
actually.
D
G
B
D
Mean
what
I
like
about
it?
I,
don't
like
to
walk.
Call
me
one
part
part,
but
it
would
if
we
did
that
continuously
as
I'm,
not
that
being
a
model,
because
if
we're
going
to
understand,
if
there
was
a
way
to
distinguish
ad
track
and
remove
track
from
set
direction,
we
could
we
could
solve
this
better
right.
The
division
so
status,
the
behavior
at
least.
Would
let
people
write
JavaScript
today
and
they
would
change
their
code
now
stop
they
have
a
lead
time
to
change.
If
they
are
looking
for
ended
they
could.
D
They
may
already
be
looking
for
remove
a
stream
removed
on
removed
and
stuff
like
that,
so
that
would
never
give
a
Bridgeway
and
I
like
that.
That
idea,
and
also
like
it,
would
literally
mediate
because
in
early
media
the
API
already
forces
you,
because
it
just
gets
the
track
earlier.
You
don't
get
to
stream
early.
So
in
that
case,
early
meeting
users
will
already
have
put
that
track
away
and
made
a
new
media
stream.
D
I
F
C
We
cook
before
we
move
on
is
Fon
plan.
You
know
a
couple
problems
of
that
or
that
assumes
of
the
other
legacy
applications
would
be
doing.
This.
Discord
are
willing
to
stream
traffic
on
the
event
and
not
just
looking
for
the
attract
ended
event,
and
you
know
this
would
only
work
if
you
actually
have
streams
and
not
for
using
to
track
without
any
strings
right
yep.
E
D
Presumably,
you
can
get
early
media
for
both
audio
and
video
right
and
they're
not
going
to
you're
not
going
to
access
to
the
stream
yet
because
the
track
event
hasn't
even
fired.
So,
presumably
those
things
two
things
implementation
still
knows
to
keep
those
in
sync.
Even
if
the
JavaScript
hasn't
it's
not
like
things
go
out
of
thing.
The
second
you
move
a
track
from
one
stream
to
another,
so
I
think
the
streams
at
this
point
are
just
more
organizing
tools
for
the
app
that,
rather
than
a
control
surface
for
syncing,
that's
right,
yeah,
I,.
E
G
I
B
C
B
D
D
D
B
D
C
Remember
if
we
already
had
this
discussion,
but
they
play
initially
notice.
Is
that
saying
about
description?
We
would
discard
any
correct
reordering
application
produces
we
did
except
pandas.
So
there
is
time
in
between
and
the
description
is
called
and
you
know
the
communications
have
switches
to
the
new
codec.
That's
on
the
top
of
the
collects
tubing.
The
application
could
call
set
boundaries
to
set
up
after
the
code.
You
want
to
use
and
I
just
Majan.
This
could
cause
issues
because
I
am.
A
C
E
C
G
C
Life
is
our
preferences
or
what
color
screen
receives
that
I'm
talking
about
our
to
be
centered,
offset
parameter,
is
changing
the
code
of
ascent.
So
if
you
know
the
browser
is
preferred
devolved
for
an
airline
start
there,
knowing
points
in
preferred
pathologies,
critic
a
and
we
receive
the
initial
remote
author.
You
call
set
parameters
to
change
it
to
be,
and
then
is
the
answer.
Oh
right,
yeah,
Sam
and
later
you
do
another
offer
answer
exchange
and
the
answer.
E
E
C
Don't
yeah
exactly
that's!
That's
the
issue.
Is
there
a
note
author?
Then
nothing
happens
until
you
buy
the
answer
to
it
sometime,
but
it's
you
know
a
local
author.
Remote
answer,
then,
is
no
one
day
and
I
don't
believe
any
browser
has
implemented
to
be
a
codec
Salina.
No
Chrome
has
been
kinda
Firefox
recently
and
albicans
I'm
going
to
code
a
free
order.
C
Nina
is
currently
satisfied
so
because
I
don't
think
it's
too
late
to
introduce
a
change
to
how
the
separators
is
allowed
to
change,
codecs
and
ortc
as
a
critic,
Taylor
type
field
in
the
encoding
printers.
So
basically
you
know
you
use
the
pay
like
to
point
to
going
to
codecs
and
fees
that
then,
basically,
we
could
just
see
that
as
long
as
the
previously
selected
codec
is
still
in
the
list
now
in
the
new
remote
searching
cases
affected.
E
Guess
that
makes
me
wonder
if
we
want
to
do
something
like
that,
whether
we
should
just
have
a
way
of
saying
the
application
to
say
it's
preference
list
is
ABC
regardless
of
what's
negotiated,
and
if
C
and
B
get
de
gauche
eiated,
then
it
will
pick
the
highest
one
in
the
application
preference
less
that
was
negotiated.
Is
that
sort
of
the
scheme
we
eventually
happen
with
or
doesn't.
G
So
the
issue
here-
and
this
goes
back
to
when
we
first
added
the
codecs
to
set
parameters.
The
issue
here
is
when
you
get
the
remote
description,
is
basically
the
remote
side
saying
to
you:
please
send
this
codec
and
then
the
application
is
calling
set
parameters
to
say
explicitly.
No
I,
don't
care
what
your
what
you
asked
for
I'm
going
to
send
what
I
want
so
the
set
codec
preferences
is
for
what
we
generate
in
our
own
offer,
or
answer
that
we're
going
to
send
to
the
other
side.
A
C
C
It
now
I,
don't
see
any
problems
with
saying:
there's
the
codec
payload
I
field
on
the
encoding
pairs
it
was
on
set
the
browser
uses,
the
no
promoting
points
or
codec
is
that
they
use
one
selected
by
application,
and
you
know
this
applications
responsibility
to
go
change
that
and
as
a
new
restrictions
arrive
and
the
set
of
code
exchanges
negative
if
an
applications
using
this
API
mvs
in
general.
What
we're
doing.
E
Argued
for
blowing
it
away
every
time
you
got
a
new
offer
answer
was
that
what
you
had
there
before
might
not
be
consistent
with
the
current
offer
answer
and
just
became
really
complicated
to
try
and
figure
out
how
you
Spector,
our
wrote,
like
you,
know,
take
your
old
preferences,
or
at
least
the
ones
that
make
sense
out
of
your
older
preferences
and
apply
them
to
the
new
thing.
It
just
became
confusing.
E
Said
we
preferred
codec
B
and
then
the
next
round
of
negotiation
offered
codecs,
D
and
E,
but
you
still
say
you
have
your
coffee,
codec
B
I
mean
that's
that's
sort
of
case
I'm
talking
about
I'm,
not
saying
we
couldn't
solve
this
case.
We
probably
could
write
something
would
work
you're
right,
I,
just
on
it's,
not
a
nice
dinner
is
almost
ours.
Reason
against
it.
C
It
does
only
reason
against
it.
I
would
say
that
I
can
resolve
easier
by
just
saying
you
know
it
goes
back
to
being
upset
and
using
the
default.
Preference
and
location
should
decide
in
what
I
want
you
Siri
sessions.
You
know
break
the
case
where
ATP
goes
baby
for
eight
years.
Abc
and
you
know,
application
can
juice
which
to
see
it
once
or
can
do
not
do.
G
I'm
throwing
around
all
right,
I
I
think
one
of
my
afford
might
be
if
you
were
able
to
write
a
paragraph
that
expressed
that
in
a
way
that
covers
this
case
and
then
and
I
propose
that
as
a
solution
and
see
if
we
are
happy
with
it,
because
I
think,
if
your
other
third,
if
you
could
write
a
paragraph
for
PR,
for
example,
that
covers
what
Cohen
is
suggesting
in
a
simple
way,
doesn't
introduce
too
much
complexity,
then
I
think
that
that
would
be
a
good
solution.
Just
in
my
opinion,.
G
J
The
one
example
I
can
bring
to
your
fighting
right.
Now
is
basically
our
IDs.
You
can
easily
create
all
kind
of
weird
scenarios
where,
like
set
parameter,
says
like
I
want
these
three
are
DS
and
then
the
set
remote
description
doesn't
match
the
thing,
and
you
will
have
to
figure
out
what
you
do
about
it
either
you
take
like
the
minimum
subset
or
you
throw
an
error
or
something
along
these
lines,
but
basically
the
whole
set
parameters.
Thing
can
cause
all
kind
of
negotiation
failures
or
equation.
J
C
C
But
I
don't
think
you,
this
song
pasque-dieu,
so
really.
D
C
C
All
right,
so
this
is
an
issue.
I
think
was
taught
by
a
couple
people
interview,
and
maybe
everyone
wasn't
aware
of
this
behavior,
but
each
stage
animal
has
we
have
some
form
of
buffer
and
when
this
buffer
is
whole
and
ten
is
called,
the
video
channel
is
closed
abruptly
I'm,
not
following
that
CP
closing
procedure
and
application
can't
send
me
hitting
anymore
with
it,
and
this
was
done
to
match.
C
Websockets
and
I
tried
to
do
some
digging
into
why
this
decision
was
made
for
WebSockets
and
the
explanation
as
far
as
I
understand
it
is
that
if
they
had
decided
to
throw
an
exception
when
this
condition
occurred,
they
were
worried.
That
means
an
application
might
just
ignore
the
exception,
and
then
you
can
see
you
trying
to
send
data
and,
as
a
result,
you
have
you
know
one
message
that
didn't
get
sentenced
and
another
message
like
that.
C
But
that
last
part
of
the
reasoning
doesn't
apply
to
other
PC
data
channels,
I
believe
because
a
lower
GC
data
journalism
point
to
because
normally
as
a
result
of
like
an
FTP
timeout,
it's
a
nice
restart
typically
would
have
an
inverse
or
connectivity
before
that
happens.
So
I
don't
think.
Where
would
you
he?
Users
are
writing
code?
C
You
know
that
expects
a
channel
to
close
during
late
and
yeah
there's
any
time
someone
does
hit
this
so
I
propose
that
we
diverge
from
WebSocket
here,
and
you
know
we
already
used
some
other
places
that
wouldn't
be
the
you
know
the
first
time
and
just
thrown
exception
when
send
is
called
a
mistake,
and
in
fact
you
know
today,
I
can't
with
both
behave
like
a
non-blocking
socket
then,
where
I
used
to
keep
sending
until
I
started
to
find
back
pressure
and
then
a
weight
for
the
rubber
mount.
Well
of
that.
I
Yeah
I'm,
generally,
okay,
with
this,
your
reasoning
about
the
difference
in
how
closes
happen
and
are
likely
to
be
expected
is
probably
reasonable.
The
you
know,
obviously
applications
will
make
exactly
this
sort
of
error
that
eat
that
is
referred
to
in
the
WebSocket
side.
It
will
call
sin
they
will
not
check
the
result,
not
have
an
exception.
Handler
and
things
will
get
lost
now,
if
it's
in,
if
it's
a.
I
I
They
have
to
deal
with
that
somehow,
either
by
handling
a
closed
or
by
handling
the
exception,
because
they
have
to
have
some
code
to
handle
it.
Anyways
they
normally
wouldn't
have
other
code
to
handle
random
closes
it's
reasonable
to
say
that
you
know
the
code
you
have
to
have
to
handle.
This
is
an
exception
handler.
We
might
want
to
make
this
very
obvious
somehow,
but
I
don't
know
forcing
them
to
have
some
code
to
handle.
The
problem
is,
you
know,
is
a
reasonable
thing
or
requiring
them
to
have
some
code,
a
LeBrons,
a
reasonable
thing.
I
E
And
no
rattle
you
are
doing,
we
should
you're
saying
basically
we
should
do
what
Taylor
is
proposing
here,
as
I
said
that
yes,
okay,
I,
agree,
I
mean
the
big
the
closet.
The
closing
without
noticing,
like
is
just
like
everyone.
I
explained.
That
too,
is
like.
You
got
to
be
kidding.
What
were
you
guys?
Drinking
I.
I
I
B
A
The
first
one
is
relating
to
DTLS
failures.
We
talked
about
it
at
the
last
interim,
but
then
we
had
the
issue
of
when
how
are
the
DTLS
failures
fired
and
and
so
forth?
Currently
we
have
rtcpeerconnection
dot
on
fingerprint
failure
which
covers
fingerprint
verification
failures,
but
doesn't
cover
other
detail
s
errors,
and
then
we
have
PR
one
one,
one
five.
The
proposal
in
that
one
is
to
utilize
RTC
d
TLS
transport
on
error,
so
have
a
non
error
event
handler
for
the
detail:
s
transport
that
will
cover
all
DTLS
errors.
A
The
first
step
of
that
is
to
add
a
DTLS
failure
to
the
RTC
error,
detail
type
and
that
has
received
alert
for
an
alert,
that's
received
and
sent
alert
for
a
value
of
detail.
S
alert,
sent
I
guess
another
question
would
be:
do
we
need
to
add
distinct,
fingerprint
failure
to
the
RTC
error.
Detail
type
taylor
mentioned
that
RC
81
22,
section
6.2,
mandates
that
both
clients
and
servers
terminate
with
a
bad
certificate
alert
on
a
fingerprint
mismatch.
E
H
E
I
find
so
I'm,
not
I'm,
not
sure
this
change
is
what
we
should
do
it
all
by
just
like
I
didn't
really
realize
that
81
22
said
that
no
one
does
that
it's
nearly
impossible
to
collect
yeah
it's
nuts
right
I
mean
like.
Can
you
imagine,
like
you
know,
people
were
trying
to
mirror
what
TLS
for
HTTP
does
an
HTTP
most
certainly
does
not
send
an
alert
when
the
CN
name
doesn't
match
the
name
you're
expecting
or
something
so
I
really
I
suspect.
Maybe
this
section
6.2
stuff
should
get
free
work,
but
I'm.
C
C
E
I
mean
I
thought
we
should
map
this
event
of
the
fingerprint
failure
up
to
the
JavaScript
layer.
I'm,
not
arguing
that
in
the
slightest,
but
like
these
dealers
like
get
delivered,
reliably,
I
think
right
in
in
in
detail
apps.
So
you
know
no,
you
can't
pretend
II
got
lost
right
and
you
don't
like
so
we're
talking
about
whether
we
think
it
delivers.
E
You
know
I
mean
we
should
either.
If
we're
going
to
do
this
as
alerts,
we
really
need
to
do
them
as
alerts
not
just
like
pretty
to
half
pretend
we
were
sort
of
doing
alerts,
but
not
doing
them
and
I
I
suspect
people
find
it
surprisingly
difficult
to
do
this
as
alerts
or
to
do
what
this,
what
a
120
to
suggest.
C
E
Be
interesting
to
see
the
TLS
working
group
review
the
change
to
TLS
that
we
just
made
over
an
M
music
right,
I
think
that
they
may
have
some
comments,
but
ignoring
that
I.
Don't
think
it
really
changes
too
much.
What
we
need
to
do,
which
is
I
mean
I
I,
see
what
you're
saying
is
it's
how
what
we
all
sort
of
agree.
We
need
to
report
this
fingerprint
failure
up
we're
just
discussing
like
how
what
container
we
deliver
it
in
right
right.
A
A
E
A
Let
me
put
it
this
way
so
currently
in
the
PRD
r105,
we
do
have
the
fingerprint
failure.
Rtc
error,
detail
type
is:
are
there
objections
to
keeping
that
there
I.
A
A
A
A
E
Guess,
when
I
really
think
about
it
as
long
as
I,
isn't
you
when
writing
an
application,
can
clearly
figure
out
what
happened?
I,
don't
really
care
what
the
container
is
that
delivers.
This
is
so
much,
but
if
I
have
to
start
writing
complicated
code
to
tear
apart
alerts,
to
figure
out,
it's
a
bad
certificate
to
find
out
that
I
had
a
fingerprint
match
or
if
I
don't
get
the
fingerprint
matter
at
all,
because
no
one
implements
the
the
alert
for
bad
certificate.
That
would
make
me
sad.
C
Quite
concerned
common
flier
implementations
to
fire
events
with
sent
alerts
bad
certificate,
even
if
they
don't
actually
implement
sending
others
it
just
matter
what
you
know
put
flavor
given
comes
in.
Is
it
running
up
separate
or
not,
and
I?
Don't
see
why
it
should
be
a
separate
event
if
it
already
could
be
covered
by
an
alert.
E
A
C
Guess
I
need
to
think
about.
That
seems
like
argument,
sir,
to
be
yes,
that
there
that's
on
Yamaha,
okay
by
reasoning.
C
B
A
This
one
came
in
from
fit
fit
bow
it's
issued
1250
and
he's
saying
that
in
WebRTC
PC
the
Detailers
transfer
doesn't
provide
a
way
to
obtain.
The
local
detail
asserts
the
transport
was
created
with
you
know
what
to
see
you,
you
can
get
them
now
in
PR
1130.
We
clarified
that
RTC
configuration
dot
certificate
if
it's
not
specified
in
the
constructor,
subsequently
get
configuration
that
certificates
is
undefined.
So
if
you
didn't
want,
if
you
didn't
specify
any
certificates,
you
do
they
still
get
generated.
A
The
default
search,
but
get
configuration
won't
retrieve
them
and,
as
a
result
of
that,
you
can't
use
get
configuration
that
certificates
to
retrieve
default
certificates.
So
I
guess
the
question
for
the
group
is:
is
there
a
need
to
retrieve
default
certificates
because
that's
I
guess
what
CIPO
is
asking
for
here,
because
you
can't
you
can't
do
it
through
gate
configuration,
dot,
certs
and
I?
A
Well,
that's
that's
the
next
affecting
the
next
slide
deals
with
that.
The
only
the
only
thing
use
case
I've
heard
is
like
to
try
to
figure
out
what
your
default
type
is
like
it's
RSA
or
ECDSA,
but
it's
been
pointed
out
that.
Why
would
you
care
about
that?
Because,
if
you
wanted
to
like
say
you
had
a
legacy
at
interoperate
with
a
legacy
app
that
only
did
RSA
well
just
go,
create
an
RSA
cert
all
the
time.
You
don't
really
need
to
know
what
your
default
is.
A
Basically,
the
question
was
asked
how
to
tell
if
a
cert
was
RSA
or
UCSD
si,
presumably
for
the
default
search
and
then,
as
a
result,
we
added
get
algorithm
in
PR
for
99,
but
subsequently
we
realized
that
without
a
way
to
actually
retrieve
the
default
search,
you
couldn't
actually
use
get
algorithm
only
you
could
only
use
it
for
the
application
created
search
and
presumably
you
could
just
store
the
key
gen
algorithm
used
to
create
those.
So
it's
purely
convenience,
and
so
the
proposal
and
PR
1160
s
just
removed
get
algorithms.
E
Think
that's
fine
I
want
to
just
make
out
just
say
one
thing,
though,
about
the
the
storing.
It
is
keep
in
mind
these
you're
going
to
have
to
store
it
across
like
starting
and
stopping
the
browser,
and
things
like
that
right
I
mean
if
you're,
if
you're,
creating
a
certain
storing
it
in
an
index
DB
and
you
might
ever
invent-
want
to
know
what
type
it
is
you're
going
to
need
to
also
store
what
type
it
was,
maybe
in
the
same
index
DB
but
somewhere
right.