►
From YouTube: IETF113-AVTCORE-20220325-0900
Description
AVTCORE meeting session at IETF113
2022/03/25 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
All
right,
it
is
10
o'clock
in
vienna
top
of
the
hour
and
most
other
time
zones
or
on
the
half
hour,
if
you're
in
some
unusual
places,
india
or
newfoundland.
I
don't
know
if
you
have
anybody
from
there
and
so
welcome
to
abt
core,
not
a
you
know
that
that's
a
decent
number
of
participants,
let's
see
so
welcome
everybody.
A
A
Hopefully
nobody
has
any
issues,
but
if
you
do
here's
how
to
do
them
report
them
note.
Well,
hopefully,
everybody
here
has
seen
this
before,
but
especially
because
you
had
to
see
it
when
you
registered,
but
in
general
this
is
the
policies
and
procedures
of
the
ietf
for
ipr
and
consent
to
recording
and
code
of
conduct
in
particular.
Fortunately,
we
seem
to
don't
seem
to
have
problems
with
this
group,
but
just
a
reminder
to
treat
everybody
professionally
and
with
respect
and
dignity
in
general
behave
like
a
good
person.
A
About
this
meeting
agenda
notes,
stefan
has
volunteered
to
take
notes,
but
he
will
not
be
using
the
the
cody
md
because
he
prefers
microsoft
word.
But
if
anybody
wants
to
take
notes
and
code
emd
they
can.
If
anybody
wants
to
monitor
the
jabber
room.
That
would
be
appreciated
because
I
might
be
juggling
too
many
things,
but
if
not,
I
probably
can
help
that.
Also,
I
think
bernard
said
he
would
monitor
the
queue.
While
I
do.
The
slides
in
the
jabber
is
that
right,
bernard.
A
Right,
yeah,
by
the
way
you
do
have
a
bit
of
hum
bernard,
so
you
might
want
to-
or
maybe
that's
the
room.
I
don't
know
we'll
see
what
happens
over
this.
Okay,
here's
the
agenda
start
with
a
brief
discussion
of
crypto
cryptex
and
then
skip
the
7983
bis.
That's
the
demultiplexing,
some
stp
for
rtp
over
quick
and
gaming
goes
over
quick
and
then
I
think
colin
had
a
suggestion
for
an
agenda
bash
because
we
have
a
bit
of
time
colin,
go
ahead.
C
Yeah,
I'm
just
hoping
given
this
time
at
the
end
that
we
could
have
some
discussion
around
this
sure-
and
I
didn't
say
my
name
colin
jennings,
these
short
tags
on
that
we've
been
discussing
for
years,
and
I
think
I've
got
a
way
of
of
us
thinking
about
this.
That
might
help
really
help
us
get
to
a
decision.
I'm
not
proposing
we'd
get
to
a
decision
pay
or
anything
we'd
go
do
that
at
the
end.
A
A
And
vp9
is
still
in
misrep
because
of,
I
think,
an
indirect
reference
on
frame
marking,
which
is
why
we've
done
back
on
frame
marking
cryptex
is
an
itf
last
call.
But
we
have
a
few
comments
on
that.
Some
issues
that
came
up
during
last
call-
I
don't
know
if
they
were
because
of
last
call
or
just
because
that's
when
richard
happened
to
look
at
it,
but
I
think
we'll
have
a
little
bit
of
discussion
of
that
in
a
bit
and
we've
adopted
a
few
other
drafts.
B
Yeah
this
one
came
up
as
part
of
when
I'm
doing
the
write-up.
You
know
it
asks
if
about
the
ipr
declarations
and
whether
the
working
group
has
discussed
this,
I
did
post
a
an
email
to
the
list
and
basically
the
what
the
pub
wreck
requests
is
that
the
working
group
has
discussed
this
and
that
there
aren't
objections
to
proceeding.
B
B
D
A
A
E
B
B
I
guess
is
selectable
congestion,
control,
advisable
and,
second
of
all
measurements,
what
measurements
they
could
they
could
offer.
I
think
these
are
two
distinct
things.
They've
made
some
progress
on
the
measurement,
stuff
and
stats,
but
you
know
the
app
can't
do
its
own
congestion
control
that
has
to
be
has
to
be
below
it,
so
that
doesn't
necessarily
address
the
congestion
problem.
So
the
question
is:
what
what
can
this
working
group
tell
them
or
advise
them
to
do,
or
is
there
some
other
working
group
that
might
might
be
helpful
to
them?
B
Usually
the
best
way
in
the
itf
to
solicit
a
discussion
is
to
post
something
completely
insane
and
then
people
will
respond
to
try
to
come
make
something
better.
My
email
may
not
have
been
stupid
enough,
so
we
didn't
get
any
responses,
so
we
thought
we'd
try
to
get
some
people
to
the
mic
and
make
suggestions
about
what
what
we
might
do
in
response
to
this
liaison.
A
F
Mosinetti
we
had
an
entire
working
group
at
itf
on
this
rmcat
and
I
think,
as
lars
pointed
out
yesterday,
you
know
that
not
really
success
coming
out
of
that.
You
know
as
a
clear
consensus
on
what
techniques
or
what
standards
or
what
protocols
to
use
for
media
congestion
control.
I
don't
think
avt
core
is
going
to
be
able
to
come
up
with
anything
better
than
armchat
came
up
with
over
years
of
of
work.
I
think
the
clear
need
is
is
known.
F
We
we
know
that
traditional
congestion
controls,
like
you,
know,
tcp
based
ones
like
bbr,
and
you
know,
renoish
things
are
not
ideal
for
media.
I
think
everyone
knows
that
a
better
rate
control
a
better
congestion
control
for
for
media,
with
feedback
to
the
application
about
what
it's
doing
so
that
applications
can
make
intelligent
decisions
about
what
media
it's
selecting
and
how
it's
configuring.
Its
sources
is
definitely
needed,
but
I
don't
think
avt
core
will
be
able
to
to
do
anything
about
it.
F
I
I
think
the
practical
thing
to
do
for
people
that
care
about
this
is:
let's
try
to
iterate
very
fast
on
what
exists
so
take
bbr
v2,
see
what
tweaks
you
can
add
to
it
to
make
it
more
media
friendly,
take
gcc
and
see
what
tweaks
you
can
add
to
make
it
more
combination,
media
and
you
know
long
live
flow
friendly
and
see
if
by
implementation
we
can
iterate
into
something.
That's
usable,
because
I
don't
think
you
know,
standardization,
and
you
know,
working
groups
for
years
has
has
been
fruitful.
F
F
D
D
Yeah
so
as
as
a
co-chair
of
our
own
cater,
I
was
going
to
say
roughly
what
mood
just
said.
Obviously
we
have
the
rmk
working
group
and
it
did
develop
a
few
rfcs
in
this
space
and
there
are
a
couple
of
congestion
control,
algorithms
that
have
been
published
with
rfcs
and
some
which
have
been
discussed
and
not
published
as
rfcs,
and
as
far
as
I
am
aware,
they
all
work,
and
you
know
they
seem
to
work
reasonably
well
that
they
they
haven't,
got
uptake
for
various
reasons.
D
You
know
if,
if
you
can
supply
that
sort
of
information,
if
web
transport
can
supply
that
sort
of
information,
that
that
would
be
useful
and
probably
gives
the
the
sort
of
information
that's
needed
to
do
the
congestion
control
feedback,
and
I
I'd
also
remind
people
that
the
with
my
other
hats
on
the
irtf
has
the
congestion
control
research
group.
If
people
want
advice
on
algorithms.
C
C
I
mean
imagine
the
use
case
of
a
browser
that
implements
web
transports
and
some
days
the
application
that
javascript
wants
is
doing
media
over
the
web
transport
and
some
days
it's
doing
file
transfer
or
something
more
like
that.
I
think
that
we
need
to
start
specifying
ways
of
putting
the
hints
down.
I
know
there's
a
common
perception
that
we
don't
do
apis
at
itf,
but
I
don't
think
that's
really
true.
C
I
think
we
do
and
we
can
and
that
we
should
I'm
not
saying
we
define
how
what
the
api
exactly
looks
like,
but
we
just
sort
of
you
know
say
like
look.
We
need
an
api
that
allows
you
to
signal
the
type
of
following
information
up
and
down
this
stack
of
all
these
things
has
passed
us
through
and
that
we
start
working
on.
I
would
be
you
know
I
I've
been
playing
with
congestion,
control,
algorithms
for
media
based
on
vbr
v2
and
have
implementations.
C
I
mean
it'd
be
very
interesting
to
just
I
mean
we
need
to
get
some
progress
on
this
for
media.
Now.
All
of
that
said,
I
want
to
back
up
and
180
degrees
the
other
direction.
I
think
it's
also
probably
worth
reminding
these
people.
You
know
people
have
run
media
over
tcp
for
years
and
it
works
fine
right
at
some
level
of
file.
So
there
is
some
definite.
You
know
there's
some
scale
here.
This
is
going
to
work
better.
C
A
G
Yep,
I
I
think
I
agree
with
most
of
the
things
I've
said
by
both
colombo
and
colin.
So
only
thing
I
would
like
to
add
is
that
looking
at
itf
as
a
body
and
responding
to
w3c
and
also
given
that
there
is
definitely
a
need
for
something
like
this
from
multiple
site,
like
the
mock
mock,
for
example,
or
the
the
web
transporter
with
risky
guys
they
needing
something
like
this.
G
We
definitely
need
a
kind
of
northbound
apis.
That
needs
to
be
that
kind
of
exposes
what
and
app
interaction
feedback
kind
of
pointer
like
the
api
endpoint
api
that
was
exposed
into
the
application.
So
that
in
application,
if
not
can't
fix
the
condition
control
algorithm,
but
it
can
react
on
how
the
congestion
control
algorithm
is
doing,
which
is
not
exposed
into
the
web
transport
today.
B
The
quick
working
group
has
pointed
out
that
they
don't
handle
congestion
control
that
that's
done
at
other
places,
so
I
don't
think
bringing
quick
into
this.
They
basically
said:
hey,
we,
you
know
just
just
use
some
other
congestion
control,
so
congestion
control
group
would
probably
be
be
more
appropriate,
as,
as
was
pointed
out.
A
Yeah
as
an
individual,
I'm
wondering
it
might
be
worthwhile
to
you
know,
bring
up
to
the
rm
cat
group
using
arm
cut
algorithms
with
quick
or
something
just
as
a
discussion.
I
don't
know,
what's
going
to
be
the,
how
much
traction
that's
going
to
get,
but
just
you
know,
maybe
just
a
guidance
on
the
existing
arm
cut
algorithms,
how
you'd
use
them
with
quick
and
which
switch
quick
extensions.
You
need
might
be
useful.
B
E
H
A
A
A
J
K
Now
you
should
hit
me
yes
yeah,
so
we
have
failed
addressed
all
the
all
the
reviews
or
the
feedback
that
they
were
writing
the
in
the
in
the
review,
and
we
have
also
added
the
content
name
and
the
email
and
the
email
address
for
the
iana
registration
and
submitted
a
new
draft
facing
these
issues.
I
think
that
it
has
already
been
reviewed
and
agreed
that
all
the
feedback
has
been
already
addressed.
So
the
only
outstanding
issue
is
the
one
feedback
that
richard
provides
in
the
in
the
gi
repository
that
it
is
the
nexus
light.
H
On
on
this
sure,
yeah,
I
can
comment
on
this.
I
I
just
kind
of
randomly
came
along
and
reviewed.
This
didn't
see
the
last
call
announcements
or
anything.
What
I
noticed
is
there's
some
ambiguity
in
how
this
document
defines
encryption,
and
I
think
it's
a
little
bit
clearer
on
the
next
slides
jonathan.
If
you
could
go
forward
yeah,
so
so
cryptex
wants
to
do
this
kind
of.
I
call
it
punctured
encryption
where
you
don't
encrypt
the
header
of
the
extension
data,
the
rfc8285.
H
Is
you
know
if
you
think
about
encryption,
how
encryption
works
like
we've
got
these
two
encryption
frameworks
that
are
universally
used.
Aud
takes
unitary,
byte
strings
for
aad,
authenticated
data
and
plain
text
and,
of
course,
produces
ciphertext
right,
so
you
can't
do
puncturing
there.
You
need
to
produce
a
provide,
a
unitary
plain
text
for
a
contiguous
plain
text
and,
if
you're
going
to
use
a
screen,
the
other
interface
is
the
stream
cipher
plus
mat
construct,
and
in
that
case
you
can
skip
around.
H
So
we
kind
of
need
to
decide
like
how
we're
gonna
we,
the
the
spike
before
didn't,
specify
clearly
kind
of
what
the
input
was
to
the
ciphers
in
these
in
these
two
cases.
So
in
the
eid
case
we
need
the
continuous
plain
text
in
the
stream
cipher
case
we
need
to
know
like.
Are
we
skipping
over
some
of
the
key
stream?
Where
are
we
just?
You
know
applying
the
key
stream
to
different
spots,
so
the
the
we
kind
of
explored
two
options
in
this
pull
request
next
slide.
H
You
know
kind
of
universal
aed
everywhere.
The
main
main
drawback
is
that
it
requires
this
swapping
operation
if
you're
doing
things
in
place,
or
it
requires
a
complicated,
more
complicated
interface,
the
aead,
but
anyway.
This
is
this
is
the
kind
of
the
first
option
to
swap
things
to
make
the
the
inputs
contiguous
next
slide.
Please
yeah.
The
other
option
is
to
do
this
kind
of
in
place.
H
H
H
C
So
so
I
mean
first
of
all,
let
me
just
start
with
yeah
100
proposal.
One
was
alright,
let's
option
one,
let's
do
this,
but
this
was
discussed
immensely
before
we
even
adopted
this
document
went
on
and
on
forever,
and
we
came
to
this
conclusion
that
the
mem
copy
was
soup
was
not
an
expense
and
in
fact,
if
you
structured
the
way
in
your
library
that
you
stored
the
data
correctly,
you
didn't
even
need
to
do
it,
but
no
one's
going
to
really
do
that.
C
The
mem
cop
is
cheap
and
the
the
that
I
that
we
were
definitely
fine
with
being
just
aead,
and
I
thought
there
was
an
itf
document.
That
said
all
future
work
should
be
aead,
but
I
can't
find
it
now
that
I
said
that
I
I'm
sorry.
I
sent
an
email
to
the
list
last
night,
but
I
realized
I
didn't
send
it
to
you
richard.
So
my
apologies,
but
I
mean
I.
I
think
that
this
has
been
the
intention
from
all
along.
A
Yeah
yeah
jonathan
individual.
This
is
what
I
this
is
how
I
implemented
it
when
I
did
the
the
test
vectors.
So
I
think
it
was
what
we
were
always
intending,
and
I
guess
it's
basically
richard
found
us
that
we
didn't
explain
it
well
in
the
document,
so
this
is
basically
just
editorial
improvements,
which
is
great
cool.
A
G
A
A
L
L
This
is
just
a
slide.
We
keep
in
place
to
keep
track
of
background
where
we
come
from
and
that
we
have
deployed
devices
in
the
skip
in
the
us
and
nato
community
that
are
presently
using
the
protocol.
We
have
written
a
draft
rfc
for
the
problem
statement
is
more
along
the
line.
The
third
bullet
that
the
most
commercial
network
administration
security
personnel
are
not
aware
of
skip
and
can
result
in
the
skip
media
subtype
being
removed
from
an
sdp
which
is
disastrous
to
us.
L
We'll
move
on
to
the
last
bullet.
This
I'm
sorry
the
skip
rfc
was
accepted
as
abt
core
work
item
in
january
comments
received,
have
been
reviewed
and
incorporated
into
a
new
draft
of
this
rfc
next
slide,
and
this
is
what
we're
looking
at
two
media,
subtypes
audio
skip
and
video
skip
have
been
registered
with
ayana
as
a
rtp
media
format.
Media
types
the
rfc-
is
needed
to
provide
additional
information
for
those
media
subtypes
the
header
fields,
payload
format,
fields
as
well
as
serve
as
a
general
awareness
of
that
skip
is
out
there.
M
M
Excuse
me,
texas,
some
of
the
very
early
adopters
of
the
skip
in
our
version
of
internal
version.
If
you
will
of
the
spp
didn't
quite,
do
it
exactly
the
way
we
had
specified
it,
but
we
certainly
again,
we
control
this
skip
protocol
in
our
own,
see
a
working
group,
so
we
can
certainly
make
those
changes
ourselves
to
bring
those
others
up
to
date,
who
also
comment
regarding
whether
or
not
to
pre-packetize
skip.
M
We
also
updated
this
the
section
about
the
marker
bit
basically
saying
it's
going
to
be
always
going
to
be
zero
for
this
discontinuous
traffic
and
market
that
will
be
set
during
continuous
traffic
based
on
the
underlying
media
again
because
during
the
continuous
traffic
we're
basically
carrying
other
other
codecs
other
registered
codecs
like
milk
and
g729b
things
like
that
that
already
defined
how
to
use
the
marker
bit.
So
we
chose
to
allow
that
to
be
controlled
by
that
those
codex
themselves.
M
For
sections
five
one
and
five,
two
that
are
basically
I've,
repeated
the
iana
registration.
Again,
we
specified
n
a
because
there's
no
previous
versions
of
the
immediate
subtype.
So
that's
the
reason
why
we
chose
that
and
left
that
in
there
at
this
point
so
and
again.
Finally,
for
sections
eight
one
and
eight
two:
we
move
the
skip
to
14.2
and
skip
to
10
references
from
the
normative
section
to
the
informational
section
and
finally,
we
renamed
and
resubmitted
the
draft
with
a
new
name.
So
that's
where
we
are
with
that.
L
Sure
I'll
take
that
we're
here,
because
issues
have
occurred
between
oems
and
of
network
equipment,
network
administrators
security
personnel,
who
are
unaware
of
skip
and
the
ftp
contents
necessary
to
establish
our
secure
session.
So
the
skip
rfc
is
a
globally
accessible
information
as
to
how
to
handle
this
comments.
We've
received
from
the
abt
core
call
for
adoption
period
have
been
reviewed
since
then,
no
new
comments
have
been
received.
So
the
question
really
is
we'll
handle
questions
from
you
guys
and
then
we
need
to
know
what
our
next
step
is.
B
I
think
the
document
is
pretty
clear
about
what
needs
to
be
done
in
the
case
of
audio,
basically
don't
mess
with
with
the
payloads
and
and
hopefully
your
sbcs
will
accept
the
skip
audio
type.
I
have
a
lot
of
questions,
though,
relating
to
the
video
use.
Cases
like
is,
is
skip,
gonna
be
used
for
video
conferencing
kind
of
in
an
intend
encryption
scenario.
L
L
There's
once
that
setting
up
a
secure
trunk,
if
you
want
to
call
it
that
between
two
endpoints,
the
the
handling
of
the
the
actual
parameters
of
the
video,
as
well
as
the
audio
stream
too,
they
are
handled
by
by
the
negotiation.
That'll
occur
across
that
link
so
to
the
to
the
networking
world
and
those
those
type
that
type
of
information
is
handled
elsewhere.
Within
the
skip
standards
to
the
networking
world.
That's
going.
What
they're
going
to
see
is
the
sdp
and
they're
going
to
see
traffic?
L
There
will
be
marker
bit
it'll
be
framed
according
to
the
ietf
standards,
so,
for
instance,
if
it's
a
video
stream
we're
doing
a
secure
end
to
end
application
layer
conference
using
h.264
that
will
be
negotiated
within
the
framework
of
that
sdp
and
to
the
ex
to
anyone.
Looking
at
that
traffic
stream,
they
will
not
be
able
to
see
what
that
negotiation
looks
like.
B
L
Well
again,
to
some
degree,
that'll
be
left
to
the
vendor
how
they
choose
what
what
protocol
they
used
to
run
and
negotiate
within
a
secure
channel
into
the
network.
It's
it's
all
gonna,
it's
gonna,
look
like
encrypted
traffic,
so
the
we
believe
it'll
be
h.264.
We
believe
in
in
time,
they'll
be
perhaps
more
about
the
how
they
handle
the
conferencing
within
these
channels.
They
may
be
more
than
one,
but
at
least
for
for
now.
That's
the
approach
is
that
we
consider
it'll
be
h.264.
E
L
They
are
the
ones
that
will
be
in
the
normative
reference
that
you
can
request
and
remember
that
that
all
that
will
be
seen
in
the
network
will
be
just
bits.
It'll
be
the
the
encryption
stream
will
be
established
and
then
there'll
be
some
negotiation,
for
instance,
going
back
to
audio,
will
it
be
melp
or
will
it
be
729,
or
will
it
be
even
a
proprietary
solution
for
voice
or
for
video.
E
I
think
I
get
it
I'm
just
interested
how
this
is
supposed
to
work,
because
this
is
this
kind
of
an
unusual
way
how
rtp
is
employed
right.
It's
it's!
It's
a
little
bit
following
the
old.
Let's
throw
some
mp4
framer
frame
stuff
there
right
everything's
is
hidden
in
that
yeah.
This
actually
seems
to
be
doing
it
even
a
little
bit
more,
I'm
just
interested
how
this
can
work,
and
but
if
these
documents
can
be
made
available,
then
I'm
read
them
and.
M
M
So
it's
not
it's
not
an
rtp
layer.
Encryption
like
the
previous
slide
was
talking
about
it's
it's
the
actual
payload
itself,
with
mel
for
729,
for
example,
for
audio
or
even
for
the
h264
for
video,
it's
it's.
The
payload
is
once
again
isn't
prickly,
so
the
header
would
the
header
of
the
header
would
look
the
same
as
it
would
for
the
native
code.
So.
B
So
cullen
is
saying
something
in
the
chat
room
that
might
be
relevant
to
folks
he's
saying.
As
far
as
I
can
tell,
the
conferences
are
all
mcu,
transcode
style
conferences,
so
they're,
not
the
conferencing
is
apparently
not
being
done
using
a
selective
forwarding
unit
which
would
need
some
header
info
to
decide
what
to
drop.
C
Yeah
sure
I
mean
basically,
I
want
to
say,
like
let's
say
these
brought
us
a
completely
tran,
completely
black
box
thing.
That
says
we
want
to
move
some
data
over
it,
we're
not
going
to
tell
you
whether
it's
a
video
or
audio
codec
or
whether
it
you
know
transcodes,
holograms
it'd,
be
perfectly
fine
for
us
to
approve
this
document
with
no
clue
of.
What's
inside
that
black
box
we're
talking
here
about
just
moving
it,
I
I
don't.
I
don't
really
see
the
problem
with
this
document
like
this
has
been
done
for
a
long
time.
C
It's
widely
deployable,
there's
no
problem
with
it.
It
meets
the
use
cases.
People
have
for
it,
but
it's
the
part
that
we're
reviewing
of
it
is
is
really
just
the
the
registration
of
the
payload
type.
We
don't
really
care
what's
inside
there,
so
I
I
think
the
whole
thing's
fine,
regardless
of
what
it
does.
That
said,
I
mean
I
I
you
know
I
I
don't.
C
A
N
Ted
hardy
speaking,
so
I
think
what
I
was
putting
in
the
chat
is
is
more
procedural,
and
I
think
what
marie
and
I
were
talking
about
is
that,
just
like
you
have
a
down
ref
called
out
in
in
a
last
call
when,
when
this
does
go
to
last
call-
and
I
assume
the
next
step
here-
is
working
group
last
call
followed
by
itf
when
it
does
go
to
last.
Call
that
calling
out
that
the
the
the
documents
are
are
probably
not
going
to
be
available.
N
N
It's
it's
possible
that
requesting
them
does
work
for
some
set
of
circumstances
and
I
just
didn't
fit
in
them
or
possibly
I
I'm
just
in
there
spam
traps
for
whatever
other
reason,
but
I
think
we
should
just
treat
it
as
a
black
box
call
it
out
in
the
in
the
last
call
as
unavailable
and
leave
it
at
that.
Okay,.
H
Yeah,
it
knows
me
that
again,
so
I'm
a
bit
concerned
about
coming
about
specifications
not
being
available
given
that
diana
registration,
these
media
types
lists
the
specifications
as
published.
Now
we
can
quibble
that.
What
it
means
to
be
published,
I
think,
being
available
to
folks
on
the
internet
is,
is
generally
a
definition
people
use,
but
colin,
I
think
you
might
have
insights
here.
C
C
My
understanding
is
that
to
discuss
sending
a
media
type
over
rtp,
you
do
not
actually
need
a
normative
reference
to
the
codec,
okay
or
any
information
inside
of
it,
and
that's
very
important
for
our
ipr
declarations
in
some
ways
and
that
you
can
have
an
informational
reference
to
it.
I
don't
even
think
this
is
a
down
raft
and
last
call
as
long
as
it
was
informational
reference.
I
sent
the
suggestion
to
the
list
long
ago
that
perhaps
it
should
be
an
informational
reference.
I
don't
know
if
that
happened
or
not,
but.
H
H
E
N
Ted
hardy,
so
I
I
think
I
have
confused
the
matter
by
using
the
term
downref
and
I
apologize
I
I
did
not
mean
to
imply
that
this
was
exactly
the
same
as
a
downrav
I
do
think
spec
unavailability
is
a
con
is
something
that
we
need
to
call
out.
I
don't
think
it's
blocking,
as
as
cullen
pointed
out,
this
isn't
something
that
we
have
to
have,
but
if
the
specs
are
in
there
and
not
available
it's
it's
just
polite
to
the
community,
as
we
ask
them
to
review
it
to.
A
M
Right,
well,
it's
it's
not
that
it's!
The
specs
are
unavailable
they're
available
on
request,
if
you
will
again
they're
controlled
by
the
by
our
nato
skip
fortune
group.
So
in
most
cases
that
I'm
sure
they'd
be
fine.
If
you
reached
out
to
them
to
request
them,
they
should
be
able
to
provide
those
to
you.
N
Teddy
thank
you
for
clarifying
that,
but
when
I
tried
it
didn't
work,
so
perhaps
you
could
send
to
avt
core
exactly
how
to
construct
such
a
request,
because
when
I
sent
it
to
the
to
the
listed
email
address
requesting
the
name
of
the
document
and
explaining
I
wanted
to
review
in
the
context
of
this
document,
I
got
nothing
back
so
I
mean
not
even
an
thank
you,
but
no
nothing.
So
if
you
would
like.
E
N
A
Okay,
so
for
our
next
step,
do
we
it
sounds
like
you
know,
while
you
know
there's
some
issues
with
you
know
people
wanting
the
documents
to
review
them.
It
doesn't
sound
like
there
are
any
remaining
open
issues
as
far
as
I
know,
so
perhaps
this
is
ready
for
working
group
last
call
bernard.
Do
you
think
so.
O
B
B
So
it's
a
description
of
how
to
multiplex
srtp
srtcp
stun
turn
dtls,
crtp
and
quick
and
then
also
a
little
bit
of
guidance
on
handling
overlap
between
quick
and
turn
channels.
That's
something
that's
not
an
issue
in
webrtc
and
it
also
updates
the
dtls
content
type
field,
diana
page
to
reference,
a
new
rc
there's.
No
other
change
needed.
So
one
caveat
here
is
that
this
applies
to
quick
version
one.
It
is
not
guaranteed
to
work
in
future
versions
of
quick,
so
next
slide.
B
So
the
document
has
been
updated
in
version
o2.
So
some
some
of
the
changes
from
version
one.
I
did
add
some
text
about
the
multiplexing
scenarios
that
this
can
be
used
for
and
they're
really,
I
think,
two
main
ones.
One
is
where
we
use
quick
primarily
for
data
exchange
and
are
continuing
to
use
rtp
and
our
tcp
for
the
media,
with
dtls
srtp,
key
management
so
and
just
to
clarify
some
of
the
discussions.
B
We
have
this
scenario,
doesn't
require
any
replacement
or
changes
to
quick
congestion
control,
it's
just
using
it
as
as
data,
and
so
that's
where
you
need
the
maximum
multiplexing
and
the
second
scenario
would
be
the
rtp
over
quick
scenario,
and
that
is
where
you're
not
using
rtp
and
or
tcp.
So
you
don't
have
to
multiplex
that,
but
you
still
have
to
multiplex
what's
done
and
turn
so.
The
document
covers
both
of
these
scenarios,
but
the
second
one
has
less
stringent
requirements
than
than
the
first
one.
B
So
we
clarified
that.
The
second
thing
is
that
the
many
of
the
documents
that
this
depended
on
have
now
reached
our
c
status.
So
we've
had
an
update
to
stun
an
update
to
turn
quick
transport
is
now
in
rfc,
as
is
tls.
So
basically,
at
this
point,
all
normative
references
are
now
published
as
rfcs
there's.
No
reference
normative
references
to
drafts.
B
A
B
B
We
have
had
discussions,
which
is
that
in
quick
v2,
you
know,
as
it
says
here,
they're
not
required
to
be
compatible
with
this.
I
mean
that's
kind
of
something
that
quick
the
quick
working
group
has
has
said.
So
I
don't
know
that
if
you're
asking
whether
it's
specifically
broken
with
quick
v2,
I
think
we'd
have
to
do
an
analysis,
but
do
we
know
enough
about
quickv2
to
do
that
right
now,.
P
P
Yeah
but
okay,
I
would
suggest
just
looking
at
it
see
what
there
and
then
follow
up,
because
it
isn't
that
far
off,
I
think
from
actually
making
progress.
So
it's
in
quick
working
group,
it
is
quick.
V2
is
the
same
as
we
won,
except
it's
flipping,
some
some
of
the
bits,
etc.
So
it's
basically
creating
some
of
this
issue
here,
etcetera,
but
it's
it's
intended
to
have
something
to
for
quick
to
use,
to
negotiate
version,
negotiation,
etc
and
exercise
some
of
these
mechanisms
so.
N
Speaking
yeah,
it's
supposed
to
be
completely
compatible
with
v1.
The
the
whole
point
of
it
is
greasing
to
make
sure
that
metal
boxes
don't
start
seeking
for
specific
bit
patterns
that
are
only
going
to
be
part
of
b1.
So
it
should
be
very
fast.
I
mean,
I
think,
we're
we're
not
expecting
it
to
take
a
year
from
now.
So
I
think
the
point
lucas
made
in
the
in
the
chat
is
probably
the
right
one
that
this
should
take
into
account.
N
A
A
B
B
C
So
I
mean
you
know:
the
purpose
of
greasing
is
to
meet
certain
needs
and
you
can
go
read
the
whole
program,
edm
program
and
everything
else
on
it,
but
it
isn't
just
to
try
and
make
things
broken
in
the
internet
right.
So
I
don't
think
they're
going
to
do
some
piece
of
greasing
that
deliberately
just
breaks
things
that
are
happening,
so
I
think
we
could
discuss
with
them.
But
I
think
this
whole
point
just
raises
the
point
that
really
we're
going
the
wrong
direction.
C
I
think
we
ought
to
move
it
to
a
bcp
and
then
it
will
constrain
all
the
program,
calls
that
do
it
and
we
should
allocate
a
range
of
bits
for
each
protocol
and
and
say
that
that's
how
it
is
across
those
protocols
and
that
would
constrain
them
and
we
wouldn't
be
having
this
discussion.
So
that's
my
two
cents.
B
A
O
So
what
I
have
done
was
created
a
get
a
new
github
that
combined
all
the
issues
from
the
various
places
where
I
had
written
things
down,
and
so
I'm
going
to
hold
off
on
updating
my
individual
draft
for
now,
but
basically
collect
those
questions
as
github
issues
and
I've
already
seen
someone
attending
the
meeting
from
not
here
who
was
issu,
who
put
in
at
least
one
new
issue
about
2am
my
time.
So
people
are
starting
to
do
that
and
then
I'll
be
working
on
answers
and
updating
the
sdp
draft.
O
O
O
So
I
did
have
some
some
issues
that
I'd
like
feedback
on
either
here
or
on
the
mailing
list,
just
fine
and
these
three
here,
whether
double
encryption
matters
or
distinguishing
between
mappings
on
the
streams
on
the
datagrams
and
quick
connection
management
in
case
of
path.
Failure
next
slide,
please.
O
What
about
apps
that
are
using
the
secure
av
protocols,
av
av
profiles
now
and
so
that's
kind
of,
like
I
said,
that's
kind
of
where
that
discussion
is
headed,
but
rather
than
going
back
and
forth
every
time
I
talk,
you
know
it's
like
changing
the
draft
every
time.
I
talk
to
somebody
that,
if
I'm
seeing,
if
I'm
seeing
discussions
that
are,
have
not
converged
yet,
I
think
it's.
I
think
it's
fair
to
ask
the
working
group.
What
the
right
thing
to
do
is.
Q
D
P
D
Once
you
start
looking
at
the
rest
of
rtp,
you
know
the
the
the
transport
doesn't
fit.
Well,
the
congestion
control
doesn't
fit
well,
the
whole
rtcp
framework
doesn't
fit
well,
srtp
doesn't
fit
well.
The
sequence
numbers
the
sslcs,
there's
not
a
whole
lot
left
of
rtp
other
than
the
payload
formats.
That
makes
sense.
D
So
I
wonder
if
maybe
that,
rather
than
trying
to
fit
rtp
over
quick,
we
should
maybe
be
saying
look.
This
doesn't
make
sense,
but
here
are
the
bits
that
do
make
sense,
and
maybe
you
need
to
define
a
different
protocol
that
reuses
payload
formats,
for
example
over
quick
and
then
it's
trivial
to
gateway.
B
Yeah,
I
would
point
out
that,
as
as
we're
hearing,
it
is
possible
to
experiment
with
a
lot
of
this
stuff,
because
we
have
some-
you
know
basic
code
and
apis
out
there
to
actually
build
these
systems
and,
in
particular
on
the
web.
It's
a
little
bit
constrained
because
we
have
web
codecs
which
allows
you
to
get
the
to
encode
and
decode
frames
and
then
basically
send
them
over
either
web
transport
or
rtc
data
channel.
B
So
you
can
actually
build
build
some
of
this
stuff
and
it
is
actually
being
done
in
commercial
applications.
I
would
actually
note
that
that
that
this
stuff
is
actually
quite
real,
at
least
at
the
moment,
it's
mostly
being
done
with
containerized
media,
but
people
want
to
get
away
from
that
because
it's
basically,
if
you
don't
need
content
protection,
it's
just
a
bunch
of
overhead,
so
people
want
a
way
of
of
transporting
these
frames
and
what
I've
seen
so
far
is
that
they
have
been
using
something
pretty
close
to
rt
rtp.
B
P
So
magnus
westland
yeah,
I
mean
on
the
higher
level
saying
here.
I
think
the
only
reason
for
having
double
encryption
is,
if
you
have
a
middle
box
that
are
forwarding
it
without
changing
anything.
So
if
you
have
ekt
for
example,
and
try
to
do
not
touched
really
at
all
the
the
key
just
forwarding
the
packets,
that's,
I
think,
is
the
only
one
which
would
be
and
that
I
think
in
that
case
you
should
negotiate
savpf.
P
Q
O
C
So
partially,
I
really
resonate
with
call,
and
I
I
think
this
is
a
this-
is
a
a
a
very
challenging
path.
That's
not
clear
the
value
of
the
end
goal
of,
but
I
think
we
sailed
past
that
bridge.
We
agreed
to
do
this
long
ago.
So
at
this
point
I
want
to
help
you
figure
out
how
to
get
it
done.
Not
just
tell
you,
you
shouldn't,
do
it
and
thank
you,
I'm
sending
you
big
hugs
for
having
to
put
this
on.
It's
not
easy,
but
that's
that
back
up.
C
I
think
your
easiest
path
here
is,
though
it
sounds
silly
to
do
double
encryption
and
actually,
if
you
were
doing
it
over
an
http
turn
connection
that
did
you
know,
https
would
be
triple
encryption.
I
think
you
should
just
do
that.
That's
what
it
signaled!
It's
the
easiest
to
understand.
It's
going
to
be
by
far
the
easiest
to
do
and
there's
multiple
cases
where
you
actually
might
want
this.
There's
lots
of
people
who
there's
more.
C
Sort
of
type
environments
who
like
the
idea
of
double
encryption,
because
if
one
of
them
is
compromised,
hopefully
the
other
one
might
be
different
like
you
might
use
rsa
and
one
in
ec
in
the
outer
or
whatever
there
are
times
where
you
can
improve
your
security.
By
doing
it
twice,
there's
also,
some
cisco
makes
some
products
where
we
do
what
we
call
throwaway
encryption,
where
the
outer
layer
is
tls
encrypted.
But
we
know
that
the
middle
box
is
the
man
in
the
middle
of
that
tls.
C
So
we
encrypt
the
stuff
inside
that
again
again
in
a
way
they
can't
decrypt.
So
I
like
look
it's
it's
not
unimaginable
that
there
are
use
cases
for
double
encryption.
It's
it's
semantically.
What
everything
means
and
you're
gonna
have
a
very
hard
time
redefining
everything
to
semantically
mean
not
double
encryption
in
this
case
over
quick,
so
I
wouldn't
do
it.
I
just
like
if
people
signal
that
they
get
double
encryption,
that's
what
they
asked
for
have
a
nice
day.
O
C
O
E
F
Mal,
those
and
eddie
one
final
point
on
the
srtp,
the
savpf
thing,
regardless
of
the
protocol
and
the
need
implementation
wise.
It
actually
may
be
easier
to
always
go
with
a
library,
that's
tightly
bound
with
rtp
and
srtp,
because
almost
everybody
is
going
to
have
that
already.
It
may
be
actually
more
work
to
unbind
them
and
figure
out
how
to
how
to
wedge
in
your
own
extraction
of
just
the
rtp
layer
and
put
srtp
much
later
somewhere
else.
F
R
Oh
thank
you
spencer,
for
working
on
this.
I
see
a
huge
amount
of
value
in
our
maybe
even
making
in
a
more
generic
way
or
the
payload
formats.
That
doesn't
mean
we
need
to
go
through
and
retroactively
handle
all
the
payload
formats
that
have
ever
existed,
but
definitely
a
way
to
decouple
rtp
payload
formats
from
rtp
itself,
so
that
it
could
be
used
in
other
transport.
Protocols
in
the
future
would
be
very
interesting,
and,
I
think,
would
add
an
awful
lot
of
value
to
this
work
and,
like
elsewhere,.
O
Cool
thank
thank
you.
I
think
I'm
hearing
a
suggestion,
not
necessarily
just
from
james
from
these
questions,
about
whether
you
know
whether
we're
talking
about
a
document
like
the
one
that
stefan
described,
which
basically
profiles
and
says,
if
you're
doing
this
over
quick
here's
what
you
you
know,
here's
what
you
should
do,
here's
what
you
should
get
from
someplace
else
and
things
like
that,
because
you
know
I've
got
other
issues
about.
O
O
Yeah
is
this
a
you're
telling
me
I
should
have
done
two
slides
okay
yeah,
but
I'm
going
to
hold,
like
I
say,
as
I
said
previously,
collecting
answers
and
collecting
questions
from
at
various
places
and
then
working
on
answers
to
the
questions
and
updating
the
sdp
draft.
It
sounds
like
either
what
I
or
other
people
or
I
and
other
people
would
be
doing-
would
be
starting
to
think
about
the
pro
the
rtp
profile
for
rtp
over
quick.
E
E
That
thing
that
thing
describes
what's
on
the
wire
right,
it
should
probably
add
a
little
bit
a
few
section.
The
following
parts
of
the
of
rfc
3550
are
irrelevant,
don't
read
them
ignore
them.
If
your
library
has
them
comment
them
out
and
then
comes
the
long
list
and
then
we're
already
done,
I
think
maybe
that's
I
don't
know
what
what
is
going
on
with
that
draft.
A
S
E
O
M
O
E
O
A
I
don't
so
just
that
george
just
comments
in
the
chat
that
his
draft
is
active
and
when
you
said
that
he's
just
only
doing
datagrams
and
not
streams,
he
said
not
yet
smiley.
So
so
it
sounds
like
york
is
continuing
to
work
on
his
drafts.
So
that's
good
excellent,
excellent,
going
forward
we'll
have
more.
O
C
Okay,
wow,
I
didn't
realize
we're
out
when
already
okay,
so
what
I'm
going
to
talk
a
little
bit
about
here
is
taking
and
I'm
getting
quite
a
bit
of
feedback
from
the
room.
I
don't
know
if
there's
a
way
to
reduce
the
mic
gain
or
something,
but
I'm
going
to
be
talking
about
the
idea
of
taking
some
data
around
game
moves
in
game
state
and
putting
them
into
rtp.
So
next
slide.
Please.
A
A
C
I'll
keep
talking
yeah,
it's
way
better.
Thank
you.
So
sorry,
no
no
worries
at
all.
Okay,
so
goals
here
is
more
and
more
we're
getting
large
systems
where
people
are
doing
these
multiplayer
games
or
applications
like
metaverse
type
things
here.
Some
of
these
other
systems,
where
you're
trying
to
take
the
state
of
game
objects
or
the
state
of
user
interface
things
and
circulate
them
over
over
various
things.
Obviously
low
latency
is
critical.
C
So
a
classical
piece
of
data
that
you
want
to
use
from
this
is,
you
might
think:
well,
there's
nothing
in
common
between
these
different
apps,
but
it
turns
out.
There
is
an
incredible
amount
of
comment.
There's
an
incredible
number
of
things
where
all
you
want
to
do
is
give
the
location
a
particular
time
and
velocity
for
net
code
type
usages
of
a
given
object.
C
So
you
know
that's
a
common
thing,
for
example,
and
so
what
we're
proposing
here
is
like
one
of
the
the
objects
that
you
can
send
inside
these
rtp
packets
is
the
the
the
geometry
of
your
hand,
bones
and
the
rate
of
change
of
them,
so
you
can
send
them
to
the
far
side.
The
far
side
can
chill
the
hand
can
show,
can
interpolate
the
hand
forward
in
in
motion
in
time
a
little
bit.
So
you
don't
have
to
send
these
instantly.
So
you
have
some
delay
and
some
of
the
other
side
next
slide.
C
C
C
It's
very
much
designed
to
allow
people
to
make
it
easily
extensible
to
build
their
own
objects
and
register
them
and
use
them
for
whatever
use
cases
they
have,
and
it's
also
it's
really
hard
to
keep
your
training
plot.
When
you're
hearing
yourself
talk
with
the
echo
of
my
apologies,
you
know
it's
it's
pretty
much
a
cut
yeah.
I
saw
that
thanks.
C
So
that's
the
general
form
of
the
solution.
Next
slide,
the
current
draft
look,
it
needs
a.
I
mean.
I
wrote
this
draft
to
give
you
enough
of
a
flavor
to
understand
what
it
is.
You
could
probably
implement
it
from
this.
There's
lots
of
the
normal
stuff
that
you
need.
As
you
know,
the
framework
templates
for
fully
specifying
you
know
for
all
the
diana
registry
stuff,
that's
all
missing,
but
you
know
how
we
do
that.
Okay,
I
mean
the
gist
of
what
this
structure
would
really
be.
C
Is
is
largely
in
there
there's
an
open
source
implementation.
People
can
go
play
with
they
want.
We
have
some
people
using
this.
It's
you
know
it's.
It's
still
very
early
stage,
that's
where,
where
it
is
today
and
my
last
slide,
so
what
I
you
know,
I
would
like
to
move
this
forward
somewhere
and
I
need
to
move
it
forward
relatively
quickly.
This
isn't
a
five-year
plan.
C
I
mean
there's
a
lot
of
people
trying
to
work
on
how
they
can
standardize
various
things
and
make
things
interoperable
between
various
versions
of
somebody
might
be
on
metaverse
or
games,
or
all
these
things.
If
this
is
the
right
place
to
do
it,
it's
great,
I
don't
think
it
slows
down
in
any
way
any
other
ongoing
work
going
on
this
working
group,
or
anything
like
this
is
probably
largely
a
slightly
different
set
of
people.
They're
interested.
C
Does
take
some
expertise
in
the
review
of
how
this
fits
on
top
of
rtp
and
all
of
those
types
of
things,
so
I
don't
want
to
be.
You
know
here
a
year
from
now
still
asking
whether
this
is
the
right
place
to
do
it.
I'd
rather
just
get
a
you
know
if
you
think
this
is,
if
you
really
wish
this
would
go
away
and
never
come
back.
Please
tell
me
if
we
want
to
do
it.
Please
tell
me
I
don't
even
care.
I
just
want
to
have
a
concrete
way
to
move
forward.
C
C
Yeah
yeah
I've
been
watching
that
a
little
bit
it.
It
seems
somewhat
related,
but
I
may
not
know
enough
about
it.
Maybe
some
of
that
interface
with
this
I
think
some
of
that
is
quite
different,
and
it's
really
focused
on
the
input
of
controllers
more
than
the
state
of
objects
in
a
game
where
there
might
be
multiple
different
ones,
with
all
different,
with
a
completely
different
list
of
factors
in
it.
But.
E
Is
that
while
the
idf
had
isolated
examples
where
it
did
good
work
on
what
I
would
call
a
codec,
it
also
had
examples
where
they
didn't
do
good
work
there,
and
this
looks
at
least
in
part
a
little
bit
like
a
codec
or
representation,
there's
also
stuff
going
on
over
in
what
these
graphics
guys.
What
what
are
they
called,
but
it
will
come
back
in
in
in
a
second,
you
know
where
intel
and
nvidia
and
those
guys
hang
out
and
play
so
so
there
is.
S
E
C
A
G
I
I
I'm
coming
from
an
implementation
experience
on
this
one
and
trying
to
see
why
something
like
the
rtp
would
make
sense
and
trying
to
provide
an
explanation
if
it
does
not
make
sense.
I'm
happy
with
that,
but
one
thing
what
I've
seen
we've
seen
is
that
most
of
these
game
moves
are
need
to
get.
They
tie
very
closely
in
terms
of
synchronization
with
the
audio
and
video
that's
happening
as
part
of
the
game
or
as
part
of
the
like.
G
You
know,
then,
the
omnibus
kind
of
multiverse
kind
of
things
and
and
rtp
kind
of
provides
that
time.
Synchronization
point
across
multiple
streams.
That's
happening
naturally,
and
having
this
all
along
the
plane
along
the
same
lines
of
audio
and
video
as
another
data
stream
would
naturally
fit
in
there
and
that
that
might
be
one
reason
I
why
I
would
think
it's
in
the
scope
of
50
core,
but
I
think
it's
a
for
the
group
to
decide,
but
that
would
be
my
consideration.
My
view
on
this
one.
A
K
Hi
hello,
so
I
definitely
think
that
having
this
kind
of
podcast
specifies
is
a
good
thing.
I
mean
I'm
completely
okay
with
trying
to
move
this
forward,
but
I'm
not
sure
if,
if
this
should
be
something
that
is
carried
over
rtp
or
if
we
could
do
it
in
in
data
channels,
because,
for
example,
if
you
are
then
integrated
into
webrtc,
it
will
require
us
to
expose
a
lot
of
apis
for
all
the
different
protocols
in
in
the
in
the
browser's
api.
In
order
to
use
it.
K
So
I'm
not
sure
if
you
have
a
thought
of
define
it,
something
that
it
is
data
data
channel
based,
for
example,
similar
to
what
the
t140
has
done
to
specify
the
t140
over
data
channels,
because,
for
example,
this
is
something
that
I
have
been
also
considering
to
do.
A
for
sending
live
customize
with
the
web
bt
over
data
channels.
K
Obviously
there
is
the
issue
about
how
to
synchronize
the
and
the
data
channels
and
the
rtp
and
the
rtp
data,
but
I
think
that
if
we
could-
or
some
of
this
is
information
is-
is
a
we
need
to
to-
it-
has
to
be
in
real
time
and
not
or
for
example,
game
moves.
They
don't
have
to
be
synchronized
with
the
video
because
they
have
to
be
processed
and
consume
as
as
soon
as
they
are
received.
They
don't
really
require
much
synchronization
with
the
with
the
video
and
and
but
obviously
it's
just
thinking
about
the.
K
C
I
mean
I,
I
had
thought
a
little
bit
about
the
issue
of
how
this
maps
into
browsers
and
I
actually
hadn't
been
like
okay.
Well,
this
will
probably
gateway
over
data
channels
or
whatever.
However,
we
do
rtp
over
web
transports.
Type
thing
was
was
my
thinking,
but
the
problem,
the
problem
with
just
directly
using
data
channels,
is
that
most
of
large
distribution
systems
that
scale
out
these
whole
networks
that
give
you
the
whole
latency
like
a
low
latency
worldwide,
they're
they're,
not
the
most
of
them,
are
not
using
webrtc
around
it.
C
C
That'd,
be
true
of
you
know:
webex
zoom,
microsoft
teams.
You
know
list
goes
on
and
I
realize
there's
ones
that
aren't
like
that,
but
so
that
wasn't
a
really
very
good
deployability
option,
just
because
the
build
out
of
the
rtp
architecture,
I
wanted
to
be
able
to
leverage
that
I
couldn't
leverage
that,
if
I
put
it
over
data
channels,
though
I
definitely
was
concerned
about
like
well,
how
does
what?
C
What
does
this
mean
for
a
client
running
on
a
browser,
though
many
of
the
you
know
mini
browser
input,
many
things
that
run
on
a
browser,
the
implement.
You
know
an
implementation
of
a
game
that
runs
on
a
browser
that
you
can
join
from
a
browser
and
you
can
join
another
way,
probably
have
gatewaying
of
different
protocols
in
the
back
anyway.
So
I
imagine
that
probably
wouldn't
be
that
big
a
deal,
but
that
sort
of
you
know
my
thought
was
a
combination
between
that
and
and
web
transport.
A
All
right,
donald
trump's,
I
guess
mostly
as
an
individual,
I
feel
like
this
group.
We
have
the
expertise
to
do
things
like
okay.
This
is
how
you
get
it
there.
You
know
you
know
reliably
and
synchronized
with
audio
and
video,
and
you
know
all
that
good
stuff.
I
don't
feel
like.
We
have
a
lot
of
expertise
in
knowing
these
are
the
correct.
A
This
is
the
correct
description
of
the
object
state
and
the
game
moves
and
all
that,
and
so
my
inclination
would
be
to
say
I
mean
if
there's
another
venue
that
can
say
this
is
the
information
we
want
to
send,
and
then
this
group
would
say
this
is
how
you
send
it
sort
of
very
much
in
the
classic
codec
versus
payload
format.
Split.
A
A
We
could
provide
a
forum,
but
I
don't
really
feel
like
this
is
our
classic
expertise.
So
if
there
were
somewhere
else
that
could
give
that
you
know
the
could
define
the
kodak,
if
you
will,
that
would
probably
that
would
make
me
more
comfortable.
But
if
that
doesn't
exist,
we
probably
could
provide
a
forum
if
we
had
to.
C
So
so,
john,
I'm
going
to
reply
to
this
a
little
bit.
I
at
some
level
100
agree
with
you
right,
but
just
to
follow
how
it's
what
it's
like
to
bring
new
work
to
the
itf
of
course
right.
I
request
a
time
in
the
dispatch
working
group
to
talk
about
that
issue
and
see
if,
where
we
should
dispatch
this
kodak
work
and
they're
like
no
we're
not
even
going
to
give
you
agenda
time.
C
This
is
in
the
scope
of
abt
core
and
it's
like
okay,
that
doesn't
quite
make
sense,
but
okay,
but
the
reality
is
there's
nowhere
at
ietf.
That
is,
does
have
that
and
we
have
as
good
a
lock
bringing
it
to
a
group
that
happens
to
have
an
email
list
called
avt.
As
any
other
email
list
like
like
you
know,
what
we're
going
to
be
able
to
do
to
bring
that
in
or
out,
doesn't
doesn't
change
in
any
way.
C
C
E
A
Yeah
I
mean,
I
think
yeah
I
mean
so
bro
rowan's
comment
is,
if
you
can
get
the
domain
experts
here,
who
know
this
stuff
and
they
can
do
good
review,
then
I
guess
we
can
do
it,
but
I
want
to
make
sure
that
I
I
don't
I
I
don't.
I
personally
would
not
have
the
expertise
to
know
whether
what
we're
doing
whether
the
descriptions
of
game
moves
is
correct
or
not
so.
F
No
mo
mozinati-
I
I
agree
with
with
stefan
and
jonathan
that
there
definitely
needs
to
be
a
split
between
the
elementary
stream
and
that
should
hopefully
be
defined
first
and
then
the
rtv
payload
format
for
it.
But
I
think
that
this
that
the
hope
I
think
was
that
this
was
simple
enough
and
generic
enough
that
it
it
didn't,
need
an
entire
working
group
or
other
sdo
for
the
codec
piece
that
we're
not
trying
to
define
a
very
you
know
bit
tight.
Codec
of
you
know
large
volume
data.
F
You
know
if
there
was,
if
we're
trying
to
describe
entire,
you
know
entire
worlds.
Absolutely
this
should
go
to
some
other.
You
know
sdo,
that's
you
know
creating.
You
know
world
point
cloud
compression
and
things
like
that,
but
I
think
the
hope
here
is
that
this
is
something
simple:
that's
you
know
conveying
low
low
rate
data.
F
I
think
that's
the
hope
here
and
if,
if
people
are
on
board
with
doing
something
simple
like
that,
I
think
it'd
be
a
relatively
quick
effort
and
if
somebody
wants
something
much
more
complex,
they
they're
welcome
to
go
to
you
know
mpeg
or
ao,
media
or
somewhere
else
who
have
active
bodies
working
on
things
like
this,
like
game,
world
descriptions,
3d
world
descriptions,
and
things
like
that.
I
don't
think
that's
what
this
draft
is
asking
for
anything
that
complex.
A
B
B
B
E
E
You
know
I'm
I'm
not
objecting,
but
quick
and
dirty
projects
have
a
tendency
to
to
mushroom
out
of
first
in
the
itf.
Nothing
is
quick.
That's
that's
number
one
right.
You
know
I
I
remember
when
we
when
webrtc
was
booted
yeah,
let's
do
that
in
a
year
we
have
it
right
and
10
years
later
we
had
it.
Finally,
it's
the
itf
is
the
wrong
organization
to
do
something.
E
That's
really
not
that
well
prepared
to
deal
with
it
right,
and
so,
unless
you
have
an
a
a
group
of
companies,
a
group
of
organization,
a
core
group
who
who
goes
hell-bent
in
exactly
one
direction
without
leaving
everyone
else
behind,
like
the
opus
guys
did
right
when
you
have
that,
and
you
can't
keep
it
focused,
maybe,
but
as
a
single
company
thing,
I
wouldn't
I
wouldn't
suggest
to
do
this
here.
I
really
wouldn't-
and
you
know,
if
you
do
it-
have
a
buff-
have
a
working
group
just
just
just
do
it
it.
D
D
C
Yeah,
I
know
I'm
I'm
with
you
on
that
and
look.
I
will
try
and
bring
that
together,
but
like
realize
that
a
large
portion
of
the
use
cases
from
this,
what
they
need
to
send
is
a
single
location
and
the
rate
of
change
of
the
location
and
the
object
id.
That
is.
That
is
like
the
90
use
case.
So
I
mean
we
can
understand
that
pretty
easily,
but
I
mean,
like
I
get
everybody's
point
on
bringing
in
the
experts.
The
problem
is,
is
unless
you
start
something.
This
is
one
of
those
ones
where
like.
C
G
G
I
would
suggest
that
the
draft
should
basically
say
what
this
does
not
do
to
kind
of
not
have
the
kind
of
the
ball,
the
entire
ocean
kind
of
thing
and
be
very
specific
on
what's
doing
and
have
at
least
a
way
to
come
and
present.
You
know
what
this
actually
stored
or
what's
been
actually
being
sent
that
way,
it
might
be
much
easier
for
people
to
just
think.
You
know,
instance,
think
of
the
game,
moves
and
everything
about
the
game.
G
A
P
Magnus
piston
yeah,
sorry
colin
about
I
mean
I
think
my
comment
was.
I
just
comment
on
the
dispatch
list
about
its
suitability
for
rtp
and
then
I
should
have
said
that,
yes,
the
format
question
is
probably
should
have
been
dispatched
but
yeah.
It
still
remains
this
question:
what's
the
most
appropriate
when
you're
here
etc-
and
I
think
anything
here
will
it's
going
to
require
some
reshortering
somewhere
anyway.
C
P
P
O
C
So
I
mean
I,
you
know
it's
it's
one
of
these
things
like
it's
really
easy
to
just
say
I
mean
it's,
it's
really
hard
to
figure
out
how
how
you
bring
new
work
forward.
I
guess
one
thing
that
I
will
say
about
this
is
the
odds
of
this.
You
know.
Failure
is
an
option
here.
The
odds
of
this
causing
any
harm
to
the
internet
is
absolutely
zero
right.
This
is
not
you
know
this
isn't
going
to
break
our
architecture.
This,
isn't
you
know
it's
not
the
spin
bit.
C
C
Care
in
the
slightest
what
the
status
level
is,
you
know,
is
there
a
way
to
move
it
forward,
and
I
mean
yeah.
We
could
have
had
this
discussion
in
dispatch,
but
it
would
have
been
the
same
people
at
the
mic
saying
the
same
thing
and
yeah.
We
all
wish
we
could
get
a
whole
bunch
of
the
experts
in
here
to
do
it,
but
I
guess
the
question
is:
how
are
we
going
to
get
to
that?
And
you
know
if
the
answer
is:
go
form
a
bunch
of
group
of
companies
together.
A
K
K
I'm
not
going
to
I'm
not
not
sure
if
it
is
in
the
just
defining
the
protocol
itself
is
within
this
charter
or
not.
But
it
is
something
that
it
would
be
interesting
for
me
for
the
protocols,
because
it
seems
that
there
is
no
real,
a
very
good
place
to
do
it
everywhere
else.
So
and-
and
I
think
that
it
would
be
good
if
we
could
define
the
two
things-
also
a
protocol
that
we
could
use
not
only
in
rtp
but
in
other
transports.
D
I'm
struggling
to
see
why
this
is
controversial.
You
know
it
it's
if
we're
going
to
do
that
over
rtp.
It's
my
tp
payload
format,
which
is
what
this
group
does.
We
need
the
people
with
the
domain
expertise,
but
yeah
that
is
the
same
for
every
other
codec
or
every
other
payload
form
that
we've
done
in
the
history
of
this
group
over
the
last
20
25
years.
D
A
A
B
A
G
F
A
C
B
A
C
I'll
I'll
I'll
send
the
stuff
on
short
stacked
to
the
list,
and
maybe
we
can
have
another
call
on
that.
At
some
point
I
I
mean
actually.
Maybe
would
I
guess
the
only
question
here.
Would
there
be
a
group
of
people
interested
in
having
you
know
a
little,
not
even
an
intern
meeting,
but
a
phone
call
sometime
on
short
tags
going
forward.
A
A
And
yeah,
so
I
mean
obviously
we
need
to
do
something
other
than
just
you
know
something
that
isn't
broken
by
magnus's
draft,
but
presumably
there's
other
cryptography.
We
could
do
so
colin
sent
the
link
to
that
in
the
chat,
probably
which
I'll
send
it
to
the
mailing
list.
Just
so
it's
okay,
so
I
guess.