►
From YouTube: IETF114 WISH 20220727 1730
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
A
Think
we're
in
the
right
place
looking
at
the
people
in
the
room.
So
if
not
go
go
join
another
session
hi
I'm
shawn
niels
is
remote.
A
You
can
see
him
there
go
through
the
nice
close
entries.
Here's
the
well
it's
wednesday,
so
hopefully
you've
seen
this
by
now.
Basically,
if
you
know
something
say
something
about
ipr,
you
know
be
nice
to
people
all
the
various
best
best
practices
for
how
to
run
a
meeting
etc.
A
And
if
you
have
any
questions
about
these,
ask
anyone
in
the
room,
I
think
most
of
the
people
I've
hear
I've
seen
before
and
are
well
versed
in
this
if
you're
remote.
Likewise
just
kind
of
want
to
highlight
the
code
of
conduct
not
been
a
problem
in
this
working
group.
Luckily,
basically,
try
to
you
know,
treat
everybody
with
respect.
You
know
speak
slowly,
use
the
avoid
the
use
of
slang.
I
think
they
put
that
bullet
in
just
for
me
make
sure
to
dispute
ideas
using
recent
argument.
A
A
Pretty
straightforward,
just
a
couple
things
to
remind
you
of
no
one
here,
everyone
here
is
messed
up,
but
that's
really
great
to
see,
but
if
you're
local
make
sure
you're
messed
up
unless
you're
at
the
microphone-
and
I
don't
at
the
front
of
the
room-
and
I
don't
know
that
anybody's
actually
going
to
be
at
the
front
of
the
room
other
than
me.
So
please
keep
your
mask
on
again.
A
Remember
the
no
whale
we
just
talked
about,
please
make
sure
to
sign
via
the
online
tool,
because
that's
how
we're
going
to
be
managing
the
queue
to
make
it
fair
for
all
the
remote
people
to
be
able
to
get
in
and
out,
and
if
you
do
that,
you
also
there's
no
blue
sheets
as
you'll
notice,
but
we
do
need
a
note
taker
and
I'm
looking
around
the
room
and
I'm
curious
who's
going
to
be
willing
to
take
notes.
We
don't
need
blow-by-blow
minute
notes.
We
just
need
kind
of
like
high-level
actions.
A
Vehicle,
oh,
that's
true,
is
anybody
else
willing
to
jump
in
and
take
minutes
for
us.
A
All
right,
I
think,
we're
having
a
little
bit
of
blipping
here
on
the
network,
but
spencer.
If
you
would
do
that,
that
would
be
greatly
appreciated.
Again,
we
don't
need
blow-by-moments.
I
think
this
is
going
to
be
fairly
straightforward,
because
we're
trying
to
resolve
working
group
last
call
comments,
and
so
we
really
care
about
like
what
was
the
resolution
of
the
particular
slide
right.
Okay,
great
appreciate
it
and.
A
We've
got
one
document
in
this
working
group:
it's
the
web
draft
and
we're
going
to
go
through
the
the
remaining
items
that
are
outstanding
or
what
sergio
wants
to
talk
about
in
the
version.
Oh
four,
that's
going
to
be
the
the
bulk
of
our
time.
I
kind
of
pick
30
minutes,
because
I
look
at
the
number
of
slides
and
I'm
like
yeah,
that's,
okay
and
then
we're
going
to
kind
of
have
a
discussion
of
like
what
the
way
forward
is
and
sergio
has
taken
the
initiative
to
write
up
a
draft
for
things.
A
I
think
he
wants
to
do
going
forward.
So
he
kind
of
beat
us
to
the
punch,
and
so
we
kind
of
made
he
you
know:
semi
combined,
slide
deck
and
kind
of
split
it.
So
there's
there's
two
sets
of
slides
there,
but
I
think
we'll
have
the
way
forward,
discussion
first
and
then
try
to
figure
out
what
the
you
know.
What
the
way
forward
is
and
what
we
will
do
with
the
working
group.
A
So
unless
there's
any
problems,
I'm
going
to
go
ahead
and
run
the
slides
for
you
sergio
so
go
ahead
and
get
in
the
mic
line,
and
I
will
go
on
mute.
Okay,.
D
Hello,
so
yes,
I
say:
let's
see,
I
said
this
is
a
the
presentation
is
about
to
to
to
comment
all
the
issues
that
we
have
or
the
feedback
that
I
have
received
for
the
working
group
last
call,
and
it
has
all
been
addressed
in
the
in
the
draft.
So
what
I
want
there
was
not
much
comments,
neither
on
the
mailing
list
on
the
and
on
the
on
the
the
project
yeah.
D
D
One
thing
that
I
received
a
other
clarification
in
support
of
what
happened
if
they,
the
media
server,
supports
only
trickle
eyes
or
ice
restart,
but
one
of
them,
but
not
both
rewarding
about
bundle,
support
that
it
is
also
requested
other
than
a
section
about
how
to
handle
a
multiple
audio
and
video
tracks
in
an
sdp
offer
from
from
the
the
weak
client
in
so
we
are
like
a
future
compatible
for
the
upcoming
version
of
whip
and
clarific,
also
a
small
clarification.
D
D
So
this
is
the
the
list
of
the
issues
that
they
after
discussing.
I
think
that
they
will
not
be
fixed
and
it
is
okay
in
the
rough
as
as
they
are
right
now,
the
one
the
first
one
was.
I
have
also
included
the
link
to
the
end
to
the
issues
to
check
the
discussion,
so
the
first
one
is
that
some
protocol
operation
and
some
normative
language
was
missing,
but
we
have
seen
that
I
mean
when
we
inherit
things
that
are
mandated
from
in
webrtc.
D
We
don't
need
to
add
the
this
informative
language
and
we
can
use
yes
lowercase
a
mass,
and
things
like
that.
So
if
there
is
any
particular
case
that
you
think
that
it
is
not,
this
is
not
covered
by
written
by
from
webrtc.
Please
point
it
out,
but
in
general,
as
we
think
that
it
is
covered.
A
So
on
that
first
point
from
a
chair's
perspective,
I
think
that
actually
helps
because
if
you
start
double
up
double
upping
on
the
requirements,
language
and
one
ever
changes
in
the
other
spec,
then
you
have
to
keep
them
in
line.
So,
if
you're
referring
to
something
else,
it's
better
to
just
leave
it
alone
like
if
it
says,
must
and
the
other
one
we're
just
gonna
do.
Must
here,
there's
no
change,
so
I
think.
D
The
second
one
is
the
third
one
is
the
the
discussion
about
if
we
should
support
basic
on
or
other
or
why
we
were
like
fixing
the
authentication
to
use
the
very
token
there
was
already
a
concert
about
that
basic
should
not
be
supported,
and
we
have
provided
a
way
how
about
how
to
use
like
a
username
and
password,
or
something
like
that
in
in
the
token
of
the
of
the
beer
header
and
anyway,
if
there
is
any
new
authentication
method
for
http,
we
will
have
to
update
with
spec
anyway.
D
C
D
A
Yeah,
so
to
be
clear
like
this,
is
the
we're
not
going
to
do
this
we're
moving
on
because
we
did
work
in
group
last
call.
So
if
you
object-
and
you
really
think
one
of
these
changes
need
to
happen,
the
mic
line
is
open.
If
not
we're
going
to
move
on
and
consider
these
closed
going
once
going
twice,
I
don't
see
anybody
in
the
queue
sold.
D
So
next
one
so
this
is
a
this
was
a
I
have.
I
just
put
some
of
the
of
the
changes
that
I
have
made
to
the
drop
that
may
have
some
impact
so
we'll
like
to
get
some
some
from
the
group
that
to
approve
it,
because
this
was
not
in
the
draft
that
was
a
in
the
working
group
last
call.
So
this
is
some
changes
that
I
think
that
will
need
consensus
in
order
to
be
approved.
D
So
I
have
added
here
in
a
change
that,
if
any
of
them,
if
none
of
them
is
supported,
then
then
the
patch
must
return
a
405,
meaning
that
none
and
the
patch
request
is
not
accepted
at
all,
neither
for
israel,
restart
or
or
or
tricolize,
and
if
the
request
is
safe
from
trigger
lice,
and
you
only
support,
if
start
or
vice
versa,
what
it
is
going
to
be
in
returning
the
501
and
not
implemented
for
the
requests
that
are
not
supported.
E
This
sentiment
here
is
correct.
Sorry,
adam
roach.
I
think
the
sentiment
here
is
correct.
The
wording
I
think,
means
a
little
bit
of
thing
because
the
the
phrasing
around
when
to
send
the
the
405
is
a
little
bit
confusing,
but
I
think
that
this
is
technically
the
right
way
to
do
it.
D
Okay,
so
sorry
you
I
mean,
because
it
is
difficult
for
me
to
just
if
it
would
be
great
if
you
could
just
write
a
small
pr,
so
we
can
address
it
and
and
then
the
concern
so
because
I
mean
I
can
write
it,
but
then
I
will
have
to
go
back
to
you
and
see
if
you
think
that
this
is
okay.
So
maybe
it's
easier,
if
you
just
can
write
it
down.
D
A
D
But
what
happens
if
the
the
question
was?
What
happens
if
the
resources
does
not
require
out,
because
we
were
requiring
that
the
options
request
was
one
authentic
authentication
in
order
to
retrieve
the
to
provide
the
and
the
student
already
and
internal
credit
deals
and
what
I
have
removed
that
and
then,
then
that
is
an
authenticated
options
to
be
returned.
D
D
D
A
G
F
E
I
was
just
like
looking
at
the
the
pr
I
was
going
to
put
in
here
for
the
the
trickle
ice
and
I
support
language
for
patch
and
actually
the
text
in
here
when
I
went
to
recraft
it.
I
think
it's
a
little
backwards.
E
E
C
Yeah,
john
max,
I
didn't
put
myself
in
the
queue.
Sorry,
I
guess
the
only
other
thing
I'd
say
is
if
you
support
patch
for
any
other
reason,
but
not
these,
you
should
still
treat
it
as
hey.
I
understand
what
patches,
but
not
this
one,
even
if
you
don't
support
either
trickle
ice
or
ice
restart.
D
So
this
is
a
the
the
the
one
yes,
this
is.
I
think
that
there
was
a
did
that
from
christopher
and
he
that
he
thought
that
it
was
a
bad
idea
to
go
about
the
masjid
they
set
setup
at
pass
in,
and
we
have
had
a
discussion
in
the
hope
issue
and
he
provided
this
this
change.
So
I
think
that
he's
okay
with
that
change.
So
so
I
think
that
so
the
question
is
say
how
about
the
rest
of
the
group.
D
So
the
the
issue
is
that
we
want
to
support
clients
or
with
clients
to
not
have
to
implement
both
at
pass
and
what
not
to
support
at
that
pass.
That
means
that
they
have
to
a
attacks
and
be
able
to
handle
activity
and
passive
for
the
from
the
depending
on
what
the
servers
say
chose,
but
our
idea
has
been
always
from
the
beginning
to
be
able
to
lower
the
barrier
of
implementing
clients.
A
H
I'm
sorry,
but
it
was
actually
about
the
previous
slide.
So
I'm
sorry,
I
missed
the
opportunity
because
I
wanted
to
discuss
the
other
discussion
to
finish.
If
you
could
please
come
back
to
the
previous
slide.
G
H
Okay,
so
my
point
is
that
so
the
natural
thing
to
work
with,
as
far
as
I
understand
the
webrtc
api,
the
browser
api,
what
you're
doing
is
that
you
first
generate
an
you.
First
generate
an
offer.
You
apply
it
to
the
peer
connection,
then
you
send
it
to
your
room
to
the
server
and
by
the
time,
when
you
apply
it
to
the
peer
connection,
you
need
to
know
about
your.
I
servers
so
in
the
proper
protocol.
There
are
two
ways,
two
things
that
can
happen.
You
can
either
send
the
options
first.
H
In
order
to
get
the
I
servers,
in
which
case
you
do
the
natural
thing,
or
else
you
don't
do
the
options,
in
which
case
you
are
applying.
You
need
to
send
the
offer
before
applying
it,
which
means
that
there
are
two
different
behaviors
from
clients
for
clients
that
are,
the
drab
doesn't
make
any
choice
between
the
two
behaviors,
and
so
one
of
the
two
behaviors
looks
really
bad
to
me
in
the
case
in
which
the
client
is
on
a
restrictive
network
that
only
allows
outgoing
tcp.
H
I
know
I'm
not
sure
what
the
consequences
are
of
sending
the
of
sending
the
offer
too
early
and
the
other
one
which
will
simply
not
work
in
some
cases
and
I'm
afraid
that
that's
going
to
be
very
difficult
to
debug,
that
we
are
going
to
have
connectivity
issues
with
some
clients
or
not
others,
and
I
would
like
the
draft
to
at
least
strongly
recommend
one
of
the
two
behaviors.
D
H
No,
what
I
mean
is
that
if
I
am
the
server
maintainer,
I
do
provide
a
turn
server
that
I
know
does
work
for
my
client
population
right
in
this
case.
There
is
no
way
I
can
guarantee
that
all
clients
will
be
using
it.
So
I'm
going
to
have
some
clients
working
some
clients,
not
working,
and
that's
going
to
be
help
to
debug
and
help
to
explain
to
your
users.
D
Do
you
want
to
to
to
to
to
mandate
that
the
client
support
one
of
both.
H
D
H
H
D
H
Giving
implementation
guidance
to
implementers
cannot
be
a
bad
thing,
and
so
the
use
case
of
having
the
clients
behind
a
restrictive
network
is
something
that
is
important
in
my
world.
Okay
in
academia,
most
networks
are
extremely
especially.
Student
networks
are
very
restrictive.
Tcp
is
the
only
thing
that
has
a
good.
D
H
H
H
So
I
would
so
what
I
would
like
would
be
to
have
to
provide
to
make
it
compulsory
for
servers
to
implement
providing.
I
servers
before
the
peer
connection
is
created
before
the
initial
offer
is
sent
and
making
it
should
that
the
client
should
use
the
the
I
servers
provided
by
the
server.
D
D
So
if
you
want
your
service
to
support
tune,
I
mean
it's
okay
for
you,
but
we
cannot
mandate
everyone
to
support
or
to
require
two
servers
in
order
to
run
to
run
a
web
server.
So
we
can
add,
the
client
should
support
and
some
of
the
configuration,
but
we
cannot
mandate
that
the
media
servers
always
send
a
to
a
server
configuration.
Okay.
H
H
So
could
you
please
outline
so
I've
asked
it
on?
I
think
it
was
on
github
or
in
the
mailing
list.
I
don't
recall,
could
you
please
outline
what
happens
if
the
server
is
providing
a
working
turn
server,
but
the
client
is
behind
a
restrictive
network?
Is
that
a
case
where
we
give
up
english?
Are
we
saying
that
the
case
of
clients
that
are
on
restrictive
networks
is
not
something
for
which
which
is
suitable.
D
H
A
E
Ahead,
adam,
so
the
the
point
that
was
raised
on
the
list
that
I
recall
is
that
it
may
require
actual
acquisition
of
resources
to
provide
these
urls
and
under
those
circumstances,
it
isn't
realistic
for
a
server
to
be
able
to
provide
a
response
in
options,
because
it's
not
certain
that
it's
going
to
be
able
to
like
authenticate
and
put
this
request
through.
It
doesn't
want
to
allocate
resources
for
that,
and
I'm
sympathetic
to
that
position.
E
I
think
we
probably
want
to
do,
is
highlight
for
implementers
that
this
is
an
edge
that
might
catch
clients
out
and
make
them
aware
that
if
this
situation
appears
to
be
occurring,
they
should
alert
the
user
that
something's
going
on,
at
least
for
the
purpose
of
making
it
easier
to
operate
these
networks.
Because
I
also
understand
the
point
that
julius
is
raising
here,
where
just
operationally
deploying
these
sorts
of
things
where
the
client
silently
fail
is
going
to
be
painful.
G
I
I
mean
I
keep
hearing
that
we
can't
mandate
that
the
servers
do
x.
I
I
don't
have
an
opinion
on
whether
they
should
or
should
not
do
x,
but
I
think
we
could
mandate
that
there's
nothing
stopping
us
from
doing
that.
If
that
was
what
the
working
group
wanted
to
do
right
and
we
do
that
lots
of
other
places
and
anytime,
you
have
something.
That's
like
a
fully
compliant
client
can't
operate
with
a
fully
compliant
server
and
they're
not
going
to
work
on
a
network
condition
that
occurs
broadly
all
over
the
place.
I
That's
never
a
great
situation
for
me
like
so
I'm
sort
of
sympathetic
to
trying
to
you
know
have
protocols,
and
obviously,
if
we
say
you
know,
you
must
do
codec
y,
it
doesn't
mean
anyone
won't
just
ignore
that
code.
That
thing,
but
at
least
when
that
happens,
you
can
say
like
look
you're
no
longer
implementing
the
spec
and
that's
why
it
doesn't
interoperate.
So
I
don't
know
I'm
just
pushing
back
a
little
bit
on
the
saying
we
can't
do
this.
I
think
we
could
do
this,
whether
we
should
do
this
or
not.
D
C
H
May
I
still
so
basically
what
I
see
right
now
in
the
current
draft
are
three
different
client
behaviors.
You
can
either
well
four,
but
one
doesn't
make
sense.
You
can
either
do
the
options
to
get
the
I
servers
or
not
to
do
it
and
you
can
either
do
the
offer
before
you
apply
it
or
after
you
apply
it,
and
that
will
have
different
consequences
and
different
things
about
ice
servers
and
candidates.
H
So
I
see
three
different
behaviors
for
clients
and
that
worries
me
because
they
will
behave
differently
and
they
will
cause
operational
problems.
I
would
really
like
it
if
we
could
at
least
strongly
recommend
one
of
the
three
possible
behaviors
having
three
different
behaviors
for
clients
is
going
to
be
absolute
help
to
debug.
D
F
D
The
solution
for
this
I
mean
I'm,
I'm
okay,
afraid
of
of
putting
that
the
client
should
use
the
the
the
turn
servers
provided
by
the
by
by
the
by
the
web
server,
either
in
the
options
or
in
the
in
the
link.
I'm
also
okay,
saying
that
the
media
servers
should
provide
the
in
case.
They
support
two
servers.
They
should
probably
should
provide
it
in
both
the
options
and
in
the
and
in
the
http
post.
D
A
So,
just
to
be
clear,
the
whole
point
is
to
get
through.
The
working
group
last
call
comment,
so
we'll
we'll
take
this
time,
we'll
take
up
the
future
conversation
we'll
we'll
just
shorten
that
a
little
bit.
So
all
right,
let's
go
to
the
next
one.
Why
does
this
not
want
to
work?
What
is
my
laptop
doing
stab
next
nope?
It
doesn't
like
that
one
passive
setup
it
finally.
D
So
so
we
have
rewarded
it
too
then
to
to
change
the
the
the
wording.
So
we
recommend
that
the
the
the
the
preferred
option
is
to
follow.
Then
the
rcc57c3
to
turn
to
an
attack,
an
ad
pass
attribute,
and
only
in
case
that
the
endpoint
it
does
not
support
a
setting
then
setting
it.
It
can
and
just
choose
to
to
send
an
update,
but
it
is
not
a
guarantee
that
it
will
work
and.
D
F
G
A
D
D
So
the
idea
is
that
then,
that
that
this
is
the
way
that
I
have
added
a
note
that,
depending
on
the
ice
implementation,
because
it
is
not
really
specified
when
they,
when
the
the
the
phase
should
be
started,
it's
obviously
not
after
the
before
the
in
the.
So
in
order
to
prevent
the
restart,
there
may
be
some
cases
when
you
need
to
apply
the
in
the
local
description
after
a
applying.
D
H
Sorry,
what
does
the
going
once
going
twice
mean?
Does
it
mean
that
we
agree
with
the
current
wording?
So
I'm
I'd
like
to.
D
D
So
this
is
the
the
case:
what
that
and
specifying
what
will
be
the
the
behavior
if,
if
a
client
send
more
than
one
audio
on
video
track
or
more
than
one
stream,
so
we
don't
have
currently
anything
in
the
in
the
in
the
graphics.
Fourth
into
just
one
audio
on
or
video
track.
D
So
and
currently
we
have
just
leave
the
the
implementation
a
bit
open
about
what
would
the
the
server
be
expecting?
So
this
is
a
trying
to
address
a
bit
more.
There
is
an
area
in
which
the
client
sends
something
that
then
that
the
server
is
not
expecting.
D
This
could
happen
not
only
in
case
the
that
the
audio
that
the
client
sends
multiple
audio
video
tracks
or
multiple
streams,
but
it
may
happen
also
in
if,
for
example,
the
the
client
sensor
audio
on
video
stream,
but
the
media
is
already
expecting
an
audio
only.
D
E
Thanks,
so
I
think
this
is
an
okay
behavior
at
a
high
level.
The
406
response
isn't
quite
right.
That's
used
for
content
negotiation
and
it's
not
a
semantic
match
for
this.
I'm
gonna
have
to
dig
in
and
see
what
we
might
use
the
better
422
might
work.
I'm
gonna
have
to
go
and
check
the
formal
definition
of
that
this
might
end
up
just
being
a
400
if
we're
going
to
be
compliant
with
http.
C
Yeah,
I
guess
two
points
one.
This
makes
me
a
little
nervous,
because
this
is
very
much
not
the
back
compatibility
model
that
offer
answer
or
uses,
which
means
that
I'm
worried
that
some
future
extensions
might
end
up
being
hard
to
deploy,
because
you
have
this
mismatch
here.
I
can't
think
of
anything
concrete,
but
I
guess
my
other
question
is:
how
is
I
mean
not
having
read
the
entire
draft
in
a
while?
Does
the
client
know
how
many
like
it's
concretely
like?
Is
the
client
have
a
way
to
know
that
the
server
is
expecting
audio?
D
I
would
expect
that
this
is
something
that
you
can
have
it
on
your
configuration,
I
mean
when
you
you
are
sending
to
youtube.
You
know
that
this
supports
audio
video.
If
you
are
sending,
for
example,
to
cliffhouse,
you
know
that
it
is
sending
to
audi
only
so.
It
is
something
that
I
think
that
should
be
kind
of
expected
to
be
known
in
in
in
at
configuration
time.
So
that's
why.
D
I
think
that
it
is
better
to
fail
completely
that's
to
indicate
that
it
is
something
that
something
is
going
wrong
that
just
to
partially
work,
so
they
the
clients
that
don't
know
what
is
going
on.
C
All
right
yeah,
I
guess
I
mean
maybe
this
would
be
a
if
this
turns
out
to
be
a
pain
point
in
the
future.
We
may
have
to
add
a
configuration
for
that,
but
that's
probably
okay.
It's
probably
for
that.
C
D
That,
in
the
future
we
will
have
to
like
have
some
something
up
to
they
get
so
the
people,
so
the
clients
can
actually
have
like
they
have
a
get
request
to
their
resources,
so
they
can
have
like
more
information
about
what's
going
on
about
the
station
and
that's
supported
nothing
like
that.
So
I
think
that
this
will
be
solving.
This
will
be
part
of
any
future
extension.
B
D
Register
to
create
a
new,
a
register
in
the
in
the
in
the
urine
super
space
for
for
protocol
parameters,
and
this
is
a
change
a
bit
about
the
format
that
the
other
of
the
extensions
and
I
have
added
the
yeah.
I
have
followed
one
example
that
I
think
that
there
was
a
zip
or
something
like
that
and
tried
to
copy
paste
everything.
A
D
D
Yeah,
so
next
steps
I
will
well.
We
have
one
necessity
that
it
is
a
final
and
or
getting
or
solving
first
day
and
the
the
error
codes
and
some
working
that
will
provide.
Also,
we
have
to
discuss
the
issue
that
julius
has
pointed
out
about
the
the
different
configurations
and
different
behaviors
of
the
eyes
of
the
I
say
of
the
I
servers.
D
A
Yeah
so
I
haven't,
I
haven't,
talked
with
meals.
My
personal
opinion
is
that
we
should,
because
we're
changing
must
2119
relative
language.
The
only
thing
is
I'm
trying
to
be
practical
is:
when
do
you
think
we
can
get
the
changes
done
and
get
a
new
draft,
because
there
there
are
parts
of
the
world
that
go
on
vacation
for
like
august,
so.
A
D
A
I'll
be
optimistic
and
say
we
can
because
that's
what's
been
going
on,
so
that
would
be
great
if
we
can
get
another.
If
we
can
get
people
to
submit
comments
on
the
proposed
changes
and
the
keep
the
discussion
going
on
this,
I
think
we
can
move
it
forward
all
right,
so
we've
got
about
10
minutes
left.
A
So
thank
you
very
much
sergio
one
of
the
big
questions
that
we
have
is
that
this
dr
this
working
group
has
a
chartered
item
a
chartered
item
and
we
are
very
much
closing
in
on
getting
done
with
that
item.
What
do
we
do
so?
The
question
is,
you
know
we
could
look
at
extensions
and
look
at
other
things
and
sergio
has
some
ideas.
He's
actually
got
a
whole
slide
deck
in
another
draft,
and
the
question
is:
do
we
do
this
in
this
working
group
or
do
we
go
back
to
dispatch?
A
E
In
line
so
my
my
personal
take
on
this
is,
I
think
we
want
to
go
ahead
and
get
whip
out
there
in
the
field
get
some
practical
experience
before
we
go
down
the
path
of
trying
to
find
other
things
in
this
space.
E
I
I'm
kind
of
agnostic
about
whether
that
means
putting
wish
into
a
dormant
state
or
running
things
through
dispatch
again
or
you
know,
finding
some
other
home,
but
I
think
that,
just
in
terms
of
the
amount
of
energy
that
we've
seen
in
wish
so
far,
we
should
probably
go
ahead
and
get
like.
I
said
some
experience
around
the
protocol
before
we
try
to
take
another
thing
on
this
group.
I
just
don't
see
it
moving
forward
very
quickly
at
the
moment,.
D
Yeah,
I
think,
in
terms
of
the
extensions
if
to
the
web
protocol.
I
think
that
I
have
some
some
in
mind,
but
I
agree
that
I
think
that
we
should
get
a
bit
more
experience
in
deploying
the
the
the
the
protocol
right
now
than
to
get
feedback
before
trying
to
to
address
them.
So
I'm
not
sure
if
we
should
say
leave
the
well
a
part
of
the
the
web
draft
that
I
will
going
to
to
present
in
a
minute.
A
Okay,
so
I'm
here
and
if
we're
gonna
do
it,
we
can
maybe
do
a
working
group
last
call
and
then
everybody
will
be
okay
with
like
just
kind
of
going
dormant,
which
is
basically
means
we
wouldn't
meet
the
next
session
if
we
get
or
the
next
ietf
meeting.
If
we
are
able
to
get
through
the
working
last
call
documents
to
get
this
to
the
isg
and
are
able
to
review
it
and
we
would
meet.
A
Obviously,
if
we
had
to
deal
with
any
isg
comments
and
we'll
see,
that's
perfectly
acceptable
all
right,
so
we
do
have
like
six
minutes.
You
did
have
another
set
of
slides,
and
so
I
think
we're
gonna
we're
gonna
we're
gonna.
Let
you
indulge
yourself
in
some
additional
slides
and
so
go
ahead.
A
A
F
B
D
D
D
B
Okay,
hello,
hi,
hello,
hi,
yeah
yeah.
This
is
from
by
rt,
from
by
dance.
Actually
yeah
by
dance
has
built
one
of
the
biggest
artistic
platform
in
the
world.
We
call
it
by
rtc
and
to
prove
to
improve
the
service
quality
and
the
stability
and
achieve
the
best
at
user
experiences.
B
We
are
looking
for
integration
with
other
rtc
platforms,
just
like
how
we
integrate
the
content,
delivery
network
platform,
but
unfortunately,
there's
no
existing
way
without
integrating
sdk.
So
thanks
weep
and
it
resolved
the
ingress
problem
to
resolve
the
egress
problem
the
web
was
drafted.
So
thanks
itf
for
the
chance
to
present
and
discuss
it
hope,
weep
and
web
can
help
the
companies
which
are
meeting
the
same
problems
as
us,
so
medical
and
the
bidens
are
working
on
the
poc
now
so
hopefully
we
can
approve
all
the
draft
yeah.
Thank
you.
B
D
So
so,
as
john
juan
has
already
said,
I
mean
even
if
aggress
is
outside,
of
the
scope
of
the
with
working
group
right
now,
I
think
we
have
reused
almost
all
the
mechanisms
and
that
we
have
to
pay
them
in
place
for
whip.
So
this
is
what,
with
what
sorry
go
one
slide
before,
because
if
not,
I
one
is
like
okay,
so
the
the
draft
that
we
have
brought
written
is
basically
replaced
with
fro
for
web,
and
that's
all
that
was
required
to
to
be
done.
D
I
think
that
it
is
very
important
for
some
kind
of
devices
like,
for
example,
like
tvs,
because
in
tvs
you
cannot
typically
or
it
is
when
you
have
like,
for
example,
impeccable
other
same
things
supported
when
you
have
have
the
the
native
player
of
the
of
the
tv
playing
a
video,
but
you
can
not
have
that
for
webrtc,
and
also
this
has
already
been
some
conversation
on
going
in
in
about
having
to
how
to
integrate
the
impact
das,
with
webrtc
and
being
able
to
provide,
for
example,
a
mixed
experience
where
you
can
have
the
the
user
being
able
to
switch
between
a
live,
webrtc
stream
and
a
time
shifted
version
of
it
to,
for
example,
to
start
watching
the
event
from
the
beginning.
D
Without
that
you
can
fall
back
to
impact
us
for
that
and
so
on.
So
I
think
that
this
would
be
also
interesting
for
that
so
well.
The
question
is:
if
we
should
register
with
working
group
to
include
digress
or
we
should
do
something
else
so
necessary,
so
I
can
easily
yeah.
So
the
idea
is,
I
mean
this
just
replacing
with
for
web,
and
the
idea
is
exactly
the
same.
D
So
you
then
we
play
as
an
http
post
with
sap
to
the
endpoint,
the
input
there
returns
the
answer
and
we
create
and
then
the
request
and
respond.
So
everything
is
set
up
and
we
can
delete
it
in
with
within
our
an
sdp
delete.
So
this
is
really
similar
this
one
please.
D
We
have
added
a
different
option
because
there
are
some
a
first.
There
are
some
webrtc
implementation,
especially
for
example,
unity.
That
does
not
support
doing
great
offer.
So
it
is
it's
strange,
but
it
is
what
it
is
and
also,
for
example,
it
will
allow
to
avoid
to
set
up
another
ambition
session
when
only
audio
is
supported.
So
the
idea
is
to
sorry
I
have
jumped
to
send
and
I
think
that
they
have
the
no.
The
the
graph
here
is
wrong.
D
B
A
Is
this
yeah?
Unfortunately,
we've
run
out
of
time.
Unfortunately,
so
I
guess
we
we
can
take
this.
This
discussion
to
the
mailing
list.
The
slides
are
up
in
the
data
tracker,
so
feel
free
to.
A
Amongst
download
other
I'm
sorry,
I
had
to
cut
you
off
there
thanks
again
for
all
the
presentations
and
discussions
today,
but
unfortunately
we're
out
of
time.