►
From YouTube: IETF114 AVTCORE 20220728 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
I
I
have
I
have
a
note
from
Sean
Turner
the
notes
that
I
did
for
him
yesterday
in
which
were
maybe
the
worst
I
think
I've
ever
done.
A
All
right
so
apparently,
yes,.
A
A
D
E
A
A
As
the
as
he
quickly
mutes,
let's
see
who
do.
G
C
A
I'm
gonna
start
randomly
clicking
on
people
in
the
participants
list
and
telling
them
asking
if
they
can
take
notes.
Okay,
Magnus
Magnus
says
he
will
take
notes,
thank
you,
Magnus
and
but
if
other
people
want
to
also
join
the
the
Cody
MD
or
whatever
we're
calling
it
now,
what
hedge
dog.
A
You
think
he's
captured
everything
that
would
also
be
great
at
which
point
I
think,
since
it
is
now
134,
we
can
get
started.
Welcome
to
the
avt
work
core
working
group,
either
here
in
Philadelphia
or
wherever
in
the
world.
You
might
happen
to
be
am
I.
Oh,
that's
right!
We're
not
surviving
the
slides.
A
Okay,
if
you're
here
in
person,
please
sign
into
the
Medico,
usually
the
medical
Lite,
if
you're
here
in
person
that
both
lets
you
join
the
queue
and
make
sure
you're
recorded
on
the
blue
sheets
and
lets
you
participate.
If
we
do
any
polls,
all
of
which
are
good
things
if
you're
here
in
person
and
you
choose
to
join
the
full
version,
keep
your
audio
and
video
off,
because
you
can
already
see
us
the
old-fashioned
way
and
please
everybody's
doing
that.
Go
well
now,
but
please
keep
if
you're
here
in
the
room.
A
A
Remote
meeting
tips
you
enter
the
queue
with
the
no
hand,
leave
with
hand,
because
who
knows
why
you'll
need
to
enable
your
audio
when
it's
your
turn
to
talk.
Similarly,
the
unveiling
icons.
You
can
also
enable
video
if
you
want,
but
that's
separate
from
audio.
If
you
just
enable
your
video,
we
will
see
you
without
hear
you,
which
for
most
purposes
is
not
terribly
useful.
A
Videos
encouraged,
but
not
not
required.
Next.
A
Here
are
some
links,
you
can't
click
on
them
in
here,
but
you
can
go
to
the.
If
you
go
to
the
data
tracker,
you
can
find
various
information,
you
can,
you
can
find
the
the
slides
and
they
should
be
clickable
in
there
I
think
next,
no
well.
A
Hopefully,
everybody
has
seen
this
by
now
since
it's
Thursday,
but
if
not
you
are
agreeing
to,
but
first
of
any
ietf
you're
agreeing
to
follow
the
IDF
procedures,
notably
you'll
have
to
declare.
If
you
have
IPR
that's
an
open
simplification.
Please
read
the
things
for
more
details.
A
You
can
you
acknowledge
that
we
can
have
audio
and
video
recordings
of
you
and
you
agree
to
follow
the
code
of
conduct
next,
especially
please
everybody
keep
things
professional
and
you
know
avoid
harassing
anybody
or
the
like,
and
if
you
see
anybody
harassing
contact,
the
ombuds
team
or
the
chairs
next.
A
And
as
I
mentioned
Mass
policy,
we
seem
to
be
good
now,
but
please,
if,
when
you're
in
the
meeting
rooms,
please
wear
a
certified
mask
unless
you're
actively
speaking
at
the
front
of
the
room.
Next.
A
A
I
Hey,
can
you
hear
me?
Yes,
we
can
okay,
great
thanks
for
the
opportunity
to
say
a
few
words
about
Steve
casner,
a
long
time
friend
and
colleague,
and
mentor
to
many
of
us
within
the
ITF
Community.
These
remarks
are
a
slightly
longer
version
of
the
tribute
prepared
for
the
plenary
yesterday
and
they
include
a
few
additional
photos
and
links
to
a
few
online
readings,
writings
and
viewings.
I
For
those
of
you
who
may
not
have
had
the
pleasure
of
knowing
Steve
directly.
His
vision
and
Leadership
were
instrumental
to
the
success
of
ietf
multimedia
standards
and
protocols
that
have
driven
the
success
of
ip-based
telephony
and
multimedia
conferencing,
as
well
as
other
real-time
multicast
and
unicast
applications.
He
began
that
Journey
at
Occidental
College.
He
graduated
in
1973
with
a
degree
in
mathematics,
and
then
he
obtained
a
master's
in
computer
science
from
the
University
of
Southern
California
in
1976.,
beginning
in
1974.
I
He
joined
USC's
information,
Sciences
Institute
as
a
graduate
student
and
remained
there
for
22
years.
He
contributed
to
the
software
design
and
implementation
of
some
of
the
earliest
experiments
with
packet
voice
on
the
arpanet,
and
thus
he
contributed
to
the
publication
of
the
network
voice
protocol
RFC
741,
published
in
1977
a
year
before
the
TCP
IP
split
and
a
year
before,
UDP
was
defined
as
high
bandwidth
packet,
satellite
and
terrestrial
networks
became
operational
in
the
1980s.
He
led
the
multimedia
conferencing
project
at
isi
to
develop
and
deploy
packet
video
over
those
Networks.
I
He
built
a
custom
packet-oriented
video,
Codec
and
later
developed
techniques
that
allowed
commercial
video
codecs
designed
for
circuits
to
operate
over
packet
switch
networks.
It
was
at
isi
in
1988
hate
to
confess
that
that
I
first
met
Steve
I
date,
myself
and
but
I
had
the
privilege
to
work
closely
with
him
over
six
and
a
half
years.
I
It
is
also
where
I
was
indoctrinated
through
him
into
the
iitf
community
culture
and
working
group
process
that
same
year
in
1988
Steve
is
documented
in
the
proceedings
of
the
ietf
11
as
having
participated
in
his
first
ITF
meeting
in
Annapolis
Maryland
and,
as
many
of
you
may
recall,
his
lovely
wife
of
over
40
years.
Karen
Kastner
often
attended
ietf
meetings
with
him
at
that
time.
I
Steve
attended
to
contribute
to
the
working
group
focused
on
the
experimental
internet
stream
protocol
version,
2
that
provided
the
technical
underpinnings
of
the
earliest
isi
BBN
Pack
video
teleconferencing
system
St
as
it
was
known,
however,
was
connection
oriented,
not
datagram
like
I
like
IP.
It
included
a
small
header
using
per
hop
identifiers
and
supported
point-to-point
or
multi
to
point
to
multi-point
connections,
as
well
as
providing
Network
bandwidth
reservation.
I
What
would
later
become
RFC
1190
Steve
would
go
on
to
found
the
audio
video
transfer
working
group
avt
fastest
facets
of
which
live
on
today
in
ABT
core
he
served
of
its
chair.
He
served
later
as
co-chair
from
1991
until
2003.
he
authored,
15
rfcs
and
most
notably,
was
an
author
and
the
principal
editor
of
the
real-time
transport
protocol,
RTP
certification,
which
has
had
a
huge
impact.
I
As
you
all
know,
a
multimedia
data
transmission
in
on
and
across
the
internet
Steve
regularly
acknowledged
that
RTP
is
designed
Drew
significantly
from
the
earlier
Network
voice
protocol
and
its
sister
protocol.
The
packet
video
protocol,
the
designs
of
which
were
spearheaded
by
the
late
Danny
Cohen,
who
ran
the
networking
division
at
isi
beginning
in
1992
Steve,
was
the
primary
organizer
of
the
movement
to
establish
the
worldwide
internet
multicast
backbone
affectionately,
referred
to
as
the
m-bone,
an
experimental
virtual
Network
overlaying,
the
internet
for
broadcast
of
audio
and
video,
using
multicast,
IP
and
rtp-based
applications.
I
It
was
launched
in
case.
You
didn't
know
this
at
the
request
of
Allison
mankin,
who
was
pregnant
at
the
time
and
unable
to
travel
to
the
upcoming
ITF
meetings.
The
m-bone
enabled
live
streaming
of
ITF
meetings,
including
return
audio
from
remote
participants
and
in
many
ways
the
Unbound
tools
were
the
precursor
to
our
hybrid
meet
Echo
meetings
and
the
precursor
to
the
multitude
of
video
conferencing
apps
in
our
lives.
Today,
the
m-bone
was
carried.
The
M
bone
also
carried
the
first
internet
radio
broadcasts.
I
It
provided
audio
chat
rooms
for
Network
Geeks,
streamed
NASA
TV
of
the
first
Hubble
repair
broadcasted,
a
Rolling
Stones
concert
resulting
in
a
Newsweek
article,
boldly
displaying
Steve
castner
Van
Jacobson
and
Steve
Dearing
as
our
modern
day
superheroes
and
demonstrated
the
first
distributed
music
performance
with
distributed.
Performers
at
the
ACM
multimedia
94
conference
in
1995
Steve
took
his
expertise
into
the
commercial
Arena
to
further
develop
conferencing
and
streaming
apps
at
precept.
Software
later
acquired
by
Cisco
Systems
in
1998,
where
he
was
a
distinguished
engineer
from
2000
until
retiring
in
2014.
I
He
shifted
gears
to
work
on
network
performance
measurement
and
routing
analysis.
As
a
fellow
at
packet
design
in
retirement,
he
continued
to
work
on
various
projects
such
as
volunteering
for
the
Computer
History
Museum,
to
produce
an
operational
emulation
of
the
1960s
era.
Ibm
1620
computer,
a
room-sized
computer,
where
he
first
got
his
start
in
coding
as
an
undergrad
at
Occidental
College.
I
At
the
same
time,
he
was
pushing
the
envelope
of
Internet
architecture.
Steve
also
was
an
early
early
adopter
of
electric
vehicle
technology
and
fit
his
house
with
solar
panels
decades
ago.
Not
surprisingly,
he
enjoyed
helping
debug
the
early
Tesla
Roadster
EV
before
it
was
released
to
the
public.
And,
yes,
that's
a
picture
of
some
of
the
earliest
Roadster
owners
on
a
group.
I
Road
trip
down
the
coast
of
California
photo
taken
out
of
the
back
of
Steve's
red
Roadster,
hopefully
by
the
passenger,
and
not
the
driver
for
those
of
you
who
have
the
privilege
to
work
with
Steve.
You
know
firsthand
that
he
had
an
encyclopedic
knowledge
about
anything
and
everything
with
which
he
became
involved
and
he
enjoyed
being
a
keeper
of
the
prehistory
of
the
internet's
Evolution
tour
packet.
Audio
and
video.
His
attention
to
detail
was
unrivaled
by
anybody.
I
have
ever
met
whether
it
wasn't
bringing
the
real-time
transport
protocol
to
life
or
in
rebuilding
historical
Electronics.
I
His
meticulousness
motivated
those
of
us
lucky
enough
to
collaborate
with
him
to
bring
our
best
selves
to
the
task
at
hand
and,
in
addition
to
his
wisdom,
Steve
was
the
consummate
role
model
for
quiet
leadership,
humility
and
kindness.
In
2011,
he
was
awarded
the
2011
leadership
award
by
the
international
multimedia
teleconferencing
Consortium
and
in
2020
he
was
the
co-recipient
of
the
IEEE
internet
award
having
been
nominated
by
his
ABT
co-chair
Colin
Perkins,
whose
wise
words
I
paraphrase
here.
I
Steve,
has
long
provided
an
example
of
how
an
ITF
working
group
chair
should
act
with
humility
and
fairness.
While
building
on
a
deep
understanding
of
the
underlying
technology
and
systems
architecture,
he
saw
consensus
where
none
seemed
possible.
He
would
patiently
patiently
listen
to
all
sides
of
an
argument
identify
the
concerns.
Correct
misunderstandings
of
the
architecture
and
then
quietly
carefully
and
respectfully
help
the
working
group
come
to
consensus.
I
When
the
fireworks
began
in
the
evening,
this
July
4th
I
couldn't
help,
but
imagine
the
fireworks
were
celebrating
Steve's
life,
all
that
he
accomplished
and
all
the
people
whose
lives
he
touched
in
conclusion
and
to
Echo
the
sentiments
of
the
many
people
who
reached
out
to
me
after
my
posting
to
the
ITF
list
about
Steve's
passing.
It
was
truly
a
gift
to
have
worked
with
him.
I
Steve
you'll
be
sorely
missed
for
those
of
you
who
wish
to
send
condolences
to
his
family
or
to
know
further
details
about
the
memorial
to
be
held
in
August
or
to
donate,
to
the
endowed
chair
in
computer
science
that
he
and
Karen
seated
with
the
honorarium
from
the
IEEE
internet
award,
and
it
was
established
for
the
newly
created
CS
department
at
his
alma
mater.
Please
reach
out
to
me
next
slide.
I
B
A
J
Yeah
I
have
a
good
filter
ad
that
hasn't
been
said
already.
There
are
some
very
big
shoes
to
fill.
Steve
was
I,
think
the
role
model
for
how
a
chair
should
behave
always
as
Eve
said
always
incredibly
well
prepared,
incredibly
knowledgeable,
incredibly
polite,
incredibly
tactful
and
willing
to
work
to
to
gauge
consensus
it.
J
It
says
it
was
very
much
a
privilege
to
work
with
him
who
I
lift
up
to
those
shoes
when
I
joined
this
coach
here
and
I
hope
that
it
would
be
a
a
an
example
for
many
in
the
idea
I.
Think
of
the
way
he
shared
groups
he'll
be
missed.
A
All
right
now
on
to
our
regular
agenda,
which
I'm
sure
he
would
want
us
to
continue
to
work
on
so
we're
going
to
start
with
kryptex
of
Sergio
and
the
DVC
palette
format
skip
payload
format,
7983
this,
which
is
the
demultiplexing
and
then
two
things
in
rtpo
for
quick,
both
the
both
the
RTP
proper
and
the
sdp
and
then
v3c
and
green
metadata.
J
J
A
Right,
okay,
yeah,
so
draft
status
we
have
published
rtt,
multi-party,
rttmex
and
jpeg
XS
vp9
is
still
in
mishraf
Waiting,
indirectly
on
frame
marking.
A
A
See
some
people
unmuting
themselves,
okay,
somebody
says
so:
she'll
have
fun
yeah.
A
Good,
thank
you
yeah.
Maybe
when
I
got
called
away
from
his
desk
and
yeah,
we've
done
Last
Call
on
cryptex
and
BBC.
We'll
have
some
comments
on
the
the
iqf
last
call.
Cryptex
VVC
will
have
some
comments
on
those
well,
it
says
somebody
says:
there's
no
slides,
so
other
people
have
slides.
A
A
Yeah,
so
yes
and
then-
and
we
did-
we
need
a
revised
ID
on
frameworking,
so
mother's
nodding
in
the
back
of
the
room.
So
hopefully
that
means
that
will
happen
soon.
A
On
Skip
and
secondary
best,
we'll
have
discussions
of
those,
and
we
have
adopted
RDP
over
quick
and
we
did
a
call
for
adoption
GameStop
for
RTP,
which
we'll
talk
about
next
slide.
I
think
it
is
yes,
so
on
game
State
over
RTP,
there
were
only
two
responses,
one
of
whom
was
the
same
organization
as
the
initial
proposer.
A
So
our
suggestion
is
that
the
proponents
go
to
the
community
I
get
the
impression
that
the
interested
Community
here
is
not
the
usual
suspects.
We
get
here
in
the
ABT
Core
Group,
so
we're
asking
and
I've
asked
colonists,
also
personally
asking
them
to
send
to
go
and
try
to
get
some
people
to
express
interest
in
the
document,
and
we
will
extend
our
call
for
adoption
until
sometime
in
September,
so
that
people
can
do
it
after
August
Vacations.
So
if.
A
Yeah
I
mean
I
think
what
we
should
do
is
we
should
ask
I
mean
Colin
Jennings,
as
the
person
who
proposed
this
to
deducted
I
mean
I
think
he
knows
who
the
community
is,
so
he
we
should
ask
him
to
to
ask
them
to
come
and
indicate
their
interest
in
this.
L
Directorate
review,
so
they
all
the
non-contentious
feedback
has
been
incorporated
into
the
graph
and
there
are
three
feedback
that
I
considered
it
as
one
fix
that
I
was
playing
later
and
V8
open
a
STL
open
issues
that
it
is
what
I
am
going
to
explain
during
this
meeting.
So
we
try
to
to
get
Twitter
from
then
and
try
to
to
see
how
to
address
them.
L
M
L
L
Don't
think
that
there
is
anything
else
that
I
can
reference.
So
that's
what
I
have
considered
this
this
as
not
fixed.
If
anyone
has
say
any
any
draft
or
any
publication
that
we
can
link,
it
will
be
right,
but
if
not
I
I
think
that
we
cannot
do
much
more
on
this
and
the
the
last
one
was
about
checking.
If
we
should
register
the
two
new
values
for
the
definite
by
profile.
It
has
the
value
that
was
incorporated
in
the
draft,
but
there
is
no
INR
register
already
for
this
values.
So
I.
L
Don't
think
that
it
is
something
that
this
technique
is
to
solve.
If
we,
the
it
should
be
done
in
either
RCC
82,
85
or
or
even
in
the
RPC
35
15.,
so
I
don't
because
I
again,
I,
don't
think
that
Crystal
shouldn't
there's
other
Ayana
register.
If
the
other
drafts
that
Define
these
values
and
and
Define
the
register,
we
could
add
the
values
that
we
have
definite
in
the
in
the
graph.
A
H
A
Just
making
it
yeah
I
think
for
for
yeah
I
mean
these
are
I,
think
the
second
and
third
ever
defined
for
I
mean
sorry,
maybe
third
and
fourth
ever
decide
to
find
where
this
value
and
I
think
I'm
I
mean
I.
Think
at
some
point
it
might
be
useful
to
do
a
registry
if
we
ever
get
any
more
of
these,
but
I
wouldn't
recommend
blocking
this
draft
on
that
I'm.
Okay,
with.
H
L
So
there
was
another,
the
and
one
issue
raised
by
by
Ayana
that
there
was
a
mismatch
between
then
the
the
description
of
the
parameter
and
what
was
actually
being
registered.
So
we
said
that
they
could
be
used
at
that
session
level
of
media
labor,
but
the
general
registration
only
registered
it
for
media
level.
L
I
think
this
was
a
mistake
that
I
made
when
one
of
the
drafts
so
I
removed
it
intentionally
the
decision
level
one
and
what
I
have
done
in
the
in
the
new
draft
is
to
just
put
the
back
again
that
it
can
be
used
for
session
level
and
media
level,
but
as
I
mean
as
it
was,
it's
a
change
to
them
to
the
to
the
to
the
graph.
I
wanted
to
write
it
here
to
just
to
see
if
this
is.
L
So
nested
light,
please
also
there
was
two
questions
about
iprs
and
I.
Don't
think
that
we
need
to
to
do
anything.
Bernard
already
already
answered
those
issues
in
in
both
the
mailing
lists
and
in
the
issues
and
I'm
not
sure
if
we
need
to
do
anything
else
regarding
this
to
to
fix
the
to
or
to
cover
the
the
feedback
or
if
we
need
to
do
anything
else.
Regarding
this.
F
F
L
So
this
one
is
the
there
was
one
that
and
that
recommended
that
this
would
be
formally
update
the
RPC
3711,
because
it
also
they.
This
is
a
mechanism
or
it's
a
alternative
approach
of
foreign.
A
N
It
doesn't
mean
that
this
is
just
with
respect
to
this
IPR
slide.
There
were
some
languages.
Offense
me
a
little
bit
and
I
would
put
to
put
on
the
record
that
I
don't
believe.
The
IDF
has
something
like
requirement
for
an
IPR
disclosure
to
be
compatible
with
something
the
ipf.
G
N
A
L
Like
please,
this
one
is
a
bit
more.
There
was
some
some
feedback
about.
If
a
we
should
first
deprecate
RPC
since
904,
and
then
you
say
if
we
should
and
if
both
are
negotiated,
if
we
sweep
the
Mandate
or
we
should
recommend
that
the
agree
test
should
be
used
instead
of
a
RPC
since
904,
because
currently
the
it
is
up
to
the
implementation.
So.
F
Yeah
in
this
one,
Sergio
I
I,
don't
know
if
it
makes
sense,
because
when
you
offer
both
cryptex
and
6904,
it
means
I
can
receive
either
one
right
which
you
might
do,
because
you
don't
know
what
the
other
side
will
actually
support
right,
presumably
the
other.
The
answer
should
only
pick
one
of
them
yeah.
F
F
A
F
D
My
name
is
I
think
it
would
be
wrong
to
deprecate
the
normal
way
of
doing
the
header
extensions.
I
know
there
are
other
usages
out
there
or
at
least
proposed
usages.
Well,
it's
not
compatible
with
cryptex.
So.
A
D
But
no
so
I
know
that
3dp
has
some
proposals
where
it
will
put.
They
want
to
have
header
extensions
declare.
I
think
they
might
also
be
head
extensions
that
needs
to
be
encrypted.
So
therefore,
the
old
mechanism
is
going
to
be
needed,
which
is
so
so,
therefore
and
I
think
it's
it's
just
if
I
understood
but
not
correct
here,
it's
like
yeah.
Let
the
application
declare
and
select
what
expressed
their
preference
according
to
normal
STP
rules,
Etc
or
other
singular
mechanisms.
D
A
D
A
So
yeah
I
mean
I'd
suggest.
If
you
followed
that
Sergio
I'd
say
suggest,
you
know,
do
a
PR
and
post
to
the
list
and
ask:
are
you
getting
back
in
the
queue
or
are
you
just
or
did
I
should
remove
your
heart
all
right.
L
Yes,
so
we
said
no,
that
we
should
not
deprecate
the
RCC
6904
and
we
put
up
yard
for
with
the
suit.
If
the
sender
support
both
that
this
should
it's
to
send
group
text
is
that,
if
even
if
it,
if
it
doesn't
require
to
to
specifically.
O
Well,
I
I
agree
that
you
should
not
deprecate
6904,
that
that
would
make
sense,
but
if
you're
negotiating
cryptex-
and
you
do
see-
and
you
also
support
1604
I-
think
the
whole
point
of
supporting
critics
is
you
want
more
security
and
you
want,
you
know
less
revealed
so
I.
Don't
understand
why
you
would
say
should
and
not
must
here,
if
you
say,
should
what
is
the
exception
of
when
you,
when
you
may
not.
B
F
O
So
you
think
that
there's
a
security
requirement
asymmetrically
that
that
I
I'm
very
security,
conscious
about
what
I've
received
but
I'm,
not
very
security,
conscious
about
what
I
send.
F
O
Well,
I
I
thought
that
the
resolution
was
going
to
be
to
say:
if
you
support
both,
then
you
should
use
cryptics
and
usually,
when
you
put
a
should
you,
should
you
specify
when
you
would
not
what's
the
exception?
Why
is
it
not
a
must?
When
would
you
not
do
this
and
I'm
having
a
hard
time
envisioning?
What
useful
text
you
would
say
of
when
you
would
not
do
this
yeah.
A
I
I
suggest
we
discuss
some
of
the
last
ones.
We
have
text
once
we
have
a
PR
unit:
okay,
yeah,
because
okay.
L
So
this
one
is
a
and
currently
we
said
that
if
we
say
that
the
that
we
support
created
a
wheel
or
an
and
the
application,
considering
that
it
is
mandatory,
but
we
receive
an
RDP
that
has
not
acquisite
headers,
that
we
should
process
in
the
RTP
packet.
And
then
the
question
was
is
not
a
massive
stop.
L
A
P
J
A
L
L
Okay
lesson
light,
so
this
is
what
is
the
The
Next
Step,
so
I
will
I
will
just
make
the
the
pr
that
it
is
missing
and
publish
it
to
the
end
to
the
mailing
list
for
confirmation
and
when
that
is
done,
is
I
will
produce
a
new
grid
text
graph
and
I'm,
not
sure
what
do
we
need
to
do
next?
If
we
should
have
a
last
call
again
or
again,
ISD
review
I.
A
Think
well,
I'm
trying
what
exactly
is
the
procedure?
You
know
if
I
think
I
think
it
just
goes
to
the
iesg
and
the
ISC
members
decide
whether
it
satisfies
their
discuss
and
comments.
So
I
think
that's
all.
A
I
yeah,
so
on
this
one
I
think
we
said
I
think
we
said
we've
got
a
must
in
you
know,
I
think
that
Sergio
said
either
go
to
muster
change.
The
word
mandatory
I'd
be
inclined
to
say,
go
to
must
because
I
think
that's
the
easiest.
N
I'm
here,
BBC
payload
for
my
next
slide.
Thank
you
so
version
16
was
out
in
the
isg.
They
came
up
with
album
with
three
discusses
and
a
whole
bunch
of
useful
comments,
including
a
real
stupid
Buck.
From
our
side,
we
populated
the
the
Yana
template
only
halfway
and
copy
paste
error
stupid
stuff.
Anyway,
these
three
discusses
two
were
cleared
after
we
published
words
in
17
in
17.
N
We
tried
to
address
everything,
so
let's
discuss
remained,
and
that
is
related
to
a
technology
that
was
introduced
in
RCA
3984
back
20
years
ago
or
so
regarding
sender
properties,
which
is
something
that
somewhat
changes
the
in
in
and
offer
answers
scenario.
Someone
changes
the
semantics
of
of
how
you
use
STP,
basically
now
that
that
history
was
probably
not
in
inside's
mind
when
he
came
up
with
this
discuss.
N
So
we
had
a
meeting
this
morning
and
the
the
outcome
of
that
meeting
is
that
well,
I
have
informative
language,
explaining
this
unusual
behavior
of
s-prop
per
points
and
issue,
a
version
18,
and
he
plans
to
clear
his
discuss
against
that
version.
18.
N
If
things
are
looking
good
and
then
our
suggestion
or
author
suggestion
is
the
updated
yarner
template,
which
was
the
only
significant
normative
change,
actually,
the
only
normative
change,
if
I
recall
that
was
signed
up
by
by
the
Jana
review
signed
off
and
the
era
directors
generally
responded.
Thanks
for
addressing
our
comments,
so
I
think
we-
and
this
change
here
will
be
in
an
purely
informative,
so
I
think
we
don't
need
another
last
program
in
the
working
group.
N
J
A
E
Let's
I'll
start
the
show
off
a
little
bit.
Okay.
This
is
Mike
Fowler
and
good
afternoon
to
the
ABT
Corp
Community.
Next
next
slide,
please
our
status.
This
is
awaiting
external
review
resolution
of
issues
raised.
We
an
email
is
referenced
here
from
the
music
working
group.
That
indicates
third
review.
The
sdp
is
complete
and
I
guess.
The
important
message
is:
it
does
not
define
any
new
sdp
attributes.
There
is
no
need
for
any
new
sdp
procedures.
E
Gen
Arts
review
had
a
simple
summary
of
the
simple
document
is
adequate
to
register
the
media
type,
as
is
art
art,
had
some
questions
on
it
and
basically
said
not
ready
and
we'll
go
over
the
the
comments
from
the
community
in
the
next
slides.
Our
draft
is
due
to
expire
on
November,
26th
and
Dan
will
pick
up
this.
We
we
put
this
together.
K
Okay,
I
guess
the
one
of
the
main
issues
that
was
actually
raised
in
both
comments
for
Gen,
art
and
art.
Art
was
regarding
the
references
to
skip
two
tenants.
References
to
skip
214.
K
Both
of
these
groups
wanted
them
to
be
normative.
However,
I
believe
that
this
group
actually
determined
way
back
when
that
these
would
be
informational
documents.
K
As
far
as
we
go
as
far
as
our
opinion,
it
doesn't
really
matter
to
us
I.
Guess
it's
just
a
matter
of
coming
to
our
resolution
on
this.
As
far
as
which
type
of
reference,
this
should
be
Bernard.
F
Yeah,
as
you've
said,
I
think
many
times.
This
document
is
not
the
documentation
of
skip,
so
it's
it's
merely
the
documentation
of
of
essentially
the
sdp.
So
I,
don't
think
it's
the
the
comment
says
you
you
need
it
to
implement,
skip,
but
I,
don't
think
that's
necessarily
relevant,
which
is
why
we
allowed
it
to
be
informational.
K
K
Okay,
next
slide
foreign
group
mentioned
that
214
has
only
mentioned
at
one
point
in
the
document
we've
discussed,
possibly
even
removing
the
reference
to
214.2
from
from
this
document.
Only
because
it's
internally
skip
214
is
really
a
precursor
to
this
upcoming
RFC.
If
you
will
so,
it's
kind
of
can
go
away.
K
If
you
will
I
guess,
the
only
issue
I
saw
with
that
is
that
it
is
actually
referenced
in
the
Guyana
registration,
so
we'd
I
guess
as
part
of
that
update-
and
it
kind
of
leads
into
another
question
later
on
about
also
about
the
Ianna
registration
about
how
that
would
affect.
If
we
do
decide
to
remove
the
skip
214
reference
from
our
document,
Bernard.
F
Yeah
I
think
you
could
remove
it
and
then
update
the
registration,
since
it
seems
like
all
the
comments
refer
to
the
references
having
as
few
as
possible,
just
I
might
just
say
to
some
hassle.
F
You
know:
do
you?
Do
you
need
this
reference?
Does
it
is
it?
You
know
really
necessary
to
understand
the
document
and,
as
you've
said
I
for
214
I
think
the
answer
is
no.
K
Right,
like
I,
said
it
was
kind
of
a
for
internally
for
our
for
our
working
group.
The
skip
working
group.
It
was
really
a
precursor
to
to
this
reference
and
it
and
it's
its
content,
is
essentially
what
this
RFC
is.
So
it
can
kind
of
go
away
if
you
will,
from
from.
E
The
the
other
way
to
think
of
it,
though,
is
also
the
fact
that
the
that,
while
the
information
presented
in
214.2
and
this
draft
Ric
are,
are
nearly
identical,
the
communities
that
will
actually
use
them
are
different
and
their
references
are
are
more
relevant.
You
know
the
RFC
is
meant
for
people
outside
of
our
skip
Community,
who
are
building
products
that
have
to
carry
our
payloads
and
that's
what
they
need
to
build
to
the
the
skip.
E
Is
references
for
ecu's
end
units
that
will
be
implementing
the
full
scope
of
a
bunch
of
other
skip
documents,
and
this
would
be
the
only
place
that
provides
a
tie-in
for
that
for
those
functions,
so
remove
it.
If
it
gets
this
along,
that's
great.
Otherwise
it
is
the
tie-in
to
the
community,
the
skip
community
and
the
the
networking
Community
yeah
I.
F
Yeah
I
guess
my
only
question
would
be
you
know,
just
it's
a
maintenance
question.
You
know,
are
you
gonna,
you
know
what,
if
you
decide
to
do
an
update
for
video
or
something
are
you
gonna?
Do
it
in
the
skip
214
series
like
have
a
DOT
three?
Are
you
gonna
update
this
document
that
that
might
be
the
only
reason
it's
relevant
is
if
you're
trying
to
point
someone
to
it.
F
E
I
I
I
can
see
it
both
ways.
That's
the
only
way
I
bring
it
up,
but
because
it
the
RFC,
won't
won't
obsolete
the
document
to
our
community,
but
yeah.
A
I
think
the
only
and
the
only
alternative
I
would
have
is
just
I
mean
if
you
are
do
want
to
keep
it
in
just
mention
it
somewhere
outside
the
abstract,
just
mention
it
in
the
introduction
or
something
saying
hey.
This
used
to
be
defined
by
214.2,
but
this
supersedes
that
or
something
like
that.
So
just
just
so
it's
more
clear
to
people
where
what
the
document
is.
You
know
they're,
just
as
it
says
like
so
it's
mentioned
somewhere
besides
the
abstract
and
the
registration.
Just
you
know,
informationally.
A
K
Thanks
next
slide,.
K
And
back
to
the
back
to
the
registration
here,
I
guess
the
question
was
the
sections
five
one
and
five
two
of
this
document
are
basically
a
if
you
will
the
Ina
registration.
B
K
Skip
drafts
that
we
did
register
the
payload
types
first,
I
think
the
question
was
as
far
as
updating
the
Ina
registration
for
this
was
or
having
it
also
repeated.
If
you
will
in
our
document
in
this
document
I
guess
it
was
they've
talked
it.
One
of
the
questions
was
about
how
to
update
contact
information
and
things
like
that
about
that
I,
don't
know
if
we
could
throw
that
question
out
there
to
talk
about
the
first
year,
I
guess
what
the
process
is.
A
I
think
that
if
the
the
goal
of
this
document
is
to
change
these
registrations
to
refer
to
this
document
rather
than
214.2,
so
I
think,
if
you
explicitly
say
on
both
the
bullets
on
this
slide,
this
you
know
Updates
this
registration
to
be
this
document,
rather
than
the
the
previous
registration
I.
Think
that
that
it
should
be
fun,
then
you're
not
repeating
but
and
you're,
not
repeating
the
registration,
you're,
changing
the
registration
and
that's
fine.
K
B
A
K
J
J
E
We
were,
there
were
some
comments
received
that
were
more
narrative
and
they
were
not
incorporated
as
they
they
don't
impact
the
technical
information
necessary
to
Port
skip.
They
were
references
to
the
intro,
the
abstract
and
background
information
where
references
were
occurring
and
and
I
it
was.
It
was
I,
guess
I
I
not
to
be
quite
blunt,
but
you
know
someone's
opinion
that
that
doesn't
really
impact
what
we
really
want.
People
to.
E
On
which
is
the
technical
information,
so
I
I
didn't
want
to
start
moving
stuff
around
for
the
sake
of
one
person's
opinion
and
it
it
doesn't
really
it's
just
a
story
and
anyone
can
tell
the
story
in
different
ways,
so
we
left
it.
It
just
seemed
like
an
easier
way
to
go
and
the
comments
which
impact
the
technical
understanding
that
were
discussed
here
with
the
resolution
we'll
put
that
into
the
draft
RFC
we
would
look
for
you
know.
E
Dan
was
asking
for
information
of
how
to
approach
Diana
about
updating
what
is
presently
there
to
reflect.
Well,
for
instance,
an
RFC
number
when
we
get
it
here,
but.
M
E
Know
that
we
didn't
know
what
the
specific
procedures
who
to
contact
and
how
to
do
that,
so
we
may
be
looking
for
guidance
there,
and
you
know
after
that,
we,
you
know,
we
can
update
this
document
and
we
can
update
Diana
in
parallel
once
we
have
something
of
an
RFC
number
to
tell
them
to
put
into
place.
But
what
are
the
next
steps?
What's
next
after
this.
F
Yeah
I
mean
I.
Think
it's
it's
basically.
The
main
thing
here
is
the
update,
the
Ayana
in
registration
section
to
do
the
things
we
talked
about
in
terms
of
next
steps.
Beyond
this
it
would
be
the
shepherd
write-up.
The
issue
we're
having
I
think
right
now
is
I.
Think
it's
stabilizing
they've
changed
a
bunch
of
the
questions
and
and
the
shepherding
procedure,
but
as
soon
as,
but
that
would
be
The
Next
Step
Beyond.
This
once
you've
submitted
a
a
new
draft.
F
I
guess
the
sector
review
is
still
outstanding,
but
hopefully
that'll
show
up
at
some
point,
but
I
don't
think
we
have
to
wait
for
that
to
show
up.
K
Right
yeah
because
I
wasn't
quite
clear
about
exactly
from
the
art
art
review,
exactly
what
specific
things
that
they
said
that
were
a
problem
that
would
prevent
this
from
moving
forward,
I
mean
there
was.
There
was
a
comment
about
some
of
the
initial
language
up
front:
the
boilerplate
documents
for
the
20
21-19
reference,
and
we
changed
that,
but
they
just
I
guess
we
were
not
clear
about
exactly
which,
which
particular
issues
that
were
raised
that
were
showstoppers
for
for
that
group.
So.
K
F
And-
and
you
know,
the
references
which
we
just
talked
about
so
I
think
we've
pretty
much
gone
over.
Everything
that
would
be
you
know,
would
be
an
impediment
to
moving
forward.
J
K
J
K
B
F
Okay,
so
we'll
try
to
make
this
quick.
This
is
an
update
on
7983
bits
next
slide,
so
I
think
you've
all
heard
what
this
is
basically
about.
It's
attempt
to
Multiplex
quick
with
srtp
srtcp
start
and
turn
dtls
and
zrtp,
and
it
does
include
an
update
to
dtls
content
field
with
no
other
change
next
slide.
F
So
the
working
good
last
call
completed
on
June
6th.
We
got
three
major
comments.
One
was
from
Martin
who
was
concerned
that
some
of
the
text
had
quick
version
dependencies.
For
example,
we
explicitly
mentioned
the
quick
short
and
long
headers
which
could
conceivably
change
in
some
future
version.
F
F
Another
question
he
raised
was
relating
to
the
multiplexing
of
churn
channels
and
quick
and
Jonathan
also
chimed
in
on
that
which
and
I'll
talk
a
little
bit
about
the
resolution.
But
it's
basically
along
the
lines
Jonathan
suggested,
which
is
that
the
overlap
between
turn
channels
and
Quake
isn't
actually
a
big
problem,
because
the
turn
channel
package
should
only
come
from
a
turn
server.
So
we'll
talk
about
that
in
a
little
bit
a
little
bit
more
on
next
slide.
F
So
this
is
the
updated
diagram.
It's
basically
the
same
as
what
we
had
before,
but
we
took
out
references
to
the
quick
short
and
long
headers.
Basically,
we
just
say
forward
it
to
quick
and
then
whatever
quick
version
you
happen
to
have,
will
figure
out
what
what
those
packets
mean.
Assuming
it's
it's
getting
it's
being
forwarded
correctly,
so
we
don't
really
have
to
put
in
version
specific
things
here,
and
so
that's
the
change
in
the
diagram.
Next.
F
So,
in
terms
of
changes
we
had
major
changes
were
in
section
one
and
section
two,
and
in
section
one
we
basically
said
hey.
We
are
compatible
with
quick
version,
two,
the
in
the
in
its
draft
form,
but
not
with
the
quick
bit
greasing
and
as
a
result,
you
must
not
send
that
transport
parameter
and
then
in
section
two.
This
is
where
we
talk
about
the
overlap
between
turn
channels
and
quick
and
how
to
deal
with
it.
F
So
this
kind
of
is
is
important
text
and
basically,
what
we're
saying
here
is
along
the
lines
of
what
Jonathan
suggested,
which
is
that
the
overlap
isn't
a
real
problem,
because
you
would
only
get
the
turn
Channel
packets
from
a
turn
server
and
what
what
that
means.
F
Is
you
basically,
as
Jonathan
said
in
this
message,
you
only
really
need
to
be
able
to
disambaguate
the
turn
from
disambiguate
stun
and
then
the
other
one
is
is
disambiguating
srtp
srtcp,
zrp
dtls
are
quick
which
won't
be
sent
from
from
a
source
in
IP
and
Port
that
had
responded
to
a
turn
allocation.
F
So
it
is
a
little
bit
different
from
the
previous.
The
multiplexing
advice
in
in
7983
and
that
you
do
need
to
keep
track
of
the
turn
server,
IP
addresses
and
ports
to
be
able
to
do
the
demultiplexing,
but
I.
Think
if
you
do
that
it
is
the
overlap,
is
not
an
issue.
F
And
and
you
can
un
Ambiguously
demultiplex.
F
Okay,
so
the
question
here
is:
have
we
addressed
everything
in
particular
this?
This
overlap
between
stun
between
turn
and
quick,
and,
if
not,
is
there
anything
else
we
need
to
address
to
kind
of
address.
All
of
the
working
group
last
call
issues
that
were
brought
up.
A
I
personally,
I
think
we're
probably
ready
and
I
guess
since
you're
the
author
I
can
take
over
shepherding
it
anybody
object,
otherwise
we'll
go
ahead.
A
G
So
we
have
a
short
update
on
RTP.
Real
quick
I
will
first
go
through
the
updates.
We
did
between
the
last
interview
meeting
and
the
call
for
adoption
and
then
later
look
at
some
of
the
open
issues
and
proposed
Solutions
next
slide.
Please.
G
So
we
added
a
scope
section
at
the
beginning
of
the
draft,
which
explains
that
this
draft
is
to
or
aiming
to
describe
a
minimum
I
think
for
our
application
usage
of
RTP
overclick.
We
try
to
do
the
minimal
stuff
first
and
then
we
can
go
to
more
complex
scenarios
later.
The
Baseline
here
expects
that
we
have
a
standard,
quick
implementation,
but
it
can
benefit
from
Quick
extensions
and
we
describe
some
of
the
optimizations.
G
We
can
do
to
RTP
over
quick
when
we
have
some
of
these
quick
extensions
and
redescribe
what
API,
what
the
API
of
a
quick
implementation
could
offer
to
implement
these
optimizations.
Q
Q
G
G
Then
there
was
a
discussion
on
the
mailing
list
that
we
need
an
alpn.
We
have
added
a
section
for
this
in
the
I
think
in
the
beginning
of
the
draft
that
an
alpn
is
required
by
click
to
set
up
a
connection,
and
we
defined
r2pmox
quick
to
indicate
that
this
that
it
would
be
possible
to
Multiplex
different
flows
next
to
RTP.
On
the
same
quick
connection,
we
will
go
back
to
that
later
and
issue.
G
M
G
Next
slide,
please,
we
added
a
section
on
API
considerations,
which
basically
lists
a
set
of
features
which
quick
implementations
can
provide
to
help
implementing
certain
optimizations.
The
section
is
split
into
two
subsection:
one
is
listing
information,
so
that's
a
quick
implementation
or
the
quick
stack
could
expose
to
the
application
layer
to
help
implementing
the
optimizations
in
RTP.
G
That
includes,
for
example,
the
MDU
size
to
send
datagrams
of
the
correct
size
acknowledgments
as
they
are
listed
in
the
rtcp
section,
which
we
talked
about
already
earlier
things
like
stream
States.
So
we
added
streams
in
the
last
meeting.
I
talked
about
that
I.
Think
and
if
we
are
using
streams,
then
we
need
to
know
something
like
how
far
is
the
stream
progress?
G
So
it's
a
RTP
packet
completely
sent,
or
is
it
not
so
that
the
RDP
implementation
or
the
application
implementation
can
make
a
decision
whether
it
wants
to
keep
the
stream
open
to
allow
for
re-transmissions
or
whether
it
wants
to
cancel
the
stream,
because
it's
too
late
to
transmit
the
packets
and
then
the
second
second
subsection
of
the
API
considerations
lists
some
methods
that
could
be
exposed
by
a
quick
implementation.
G
Such
as
canceling
streams,
if
we
want
to
or,
for
example,
setting
congestion
controllers
next
slide,
please
other
options
which
are
a
little
changes
in
the
sections
which
are
already
there
re-restrict
RTP
sessions
for
now
to
use
either
quick
streams
or
quick
datagrams,
not
both.
At
the
same
time,
different
RTP
sessions
can
use
Quick
streams
and
datagrams.
So
just
not
within
one
session.
G
And
then
we
add
some
implementation
applications
about
the
mapping
from
Quick
statistics
to
rtcp
when
quick
streams
are
used.
I
think
I
already
mentioned
this
in
the
last
meeting
that
in
this
case
the
connections
are
not
exactly
what
is
in
the
network
because,
due
to
retransmissions,
we
have
other
statistics,
then
we
would
have
if
we
would
use
rtcp
and
we
added
an
amplification
tutorial
node
to
the
draft
that
an
application
should
be
aware
of
this.
G
C
C
O
Just
a
question
about
the
first
point:
what's
the
what's
the
point
of
the
restriction
on
not
being
able
to
use
streams
and
datagrams
simultaneously.
G
For
now,
as
far
as
it
was
just
because
we
wanted
to
do
the
simple
thing:
first,
we
are
not
exactly
sure
what
the
implications
are.
If
one
session
is
using
both
and
we
might
loosen
this
restriction
later,
I
would
say,
but
we
were
just
not
clear
about
what
the
implications
are
of
this.
Okay.
O
So
just
just
FYI
in
in
some
other
and
some
other
usages
of
media
over
quick
like
like
in
Mock
and
quicker.
We
are
actively
sending
both
streams
and
datagrams
and
we
see
a
lot
of
use
cases
where
that
that
actually
has
some
benefits.
Yeah.
G
F
Yeah,
so
I
did
want
to
follow
up
on
What
mo
was
talking
about
you
know,
particularly
when
you,
when
you're
bundling
things
together
right,
there
might
be
you
might.
You
might
have
a
bunch
of
things
on
the
same
quick
connection,
you
might
be
sending
data
and
that
actually
led
me
to
a
question
about
the
alpn.
You
know
you're
suggesting
RTP
mux,
but
you
might
also
be
sending
data
on
that
connection.
F
Presumably,
if
you're
sending
data,
you
still
would
want
the
the
same
congestion
control,
for
example,
if
you're,
if
you're
doing
audio
and
video
and
you're
sending
data
that
data
you
know,
might
well
use
the
same
low,
latency
algorithm
right,
you
don't
necessarily
care
that
and
the
algorithm
would
take
care
of
of
multiplexing
those
two
things
so
anyway.
I
think
the
main
thing
is.
F
O
Just
to
clarify
that
the
use
cases
that
I
had
in
mind
were
sending
audio
as
datagrams
and
video
as
streams
or
a
complex
video
stream,
layered,
video
stream,
the
dependent
layers
as
streams
and
the
independent
layers
of
streams
and
the
dependent
layers
as
datagrams.
Those
are
the
specific
examples
that
I
was
at.
F
I've
seen
I've
seen
usage
similar
usage,
where
the
base
layer
is
sent
as
reliable
and
the
upper
layers
are
sent
as
datagrams.
A
R
Yeah
you're
good
just
quickly
on
this.
We
have
that
on
our
radar
as
as
much
as
said
it's
since
there
is
different
ways
of
how
you
could
prioritize
one
thing
over
the
other.
The
quick
datagram
graph
currently
says.
So,
if
there's
a
datagram
coming,
you
sent
that
first
there's
a
bunch
of
implications
to
be
understood,
and
this
is
what
we
currently
have
on
our
agenda
of
trying
to
figure
out.
R
So
there
is
not
a
a
disagreement
with
this
idea,
but
it's
it's
not
completely
obvious.
What
kind
of
feature
interaction
it's
been
using
both
at
the
same
time
for
different
things?
Would
there
would
be.
F
G
So
one
thing
which
we
have
not
as
a
data
repository
first
in
the
GitHub
repository
first
translators,
forwarding
UDP
packets
from
or
rtps
packets
over
UDP
received
via
RTP
over
quick,
are
bound
to
the
MTU
of
the
UDP
packet
and
in
our
current
draft
it
says
that
we
can
use
streams
for
RTP
packets,
where
one
RTP
packet
is
sent
on
one
screen
and
that
could
potentially
be
larger
than
the
MTU
in
the
UDP
which
it's
being
forwarded
to.
So
that
is
one
problem
that
we
might
have
to
solve.
G
Then
two
issues
for
which
we
already
have
pull
requests
in
the
GitHub
repository.
The
first
one
is
with
transmission
flow
IDs.
There
was
a
question
that
on
which
Pro
ID
RTP
packet
has
to
be
retransmitted
and
I
would
say
that
is
up
to
where
a
rich
RTP
screen
that
RTP
packet
is
re-transmitted
in
and
then
the
flow
ID
will
be
that
of
this
RTP
session.
G
Then
there
was
a
question
about
which
screen
times
we're
using
and
we
added
a
pull
request
which
says
that
we
are
actually
only
using
unidirectional
because
we
intend
to
close
the
stream
as
soon
as
the
RTP
packet
is
transmitted.
And
then
that
case
we
don't
have
any
data
flowing
in
the
other
direction,
because
we
cancel
the
stream
after
close
the
stream
afterwards
anyway.
So
we're
using
unidirectional
screens
Chevron.
N
N
Stupidity
is
something
you
can't
design
against
yeah
if,
if
a
sender,
if
you
are
in
a
scenario
and
which
you
will
be
probably
in
the
next
10
or
20
years,
whether
maybe
a
Gateway
involved
that
that
speaks
UDP
on
the
other
side
and
Center
is
stupid
enough
to
create
packets
that
are
that
are
megabyte
long
well,
tough
right
business
will
take
care
of
that.
Okay,
thanks.
C
This
is
Spencer
Dawkins.
We
talked
with
that's
a
little
a
little
bit
about
this
earlier
today.
C
I
think,
and
one
of
the
things
I
was
suggesting
was
that
there's
lots
of
different
kinds
of
RTP
translators
in
Little
Boxes
looks
like
there's
an
RFC
full
of
them
and
for
us
to
be
real
in
addition
to
what
Stefan
was
saying,
it's
good
to
be
real,
clear
on
what
kind
of
middle
box
we're
talking
about
here,
because
there's
lots
of
them
and
there's
probably
one
or
two
that
we
might
have
in
mind
for
use
with
RTP
with
RTP
over
quick.
F
There's
a
bunch
of
things
here
that
that
this
group
is
doing
or
may
do
that
may
have
impact
on
RTP
topologies.
F
So
it
may
be
worth
thinking
about
how
to
get
that
information
somewhere,
I'm
thinking,
in
particular
about
intent,
encryption
there
may
be
situations
where
you
know
a
main
can't
wouldn't
be
able
to
adjust
the
MTU
size
or
anything
like
that
and
I
think
this
is
just
one
of
them.
So
just
something
to
think
about.
G
Okay,
then,
the
last
two
issues
are
two
issues
to
which
we
don't
have
Solutions.
Yet
the
first
one
is
considerations
about
stream
concurrency,
because
in
quick
we
need
the
sender
needs
credits
to
open
streams,
and
the
receiver
has
to
provide
enough
credits
for
that
and
Lucas.
If
I
do
opened
this
issue
and
suggested
that
we
should
add
some
considerations
about
that,
because
it
limits
the
amount
of
parallel
rgp
packets,
which
are
currently
being
transmitted,
and
we
should
probably
give
some
guidance
on
this.
G
How
a
receiver
has
to
manage
this
and
then
the
last
one
is
also
from
Lucas.
Potter
is
what
happens
if
datagrams
are
not
enabled
and
he's
addressed,
that
we
could
encode
something
for
this
case
in
the
alpn.
G
Tokens,
for
example,
to
let
senders
and
receivers
negotiate
and
the
connection
establishment
what
kind
of
transmission
they
are
going
to
use,
streams
or
datagrams
or
use
transfer
parameters
for
that,
and
but
then
we
also
have
the
external
signaling
for
setting
or
negotiating
the
sessions,
probably
in
sdp,
for
example,
and
what
what
would
happen
if
I,
for
example,
negotiate
something
in
sdp
and
then
the
connection
setup
does
something
else.
So
that's
an
issue
we
are
having
in
the
GitHub
repositories
currently
and
we
don't
exactly
know
how
to
resolve
this
yet
yeah.
G
G
So
as
the
next
steps
or
recent
steps,
we
submitted
a
working
group
draft
this
week
and
then
we're
going
to
continue
with
it
working
with
Spencer
and
the
sdp
signaling
yeah
I
think
that's
all
I
have
for
now,
and
you
know.
F
Just
a
comment
in
in
the
web
transfer
working
group,
we
also
talked
about
whether
datagrams
should
be
required,
and
it
was
pointed
out
that
this
is
very
easy
to
implement
in
quick.
So
there's
no
real
excuse
for
not
doing
it
in
a
quicker
momentation,
so
the
thinking
was
just
require
it.
You
know
in
the
transport
parameter
and
and
just
get
it
up,
you
know
get
it
over
with
there.
Whether
you
use
it
or
not.
An
sap
is
a
different
story,
but
at
the
quick
layer
just
require
that
they
do
datagrams.
F
J
C
So
I'm
Spencer
Dawkins
and
I'm
the
follow-on
to
Mathis
and
York
next
slide.
Please.
C
So,
basically,
remembering
that
Michael
with
an
individual
draft
was
to
do
a
minimal
sdpa
specification
which
roughly
tracks
the
draft
that
has
now
been
adopted
by
the
ABC
core
working
group
and
to
track
more
high
level
issues
in
a
separate
repo.
C
That
I
think
a
lot
of
the
discussion
will
not
end
up
in
the
minimals
STP
specification,
so
fsitf
I'm,
providing
an
update
based
on
the
it
was
I,
was
actually
looking
at
Dash
four
of
the
International
Drive,
but
I
think
the
only
change
was
the
name
to
reflect
adoption
and
please
feel
free
to
provide
feedback
to
on
the
mayoral
list,
also
and
my
Congress
to
ensure
one
of
the
minimal
specification
before
our
next
WT
Corps
meeting,
eventually
I
think
would
be
good
for
me
to
request
an
option
of
a
normal
specification
so
but
I'm
not
doing
that
at
this
time.
C
So
what
ABC
core
sorry
AVP
profiles
to
register
was
issue
number
five.
First
off
the
last
General
was
to
register
one
profile,
quick,
RTP,
absolute
pef,
and
noting
that
the
secure
IDP
profiles
are
most
useful
when
bridging
to
non-quick
or
TCP
RTP,
and
we
were
saying
that
we
won't
have
that
conversation
or
revise
the
RTP
topologies
RC
and,
of
course,
I
forgot
to
prepare
UDP
for
consistency
in
the
registry.
C
My
apologies
and
then
other
related
questions
started
popping
up
a
lot
about
datagrams,
strange
sources,
datagrams
on
the
next
slide
and
where
we
need
ice
TCP,
which
is
a
real
issue.
Next
slide.
Please.
C
So,
let's
say
about
RDP
other
streams:
datagrams
are
both
chosed
up
in
a
couple
of
places,
the
issue
in
a
parade
in
Issue,
Number,
Nine
or
sorry
number
three
right
now,
there's
discussion
of
including
a
shared
capability
as
well
in
the
draft
we've
adopted,
although
I'm
getting
slightly
ahead
of
where
the
adopted
draft
is
so,
my
proposal
would
be
to
do
extreme
datagram
and
share
it
if
we
get
to
Shared,
basically
just
based
on
the
discussion,
we're
heading
about
that
draft
next
slide,
please
this
is
new.
C
Do
we
need
tcpis?
This
is
from
Roman
and
when
this
is
my
summary
of
His
longer
explanations
that
are
on
list
I
would
recommend
taking
a
look
at
those
his
key
Point
as
I
understand
it
is
that
we
need.
We
need
a
way
to
fall
back
to
TCP.
C
If
we
can
use
ice
TCP
candidates,
we
do
have
a
fallback
and
if
we
can't
what's
the
alternative,
his
proposal
was
to
also
register
TCP,
quick
RTP,
avpf
style
profiles
and
there's
actually
a
continuing
discussion
since
I
selected
since
the
slides
in
on
the
mailing
list
about
well.
Why
would
we
not
just
you
know,
go
go
to
RTP
over
over
TCP,
like
I,
say
more
working
group
discussion,
yeah.
R
Just
to
to
point
out
that
that
probably
requires
some
some
fundamental
and
explanation
on
the
list,
because
I
haven't
yet
fully
understood
how
this
reason
chain
of
reasoning
came
into
being,
that
that
would
need
to
be
registered.
If
we
are
worried
about
running
two
congestion
controls,
one
in
screen
or
something
on
top
of
quick,
you
should
be
even
more
worried
about
running
three
contrasting
controllers
on
top
of
each
other.
If
we
tunnel
the
whole
thing,
then
to
TCP
that
just
doesn't
sound
about
what
we,
what
we
would
want.
A
To
be
doing,
Roman
won't
let
you
respond.
First,
then
I'll
I
guess
I
put
myself
in
the
queue
for
as
an
influential.
M
Ice
machinery
we're
setting
up
calls
they
come
with
certain
kind
of
features
which
again
haven't
been
designed
for
RTP
over
quick
they've,
been
designed
for
FTP
over
UDP,
and
they
come
with
support
for
tunneling
over
TCP
or
TLS
like
for
instance,
if
you.
So,
if
you
use
turn
servers,
you
are
away
through
a
intermediary
server
and
one
of
the
relays
can
be
over
TCP
to
return
server
and
from
turn
server
over
UDP
to
whatever
is
using
whatever
we
use
the
party
on
the
other
end.
M
So
it's
kind
of
part
of
ice
Machinery.
The
other
situation
is
the
other
kind
of
extension
is
istcp,
which
is
where
you
try
to
establish
TCP
connection
between
the
like
two
eyes
or
agents,
and
you
tunnel.
The
protocol
over
a
TCP
connection
am
I.
M
Guess
the
mean
complicating
factor
that
people
kind
of
Miss
in
all
of
this
is
that
the
way
eyes
operate
is
that
you
can
end
up,
for
instance,
with
your
packets,
going
over
HP
connection
and
in
the
process
of
nomination
your
same
or
a
protocol
which
is
running
on
top.
You
can
switch
to
UDP,
like
the
typical
example
would
be.
M
It
takes
some
time
to
set
up
eternally,
which
would
be
over
UDP
so,
and
your
istcp
candidates
will
work
first
so
like
if
you
start
negotiating
connection
over
istcp,
and
then
you
switch
to
relay
through
a
turn
server.
While
the
protocol
is
still
being
set
up,
while
you're
basically
sending
initial
packets
for
media.
So
it's
like
so
it's
kind
of
all
designed
to
work
together
and
not
necessarily
ideal
for
what
we're
doing
with
RTP
over
quick.
M
M
So
that's
that's
kind
of
where
this
whole
TTP
tunneling
comes
from,
and
the
candidate
like
actually
comes
from
working
in
some
of
the
quirks
of
sdp
ice
negotiation,
and
that's
why
I
had
to
add
those
like
TTP
versions
of
protocols
for
dtls
srtp
and
did
like
for
the
MRCP.
It's
just
because
of
the
like.
In
a
certain
sequence
of
events
you
and
like
you
need
to
signal
that
you
are
sending
stuff
over
dcpano
and
that's
the
only
way
to
specify
it.
It
doesn't.
M
We
affect
the
overall
raw
protocol,
but
it's
again
not
ideal,
because
there
are
multiple
layers
of
vacuum
contest.
There
are
multiple
issues
with
head
of
the
line:
congestion
when
your
tunneling
over
TCP,
which
are
again
undesirable,
but
it's
kind
of
been
treated
as
a
a
tree
that
is
like
is
yeah
so
anyway.
So
it's
just
if
we're
using
ice
like
we
need
it.
If
we're
not
using
rice,
we
need
to
come
up
with
alternative
for
going
through
essential,
negotiate
connection
from
behind
that
or
behind.
C
Yeah
I
I
should
just
make
the
observation
that
Roman
and
I
and
York
are
the
three
people
that
are
talking
on
the
mailing
list
right
now.
But
the
discussion
is
happening
in
a
mail
in
a
through
email
thread
with
a
not
particularly
obvious
subject.
I
would
suggest
that
we
plan
to
do
more
discussion
on
the
mailing
list,
which
will
now
in
our
next
meeting
and
that
the
next
person
to
reply
change
the
subject.
A
Yeah
yeah
Jonathan
Lennox
is
an
individual
I
was
going
to
say.
I
mean
part
of
the
problem
is
that
ice
Stacks
generally,
the
obvious
implementation
is
to
get
to
abstractly,
provide
a
datagram
API,
and
then
the
ice
ice
stack
figures
out
how
you
get
end
to
end.
A
So
your
suggestion
of
doing
RTP
over
TLS
well
abstractly,
that
would
be
a
cleaner
thing
than
quick
over
TCP,
would
be
would
mean
we
have
to
feed
entirely
different
things
down
into
your
stack,
depending
on
what
the
ice
negotiated,
which
would
be
very
much
a
layer
violation
in
terms
of
having
to
know
what
theri
stack
is
doing.
F
Comment
was
that
I
think
we
may
not
be
thinking
about
this
at
a
high
enough
level,
basically
within
quick,
we
always
have
to
think
about
failover
right
and
and
often
that's
done
at
the
app
layer.
So
as
an
example
in
web
transport,
we
fail
over
from
HTTP
3
to
http
2.
F
and
that
does
have
a
whole
other
series
of
of
issues
with
it,
because,
obviously
you
can't
emulate
quick,
but
I
I
wouldn't
mess
as
as
horse
said,
I
running.
You
know,
multiple
layers
of
congestion,
control,
RTP
congestion,
control
over
quick
congestion
control
over
TCP.
That's
just
going
to
be
a
disaster.
I
wouldn't
even
want
to
imagine
to
analyze
that,
like
bbrv2
over
new
Reno
scream
over
bbrv2
over
new
Reno
thanks.
A
C
B
R
That
explanation,
I
also
want
to
remark
that,
back
in
the
days
when
I
my
my
dim
memory
comes
twice
to
remember
what
I
had
been
what
we
had
been
doing
when
I
was
sharing
a
music
at
the
time,
you
could
tell
ice
what
you
wanted
to
negotiate
right.
So
if
we
have
an
API
abstraction
problem,
that's
a
different
thing
from
being
a
protocol
from
being
a
protocol
and
signaling
problem,
and
we
shouldn't
be
getting
the
letter
in
the
way
of
getting
the
former.
This
other
thing
right.
M
Yes
again,
just
to
reiterate
again
I
as
far
as
I
know,
with
its
currently
limitations
cannot
include
like
a
non-uniform
protocols.
You
cannot
negotiate
between
RTP
over
TLS
and,
like
let's
say,
quick
over
TP
using
ice
partially
because
you
are
sending
media
and
you're
sending
data
from
a
higher
level
protocol
during
the
elimination.
M
So
the
candidates
are
changing
and
your
protocol
can
rewind
transport
protocol
is
changing
while
you
are
sending
media,
so
it
essentially
means
like
figuring
out
the
transition
from
RTP
over
click
to
RTP
over
TLS
and
or
it's
actually
like
switching
between
quick,
handshake
and
RTP
over
TLS
handshake
in
the
middle
of
the
handshake,
and
this
is
just
like
not
something
that
it
is
possible
to
do.
It's
like
it's
designed
to
send
the
same
kind
of
ending
the
same
higher
level
product.
C
C
So
we
were
having
a
conversation
about
what
to
do
with
quick
congestion
control
and
whether
we
need
to
be
able
to
explicitly
ask
an
implementation
or
do
things
and
where
we
were
at
the
last
interim
meeting.
I
guess
was
that
I
was
proposing
to
explore
whether
with
our
RTP
running
over
a
quick,
it
was
a
Frontline
practice
at
the
congestion
control
issues.
C
Now
that
we're
recommending
all
right
now
that
the
draft
will
adopted
has
is
registering
in
alpn
we'll
have
a
quick
implementation
of
the
other
end.
We'll
know
this
is
something
like
rpt,
so
the
proposal
is
that
the
sap
should
carry
arpans
because
that'll
last
long
years
of
multiple
draft
versions
and
experiments
and
things
like
that
and
mix
up
next
slide.
Oh
sorry,
Bernard,
please
Jump
Right,
In.
F
Yeah,
my
my
concern
would
be
you're
now
creating
additional
complexity.
F
You
know,
for
example,
in
in
webrtc
we
don't
negotiate
alpns
within
gtls
right,
so
I
would
I
would
question
why
you
need
to
do
that
at
multiple
places,
because
you'll
then
oh
I
negotiated
this
alpm,
but
I
got
another
one.
You
just
have
to
check
both
of
them,
so
it
just
creates
additional
failure
modes.
F
C
Q
F
C
Right
so
I
I
think
what
you're
talking
about
may
be
that
I
am
getting
a
little
bit
ahead
of
wherever
we
need
to
be
with
this
in
the
in
the
in
the
sdp
address
discussions.
A
C
One,
oh
yeah:
how
did
I
ask
for
quick
feedback
is
new.
We
want
to
allow
implementations
to
as
quick
for
feedback.
This
is
it
in
the
draft.
Well,
yeah.
O
I
I,
don't
I
understand
where
the
LPN
purists
are
coming
from
that
okay
I
just
operate
generic
web
servers
and
I
have
no
idea.
People
connecting
to
them
blindly
are
going
to
get
you
know,
H3
or
H2,
or
something
else
or
or
not,
even
a
HTTP
service.
But
something
else
I
understand
that
aspect,
but
I
think
this
is
very
different
because
you're
talking
about
a
signaling
exchange
before
where
you
know
the
parties
know
what
what
the
service
is.
O
It's,
not
a
blind
client
going
to
a
port
number,
so
I
I,
don't
think
registering
a
bunch
of
alpns
to
describe
very
complex.
Sdps
is
useful.
A
few
months
20
different
things.
I,
don't
think
it's
worth
all
the
permutations
of
alpns
being
registered
to
to
say
that
okay
I
made
most
these
20
different
things.
The
sdp
is
being
explicit
about
what
is
being
connected
to
yeah,
so
I.
Don't
think
the
LPN
really
provides
any
benefit
whatsoever
there
yeah.
C
So
make
two
observations
there.
C
One
is
that
what
I'm
talking
about
is
if
there
are
two
different
versions
of
the
RTP
over
quick
specification
that
you
support,
that
you
would
have
two
different
aopms
for
those,
but
that
you're
not
you
know
that
you're
not
registering
a
bunch
of
alpns,
depending
on
what
the
STP
says.
What
do.
O
You
think
that
if
you
have
different
RTP
over
quick
versions
that
you
also
have
different
STP
for
those
Arts,
pure
quick
versions,
it
seems
like
it
seems
unimaginable
to
me
that
Alpine
is
really
the
way
to
disambiguate
all
this
stuff.
There's
gonna
be
a
boatload
of
STP
way
before
you
hit
the
alpn
I.
C
Believe
you
thank
you
back
to
the
next
slide,
so
basically,
now
that
we're
want
to
allow
optionally,
in
the
current
draft,
substituting
transport
layer,
feedback
for
rtcp
feedback
for
some
for
some
aspects
of
feedback
and
like
I,
say
recognizing
that
we
are
trying
to
reduce
overhead
where
possible
and
that
mapping
may
require
some
creativity.
C
One
of
the
proposals-
that's
in
the
the
prep
that
the
group
has
adopted,
is
that
Quirk
does
not
have
Knack,
but
it
can
interpret.
You
know
it
can
detect
lost
packets,
so
if
it
bounces
that
back
up
as
a
knack
or
an
RTP
implementation
could
know
what
to
do
with
it.
C
My
question
here
is
in
order
to
do
this:
do
while
we're
talking
about
enabling
transport
layer
feedback
as
a
clump,
or
are
we
naming
individual
pieces
of
Transport
feedback?
There's
a
layer
feedback
that
you
want
to
get?
My
proposal
was
to
you
know
to
request
this
as
a
clump,
but
again
this.
This
is
the
first
time
I'm
talking
about
this
with
the
working
group.
So
that's
almost
certainly
needs
more
working
group
discussion
unless
everybody
uses
just
agree
with
me.
F
Yeah
I
think
we're
going
to
need
to
discuss
this
in
more
detail
because,
along
with
I,
think
the
quick
requirements
for
the
transport,
because
you're
going
to
be
negotiating,
you
know
just
as
transport
parameters
a
whole
bunch
of
quick
extensions
and
things
like
that
which
may
impact
your
ability
to
do
things,
and
then,
on
top
of
that,
you
have
the
what
I
think
of
as
the
RTP
negotiation,
where
you're
saying
What
rtcp
mechanisms
you're
using
so
I
I'd,
be
a
little
bit
concerned
about
the
interaction
between
all
that
stuff
and
so
I.
F
Think
we,
you
know
as
an
example.
We
should
be
real
clear
about
what
we
might
not
be
doing
like.
We
might
not.
We
might
be
doing
using
quick
acts,
but
that
might
require
timing
extensions
and
then,
if
we
have
a
whole
bunch
of
stuff,
we
might
be
able
to
not
negotiate
Max.
Just
as
a
weird
example,
so
I
think
we
need
to
dig
into
the
transport
requirements
and
understand
fully
what
we're
like
what
we
need
to
get
rid
of
various
things.
C
I
would
thank
you,
Bernard
I,
would
agree
and
I
would
I
would
observe
that
a
lot
of
the
discussion
that
we've
had
has
been
assuming
that
thatagram
was
an
option
before
that
Graham
was
yeah.
I
think
that
I
think
we
started
talking
about
this
before
data
Graham
was
a
working
group
draft
and
quick
now
that
it's
an
RFC
and
quickest
starting
to
do
other
extensions
that
might
be
relevant
to
us.
C
That's
probably
a
good
thing
for
us
to
keep
in
mind
as
well.
Thank
you.
A
So
I
guess
my
question
is:
are
we
is
it?
Do
we
want
to
try
to
Automall
I
guess
you're
first.
O
Mozinary
one
on
the
previous
topic
for
feedback,
one
one
thing
to
note
from
this
morning's
quick
session.
This
proposal
for
quick
timestamps
to
be
adopted,
I
think
it's
very
relevant
for
RTP
or
media
in
general.
So
I
think.
If
people
here
want
to
support
things
like
the
rtcp
feedback
formats
that
do
have
time
stamps
and
they'd
like
to
carry
those
over
to
quick
I.
Think
I
should
chime
in
on
the
Quick
List
to
say
that
you
support
that
time,
stamp
extension
being
added
to
quick
right.
C
Chris
Christian
equipment,
who
is
the
author
of
The
Ian
quick,
was
asking
if
the
working
group
was
ready
to
adopt
the
time
stamps
draft
and
the
working
group
was
kind
of
sort
of,
maybe
if
I'm
characterizing
them
correctly
and
but
that
I,
you
know
I
did
say
you
know.
Abt
core
is
interested
in
this
for
some
of
the
media.
Real-Time
media
congestion
control
mechanisms
that
use
time
stamps
and
it
may
be.
C
It
may
be
correct
that
amox,
the
mock
stuff
goes
the
same
way,
also
Desiring
to
use
timestamps,
so
yeah.
Well,
Mary's
point
is
well
taken.
I
think
the
chairs
would
be
in
a
quick
would
be
sympathetic
to
people
expressing
that
you
know
views
about
this
and
saying
some
variation
if
we
made
this
for
media
because
we're
using
timestamps
anyway.
C
A
C
Many,
how
many
times,
how
many,
how
many
stacks
are
we
talking
about
here,
but
now
that
we
have
our
own
working
group
drafts?
My
goal
would
be
to
try
to
keep
my
draft
synchronized
with
the
working
group
political
specification
like
within
a
meeting
cycle,
and
so
I
would
like
to
get
my
draft
coordinated
with
the
working
group
draft
new
protocol
specification,
but
the
next
time
we
have
a
ABD
core
meeting.
C
Are
we
having
an
interim
and
whenever
that
is,
and
as
far
as
the
working
group
to
consider
adoption
at
that
point?
Thank.
A
You
all
right,
thank
you.
Okay,
v3c
who's,
presenting
Laurie.
P
Good
I'm
gonna
be
presenting,
so
this
is.
P
Okay,
so
at
least
someone
confirmed
that
they're
hearing
me
so
I'm
going
to
be
presenting
the
progress
on
the
RTP
pilot
format
for
b3c
next
slide,
please.
P
So
just
as
a
brief
background,
we
bro
first
brought
this
topic
to
ADT
core
in
a
virtual
meeting
in
February
this
year
and
since
then,
we've
been
receiving
some
amount
of
feedback
not
much
and
just
as
a
quick
refresher.
So
this
v3c
encoding
is
like
intending
to
reuse,
existing
2D,
video
coding,
Technologies
and
compress
a
volumetric
video
using
that,
and
it
is
in
fact
designed
to
be
video
code
recognostic.
So
you
can
use
pretty
much
any
video
Codec
available.
P
M
P
Is
therefore
also
aligned
with
the
beta
coding
specifications,
so
the
video
components
can
be
streamed
according
to
the
respective
RTD
pellets
specifications.
Again,
you
can
pretty
much
use
whatever
video
Codec
you
want
to
use
and
then
choose
the
corresponding
RFC
for
the
payload
format.
The
issue
is
that
there
currently
is
no
rtb
payload
format
for
this
Atlas
data,
which
is
the
metadata
that
describes
the
reproduction
of
this
video
components
into
the
back
into
the
3D
frame,
and
therefore
we
were
proposing
to
Define
an
encapsulation
for
this
Atlas
null
units
into
RTP
packets.
P
Along
with
that,
we
propose
some
b3c
specific,
specific
payload
format,
parameters
which
operate
just
the
same
way
as
video
coding
payload
from
Target
parameters
too,
then,
in
addition,
there's
a
new
grouping
type
that
we're
proposing
which
allows
you
to
group
multiple
beta
components,
streams
and
Atlas
streams
together
to
indicate
that
these
streams,
media
streams
should
be
consumed
together
and,
lastly,
there's
this
reference
to
bundling,
which
is
using
this
RFC
8843,
which
essentially
allows
you
to
bundle
these
multiple
streams
into
a
single
session
or
single
stream.
P
P
So
we
removed
a
lot
of
the
stuff
that
was
inherited
from
hevc,
RDP
pellet
format
and
then,
for
example,
dropped
the
multi-time
application
package
and
refined
the
payload
format,
parameters
section
and
so
on,
so
essentially
just
cleaned
it
up
a
bit,
and
after
that,
we've
only
received
a
couple
of
minor
improvements,
just
suggestions
mostly
focusing
on
edit
editorial
stuff
and
just
as
a
reminder,
so
we're
managing
this
feedback
on
this
behind
this
GitHub
link
next
slide,
please.
P
So
in
order
to
solicit
more
feedback
and
continue
the
progress,
the
draft,
we
would
like
to
propose
a
working
group
adoption
at
this
point.
P
I
hope
that
is
something
that
we
can
all
agree
to
and
yeah.
Now
any
questions
or
comments.
A
Anybody
Stefan.
N
So
this
isn't
within
this
voice.
I,
can
understand
within
the
scope
of
the
working
group
so
and
it's
specifically
mature,
so
I
have
no
problems
in
adopting
it.
One
other
thing,
and
that
is
Lori.
You
will
soon
run
into
the
same
issue
with
your
green
metadata
people
ran
into
a
few
weeks
ago,
and
that
is
the
public
availability
of
iso.
N
Documents
for
free
and
I
cannot
hold
my
service
there
again
to
distribute
that
you,
you,
Point,
Cloud
people
sent
me
a
late,
pre-ballot
draft
or
pointer
to
it
on
the
MPX
site
and
end
document,
a
November
document
and
people
who
want
to
review
this
ISO
document
deciser
standard
can
contact
me
privately
and
I
will
forward
it
to
those
people.
Thank
you.
Thank.
A
You
Stefan
all
right
so
yeah
I
think
it
sounds,
like
certainly
is
in
scope,
so
I
suspect,
I
think
what
we
should
do
is
we
should
do
a
call
for
adoption
on
the
mailing
list.
This
will
give
you
a
chance
to
also
you
know
the
community.
That's
interested
in
this
can
express
their
interests,
but
it's
certainly
in
scope,
so
I
think
we'll
do
a
call
for
adoption
unless
you
disagree
burner,
but
I
think.
F
A
We
do
yeah
we're
covered
tight
on
time,
all
right,
so
yeah.
Finally,
green
metadata.
Q
Like
to
be
on
time-
and
it's
about
rdcp
messages
from
Green
million
in
the
next
slide,
please
so
this
is
about
the
Epic
specifications.
Can.
Q
Right,
yeah
I
hope
this
works
better.
Now,
oh.
B
Q
So
this
is
about
the
iso
specification
23001-11,
which
is
an
Egyptian
media
consumption.
So
this
is
talking
about
how
encoding
and
decoding
can
be
done
in
a
more
energy
efficient
fashion.
So
this
specification
provides
two
sets
of
metadata
one.
Is
this
video
encoder
generated,
which
is
complexity,
information
being
sent
to
the
decoder
so
that
it
can,
you
know,
adapt
its
decoding,
but
this
these
sets
of
matter
that
I
sent
via
supplemented
SEI
within
the
video
stream.
So
this
is
not
the
focus
of
the
draft
here.
Q
The
focus
of
this
draft
is
a
second
set
of
metadata,
which
is
the
decoder
feedback
messages
so
to
decode
to
send
some
feedback
and
encoder
trials
without
accordingly
the
energy
collection
at
the
decoding
end.
So
we
needed
a
format
for
that
those
messages,
because
there
is
no
rtcp
format
defined
for
this,
and
this
is
the
format
that
is
being
specified
outlined
by
this
draft,
and
the
current
version
is
linked
here.
This
stock
is
providing
two
new
rtcp
messages.
Q
One
is
to
post
push
a
resolution
request
and
the
other
one
is
the
feedback
message
from
the
encoder,
which
is
a
to
post
special
resolution
notification.
Next
slide,
please,
so
the
new
messages
are
specified
in
a
similar
fashion
to
the
payload
specific
feedback
messages
which
are
defined
in
avpf.
So,
as
mentioned,
the
two
new
messages
they
are,
they
can
be
sent
as
a
full
compound
rdcp
packet
or
an
early
rtcp
packet.
Q
The
reason
being
is
that
these
messages
are
not
very
time
critical,
so
you
can
send
them
as
early
rtpcp
messages
if
the
application
so
reads,
but
this
is
not
required
and
then
the
main
idea
is
that
the
first
message
on
the
top-
this
is
what
the
decoder
sends
towards
encoder
when
it
wants
the
encoded
to
adapt
the
energy,
the
the
the
decoder
industry,
consumption-
and
this
is
done
via
this
typical
message-
format
ssrc
is
equals
number
and
then
obviously,
these
are
the
key
elements
here
frame
rate
picture
height,
which
is
the
request
that
the
decoder
is
sending
okay,
please
adopt
to
this
new
resume
function
or
frame
rate,
and
then,
as
these
messages
go,
there
is
a
feedback
message
from
the
encoder
back
to
the
decoder.
Q
It
has
similar
information
Fields
here,
but
the
reason
of
these
information
Fields
is
that
the
encoder
might
be
trying
to
adopt
from
multiple
decoders,
so
it
might
have
a
different
decision
to
do
so.
It
informs
the
decoder
hey.
This
is
what
I
thought
I've
done
with
your
request.
So
next
slide,
please
some
comments
about
timing
and
security.
So,
as
mentioned
before,
the
encoder
might
be
catering
for
multiple
decoders.
So
if
there
are
multiple
messages
coming
in,
then
the
encoder
needs
to
decide.
Q
You
know
joint
need
of
optimization,
so
one
decoder
saying
that
another
one
saying
that
so
then
code
has
to
make
a
decision,
as
mentioned
before,
advances
are
not
time
critical,
so
their
Center
is
a
regular
rtcp
timing.
Some
security
considerations
have
been
documented
in
this
draft,
which
is,
if
the
message
is
approved
or
there's
a
malicious
message:
it
might.
The
decoder
might
request
the
maliciousness
message
might
request
a
extremely
low
value,
quality
or
I
mean
we
just
recently
got
thinking.
Q
It
could
be
a
request
for
extremely
high
video
quality
that
the
whole
decoding
can
install.
So,
yes,
some
integrated,
Integrity
production
authentication
is
required.
That
can
be
done
in
a
very
simple
fashion
to
avpf
as
using
srtp
or.
C
Q
A
vpf
next
slide,
please
yeah,
so
that's
the
last
slide
that
I
have
so
that's
the
purpose
to
gather
feedback.
We
already
have
some
feedback
comments
from
Jonathan
that
we
mostly
acknowledge-
and
we
are
already
working
on
the
draft
to
to
implement
that
the
the
target
is
to
have
no
reflected
discussion
and
then
incorporate
this
feedback
and
eventually,
when
the
time
comes,
seek
for
an
adoption.
Yes
sure
George.
R
Here's
your
code,
I,
have
one
quick
question:
RTC
pick.
Rtcp
messages
aren't
reliable.
So
are
you?
Are
you
sending
this
as
kind
of
soft
state
that
you
keep
repeating
what
you
expect
continuously,
since
he
has
transaction
right?
The
receiver
sends
something
the
decoder
sends
a
wish
to
the
encoder.
The
encoder
at
some
point
would
respond.
R
How
does
the
decoder
know
that
the
encoder
ever
got
what
it
was
sending
so
since
there
is
no
acknowledgment
in
rtcp,
do
you
repeat
this
on
a
constant
basis
until
things
get
better
or
I
didn't
find
anything
in
the
draft
when
I
was
quickly
grabbing
through
it?
So.
Q
But
I
might
have
missed
stuff
yeah,
so
these
messages
are
working
in
a
very
similar
way,
as
the
typical
special
trade-off
request
message
in
avpf,
almost
identical
fashion.
So
the
decoder
sends
a
message
with
the
specific
sequence
member.
The
encoder
is
supposed
to
reply
to
that
sequence.
Number.
So
that's
how
the
decoder
finds
out
that
for
a
given
ssrc
for
a
specific
sequence
number,
it
got
the
message.
The
The
Encore
got
the
message
all.
A
Right
yeah,
like
some
questions
as
an
individual.
First
thanks
to
Stefan
when
he
sent
me,
the
the
ISO
document,
I
see
that
there's
actually
four
different
feedback
mechanisms
in
that
document.
That
you're
only
doing
one
at
this
point
is
that
all
you're
intending
to
do,
or
is
this
just
your
starting
point
and
you're
planning
to
do
some
of
the
others
as
well
yeah.
Q
I
think
we
picked
the
most
important
thing
that
we
found
at
this
point
in
time.
It
could
be
based
on
feedback
if
I
think
there
are
more
messages.
A
Okay,
I
mean,
if
that's
I
mean
if
you
think
this
is
the
one
that's
the
most
important.
That
seems
reasonable.
I
just
wanted
to
see
if
what
your
plans
were
going
forward
and
then
the
other
is
I.
There
are
some
mechanisms,
I'm
not
sure.
I
I
seem
to
recall
at
the
sdp
level,
to
specify
things
like
frame
rate
and
resolution
to
negotiate
that
at
the
signaling
level
and
I
want
to
know
is
this:
to
what
extent
is
this
complementary
to
that
versus
overlapping?
It.
Q
A
A
Check
that
out,
okay,
okay,
thank
you,
yeah,
okay,
and
if
that
yeah
so
you're,
not
you're,
not
asking
for
adoption.
Yet
you
want
to
do
some
more
provisions
and
then.
Q
A
Thank
you
all
right,
great
well,
I
think
that
then
wraps
us
up
unless
anybody
has
any
other
business
in
the
one
minute
we
have
left.
Otherwise.
Thank
you
all
we'll
discuss
whether
we
need
an
interim
we've
been
doing
interims
fairly
successfully
lately,
but
once
per
cycle.
So
we
may
do
that
again,
depending
on
how
things
are
progressing.
Otherwise,
we'll
see
you
all
on
Monday.
Thank
you
all
very
much.