►
From YouTube: IETF102-AVTCORE-20180716-1550
Description
AVTCORE meeting session at IETF102
2018/07/16 1550
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
B
C
A
A
A
Do
we
have
anybody
other
than
me
in
the
driver
room
I
doubt
that's
gonna
be,
but
we
do
have
two
more
row
participants,
so
we
but
I
mean
so
they're
more
participants.
If
you
want
to
speak
to
the
room-
and
you
can
use
the
remote
cue,
but
if
not
I
can
keep
an
eye
on
the
room,
but
it'd
be
good.
If
you
had
somebody
else
in
the
GABA
room
just
to
relay,
if
necessary,
I'll.
A
So
Colin
well
Colin
will
keep
an
eye
on
that.
So
I
think
that's
all
the
opening
administrivia.
So,
let's
see
no
well
I
think
this
is
the
wrong
note.
Well
as
where
the
users
business
they're
supposed
to
be
new
one
now
I.
Never
remember,
okay!
Well,
pretend
this
is
the
new
not
well
and
note
it
well,
and
if
you
have
any
IPR,
you
figure
out
what
to
do
and
do
the
right
thing.
Please.
A
A
Last
time
we
had
some
discussion.
We
were
going
to
do
a
comma
list,
see
if
anybody
still
cared,
who
cared
so
little,
that
we
didn't
do
the
call
on
the
list,
which
it
probably
tells
us
something
so
I,
don't
remember
what
I
I
think
remember
what
we
agreed.
What
the
decision
was
last
time
but
multipath
RTP.
Are
we
going
to
see
if
anybody
cares
and
if
not
remove
it
as
a
mouse
done?
Okay?
A
A
Okay,
okay,
good
and
Rachel
said:
she'll
actually
do
it,
which
is
good
cuz.
She
remembers
to
do
things
with
me
and
then
frame
marking.
We
had
a
working
group
last
call
and
there
were
a
number
of
comments
and
then
there
was
no
new
revision,
which
seems
unfortunate
or
any
of
the
authors
of
that
here,
Mo's,
not
here
our
Mo's
on
the
Medeco
mode.
You
want
to
talk
about
what
the
status
of
remarking
is.
Here's
all
excellent.
A
F
G
F
Still
some
questions
about
the
types
of
streams
that
that
the
frame
marking
is
useful
for,
and
some
people
are
now
questioning,
whether
or
not
the
restrictions
we
put
in
place
are
really
okay
to
handle
real
streams
that
people
plan
to
use.
To
recap:
there's
a
restriction
of
it
must
be
terribly
nested
streams.
That's
the
only
thing
that
frame
marking
is
recommended
for
some
people
are
wondering
whether
or
not
that's
actually
too
restrictive,
so
we're
trying
to
figure
out
if
there's
ways
to
relax
and
those
and
get
the
updates
in.
A
F
A
H
C
Question
I
had
more
was
more
because
I
got
the
same
question
in
my
draft
about
how
do
you
know
how
how
much
bandwidth
is
used
in
each
of
the
layers
in
order?
If
you
want
to
discard-
and
you
want
to
achieve
a
certain
bandwidth,
so
it
was
asked
from
me
about
the
priorities,
but
I
figure
out
it's
the
same
issue.
Also,
if
you
want
to
discard
some
layers,
because
you
have
a
bandwidth,
restriction
or
congestion,
how
do
you
know
what
is
the
bandwidth
of
each
of
the
layer?
C
Because
at
least
I
wrote
in
the
document
that
I
think
I
talked
to
any
other?
We
do.
It
is
basically
we
do
it
based
on
some
knowledge
from
the
past.
We
just
try
to
figure
out
what's
being
happening
in
the
in
the
streams
and
figure
out.
What's
the
each
priority,
what's
the
bandwidth
of
each
priority,
I
think
that's
probably
similar
here.
It's
just
sub
simple
heuristics
about.
C
Just
some
informative
text
that
says
that
that
you
can
figure
out
if
you
want
to,
if
you
want
to
get
too
specific,
then
weights,
so
you
want
to
know
what's
each
layer
what
Ben
widgets
is
using.
You
can
figure
it
out
based
on
some
past
knowledge,
or
some
other
means
that
you
don't
need
to
I,
don't
know
if
you
need
to
specify
that
even
it's
just
I
think
it's
very
trivial.
Okay,
from
my
perspective,
it's
nothing
that
it's
a
you
can
figure
out
how
to
do
that.
A
Yeah
I
mean
it's
I,
think
sort
of
the
the
the
dual
of
that
is
that
there's
no
promises
about
either
the
discount
the
fraction
packet,
that
of
this
card
bid
or
the
fact
of
the
packet
that
at
any
given
layer,
information,
it's
just
you
have
to
figure
it
out
by
watching
the
screen.
Yeah
everything's
estimate,
there's
no,
there's
no
way
that
you
can
say
upfront
what
anything
needs
other
than
just
they
exist
and
have
these
relationships,
but
not
their
relative.
Bandits
no.
E
E
E
Proper
I
mean
if
you're
gonna
be
dropping
things
you,
you
presumably
need
to
know
the
statistics
of
your.
How
often
things
with
particular
markings
occur
to
just
like
what
to
drop
and
and
I
mean
yes,
I
suppose
in
theory,
you
could
observe
the
stream
and
estimate
that,
but
that
Rick
that
relies
on
the
stream
being
long
lived
and
the
problems
only
occurring
after
the
stream
has
been
long
enough
lived
for
you
to
make
a
good
estimate
of
the
data
and
you
having
enough
state
to
be
able
to
do
that.
C
I
was
just
mark
just
when
I
sent
the
email.
I
said
that
I
think
the
same
issue
rise
is
equivalent
to.
If
you
want
to
know
when,
when
you
have
differently,
if
you
have
different
in
different
layer
which
how
much
is
used
in
each
layer
in
order
to
figure
out
what,
if
you
want
to
drop
to
a
specific
to
specific
people,
that's
all
it's
the
same
problem.
What
I'm
saying
the
same
problem.
A
A
Think
that
that's
sort
of
a
fundamental
assumption
of
this
approach
that
it
just
says
here,
are
the
layers
and
how
they're
behaving
we're
not
telling
you
anything
about
that
that
just
they
exist,
and
we
want
to
have
you
a
description
of
layers,
then
we
need
to
have
so
either
some
additional
spec
or
an
alternative
spec
to
describe
that
and
I
mean.
Apparently,
people
think
that
this
as
it
exists,
is
sufficient
for
some
of
their
use
cases.
A
E
A
Statistics
I
mean
if
you
wanted
to
filter
out
a
thicker
layer,
you
couldn't.
We
need
to
know
what
the
layer
is
or
have
some
notion
of
what
the
areas
to
decide
that
that's
a
reasonable
thing
to
do.
You
know
so
either
you
have
to
do
that
by
observing
the
stream
or
having
some
upfront
knowledge
about
the
stream
which
we're
not
specifying
at
the
moment,
yeah.
E
I
mean
I
sort
of
assumed
that
a
lot
of
the
use
cases
where
you
know
what
what
layers
exist
and
you
just
want
the
marking,
so
you
can
strip
them
out
entirely
for
a
gateway
to
a
particular
set
of
devices
that
don't
support
it
and
for
that
sort
of
use
case,
I
would
think
this
would
work
brilliantly
for
things
where
you're
trying
to
do
prioritize
drops
and
decide
which
things
to
drop
and
at
which
rates
you've
been.
You
need
to
know
more
about
how
many
things
are
in
each
layer
and
seat.
Seating
gonna
be
yeah.
A
E
A
Oh
and
then
there
was
some
feeling
that
we
didn't
need
to
so
I've
got
to
go
with
that
unless
somebody
screams
so
yeah,
so
I
think
back
to
what
we
were
saying
just
try
to
they
try
to
get
that
revised,
written
out
and
also
you
know,
precisly
call
out
in
the
list
the
changes
you
made
so
that
people
can
review
them
and
see
whether
they
agree
with
them
or
think
we
need
more
calm,
more
changes
or
a
new
last
call,
or
anything
like
that.
Okay,.
E
E
A
E
H
E
We'll
just
scroll
what's
good
enough
right,
so
this
is
the
conditioner
of
feedback
format
which
we
discussed
on
the
last
meeting
and
we've
discussed
in
the
our
MCAT
group
a
couple
of
times.
Main
thing
that's
happened
is
we
got
some
comments
on
the
our
MCAT
mailing
list
from
Sergio
and
neurosis
and
comments
from
the
previous
I
TF,
which
we
we
only
just
got
around
to
incorporating
and
the
zero
to
version
which
was
submitted
yesterday
because
I'm
disorganized
inferior
dresses.
These
comments
next
slide.
Please
most
of
the
changes
are
actually
pretty
straightforward.
E
Those
some
clarifications
that
the
timestamps,
which
are
in
CP
formats
time
stamps
of
the
use,
the
same
clock
as
those
in
the
sender
report,
packets
and
it
used
to
say,
send
the
reports
or
receive
a
report.
And
then
someone
pointed
out
the
receiver
reports.
Don't
have
such
NCP
for
that
time
step.
So
we
can
fix
that.
E
E
The
the
format
ending
sequence
numbers
Sergio
suggested
that,
rather
than
reporting
the
ending
sequence
number,
if
we
report
the
M
sequence,
number
plus
1,
that
would
simplify
his
implementation
and
in
addition,
it
would
allow
us
to
report
those
two
fields
with
the
same
value
to
signal.
But
no
packets
were
received
in
the
interval
and
you
can
infer
that
from
the
receiver
reports,
but
it
makes
the
code
easier
if
it's
all
in
the
same
block
without
eggs,
are
immature
around
didn't
cover
any
ever
report
block
as
well,
as
else
was
currently
in
the
draft.
E
There
was
also
a
comment
and
Varun
remembered
this
from
someone
said:
it
won
the
previous
meetings
and
I
forget
who
it
was
that
maybe
we
should
report.
Beginning
sequence,
number
11.
Instead
of
that,
and
that
which
is
the
last
report
length
of
0
to
indicate
my
packets
received
and
to
me
that
actually
sounds
sounds
cleaner,
so
I
would
have
suggest
we
change
to
beginning
sequence,
number
on
the
land.
I'm,
not
sure
it
matters
that
much.
A
E
Judgments
is
to
do
it,
but
if
anyone
who's
thinking
of
implementing
it
has
really
strong
opinions,
then
let
me
know,
but
I
don't
think
it
matters
that
much.
To
be
honest,
if
not
next
slide.
Okay,
the
some
text
in
the
draft
that
says,
if
the
you
don't
accept
a
report
where
the
sequence
number
space
jumps
by
more
than
a
quarter
of
the
the
sequence
number
range
as
a.
I
E
Of
a
sort
of
crude
check
that
the
report
is
valid
and
sort
of
in
window
and
the
latest
version
adds
some
text
say
well:
okay,
if
you're
not
if
you're,
ignoring
things
where
the
sequence
numbers
have
jumped
a
significant
amount,
that's
fine,
but
maybe
that
actually
has
been
an
outage.
So
if
the
outage
has
been
long
enough
that
it's
reasonable
that
it
could
have
jumped
that
much
then
don't
ignore
it.
E
It's
a
sort
of
thing
you
have
to
implement
anyway,
to
make
a
robust
implementation,
I'm,
trying
to
phrase
that
in
a
you
know,
a
way
which
suggests
the
right
thing
to
do.
If
the
phrasing
is
clear,
that's
great,
if
you
read
it
and
find
that
phrasing
confusing,
then
please
suggest
for
all
summative
phrases
or
tell
me
what
you
think
is
unclear
about
it.
In
addition,
we
put
a
note
that
you
shouldn't
have
more
than
you
shouldn't
report
on
more
than
the
course
or
the
sequence
number
space
in
each
packets,
which
is
something
Sergio.
E
What
would
be
worth
clarifying
in
practice?
You
couldn't
anyway,
because
the
pack
is
some
thickness
and
if
we
change,
if
we
change
to
the
length
field,
you
can
see
either
because
the
length
is
the
16
bits.
Oh
yeah,
the
wealthier,
the
packets
won't
be
big
enough
in
arc,
so
doesn't
RTP
double
grams
yeah.
E
E
So
since
this
is
an
ACK
on
a
TCP
back
feedback
thing,
there
is
already
a
an
SDP
mechanism
defined
to
do
that.
We
just
needed
to
register
them
value
to
go
in
it,
and
we
add
that
registration
and
that
lets
you
use
the
existing
mechanism
defined
in
RFC
four
five,
eight
five
to
signal-
or
this
is
press
which
is
just
the
usual
sdp
attributes
and
the
offer
answer
business
next
slide
and
that's
it
I
think
this
is
essentially
done.
I.
E
A
Now
this
is
one
thing
in
the
permutation
there's
another
question
so
I
know
we
had
some
sort
of
discussion.
I,
don't
know
if
anybody
be
interested
in
this
they're
thought
of
maybe
trying
to
do
I
would
both
for
our
MCAT
and
for
this
doing
maybe
some
hackathon
work
at
the
next
IETF.
Anybody,
that's
interested
in
that.
Would
anybody
be
interested
in
anything
like
that
or
know
anybody
who
would
or
have
these
students
you
could
recruit
or
do
it
to
do
that?
I.
A
D
G
E
Yes,
so,
rather
than
putting
an
extra
sequence
number
in
which
I
think
that
one
did
as
a
header
extension,
this
uses
the
existing
sequence
numbers
so
yeah.
It
makes
the
forward
packets
smaller
and
it
fits
with
the
way.
Rtp
works,
perhaps
a
little
more
naturally.
But
it
means
you've
got
a
little
bit
more
bookkeeping
as
Jonathan
says,
but.
A
D
The
real
question
is
like:
if
you
already
have
one,
you
know
what
would
one
be
looking
for
like?
Where
does
the
worker
want
to
produce?
The
Brooklyn
area
is
a
specific
recommendation
of
one
of
these
particular
message:
P
mount
for
both
formats
that
everyone
should
use,
or
should
we
not
so
the
markets
speak
so.
A
A
This
is
something
that
was
designed
to
work
for
all
of
the
candidates
feedback
all
of
the
cabinet
congestion
control,
algorithms
that
are
MCAT
is
looking
at
and
that
kind
of
inputs
from
all
of
those
I
believe
and
then
the
idea
being
that
then,
even
if
people
using
entirely
disparate
potential
algorithms,
they
could
use
any
of
these
feedback
mechanism.
They
could
interoperate
with
these.
This
feedback
message,
specifically
this
being
the
one
with
the
IETF,
recommends
I.
E
Mean
what
it
reports
is
the
issue
of
back
a
couple.
Slides
I
mean
it's
reporting,
the
the
lost
packets
and
and
the
rival
yeah
yeah.
So
so
each
packet,
it
reports
whether
it
was
received
or
not
what
the
ec
n
marks
were
and
when
when
it
was
received,
and
it's
not
a
particularly
optimized
format,
and
that
there
are
ways
of
optimizing
it.
E
My
analysis
for
the
kit
that
scenarios
I
looked
at
shows
that
optimizing.
It
doesn't
help
you
a
lot
because
the
overhead
of
the
year,
the
UDP
packets
and
the
sender,
reports
and
everything
else
as
go
in
the
packet
is
so
much
that
if
even
if
you
have
the
size
of
this,
it
doesn't
say
for
significant
amount.
So
it
didn't
seem
worth
optimizing
it,
but
we
can
optimize
it
if,
if
people
care
I.
D
E
A
D
B
I
think
it's
important
that
these
working
groups
put
themselves
more
in
the
shoes
of
somebody
trying
to
convince
their
boss.
They
should
allocate
time
to
do
this,
so
I've
been
in
that
position
and
I've
been
asked.
Some
very
uncomfortable
questions
like
the
ones
that
Justin
just
asked
and
I
didn't,
have
really
convincing
answers,
and
you
know
having
been
through
the
situation
where
people
say.
Oh,
the
way
to
get
better
in
our
ability
is
through
a
new
standard.
I
never
actually
had
that
achieve
better
interoperability,
fixing
existing
stuff
and
doing
Interop.
B
That
generally
does
actually
produce
better
interoperability.
So
I
can
I
can
tell
you
that
I
would
love
if
there
was
something
in
this
document
that
said
here,
you
know
we
looked
at
all
these
different
things
and
there's
some
convincing
reason
to
do
this
right.
So
I,
just
like
I've
been
in
that
position
and
it's
been,
it's
not
been
a
good
conversation.
I
haven't.
E
E
E
I
think
this
fits
the
way
RTP
does
sources
and
sequencing
on
bring
better
and
therefore
is
more
likely
to
fit
with
future
extensions,
and
given
that
we
have
already
been
bit
with
a
number
of
problems,
building
web,
as
you
see,
with
the
definition
of
sessions
and
multiplexing,
and
all
of
that
mess
with
bundle,
because
people
had
built
things
in
a
way
which
wasn't
very
future
proof.
Maybe
we
should
learn
from
that
and
try
and
move.
A
To
something
that's
a
little,
it's
also
truth.
Does
work,
I
mean
again
not
surround
property
itself,
but
work
could
work
for
more
RTP.
Topologies
like
this
would
be
not
unreasonable
for
our
to
be
multicast,
I
mean
nobody
has
a
multicast
just
control
algorithm
yet,
but
I
think
there's
nothing
about
this
protocol
that
doesn't
make
sense,
but.
E
G
G
G
A
L
B
It
doesn't
it
doesn't
matter
because,
what's
happened
is
there'll,
be
people
who'll,
do
the
old
one
and
we'll
have
them
in
mobile
apps?
That
will
ship
for
the
next
five
years
and
there's
yeah
I
know,
and
you
know
what
that
conversation
is
like,
which
basically
means
you'll
have
to
do
the
old
one
and
you'll
have
to
do
the
new
one
and
you'll
have
to
negotiate
between
them
and
make
sure
that
both
of
them
will
operate
sensibly.
Oh.
B
You
pretty
much
have
to
do
the
Google
one,
because
that's
out
there
and
you'll
probably
have
spend
the
next
year
and
a
half
fixing
all
the
bugs
and
getting
it
to
work
and
then
you'll
be
asking
the
same
questions
that
we
just
asked.
Why
do
I
have
to
do
this
new
thing
and
what
do
I
get
out
of
it
and
your
boss
will
have,
will
ask
you
some
very
hard
questions
and
how
much
time
you
just
spent
getting
the
old
one
to
work?
Some.
A
But
I
think
the
other
point
which
I
think
is
relates
to
what
Harold
said
about
about
what
he
thought
that
Walmart
said
is
that
the
difference
between
implementing
this
and
implementing
the
hallmark
feedback
is
essentially
what
what
you're
you
know,
whether
your
hash
table,
keys
or
16
bits
or
48
bits.
You
know
whether
you're
indexing
by
a
new
sequence,
number
or
SSRC
and
RTP
sequence
number
other
than
that,
and
though,
obviously
the
factorization
d
packetization,
but
everything
else
is
exactly
the
same.
A
D
Okay,
Cullens,
let's
go
I
mean
I
I,
hear
what
you're
saying
but
I
sort
of
disagree
that
you'll
need
to
implement
both
I
think
you'll,
usually
I
mean
you've
gotten
five
years
of
shipping
without
implementing
any
so
I.
Don't
really
see
this
being
real
high
on
the
priority
list
to
go,
implement
right
away.
D
So
you
might,
you
know,
I,
think
of
all
the
browser
vendors
agreed
upon
which
one
they
were
going
to
implement,
preferably
using
a
standards
process
to
do
that,
but
that
would
be
great
and
that
you
probably
don't
need
to
implement
all
the
old
ones.
You
could
probably
get
away
with
implementing
the
one
that
a
bunch
of
people
can
decide
to
go
forward
with
I'm,
not
arguing
which
one
that
one
is,
but
that
would
be.
The
really
key
thing
to
me
is:
let's
come
down
on
one
of
those
and
not
to.
D
A
D
Yes,
yeah
absolutely
sequence:
number
two
fire
three
yeah,
it's
their
2.5
amazed.
You
know
anyway,
III
think
you
know.
The
question
for
the
chrome
team
is
like.
Okay.
Is
this
something
that
we
think
is
a
natural
solution
for
our
stuff
anyway?
And
if
we
do
make
this,
you
know
go
in
this
direction,
then
I
think
that'll,
probably
everyone
else
you
just
know.
Web
RTC
will
follow
just
because
it'll
not
require
five
months
of
button.
D
A
And
I
think
you
know
at
least
I
mean
if
you
at
least
like
have
your
implementers
look
at
it
like,
if
you
feel
like
I
said,
have,
if
you
think
stuff
I
looked
at
it
in
the
past.
If
you
could
look
at
it
again
and
say
you
know
yes,
this
is
easier.
Oh
my
god,
my
hair
is
on
fire
and
let
us
know
why
his
hair
is
on
fire.
That
would
be
helpful.
Just.
E
E
I'm
not
sure
they're
written
them,
we
discussed
them
in
one
of
the
previous
meetings,
so
they're,
probably
in
the
minutes.
If
I'm
remembering
right,
it's
that
it
reports
on
ACN
and
I,
don't
think
the
other
one
does
and
that
it
fits
the
way
we
do.
Sequence,
numbering
and
SSRC
SNR
CP,
better,
which
I
think
is
just.
D
E
No
because
I
mean
I
think
what
you
did
before
was
just
you
use
the
global
sequence
number
and
you
work
at
a
fraction
loss
based
on
that
and
what
you
would
do
this
time
is.
You
would
look
at
okay
for
this
SLC.
We
see
this
many.
You
know
this
many
packets
ends
and
this
may
lost
and
for
this
SSE
we
see
the
same
fraction.
We
add
them
up
and
if
you
want
to
implement.
A
It
internally,
as
you
maintain
that
you're
you
know
internally,
who
have
a
global
seat,
you
have
a
global
sequence.
Number
you
remember
what
SRC
and
RTV,
so
you
guys
ever
do
is
for
each
one.
Then
you
get
the
feedback
back.
You
look
that
up
in
your
hash
table
map
it
back
and
run
the
exact
same
algorithm.
That's
a
perfectly
reasonable
implementation.
Okay,
I
actually
think
it's.
E
Much
simpler
than
that
yeah
you
look
it
up.
You
versus
I,
see
one
you've
lost
this
fraction.
You've
lost
six
out
of
the
thunder
thousand
packets
for
SSRC
two
year
was
one
out
of
a
thousand
packets
that
gives
you
seven
out
of
two
thousand,
and
that
gives
you
your
lost
fraction
all
right.
Well,
rather,.
A
D
M
J
I
I
Well,
you
can
go,
you
can
skip
the
outline.
So
it's
a
short
presentation,
well,
there
being
a
lots
of
editorial
changes
in
the
latest
version,
and
you
will
definitely
see
that
if
you
do
look
at
it.
If
but
I
have
a,
we
worked
on
improving
the
use
of
the
RTP
taxonomy
RFC
76
56.
We
done
some
significant
changes
around
the
descriptions
of
the
RTP
sessions,
the
synchronization
source
and
in
the
pale
RTP
payload
type
description.
I
These
broad
categories
of
choices
between
how
you
put
in
multiple
media
streams
in
one
session,
among
in
in
having
them
in
the
same
session
in
multiple
sessions,
is
that
drawing
in
so
that's
focused
a
bit
being
focused
on
on
on
the
most
relevant
differences
and
some
of
them
really
not
meaningful
ones
has
been
removed.
So
I
may
also
improve
the
security
considerations
discussion.
So
next,
so
it's
documents
open
issues
that
we
had,
as
in
the
other
team
we
had
some
discussion
on.
What's
currently
is
written
around
our
TP
sinks
since
I
have
to
be
sources.
I
We
had
a
discussion
yesterday
around
this
and
and
our
proposal
is
basically
to
work
more
around
the
use
of
our
to
be
participants,
so
a
sink
would
be
basically
could
be
described
as
an
RTP
participant
in
an
RTP
session
that
receives
RTP
data
packets,
something
along
that
line.
We
gonna
words
miss
this
further,
as
we
do
the
updates.
I
Another
issue
we
had
was
in
the
issue
list
in
the
draft
was
around
msid
and
actually
our
suggestions
is
actually
to
remove
a
discussion
of
msid,
because
it's
no
longer
really
it's
a
very
RTC
web,
specific
binding
of
media
tracks
to
media
streams,
and
it's
really
not
obvious
that
it's
applicable
in
general.
So
our
suggestion
here
is
to
remove
it
and
also
for
improving
these
design
choices
and
and
going
from
one.
I
I
There's
some
addition,
I
think
editorial
improvements.
We
can
do
the
document,
but
really
the
goal
should
be
that
by
the
next
version
in
time
for
the
next
before
they
meet
next
meeting
should
have
be
ready.
Actual
working
plus
call
it's
time
to
finish
this
document.
It's
and
I,
don't
I
think
we're
getting
there.
It's
so
any
comments,
questions,
etc.
I
C
N
C
It
is
priority
value
for
the
non-scalable
stream
droppable
frame,
it's
a
applicable
to
a
single
RTP
stream
and
not
for
comparing
between
multiple
stream.
So
it
allows
the
middle
box
to
discard.
Part
of
all
of
the
discardable
frame
is
marked
by
the
encoder.
It's
provided
more
option
for
changing
the
bitrate
on
congestion,
and
it's
a
lot
of
differentiation
between
reference
and
non
reference,
be
frame
to
drop,
to
provide
different
priorities
to
allow
to
drop
first
non-reference,
be
frame
and
also
to
drop.
C
A
p
frame
that
are
closer
to
the
end
of
the
group
of
GOP
is
better
than
dropping
one
at
the
beginning
and
can
be
marked
as
droppable
with
lowest
priority.
The
the
things
that
we
we
believe
is
I
looked
at
to.
If
we
can
signal
what
is
there
was
a
question
about
how,
if
you
can
figure
out
how
we
can
figure
out
how
much
we
are
there
from
each
priority
level
in
terms
of
the
ratio
between
them.
C
So
I
looked
at
trying
to
say
to
provide
some
signaling
and
the
only
idea
I
had
about
it
was
to
add
some
extension
attribute
because
I
couldn't
edit
there
and
then
it
would
be
to
offer
mutually
exclusive,
which
is
very
complicated.
I
didn't
know,
make
sense
to
do
that
in
the
first
place,
and
we
discussed
it
internally
because
we
are
using
that
and
the
way
currently
we
are
doing
that
is.
We
are
doing
estimation
based
on
history,
about
how
many
RTP
packets
are
in
each
priority.
We
have
to
take
into
account.
C
C
Next
slide
hey,
so
the
solution
is
just
cleared
to
bits
from
the
fall
must
be
zero
bits
when
zero
does
them,
because
if
we
have
been
the
non-scalable
case,
the
bits
that
are
not
that
are
must
be
0.
So
we
are
suggesting
to
use
two
of
them
to
provide
priority
where
0
0
is
the
highest
priority,
which
will
keep
it
as
it
is
today,
and
the
1
1
would
be
the
lowest
priority.
C
The
thing
that
we
discussed
in
the
past
is
that
at
least
we
won't
do
anything
with
that
until
we
finish
the
the
frame
marking
and
then
we
can
decide
to
do
it
as
a
second
document
afterwards,
so
we're
still
waiting
for
the
D,
so
I
don't
think
we
need
to
adopt
it
now,
but
we
can
look
at
it
after
they.
The
frame
marking
is,
it
will
go
to
publication.
A
C
We
are
doing
it
internally,
I,
don't
know
if
it's
done
outside.
We
didn't
check
there,
but
I
know
that
internally
we
are
doing
it
with
testing
and
we
are
using
that
internally
and
in
most
cases,
are
showing
on
the
Wi-Fi
connection
router,
because
that's
where
we
have
some
problem
when
you
go
inside
this
congestion
inside
the
the
home,
so
that's
how
it's
being
used.
A
A
C
F
No
I
just
submitted
a
revision
that
has
all
the
changes
for
Magnus
and
quite
a
few
more
changes.
So
I
think
it
would
really
be
good
for
anyone
that
reviewed
their
earlier
versions
of
the
document.
So
look
at
it
again.
A
lot
of
changes
in
sections
four
and
six
where
people
were
complaining
about
confusion.
So
the
layouts
of
the
format's
are
now
more
clearly
spelled
out
in
recovery
procedures
and
welcome.
So.
C
Maybe
I
should
do
another
working
book
last
call
okay,
so
I'll
do
another
working
fresco,
short,
a
short
one,
but
I
hope
people
now
I
mean
as
long
as
the
people
are
here.
I
hope,
I
think
that
please
do
review
it
once
this
comes
on
the
in
the
tools.
I
mean
the
be
on
the
website
and
provide
feedback,
because
we
want
to
finish
with
it.
We
don't
want
to
be
last
year.
We
have.
N
N
C
N
C
Least,
what
I
did
I
tried
to
verify
that
it
addresses
the
comments
that
I
saw
on
the
least
in
the
version
personally
to
verify
and
I
hope
now
that
and
just
wait
for
Steve
you'll.
Do
that
so
I'll
wait
for
Steve
to
look
at
it
and
Magnus
will
have
to
look
at
see
that
his
comment
is
addressed
and
I.
Think
that's
will
cover
that.
So.
C
N
F
Okay:
okay,
there
were
mostly
clarification,
so
the
wording
confused
people
was
unclear.
So
we
clarified
a
lot
of
the
the
formats
so
restructuring
of
the
of
the
presentation
of
the
formats,
not
the
actual
course
there
was
one
technical
change
that
Magnus
suggested
that
the
authors
agreed
with,
which
was
changing
the
retransmission
format
to
just
change
the
meaning
of
one
of
the
bits
so
previously
defined
that
the
F
bit
was
was
one
now
it's
redefined
to
be
zero.
Just
makes
it
simpler
for
copying
the
the
RTP
packet,
as
is
to
retransmit
it
okay.
C
I'll
just
wait
for
just
well,
please
do
the
reviews
and
then
we
say
the
publication.
There's,
there's
other
payload,
there's
a
payload
that
which
is
working
a
blast
cold,
but
it's
really
getting
reviewed
by
outsiders
from
from
here
who
are
interested
in
this
codec.
So
we
got
refused
on
that
and
I
did
a
review
to
verify
that
today,
it's
correct
according
to
the
structure
of
the
document,
and
they
should
surprise
need
to
bring
another
version
and
that's
the
Tetra
one.
You
could
develop
your
cover.
Okay
and.