►
From YouTube: IETF110-WISH-20210309-1200
Description
WISH meeting session at IETF110
2021/03/09 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
Okay,
I
think
we
can.
We
can
start
right
now.
So
thank
you.
Everyone
for
joining
the
first
wish
working
group
meeting.
Unfortunately,
it's
online,
but
that
should
be
addressed
in
future
meetings.
So
sean
can
you
go
to
the
next
slide?
Please.
First,
we're
gonna
start
with
with
the
agenda
we're
gonna
start
with
the
normal
administration.
B
The
usual
ietf
policies
are
in
effect.
You
agree
that
you
follow
the
ietf
processing
policy.
B
If
you
for
example,
aware
that
any
ietf
contribution
is
covered
by
patent
or
patent
application
that
are
owned
and
controlled
by
you
or
your
sponsor,
you
must
disclose
that
fact
or
not
participate
in
the
discussion
as
a
participant
or
an
attendee
to
any
ietf
activity.
You
acknowledge
that
written
audio
and
video
and
photographic
records
of
meetings
may
be
made
public
personal
information
that
you
provide
to
the
ietf
will
be
handled
in
accordance
with
the
ietf
privacy
statement
as
participant
or
attendee.
You
also
agree
to
work
respectfully
with
other
participants.
B
B
So
welcome
again.
We
had
made
on
the
on
the
mailing
mr
request
for
javascribe
and
not
taker.
Did
we
had
any
volunteer
shen?
I
didn't
see
any,
but
you
might
have
are
aware.
C
B
D
E
D
E
Yeah,
so
if
I
open.
D
F
I
like
there,
we
go
oh
yeah.
I
can
act
as
a
jet
prescribe.
B
Fantastic,
so
we
have
about
two
two
slots
filled
and
we
can
proceed.
There
will
be
no
blue
shield.
Mitico
is
taking
care
of
that
automatically
for
us.
Thank
you
and
I
will
let
shan
start,
maybe
on
the
on
the
status
well,
what's
in
on
autoscope
and
the
action
taken
from
the
the
chartered
discussion
itself.
A
Yeah
hi
you'll
note
that
the
insert
graphic
here
I
wasn't
witty
enough
when
I
was
making
these
slides
account
with
a
cute,
wish
graphic
to
put
on
the
right
so
next
time
we'll
get
on
that.
More
importantly,
what's
in
and
out
of
scope,
basically,
this
is
a
kind
of
a
narrow,
narrowly
scoped
working
group
and
there's
only
a
couple
of
things
that
we
are
chartered
to
do
something.
That's
simple,
extensible
https
based
and
it's
a
signaling
protocol.
A
But
the
plan
is
to
establish
a
one-way
webrtc
session
between
broadcasting
tools
and
real-time
media
broadcast
network,
and
that's
about
it
we're
going
to
try
to
stay
very
tightly
focused.
We
we're
not
trying
to
you
know
change
sdp,
we're
not
trying
to
you
know
change
https
or
any
of
that
other
stuff.
We're
trying
to
stay
on
point
with
this,
so
when
we
have
anything
that
we're
going
to
adopt
or
work
on
we're
going
to
try
to
make
sure
that
we
stay
within
scope.
A
A
Yeah
then
we
need
some
extensibility
is
something
that
jonathan
lennox
has
highlighted
during
the
work
in
progress
discussions
at
dispatch,
109.
B
No,
no,
I
think
I
think,
that's
pretty
clear.
Maybe
I
want
to
add
for
the
people
that
are
not
familiar
with
the
etf,
that
if
there
are
some
stuff
that
would
like
to
do,
that
is
not
in
the
skop.
There
is
the
rtc
web
group
that
is
still
open,
and
there
is
the
dispatch
group
that
is
here
to
welcome
any
new
request
or
for
for
work
like
this.
G
G
Yeah,
we
have
a
problem
right
now
when
using
webrtc
for
for
real-time
streaming
and
that
currently
there
are
modern
signal,
improv
products.
I
think
that
it
is.
We
acknowledge
that
webrtc
is
the
best
media
transfer
for
real-time
streaming.
I
mean
it's
the
the
best,
the
best
one
for
low
end
to
end
and
delay.
G
I
H
So
every
one
of
the
large
shipping.
J
Video
at
very
different
bit
rates
to
very
different
users,
and
because
of
that
they
end
up
transcoding
extensively
on
the
server
saw
on
the
media
distribution
side
before
they
distribute.
J
So
are
you
going
to
try
and
are
going
to
try
and
support
that
or
avoid
that?
Like
I
mean
the
two
options
are:
are
if
you're
trying
to
avoid
that
which
eye
cream
has
latency
problems?
Like
you
pointed
out,
then
it
means
the
client
needs
to
deliver
all
the
bandwidths,
which
is
often
very
hard
to
do
on
the
uplink
and
the
model
for
these
large
teams,
just
they
all
tr,
every
single
one
of
them,
I'm
aware
of
today
transcodes.
J
So
I
I'm
asked
I'm
trying
to
get
whether
our
requirement
is
to
be
able
to
deliver
multiple
bandwidths
up
and
not
transcode,
or
whether
we're
going
to
assume
transcoding
will
be
happening.
I
think
that
that's
a
pretty
big
architectural
discussion
like
decision
point
of
what
we
do
so
maybe
we
don't
need
to
resolve
it
right
now
or
anything,
but
I
think
that
that
requirement
might
be
a
little
bit
more
complicated.
I
mean
you
have
thoughts
on
that.
G
G
B
Then,
with
with
my
individual
hat
on,
I
think
the
scope
is
for
signaling
protocol.
I
don't
think
we
assume
anything
on
what
happened
with
the
media,
whether
the
trans,
the
it's
similar
castle,
svc
at
the
source
or
transcoding
letter.
I
think
the
telescope.
B
J
Sure,
but
you
just
said
the
requirement
is
the
signaling
support,
simulcast
and
multicast
or
simulcast
and
svc
to
my
knowledge
there
is
not
yet
actually
an
ietf
specification
for
that.
That
fully
does
that,
I
agree,
I
think
that's
the
right
requirement,
I'm
just
saying
you
know
like
that
this
that
there's
a
very
specific
requirement
you
have
in
mind
and
I'm
not
sure
everyone
has
the
same
requirement
in
mind
you
might
want
to.
J
You
might
want
to
be
clear
that
your
requirement
is
for
signaling
that
you
know
you're,
that
this
has
to
support
simulcast
and
scalable
codecs.
J
J
B
B
I
wrote
there's
a
question
harold
if
it's
related
to
to
the
threat
kevin
started,
do
you
want
to
go
ahead.
B
I
think
I
think
we
can
continue
this
discussion
on
the
mailing
list,
but
I
think
callan
has
a
point
and
I
think
there's
a
lot
of
things
that
came
out
for
from
cluster
238
not
very
long
ago.
It
may
be
a
good
time
to
to
clarify.
I
think
it's
a
good
clarification
point.
I
will
take
it
as
an
action
item
to
relay
it
on
the
list.
After
the
meeting.
H
J
I'm
just
my
my
the
only
point
I
I
sort
of
stopped
us
on
the
requirements
is,
I
think
we
actually
have
agreement
on
what
the
architecture
is
in
much
more
detail
than
these
requirements.
Are
that
yeah?
J
You
know
like
if
we
all
agree
on
this
point
that,
like
we're
going
to
avoid
transcoding
and
we're
going
to
do
that
by
using
simulcast
or
scalable
video
codecs,
that's
a
huge
move
forward
in
nailing
down
what
we
need
to
do
in
this
working
group
and
really
narrows
the
solution
space,
and
I
suspect
it's
clearly
what
you're
thinking
without
thinking
you
know,
I'm
trying
to
like
write
down
requirements
that
help
narrow
down
the
solution
space
we
need
to
explore,
so
we
can
get
to
a
solution
faster.
L
J
Thank
you.
I
don't
want
to
over
over
rotate
on
this
particular
issue.
I
it's.
We
almost
sounded
like
we
landed
on
a
spot
where,
like
simulcast
and
svc,
was
mandatory
and
ingest,
and
I
I
don't
think,
that's
necessarily
what
we
want
in
this
case,
although
I
do
agree,
this
is
probably
something
that
we
need
to
nail
down
in
this
back,
so
taking
it
on
as
a
requirement
to
like
clarify.
This
is
good,
but
I
I
don't
want
to
come
out
of
this
thing
that
we've
like
chosen
a
specific
direction.
G
Okay,
so
this
was
the
the
original
requirements
because-
and
some
of
them
has
been
already
challenged
so
and
change
it
so
and
that
the
first
one
that
it
has
to
be
easy
to
use
as,
for
example,
as
ccs,
we
have,
as
our
tmp
is
able
to
use
it
with
just
a
new
your
url,
and
we
only
need
to
support
unity.
Directional
flows,
it
was
also
required
asked
asked
why
what
was
the
use
case,
that
the
usc
is
as
an
encoder
publishing
to
a
server?
G
So
one
of
the
original
assumption
is
that
the
server
was
assumed
to
be
publicly
retractable
for
the
encoder
or
the
broadcaster,
but
adam
has,
and
another
people
thinks
that
it
is,
would
be
also
good
to
to
support
having
the
media
service
behind
and
not
environments
without
and
by
supporting
the
I
say
candidates,
and
it
should
be
something
easy
to
support.
So
I
just
leave
it
here,
but
it
will
probably
change
and
there
is
no
really
needs
for
support
for
renegotiation,
but
also
again,
people
think
that
maybe
ice
restarts
should
be
supported.
G
It
has
to
be
compatible
with
webrtc
and
rtc
web
aspects.
So,
for
example,
with
regards
to
simulcas
on
sbc,
we
have
to
implement
what
they
support
and
we
cannot
create
new
new
specs,
for
that
must
support,
authentication
and
should
be
both
be
able
to
implement
it
in
browsers
and
in
native
encoders,
and
the
idea
is
to
lower
the
the
the
requirement
and
the
implementation
costs
for
supported.
G
Embossing,
however
encoders
and
requested
by
supporting
the
less
amount
of
generalities
that
would
make
it
hard
to
implement
and
interoperate,
because
the
idea
is
that
the
there
is
a
broad,
the
range
of
encoders
and
both
hardware
and
software
that
are
available.
B
G
Okay,
so
the
idea
of
the
original
idea
was
to
just
make
an
a
simple
http
post
url
and
that
it
is
that
it
is
a
the
url
of
the
web
endpoint
and
to
do
an
sdp
offer
answer
in
the
post
request
that
will
allow
us
to
set
up,
I
say,
and
then
the
data
list
and
rtp.
So
originally
we
I
was
proposing
that
a
ice
contest
fresnel
was
used
for
the
disconnection
and
also
details
are
down
to
to
to
signal
the
normal
disconnection
from
the.
G
Most
people
and
other
people
think
that
it
would
be
good
to
have
more
more
commands
to
be
able
to
terminate
the
session
explicitly
because
a
dtls
can
be
lost
on
and
not
to
have
to
wait
for
the
ice
disconnect
this
time
out
before
being
able
to
terminate
the
session
and
the
after.
His
authentication
onto
the
decision
is
done
by
via
a
standard,
http
header
request.
G
Both
then,
and
I
was
proposing
to
use
the
authentic
authorization
header,
but
in
some
people
think
that
it
would
be
also
good
to
to
have
digest
authentication
via
username
and
password,
but
as
long
as
it
is
supported
by
http.
I
think
that
we
can
support
both,
and
we
also
this
will
also
support,
redirections
and
load
balancing
by
just
the
returning
and
the
different
redirection
response
from
there
with
pinpoint
8.2
and
to
you
could
have
a
url
for
a
a
for
an
entry
point,
and
this
would
ready.
J
H
J
Go
I
just
want
to
make
sure
the
discussion
around
the
different
authentication
methods.
I
think
I
may
have
been
the
one
who
initiated
that
and
after
looking
at
it
a
little
bit
more,
I
don't
think
we
have
that
requirement
anymore.
So
I
just
wanted
to
throw
this
out
there
to
see
if
anyone
else
had
thoughts
on
that.
If
it
was
just
us,
then
I
think
we
can
probably
retract
that
as
a
requirement.
J
B
J
B
J
Whether
we
why
we
really
think
we
need
ice
and
what
our
alternatives
are
for
for
that
that
area,
because
or
or
what?
What
are
the
restrictions
on?
How
we'll
use
ice
something
in
that
space,
because
right
now
ice
is
one
of
the
largest
failure
points
of
webrtc,
and
I
think
that
we
could
make
it
much
better.
At
the
second
point.
Well,.
B
I
can
already
respond
at
the
chair
right.
We
want
to
be
back
what
compatible
with
we're
about
to
see
and
webrtc
mandate
ice
to
a
certain
extent,
so
we
won't
be
able
to
completely
remove
it
in
a
way
that
will
not
be
compliant,
but
the
discussion
between
do
we
support
ice
light
or
full
eyes
or
trickle
eyes,
and
things
like
that
is
in
the
scope.
So
what
I
propose
is
I
put
a
second
point
after
authentication
in
that
40
minutes
period,
at
the
end
of
the
of
the
meeting
for
a
longer
decision.
J
J
J
J
So
I
I
did
want
to
address
the
both
the
charter
issue
and
the
the
notion
of
of
what
constitutes
webrtc.
Here
the
the
charter
does
say
we're
going
to
use
webrtc
as
a
basis
and
right
now,
if
you
read
through
even
the
base
specifications
ice,
is
absolutely
a
requirement
for
getting
things
set
up.
You
can
add
on
optionalities
things
like
the
simulcast,
but
the
I
don't
think
the
discussion
of
whether
we're
going
to
use
ice
is
in
scope
here.
J
J
In
the
charter
right,
that's
that's
my
only
thing.
I
the
the
thing
that
that
was
actually
raised
of,
like
hey,
it's
ice,
light
single
ips.
All
those
things
is
exactly
the
discussion
like
I'm
not.
This
was
not
a
discussion,
I'm
trying
to
kill
ice.
The
discussion.
Can
we
talk
about
how
we
use
ice
to
dramatically.
H
B
J
There
are
no
extensions
possible
to
webrtc
in
this
work
because
we're
not
going
to
manage
to
do
it
that
way
like
like
that's
very
unlikely
than
what
we
want
to
do
right.
We're
not
looking
for
extensions
here,
we're
just
looking
for
no
emissions
right.
That's
you're
asking
to
omit
what
is
fundamentally
a
core
feature
of
webrtc
session
startup.
I.
H
J
Not
ask
to
remove
ice,
I
discussed
time
to
discuss
ice
right,
and
what
I
want
to
discuss
is
exactly
all
the
things
alex
rightfully
raised
of
like
hey.
Can
we
assume
that
the
far
end
has
a
public
ip
address?
For
example,
could
we
you
know
that
dramatically
changes
what
you
need
to
do
to
do
ice
and
no?
I
do
not
believe
that
this
work
should
require
that
the
end
point
on
the
full
side
implements
full-blown
ice.
Necessarily.
K
B
M
So
I
would
like
a
clarification
about
the
charter,
so
are
we
as
humans
here
that
everything,
so
the
stock
seems
to
imply
that
signaling
goes
over
some
sort
of
restful
interface
or
perhaps
something
that
resembles
sip?
And
I
have
the
impression
that
much
of
the
webrtc
client
server
community
has
standardized
on
using
websockets.
M
B
So
the
scope
of
the
of
the
charter
is
a
signaling
protocol.
It's
one
way
with
most
of
the
time
the
destination
not
being
a
browser,
so
it
fits.
What
harold
comment
was
addressing
it's
webrtc
based
right,
so
that
means
we
need
to
use
jset,
for
example.
So
in
all
the
specifications
we
have
an
ietf
for
jsat.
B
N
B
And
so
until
today,
everybody
could
use
whatever
they
wanted
and
that
included
xmppc
websocket,
whatever
you
want,
but
it
was
not
standardized.
So
the
idea
here
of
the
of
the
scope
of
this
group
is
to
say
in
the
specific
use
case,
of
a
one-way
webrtc
base
between
something
and
a
network
right
and
a
platform
where
we
can
make
some
assumption
about
an
ip
we're
gonna
define
an
http
based,
simple
signaling
protocol.
M
B
J
So
I
just
wanted
to
address
so
julius.
You
are
correct
that
the
like,
when
you're
talking
about
regular
web
applications
talking
to
themselves
internally,
that
websockets
is
fairly
popular
here
as
a
practical
matter
for
the
proprietary
clients
that
have
been
put
out
in
this
space
in
active
production
by
and
large
they're
using
restful
interfaces.
J
B
F
I
think
that
the
idea
that
we
should
consider
web
sockets
is
worth
at
least
a
little
bit
more
consideration.
So
far.
The
discussion
on
the
list
has
seemed
to
be
about
simplifying
the
implementation
on
the
encoder
side
and
keeping
that
kind
of
minimal.
F
But
if
you're
already
implementing
all
these
other
things
for
the
media
flow,
you
already
have
much
more
complexity
than
websockets
brings
to
the
table,
so
the
benefit
would
be
that
we
don't
have
to
invent
new
semantics
to
layer
on
top
of
http
semantics
going
back
and
forth.
F
So
some
of
the
things
that
we've
discussed
about
commands-
and
you
know
how
to
manage
the
session-
you
know
using
a
heartbeat
as
a
chance
to
you,
know,
respond
or
send
a
message
from
the
server
to
the
client
that
is
all
simplified
by
using
kind
of
the
existing
de
facto
websockets
approach.
So
I
think
that
we
should
be
at
least
carefully
consider
our
reasons
for
ruling
that
out
and
maybe
articulate
them.
G
Yeah
yeah
and
though
I
was
going
to
recommend
that
I
agree
with
mike
that
I
think
that
resist
is
good
and
if
we
keep
and
dreams
like
simple
requests,
but
if
we
start
to
introduce
lone
polling
and
things
like
that,
I
also
will
be
more
likely
to
go
move
to
our
socket
into
the
api
that
that
introduced
propelling.
But
I
think
that
adam
will
talk
about
this
in
his
slide.
So
we
can
keep
the
discussion
for
later.
B
Great
thank
you
sergio
and
we
were
a
little
bit
ahead.
Then,
in
a
long
ietf
tradition,
we
we
ate
all
the
time
we
had
gained
next
would
be
adam.
There
will
be
a
a
lot
of
interesting
content.
So
let's
get
ready
for
discussion.
It's
supposedly
20
minutes,
but
I'm
going
to
put
a
30
minute
counter,
just
in
the
spirit
of
controlling
the
time.
B
J
So
I
sat
down
and
looked
through
what
the
things
were,
that
I
believe
we
need
for
this
kind
of
an
in-depth
protocol
and
compared
it
against
what
we
had
in
in
the
initial
proposal
and
came
up
with
a
handful
of
things
in
combination
with
the
comments
that
were
made
during
dispatch.
J
That
I
think
we
would
want
to
add
to
the
wish
the
well
to
whip
the
whip
proposal,
and
this
is
kind
of
the
list
of
areas
for
conversation.
J
J
The
need
for
extensibility
was
put
out
there
as
well
as
the
sorry
and
on
top
of
that,
some
of
the
stuff
that
we've
realized
that
we
needed
from
a
signaling
layer
is
the
ability
to
have
heart
beating
to
determine
at
a
signaling
layer
whether
a
session
was
still
alive,
and
this
is
kind
of
based
on
a
separation
of
concerns
where
you
have
signaling
on
one
layer
media
on
a
different
and
and
a
signaling
protocol
in
the
network
itself
that
talks
between
them,
which
is
a
fairly
common
way
to
decompose
these
sorts
of
things
for
scalability.
J
Now
we're
going
to
touch
on
this
when
we
get
to
the
I
have
some
slides
specifically
on
why
we
might
need
more
ice
operations
than
is
immediately
obvious,
and
we
also
probably
need
to
have
either
a
specific
specification
of
which
media
types
and
how
many
are
going
to
be
sent
or
a
means
of
of
negotiating
that
and
I'll
touch
on
all
of
these
in
future.
Slides
so
go
ahead
and
go
to
the
next
one.
J
Some
of
the
constraints
that
are
put
on
us
by
these
documents,
so
the
most
notable
restrictions
that
we
probably
need
to
keep
in
mind.
As
we
turn
over
various
solutions
in
our
head,
is
that
we
can't
define
any
new
hd
methods,
headers
or
responses
unless
they
have
some
impact
on
http
processing
itself.
J
So
that
means
that
we
can't
put
some
sort
of
like
wish-operation
header
field.
That
indicates
what
we're
trying
to
do.
We
have
to
use
any
existing
methods
that
we
use
to
mean
what
hd
http
defines
them
to
mean.
J
So
we,
this
is
why,
for
example,
we
don't
want
to
use
options
to
mean
ping,
because
options
has
a
specific
meaning,
and
it's
not
that
and
then
finally,
we
can't
define
rules
for
building
http
urls.
We
can't
like
send
a
base
path
and
then
say-
and
then
you
add
these
things
onto
the
end
of
it
in
this
in
this
formulaic
way.
J
Okay,
so
the
first
thing
that
we
probably
want
to
nail
down
is
how
we
want
to
do
session
management
in
general.
This
is
kind
of
a
sort
of
the
base.
How
does
the
protocol
work?
J
One
of
the
there
were
a
couple
of
options
that
are
basically
bending
around
the
mailing
list.
The
first-
and
this
is
very
similar
to
the
the
current
proposal-
is
where
you
would
send
a
post
operation
to
a
url
that
represents
sort
of
a
session
creation,
endpoint
and
then
get
back
a
201
created
response
with
location,
header
field
that
points
to
a
newly
created
resource
and
that
resource
represents
the
session,
and
then,
in
terms
of
when
you
tear
that
down
what
you
could
do
is
you
could
send
an
http
delete.
J
That
means
delete
this
resource,
that's
a
very
good
semantic
match,
or
we
could
have
basically
session
termination
by
whatever
means
we
do
other
operations
for
a
certain
level
of
consistency.
J
The
second
approach
here
would
be
to
send
a
post
to
that
session
creation
url
and
get
an
ok
back
where
the
the
body
contains
in
some
way
a
list
of
urls
that
tells
you
how
to
perform.
The
various
operations
that
the
server
itself
supports
and
one
of
the
things
that's
kind
of
nice
about
this
approach-
is
that,
while
the
post
201
just
the
way
that
http
has
defined,
that
can't
contain
a
body
in
the
answer,
so
you
can't
do
anything
else
really.
J
J
Adam
it
just
seemed
like
we've
got
a
lot
of
experience
with
doing
rest
api
to
send
an
offer
answer
up.
There's
lots
of
languages
for
defining.
I
mean
you
know,
various
api
description,
languages
that
are
supported
by
api
gateways
and
all
those
things,
and
I
just
think
that
we
would
probably
want
to
go
with
a
very
common
practice
way
of
doing
this.
I
do
think
doing
an
offer
answer
and
round
round
trip
should
be
one
of
our
requirements.
J
N
J
D
J
Says
we
can't
do
because
bcp
190
says
we
cannot
do
that.
I
I
don't.
I
think
if
I
think,
martin
on
him
have
discussed
extensively,
bcp
990
doesn't
says
that
and
either
way
I
don't
care.
I
think
we
should
do
this.
The
way
apis
are
largely
done
on
the
internet
today,
regardless
of
whether
bcp
190
says
whatever.
I
think
we
should
do
what
works
well.
J
H
J
J
Sure
I
will
be
happy
to
send
you
a
a
blueprint
or
a
swagger
definition
of
that
which
will
be
like
about
five
lines
and
like
that's,
actually
what
I
think
our
spec
for
this
whole
working
group
should,
more
or
less
be
right,
like
an
ietf,
just
manages
to
wrap
itself
into
into
tangles
of
of
not
doing
what
works
well
on
the
web,
like.
Let's
do
something
simple
and
pragmatic
and
is
proven
to
work
well
today.
We
all
know
how
to
do
this
well,
to.
J
B
In
the
spirit
of
time
and
the
absence
of
distribution
and
statistics
of
apis
across
the
entire
web,
sergio.
G
Yeah,
I
think
that
obviously
I
have
a
favorite
for
between
these
options,
but
I
think
that
it
will
also
depends
which
options
do
we
want
to
add
to
the
basic
negotiation,
because
if
we
don't
want
what
we
do.
D
Yeah,
so
I
think
this
may
I
kind
of
agree
with
sergio,
and
I
think
it
may
also
hang
on
how
load
balancing
looks.
I
think
these
two
options
are
different
for
the
different
load
balancing
techniques.
If
somebody
could
stick
well,
yeah,
okay,
cool
I'll,
try
and
note
myself,
there.
J
Right
so
actually
I
covered
these
just
orally.
Let's
go
ahead
and
go
forward,
so
I
also
wanted
to
add
a
slide
since
it
sort
of
came
up
on
the
list.
I
don't
think
we're
quite
to
the
point
that
we
want
to
have
a
discussion
around
session
management
syntax
until
we
have
an
agreement
in
principle
about
which
session
management
approach
we're
going
to
use
here.
So
next
slide.
J
So
the
the
next
topic
here
is
is
how
we're
going
to
have
extensibility
in
general,
and
there
are
a
couple
of
different
dimensions
for
extensibility.
The.
What
I
would
oppose
is
that
we
have
the
the
wish
document
here,
defining
a
core
set
of
functions
that
clients
and
servers
need
to
implement
and
that,
just
in
principle,
implementing
these
base
functions
needs
to
always
be
sufficient
to
initiate
a
broadcast
and
that
we
want,
on
top
of
that
extension
points
for
adding
new
operations
to
enhance
functionality
and
as
a
separate
concern.
J
Extension
points
for
adding
new
parameters
to
existing
operations
and
the
the
way
that
we're
going
to
achieve
interoperability
with
this
sort
of
scheme
would
be
that
the
clients
and
servers
can
always
ignore
unknown
or
unsupported
operations,
while
still
functioning
correctly.
J
The
analogy
that
I
think
I
put
out
on
the
mailing
list
here
is
one
with
the
way
the
sip
works,
which
is
that,
for
example,
a
base
sip
terminal
can
dial
into
a
conference
bridge
and
have
things
work,
just
fine
for
the
person
dialing
in
they're,
going
to
miss
out
on
enhanced
conference
related
functionality,
and
then
we
have
other
things.
We've
added
on
to
sip
that
allows
the
participant
to
like
do
floor
control
and
to
see
who's
in
the
conference
and
that
sort
of
thing,
but
those
aren't
necessary
to
participate
they're
just
enhancements.
J
And
again,
I'm
looking
to
see
if
anyone's
in
the
queue,
I
don't
see
anyone,
so
I'm
going
to
go
on.
Go
ahead,
no,
nobody
in
the
queue
thanks.
I
mentioned
this
up
at
the
top
around
heart.
Beating
there
are
certain
decompositions
of
networks
that
makes
it
easier
and
cleaner
and
less
resource
intensive
if
you've
separated
concerns
between
a
signaling
plane
and
a
media
plane
and
then
are
able
to
determine
liveness
independently
at
the
signaling
plane
of
the
media
plane.
J
So
one
of
the
things
that
we
propose
is
that
we
would
have
a
simple
heart
meeting
mechanism,
just
whatever
thing
we
use
for
operations
would
include
heartbeat
as
an
operation
and
that
the
client
would
be
expected
to
perform
just
a
very
simple.
You
know
as
small
as
possible
operation
against
the
session
endpoint,
and
there
are
some
things
we
want
to
nail
down
here
like
how
we
determine
what
the
period
for
heartbeats
are
like.
We
could
have
a
hard-coded
thing
or
we
could
have
something
where
the
the
server
indicates.
J
The
client
which
heartbeat
interval
it
expects
or
even
a
negotiation,
although
that
seems
to
be
getting
a
little
bit
too
baroque.
So
let's
go
to
thecube.
G
G
The
the
signaling
is
is
disrupted,
but
the
media
is
flowing
perfectly
because
you
have
different
different
paths
and
I
don't
I
don't
I'm
not
sure
if
it
is
something
that
I
want
to
implement.
I
mean
it's
this
because
we
are
having
a
situation
in
which
we
are
terminating
sessions,
because
because
the
signaling
path
is
not
working
properly
properly,
but
the
media
is
perfect
and
we
are
in
the
tearing
down
the
media
session
when
it
was
not.
B
I'm
going
to
wait,
wait
adam.
There
was
an
there
was
mike
before
that
say
if
we
have,
if
we
want
to
have
an
airbeat
and
so
on,
then
why
not
going
to
websocket.
So
that
bears
two
questions,
one.
What
what
is
the
the
use
case?
What
is
the
necessity
of
a
heartbeat
exactly
and
two,
if
wouldn't
be
websocket,
then
better
in
in
that
case,
before
we
go
to
to
timothy
in
the
queue.
B
I
was
speaking
to
you
adam,
and
I
was
referring
the
question
that
mike
asked
before
about
websocket,
saying
that,
for
example,
if
we
had
to
use
an
herbit,
then
we
might
as
well
use
web
socket,
for
example,
because
that
would
be
bundled
among
other
things,
right
and
and
that
beard
the
question.
Do
we
really
need
on
herbit?
J
Right
so
I
have
to
admit
the
notion
of
using
web
sockets
along
this
hadn't
really
occurred
to
me
before,
so
I'm
going
to
have
to
cross
that
process
that
a
bit
before
I
put
forth
an
opinion
in
terms
of
heart,
beating
being
sufficient
to
push
us
over
that
threshold,
probably
not,
but
I
can
see
between
heart,
beating
and
the
ability
to
send
operations
from
the
server
we
might
get
there.
It
might
make
for
a
bit
of
a
stronger
point
in
terms
of
needing
heart
beating
at
the
signaling
layer.
J
Again
there
are
certain
architectures
where
the
design
makes
this
something
that
is
far
easier
to
deal
with.
If,
depending
upon
what
sort
of
control
structure
you
have
between
a
signaling
plane
and
a
media
plane
such
that,
I
don't
want
to
end
up
with
a
situation.
You
have
to
have
operations
necessarily
initiated
from
the
media
plane
to
say
to
the
signaling
plane.
Hey
this
session
has
gone
away.
J
It's
not
necessarily
an
absolutely
hard
requirement.
It
just
makes
things
a
little
odd
when
you
have
something
coming
basically
from
a
controlled
plane
to
the
controlling
plane.
To
let
it
know
the
session
has
been
torn
down,
as
I
mean
as
a
matter
of
practice.
Obviously,
when
you
have
things
exceptional,
you're
gonna
need
that
sort
of
operation.
D
Yeah,
I
mean,
I
think
you
have
to
think
about
what
the
failure
modes
are,
that
the
heartbeat's
trying
to
protect
you
against
and
and
the
webrtc
experience
is
that,
like
people
really
just
do
shut
their
browsers
and
like
you
want
to
catch
that
in
whatever
your
quickest
way
is
and
and
I'm
not
convinced
that
a
heartbeat
and
certainly
a
websocket
layer
is
going
to
do
what
you
want.
It
doesn't
tie
closely
enough
to
the
media
to
be
useful
in
my
view,
but
I
I
mean
probably
exceptional
on
that.
M
So
I'd
like
to
argue
in
favor
of
heartbeats,
so
coming
back
to
the
academic
use
case,
there
is
this
common
situation
in
which
you
have
100
students
waiting
for
a
lecture,
and
the
students
want
to
have
positive
confirmation
at
the
beginning
of
the
lecture
that
their
connection
is
working
fine.
So
if
they
somehow
get
kicked
out
from
the
network,
they
need
to
be
notified
of
that
in
a
timely
manner,
even
if
no
media
is
flowing
yet.
M
I
G
Yeah
just
talking
about
her
bits,
not
about
bullying,
because
if
we
have
long
pulling,
we
probably
need
hair
bits
anyway,
but
we
need
to
implement
a
media
timeout
from
the
media.
So
I
don't
know
why
we
need
to
do
this
twice
in
the
signaling
plane
and
in
the
media
server,
because
the
media
server
already
has
to
do
ice
content
fresnos.
That
will
time
out
this
noise
received.
G
So
you
have
to
take
that
into
account,
and
I
don't
see
what
extra
value
has
the
this
hair
bit
to
the
signaling
plane
provide
over
the
media
her
bit,
because
if
the
ice
is
same
because,
for
example,
like
whatever
happens
to
your
encoder
and
and
the
media
is
is,
is
has
stopped
flowing
on,
the
ice
is
of
completely
well.
You
are
getting
her
bits
for
the
signaling
plane,
but
then
the
media
is
not
flowing
and
you
have
to.
You
must
handle
this
situation,
so
you
already
need
to
support
that.
G
I
know
sure
exactly
what
does
the
the
herbitore
the
signaling
plane
provides
over
the
media?
The
habit.
J
G
C
G
I
mean
because
we
have,
we
have
got
problems
with
nginx
being
overflowed
and
hair
bits
and
just
stop
for
several
one
minutes.
Something
like
that.
Then
all
the
media,
all
the
media
stations,
were
dropped
because
we
have
a
heart
rate
in
the
in
the
signal
and
plane,
but
the
media
was
perfect.
So
we
have
all
the
sessions
tear
down
because
that
problem
in
the
nginx.
That
was
not
even
the
media
plane.
J
Okay,
so
basically
you're
putting
forth
a
requirement
that
the
session
should
be
able
to
survive
a
failure
of
the
signaling
channel.
J
Okay,
that,
if
that's
the
case,
we
should
probably
document
that
as
a
as
a
constraint
on
the
on
the
solution.
G
B
What
is
saying
is
you
want
to
explicitly
write
it
down
as
one
of
the
requirements
while
it
was
in
implicitly
a
feature
of
your
proposed
solution
before
yeah
nowhere
you
have
written.
I
would
love
this,
the
signaling
session
to
survive
in
case
in
case
it's
broken
and
the
media
is
still
flowing
right.
J
E
J
J
J
You
know
I
I
think
that
part
of
what's
causing
the
confusion
here
is.
Maybe
this
would
we're
talking
about
a
specific
mechanism
to
support
a
signaling
channel,
but
I
think
some
of
us
are
not
100
clear
on
what
the
signaling
channel
is
used
for
after
this
initial
setup
of
of
the
call
I
mean
even
the
the
buy
or
what
like,
maybe
that's.
We
just
got
our
ordering
a
little
bit
wrong
here
of
that.
If
we
looked
at,
you
know
why
do
we
need
a
a
signaling
buy?
Could
we
just
use
a
media
one?
J
What
are
the
other
signaling
mechanisms
that
we
need?
Let
me
call
it
mid-call
for
a
lack
of
a
better
word.
I
know
that's
not
the
right
way
to
phrase
it,
but
you
know
what
I
mean
by
it
once
we
understood
what
we
were
trying
to
use
it
for,
then
I
think
we
would
understand
what
reliability
characteristics
we
needed
of
it
better,
and
then
we
could
discuss
how
a
heartbeat
mechanism
may
or
may
not
be
needed
to
meet
those
reliability
characteristics.
Does
that
make
sense?
It's
just
a
way
of
thinking
about
it.
J
That's
fair
and
we
get
to
some
of
the
operations
here.
I
think
in
one
or
two
slides
the
one
thing
that
I
want
to
hold
out
as
something
to
be
aware
of
is
because
we
might
want
to
have
new
operations
in
the
future.
Casting
back
the
extensibility
discussion,
we
have
to
consider
this
an
initial
set
and
not
a
closed
set
right.
J
J
We
do
minimally
want
the
ability
for
the
server
to
terminate
a
session,
and
I
suppose,
if
we're
going
to
the
the
prospect
of
using
media
level
heartbeats,
then
we
can
use
media
level
termination
for
this.
I
still
have
some
pretty
strong
reservations
about
that
approach,
but
if
we
assume
that
we're
using
signaling
for
session
control
here,
then
we
want
to
be
able
to
terminate
a
session
from
the
server
back
to
the
client,
and
there
are
a
couple
approaches
that
we
could
do
here.
J
The
one
is
sending
server
to
client
operations
in
heartbeat
responses.
Now
we're
assuming
under
that
that
we
would
have
heartbeats
in
the
first
place,
and
there
are
a
couple
of
different
ways
that
we
could
do
this
one
would
be
to
have
the
server
wait
for
a
heartbeat,
and
if
we
have
a
relatively
frequent
heartbeat
cadence,
then
this.
J
Big
of
a
deal
in
terms
of
having
to
have
the
server
have
to
wait
up
to
again,
if
we
use
say
15
seconds
as
a
straw,
man
here
wait
up
to
15
seconds
to
be
able
to
send
an
operation
to
the
client.
That's
not
terrible,
and
the
other
approach
that
we
discussed
briefly
on
the
list
is
having
some
kind
of
long
pull
for
the
heartbeats,
where
the
the
client
would
send
a
heartbeat
and
then
wait
on.
D
Just
lost
adam's
audio,
which
makes
note
taking
tricky.
J
J
So
I
got
I
got
through
most
of
that,
then
the
other
approach
would
be
to
have
effectively
a
long
pole
where
the
heartbeat
transaction
would
pend
basically
for
the
duration
of
the
heartbeat,
and
then
the
server
would
respond
with
you
know
either
a
200
to
the
heartbeat
and
the
says
the
client
would
turn
around
and
initiate
another
one
right
away,
or
if
the
server
wanted
to
send
an
operation,
it
could
send
that
that
response
earlier
in
the
cycle
so
as
to
get
the
operation
of
the
client
as
soon
as
possible.
J
The
other
approach
and
this
sort
of
ties
back
to
what
mike
was
saying,
is
that
we
could
have
a
persistent
channel
setup
like
a
websocket
or
a
data
channel
or
something
that
we
could
send
these
operations
back
to
the
client
on,
and
I
know
we
should
have
a
queue
now.
J
I
I
I
mean,
I
think
it's
sort
of
been
mentioned
by
other
people,
but
I
I
don't.
If
we
need
these
types
of
things,
I
think
that
like
if
we
need
mid-call
signaling,
initiated
from
the
server
to
the
client
or
or
notification
of
things,
it's
very
unlikely
that
a
15-second
delay
is
going
to
be
okay
from
an
extensibility
model
to
the
type
of
stuff.
You'd
want
to
do.
N
J
I'm
not
sure
we
need
it
at
all,
but
like
really
this
looks
like
I.
This
looks
like
one
of
the
hackiest
worst
ways
to
do:
notifications
to
clients.
I
can
imagine.
I
think
we
should
use
something
architectural
a
little
cleaner.
If
we
decide
there's
a
need
for
this
and
like
we
don't
need
to
discuss
it.
Just
their
file
like,
like
hey
opinions,
vary
whatever,
but
I
think,
as
we
come
clear,
what
we
need
it's
fair
to
do
it
and
I
mean
data
channel
I
mean
it
seems
like
we
have
lots
of
options
available.
J
I
mean
seems
like
there's
better
ways
to
skin
this
cap,
but
we're
discussing
about
the
exact
details
of
how
to
move
the
bits
on
the
wire.
When
really
we
should
be
discussing
the
semantics
of
what
information
we
need
to
flow
between
the
the
server
and
the
client
okay.
So
that's
just
that's
an
ordering
comment
effectively
there.
J
Okay,
so
we
can.
We
can
return
to
this
then
after
we
have
a
better,
better
notion
of
exactly
what
it
is
that
we
want
to
accomplish.
We
have
mike
in
the
queue
oh
mike.
F
I
just
wanted
to
kind
of
echo
comment
that
I
I
think
we
have
some
semantics
questions
to
grapple
with
before
we
get
into
the
implementation
details
of
bits
on
wire,
you
know
kind
of
outlining
the
participants
and
some
of
these
different
constraints
that
we've
talked
about.
F
It
may
be
worth
kind
of
surveying
the
status
quo
of
you
know
what
does
a
browser-based
ingest
session
look
like
today
and
then
how
do
we
envision?
You
know
the
participants
of
a
non-browser-based
session
having
different
constraints.
F
I
mean
sorry,
I
may
have
lost
my
army.
I
guess
one
of
the
big
ones
is
you
know
why
not
websockets
right,
like
you
know
it's
come
up
before
I
let
you
know
we
think
we
can.
F
You
know,
get
away
from
this
complexity,
but
if,
if
we
have
need
for
session
management
and
this
two-way
communication,
we're
gonna
want
some
kind
of
persistent
channel,
so
I
think
there's,
I
guess,
there's
two
things,
then
you
know
one
would
be.
You
know
new
constraints
that
come
from
this
different
environment,
which
is
you
know,
encoders
that
are
are
not
browser
based
and
two
would
be
assumptions
that
we
could
make
about
this
context
where
we
can
cull
some
complexity.
F
So
things
like
you
know,
trimming
down
what
we
need
ice
to
do
if
we
can
assume
that
the
server
side
has
public
ip.
I
think
we
can
also,
you
know,
say
similar
things
like
if
we
assume
that
an
encoder
is
only
doing
this,
you
know
we
may
be
able
to
remove
some
complexity
there.
So
but
I
think
that's
maybe
the
level
of
the
discussion
that
we
need
to
have
before
we
get
into
websockets
or
data
channels,
or
you
know
long
polling
or
whatever
actually
makes
sense.
F
D
Tim
yeah,
I
think
we
need
to
think
about
who
the
audience
is
for
this,
like
one
of
the
things
that
isn't
in
the
charter
and
maybe
should
be,
is
the
explicit
goal
from
my
point
of
view?
Is
that,
like
somebody,
who's
who
is
building
a
web
service
at
the
moment
that
is
happily
using
like
rtmp
should
be
happy
to
pick
this
up
and
shouldn't
get
the?
Oh
god
it's
webrtc?
D
I
don't
want
to
touch
it
feeling
and-
and
you
can
like
frown
at
that,
but
it's
a
real
perception
you'll
get
from
a
ton
of
web
developers,
so
the
less
likely
what
you
see
this
looks
the
more
likely
they
will
sign
up
for
it,
and
I
think
it's
kind
of
hard
to
put
that
in
the
charter.
But
I
really
think
that
should
be
a
goal.
B
Scope,
so
the
scope
of
the
working
group
is
a
signaling
protocol
for
webrtc
based
audio
visualization
right
so,
and
we
said
at
the
beginning
with
shan.
We
do
not
want
to
reinvent
without
this
here
to
strip
it
down,
so
we
can
make
a
good
point.
We
might
want
to
go
into
the
webrtc
spec
and
define
it
we
better.
B
What
we
want,
but
one
of
the
things
we
absolutely
do
not
want
is
to
challenge
eyes
to
challenge,
accept
to
challenge
sdp
offer
answer
as
a
way
to
negotiate
the
media
type
and
the
encoder
and
the
decoder
and
things
like
that.
Otherwise,
we
go
down
that
way
about
you
see
we
want
to
be
able
to
navigate
between
possibly
the
optionality
of
webrtc
like
we
have
a
different
ietf
document
for
the
non-browser
for
the
gateway.
B
D
Sorry,
if,
if
I
gave
that
impression
that
wasn't
what
I
meant,
it
is
obviously
going
to
be
web
otc
based-
and
I
don't
want
to
say
anything
different
there.
But
what
I
do
want
to
say
is
that
a
web
developer,
who
picks
it
up,
shouldn't,
be
smacked
in
the
face
with
a
huge
ton
of
webrtc-ness
and
there's
a
distinction
there,
so
that
the
more
we
can
cover
up
the
webrtcness
and
the
more
we
can
make
it
invisible.
D
So
I
think
the
moment
you
have
a
side
channel
that
can
do
stuff,
then
you've
strayed
away
from
the
rtmp
model,
where,
like
you,
set
it
up
and
it
keeps
running
and
it
so
if
the
side
channel
is
the
signaling
channel
is
required,
then
you've
strayed
away
from
the
rtmp
layer.
You
look
at
rtsp
and
rtmp,
and
things
like
that.
G
I
I
agree
with
him
in
that
that
we
should
not
over
engineer
things.
I
mean
we
are
idf
and
we
like
to
do
that,
but
I
think
that
people
is
happy
implementing
rtmp
and
the
functionality
that
rtmp
is
is
very
limited,
and
I've
struggled
to
think
that
we
should
implement
much
more
than
what
our
tmp
does
to
cover
the
same
use
case
that
they
are
doing.
G
I
mean
if
we
can't
at
things
that
that
most
complexity
in
add
value,
we
should
definitely
go
for
it,
but
I'm
reluctant
to
implement
stuff
that
it
is
not
really
proven
to
be
a
mass,
because
it's
feature
that
we
add,
even
after
optional
to
the
spec,
is
going
to
be
less
likely
that
it
is
going
to
be
implemented.
For
example,
in
ffp
mp,.
D
F
Yes,
so
I
think
I
think
what
timothy
is
trying
to
articulate
is
rtmp,
not
necessarily
as
a
complete
set.
C
F
Functionality
that
we
need
to
emulate
here,
but
more
as
an
example
of
the
type
of
use
case
that
we're
going
to
be
attempting
to
translate
onto
webrtc,
because
we
have
some
some
benefits
from
using
webrtc
rather
than
rtmp,
and
so,
if
we
can
kind
of
like
articulate
like
today,
for
example,
you
know
we
do
webrtc
broadcast
out
to
end
users,
but
the
majority
of
our
ingest
is
rtmp,
and
so
we
have.
F
You
know
overhead
from
the
all
the
the
transcoding
associated
with
you
know,
taking
in
rtmp,
and
you
know
outputting
over
webrtc
in
cases
where
we
can
run
webrtc
natively
and
end
everything's
a
lot
cleaner,
but
we
can't
just
point
ffmpeg
at
you
know
our
injust
and
say:
do
a
bart.
You
know:
do
webrtc,
here's
your
webrtc
uri.
F
You
know
it's
a
lot
simpler
for
rtmp.
You
know
on
on
the
the
encoder
side
and
I
so
I
think
what
we
want
to
do
is
stay
focused
on
that
use
case
and
say
you
know
we
want
to
kind
of
basically
work.
You
know
the
way
that
you
can
just
point
ffmpeg
or
whatever
your
encoder
is
at
an
rtmp
endpoint
and
go.
F
B
B
M
I
was
thinking
about
your
case,
which
is
one
person
speaking
to
120
students
and
students,
asking
questions
usually
in
written
form,
which
is
what
we
have
been
doing
during
covered
lockdowns.
M
No,
I
wanted
to
sorry.
No
that's
a
mistake.
I
wanted
to
ask
one
question,
which
is
so
I
I'm
starting
to
understand,
sergio's
point
about
simplifying
the
protocol
and
not
having
a
control
channel
or
minimizing
it.
O
B
M
B
F
F
J
J
If
we
don't
end
up
with
pretty
much
universal
ipv6
deployment
before
we
have
address,
exhaustion
sufficient
to
impact
like
server
deployments
right.
J
So
it's
easy
to
imagine
that
you
have
sort
of
a
first
contact
point,
a
signaling
contact
point
that
has
a
public
ip
address
and
then
a
large
bank
of
like
a
scalable
cdn
behind
that
that
is
actually
behind
that's
and
if
you
ever
end
up
in
that
situation,
we
do
need
to
have
the
ability,
either
with
a
base
protocol
or
with
some
set
of
extensions,
to
have
the
ability
to
have
like
a
full
ice
implementation
with
trickle
and
with
restarts
now
with
a
sufficiently
rich
extension
mechanism.
J
This
isn't
really
an
issue,
but
it
does
kind
of
violate
the
principle
that
that
I
mentioned
at
the
top
of
my
discussion,
which
is
that
we
do
want
the
base
protocol
to
always
be
sufficient
to
start
up
a
session
in
terms
of
the
additional
complexity
that
introduces
as
long
as
we
have
like
operations
that
we
can
send
inside
a
session.
This
is
pretty
minimal,
because
ice
and
trickle
ice
are
already
part
of
jsep.
J
So
assuming
that
people
haven't
like
gone
off
and
implemented
webrtc
from
the
ground
up
and
are
using
like
one
of
the
available
libraries,
this
is
already
going
to
be
included
right,
trickle,
ice
and
ice
restart
are
going
to
be
part
of.
What's
in
the
webrtc
stack
that
you
take
on
and
from
that
perspective,
adding
them
to
whip
isn't
going
to
be
particularly
complex.
J
H
J
This
is
one
of
those
areas
I
think
we've
had
a
lot
of
like
the
the
internet
is
littered
with
like
jokes
about
like
you
trying
to
use
webrtc,
then
you
find
out,
you
need
a
turn
server.
You
can't
find
a
turn
server
and
then
you
give
up
and
go
do
something
else
I
mean
like.
This
has
been
one
of
the
really
hard
points
for
people
to
deal
with.
J
So
let's
talk
about
the
case
where
I
have
a
bunch
of
server
where
I
don't
have
a
lot
of
ipv4
addresses
for
my
servers,
but
I
have
some
and
aws
is
natting
me,
isn't
adding
my
servers
behind
on
the
server
side?
Okay,
the
way
that's
done
is
there
still
will
be
a
port
allocated
and
ip
to
the
load,
balancer
and
then
the
load
balancer
will
span
that
out
to
multiple
machine,
but
I
will
know
my
ip
and
port.
J
That
is
the
thing
I
advertise
I'll
know
that,
ahead
of
time
on
the
server
side,
even
if
I
am
being
added
with
v4
addresses
on
the
server
side
I'll
know
it
will
be
the
type
it'll
be
a
full
cone
style
on
that
it
will
be.
You
know
things
to
be
able
to
come
in
there.
J
Clearly,
the
clients
will
be
behind
that's
all
the
time,
but
it
seems
like
if
we
mandate
that
the
server
must
be
able
to
advertise
an
ip
address
and
port
that
it's
publicly
reachable
at
or
one
of
its
nodes
in
its
cluster
is
publicly
reachable
app,
and
you
know,
first
of
all,
the
server
would
only
have
to
implement
ice
light
which
dramatically
improves
the
performance
and
speed
of
the
high
of
the
high
speed
servers.
J
We
could
get
to
a
place
where
it
was
really
easy
for
the
clients
to
know
in
a
round
trip
that
we
could
say
something
like
you're
doing
ice,
but
the
client
never
provides
anything
other
than
its
reflexive
candidate
and
if
that
goes
up
in
the
offer
and
then
coming
down
in
the
answer,
comes
the
cert.
The
servers
thing
and
you
don't
need
trickle
eyes,
you
know
in
a
single
round
trip
you
can
fill
your
offers
and
answers
with
the
actual
ips
in
use.
J
You
don't
have
to
deal
with
any
of
the
trickle
things
you
don't
have
to
deal.
You
will
never
need
a
turn
server.
You
will.
You
know
we
could
very
much
pair
this
down
to
something.
That's
not
only
easier
to
write
and
deploy
and
is
is
still
sort
of
nice.
It's
still
doing
valid
ice,
but
it's
also
much
easier
to
debug
and
that's
really.
My
main
concern
is
the
much
easier
to
debug
apart,
because
that's
one
of
the
things
where
ice
goes
very
sideways.
J
I
mean:
do
you
see
any
problems
with
I
mean.
Does
that
was?
Does
that
vision
of
constraining
it
in
that
way
limit
anything
that
you're
talking
about
here
or
would
that
work?
So
let
me
answer
that
after
I
ask
well
maybe
clarification
and
ask
a
question.
So
the
clarification
is
that
if
we
were
to
go
down
this
path,
it
wouldn't
necessitate
that
servers
do
anything
other
than
ice
light
unless
they
end
up
in
an
architecture
that
requires
them
to
do
something
more
complex
right.
J
So
this
this
this
still
allows
servers
to
do
isolite
when
their
deployment
supports
it
right.
What
I'm
saying
is
that
the
wish
protocol
could
say
that
all
the
that
the
offer
answers
that
you
know
we
didn't
have
to
basically
the
wish
in
the
wish
servers
needed
to
be
deployed
in
the
type
environment
where
ice
light
was
possible
and
that
greatly
simplified
the
number
of
round
trips
of
signaling.
We
needed
needed
to
do
to
start
up
something
perhaps.
J
J
J
E
J
All
right,
then,
only
that
and
it
will
send
that
in
the
offer
not
send
it
later,
it
will
get
that
before
it
sends
the
offer,
send
it
and
then
it'll
get
back
the
answer
and
the
answer,
because
anything
else
will
not
result
in
media
starting
any
soon
right,
you're
not
going
to
get
media
until
you
have
that
address
right
and
sending
an
initial
one
allows
it
to
even
be
primed
so
that
the
first
packet
come
from
the
server
arrives
like
it
just
it
ends
up
in
an
incredibly
simple
flow,
simple
to
debug.
J
H
B
Queue,
but
I'm
not
closing
that
subject,
so
you
will
have
an
opportunity
to
come
back.
I'm
worried
about
a
client
that
would
be
in
a
bank
or
in
a
network
where
the
the
reflex
candidates
are
impossible
and
we
still
need
a
turn
server.
I
I
don't
think
we're
going
to
be
able
to
buy
that
bullet
on
the
sending
side
on
the
client
side,
but
we
can
have
that
discussion.
H
B
Some
it's
a
wishes
in
one
way.
Right
whip
is
the
one
way
and
so
on
the
on
on
the
sender
side,
it
could
be
within
a
bank
or
within
a
network
that
that
doesn't
that
requires
a
turn
to
actually
go
out
and
traverse
the
net.
You
know
restricted,
not
restricted,
firewall,
restricted
port
need
to
go
over
tc,
tcp
343.
B
J
Well,
I
mean
a
restricted,
nat
or
restricted
firewall
would
not
require
turn
in
this
use
case
with
the
server
ip
address
is
public.
Look
if
it
can't
reach
this
like
this
server
address,
that's
public!
It's
not
going
to
be
able
to
reach
the
turn
server
either.
So
turn
does
not
help
in
the
case
you're
describing.
D
I
was,
I
was
interested
in
that
as
well.
I
think
turn
tls
is
a
question.
Do
we
do?
We
have
use
cases
which
will
require
the
support,
turn
tls,
and
I
think
that
the
benefits
that
we're
talking
about
here
over
rtmp
and
and
and
peg
dash
and
the
other
ingest
mechanisms
are
like
massively
degraded
by
the
fact
that
you
you're
going
to
layer
it
over
tcp
and
tls,
and
so
I'm
kind
of
of
the
view
that
anyone
who's
doing
this
over
turn
tls
is
already
lost.
Now
I
I've
got
no
implementation.
Experience
of
that.
D
So
I
can't
tell
if
that's
true,
but
that's
my
instinct,
so
that
and-
and
I
think
the
other
aspect
is-
I
think
cullen
is
largely
right
with
this-
that
icelite
will
do
everything
we
want
and
it
will
make
the
thing
quicker
and
and
there's
I
see
no
need
for
trickle.
J
One:
okay,
that
that's
fair
and
just
to
respond
to
the
question
that
colin
asked
during
his
his
comments.
I
might
have
to
think
about
it
a
little
bit
more,
but
I,
the
description
sounds
pretty
persuasive.
That
trickle
ice
may
be
something
we
don't
need
in
the
grand
scheme
of
things.
I
Yeah,
so
just
actually
going
even
a
little
bit
beyond
pollen.
If
you
can
assume
that
the
river
is,
if
you
reach,
we
don't
even
need
the
productive
address
you
can.
Just
put
you
know
your
post
address
or
a
dummy
address.
The
server
gets
the
client's
address
as
pure
reflexive.
I
You
don't
need
any
standard
turn
servers
at
all.
The
only
case
is
the
previous
discussion.
If
you
do
need
to
worry
about
case,
if
your
udp
is
blocked
entirely,
then
yes,
you
need
to
worry
about
getting
some
tcp
based,
probably
turn
server
or
candidate,
which
com
which
adds
complexity,
which
is
annoying,
but
if
we
want
to
say
no,
we
assume
udp
is
reasonable
for
this
to
work.
Then
you
can
just
you
know
the
ice.
I
I
simplifies
it
in
a
lot.
Basically,
the
client,
that's
particularly
the
client
logic,
simplifies
a
lot.
L
Oh
hi
luke
from
twitch
just
wanted
to
say
that
agree.
Yeah,
you
don't
need
ice
trickle.
The
idea
here
is
that
this
neighborhood
has
a
nat
as
a
slide
point,
but
it's
really
a
load
balancer
so
long
as
it
has
a
public
ip
address
and
port.
L
It
appears
address
via
the
ip
source,
source,
port
and
ip
address,
so
yeah.
It's
something
that
it's
it's
something
that
we've
been
struggling
with
too.
It's
just
like
how?
How
do
you
want
a
long-lived
connection
or
not?
Do
you
need
it
and,
but
in
the
case
of
ice
trickle,
if
you
just
have
a
public
ip
address
and
port,
you
really
don't
need
this
it'd
be
nice.
B
Jonathan
you're
still
in
the
in
the
list,
but
I'm
going
to
remove
you,
you
can
have
you
on
the
back.
If
you
need
kalin
you're
next.
J
So
I
wanted
to
talk
about
restart,
or
whatever
I
mean
we,
we
had
the
the
use
case
adam
you
know
illustrated
just
a
few
minutes
ago
where
something
went
wrong
and
he
had
to
rejoin
his
media.
I
think
we
have
lots
of
places
where
clients
need
to
redo
media.
J
Sometimes
it's
somebody
just
switched
wi-fi
networks
or
they
went
from
cellular
to
wi-fi
or
something-
and
I
know
that
that's
been
a
hit
on
the
environment,
but
if
we
could
have
pretty
rapid
recovery
like
less
than
two
seconds
of
the
media
when
the
client's
ip
address
possibly
changed
or
redid
something
I
was
going
to
argue
that
that
would
be
a
good
thing.
However,
I
think
jonathan
lennon's
comment
from
like
a
second
ago
sort
of
highlights
that,
like
we're
going
to
get
that
for
free,
it's
no
big
deal.
J
Actually,
the
client
will
just
reconnect
the
same
address,
because
the
public,
ip
and
port
of
the
server
won't
have
changed,
but
where
it's
coming
from
from
the
client
might
change
anyway.
I
think
we
should
talk
a
little
bit
about
that
like
how
we
can
have
rapid
reconnective
media
type
thing
would
be
a
good
thing
and
I
sort
of
assumed
that
ice
restart
would
be
sort
of
part
of
that.
But
maybe
it's
not.
B
So
guys,
I'm
just
going
to
interject
here
for
one
minute
we
have
30
minutes
left,
I
understand
adam.
You
still
want
to
speak
about
media
type
and
then
after
we
have
five
minutes
for
lorenzo
and
we
have
two
extra
points:
authentication
and
ice
ice.
We
we're
speaking
right
now,
so
we
okay,
but
we
have
20
minutes
of
discussion
left.
J
B
J
Don't
expect
the
media
type
conversation
is
going
to
take
very
long
that
it
was
more
a
matter
of
flagging
it
for
people's
attention.
I
could
be
wrong,
but
that's.
I
think
this
is
probably
something
that's
really
important
to
nail
down,
because
whether
we
need
to
do
ice
talk
and
this
this
speaks
a
lot
to
whether
we
need
some
sort
of
session
construct
right.
H
Talking
about
lorenzo
lorenzo
is
in
the
queue.
K
N
So,
first
of
all,
so
don't
worry
about
my
five
minutes,
because
they're
probably
going
to
be
15
or
30
seconds.
I
really.
It
was
just
some
comments
on
adam's
presentation.
So
it's
not
really
going
to
take
that
long,
but
I
just
wanted
to
add
some
notes
about
the
trickle
itself,
which
I
agree
is
not
really
needed
because,
as
we've
seen
also
in
the
early
prototypes,
we
reflexive
can
can
do
the
job
as
soon
as
as
long
as
you
have
a
publicly
reachable
address
address
for
the
server.
So
there's
no
problem
there.
N
I
still
think
it's
it's
a
nice
feature
to
have,
especially
if
it's,
let's
say
optional,
and
if
you
actually
really
want
to
to
convey
this
information
you
can
somehow
and
mostly
for
reasons
that,
I
would
say,
are
let's
say,
figuring
out
some
ambiguities
from
a
service
side
side
of
things,
because
if
all
you
see
are
pre-reflexive
addresses,
you
lose
the
the
view
or
the
perspective
of
where
that
pre-reflexive
address
is
actually
coming
from,
because,
for
instance,
your
clients
may
actually
making
you
be
making
use
of
a
turn
server.
N
I
Yeah,
so
I
think
we
on
the
sort
of
generalized
the
ice
restart
question.
I
think
we
need
some
story
and
you
know
a
good
answer
for
the
various
high
ability,
high
availability
cases.
Both
you
know,
client,
failover
and
a
server
failover
ice
restart
might
be
part
of
that
or
we
might
discover
that
mechanism.
I
We
need
for
that
for
re-establishing
whatever
the
signaling
or
recession
or
whatever
is
sufficient
for
this
new
mail
over
there,
and
I
think
we
should
sort
of
understand
the
whole
story
there
before
we
decide
that
I
just
restarted
this
general
restart
problem.
I
J
Oh
sorry,
no
I
was
trying
to
figure
out
when
you're
talking
about
the
potentially
not
needing
ice
restarts
to
handle
failure
cases.
What
alternatives
did
you
have
in
mind?
Yeah.
I
D
D
N
I
J
E
D
So
so
that
speaks
to
doing
the
201,
because
what
you
get
back
from
the
201
is
the
resource
which
you
could
then
talk
to
again.
So
you've
got
it.
You've
got
a
reconnection
point,
so
you
don't
have
to
go
necessarily
through
the
whole
process.
You,
maybe
we
don't
need
to
reallocate
some
resources
on
the
server
side,
because
you're
going
back
to
a
resource
that
you
haven't
yet
deleted.
J
J
Okay,
so
I
assume
we'll
circle
back
this
at
the
end,
if
there
is
more
conversation
to
be
had,
but
I
guess
for
now
go
on
to
the
next
slide.
B
M
Speaking
about
is
you're,
giving
a
lecture
to
100
students,
and
you
wouldn't
imagine
how
bad
the
networks
are.
If
you
have
100
students,
you
can
afford
three
or
four
people
not
being
able
to
follow
your
lecture.
If
20
people
don't
follow
your
lecture,
you
have
a
problem,
and
now
most
of
the
students
are
some
students
are
on.
You
know
ordinary
home
networks
that
are
not
are
connected
over
4g,
and
you
guys
all
know
what
the
4g
operators
do.
M
Some
are
on
university
networks
and
you
people
don't
know
what
the
university
system
administrators
do,
but
everything
is
firewalled
and
everything
is
extremely
unstable.
I've
seen
sessions
going
over
five
ip
addresses
where
the
websocket
was
staying
connected,
so
the
net
implementations
are
absolutely
frightening
and
in
this
situation
you
want
to
have
a
robust
enough
robust
enough
session
that
your
lecture
doesn't
get
interrupted
in
practice.
We
have
found
that
two
things
are
essential:
it's
falling
back
to
tcp,
okay,
and
you
need
to
very
carefully
choose
your
your
server-side
tcp
port.
M
M
B
Right,
so,
if
I
understand
you
don't
really
care
if
it's
ice
restart
as
long
as
there
is
almost
continuity
in
in
in
the
flow.
So
if
the.
B
Right:
okay,
that's
that's
an
important
point.
I
think
moving
forward
when,
when
we
have
benchmark
of
implementation.
B
B
I'm
just
making
sure
which
which
it
guy
I
need
to
go
to.
M
So,
okay,
I'll
just
say
a
few
words.
Most
of
the
university
networks
were
set
up
in
the
1990s
by
people
who
had
to
deal
with
windows
95
and
it's
always
easy
to
firewall
the
network,
but
then
the
political
issues
with
getting
it
unfired,
25
years
later,
on
next
to
impossible.
B
J
Right
yep,
as
I
say,
the
last
thing
that
I
wanted
to
hit
on
because
it
wasn't
really
touched
on
at
all
in
the
initial
proposal
was
we
want
to
have
some
agreement
on
what
stream
ordinality
to
expect.
J
J
Like
I
said
it's,
so
it's
a
matter
of
we
want
to
document
this,
but
before
we
write
something
down,
I
want
to
make
certain
that
there
are
not
objections
to
the
prospect
that
any
given
session
is
going
to
have,
like
I
said,
zero
one
video
zero
one
audio.
I
see
sergio
in
the
queue.
B
Yeah,
if
you
don't
add
them,
I'm
going
to
let's
search
you,
take
the
mic.
Yeah.
G
G
So
this
is
a
use
case
that
we
may
need
to
support
is
like
a
at
the
end.
It
would
be
only
one
track
that
they
will
be
the
one
that
will
be
selected
but
having
different
options
to
for
having
an
input.
I
mean
I
don't
know
exactly
how
this
could
be
supported.
I
think
that
maybe
sdp
has
a
language
option
or
something
like
that,
but
maybe
it's
a
use
case
that
we
may
consider.
J
Yeah,
there
are
definitely
language
tags
for
that
kind
of
thing
and
if
that's
a
requirement,
we
can
work
it
out.
But
what
I
heard
at
the
end
there
was
that,
after
the
negotiation
completed,
there
would
still
be
only
one
audio
stream
you're
just
performing
some
sort
of
negotiation
in
the
middle
to
determine
which
audio
stream
the
client
elects
to
send
is
that
accurate.
G
Yeah
well
in
my
use,
cases
would
be
that
they
collect
the
the
the
the
encoder
will
not
renegotiate
and
will
send
all
the
languages
at
the
at
the
beginning.
So
the
server
will
allow
the
clients
to
choose
which
one.
But
it
is
not
it's
not
something
that
it
is
dynamic.
It
will,
for
example,
they
will
send
one
film
in
spanish
and
english
and
whatever,
and
then
the
the
client
had
choose,
which
is
the
language
that
he
wants
to
to
view
the
the
film
or
the
stream
or
whatever.
But
it
is
not.
I'm
sorry.
P
G
J
G
But
it
will
not
be
negotiated
or
they
will
just
send
everything
and
then
the
client
will
choose.
The
watching.
Client
will
choose
which
language
he
wants
to
listen
to.
J
G
That's
I
would
say
that
it
will
and
send
it
in
the
offer
and
the
server
will.
If
he
does
it,
it
will
just
attach
all
the
tracks
and
if
not,
he
will
just
choose
one.
J
B
Sure
that
there
are
three
other
people
in
in
the
cube,
but
in
in
the
context
of
my
understanding,
is
there
any
reason
why
you
would
divert
from
8860
the
multiple
media
type
per
station
or
or
the
latest
rfc
that
touch
on
the
subject?
Any
reason
you
would
you
would
like
to
do
something
different
than
where
about
tc
is
doing.
J
I
know
the
question
of
like
what
to
put
in
the
stp.
If
you
want
to
do
this
sort
of
thing
is:
is
pretty
straightforward
but
like
if
you
look
at
what
the
whole
like
what
base
webrtc
says,
I
could
send
12
audio
streams
and
and
two
dozen
video
streams,
and
that
would
be
well
within
spec,
but
it's
probably
not
something.
I
D
So
I
think
the
constraints
on
this
and
the
rules
here
should
be
external
to
wish
like
if,
if
your
your
media
encoder
wants
to
send
like
3d,
video
and
multiphonic
stereo
and
and
he's
using
seven
webrtc
tracks
to
do
that,
that's
fine!
It's
not
wish's
problem
to
understand
that
it's
an
it's
a
private,
not
private,
but
it's
a
that's
a
statement
between
the
ingest
engine
and
the
the
the
encoder
that's
generating
this
this
traffic
and
wish
doesn't
have
anything
to
do
with
it.
K
B
F
Mike
yeah,
I
was
just
gonna
relay
a
comment
from
julius
and
I
missed
exactly
what
he
was
responding
to.
But
the
comment
was
you
stream,
video
plus
audio
plus,
slides,
plus
virtual
blackboard.
B
M
So
you
were
making
the
point
that
there
was
just
one
video
plus
audio
session
being
streamed.
I
think
that
the
requirement
of
streaming
your
face
plus
slide,
plus
a
virtual
but
blackboard,
is
fairly
common.
B
B
M
B
J
Okay,
so,
but
julius
raises
a
really
good
point
here,
which
is,
for
example,
if
we're
bringing
in
multiple
video
streams,
then
if
we
have
any
hope
of
basic
interoperability,
we
need
to
have
some
means
of
the
ingest
network,
knowing
which
one
is
which
right.
So
if
I
create
a
broadcast
client
that
is
doing,
you
know,
here's
my
here's,
my
headshot,
here's,
my
whiteboard
or
here's,
my
video
game
or
you
know
whatever
it
is
that
you're
choosing
to
put
as
your
second
stream.
J
Then
the
index
network
has
to
know
which
is
which
and
that
I
mean
that
that's
fundamental
interoperability,
that's
not
something
we
can
just
say.
You
know
it's
up
to
the
two
of
them,
because
then
it's
like
you're
you're
back
to
having
bespoke
clients
for
for
every
network,
so
that
you
can
like
signal
which
stream
means.
What
and
that's
kind
of
why
I
put
this
here.
If
we
want
to
have
that
ability,
then
we're
going
to
have
to
specify
it
leave
it
for
an
extension
or
miss
out
on
a
huge
chunk
of
interoperability.
H
J
Well,
so
I
mean
you've
reduced
it
to
a
previously
unsolved
problem
there
right.
We
still
need
some
way
for
the
tools
and
the
networks
to
understand
what
each
stream
is
under
those
circumstances,
and
I'm
okay,
tackling
that,
if
we
think
that's
a
requirement
alternately
if
we
have
a
sufficiently
extensible
like
session
based
setup
here,
we
can
add
this
as
a
future
extension
and
I
think
that's
probably
a
reasonable
approach
as
well.
L
Hi
I
just
wanted
to
pitch
as
well
a
possible
little
stream.
A
timed
metadata
like
the
idea
is
that
you
can
send
data
that
relates
to
the
stream,
but
it's
not
necessarily
audio
of
video
in
rtmp
world
today
we
do
it
with
id3
tags
and
whatnot,
but
it
may
also
be
a
case
to
just
have
this
dedicated
like
data
channel
stream
or
something
to
say
this
is
this.
Is
this?
Is
data
that
persists
to
the
these
time
stamps,
and
that
would
be
something
that
would
be
yeah.
G
Yep,
yes,
regarding
the
stream
ordinality,
I
think
that
the
both
cases
that
we
have
been
presented
so
far
that
it
is
the
multi-language
and
the
different
slides
and
things
like
that
can
be
implemented
with
this
some
saps
attribute
that
already
assists.
So
we
consider
that
the
we
want
to
support
it.
We
may
be
able
to
do
that
with
resisting
access
and
not
have
to
implement
anything
new.
J
So
I
I
just
think
that
that
we
need
to
make
this
well
like.
Let's
just
say,
we
added
some
tags
to
the
sdp
that
allowed
you
to
tag
an
audio
stream
with
a
language,
or
maybe
it's
already
there
or
a
video
stream
or
an
audio
stream
with
like
you
know.
This
is
slot
like
a
couple
common,
well-known
tags
like
slides,
whiteboards
presenter,
you
know
perhaps
a
few
others
I
mean,
I
think,
that's
that's
absolutely
mandatory
for
interoperability,
particularly
with
non-web
clients.
J
I
think
it's
one
of
the
things
we've
had
huge
mistakes
before
like
there's.
No
really
I
mean
there's
been
whole
working
groups
that
were
trying
to
figure
out
whether
which
screen
was
which
video
stream
was
the
right
and
which
one
was
the
left,
and
just
saying
this
is
up
to
the
application,
doesn't
make
any
sense,
because
you
want
to
stream
stuff
up
from
a
client
that
wasn't
necessarily
made
by
the
same
person
as
the
media
servers.
That's
the
whole
point
of
why
rtmp
is
successful.
I
think.
K
I
J
I
think
we
are
making
a
service
right.
The
fact
that
we've
constrained
this
to
be
a
broadcast
network
ingest
really
points
to
it
being
a
service
definition,
so
I
think
we
need
to
nail
it
down.
I
mostly
got
in
the
queue
to
basically
say
that
cullen
did
a
very
good
job
of
explaining
my
concerns
in
a
way
that
I
I
apparently
wasn't
as
good
at
so
just
a
huge
plus
one
to
what
he
said.
B
All
right,
we
have
a
few
minutes
left.
We
didn't.
We
didn't
speak
about
authentication
at
all.
This
is
a
matter
I
will
put
back
on
the
on
the
list
for
full
discussion.
If
there
are
people
that
want
to
discuss
it
on
the
list,
for
if
there
is
any
people
new
to
ietf,
most
of
the
final
decisions
are
taken
on
the
list,
even
if
we
make
any
vote
or
anything
during
the
meeting.
So
please
join
the
list
and
participate
into
into
the
discussion
moving
forward.
This
is
just
the
beginning.
B
B
D
E
A
A
Yeah,
the
important
part
is
that
we
got
any
decisions
that
got
made
and
again
I
think,
thanks
to
mike
who
did
the
jabber
scribe
somebody
at
the
jabber
scrub.
I
appreciate
that
and
we'll
see
y'all
on
the
list.