►
From YouTube: IETF101-PAYLOAD-20180322-1330
Description
PAYLOAD meeting session at IETF101
2018/03/22 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
B
B
B
Okay,
so,
but
you've
seen
you
before
in
the
in
the
previous
session
AVT
the
agenda,
the
status
update,
the
plate,
payload
format
for
flexible
fact,
vp9,
a
TS
v,
TS
v,
CIS,
codec,
tetra,
audio
codec
and
we'll
end
like
our.
Hopefully,
since
the
last
meeting,
we
had
the
RFC
8
3
21,
which
is
the
ancillary
payload
published,
and
we
have
in
a
devaluation.
We
see
2h
high
quality
in
a
devaluation.
B
The
current
document
status
no
other
documents,
because,
basically,
all
the
documents
would
be
presented
because
we
have
two
documents
which
are
no
comments
and
two
documents
here
that
our
individual
drop
the
card
milestones
for
the
two
visual
drafts.
So
we
have
our
knots
to
the
payload.
Sorry
for
the
for
the
working
group
to
submit
the
I
mean
the
fact
we
would
like
to
finish
it
as
soon
as
possible.
It's
a
in
the
list
of
document
that
for
RTC
web.
B
B
B
B
C
No
changes
in
the
packet
formats,
no
changes
in
the
operations
that
are
that
are
done
on
either
arm
encoding
or
decoding
sides,
but
a
significant
amount
of
churn
in
the
text
itself.
So
when
you
diff
in
here
I'm
noting
gifts
from
oh
seven
205,
because
there
were
actually
two
changes
to
versions
of
since
lost
ITF,
and
when
you
do
that
diff,
it's
pretty
big.
So
don't
don't
let
that
scare
you
into
thinking
that
we've
made
a
lot
of
substantive
changes,
hopefully
just
a
lot
of
things
that
are
going
to
make
it
easier
for
implementers
they're.
C
So
quick
next
slide,
so
summary
of,
what's
changed,
there's
a
lot
of
general
nomenclature
that
was
imported
from
RFC,
60,
63
or
63
before,
and
it
doesn't
really
gel
well
with
the
RTP
based
mechanisms
that
were
describing
here.
So
we
basically
just
replaced
all
of
the
all
of
the
generic
words
that
you
know
flow
and
symbol,
and
things
like
that
from
60
feet
from
6363,
which
is
not
just
RTP.
It
applies
to
a
lot
of
other
transports
and
application
of
reporter
goals,
so
we
replace
those
with
with
RTP
centric
terms
from
taxonomy.
C
Hopefully
that
will
make
it
clearer
for
someone
who's,
just
the
North
Sea
Island
and
in
the
abstract
people
were
several
people
mentioned
that
they
didn't
realize
that
this
allows
multi
multi
stream
protection
until
pretty
deep
in
the
document.
That
should
be
upfront.
So
we
added
in
the
abstract
that
a
single
FET
packet
can
actually
protect
multiple
source,
RTP
streams
mm-hmm,
and
there
was
some
lingering
comments
about
extensibility
to
other
effect
codes
beyond
XOR.
That
was
from
earlier
versions
the
draft
where
we
were
expecting
extensibility
to
read,
Solomon
and
Raptor
and
other
other
codes.
C
That
was
rejected
because
of
IPR
clarity,
so
he
can
follow
up
your
declarations
on
specific
drafts
and
not
sections
of
drafts.
So
all
those
extensibility
features
have
been
removed,
so
flux
effect
is
not
that
flexible
and
anymore,
but
there
were
some
things
lingering
that
still
mentioned
it.
So
we
moved
all
those.
C
Then
the
introduction
was
pretty
long,
it's
several
sections
long,
but
it
was
confusing
for
some
readers
to
understand
the
differences
between
the
different
schemes
that
were
being
outlined,
and
so
we
made
separate
sections
that
clearly
show
all
the
different
schemes,
the
one
dean
under
leaved
or
Ofek,
the
interleaved
column
feck
and
the
combination
of
2d
row
and
complex
schemes.
Hopefully
that's
clear
to
readers
now
and
implementers
will
be
confused
next
slide.
C
And
then
Stephen
asked
for
definitions
and
we
agreed
that
it
was
probably
a
better
to
have
all
this
upfront
in
the
document
mm-hmm.
So
we
added
most
notable
definitions
about
row
and
column
feck
and
about
what
to
defect
is
and
then
places
where
source
block
in
fact
block
were
used.
They
they
were
also
used
in
6363
undefined,
so
we
made
sure
we
defined
him
here
and
the
repair
window.
C
That's
actually
one
of
the
parameters
of
ESD
negotiation
made
clear
what
the
repair
window
were
first
to
and
then
finally,
what
X
or
of
parity
codes
our
next
slide
and
then
in
the
packet
formats.
That
was
a
also
some
confusion
here.
So
we
wanted
to
coolly
separate
out
what
is
an
RTP
header
and
what
is
effect,
header
and
clearly
separate
out
what
are
the
source
packet
formats
and
what
are
the
effect
where
pair
packet
formats,
there
was
confusion
around
what
does
the
RTP
header
of
the
source
packet
look
like
and
are
there
any
restrictions?
C
So
we
clarified
that
basically,
the
full
RTP
packet
can
be
recovered,
except
the
version
has
to
be
version
2.
That's
the
only
restriction
that
the
spec
scheme
imposes.
Everything
else
is
is
standard
RTP.
You
can
protect
any
kind
of
RT
packet
with
extensions
with
padding
with
its
own
c.src
list
and
count
none
of
those
have
any
restrictions
or
bindings
to
the
to
the
fact
packets.
Now
for
the
fact
packets
RTP
header
there
was,
there
was
lack
of
clarity
about
what
exactly
all
those
fields
mean
in
the
in
the
in
effect
packets,
RTP
headers.
C
So
we
clarified
that
the
CC
and
c.src
are
explicitly
used
and
they
bind
to
the
source
streams.
So
the
c.src
of
the
fact
packets
points
to
the
SSRC
of
the
source,
packets,
so
they're
like
the
source
packets,
you
can
think
of
them
as
contributing
sources
of
the
fact
payload
and
the
extension
and
and
padding
of
defect
packets
are
independent
of
the
extension
of
padding
of
the
source
RTP
packets.
C
The
the
other
main
area
of
confusion
was
in
the
feck
header,
so
after
the
RTP
header
I'm
inside
of
the
feck
header,
there
is
also
variants
of
that
fact
header
and
it
wasn't
clear
what
all
those
variants
were
and
when
they
apply
to
when
they
don't
so.
We
broke
that
out
clearly
into
three
separate
sections
for
the
case
where
you
have
the
retransmits
zero
and
the
flexible
bit
zero.
That
means
there's
a
mask
a
bit
mask
that
signals
what
the
source
packet
numbers
are.
C
So
you
have
the
base
sequence
number,
plus
a
bit
mask
of
all
the
higher
sequence
numbers
that
were
used
to
generate
this
effect
packet
and
then
the
second
variant
is
when
you
have
R
equals
zero.
So
not
a
retransmission,
but
F
equals
one,
meaning
that,
rather
than
having
a
bit
mask,
there
is
a
fixed
pattern
block
the
there's,
a
fixed
2d
block
pattern
for
for
the
source
symbols,
and
there
M&N
give
you
the
row
and
column
dimensions
of
that
block.
C
And
then
you
map
the
the
sequence
numbers
of
the
source,
packets
based
on
that
row
and
column
level,
and
then
the
third
format
is
a
retransmission
format
when
R
equals
one
F
can
be
0
or
1,
and
that's
just
an
optimization
to
allow
people
to
do
retransmission
without
using
the
re,
80,
X,
40,
588
format,
and
that's
the
majority
of
the
changes
next
slide.
I
think
that's
it.
D
Boba,
so
what
we
have
been
involved
in
an
implementation
and
a
thing
that's
actually
turned
out
to
be
most
confusing,
doesn't
relate
to
most
of
the
document
at
all.
It
relates
to
the
kind
of
SDP
negotiation
that
goes
on
in
a
number
of
weird
scenarios
like
people
offering
both
like
r-tx
and
and
this
stuff,
and
being
real
clear
about.
What's
mandatory
to
implement
and
not
like
my
assumption
and
reading
a
document,
was
you
kind
of
have
to
support
retransmission?
D
D
Yeah
I
mean
when
you're,
offering
it
or
answering
it.
It
is.
The
assumption
is
when
you
say
you
support
this,
that
you're
supporting
the
retransmission
and
so
like
as
an
example
when
someone
offers
are
like
somebody
might
offer
r-tx
in
this.
They
don't
know
what
the
other
side
does
right.
So
you'd
want
to
offer
both
of
them,
and
then
that
can
a
little
bit
of
the
confusion
is.
If
somebody
answers
you
like
what
are
the
answers
mean
like
if
it's
only
r-tx,
it
means
okay,
I
only
do
forty
five.
D
E
Right
so
I
mean
I
mean
my
inclination
would
be
the
standard.
Operetta
semantics
is,
if
you
list
Flex
facts
before
RDX
in
your
codec
list,
immunity
prefer
it.
If
you
guys
are
the
experts
we'd
prefer
that,
but
I
think
that's
just
I
would
think
that
would
be
standard
now,
of
course,
the
tricky
thing
is
that
you
know
the
point
of
using
flex
back.
Is
that
you
know
you
don't
need
to
go
through
some
of
the
convolutions
about
you
know
binding
retransmission
sources
to
primary
sources.
D
Yeah
and
also
yeah
I
guess
the
other
thing
which
is
maybe
just
my
own
confusion,
is
just
the.
There
are
only
three
STP
parameters
defined
right
now
and
so
I've
had
questions
about
whether
those
are
the
only
you
know.
Those
are
the
only
three
you
need
to
kind
of
define
it
or
not,
and
and
whether
there's
other
kind
of
non
negotiated
settings
that
one
would
normally
have
in
and
a
limitation
to
change
things,
but.
C
E
C
So
so
from
all
that,
I
think
we
can
for
the
notes.
We
can
make
one
update
to
clearly
spell
out
that
all
three
of
these
variants,
including
the
retransmission,
are
always
mandatory
to
support
receiving
by
anyone
implements
the
spec
any
interplay
with
old
forty
five.
Eighty
eight,
we
can
add
up
one
or
two
sentence,
things
saying
that
you
know
you
know.
Regular
STP
and
RTP
mechanisms
still
apply.
A
minor
preference
still
applies
things
like
that.
There
should
be
easy
enough.
D
The
receive
stuff
makes
sense,
I.
Guess
it's
a
little
bit
confusing,
because
if
I
offer
both
does
the
answer
assume
that
I
can
like
he's
going
to
come
back
with
something
right
say,
puts
ice,
offer
all
r-tx
and
black
focus
and
he
comes
back
and
says
he
wants
to
do
flex
back,
oh
and
doesn't
put
in
the
art.
Yes
does
that
mean,
but
he
would
this
that
he
does.
D
He
can
the
answer
always
assume
that
it's
it's
mandatory
for
the
sender
to
support
retransmission
as
well,
because
he's
got
to
answer
something
because
basically
does
he
have
to
put
both
like
he'll
put
flex
like
an
RT
X,
because
he
doesn't
know
whether
I'm
gonna
send
RT
X
or
something
and
then
I'll
I'll.
Take
that
and
basically,
if
I
do
I
do
reach
in.
If
I
want
to
do
retransmission
as
a
sender,
I'll
then
do
it
or.
E
I
mean
if
you're
talking
about
an
RT
X
file
mechanism,
I
mean
the
other
half
of
that
is.
Do
you
also
have
to
negotiate
that
you
support
the
Mac
or
just
via
feedback
so
but
I?
Think
if
you
have
you
have
both
artists
to
be
feedback
I
would
my
expectation
would
be
you
can
support
both
flex
back
and
na
cards
me
feedback?
Then
you
expect
to
do
nak.
That
is
an
implicit
expectation,
and
maybe
we
need
to
make
this
more
explicit
somewhere.
C
E
E
B
A
C
B
But
since
if
the
receiver
ones
also
is
to
support
out
the
X,
he
cannot
force
it
to
be
part.
As
a
hearing,
the
signaling
that
RT
X
will
be
supported
by
the
sender
because
he
said
said
dissenters,
it's
an
optional
for
him
to
send
the
RT
X.
So
if
he
would
not
want
to
have
RT
X,
then
the
only
way
for
to
do
it
is
only
if
he
offers
to
receive
our
text
separately.
Also,
unless
you
have
something
that
will
make
the.
In
this
case,
the
sender
send
out
the
X.
D
I
agree
with
what
you
just
said:
no
the
boat
thing
we
want
to
be
most
clear
about.
Is
what
do
you?
What
do
you
do
in
negotiation?
If
you
don't
want
to
have
any
r-tx
you
just
both
sides
would
rather
do
flex
back
I'm,
assuming
they
they
both
just
like
and
put
it
in
flex.
The
answer
would
remove
the
re,
TX
pillow
type
right,
so
he
you
would
offer
r-tx
og.
D
E
B
C
What
I
thought
I
heard
was
what
I
thought
I
heard
was
people
want
to
negotiate
offer
both
are
ATX
and
flex
back,
but
answer
with
only
flex
effect
in
order
to
deprecate
RI
TX
if
both
are
supported,
but
I
don't
know
if
we
want
to,
we
definitely
don't
to
make
that
a
must.
We
definitely
don't
want
to
say
that
there
that
you
implementations
have
to
do
that.
Maybe
we
could
make
it
a
shirt
in
the
document
that
you
know,
implementations,
okay,
so
so.
B
B
E
You
know
image
at
different
resolutions
or
what-have-you
and
then
for
our
patterns
of
the
temporal
scalability.
We
had
call
it
a
group
of
frames.
What
is
actually
these?
The
things
that
were
being
grouped
were
actually
pictures,
but
group
of
pictures
means
something
else
in
video
coding,
so
we
called
it
a
picture
group
instead.
This
is
not
the
greatest
terminology
and
suggestions
for
something
better
would
be
welcome,
but
we
couldn't
think
of
anything
so
and
there's
a
note
in
there
saying.
No,
a
picture
group
was
about
the
same
thing
as
a
group
of
pictures.
E
This
person,
the
drafts,
are
also
added
some
explanations
of
how
to
use
bp9
for
scalability,
both
in
terms
of
like
what
you
know,
Flags.
You
have
to
turn
on
and
off
for
each
frame
and
also
how
you
structure
the
use
of
the
reference
buffers
to
get
both
temporal
and
spatial
scalability.
For
you
know
three
to
three
spatial
using
the
eight
reference
buffers.
F
It's
different,
you
know,
Jonathan,
please
make
sure
that
they
I
mean.
It
would
probably
be
a
really
good
idea
to
for
the
terminology
to
keep
it
aligned
with
what
you
plant
at
U
is
an
AV
one
yeah,
because
or
go
back
and
use
what
everyone
else
is
using
things
like
XS
unit
right
instead
of
super
frame.
E
F
E
G
E
The
lrr
format
is
now
aligned
with
the
actual
lrr
draft,
which
is
fast,
but
there's
less
call
alright
and
then
five
thanks
to
tempt
area
for
the
review.
This
defined
the
behavior.
The
main
changes
to
define
the
behavior
for
frames
that
have
a
visited
the
frames
with
show
frame
equals
false.
You
know
sometimes
called
all
graph
similarly
used
for
the
equivalent
of
B
frames.
E
It
doesn't
work
quite
the
same
way,
I
think
for
mostly
for
working
around
IPR
reasons,
but
basically
these
are
pictures
that
are
our
frames
that
are
never
meant
to
actually
be
displayed
at
the
time.
They're
encoded,
they're,
usually
displayed
later
with
a
very
small,
show
the
reference
buffer
thing
at
the
pants
that
to
be
decoded.
So
the
thing
that
you
specify
here
is
that
these
get
there.
You
know
these
get
their
own
picture
ID.
E
We
wanted
those
to
be,
you
know
listed
separately,
so
it's
so
that
you
can
do
the
scalability
properly
and
the
luck-
and
this
then
makes
a
question
because
these
are
never
actually
should
displayed.
What
they're
are
keeping
timestamp
should
be
is
a
little
ambiguous.
So
I
basically
said
you
know,
do
something
vaguely
sensible,
but
it
doesn't
actually
matter
that
much.
So
basically,
it
began
a
particular
because
container
formats,
they'll
be
part
of
the
same.
Super
frame
and
timestamps
are
assigned
the
super
frames.
E
I
say
this
can
be
the
time
step
may
be
the
same
as
the
subsequent
display
frame.
So
the
open
issues,
the
offer
answer,
needs
thought
and
review
slice
loss.
Indication
usage
needs
specification.
If
anybody
cares
much
or
anybody's
still
doing
slice
loss
indication-
and
we
need
a
whole
lot
of
descriptive
text
for
vp9,
because
right
now
the
actual
descriptions
of
the
codec
proper
are
basically
missing.
E
We
also
need
a
whole
lot
of
data
Carl
work,
because
the
documents
kind
of
a
mess
and
also
reviews
from
more
people
than
just
Tim
would
be
nice
thanks
to
Tim,
Tim
reviews
have
been
great
and
I
mean
more.
Who
is
from
Tim
would
be
good
great,
but
you
know
this
has
been
implemented.
You
know
we're.
Actually
you
know
this
is
actually
shipping
in
chrome
without
a
flag,
so
it'd
be
good.
If
we're
you
know
the
document
describing
what
chrome
is
doing.
Actually,
you
know
were
published
so
I'd
love.
B
E
B
B
E
B
E
E
E
Okay
Tim
says
the
draft
is
in
much
better
shape
and
move
up.
You
lot
easier
now
and
so
yeah.
If
Tim
we're
able
to
contribute
text
for
the
descriptive
things
about
people,
nine
that
would
be
awesome
or
otherwise.
I
can
try
to
wake
up
my
co-authors
to
get
some,
maybe
get
some
of
them
to
do
it
or
something
but
cool.
A
A
E
Be
good,
okay
and
so
other
than
that,
like
I,
said
any
reviews,
but
you
know
all
reviews
are
welcome
and
or
anything,
and
so
because
I
would
like
to
get
this.
Like
I
said
it
says
this
isn't
shipping.
This
is
in.
You
know
this
isn't
you
know,
however,
many
crumb
brothers
are
out
there,
which
is
quite
a
lot,
so
it
would
be
good
if
we
actually
documented
what
I
should
work.
Okay.
E
H
H
It's
based
on
the
melt
speech
coder,
which
is
the
previous
draft
that
we
had
been
involved
in
in
providing
and
shepherding
towards
an
RFC
and
as
such,
as
basically
extends
the
information,
that's
in
milk
and
replaces
it
with
additional
LSF
parameters,
light
spectral
frequency
parameters
and
that's
packed,
there's
a
certain
number
of
them
that
you
can
use.
You
can
actually
use
kind
of
a
variable
number
of
those.
H
So
the
speech
the
the
RTP
payload
format
allows
for
that
to
be
done.
The
proposal,
the
proposed
format
that
we
have
allows
for
the
contents
to
be
stripped
or
reduced
in
complexity
as
as
is
being
transmitted
or
used
by
various
devices
or
conferencing
stations
or
conferencing
devices
and
and
other
endpoints.
H
So
this
has
been
submitted
last
October
when
redeemed
a
bit
out-of-band
so
far,
there's
no
significant
text
changes
I
have
disgusted
with
a
couple
of
other
these
see
if
I
can
get
them
to
publicly
announce
since
the
port
it'll
take
a
little
bit
of
time.
For
that
to
happen,
we
like
to
promote.
It
was
nineteen
draft,
because
they
would
help
ensure
that
it's
a
belt
Melfi
compatible
RTP
payload
that
gets
used
for
this.
So
and
that's
what
we're
asking
for
this
group
is
to
have
an
adapt
by
the
IETF.
B
Okay,
so,
as
you
can
see,
this
is
this:
is
an
RTP
payload
for
voice
codec.
This
is
in
scope
with
with
the
charter
of
the
world
group
to
do
RTP,
payload,
so
I
suggest.
We
would
like
to
ask
if
there's
we
should
accept
this
as
a
to
support
to
have
support
for
the
TSV
acis
codec
pay.
Rtp
payload
is
a
work
item
for
the
milestone
in
the
Charter,
for
the
working
group
and
to
the
other
thing
is
to
accept
this
document
as
the
documents
to
a
fulfill.
B
B
H
B
I
I
It
comes
with
20
bytes
payload
on
30
millisecond
packet
size
and
what
it
was
60
millisecond
pickup
services,
it's
quite
similar
to
to
the
ones
which
are
already
specified
by
RFC
3551
Sochi,
taught
723
dot,
1
G
dot
729
so
on,
and
that
just
compared
about
computation
complexity,
which
is
the
size
of
the
Vols,
most
values
and
an
IP
data
rate.
So
one
could
ask:
why
should
we
strive
to
standardize
worse,
MOS
value
with
higher
computation
complexity?
F
I
In
charge
on
the
ear
interface,
where
it's,
the
only
standardised,
codec
type
to
be
used,
and
if
we
think
about
there
is
an
example,
creating
a
lien,
for
example,
continuously
using
up
to
800
data
talk
groups
where
they
permanently
do
voice
recording
for
their
legal
evidences,
and
for
them
it
totally
matters
whether
you
you
have
to
deal
with
a
60
megabit
per
second
off
of
quality
of
service,
IP
bandwidth
or
whether
you
can
reduce
it
to
smaller
than
nine
megabit
per.
Second.
G
I
Critically,
communicate
the
critical
communications
Association,
a
body
instan
ciated
by
the
80.
It
was
the
format
data
critical
communications.
Association
is
already
working
on
the
successor
of
tetra,
which
will
be
4G
LTE
paced.
It's
called
mission-critical
PTT
application,
sip
RTB
based,
and
we
expect
that
renewal
cycle.
So
we
know
that
renewal,
sarkis
of
such
infrastructure
investments,
typically
last
very
very
long.
I
So
we
assume
there
will
be
a
migration
phase
from
date
or
two
mission-critical
PTT,
which
will
last
at
least
till
2025
or
maybe
even
longer,
and
for
this
period
of
time
it
totally
makes
sense
to
have
this
data
codec
standardized
as
RTP
payload
as
mission-critical
PDT,
is
using
sip
RTP
for
its
voice
communication.
So
I
have
only
invite
you
to
to
do
a
review
on
that.
Rafter
have
proposed
and
asked
for
adopting
this
draft
by
the
working
group.
B
Okay,
so
again,
this
is
this:
is
an
individual
draft
I'm,
not
sure
if
anybody
else
read
it,
I
read
I,
said
comment
and
about
it
and
we'll
have
a
revision
also
about
this
during
registration.
So
the
question
here
is
about
against,
like
the
previous
one.
This
is
again
an
RTP
payload,
it's
coming
from
body
in
Germany
and
it's
hidden
charter
of
our
work.
B
So
we
would
like
to
do
to
get
it
as
a
milestone
in
adopted
document
is
the
working
document,
since
we
can't
and
again
since
we
currently
have
only
two
documents
is
working
with
documents,
and
hopefully
we
are
going
to
finish
at
least
the
fact
is
the
highest
priority.
We
don't
have
much
burden
on
the
working
group,
so
we
don't
have.
Our
new
is
accepting
to
document
to
don't
need
payload
for
our
work,
guess
for
mercenary.
C
I
Over
RTP
is
not
yet
in
widespread
use.
It's
just
a
draft
in
in
this
registered
association,
we
published
a
standard
which
just
has
informal
character,
but
no
normative
meaning,
and
we
want
to
spread
it
of
course,
and
we
assume
that,
due
to
mission-critical
PTT
over
LTE,
it
will
become
more
of
interest.
The.
I
G
B
G
B
Thank
you.
Okay,
so
I'll
again,
I'll
sent
to
the
least
a
question
about
accepting
this
work
and
we
look
into
the
congestion
on
the
adjuster
I
said
the
comment
of
rejection.
I
didn't
put
your
I
didn't
put
the
circuit
breaker
in
that,
so
we'll
look
at
that.
Okay,
any
other!
Okay!
So
thank
you.
So
this
is
the
last
presentation
for
payload
and
the
other
issues
that
say:
okay,.
F
B
We
said
I
don't
affect
on
fact
what
they
said.
I
would
start
to
recoup
last
call
and
one.
The
comment
we
had
here
will
be
addressed
as
the
working
class
called
comment.
That's
that's!
Okay!
That's
that's
in
the
do
not
already
okay.
So
now
we
finished
with
paler
than
the
last
section
of
the
of
the
session
today
will
be
the
XR
block
one.