►
From YouTube: IETF113-WISH-20220321-1200
Description
WISH meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
Good
morning,
according
to
my
time,
clock
it's
time
to
start,
but
I
think
we're
going
to
give
people
a
couple
of
minutes.
A
B
Hi
sean
they
were
giving
them
out
at
the
registration
and
I
have
a
whole
bunch
of
very
boring
white
ones,
but
it's
very
hard
not
to
fall
to
the
allure
of
bright
and
shiny
colors.
C
C
A
So
welcome
to
wish,
please
make
sure
your
video
is
turned
off
unless
you're
speaking
as
well,
your
microphone,
a
bunch
of
links
for
the
media
co
how
to
get
in
the
audio
panel
java
and
the
minutes,
which
is
also
the
note-taking
mechanism
as
well.
A
I
believe
there
was
a
qr
code
that
comes
at
the
beginning
when
you
came
in
the
room
which
you
need
to
scan
to
make
sure
that
you
get
added
to
the
blue
sheets.
It
saves
everybody
from
having
to
worry
about
cleaning
pens.
A
This
is
only
the
second
session
of
the
ietf
meeting
that
you
may
have
been
at
know
well
remind
you
of
the
various
policies
that
you
agree
to
adhere
yourself
to,
because
you're
participating
lots
of
things
in
here
lots
of
ipr
policy
how
to
work
in
the
group,
any
harassment
code
of
content,
copyright,
patents,
etc.
If
you
have
any
questions,
we
can
answer
them.
Other
people
in
the
room
can
answer
them.
If
you
see
or
feel
that
anything's
being
done,
that's
out
of
line
with
those
please
contact
the
obods
team.
A
And
this
is
kind
of
one
that
we
wanted
to
highlight,
which
out
of
contact
is
basically
try
to
treat
everybody
with
respect,
try
to
speak
as
slowly
as
possible,
trying
to
limit
the
use
of
slang.
I
feel
like
they
put
that
in
just
for
me
dispute
ideas
by
using
a
reasonable
argument,
use
your
best
engineering
judgment
find
the
best
solution
for
the
whole,
the
internet,
and
I
contribute
to
the
ongoing
work.
A
And
our
agenda
is
pretty
light
tonight,
so
we're
gonna
go
through
the
venus
trivia.
We
have
one
draft
and
we
have
some
implementation
experience
that
got
bumped
from
the
last
time
and
then
we'll
have
some
open
time.
I
don't
know
if
we're
gonna
need
30
minutes
to
talk
about
the
draft,
because
there's
only
one
open,
pull
request
and
two
issues,
and
so
we
may
be
able
to
close
that
out
and
actually
go
for
working
group.
A
Last
call
with
this
with
this
one
draft
and
that's
really
it
so,
I
wonder,
is
sergio
available.
F
D
D
E
A
A
F
E
E
E
Yeah,
this
is
it
finally
about
that
folks,
okay,
so
this
is
the
list
of
changing
between
the
the
previous
version
of
the
withdraft
and
the
on
the
latest
one.
E
There
is
one
minor
change
related
to
the
to
the
linear
relation
type
of
that
we
have
in
the
draft
that
will
probably
has
the
urn
of
the
urine
itf
pattern
sweep
and
we
have
renamed
it
yesterday.
Server
and
the
main
difference
between
the
two
drafts
is
the
the
the
last
open
point
that
we
have
for
the
draft.
That
was
how
to
handle
a
patch
request
that
could
be
out
of
order
before
between
a
patch
required.
E
That
was
doing
a
I'm,
sending
new
istrical
candidates
from
the
one
that
was
doing
a
restart
and
what
happened
when
they
were
received
out
of
order
and
how
to
to
solve
that.
The
problem
was
presented
last
in
the
last
ietf
meeting
and
it
was
agreed
that
we
were
going
to
go.
E
This
entity
tax
is
an
opec,
opaque
value,
so
meaning
that
the
if
the
the
whipping
the
the
clients
has
not
have
to
take
any
kind
of
or
try
to
get
any
semantic
semantical
value
of
it.
E
It's
an
opaque
value
and
it
is
up
to
the
server
how
to
how
to
choose
the
value
and
how
it
is
generated,
and
it
could
be
just
an
auto
grant
counter
and
uuid
or,
for
example,
the
I
user
name
and
it
is
updo
to
the
to
the
server
how
to
to
implement
it
and
how
to
use
it
and
the
entity
value
entity.
Tag
value
must
be
returned
both
in
the
in
the
201
created
response
to
the
original
post
request
or
in
any
200.
Okay
response
to
a
patch
request
that
it
is
triggering
I
restart.
E
So
this
means
that
every
time
the
there
is
a
new
ice
session
because
it
is
either
the
initial
one
or
the
or
because
a
new
ice
restart
is
triggered,
the
entity
value
has
to
be
changed
and
report
it
back
to
the
client.
E
Two
a
precondition
fail
as
in
the
as
specified
by
the
in
the
itachi
rpc,
and
then
the
pass
requests
for
isostar
must
contain
an
if
matched
value
of
an
aesthetic,
as
there
is
meaning
that
it
in
regard
that
the
ice
restart
must
happen,
regardless
of
which
is
the
the
value
of
the
entity
tax.
That
means,
because
you
want
to
trigger
the
restart
always
and
also
I
this
is
the
one
thing
that
we
should
check.
E
I
think
that
that
it
is
valid
according
to
the
http
specs
is
that
we
should
only
need
to
send
or
should
only
the
the
the
with
clients
should
only
send
the
ifmatch
header
for
the
pass
request
and
not
for
the
other
requests
that
are
not
changing.
The
the
I
session,
for
example,
in
the
http
delete,
and
also
as
a
consequence
of
the
that
the
patch
request
for
sending
ice
candidates
must
contain
the
the
entity
attack
of
the
of
the
investors.
Then
the
client
must
buffer
all.
E
So
this
is
something
that
it
was
already
requested,
or
it
was
already
required
to
be
done
before
and
on
the
original,
and
when
I
started
the
session
and
now
we
are
also
having
to
do
it
when
there
is
another
start
on
going.
A
So
we
have
two
people
in
the
queue
I
don't
know.
Do
you
guys
want
to
do
your
points
now
or
do
you
want
to
wait
till
the
end.
H
You
hear
me:
okay,
cool,
so
could
you
please
clarify
and
I'd
like
to
see
it
clarified
in
the
draft
how
the
server
determines
whether
an
sdp
fragment
is
a
restart
or
a
or
a
candidate?
E
It
this
has
not
changed
that.
How
is
that?
And
it
is
a
specified
in
the
rfc
for
the
ice
fragment,
and
you
have
to
check
the
username
and
password
to
see
if
they
have
changed
between
the
one
that
you
have
and
the
one
that
it
is
say
for
the
the
the
one
that
you
have
for
the
client
or
not.
So
this
is
this
is,
according
to
I
don't
recall
the
the
number
of
their
facebook.
E
E
H
I
Yeah,
jonathan
lennox,
I
think
the
other
probably
another
point
you
want
to
say
is
you
can't
start
a
nice
restart
while
an
existing
ice
restart
is
pending?
Basically,
you
can't
have
more
than
one
ice
restart
in
flight
at
a
time.
I
That's
probably
a
requirement
you
want,
otherwise
things
get
confusing
as
to
which
one
actually
is
the
current
one.
I've
seen
this
like
nobody
would
probably
do
this
on
purpose,
but
I've
seen
this
like
when
a
device's
network
is
flapping
and
it
just
thinks.
Oh,
I
have
to
do
another
ice
restart
right
away,
so
you
probably
want
to
say
you
know,
wait
till
the
previous
ice.
You
get
a
response
to
the
previous
i3
start
before
you
start
another
one.
I
I
Well,
I
think
I'm
not
sure
what
the
requirement
should
be,
but
we
should
have
a
description
how
to
handle
this,
because,
if
you're
not
sure
which
requests
actually
reach
the
server
first,
you
could
be
uncertain
which
one
you're
actually
supposed
to
which
one
you
should
actually
switch
to.
So
might
you
might
need
some
logic
there.
I
K
G
E
G
A
H
E
H
Sure,
but
I'm
saying
that
I
feel
that
this
should
be
stated
normatively.
H
So
if
you
look
at
the
places
where
consent
is
mentioned
in
the
document,
the
only
there
is
the
normative
la
there
is
normative
language
only
in
two
places
and
it
feels
incorrect
and
it
feels
incomplete
sorry.
H
Okay,
so
I
feel
that's
a
that's
an
editorial
issue,
not
a
fundamental
issue.
So
what
I
would
like,
I
might
not
be-
I
might
be
the
minority
here.
So
I
feel
that
you
should
be
stating
that
non-native
language
clearly
in
this
document,
even
though
it
repeats
other
documents.
But
that's
just
my
opinion.
E
I
don't
have
a
strong
opinion
on
that.
I
mean,
I
would
just
say,
would
like
to
get
input
out.
What
is
the
best
way
of
doing
the
the
editorial
of
that?
I
mean
I'm
fine
with
both
waves,
no
seriously,
which
is
the
the
correct
one
of
doing
that,
but
I
will
be
fine
to
to
change
it
to
whatever
is
the
most
appropriate
one.
So.
H
E
L
Thanks
so
I
wanted
to
comment
on
what
harold
was
saying.
The
I
think
we
really
want
to
be
careful
here
is
that
we
don't
try
to
define
the
e-tag
semantics
here
as
much
as
pointing
to
the
behavior
described
in
7232,
and
from
that
perspective,
I'm
I'm
not
sure
the
answer
is
correct,
that
it
doesn't
change
when
candidates
arrive,
I
think
when
you're
patching
a
resource,
it's
changing
the
resource
value,
and
so
the
e-tag
is
necessarily
going
to
change.
But
again,
I
think
that's.
E
L
Sure
yeah
I'll
do
that.
I
was
more
responding
to
the
the
discussion
in
the
room
here.
I'm
I'm
not
exactly
sure
what
the
text
says
at
the
moment,
but
I'll
look
at
it
and
and
open
a
pr
if
there
needs
to
be
a
change
thanks.
E
Yeah,
I
think
that
this
is
the
the
the
trade-off
is
how
verbose
verbose
would
have
to
do
in
the
in
the
document.
So
it
is
splitted
about
what
needs
to
be
done
in
by
a
whip
implementation.
Instead
of
having
to
look
at
too
many
different
drafts,
or
at
least
to
have
a
more
clear
idea
of
what
to
what
needs
to
be
done.
But
obviously
we
need
to
be
precise
on
the
language
so.
A
Sergio
from
experience
here,
I
think
the
isd
has
waffled
over
the
years,
whether
they
want
lower
case
language
if
you're
repeating
requirements
from
other
drafts,
as
long
as
I
think
as
long
as
you're
consistent
to
make
sure
that
we
know
where
the
requirement
came
from
whether
it's
new
or
imported
another
document,
that's
fine.
The
only
problem
with
repeating
the
requirement
is
that
it's
changed
in
the
base
document
and
not
in
the
other
document
and
there's
this
mismatch
problem,
but
I
think
long
as
you're,
clearly
as
defined
in
rfc
empty
squad
in
section
block
comma.
F
E
E
No,
but
it
was
a
one
night
from
the
very
beginning,
and
I
don't
think
that
it
is
relevant
anymore
and
the
other
one
was
about
the.
If
we
should
specify
the
more
about
the
http
error
response
code,
I
think
that
we
are
already
doing
that
for
the
most
of
the
requests
that
have
a
semantic,
or
that
means
we
need
to
to
to
provide
responses
in
case
of
something
that
happened
and
for
general
errors
like
not
phone
or
things
like
that
or
international
better.
E
A
So
sergio
what
I'd
like
to
see
is
to
have
you
clear
up
the
issues
if
they're
old,
like
close
them
out
and
the
other
pull
request,
is
just
kind
of
like
lingering
there.
If
you
can
close
those
out
and
then
anybody
else
can
get
their
stuff
in
as
quickly
as
possible,
and
then
we
can
go
to
a
working
group
class
call.
E
F
H
So
I'm
I'm
so
sorry
sergio.
I'm!
I'm
really
sorry,
but
I
disagree
with
you
on
the
error
handling
issue
and
the
reason,
I'm
sorry
is
that
it's
horrible,
defining
precisely
all
the
error
values
is
horribly
tedious
work
and
I
feel-
and
I
feel
that
that's
not
something
that
you
should
leave
to
the
implementer.
H
So
if
I'm
implementing
the
server
side,
of
which
I
don't
want
to
have
to
go
through
all
of
the
http
rxcs
in
order
to
find
out,
which
is
the
right
error
value
to
send
at
a
given
point,
when
I
have
a
failure
and
when
implementing
your
draft
I
have
had,
I
have
had
the
problem
so
I've
I
wanted
to
get
it
done.
So
I
have
to
say
that
I
was
more
or
less
sending
errors
randomly
and
that's
something.
H
I
felt
the
need
for
guidance
telling
me
that
if
you
have
this
kind
of
failure,
send
this
error
here.
So
some
of
them
are
obvious.
If
I
have
an
implementation
failure,
if
I
have
an
unexpected
error,
I
send
internal
server
error.
That's
fine,
but
in
cases
where
the
client
is
sending
something
that
mismatches
and
so
on,
whether
to
send
which
of
the
400
errors
or
500
errors
to
send.
E
Because
it's
horrible!
No,
no!
No!
No!
No,
but
I
mean
what
I
can
do.
This
is
the
typical
lot
please
feel
free
to
to
submit
a
pr
solve
with
that,
but
I'm
not
going
to,
but
I
mean
yes
for
example,
how
exhaustive
can
we
how
we
do
we
need
to
go
into
this
because,
for
example,
do
we
need
to
specify
what
happens
if
someone
sent
us
an
invalid
sdp
when,
when
in
the
patch
request,
I
think
that
we
shouldn't?
E
I
mean
this
is
already
a
standard
http
and
we
don't
need
to
reference
the
the
what
code
needs
to
be
be
returning,
for
example,
instead
of
an
sdp
and
we
get
a
or
something
there
are
a
lot
of
things
that
they
we
shouldn't
er.
We
should
not
be
specifying
because
it
is
just
how
http
works.
I
mean
you
have
errors,
responses
that
are
defined
for
the
the
for
the
common
cases.
I
think
that
we
have
to
define
responses,
for
example,
for
when
the
semantic
issues,
for
example.
H
H
Okay,
it's
tricky
because
you
can
batch
the
candidates?
Okay,
so
you
answered
something
which
I
agree
with
ignore
the
candidate
and
return
success,
but
I
feel
that
it
should
be
in
the
draft.
E
Yeah
no
no,
and
I
have
I
have
added
that
in
the
graph
okay.
But
but
if
you
check
this
is
not
about
whatever
code
to
return,
it
is
what
is
the
behavior
of
the
server
yeah
so
that
so
that's
these
cases.
I
completely
agree
that
we
have
to
to
add
anything
that
we
can
find
in
the
server
in
the
in
the
in
the
draft,
for
example,
because
this
is
not
just
specified
which
is
there
were
code
to
return.
H
H
E
E
A
But
I
think
one
way
that
we
start
to
ferret
out.
A
lot
of
these
is
actually
by
doing
the
working
group
last
call.
A
So
I'd
really
like
to
get
there
in
the
next
couple
of
weeks
where
we
can
fire
this
off
so
I'll,
be
watching
the
repo
and
sergio
I'll
be
talking
with
you
to
make
sure
that
we
make
sure
everything
is
dutifully
knocked
off
as
much
as
possible,
and
then
we
do
the
work
last
call
and
see
where
we
go,
and
then
we
can
start
talking
about
all
the
other
issues
of
sending
mana
tag
and
language
support,
subtitles,
etc.
E
So
I
think
that
my
general
question
is,
if,
once
we
have
the
whip
draft,
publish
or
ready
for
publishing,
if
we
have
to,
we
should
be
working
on
on
adding
new
functionalities
to
whip.
For
example,
the
ones
that
comes
immediately
in
mind
to
me
is
how,
for
example,
sending
metadata.
Alongside
with
the
with
the
with
the
audio
video,
there
are
a
lot
of
specs
already
available
that
are
used
in
the
traditional
streaming,
that
we
could
support
and,
for
example,
multi-language
support.
E
E
A
Sergio
I
too
have
the
same
question,
but
I
guess
we'll
need
to
figure
out
how
to
do
that,
because
I
know
that
we
initially
tightly
scoped
this
working
groups
charter,
so
we
may
have
to
cuddle
with
our
80s
to
figure
out
what
they
want
to
do,
whether
it's
you
know
this
goes
away
and
they
all
get
dispatched
or
they
all
go
to
avt
core.
J
A
A
J
J
You
can
just
hover
over
my
name
in
the
in
the
participants
list
and
there
should
be
an
icon
that
says
pass
control
to.
Let's.
A
J
Okay,
I'll
I'll
be
brief,
so
I
will.
I
won't
bother,
bore
you
too
much
with
all
these.
I
just
wanted
to
share
some
implementation
experience
with
both
the
web
client
and
server
that
we
implemented
as
an
open
source,
an
open
source
tool
and,
in
particular,
using
two
completely
different
webrtc
stacks,
which
was
also
helpful
in
terms
of
integration
interoperability
as
well.
J
So
I
won't
go
too
much
into
the
detail
of
the
on
the
implementation
itself,
so
you
can
find
more
information
in
that
blog
post.
If
you
are
interested-
and
I
also
made
a
presentation
at
a
conference
in
chicago
a
few
months
ago-
where
I
also
went
a
bit
more
in
detail
about
all
the
different
aspects
but
I'll
share
some
some
details
about
both
the
server
and
client-side
implementation.
J
J
So,
rather
than
embedding
the
web
api
inside
genos
itself,
which
is
what
julius
did
in
galin,
for
instance,
if
I
record
correctly,
we
chose
a
a
simpler
and
more
loosely
integrated
approach,
which
was
basically
of
placing
a
tiny
wrapper
in
front
of
janus
itself,
which
means
that
we
have
a
small
server
implementation
that
sits
in
front
of
janus
that
implements
the
web
api.
And
then
it
translates
all
the
interactions
on
the
website
to
interactions
on
the
janos
side.
J
So
it
translates
the
apis
on
the
fly
and,
of
course,
nothing
needs
to
be
changed
on
the
webrtc
stack,
because
that
doesn't
change.
So
it's
a
very
thin
layer
on
the
signaling
on
a
signaling
level
and
we
implemented
it
very
quickly
using
node.js.
So
it's
basically
a
very
basic
express
based
rest
api
for
what
implements
the
the
web
api
and
then
the
janus
inter
integration
is,
is
done,
programmatically
as
well,
and
of
course
it
only
takes
care
of
the
ingest
part.
J
So
we
make
sure
that
the
video
gets
to
janus
and
then
what
happens
after
that
is
out
of
scope
of
the
web
server
itself.
So
if
you
need
to
distribute
it
somehow
that's
up
to
you
and,
as
I
mentioned,
this
is
completely
open
source.
So
if
you
want
to
give
that
a
try,
you
just
need
to
to
clone
that
repo
and
everything
should
should
be
working
and
just
to
give
you
an
idea
about
how
it
works.
So,
as
I
mentioned,
it's
very
simply
an
application
layer
in
front
of
janus
for
what
concern
the
signaling.
J
So
you
have
a
web
client
talking
talking
the
whip
language
with
this
simple
web
server.
The
web
server
translates
it
to
janus
requests,
which
means
that
eventually,
you
end
up
with
the
webrtc
peer
connection
between
the
web
client
and
the
janus
server
that
is
being
controlled
by
this
simple
web
server
and
as
far
as
the
this
translation
is
concerned,
it's
actually
quite
trivial,
which
means
that
the
same
process
could
be
done
with
other
media
servers
as
well.
J
In
this
case,
for
instance,
this
is
the
http
post
that
originates
the
the
publishing
process,
which
means
that,
as
soon
as
we
receive
a
new
offer,
we
need
to
pass
this
to
janus
somehow
and
since
we
are
using
the
sfu
plugin
with
that,
it
means
that
we
need
to
create
a
connection
with
janus,
create
the
resource
that
we
need
to
talk
to
jarvis.
For
that,
and
then
we
join
an
existing
sfu
room
as
if
we
were
an
actual
participant.
J
Also
when
you
group
candidates,
so
no
problems
there.
Of
course,
what
happens
when
you
start
exchanging
trickle
candidates
is
that
the
actualized
and
dtls
exchanges
are
going
to
happen
between
the
producer
and
janus
itself,
so
the
web
server
is
not
involved
in
the
process.
After
that
for
ice
restarts,
the
process
was
a
bit
more
complicated
just
because
on
the
website
we
just
use,
we
just
exchanged
the
credentials,
not
the
whole
sdp,
while
janus
expects
the
whole
sdp
to
update
a
session
to
trigger
a
restart,
which
means
that
the
the
web
server
needs
to
to
keep.
J
J
We
receive
a
complete
sdp
back
and
then
we
extract
the
new
credentials
from
this
answer
and
only
send
those
via
via
whip
instead,
so
a
bit
more
work,
but
it's
not
really
that
complicated
tearing
down
a
session
is
also
quite
easy
because
we
just
need
to
basically
tear
down
the
resource
on
the
genocide
whenever
we
receive
a
delete.
J
Of
course,
the
counterpart
may
also
be
happening,
so
we
may
be
detecting
a
peer
connection
going
down
because
of
iso
or
dtls,
and
in
that
case
janus
can
intercept
it
and
notify
that
via
the
janus
api
to
the
web
server
that
is
controlling
it.
And
when
that
happens,
the
web
server
can
then
clean
up
the
resources
automatically,
so
that,
if
appear
connection
was
closed
because
there
was
a
dtls
alert
but
no
signaling
involved.
For
instance,
we
can
still
take
care
of
cleaning
everything
up
accordingly
and
of
course
I
mean
web
server.
J
Unfortunately,
obs
webrtc
does
exist,
but
does
not
support
whip
at
the
moment
it
did
support
whip
in
a
very
early
stage
last
year,
but
right
now
it
only
supports
the
custom
millicase
protocol,
so
I
basically
chose
to
use
g-streamer
for
the
purpose
because
it
does
come
with
a
webrtc
stack
in
webrtc
bin
and
I
actually
had
already
used
this
stack
for
a
few
other
applications
in
the
past.
J
So
I
was
partly
familiar
with
it
and
I
wanted
to
play
with
that
and,
most
importantly,
it
is
very
modular
and
very
powerful
which,
as
I
explained
later,
basically
allowed
me
to
do
some
more
prototyping
and
doing
some
interesting
things
with
all
these
right
away,
and
all
this
is
also
open
source
if
you
want
to
to
play
with
it
a
bit.
So
I
encourage
you
to
do
that
and
as
far
as
the
futures,
there
are
some
limitations.
J
So
it's
pretty
much
complete
in
terms
of
adherence
to
this
to
the
to
the
spec,
but
there
are
some
limitations,
so
we
do
support
trigger
settings
standard
either
in
advance
or
via
the
link
header
as
specified
in
the
document.
We
support
authorization
via
tokens,
delete
and
so
on
and
so
forth.
We
can
also
do
non-triggle
if
you
want
to,
even
though
the
speak
does
mandate
support
for
trickle
and
we
have
a
way
to
force
turn
in
case.
J
The
problem
is
that
at
the
moment,
webrtc
bin
has
some
limitations,
so,
for
instance,
it
does
not
support
ice
restarts
yet,
which
means
that
I
could
not
test
that
part
so
far,
and
there
is
a
pull
request
to
add
support
for
that,
but
it
still
is
still
stuck
for
a
while
and
besides.
J
This
only
supports
linux,
because
that's
what
I
use
on
my
own
laptop,
but
in
theory
it
should
be
easy
enough
to
port
it
to
windows
and
macos
as
well.
I
just
don't
have
much
experience
in
development
on
those
environments,
so
since
this
is
open
source,
if
you
have
a
bit
of
experience
in
updating
the
make
files
to
get
it
working
there
as
well
I'd
be.
This
would
be
very
welcome
and,
to
conclude
I
mean
this
is
how
you
can
basically
start
with
client
session,
so,
for
instance,
in
this
case,
that
address
is
actually
real.
J
So
it's
an
address
that
I
set
up
for
the
academy
last
itf
and
it's
still
active
if
you
want
to
play
with
it
a
bit.
So
if
you
send,
if
you
create
a
web
session,
a
ted
address
with
that
token,
then
you
can
just
choose
what
you
want
to
send
as
audio
and
video
streams,
and
then
that
should
just
work
and
you
can
test
it
using
this
web
page
over
here.
So
since,
basically,
the
the
whip,
the
web
server
talks
to
john's
to
create
a
fake
participant
in
a
room.
J
Basically,
all
you
need
to
make
sure
that
it
is
actually
working
is
joining
the
same
room
somehow,
so
that
link
allows
you
to
join
as
a
passive
participant.
If
you
see
something
everything
is
working,
and
in
this
case
we
are
capturing
a
fake
audio
source
and
a
fake
video
series,
but
this
could
be
an
actual
webcam.
This
could
be
streaming
from
a
file
or
something
else.
So
everything
that
gstreamer
supports.
J
J
So
I
wanted
to
check
if
I
could
actually
already
used
web
obs
as
a
way
to
produce
a
stream
and
then
send
it
to
voip
rtc.
Somehow
and
I
prototype
a
prototype
the
way
using
an
intermediate
technology
that
is
called
ndi,
which
is
basically
a
standard
defacto
in
the
broadcaster
industry.
Basically,
I
had
obs,
I
produced
something
in
obs
configured,
an
ndi
output
in
obs
and
since
gstreamer
has
a
plugin
to
use
ndi
as
a
source.
J
This
very
silly
demo
over
here
where
I
was
capturing
myself
playing
guitar.
I
did
a
lot
of
gifs
like
this
was
a
90s
website
and
then
basically
started.
I
produced
this
stream
live
and
then
vi
and
d.
I
passed
it
to
the
web
client.
The
web
client
sent
it
to
janus,
and
I
had
in
a
demo,
there
were
about
20
people
watching
the
webrtc
concert
in
real
time.
J
F
Otherwise,
thank
you
renzo
always
helpful
to
get
feedback
from
actual
implementations,
and
with
that
I
think,
thank
you
for
attending
wish
sounds
like
we're
good
track
to
make
it
to
working
group
last
call
pretty
soon
and
sean
and
me
will
take
the
item
to
figure
out
what
to
do
with
extensions
regarding
metadata
and
subtitles
and
that
kind
of
stuff.
F
Oh
yes,
sorry
about
that.
My
chrome
had
like
asked
before
permissions
to
do
the
screen
recording
again,
which
would
have
required
like
to
restore
chrome.