►
From YouTube: W3C WEBRTC interim July 2019
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
A
B
B
B
C
C
The
introduction
here
is
to
describe
what
I
call
perfect
negotiation
and
I'd
like
you
to
imagine
what,
if
you
could
add,
remove
media
to
and
from
a
live
rtcpeerconnection
without
worrying
about
state
glare
role,
meaning
what
side
you're
on
and
what
condition
the
connection
is
in
we'd
simply
call.
For
instance,
you
know,
PC,
add
track
track
stream
and
that's
it.
The
track
appears
remotely
and
behind
the
scenes.
C
Negotiation
is
written
one
and
it's
oscillated
from
the
rest
of
your
application
logic
using
a
nice
candidate
on
negotiation
needed
and
you're
signaling
on
message,
and
these
are
written
perfectly
where
on
message
is
written
to
handle
glare,
meaning
to
see
its
compete,
competing
about
sending
an
offer
a
handle,
Hanlin
glare,
using
wall
back,
and
is
this
not
know,
I,
think
chrome.
575
now
supports
an
ago.
She
ation
needed
there
were
some
bugs
in
it,
but
right
now,
Firefox
is
the
only
one
browser
to
implement
rollback.
C
D
C
Reveals
r-spec
api's
to
be
racy
and
Claire
Chrome.
So
that's
what
a
lot
of
these
issues
are
about
to
fix
our
api
s--
so,
but
I
want
to
so
next
slide
so
that
here's
some
illustrations
basically
so
the
highlife
little
application
methods
will
be
the
ones
on
top
and
track
creator
channel
and
that
kind
of
stuff,
including
transceiver
methods
like
direction
or
attributes
like
direction
and
set
streams
and
stop,
and
those
are
separate
in
my
mind
from
the
lower
level,
the
lower
level
signaling
methods
that
can
be
all
abstracted
away.
C
Using
events
like
negotiation
needed
a
nice
candidate
next
line.
So
perfect
negotiation
really
means
to
have
those
negotiation
and
methods
written
once
and
then
the
application
log
doesn't
have
to
deal
with
it
anymore
next
slide
and
can
now
even
manage
a
peer
connection
on
either
end
using
only
these
methods
and
glare
is
solved
in
negotiation,
heated
using
rollback.
So
that's
that's
the
holy
grail
and
that
sort
of
works
in
Firefox.
Now
we
fix
some
bugs
and
but
it
didn't
covered
a
lot
of
ugliness
in
our
API
ax.
So
next
slide.
C
So
here's
some
so
we're
diving
right
into
the
hardest
one
I
might
have
we
sorted
some
of
these
slides
I
wanted
to
tackle
the
what
I
thought
were
the
most
pressing
ones
first,
so
the
stop
on
a
situation
is
a
long-standing
one,
so
I'm
going
to
try
to
explain
it
with
some
slides
and
the
problem
and
show
a
PR.
That
I
hope
is
that
I've
discussed
some
with
Henrik
as
well.
That
we
think,
is
the
best
solution
to
this.
C
So
here's
the
chart
again
using
I'm
going
to
use
this
slide
a
lot,
so
let
me
set
it
up
is
like
on
the
far
left
and
the
far
right
side.
You
have
the
application
logic
on
either
side
and
in
the
middle
you
have
the
negotiation
logic,
and
so,
whenever
you
call
I,
create
data
channel
or
add
track
in
this
case,
the
offer
is
on
and
the
offer
is
always
on
the
left
and
the
answer
is
on
the
right.
So
a
change
happens
on
applications.
One
tick
on
the
Left
negotiation
needed
is
fired.
You
get
set.
C
Local
description
offer
goes
to
the
other
side
which
receives
it
and
does
a
applies.
A
set
remote
description
offer
and
then
generates
an
offer
like
the
create
offer,
ends,
are
sort
of
implicit
assume
that
they're
called
as
well,
and
then
he
gets
that
local
description
and
sort
of
goes
back
to
the
offer
and
on
the
remote
end
you
also
have
created
a
channel
at
track
and
all
these
things
those
are
not
really
picked
up
on
in
the
as
the
answer
is.
That's
part
of
the
answer
is
stage
except
for
stop
all
those
methods.
C
If
you
call
that
track
there,
that
fires
negotiation
needed,
but
that's,
but
that
the
answer
basically
says
I'll
hold
on
we're,
going
to
wait
with
negotiation
needed
until
we're
back
to
stable
state,
because
that's
much
simpler
and
in
that
case
the
rolls
end
up
being
reversed
and
an
offer
will
come
out
from
the
answer
side
and
the
heiress
will
go
the
other
way
and
you
can
basically
or
you
can
reverse
the
diagram
and
switch
which
ones
down
further
in
the
answer.
So
next
slide.
C
So
today
this
is
Woodstock
on
the
offer
side.
Everything
works
great,
you
called
you
have
two
transceivers
TC
1
and
TC
2.
You
call
TC
1,
stop
the
the
jsf
basically
creates
a
0
port
that
could
sent
over
to
the
other
side.
The
other
transceiver
gets
stopped.
Everything
is
wonderful
and
they
come
back
to
stable
state
on
both
sides
next
slide.
C
So
here's
the
stop,
bundle
problem.
What
happens
now
if
the
amps
are
calls
TC,
TC
1,
stop
and
that's
a
little
different,
because
and
technically
speaking,
this
is,
if
you
call
TC
1
stopped
right
inside,
have
remote
offer
or
right
before
set
remote
description.
Offer
is
called
so
you
can
even
call
it
in
stable
state
and
it's
still
a
problem.
What
happens
here
is
if
you
try
to
stop
the
first
time
saver,
TC
1,
that's
also
the
offeror
tag,
end
line
and
there's
no
affordance
in
JSF
or
bundles.
C
That
ends
up
stopping
a
transport
for
everyone
in
the
answer
and
there's
no
way
in
vamo
JSF
to
to
switch
around
the
Trinity,
the
transport
to
one
of
the
others
and
time.
So
what
happens
when
you
get
it
in
the
answer?
I
end
up,
stopping
both
try
to
see
every
T,
so
you
wanted
TC,
2
and
Hoover
is
sad
about
that.
So
next
slide
so,
and
this
says
the
same
thing.
C
C
The
other
use
case
is
the
low
level
expert
that
wants
to
reject
and
offer
an
EM
line
in
time
for
the
answer,
and
so
next
one
and
it's
actually
worse
than
we
thought,
because
I
loaded
two
already
is
that
the
current
spec
language
in
stop
assumes
that
this
is
only
a
problem
in
have
remote
offer
when
in
reality,
it's
a
problem
even
in
stable
state.
If
you
can't
stop
and
stable
the
way,
the
model
is,
there's
no
way
to
know
what
comes
next.
If
what
comes
next
is
set,
the
local
description
offered,
then
you're
fine.
C
However,
if
what
comes
next
is
set
they're
not
prescription
offer,
then
you
have
this
problem
and
even
the
language
we
haven't
stopped
today,
which
says:
if
we're
in
have
remote
offered,
then
take
care
of
stopping
all
this
other
transceiver
JavaScript
objects
does
not
work.
So
how
do
we
fix
this?
And
basically
this
is
an
inherent,
a
sub
problem.
There's
Jason
only
has
one
idea
of
stopped
and
it's
synchronous
and
once
you're
in
that
state
there's
no
way
out
of
it.
C
C
Now
this
defines
Jase
up
a
bit
which
doesn't
anticipate
and
has
no
affordance
for
creating
a
stop
offer,
while
not
also
being
a
stop
transceiver.
So
that's,
but
I
think
we
can
solve
that
because
one
way
I
look
through
JSF.
It
wasn't
that
many
on
the
references
to
stopped,
so
we
explored
a
solution
that
avoids
avoids
JSF
basically
next
time.
C
So
at
this
point
you
might
wonder:
do
we
really
need
stop
so
I
put
in
the
slide
to
remind
people
why
it's
important
in
plan
B?
This
was
very
common.
People
would
just
call
PC,
add
track
when
the
participant
enters
and
then
PC
remove
track
tender
when
the
participant
drops-
and
they
would
do
this
over
and
over
again
and
there
would
be
lots
of
participants
joining
and
leaving.
Everything
was
fine
and
I
think
in
plan
B.
It
just
cleaned
up
resources
automatically
I,
don't
know
exactly
the
details,
but
that's
how
the
code
is
written.
C
Unfortunately,
in
unit
plan
in
a
unified
plan,
this
accumulates
resources,
because
the
transceiver
remains
even
in
the
API,
when
you
call
remove
track.
This
is
just
setting
the
direction
of
your
transceiver
to
inactive,
but
it's
still
there
and
we
change
this
back
where
it
used
to
end
tracks.
It
now
mutes
remote
tracks,
instead
of
ending
them
because
they
can
resume
because
they're
still
there
so
the
API
now,
sadly
for
many,
it's
complicated,
because
it
supports
two
models,
two
ways
of
thinking
the
old
way
and
then
they
transceiver
way.
C
So
what
you
have
to
do
in
the
API
two
is:
do
it
when
you
call
add
track
and
remove
when
you
call
remove
track
when
the
purchases
have
been
drops.
You
also
have
defined
the
transceiver
for
that
sender
and
you
have
to
stop
it
and
the
browser
cannot
automatically
stop
it,
because
this
stops
both
directions,
so
we
have
no
way
of
knowing
it
that's
what
the
user
wants.
So
this
is
like
it
or
not.
This
is
the
API.
Do
we
have,
and
then,
in
fact,
what's
becomes
clear.
C
C
If
you
later
call
add
track,
add
track
is
defined
to
attach
itself
to
transceivers,
so
this
will
attach
to
the
dummy-
and
you
don't
have
a
and
now
you're
back
to
square
one
and
as
I
said,
you
wanted
to
keep
a
transceiver
around
that
you
would
never
stop.
And
now
you
don't
have
that
anymore.
So
web
developers
would
then
have
to
either
avoid
track
outright
or
learn
to
you.
It's
only
a
transceiver,
but
that
is
different
semantics
and
it
won't
pair
up
the
remote
transceivers.
The
API
is
slightly
different
than
quite
ugly.
Another.
E
C
Another
problem
is
that
both
ends
up.
Do
it
both
ends
end
up
doing
this,
you
end
up
with
two
dummies,
which
is
seems
like
a
waste
and
also
confusion
over
the
order
of
transceivers
and
which
one
is
actually
used
for
the
transport.
But
ultimately,
this
work
on
does
not
solve
the
foot
guns,
because
people
will
still
need
to
actively
know
about
it
and
to
in
actively
try
to
avoid
it.
C
Stopping
effects
create
offer
only
not
crate
answer,
and
we
do
this
by
tricking
J
set,
because
jasa
only
had
like
a
handful
of
references
stopped.
So
we
avoid
this
problem
and
there's
one
place
where
we
have
to
say
when
you
actually
create
the
SDP,
we
have
to
say,
create
less
DPS
escalators
to
pee,
create
the
SVP
as
as
outlined
in
J
sub,
and
we
are
adding
the
language
with
the
exception
that
treated
stopping
transceiver
as
stopped.
Only
in
this
case.
C
E
So
so
it's
it's
the
same
thing
as
it
is
today,
except
that
it
won't
stop
anything
in
an
answer.
It
will
wait
like
it
won't
negotiate
that
it
stopped
until
the
next
great
offer,
meaning
this
there's
a
window
of
time
where
your
locally
you're
stopped,
but
you
haven't
received
the
Ragman
that
right.
The
other
end
knows
that
you're
stopped,
but
but
it's
it's
achieving
the
same
thing.
Yes,.
C
So
stop
already
today
has
asynchronous
part
to
it
and
then
negotiated
part
to
it.
So
the
synchronous
part
now
is
formally
called
stopping,
which
is
the
local
stop
and
that
will
still
send
our
tcp
by
to
the
other
side
and
it
will
end
track
a
transceiver
receiver
track.
So
you'll
have
ended
tracks,
but
it's
already
today
a
state
where
you
could
actually
receive
events
and
other
things,
and
so
this
is
sort
of
a
a
bit
uneven
state
where
one
side
is
stopped
and
the
other
is
not
yet.
C
But
but
the
good
part
is
to
highlight
the
good
part
is
that
we
cite
my
sidestepping
create
answer.
We
also
started
sidestep
to
hold
on
the
problem
and
we
haven't
made
any
exceptions
or
any
and
nothing
works
differently
for
the
first
transceiver
than
any
other
transceiver
and
so
you'll
see
in
the
web
IDL
here
so
I
have
more
slides
to
go
through
how
this
solves
it.
So
I'm
happy
to
go
back
to
the
earlier
slides.
If
anyone
wants
to
comment
and
then
I
can
push
forward
a
little
more,
so
there's
also
a
new
reject
method.
C
Here.
That
said,
that's
basically
the
old
stop
and
it
sets
the
stopped.
It
actually
should
say
it
probably
should
say
it
sets
both
stopping
and
stopped
in
the
sense
that
stopping
it's,
the
local
stop
and
stopped
is
the
local
and
remote
stop.
We
can
bike
shed.
Some
people
said
shouldn't
stop
and
go
to
false.
Once
you
go
to
stopped,
we
can
bike
shed
that
later
I
think,
but
it
works
the
same.
C
But
the
benefit
of
this
new
reject
meant
that
it
would
throw
an
error
and
that
the
state
or,
if
you're
not
in,
have
remote
offer.
So
it's
a
little
safer.
It
doesn't,
but
you
would
have
to
call
reject
and
then
roll
back
your
offer
after
that,
and
don't
do
that.
So
it's
much
more
safer
than
it
is
today
and
that
lets
people
who
still
want
to
reject
and
Lyons
the
old
way
to
still
do
the
most.
B
C
C
F
D
C
Order
to
move
forward,
I
suspect,
I,
would
approach
it.
This
way,
this
PR
breaks
up
the
existing
stop
into
two
methods,
stop
and
reject
two
functions
for
two
different
use
cases:
one
is
for
a
high
level,
I'm
done
with
resources,
clean
them
up
and
the
other
one
is
rejected
in
the
answer.
Please,
and
so
by
splitting
them
up,
we,
it
allows
us
to
talk
about
them
separately,
and
you
know
if
we
want
to
talk
about.
Deprecating,
reject
I,
think
that
we
could
talk
about
that
laughter.
C
C
Excuse
me.
So
how
would
if
you
remember
the
slide
from
before
we're
gonna
stop
the
ants
on
the
answer.
Side,
we're
gonna,
call
TC
one,
stop
and
see
what
happens
now.
So
if
you
see
the
one
there
there
little
burnt
part,
you
call
TC
one
stop
and
we
now
end
up
in
stopping
state
not
stopped
State.
So
what
happens
here
is
that
well,
the
assumption
of
this
chart
is
it's
showing
you
state
after
this
senate,
whole
thing
has
happened,
so
imagine
that
TC
one
made
some
change
unrelated
calls
them,
as
set
local
description.
C
Offer
comes
to
the
answer
side
to
set
remote
description
offer,
but
we
either
already
call
TC
one
stop
or
we
call
TC
one
stop
right
after
this
and
that's
the
race,
so
one
has
so
what
happens
now
to
solve.
It
is
that
if
you
see
the
monkey
they're
holding
is
here,
that's
the
jsf
monkey.
It
does
not
listen
to
the
fact
it
does
it
only
here
knows
about
stopped,
it
does
not
know
about
stopping.
So
it
says
la
la
la
I'm
just
going
to
create
an
answer.
C
That's
totally
fine
and
my
MacBook
went
into
screensaver
mode
hold
on
come
back,
and
so
what
happens
here
is
that
the
negotiation
completes
and
on
the
left,
there's
a
little
star
in
TC
1
TC
1
is
neither
stopping
nor
stop
yet
because
it
hasn't
heard
anything
about
stopping
the
only
thing
that
everything
appears
normal,
except
if
it
notices
it
might
notice
that
its
TC
1
receiver
track
has
ended
because
it
received
an
arc.
You
see
people
right.
E
C
The
other
side
excuse
me,
so
what
happens
after
everything
goes
back
to
stable
is
that
negotiation
needed
will
kick
out,
kick
up
on
the
REM
suicide
and
rolls
will
reverse,
and
this
will
send
out
well.
This
is
immediately
we
followed
by
next
slide.
Basically,
so
what
happens
next
is
that
stable
is
reached,
negotiation
needed
is
fired,
we're
still,
tc1
is
still
in
stopping
state,
even
though
it
says
stopped
in
the
diagram.
C
There's
a
little
star
there,
because
I
should
have
improved
this
slide
to
show
the
state
and
do
two
different
points
in
time,
but
this
slide
doesn't
afford
that.
So
this
time
the
Jacek
monkey
is
listening,
because
we
have
a
special
language.
That
said,
when
you're
creating
an
offer,
treat
stopping
as
stopped
so
Jace.
If
says:
okay,
I'm
gonna,
stop
the
port
is
Airport
and
that'll.
Stop
the
offerors
transceiver.
C
Well,
we'll
stop
the
transceiver
on
the
Left,
which
is
the
roles
are
reversed.
Now
it's
actually
the
answer
area.
So
this
is
just
a
regular
stop
going
the
other
way
and
when
the
answer
comes
back
set
remote
description
answer
will
still
set
stopped,
so
the
transceivers
and
both
ends
will
end
up
in
stop
state
and
everything's
hunky-dory
and
unfortunately,
transceiver
number
two
still
works.
C
So
that's
what
we're
going
to
solve
next
slide
and
it
has
the
simple
case
you
know
just
to
show
that
it
still
works
D
a
regular
way
when
the
offer
calls
TC
one
stop.
It
still
works,
because
the
Jason
monkey
is
listening
because
of
the
special
language.
We
added
that
stopping
should
be
treated
to
stop
in
that
case,
and
it's
just
regular,
it's
just
as
easy
as
it
was
before,
and
no
harm
done
and
again,
except
that
the
TC
one
will
be
in
stopping
state
initially
and
only
becomes
stopped
once
it's
back
in
stable
next.
C
So
here's
the
language
there's
a
pn
actual
PR,
so
I
put
in
the
language
here-
and
maybe
people
who
want
to
can
read
this.
While
we
do
questions
or
should
I
go
through
this,
basically
I'm
gonna
make
go
through
it.
So
when
stopping
it's
true,
it
indicates
that
this
transceiver
has
irreversibly
entered
its
stopping
procedure.
Ie
from
a
call
to
stop.
Transceivers
sender
will
no
longer
stand
and
it's
receiver
will
not
going
to
receive
they
stopping
transceiver.
That
is
not
stop,
needs
negotiation
and
that's
a
good
part.
C
So
the
updated
the
negotiation
needed
algorithm
has
such
an
explicit
line
in
SPR.
That
says,
if
a
transceiver
is
stopping
but
not
stopped,
it
needs
negotiation
returns.
True
that
way,
the
goal
is
that
stopping
there
are
cases
where
you
have
fixed
roles.
Not
everyone
uses
negotiation
needed,
so
you
could
end
up
in
being
in
stopping
state
a
long
time,
but
but
the
gravity
pulls
toward
this
transceiver
should
once
you
have
successful
negotiation
meeting
that
starts
with
an
offer.
From
this
end,
you
will
end
up
in
start
state.
That's
the.
D
E
E
C
C
It
has
two
places,
I
think
they're,
just
optimizations
for
creating
some
local
transport
objects,
but
as
far
as
I
could
tell
most
of
negotiation
needed
is
highly
orthogonal
to
whether
something
is
stopped
or
not,
which
and
I
tested
this
in
Firefox
today,
even
is
that
you
can
find
Firefox
today,
I
have
a
fiddle
for
this
and
a
good
hub
issue
you
can
receive.
If
you
call
you
know,
if
you
call
stock
on
the
offer
and
it's
easy
I
mean
you
get
a
zero
port
offer.
C
But
if
you
call
stop
right
before
on
the
answer
side
right
before
calling
set
remote
description
offer,
then
you
have
a
perfectly
valid
offer.
That's
not
stopped
that
you're
applying,
but
the
local
trends
team
has
been
stopped
in
that
case,
and
you
called
it
even
before
it's
that
remote
prescription
offer
you'll
still
get
events
firing
right,
you'll.
E
Objects
to
exist
right,
but
you're,
not
spending,
so
you
don't
need
an
included
not
receiving
you.
Don't
need
a
decoder.
You
you've
ended
the
receiving
tracks.
You
don't
need
an
image
buffer
like
anything
expensive.
It's
gone
other
that
you
have
to
keep
the
transport
support
relevance,
but
if
you're
using
bundling
so
you
know,
you're
gonna
have
one
port
open
all
the
time
anyway,
unless
you're
using
all
of
them,
in
which
case
now.
C
That's
a
good
point:
I
see
what
you
mean
that
you
internally
browsers
yes,
could
clean
up
resources.
We
still
have
to
have
the
important
as
far
as
API
exposure
to
transceiver
will
still
be
in
the
list
of
transceivers,
and
a
transceiver
will
still
have
a
receiver
track,
but
that
track
will
be
ended.
So,
yes,
you're
right
under
the
hood,
you
could
clean
up
resources.
Sure
good
point.
C
So
the
difference
here
between
stopping
in
stopping
and
stopped
is
that
the
stopping
says
that
current
see
where
that
is
stopping
will
cause
future
calls
to
crate
offer
to
generate
a
see
report
and
meet
a
description
for
the
corresponding
transceiver
has
to
find
the
jsf.
The
user
agent
must
treat
a
stopping
receiver
as
stop
for
the
purposes
of
JSF.
Only
in
this
case,
so
that's
the
only
way
place.
We
trick
JSF
basically,
and
it
says
how
are
to
avoid
problems
with
bundle.
C
C
This
is
the
stop
method,
now
stop
irreversibly
marks
of
transceiver
at
stopping
unless
it's
already
stopped,
and
this
will
immediately
cause
when
Seaver
send
her
to
notice
and
and
receiver
to
not
receive
calling
stop.
Also
updates
the
negotiation
needed
flower,
and
the
note
here
says
what
I
said
earlier.
A
transceiver
that
is
stopping
but
not
stop
will
always
need
negotiation
in
practice.
This
means
that
calling
stop
on
a
transceiver
will
cause
the
turns
saver
to
become
stopped
eventually
provided.
C
Negotiation
is
allowed
to
complete
on
both
ends
next
time,
and
this
is
the
reject
method,
and
this
is
almost
like
stuff.
Today
the
note
is
modified
to
say
this
method
may
only
be
called
between
applying
a
remote
offer
and
trading
an
answer
to
reject
em
lines,
and
then
it
goes
to
describe
the
bungle
problem
and
it
says
to
avoid
this
usership
instead
consider
using
the
safer
stock
method.
Yes,.
G
C
It's
better
because,
by
checking
on
a
signaling
stake,
the
method
only
works
in
in
the
signaling
state,
so
we
don't
have
to
treat
and
we
don't
have
to
work.
It's
solved
the
stable
problem.
What
happens
if
you
call
stop
in
stable
because
you
can't
reject
in
stable
state
basically
and
that
yeah
that's
an
important
problem,
because
we
don't
know
what's
coming
next?
Is
it
gonna
be
a
settler?
Can
offer
a
set
remote
description
offer?
So
it
solves
that
part.
The
only
way
you
can
get
in
trouble
now
with
a
foot
gun.
C
C
E
I
mean
if
you're
using
reject
you're
already
in
the
in
the
state,
are
sending
an
answer
so,
like
the
the
ground,
half
a
round-trip
time
to
get
there
like.
If
you're
sending
an
answer,
you
can
send
the
offer
as
well.
But
you
have
to
wait
for
this
to
get
an
answer
back
there
is.
There
is
some
additional
time
where
you
could
wear
your
dresses
at
the
risk
of
glare,
but
the
way
I
see
it
is
the
basic
likely
an
SDP
ping.
You
send
something
you
get
an
answer
back
instead
of
just
you
send
something.
E
So
it's
it's
I
think
it's.
This
is
an
optimization
you,
you
get
rid
of
an
offer.
Answer
exchange,
but
I
see
very
little
benefit
to
to
what
this
is
sheaves
and
it
achieves
this.
This
you
just
skip
an
offer.
Answer
exchange.
That's
that's
the
good
part.
The
bad
part
is
suddenly
the
car
API
users
have
to
care
care
about
offer,
tag
and
bundle,
and
it's
it's
like.
C
E
Still
a
foot
gun,
it's
still
an
API
that
it's
hard
for
me
to
get
behind,
and
it's
hard
for
me
to
imagine
telling
someone
like.
Oh,
you
should
use
this
API,
it's
hard
for
me
to
imagine
thinking.
Oh
yeah,
you
should
use
to
reject
API
in
this
case.
Okay,
I
think
I
just
say
just
use
up
and
you
don't
have
any
problems.
If
you
use
return
and
then
we
need
to
have
like
a
half
an
hour
lecture
so.
C
So
my
goal,
my
goal
was
to
reduce
the
amount
of
enemies
for
this
PR,
so
I
didn't
want
to
remove
any
functionality.
So,
yes,
III
I,
really
think
that
that
could
be
discussed
separately.
Maybe
it
reject
only
reflects
what's
existing,
what's
possible
in
the
existing
API
so
and
if
there
are,
there
might
need
a
broader
audience.
If
we're
gonna
remove
functionality,
then
I
could
see.
Maybe
there
are
some
like.
We
have
a
lot
of
functionality
that
has
been
taken.
A
lot
of
discussion
to
get.
C
E
And
I'm
fine
I'm
fine
with
having
that
as
a
separate
discussion
like
the
the
main
problem,
is
that
we're
introducing
a
concept
of
being
stopping
before
being
stopped
for
lunch
and
I?
Think
that
that's
that's
clearly
the
path
forward
and
like
the
opposing
reject
is
not
me
opposing
the
solution
to
this
problem.
It's
all
about
discussion.
Mr.
C
Biegler,
though,
internally
we
even
with,
if
we
can
clean
up
the
API,
we
still
need
to
have
a
concept
of
stopping
separate
from
stopped
as
internal
slots,
and
there
are
two
reasons
for
that.
One
is
because
we
need
to
keep
track
of
the
local
stuff,
because
in
cases
like
fixed
roles,
you
might
end
up
being
in
that
state
for
a
while,
and
you
have
to
do,
might
have
separate
negative.
Several
negotiation
is
completing
from
the
initiator
from
the
other
side
that
still
doesn't
bring
you
to
stop.
Okay,.
B
B
What
I'd
like
to
propose?
Can
we
try
to
get
consensus
on
on
the
two
pieces
here?
One
is
the
stopping
addition
of
stopping
and
the
other
is
reject.
Is
that
does
that
make
sense
as
a
way
to
kind
of
figure
out
where
we
are
sure,
okay,
so
I
guess
the
first
question
is:
are
there
any
objections
to
what
Yan
a
var
has
proposed
for
introducing
stopping?
Does
anybody
have
a
problem
with
doing
that.
B
G
E
C
E
It's
like
it's
like
an
album,
a
concise,
optimization
like
you,
don't
have
to
do
another
follow
up
offer
answer,
but
like
I'm
kind
of
like
so
what
like
doesn't
matter
and
then
you
mentioned
I
hadn't,
even
thought
about
it.
You
said,
if
you
use
reject
and
then
you
do
a
rollback
like
does
this
add
even
more
complexity
like
does
this
mean
that
if
you
use
this
API,
no,
we
can't
do
rollback.
No.
C
No,
the
neither
stopped
stop,
stop
both
stopped
and
stopping
cannot
be
rolled
back
and
that's
already
true
for
stopping
in
respected
a
so.
What
I'm
saying
is
that
the
only
way
to
get
into
the
foot
gun
to
get
out
of
the
safety
basically
is
to
then
call
stop
and
then
do
a
rollback,
because
the
spec
won't
allow
you
to
roll
back
out
of
stuffed,
which
means
you're
now
in
stop
states,
and
you
may
have
now
received,
but
that's
sort
of.
C
E
B
So
here's
here's
what
I'd
like
to
propose
based
on
this
discussion
that
the
the
part
of
this
PR
that
relates
to
stopping
right
we
can,
we
can
just
apply
it
right
and
then
we
should
smoke.
We
should
separate
the
out
the
portion
relating
to
reject
I
guess
into
a
separate
PR
and
as
a
now
there's
no
consensus
for
that
PR.
But
I
guess
you
know
we
you
can
ask
around
Yanni
bar-
and
you
know
maybe
make
the
case
later.
If
it
turns
out
where
we
missed
something.
Does
that
make
sense,
yeah.
C
B
C
C
Actually,
unless
the
proposal
a
here
one
of
the
workaround
ideas,
if
you
remember
the
workaround
problem,
was
that
proposal
a
might
still
have
some
general
value
to
people
and
that
you
can
call
a
transceiver
with
an
ineligible,
true
flag
that
basically
has
a
special
property
that
this
ncver
is
ineligible
for
reuse
by
add
track
just
wanted
to
throw
that
out
there.
Someone
likes
that
idea,
but
other
than
that
we
can
skip
this.
C
I
E
B
C
C
You
called
create
offer
away
than
they
pass
in
an
optional
argument,
and
that
allows
you
to
put
in
ice.
We
start
trip
and
that's
clever
accepted.
It
will
fail.
It's
ice
connection,
state
changed
ever
fires
outside
of
a
stable
state
and
I
would
be
worse.
It
would
be
an
intermittent,
so
you
might
not
even
catch
that.
Furthermore,
if
what
if
your
negotiation
needed
uses
rollback
to
implement
perfect
negotiation,
your
ice,
we
start
just
got
rollback
and
what
you
do
now.
C
So
the
proposed
fault
here
is
to
add
a
restart
ice.
A
first
class
restart
ice
method,
connection
that
effectively
sets
an
internal
slot
for
restart
ice
and
fires.
Negotiation
needed
importantly,
that's
only
cleared
in
centrum
of
description
answer,
meaning
that
negotiation,
a
random
negotiation,
has
completed
starting
from
your
end,
and
we've
already
implemented
this
in
Firefox
behind
the
press,
but
it's
not
landed
yet.
I
was
hoping
to
do
that
before
the
meeting,
but
it's
still
in
the
queue
there
and
the
biggie.
C
You
can
still
look
at
there's
a
link
here
to
the
web
platform
tests
and
we
wrote
for
this,
and
it
asks
these
important
properties
that
it
survives
the
rollback
and
it
causes
a
nice
restart
which
attests.
Obviously,
it
also
survives
a
remote
offer.
It
fires
negotiation
needed
and
it
returns
a
boolean
whether
you
know
calling
it
ended
up
doing
anything
and
whether
the
state
changed
the
internal
spot
and
it
also
checks
that
there's
some
corner
cases
where
there
might
be
in
remote
ice.
C
C
You
can
cancel
it
that
way
if
we
don't
get
rid
of
the
old
API
and
lastly,
it
survives
the
room
one
offer
containing
a
partial
restart
which
is
actually
possible
to
do
an
SDP,
because
these
the
port
0
is
per
transceiver.
So
this
method
does
all
that,
and
it
was
actually
it
didn't.
You
know
took
a
day
or
two
to
implement
actually
because
in
Firefox
anyway,
we're
late
like.
I
E
C
D
C
C
Yes,
so
now
I'm
there's
a
we're
down
to
a
triumvirate
of
race
issues
that
have
to
do
with
the
JavaScript
event
loop
a
little
bit
and-
and
this
is
where
I
actually
have
to
explain
how
I
did
perfect
negotiation
needed.
So
please,
if
there's
anything
unclear
here,
ask
along
the
way
so
this
without
further
ado.
C
So
if
you
look
at
the
JavaScript
here,
if
we
get
a
description,
we
basically
check.
If
the
description
is
an
offer
but
we're
not
in
stable
state,
then
we
need
to
do
something
different,
and
so
the
only
difference
inside
that,
if
statement
and
if
we
are
the
impolite
peer,
we
simply
just
ignore
the
other
side,
we're
the
impolite
one
we're
just
gonna
pretend
that
never
happens
that
we
return.
That's
the
if
not
polite,
return
statement.
C
So
all
of
the
rest
of
the
code
here
following
its
implementation
of
the
polite
pair
and
we
basically
there's
an
odd
construct
that
we
use
promise
all
to
call
two
methods
on
the
pic
connection-
object
right
away.
That's
set
local
description
with
rollback
and
then
we
basically
rolling
back
our
offer
that
we
had
because
we
were
not
in
stable
and
that
takes
us
back
to
stable.
So
we
can
then
call
set
remote
descriptions
with
the
incoming
description,
and
that
sounds
good,
and
that
takes
care
things.
So
there
are
only
remaining
question
here
is.
C
Why
did
we
have
to
use
promise
all?
Why
couldn't
we
just
a
wait,
set
a
local
description,
rollback
and
then
a
wait
followed
by
a
wait,
send
remote
description,
description
and
the
answer
there
is
in
the
last
line
here,
which
is:
if
a
candidate
comes
in
and
we
call
add
its
candidate,
and
that
can
happen
sometimes
yeah
and
there's
an
incoming
offer.
Every
offer
usually
is
chased
by
a
couple
of
candidates
that
belong
to
that
offer
right
after
it
right.
D
C
And
we're
inside
an
async
function
here,
which
is
really
just
a
promise
chain.
So
what
happens?
Is
that
that
that
candidate,
that
basically
I
own
message
may
fire
again
before
this
first
IO
on
message
has
finished
and
the
good
news
is
the
peerconnection
implements
an
internal
operations
cube,
which
means
that
you
can
already
call
asynchronous
methods
one
after
the
other
synchronously
on
the
peer
connection
and
the
peer
connection
will
dutifully
put
this
on
a
queue
and
only
process
one
in
time,
so
that
the?
C
If
you
call
two
methods
the
second
one,
will
only
run
after
the
when
the
first
one
completes,
which
is
great,
which
is
why
this
trick
works.
If
we,
we
use,
promise
all-
and
it's
almost
explained
easier
to
explain
the
workaround
for
an
expand.
The
prom,
if
we
use
promise
all
both
minutes
at
local
description,
roll
back
and
set
remote
description.
C
Description
get
queued
on
the
peer
connection,
object,
which
means
that
they
are
guaranteed
to
run
before
any
other
method.
You
then
call
on
peer
connection
will
get
to
run.
We
don't
do
this
if
we
just
keep
waiting
one
and
white
the
other.
We
leave
a
time
window
where
a
nice
candidate
could
come
in
beforehand,
and
that
will
mean
they're
not
in
have
remote
offer
yet,
and
that
method
will
fail.
So
and
this
works
except
you
know,
you
have
to
use
promise
all
and
know
about
all
this
stuff,
and
it's
gonna
do
that.
C
So
the
proposal
is
to
fix
this.
We
don't
need
to
use
promise
all
in
these
races
and
all
these
three
issues
are
Marion's
of
this.
So
next
Lane-
and
this
is
this
particular
case
to
solve
rollback-
we
can
have
a
I
think
the
API
we
had
for
all
bike.
What's
already
ugly,
it
said
local
description
and
you
bring
in
your
own
object
instead
of
the
description
and
has
a
type
of
fallback.
So
why
don't?
C
We
just
pass
this
as
an
options
argument
to
set
remote
description,
it's
simpler
and
it
ends
up
being
a
race
proof,
because
now
there's
only
one
method
that
has
to
complete
and
basically
set
remote
description
and
instead
of
invalid
state
offer,
if
we're
not
in
the
right.
If
this
is
an
offer
and
we're
not
in
there
and
not
in
stable
state
roll
it
back
to
stable,
so
that's
basically
the
proposal
there's
actually
two
parts
to
it.
One
is
that's
said
too
much.
C
I
set
remote
description
takes
this
options
argument
and
the
the
basically
it
says
what
I
just
said:
I
think
making
sure
I
didn't
miss
anything
yeah.
So,
basically,
now
once
set
remote
description,
isn't
cued
and
I
scan
candidate
cannot
beat
it
because
and
there's
a
JavaScript
note
here
that
when
you're
using
a
weight
it
everything
inside
in
the
weight
a
sync
function,
the
first
part
of
that
function
runs
synchronously
until
you
reach
the
first
awake
statement,
including.
D
C
Expression,
that's
immediately
after
the
away
statement
also
run
synchronously,
that's
important,
so
we're
only
awaiting
the
result,
so
we're
actually
calling
PC
set
remote
description
with
an
robach.
True
argument:
synchronously
in
this
case
we're
merely
waiting
for
its
result,
and
that
makes
it
glare
proof.
Question.
D
E
If
we
surprised,
if
considering
only
Firefox,
is
implemented
roll
back,
but
if,
if
one
is
to
start
from
scratch
and
implements
set
remote
description
with
roll
back,
is
there
any
reason
to
implement
set
local
description
with
roll
back
right?
Is
there
a
reason
to
give
users
of
the
API
it's
a
possibility
of
making
a
mistake
here?
Is
there
any
any
use
case
for
rolling
back
where
we're
not
actually
rolling
back,
because
we're
receiving
a
remote
offer
I
I.
C
Think
that
that
would
be
a
beautiful,
optimization
and
I
think
I,
don't
know
if
I
can
speak
for
all
Mozilla,
but
I
think
we
I
think
we
would
be
ok
with
considering
deprecating
that
if
that's
what
the
working
group
wants,
but
again
you
know
you're
talking
about
her
ruling
functionality,
which
I
was
trying
hard
to
avoid
and
one
can
to
solve
these
problems.
And
then
we
can
pare
down.
I
mean
I,
guess
rollback
is
feature
at
risk
already.
So
great
yeah.
D
C
Can
implement
someone
implements
this
version
first
and
not
the
other
one
I
guess
the
old
one
would
be
at
risk,
and
this
one
would
not
be
okay.
So
the
alternative
proposal
here
is
proposal.
B
is
to
always
do
this
implicitly
on
set
remote
description.
Then
there's
no
API
and
change
to
surface
at
all,
but.
C
A
C
E
E
Don't
know
I
I
kind
of
like
this
being
implicit,
because
if
it
ties
into
the
negotiation
needed
and
then
like,
if
we
have
perfect
negotiation,
but
I
can
also
see
how
it's
it
could
merely
to
unexpected
right
things,
if
it's
not
explicit,
so
I
can
kind
of
go
either
way
on
this
one.
My
initial
reaction
was
I
like
the
implicit
one,
because
it's
only
applies
when
you're
making
a
mistake,
but
I
can
also
see
that
hey
now
you
don't
know
you're
making
a
mistake
right.
C
I
guess
the
issue
with
the
implicit
one.
Is
that
rollback
isn't
necessarily
obvious?
Yes,
so
you
might.
The
JavaScript
might
find
itself
in
a
state
that
you
know
it
wasn't
expecting,
maybe,
but
then,
since
there's
no
other
way
to
interpret
their
intent,
you
could
also
interpret
their
intent
to
mean
that
well
you're
trying
to
apply
and
a
remote
offer
here
but
you're,
not
in
you
know
it's
stable
state.
So
what
did
you
mean?
C
B
Okay,
so
what
what
do
we
want
to
do
here
is.
Let
me
ask
a
question.
Let
me
ask
first
about
proposal
a
a
proposal
B,
it
is,
let
me
put
it
this
way.
Is.
J
B
B
C
It
looks
like
it's
less
explicit,
I
guess
right,
but
at
first
there's
also
a
proposal
C,
which
would
be
to
do
nothing
and
I
don't
hear
it
sounds
like
everyone
was
on
board
with
doing
either
A
or
B
going.
So
that's.
B
E
B
C
C
E
Right
yeah:
let's
do
this,
it's
a
good
point
that
that
it
makes
it
makes
not
supporting
rollback
means.
This
operation
behaves
differently
in
different
browsers,
right,
different
browsers,
I
think
that
that
would
be
an
argument
for
going
with
this
will
aid,
but
if
it's
gonna
be
implemented,
I
think
be
is
is
good.
K
B
Well
so
oh,
we.
B
C
B
Sounds
great
I
mean
yes,
but
it's
it's
not
gonna.
This
isn't.
This
is
one
of
the
more
complicated
things
so
so,
like
not
gonna
bet
that
it
will
be
completed
in
you
know
a
few
months
or
something
if
I
might
take,
it's
probably
the
kind
of
thing
that
require
a
good
spec
code
review.
You
know
all
the
usual
I'm
happy
yeah.
C
B
Let
me
let
me
put
it
this
way:
I
think
this
Inc.
This
increases
the
chance
that
roll
back
will
get
done,
because
now
it's
part
of
a
more
attractive
set
of
things.
I
mean
if
you
understand
what
I'm
saying
Dom
I
mean
roll
back
is
already
at
risk,
so
I,
don't
think
this
makes
it
more
at
risk
than
it
was
before.
B
C
A
I
think,
okay,
so
next
slightly
yeah
and
you
can
you
can
future
the
text,
whether
you're
doing
it
with
weather,
like
that
for
me
capable
of
doing
it
by
said,
yes,
cutting
a
local
offer
and
then
applying
a
remote
and
buying
a
fake
remote
offer.
Yes
good
point.
We
should
make
sure
that
we
have
different
errors.
So
two
cases
all.
C
Right
so
this
is
just
you
can
skip
this
slide
in
because
that's
existing
PR
language,
but
they
roll
back
boolean
all
right.
So
the
second
issue
would
the
polite
pure
exercise
reveal
that
there
was
a
similar
race
in
negotiation
needed,
meaning
that
negotiation
needed
itself
as
expert
Blair
prongs.
So
you
know
you
typically
write
PCO
negotiation
needed
and
then
you
do
a
wait,
create
offer
and
then
I
had
to
add
a
new
line
here
after
that
says,
if
PC
signal
state
is
not
stable
than
return,
why
wow?
C
This
funk
was
guaranteed
to
always
be
called
from
stable
state.
Only
and
that's
good,
except
a
weight
korean
offer
means
create
offer
takes
time.
So
by
the
time
we
come
back
to
this
function,
we
may
not
longer
be
in
stable
because
there's
a
race
here
with
an
incoming
offer
great,
which
means
that
psychological
description
will
fail.
What
and
the
third
line
will
fail
with
invalid
state
officers,
and-
and
this
can
happen,
I
mean
remote
offer
can
come
in
between
create
often
settle
description
and
who's
going
to
Renault
or
remember
that
or
over
some
rare
intermittent.
C
The
top
function
to
the
bottom,
one
where
we
simply
call
PC,
set
local
description
with
no
arguments
and
two
things
go
into
making
that
happen
proposal
a
is
basically
one
of
them
which
says
that
set
a
local
description
without
SDP
implicitly
calls
create,
offer
or
answer
if
needed,
instead
of
in
bounce
later
and
more
one
more
settle
description
without
type
in
first
type,
from
the
current
signaling
state.
Actually,
the
current
is
the
signaling
state
in
the
ink
and
a
peer
connection
Q
at
the
moment
you
get
executed
on
Q.
C
So
if
we're
in
a
state
that
you
know
have
remote
offer,
then
it's
an
answer.
Otherwise
it's
an
offer,
and
that
means
that
just
calling
PC
settle
description
implicitly
will
create
from
negotiation.
It
will
implicitly
create
an
offer
and
just
set
it
keep
it
simple
stupid.
It
sort
of
the
idea
there
and
any
thoughts
on
this
I
mean
I
think
there
are
more
slides.
Let
me
see
yes,
so
I
can
go
on.
C
C
It's
a
ritual
from
days
past
and
in
fact,
providing
a
description
is
identical
to
protocol
increate
offer
first
and
then
calling
cycle
description
only
with
the
type
of
offer,
because
the
spec
already
says
to
fish
out
last
crated
offer
in
turn
flatten
and
use
that,
in
fact,
if
you
try
to
set
anything
else,
it'll
fail
so
again,
and
the
same
is
true
for
the
answer.
So
the
next
natural
step
here
I
would
argue,
is
that
you
know
if
last
created
offer
is
null.
C
Instead
of
rejecting,
you
can
just
invoke
the
algorithm
right
decorating
offer
algorithm
before
proceeding.
So
there's
a
you
know.
These
two
slides
I
mentioned
the
proposal
a
and
B.
Both
though,
and
it's
a
hundred
percent
backwards
compatible
and
set
remote
descriptions
will
remain
unchanged
because
there's
no
such.
E
This
I
think
the
create
offering
create
answer
is
that
local
description
are
really
one
operation,
splitting
that
to
enable
STP
munging,
which
it
should
be
or
is
prohibited,
but
so
so
having
a
race
free
alternative.
The
gets
rid
of
this
historical
reason
to
do
them
separately
is
it
seems,
like
yeah,
of
course,
and
in
terms
of
implementing
it
I
think
I
think
it's
easy
and
I'm
happy.
So
what
do
you
like?
Henrik,
a
or
P.
E
I
want
I
want
type
to
be
explicit
so
that
you
say
whether
it's
an
offer
or
an
answer,
rather
than
it
being
because
otherwise
you
have
a
you,
have
a
hidden
input
to
this
function
where
so,
if
you're
debugging
code-
and
you
see
someone
calling
this
function,
you
don't
know
if
their,
which,
which
step,
is
it?
If
you.
E
B
C
E
Also,
if
you
have
any
any
bugs
or
any
races
somewhere
and
and
you're,
assuming
that
the
type
is
one
thing
with
that,
that's
checking,
then
you
won't
wouldn't
get
the
error
thrown
that
you're
in
the
wrong
signaling
states.
With
this
it
was
like
you
think
it's
creating
an
offer,
but
it's
really
creating
an
answer.
E
D
C
E
But
yeah,
but
so,
if
you're,
if
we're
merging
this,
then
you
are
you're
implicitly
creating
an
offer
or
you're
implicitly
creating
an
answer
as
part
of
setting
the
description.
So
you
are,
it
does
have
a
return
value
and
it
has
different
return
values
depending
on
which
input
it
has
right
either
either
you
say,
give
me
an
offer,
or
you
say,
give
me
an
answer
and
depending
on,
if
you
get
an
offer,
you
get
an
answer.
You
do
different
things
right.
C
But
you
can't
you
can't
you
can't
say,
give
me
an
offer
or
give
me
an
answer,
because
one
of
them
will
always
fail
depending
on
what
stick
you're
in.
So
you
just
like
Bernard
claim
that
the
assumption
is
already
that
the
JavaScript,
no,
the
developer,
has
to
know
what
state
they're
in
before
they
call
it
method
right.
C
C
B
E
H
E
C
B
C
C
C
Sorry
too
much
talking
with
me
so
and
basically
the
strategy
here
is
to
and
cue
all
the
methods
we
need
to
get
back
to
stable
state
immediately.
So
we
do
a
promise
all
we
set
the
remote
description.
We
create
the
answer.
We
call
cyclone
post
local
description
with
this
special
mode
that
I
covered
earlier
as
a
fun
fact
where
you
set
and
type
the
answer.
C
We
cannot
provide
the
argument
from
crate
answer,
obviously,
because
we
just
recalling
these
methods
synchronously,
so
we
don't
have
the
answer
yet,
but
luckily
this
works,
because
we
can
cue
all
these
three
methods
on
settler.
The
last
set
set.
The
local
description
will
pick
up.
The
last
created
answer
internal
slot,
and
this
will
just
work,
and
this
solves
an
important.
This
gets
us
back
to
stable
before
any
second
offer
can
come
in
while
we're
busy
responding
to
the
first
offer.
C
So,
even
with
all
the
proposals
that
we've
agreed
to
so
far,
we
still
can't
totally
get
rid
of
promised
all.
In
this
case,
we
can
call.
We
still
have
a
set
remote
description
list
of
the
code
below
here.
Promise
all
set
local
description
set.
Remote
description
sorry
followed
by
a
set
local
description
with
no
arguments
so.
C
A
G
A
A
C
A
C
C
But
what
I
wanted
to
solve
was
that
the
API
would
be
receptive
to
methods
sooner
without
running
into
this
signaling
estate.
I
got
these
signaling
state
collisions
was
basically
the
idea,
and
it
depends
on
depending
on
how
we
feel
about
these
I'm.
All
in
this
light,
I'm
also
making
the
case
that
basically,
that
show
this
shows
that
our
negotiation
methods,
where
we're
built
for
a
different
time
when
it
was
important
to
be
able
to
have
these
discrete
steps,
because
we
might
want
to
reject
em
lines,
for
example,
which
we've
now
gotten
rid
of,
reject.
C
E
To
two
points,
so
one
is:
is
yes
like
a
lot
of
these
things
that
are
four
steps
are
really
just
like
two
steps
or
like
like
right.
Whenever
you
do
an
offer
answer
you
kind
of
copy-paste
doing
this
and
whenever
you
set
remove
Description
offer,
you
always
follow
that
by
great
answers
that
look
at
the
description
answer
and
like
I,
don't
really
see
so
this
this
sort
of
makes
sense
in
this
to
just
yeah.
It's
really
something
you
always
do
so,
why
not
put
them
in
one
step?
E
So
it's
and
it's
would
be
simple
to
implement.
So
so
that's
I
think
that's
a
good
idea.
So
one
thing
like
if
we
want
to
be
lazy
and
not
do
this.
One
argument
against
this
is
so
it's
about
pushy
as
I
views,
and
so,
if
we
implement
perfect
negotiation,
I
don't
think
we
would
ever
have
a
pushy
peer,
because
the
peers
keep
track
of
signaling
state
and
I.
Don't
think
you
would
end
up
with
this
unless
I'm
mistaken.
E
B
E
Okay,
I'm
sure
had
a
my
my
point.
My
point
was
that
if,
if
like
perfect
negotiation
is
framed
in
terms
of
peer
to
peer
and
if,
if
an
effort
of
you
does
something
outside
of
perfect
negotiation,
it
does
doesn't
keep
track
of
signaling
to
stake.
It
just
keeps
pushing
with
new
offers.
You
could.
You
could
argue
that.
E
Well,
this
is
an
S,
if
you
use
case
and
guess,
if
you
could
just
tell
the
application,
hey
use
promise
at
all,
but
I
think
this
is
like
a
nice
API
even
outside
of
cushiest
of
you
use
cases
and
and
also
appreciate
fuses.
It's
a
use
case.
We
should
care,
but
I
guess
so.
I'm
just
contracted
contradicting
myself,
yeah.
C
A
E
It's
doing
something
that's
very
easy
to
do
anyway,
like
like
it
doesn't
seem
to
add
much
value
on
one
hand,
but
on
the
other
hand
it
doesn't
it's
not
that
difficult
to
implement,
but
like
this
would
be.
The
other
things
presented
here.
I
think
are
that
higher
higher
priority
and
this
one
seems
like
well.
If
we
have
time,
we
can
add
it,
because
why
not?
It
seems
nice,
but
it
doesn't
seem
like
this
is
needed
for
perfect
negotiation.
Like
no
I
mean
if
you
have
a
pushy
SFU,
then
okay
take
take
care
of
the
fact.
C
Right
this
would
be
a
method,
though
in
in
addition
to
an
existing
methods,
and
the
only
issue
would
be
our
people
aware
of
this
race
today.
I
guess
this
much
well,
because
it's
easy
to
I
agree.
It's
easy
to
do
without
this
method,
but
it's
also
easy
to
be
wrong,
so
that
would
be
my
argument.
I
think.
E
C
But
that's
just
you
would
see
an
occasional,
unbalanced
data.
In
that
case,
I
guess
you
would
be
able
to
learn
this
after
a
while
I
think,
Henrik
posted
a
good
comment
on
the
notes
here
and
it
can
appear
be
pushy,
so
I
guess
people
think
that
if
this
only
applies
to
the
pushy
has
a
few
case,
I
guess
the
expectation
is
that
you're
supposed
to
know
a
little
more.
What
you're
doing,
if
you
have
an
S
of
you
yeah
that.
E
A
B
C
You
could
have
a
peer
acting
as
a
pushy
as
a
few
people,
or
at
least
pushy,
then
your
heart
will
describe
by
using
roll
back.
Is
that
someone
else
joined,
I'm
gonna,
just
roll
back
my
state
and
send
another
offer.
If
that's
your
setup,
so
you
could
program
it
this
way,
but
yeah
you
won't
have
to
use
promise
all
to
be
yeah
race,
free,
yeah,.
E
B
E
Because,
because
if
if,
if
the
the
perfect
negotiation
has
this
problem,
then
I
think
and
I
would
argue
for
adding
this
API
for
the
sake
of
completeness
and
a
for
sake
of
having
api's
that
are
never
racy.
But
if
it's
just
a
use
case
for
for
someone
is
doing
imperfect
negotiation,
then
I
think
nice
to
have
but
not
essential.
I
B
B
A
C
C
C
All
right,
so
that's
it
I
think
this
is
just
happy
and
slide.
Oh
wow,
oh
yeah,.
E
I
know
I
have
two
slides
I
do
think
it
would
be
time,
but
there
is
so
this
this
one.
Yes,
so
we
agreed
that
stopping
is
a
good
idea
and
then
reject
with
sort
of
questioned,
but
basically
so
that
this
is
to
start.
The
starting
point
of
this
slide
is
everything
we
we
talked
about
earlier.
We
have
it,
and
so
the
problem
is.
E
We
now
have
two
new
api's
and
I
would
say
that
you
very
rarely
care
about
the
difference
between
stopping
and
stopped,
because,
if
you're
stopping
you're
already
like
locally
you're
stopped,
it's
just
a
matter
of
receiving
an
acknowledgement
of
the
fact
and
the
only
reason
we're
doing
all
adding
all
of
these
complexities
is.
We
want
to
avoid
the
bundle
foot
gun
all
right.
So
that's
what
we're
trying
to
avoid
the
foot
can
a
question
is
like
how
many
new
api
is.
Do
we
want
to
expose
just
to
avoid
this
thing
like?
E
E
So
my
solution
is,
we
treat
stopping
as
a
direction
and
we
remove
reject
and
we've
already
talked
about
reject
so
just
quickly.
I
my
art,
the
argument
for
removing
reject
is
that
it
optimizes
away
in
sdp
paying
for
the
cost
of
being
a
food.
Again,
it's
not
worth
it.
Stop
is
good
enough.
So,
let's
just
remove
that
the
rest
of
the
slide
is.
E
If,
if
we
treat
stopped
as
a
direction,
then
we
don't
need
to
stopped
attribute
and
we
don't
need
the
stopping
attribute,
because
we
know
whether
or
not
we're
stopped
or
stopping
by
looking
at
direction
and
current
direction
right,
like
the
difference
between
stopping
and
stopped
is.
Has
this
been
negotiated
and
that's
sort
of
what
the
difference
between
direction
and
current
direction
is
one?
Is
the
direction
is
I'm
willing
to
to
use
this
direction
and
the
current
direction
is?
E
E
Don't
care
either
way,
but
that
one?
The
the
point
is
removing
the
stopped
attributes,
so
the
difference
between
direction
today
and
direction
in
this
scenario
is
that
if
the
stopping
internal
slot
is
true,
then
we
say
direction
is
stopped,
so
you
can
say
like
okay
direction,
stopped
says
we
need
to
negotiate
that
we're
stopped.
The
current
direction
might
still
be
something
else
indicating
that
we're
not
fully
stopped
yet
we
haven't
negotiated
yet
once
we
we
are
fully
stopped,
then
both
the
direction,
the
current
direction
would
say,
stopped.
E
E
While
you
are
stopping
it's
taking
two
similar
two
concepts
and
putting
in
them,
and
why
as
one
but
what
I
want
to
say,
is
it
doesn't
matter
what
the
direction
is
and
you
don't
need
the
direction
as
a
control
surface
once
you're
stopping
because
stopping
is,
is
this
dead-end
thing
you
you
become,
stop
stop
being
and
then
and
it's
it's
gone.
It
doesn't
matter
if
the
answer
says
this
is
stopping,
but
it
send
receive,
or
this
is
stopping
and
it's
inactive,
because
the
direction
isn't
applicable
to
something
that
stopped.
E
C
Well,
so
yummy
very
I,
don't
think
I
like
this,
because
I
see
see
three
problems
with
it.
One
is
that
Direction
is
sort
of
this
long-held
concept
with
send
receives,
send
only
receive
only
an
active
that
matches
J,
SEP
and
STP,
and
it's
not
clear
that
it.
You
know
we
could
have
done
this
before
right
and
we
have
it.
C
The
working
group
hasn't
done
this
before
yeah
and
the
other
part
I
don't
like
is
and
I'm
not
sure
the
concepts
blend
as
well
and
I
worry
about
the
edge
case
where
your
locally
stopped,
but
the
other
side
isn't
hasn't
been
informed.
Yet
you
can
still
receive
incoming
offers
for
awhile,
even
if
you
have
fixed
roles
that
you
have
to
deal
with,
and
the
current
algorithms
word
for
applying
might
actually
even
change
direction.
B
E
Yeah
I'm
not
I'm,
not
suggesting
we
change
the
direction
infernal
slots,
but
it
will
behave.
This
think
I'm
only
suggesting
that
the
attributes
Direction
SS
stopped
the
internal
slot
is
gonna,
be
whatever
right
and
the
the
thing
you
said
that
you
still,
you
still
need
to
be
prepared
for
offers,
even
though
you're
stopped
like
yes
and
that's
true,
even
if
the
API
says
stopping
and
stops
separately,
that's
true,
but
the
thing
is
once
it's
stopping
is
it's
not
sending
in
and
it's
not
receiving.
So
it's
it's
a
dummy
like
why.
E
C
Right,
the
other
thing,
I'm,
not
sure,
I,
understand
fully,
though
the
direction
I
thought
you
meant
at
first.
When
he
told
me
this
I
thought
you
meant
that
you
set
direction
to
stopped
when
both
ends
are
stopped.
Part
of
negotiation,
but
you're
saying
this
is
instead
of
stopping.
Is
that
right?
Yes,
right.
E
Yes,
so
Direction
direction
being
stopped
is
the
equivalent
of
the
stopping
state
and
the
current
direction
being
stopped
is
the
equivalent
of
the
start
state.
Well,
this
is
how
you
tell
the
difference
between
stopping
and
stopped.
So,
if
you,
if
you
care
about
that
difference,
you
still
like
this.
This
me,
a
proposed
API
still
gives
you
the
same
amount
of
information,
the
only
edge
case
that
I
can
think
of
that
you
don't
know
the
same
amount
of
information
as
before
is
when
you're
in
has
having
remotes
offer
and
you're.
E
Well
that
you
can
be
in
that
case,
where
you're
stopping
and
you
the
directions
slot
is
used
to
generate
the
answer,
so
you
can't
predict
the
direction
that's
gonna
show
up
in
the
SVP,
because
the
direction
attributes
just
stopped
instead
of
saying
whatever
it's
gonna
show
up
in
the
answer.
But
my
argument
is
so
what
it
doesn't
matter,
your
your
transceiver
is
stopped,
it's
not
used
for
anything,
and
it
doesn't
matter
what
the
answer
says,
because
your
third
series,
I'm
kind
of
sanding,
it's
gonna,
not
gonna,
receive
sorry.