►
From YouTube: IETF112-WISH-20211112-1430
Description
WISH meeting session at IETF112
2021/11/12 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
And
good
afternoon,
good
evening,
people
that
have
welcomed
to
show
up
at
the
wish
working
group.
I'm
one
of
your
working
group
chairs
sean
niels
is
here
as
well.
A
Evening
I'll
come
to
wish
little
early
for
niels,
but
let's
get
it
started.
So
some
little
little
notes
for
your
virtual
interim
working
virtual
meeting
host.
Please
make
sure
your
mic.
Video
is
off
unless
you're
speaking,
unless
you
wanna,
you
know
have
people
know,
and
it's
great.
Please
meet
your
microphone
unless
you're
speaking,
here's
the
links
to
the
the
medico
and
audio
stuff,
here's
the
note
well,
which
is
a
you,
know,
kind
of
a
wall
of
text
about
you
know
hey.
A
If
you're
participating
in
the
ietf,
you
need
to
adhere
to
a
bunch
of
policies
related
to
ipr
and
a
bunch
of
other
things.
It
gives
you
links
to
working
group
process
and
how
things
go
and
then
any
harassment
and
code
of
conduct
and
things
in
copyright,
et
cetera
for
the
code
of
conduct,
we're
gonna
get
to
that
a
second
for
the
ipr.
It's
pretty
straightforward.
If
you
know
anything,
you
speak
up
or
if
you
contribute,
you
need
to
disclose
straightforward.
A
We've
got
a
slide
on
the
itf
code
of
conduct,
since
it's
friday.
Hopefully
you've
all
seen
this
multiple
times.
This
work
group
has
not
suffered
from
this
problem,
but
I
guess
we
want
to
show
everybody
the
same
so
kind
of
give
everybody.
The
guidelines,
like
basically
treat
everybody
with
respect,
try
to
speak
slowly,
which
I
often
have
a
problem
with,
so
I
will
try
to
do
it
slowly
as
well.
Please
just
dispute
ideas
by
using
recent
arguments
use
your
best
but
judgment
engineering
judgment.
A
Please
try
to
find
the
best
solution
for
the
whole
of
the
internet.
It
contributes
to
the
ongoing
work
by
you
know.
The
group
of
the
itf
remember
that
we,
the
code
of
conduct
guidelines,
are
applicable
to
both
the
meet
echo
stream,
as
well
as
the
jabber
and
email
list,
and
we
appreciate
you
for
doing
the
right
thing
heretofore
again
wish
at
ietf112
here's
our
quick
agenda,
we'll
do
some
mistrivia.
A
Luckily,
the
blue
sheets
are
now
automatically
generated.
We
did
not
coordinate
this
beforehand,
but
is
there
anyone
that's
willing
to
take
notes
for
us,
and
all
we
need
is
high
the
high
points
we
don't
need
blow
by
blow,
just
any
decisions
we
make.
A
Adam
was
that
you
saying
yes,
yes,
that's
adam
awesome
great,
so
we
got
that
we
have
a
jabber
scribe.
Luckily,
this
is
all
kind
of
integrated,
so
I'm
hoping
that
there's
anybody,
that's
in
the
jabra
stream
that
that
pops
in
we'll
be
able
to
figure
that
out.
So
if
anybody
feels
that
they
they
have
any
kind
of
audio
problems,
feel
free
to
put
like
mic
mic
colon
in
front
of
their.
A
You
know
points
in
the
java
room
and
or
in
the
chat,
and
we
can
make
sure
it
gets
discussed
on
get
some
live
time.
Update
that
we're
not
just
chartered.
So.
Basically,
our
quick
agenda
is
we're
going
to
talk
about
the
draft
the
wish
whip
draft
then
we're
going
to
have
some
hackathon
discussions
and
then
some
information
implementation
experience
from
two
implementers,
which
I
think
is
great
because
it
makes
our
job
a
whole
lot
easier.
B
Tim
go
ahead
just
say
I
can
add
a
kind
of
two
seconds
of
implementation
experience
as
a
third
implementation
of
a
client
implementation.
I
did
in
the
run-up
to
the
hackathon.
A
Absolutely
very
exciting
the
more
the
merrier
is,
how
I
look
at
it:
oftentimes
we
progress
protocols
in
the
ietf
and
there's
no
one
implementing
them.
So
it's
good
that
this
is
happening
here.
I
guess
my
only
note
of
caution
is
that
we
are
supposed
to
liaison
slash
discuss
with
other
working
groups.
So
one
of
the
things
that
I
guess
I
want
to
talk
about
at
the
end,
if
we
have
time
is
at
what
point
do
we
need
to?
A
C
Take
the
floor,
sir
yeah.
So
first
slide,
please.
So,
basically
the
first
drop
was
the
and
based
on
the
version
2
of
the
murillo
whip,
personal
draft.
So
this
is
the
one
that
we
adopted
in
the
last
minute
and
since
that
I
we
have
incorporated
several
changes
into
the
the
into
the
this
zero
one
version
of
the
sweep,
and
mainly
there
was
a
from
feedback
received
by
the
my
in
the
mailing
list
about
the
produce
draft.
C
For
example,
it
do
not
require
the
web
server
to
be
public
accessible,
but
just
request
that
they
either
the
server
retrieves
no
candidates.
So
all
the
candidates
in
the
sap
answer
that
are
returned
from
the
in
the
in
the
sdp
answer,
also
some
clarifications.
Regarding
the
responses
of
the
of
the
tricky
license,
restart
patch
request
to
the
endpoint
resource.
C
It
may
need
to
differ
to
differentiate
that,
if
it
is,
the
server
can
return
to
different
the
response
codes
with
container,
with
or
without
content
regarding,
if
it
is
a
nice
trickle,
because
if
the
the
server
does
not
require
a
to
send
back
any
new
information
or
if
it
is
a
nice
restart,
it
has
to
return
a
200.
Ok
with
a
with
an
sdp
with
the
new,
a
ice
username
and
fragment
username,
fragment
and
password.
So
they
also
the
client
can
do
the
ice
restart
properly.
C
C
Anymore,
for
example,
if
you
are
doing
nice
light,
you
have
just
returned
204,
and
but
we
are
not
adding
any
complexity
about
adding
and
having
the
client
to
check
if
they're
the
response
curves
and
do
one
thing
or
another
depending
on
on
it.
So
just
say:
if
you
don't,
if
the
server
does
not
need
to
to
do
anything
with
the
with
the
you
know,
ice
candidates
just
ignore
it
and
it
will
be
fine
and
we
have
added
a
and
some
handling
of
the
out
of
the
order
request
because,
yes,
colleen.
E
Just
getting
permission
just
getting
my
permissions
here,
so
I
I
just
want
to
make
sure
I
I
understood
that
correctly,
so
it
when
we
get
this
patch
with
the
new
sdp
on
the
server,
you
can
basically
ignore
all
the
stuff.
That's
in
it
like
that.
Doesn't
that
doesn't
sound,
really
very
right
to
me.
It
sounds
like
that
will
create
lots
of
problems
if
some
clients
are
processing
the
stp
and
some
are
not
processing
the
stp.
C
E
C
Yeah
well,
the
the
the
patch
information
is.
The
only
contains
the
the
ice
candidate,
so
we
can
only
contact
the
the
a
new
ice
candidate
or
the
information
up
for
doing
a
nice
restart.
So
so
it's
not
changing
any
any
kind
of
other
parameters
that
are
not
ice
related,
so
it
can
only
be
triggered
for
an
trigger
lice
for
for
providing
new
candidates
or
for
a
new
username
and
friend
men
for
doing
a
nice
restart.
C
E
F
E
C
Yeah
number
one
and
also
the
last
point,
was
a
attempted
team
about
how
to
handle
auto
for
the
request.
C
C
C
C
So
the
question
is:
if
we
continue
using
this,
then
the
sat
format
that
it
is
a
in
the
in
the
sdp
fragment
rcc
or
we
just
extend
the
abn
f-
that
it
is
something
that
it
is
allowed
by
the
by
the
rcc
and
just
allow
the
candidates
and
ice
stuff
to
be
also
present
at
session
level.
So
we
don't
have
to
include
the
the
m,
the
fake
m
and
line
with
the
mid
that
it
is
has
no
meaning
for
us.
C
E
C
C
No,
the
the
one
we're
using
is
the
it
requires.
C
E
C
H
C
C
H
C
E
I
think
it's
a
little
bit
more
complicated
now.
I
think
you
need
to
go
change,
a
version
of
patch
that
allows
that
right
I
mean
it's
not
just
like
changing
the
a
b
and
f
will
magically
make
this
go
away.
I
mean
whatever
reasons
that's
like
that
in
the
original
giraffe
needs
like
we
need
a
different.
It's
no.
C
C
G
I
Like
bundle
is
required
by
the
spec
right
now
and
so
he's
saying
basically
like
you're,
that
that
results
in
the
different
media
sections
not
being
able
to
go
to
different
servers.
So
why
do
we
need
to
repeat
all
the
ice
candidates
in
all
the
different
media
sections?
Why
not
put
them
in
the
session
level,
make
it
clear
like
rebundling,
there's
only
one
ice
session,
it
cannot
go
to
different
servers,
but
it
requires
spec
changes.
I
think
that's
what
sergio
is
trying
to
ask
you.
C
And
I
mean
the
first
one:
the
the
the
first
dp
fragment
is
working
right
now.
The
only
thing
is
that
it
is
a
bit
that
one
can
cause
problems
in
in
the
implementations,
because
it
is
a
bit
awkward
what
we
are
sending
if
you
are
coming
from
webrtc
and
probably
the
second
one
is
more
straightforward,
but
it
is
just
a
matter
of
day
of
the
syntax
of
the
of
of
how
the
candidates
are
encoded
and
not.
What
is
the
information
is
there
or
how
it
is
handled?
E
I
I
I
guess
I
you
know
I
I
certainly
I
I'm
understanding
better
now
what
you're
talking
about
makes
sense.
Thank
you.
I
just,
I
think,
like,
as
you
start
changing
how
existing
libraries
process
this
stuff
and
things
I
mean
every
one
of
these
things.
My
question
is
going
to
be
like.
Why
like,
why
why?
Why
would
I
mean
it
can't
be
bandwidth?
Saving,
that's
not
a
good
answer
in
this
case.
E
That
could
not
possibly
be
the
answer,
so
I
I
just
would
ask:
what's
the
you
know,
minimal
set
of
changes
of
what
people
have
already
implemented,
that
that
need
to
be
done
for
this,
and
I
think
really.
I
would
I
mean
I
think
when
I
read
the
draft,
I
I
I
really
wonder
why
we're
doing
it
in
the
general
direction
of
the
client
generates
the
offer.
Why
doesn't
the
server
generate
the
offer
and
the
other
way
the
answer?
All
of
these
patching
problems
that
trickle
ice
problems.
A
ton
of
these
problems
go
away.
F
E
Would
initiate
the
client
would
initiate
an
http
post
or
something
to
create
a
new
resource,
but
the
resource
would
come
back
along
with
the
offer
and
then
you'd
send
back
up
the
answer
right.
So,
of
course,
it's
still
the
client
that
initiates
the
transaction,
but
it
it
puts
right
now.
The
hard
part
in
dealing
all
of
this
is
matching
up
offers
and
answers,
and
you
wouldn't
have
to
do
all
that,
because
the
browser
would
be
implementing
it
that
side
and
that
end
of
it
would
make
it
much
easier.
C
C
D
E
E
C
C
C
D
C
E
Okay,
you
want
to
have
a
detailed
conversation
about
changing
an
abn
f,
but
we
don't
understand
why
you
need
that
and
we
don't
understand
why
the
architecture
causes
the
need
for
that.
So
it's
it's
back
to
that
usual
conversation
where
you
have
an
implementation
want
to
talk
to
a
man
neat
detail
of
the
existing
implementation
without
really
hitting
the
requirements
or
why
why
we
need
this
or
what
we
need
to
change?
I
mean
that's
and
that's
why
it's
sort
of
hard
to
follow
exactly
what's
being.
C
E
C
For
example,
in
the
current
implementations
you
don't
have
the
mit
in
the
in
the
in
the
api,
the
wcc
api.
You
don't
have
the
mid,
so
you
have
to
get
the
to
get
the
mid.
You
have
to
get
the
you
have
to
get
the
transceiver
and
get
the
mid
also
get
the
the
audio
type.
So
it's
not
much
so
yeah
you
just
was
asking
if
it
makes
sense,
I
mean
I
it
current
implementation,
not
working
fine
with
the
first
with
the
first
system.
I
don't.
E
C
Yeah
I
mean
the
idea
is
that
we
are
doing
banding,
so
it's
so
we
can
just
send
the
candidates
at
the
session
level.
Sdp
supports
sending
candidates
in
the
session
level,
but
this
a
zip
fragment.
Don't
so.
The
idea
is:
if
we
shoot
the
assistant,
then
the
fragment
will
also
support
the
candidates
in
the
session
level
or
not
okay,
because
the
zp
already
supported.
So
it
is
just,
and
it
is
so.
It
is
just
an.
E
It
sounds
more
like
it's
going
to
cause
them
to
prevent
them.
I
mean
I'm
all
for
preventing
reducing
interoperability
issues,
but
I'm
not,
it
seems
the
opposite.
C
I
mean
I
mean
I
find
with
by
using
it
I
mean
just
was
raising
the
question.
The
current
implementation
already
working
fine
with
the
first
one.
So
if
no
one
sees
a
reason
to
move
to
the
second
one,
I
find
to
leave
it
as
it
is
so
just
say
I
don't
expect.
I
didn't
expect
it
to
be
so
controversial,
but
I
mean
I'm
fine
to
keep
it
as
it
did
right
now.
J
E
E
D
A
Fair
enough
calling
can
we
can
we
try
to
take.
A
Of
the
repo
all
right
thanks,
martin
you're
next.
K
Keep
that
so,
let's,
let's
try
to
separate
these
things
out.
First
thing:
is
you
don't
get
to
change
the
definition
of
what's
in
8840
here
it
looks
like
you're
you're
asking
for
something
that's
fundamentally
different
than
what's
different,
so
define
something
fundamentally
different
and
describe
how
it
works
and
move
on.
I
don't
think,
there's
anything
particularly
complicated
with
what
you're
asking
for,
but
it's
not
what's
in
rfc
8840.
K
K
The
other
thing
was,
with
with
ice,
restart
the
way
that
webrtc
generally
works
is
you
have
a
complete
offer
answer
exchange
and
it
seems
to
me,
like
you-
could
do
the
same
here
quite
reasonably
if
you've
got
the
ability
to
to
run
another
offer
answer
in
the
same
session,
and
if
you
don't
then
again
define
a
new
format.
C
But
yeah
yeah
again
foreign,
you
don't
really
need
a
new
zp
answer
offer
you
just
need
to
generate
a
new
username,
fragment
and
username
password,
so
that
is
the
only
thing
that
it
is
required.
C
Obviously
you
in
in
sdp
in
webrtc,
we
are
generating
a
full
offer
answer,
but
it
is
not
because
we
and
it
is
mandated
to
do
an
http
offer
answer
again.
You
just
need
to
date
the
username
and
password.
K
Want
that
that's
understood,
I'm
just
I'm
just
talking
about
ensuring
that
things
are
consistent
with
with
other
systems
and
just
and
having
you
justify
those
things.
I
think
you
have
justified
them,
but
don't
use
8840
point
at
88.40
for
all
of
the
behavior,
but
you
can't
use
the
format.
C
I
C
K
C
Okay,
so
that's,
but
anyway
that's
clear,
and
I
think
that
we
just
and
what?
If
we
don't
do
nothing,
then
this
is
it
I
mean,
because
what
we
did
already
in
the
the
current
draft
is
using
rpc
8040
as
it
is
without
any
changes
at
all.
So
the
question
is
is
if
we
should
change
it,
and
but
it
seems
that
there
is
that
the
answer
is
no,
so
we
just
can
stick
to
what
it
is
in
there
and
and
we
will
be
fine
just.
E
E
You
could
use
8840
exactly
like
it
is,
or
you
could
have
a
different
session
level
syntax,
which
may
be
the
right
thing
to
do.
But
if
you
do
that,
you
need
to
define
something.
That's
not
advanced.
E
C
I
B
B
Ahead,
okay,
cool-
I
just
wanted
to
say
I
think
the
stp
fragment's
the
wrong
answer
to
this.
We've
got
a
bit
of
experience
of
of
doing
this
kind
of
thing,
and
actually
it
turns
out
to
be
much
easier
to
send
something
that
looks
quite
like
a
diff
and
and
then
synthesize
the
offer
answer
out
of
that.
I
I
just
don't.
I
mean
sdp,
fragments
the
wrong
answer
and,
and
the
reason
we're
struggling
with
it
is
because
it's
the
wrong
answer
we
should
be.
B
G
So
I
just
wanted
to
respond
to
some
of
the
things
that
cullen
was
saying
he
was
raising
some
sort
of
fundamental
architectural
issues,
and
the
key
point
that
I
want
to
make
is
that
the
presence
of
trickle
ice
in
in
wish
isn't
some
like
accidental
relic
that
arises
from
the
way
that
we're
like
deciding
to
send
the
offer
from
one
direction
or
the
other.
It's
a
requirement
of
the
system
in
order
to
get
broadcasts
up
and
running
as
quickly
as
possible,
so
making
changes
that
obviate.
G
L
L
L
If,
like
me,
you
have
to
suffer
through
networks
that
do
require
turn,
then,
if
you're,
trying
to
probe
all
turns
all
turn
servers
before
you
even
attempt
to
send
an
offer,
it's
going
to
give
a
bad
user
experience.
The
second
point
I
want
to
make
is
a
little
bit
orthogonal.
L
I
think
that
the
distinction
between
an
ice
candidate
and
an
i3
start
should
happen
120
layers
above
parsing
of
sdp.
I
want
to
know
I'm
the
server,
and
I
want
to
know
whether
the
client
is
doing
a
nice
restart
or
sending
me
a
nice
candidate
straight
away.
I
want
it
at
the
http,
the
http
layer.
I
don't
see
why
we
are
refusing
to
put
either
a
url
parameter
or
an
http
header
that
tells
the
server
explicitly
whether
we're
doing
a
nice
restart
or
sending
a
nice
candidate.
L
C
I
mean
currently,
we
are
using
the
same
request
for
both
theatrical
the
triglyceride
start,
because
the
the
the
db
fragmenting
c840
allows
to
do
that
in
the
same
in
the
same
in
the
same
request.
So
this
the
the
first
question
is:
if
we
should
do
something
different,
they
has
to
signal
that
the
the
client
is
just
sending
an
attribute
lice
or
a
restart,
but
I
think
that
it
is
also
has
to
be
with
a.
C
How
do
we
handle
a
out
of
order
a
pass
request,
because,
obviously
we
don't
want
to
the
client
to
do
kind
of
any
kind
of
blocking
for
any
http
request.
Hey
has
been
a
response
has
been
receiving
before
issuing
a
new
one
because,
for
example,
if
you
are
doing
a
a
nice
restart
because
you
have
a
network
change,
probably
then
you
have
some
previous
http
http
post.
That
will
never
be
best,
be
the
answer
or
will
be.
You
will
have
to
wait
for
the
timeout
for
it
to
be
received.
C
So
then
the
question
is
how
to
deal
with
this
out
of
a
of
the
folder
requests
on
the
server
side,
and
we
have
two
different
cases.
One
if
we
receive
first
a
nice
candidate,
we
send
a
nice
candidate
and
then
a
nice
restart,
but
we
receive
it
in
the
in
the
other
way
in
the
other
order.
So
we
received
first
the
restart
and
then
the
ice
candidate.
C
These
new
candidates
should
these
all
candidates
must
be,
must
be
discarded.
But
how
do
we
know
that
it
is
a
an
old
candidate
and
not
a
a
new?
I
say
I
restart
and
then
the
other
one
is
that
if
it
is
an
address
or
natural
stand
and
then
as
a
nice
candidate
and
with-
and
you
receive
the
the
ice
candidate
for
that,
it
is
still
valid.
But
you
have
not
yet
yet
done
the
ice
restart.
C
L
So,
yes,
it
doesn't
solve
all
issues.
The
fact
of
having
this
one
bit
of
information,
so
martin
is
suggesting
using
different
content
types.
C
If
we
are
doing
it
on
the
server
checking
that
the
client
effect
and
if
it
is
not,
and
then
it
is
a
nice
restart.
So
it
is
something
that
can
be
done
easily.
C
The
only
thing
is
what
happened
if,
with
this
out
of
order
request,
because
we
either
have
to
mandate
the
the
server
to
keep
a
small
list
of
the
previous
username
of
fredward
to
detect
a
previous,
previously
used,
username
fragments
to
discard
to
to
detect
this
of
order
request
or
if
we
should
have
just
put
a
patch
or
a
timestamp
on
the
request
to
to
make
sure
that
when
they
it
to
to
so
they
take
the
the
server
can
know
if
the.
C
G
I
know
it's
sort
of
orthogonal
to
the
issue
that
the
julius
is
raising,
but
in
terms
of
ensuring
ordering
martin
has
pointed
something
out
in
the
chat
that
I'm
a
little
embarrassed
and
occurred
to
me
earlier.
We
have
a
mechanism
in
hdp
to
ensure
this
kind
of
ordering
already
we
have
conditional
operations
using
e-tags,
and
I
think
that
would
be
a
much
cleaner
way
to
handle
ensuring
that
you're
not
putting
state
on
top
of
stale
state
we're
not
putting
stale
state
on
top
of
existing
state
for
these
sorts
of
cases.
C
C
C
C
What
we
have
proposed
is
to
just
to
map
the
information,
for
example,
that
it
is
currently
in
the
in
the
wc
apis
to
a
link
here
that,
just
as
the
in
the
url,
the
the
username,
the
the
credential
and
the
credential
type,
that
is.
This
is
exactly
the
same
definition
that
we
are
doing
in
the
in
the
daily.
Then
the
wc
w3c
apis
to
for
for
this
options
and
then
yeah,
I
put
the
rel
type
of
I
server.
C
K
Format-
this
is
just
me,
quibbling
you've
got
colons
instead
of
equal
signs,
and
you
forgot
your
ankle
brackets,
but
I
was
going
to
say
this
is
this
is
a
reasonable
thing
to
do.
C
It
wrong
and
a
one
thing
that
we
have
currently
is
that
a
the
both
the
webrtc
and
the
rtc
web
offices
and
apis
allows
to
update
the
the
configuration
and
the
ice.
The
the
tool,
server
and
understood
server
configuration
before
the
the
the
gathering
phase
has
has
been
started.
That
will
be
before
putting
the
or
setting
the
remote
description
so
and
but
we
thought
that
the
implementation
will
not
allow
to
do
that.
C
C
D
Yeah,
I
don't
know
if
I
can
chime
in
already
that
was
in
cuba.
Sorry
yeah
just
to
just
to
mention:
that's
I
mean
yeah.
You
say
that
just
remember
as
apache
in
the
works,
but
actually
the
issue
there
is
that,
for
instance,
my
my
web
client
is
currently
based
on
g
streamer
and
g
streamer
doesn't
allow
you
to
do
that
update,
which
is
why,
in
my
current
implementation,
I
only
have
to
rely.
D
I
have
to
rely
on
options
to
to
get
that
working
actually,
and
so
the
problem
is
that,
even
if
you
get
a
patching
g
streamer
today,
just
rumor
has
its
own
development
cycle
and
that
can
take
a
long
time
before
it
actually
lands
in
all
the
major
distributions
that
are
available
out
of
notes
to
everybody,
which
means
that,
even
if
it's
ready
today,
it
may
only
be
available
to
most
people
that
are
interested
in
this
in
one
year
or
two
years,
or
something
like
this.
So
this
is
just
really
from
a
practical
perspective.
D
It
may
make
sense
to
at
least
for
the
people
that
are
interested
in
using
g
stream
or
it
may
be
other
implementations
I
mean.
I
don't
know
to
keep
options,
at
least
as
as
an
available
option,
and
I
don't
know
whether
it
should
be
a
master
shoot
that
may
or
whatever
it's
just
to
basically
allow
this
option
to
to
be
available.
C
I
mean
I
find
also
with
that,
because
anyway,
what
we
are
restricting
is
that
the
the
options
must
be
authenticated
so
to
be
able
to
to
do
the
to
to
retrieve
the
the
tool
server
configuration.
So
if
you
are
not
doing
the,
if
you
don't
really
need
it,
then
you
will
not
provide
it.
What
we
can
do
is
just
that
the
options
do
the
doing
the
options
and
returning
the
configuration.
C
Not
the
option
is
like
kind
of
optional
and
but
in
the
post
it
is
mandatory,
meaning
that
you
cannot
descend,
certainly
in
the
option.
So
probably
so,
if
you
support
conf
doing
the
configuration
in
the
when
you
receive
the
post
request,
you
avoid
doing
the
the
first
software
request
to
to
prevent
the
server
to
have
to
to
fetch
the
credential
twice.
A
B
So
I'm
in
favor
of
keeping
this
in
options,
because
I
think
otherwise
you
aren't
you
effectively
mandating
tricholites
as
well,
because
you
wouldn't
get
a
stun
result
because
you
didn't
have
a
stun
service
set.
So
your
initial
offer
wouldn't
have
any
candidates
other
than
the
locally
discovered
addresses
in
them,
and
so
you're
kind
of
you
know.
If
you
take
it,
take
this
out
of
options,
then
you're
forcing
triple
ice
on
everybody
and
so
you're
radically
complicating
some
of
the
stupider
clients
like
mine,.
G
Yeah,
I'm
sorry
it
was
unmuting.
G
So
I
wanted
to
give
a
plus
one
lorenzo
said
and
add
on
that.
The
bigger
problem
is
probably
not
the
g
streamer
release
schedule
as
much
as
browser
release
schedules
right
now.
You
need
to
have
this
information
before
you
start
your
initial
peer
connection
to
get
the
candidates
that
you're
going
to
put
into
the
offer
in
the
first
place.
G
So
I
think,
while
I
proposed
options
as
being
something
transitional,
I
think
it's
going
to
be
a
very
long
transitional
phase
that
we
can't
like
allied
at
this
point
it's,
and
for
that
reason
I
don't
think
you
can
make
it
optional
in
options.
I
think
this
needs
to
be
there
at
least
for
a
fairly
long
time
I
mean.
Maybe
we
can
come
back
and
revisit
this
for
five
years
in
the
future
and
like
deprecate,
that
the
it's.
G
The
final
point
on
that
that
I
want
to
make
is,
whenever
you
see
an
options
like
this
you're,
pretty
much
guaranteed
that
there's
a
post
coming
along,
and
it
seems
to
me
that
the
the
server
should
just
be
able
to
cast
the
credentials
for
what
is
a
very
short
period
of
time
and
avoid
having
this
this
double
access
to
try
to
get
the
the
credentials
a
second
time.
I
think
this
is
something
that
can
be
fairly
easily
optimized
in
the
server
itself.
C
D
D
D
That
involved
me
sergio
julius
and
gustavo
garcia
as
well,
and
that
was
quite
successful
and
ended
up
providing
a
lot
of
feedback
for
zero
one,
and
in
this
case
we
ended
up
having
some
more
implementations
to
test.
So
there
was
mine
that
is
based
on
janus.
This
was
julius
based
on
galen,
sergio
integrated
this
in
millicast,
and
then
there
was
a
new
sfu
based
on
pion.
D
That's
that
supported
this
and
multiple
clients
that
could
actually
be
taken
advantage
for
the
purpose
again
using
different
stocks
like
iu,
rtc
pi
on
the
the
stock
that
team
implemented
for
raspberry,
pi's
and
so
on
and
so
forth,
and
let's
say
the
end
result
was
pretty
much
successful,
mostly
successful,
more
successful
than
this
slide
might
suggest.
Basically,
the
grain
means
everything
worked
out
of
the
box.
D
Yellow
means
some
things
needed
to
be
changed
in
the
implementation
on
either
side
to
get
something
working
and
orange
and
red
instead
meant
different
issues
that
happened
that
basically
prevented
a
successful
setup
at
the
time
being,
which
may
or
may
not
be
related
to
whip
itself,
though,
in
some
cases
it
was
related
to,
for
instance,
the
different
stock
implementations
or
different
stock
implementations
unable
to
work
with
each
other
or
even
just
different
codecs,
because,
for
instance,
some
endpoints
are
not
coded
to
send
vp8,
and
that
is
a
fuel,
for
instance,
only
supports
h.264
for
ingestion,
which
means
that
in
that
case,
that's
the
reason
why
the
the
the
interrupt
test
didn't
work
which
isn't
really
a
fault
in
in
whip,
but
just
basically
the
negotiation
ended
up.
D
Closing
there
were
a
few
issues,
as
I
mentioned,
related
to
the
to
the
webrtc
stacks
that
needed
to
be
fixed.
In
some
cases,
it
was
just
basically
some
basic
firewall
problems
and
so
on
and
so
on
and
so
forth.
So
I
wouldn't
really
bother
you
with
the
details
about
all
these.
You
can
just
have
a
look
at
these
lights
for
that.
D
That
did
basically
sound
like
a
good
starting
point
for
us
and
what
we
really
want
to
do.
Next,
though,
is
basically
start
looking
a
bit
more
in-depth
at
other
functionality.
For
instance,
we've
spent
a
lot
of
time
now
talking
about
ice
restarts
and
how
to
actually
trickle
candidates
and
so
on
and
so
forth.
That's
not
something
that
we
have
tackled
tackled
so
far,
some
more
issues
related
to
possibly
or
front
sessions.
If
you
don't
do
an
http
delete,
for
instance,
whether
or
not
the
server
is
able
to
detect
stuff
automatically.
D
We've
mentioned
the
the
link
support
for
stun
internal
auto
configuration
so
whether
or
not
post
versus
options
can
cause
issues,
anything
related
to
bearer
tokens
and
and
stuff
like
this.
So-
and
this
was
the
interrupt
testing
team,
so
it
was
basically
six
of
us
working
working
together
during
past
week,
and
I
don't
know
if
you
have
any
quick
question
for
us
at
this
specific
point
or
if
you're
satisfied
with
this
very
quick
overview.
A
I
have
to
leave
it
as
as
we're
good
and
they
should
take
questions
to
the
list
or
to
get
up
either
way
and
I'd
like
to
kind
of
arbitrarily
pick
julius
to
go
next.
I
know.
A
Minutes
but
we
can
jump.
Hopefully
we
can
do
it
kind
of
quickly
or
at
least
get
we
got,
because
we
have
at
least
two.
There
was
going
to
be
a
third
s.
You
know
a
couple
seconds
about
implementation
experience,
but
people
should
feel
free
to
comment
on
the
mailing
list.
I
did
post
the
slide,
so
that's
good
julie
is
very
good.
L
L
And
at
some
point,
dave
told
me
about
which
I
implemented
weapon
galen
and
the
main,
and,
unlike
the
other,
unlike
some
of
the
other
implementations,
the
first
class
implementation,
it's
actually
part
of
the
server
I'm
not
attempting
to
translate
into
galen's
native
signaling
protocol.
Next,
please.
L
And
so
the
good
news
is
that
whip
works
and
it's
easy
to
implement.
I
did
it
in
one
night:
there's
427
lines
of
code
that
are
specific
to
whip,
there's
50
lines
of
patches
to
galen's
core,
but
that's
galen's
fault,
because
I'm
not
exporting
enough
of
the
english,
the
internal
data
structures
and
I
had
help.
I
had
a
client
and
that
was
laurenta
mignero's
simple
web
client.
Next,
please.
L
So
it's
five
shell
commands.
If
you
need
a
server
to
test
your
web
client
against,
it's
literally
five
commands
to
get
it
running
next,
please,
okay,
and
so
that
was
the
good
news.
I
had
some
minor
difficulties
and
the
main
reason
for
that
is
that
I'm
not
competent,
and
that
means
that
I'm
a
precious
resource
because
I'm
currently
the
only
incompetent
whip
implementer,
but
if
whip
becomes
successful,
then
I
will
no
longer
be
the
only
incompetent
web
implementer,
hopefully,
and
so
we
must
aim
the
draft
its
incompetence-
and
I
had
mainly
four
difficulties.
L
This
were
course
url,
multiplexing,
authentication
and
distributions
what
I
mentioned
already
candidates
from
restarts.
Next,
please
lorenzo
explained
course
to
me.
I
knew
nothing
about
cars
I
had
vaguely
heard
about
it
and
asking
lorenzo
for
help
is
something
that
doesn't
scale.
So
I
think
that
the
draft
should
explain
course,
or
at
least
do
the
link
next,
please.
L
So
the
other
difficulty
is
that
in
galen
we
want
to
have
a
very
simple
user
interface.
We
have
just
one
url
both
for
the
native
javascript
client
and
the
with
request,
and
so
I
would
really
like
if
wood
could
mandate,
that
there
is
a
url
parameter.
L
L
L
A
I'm
helped
pretty
impressive.
Thank
you
for
condensing
that
into
four
minutes.
I
I
guess
my
point
about
the
implementation
experience.
Is
it
really
does
help
us
as
chairs
move
things
forward?
So
if
we
really
only
have
a
few
things
less
that
we
need
to
kind
of
agree
upon,
that
really
makes
makes
me
feel
really
great,
because
I
did.
I
did
think
that
this
wasn't
going
to
take
forever,
but
again
I'm
hoping
that
we
can
take
everything
else.
A
The
list-
and
I
do
want
to
apologize
for
the
others
who
made
please
check
them
out
in
the
github
repo
and
the
data
tracker.
The
one
final
thing
I
think
I
want
to
check
on
the
list
is
at
what
point
do
we
need
to
go
to
other
working
groups
that
we
said
with
liaise
with
to
you
know,
make
sure
we
get
an
early
review
that
we're
not
on
the
wrong
path,
because
I
would
hate
for
the
implementations
to
get
out
in
the
wild
and
get
corrected
later.