►
From YouTube: IETF104-AVTCORE-20190326-1610
Description
AVTCORE meeting session at IETF104
2019/03/26 1610
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
B
I'm,
keeping
an
eye
on
the
Dever
and
I
see
a
few
other
people
who
are
here
because
I
am
in
Denver.
So
let's
do
it
and
let's
see
we
have
a
number
of
remote
participants,
nice.
Anyone
wants
to
talk
if
you
can
and
wish
to
and
don't
feel
like
you're
to
unclutter
organic
use,
the
vehicle
you
need
for
muff.
You
want
to
speak.
Otherwise,
if
you'd
rather
not
you
can,
you
know,
relay
to
the
real
barbarous
referenceusa
blue
keys
are
going
around
you're
here,
make
sure
to
sign
up,
and
you
know
me
to
go.
D
B
Yes,
excellent
hello.
Try
that
again,
so
the
people
remotely
can
hear
me
welcome
to
abt
core.
Let's
run
through
this
again
welcome
to
a
Vedic
or
we
have
I
also
want
to
make
sure
that
I
have
on
the
recordings.
We
put
the
notes,
so
I
can
remember
so
the
Brian
Rosen,
taking
the
notes
anybody
else
who
wants
to
join
the
ether
pad
can
do
so.
We
have
a
few
people
in
Java
if
you're
on
me
to
co,
use
it
if
you're
able
and
feel
sufficiently
telegenic,
otherwise,.
B
You
can
prefix
to
the
room
and
some
people
will
relay
for
you
note
well
note
very
well,
and
this
is
our
agenda.
You
listed
30
minutes
religion
for
those
I
guess
because
we
have
to
yell
at
mo
okay,
okay,
yeah,
so
we'll
start
with
agenda
bash
and
status
update.
B
We
also
have
some
slides
for
Ronnie
to
present
on
behalf
of
the
payload
working
group,
so
that
because
they're
not
formally
meeting
here
today,
but
it's
largely
the
same
group
of
people,
I
guess
we'll
do
that
the
end
or
or
when
do
you
want
to
I
mean
okay,
so
no
new
documents
since
last
time,
but
next
slide
I'm
still
over
yeah,
we
still
have
a
number
of
things
sitting
in
cluster
238,
which
is
not
surprising
to
anybody
who's
familiar
with
this
area
of
the
IETF.
B
F
B
But
yeah,
that's
the
other
thing
of
note.
There
are,
then
is
the
the
Ben
is
stepping
down
as
our
ad,
and
we
want
to
thank
him
for
excellent
work
for
the
past
four
years
and
very
well.
We
taking
over
so
then
frame
marking
which
I
believe
we
we
had
a
working
group
last
call
on
and
there
were
comments
and
the
author
who
is
hiding
in
the
back
hoping
I,
don't
notice,
oh
no,
there.
You
are.
G
G
B
B
I
Hi
I'm
Colin
Birkins
I
wanna
talk
about
the
RTP
congestion
control
feedback
draft.
If
any
of
you
were
in
our
MCATs
earlier
in
the
week,
you
can
stop
paying
attention
until
I
get
to
about
two
slides
for
the
end,
because
the
first
three
quarters
of
the
presentation
is
exactly
the
same
as
the
one
I
gave
earlier
in
the
week.
So
we
we
have
the
draft
I'm,
giving
it
a
generic
feedback
mechanism
for
packet
loss,
ecn,
Marcus
timing,
information
that
were
using
for
congestion
control
feedback
dress
been
around
for
a
while.
I
I
So
we
accrued
some
really
useful
feedback,
as
a
result
of
that
which
we
discussed
at
the
Bangkok
meeting
in
in
this
working
group,
and
we
submitted
the
zero
free
draft
just
before
Christmas.
If
I
remember
rights,
to
try
and
reflect
these
experiences,
this
makes
one
minor
change
to
the
packet
format,
which
will
hopefully
be
the
last
one
we're
making
and
a
whole
bunch
of
clarifications.
I
B
I
This
makes
the
logic
in
the
rest
of
the
specification
a
lot
a
lot
simpler.
A
lot
easier
also
gives
us
a
much
easy
way
of
specifying
you
know.
There's
no
reports
included
used
for
a
number
of
reports
of
zero.
Hopefully
it
also
simplifies
the
implementations.
It
certainly
simplifies
the
specification
in
addition
to
that,
there
are
bunch
of
clarifications.
In
particular,
one
of
the
big
discussions
we
had
last
time
was:
what
is
the
the
value
of
the
the
arrival
timestamp
or
what
does
it
mean
and
how
do
you?
I
I
But
there's
an
over
range
indicator
and
we
specified
what
to
do
if
a
packet,
if
you're
reporting
on
a
packet
which
is
arrived
after
the
timestamp
of
the
report,
which
seems
like
it
shouldn't
be
possible,
but
it's
possible
if
your
report,
if
you
have
a
delayed
report
if
you've
had
to
split
the
reports
across
multiple
report,
blocks
you
putting
them
in
a
packet.
So
there
are
some
corner
cases
like
that.
I
Similarly,
we
clarified
exactly
what
is
meant
by
the
report
time
stamp,
to
specify
that
it's
the
instant
from
which
the
arrival
time
offsets
are
calculated
rather
than
the
instance
at
which
the
report
packet
was
generated
again,
because
you
might
be
sending
reports
late,
because
you've
had
to
split
there.
That
means
too,
and
because
our
MTU
issues
and
all
this
sort
of
thing,
we
clarified
that
you
should
report
on
every
active
SSRC
as
a
receiver
rather
than
every
SSRC.
I
Their
bunch
of
clarifications
around
duplicate
reports,
we
have
the
case
you
what
works
possible
to
report
on
overlapping
ranges
in
multiple
reports,
and
we
specified
a
few
marker
packet
as
received
in
one
report,
then
you
have
to
also
mark
it
received
in
any
later,
of
course,
covering
the
same
portion
of
the
sequence.
Number
range
you
cover
in
then
John
reception.
I
Similarly,
there
are
a
bunch
of
clarifications
around
duplicate
packets.
We
made
it
clear
that
if
you
get
more
than
one
copy
of
the
packet,
you
should
report
the
arrival
time
of
the
first
copy
of
the
packet
which
you
receive
and
if
you're
using
ecn
and
one
of
the
packets
yeah
and
an
EC
n
marks
packet
gets
duplicated.
It's
possible
that
not
all
of
the
duplicate
copies
of
the
packet
will
have
the
same.
You
see
n
mark
depending
where,
in
the
network
it
was
duplicated
and
where
its
marked.
I
So
if
any
of
the
copies
EC
NC
c
e
marked
for
congestion
experience
than
you
report,
that
of
that
packet
was,
you
report,
see
e.
Otherwise,
you
report
the
e
CN
mark
of
the
first
copy
of
the
packet
you
receive
and
again,
if
it's
not
congestion
experienced,
you
should
be
getting
the
same
ec
n
mark
on
all
copies
of
the
duplicate
packets.
I
The
previous
versions
have
the
draft
had
a
long
discussion
about
what
to
do
about
outages
and
how
to
detect
that
they've
been
a
burst
of
packet
loss
and
when
to
recover,
and
all
that
we
took
that
text
text
out.
This
is
a
general,
a
TCP
problem
of
how
to
detect
that
packets
are
stopped
flowing
and
what
to
report
and
when
and
the
same
approach
you
take
for
any
of
our
TCP
packets.
I
You
should
take
for
this,
so
it
wasn't
worth
trying
to
repeat
that
explanation
again
in
terms
of
signaling,
there
was
a
comment
again
from
the
hackathon
which
the
rtcp
feedback
format.
We
have
allows
you
to
specify
a
particular
set
of
payload
types
torch.
It
supplies
and
we
specified
that
you
should.
You
must
I,
think
specify
a
start
as
to
signal.
I
I
Wondering
if
it
might
be
a
bug
in
one
of
the
traps,
maybe
sure
I
copied
pasted
this
so
for
all
making
the
same
mistake,
maybe
one
of
the
ASDP
traps
is
inconsistent.
Might.
J
I
I
Seven
nine
is
the
ECM
for
RTP
RFC
and
that
that
RFC
has
a
couple
of
things
in
it,
most
of
which
it,
but
most
of
what
that
else
he
talks
about,
is
how
you
use
ECM
with
RTP
and
how
you
might
packets
and
how
you
signal
that
you're
going
to
use
ECM
and
how
you
validate
that
the
the
ECM
works
over
a
particular
path.
It's
also
got
a
particular
feedback
format
for
sending
ecn
feedback.
I
B
John
clinics
I
mean
I,
think
the
as
an
individual.
The
issue
here
is
that
you
say
you
must
not
offer
both,
but
you
might
be
in
a
position
where
you
don't
know
whether
your
peer
supports
ucfb,
so
I
think
this
is
a
bolita
to
some
the
other
stuff
I
mentioned
in
my
email.
You
might
want
to
offer
both
when
the
answer
should
pick
one,
because
you
might
be
talking
to
a
peer
who
might
support
Mac,
you
see
an
ER
might
support
GCF
B,
you
don't
know
in
advance.
B
I
J
I
Phone
and
what
were
the
issues
here
so
there's
a
bunch
of
signaling
related
issues,
and
there
was
a
bunch
of
other
things
too
in
terms
of
the
signaling.
There
was
a
question
about
if
you're
bundling,
if
you're
using
this
with
bundle,
is
it
possible
to
signal
this
for
only
some
of
the
bundle
of
media
lines,
or
do
you
have
to
sing
with
all
of
them?
H
H
I
mean
the
bundling
is
basically
goes
beyond
my
head,
but
the
simplest
thing
would
be
like
to
do
it
for
every
every
one
of
them
and
then
basically,
how
you
treat
how
we
fit
those
information
to
condition.
Control
might
depend
like
whether
you
would
like
to
do
and
in
like
independent
flow
with
string,
College
control
and
bundle
conditional,
I,
don't
know
yes,
I.
H
I
H
I
I
B
I
B
I
We
should
figure
out
what
it
should
be
and
write
it
down
so
they're
all
consistent
in
terms
of
negotiating
congestion,
control
feedback,
and
this
relates
back
to
the
issue
of
the
the
ECM
you're.
Obviously,
there
are
a
bunch
of
different
ways
of
doing
congestion
control
feedback.
You
probably
only
want
to
use,
try
and
use
one
of
them
simultaneously.
H
In
here
again,
I
mean
so
what
we're
offering
an
implicit,
explicit
way
of
condition
right
like
getting
getting
some
degree.
Information
are,
oh
I
mean
so,
basically,
if
you
have
to
like
get
information
about
condition
in
different
form,
ECN
or
delay,
there
are
application
like
algorithm.
They
can
combine
them
like.
One
of
them
were,
example,
isn't
fit
another
in
our
own
cat.
They
actually
could
use
both
a
scream.
H
B
H
B
H
It's
what
what
sort
of
negotiating
what
feedback
you
get
so
yeah
I'm.
Getting
to
that,
and
my
point
is
like
for
the
sender
to
decide
what
to
do,
it
is
on.
All
thing
could
be
a
different
could
be.
It
could
be
that
that
thing,
but
I
think
if
we
can
minimize
the
feedback
number
feedback,
you
need
to
send
from
the
receiver
to
the
sender
that
that
what
should
be
the
aim
here,
yeah.
H
If
Sen,
a
signal
is
covered
by
this
feedback
message
should
not
send
that
or
something
like
that,
so
the
only
thing
is
like.
If,
in
my
opinion,
we
should,
we
should
be
recommending
the
behavior
like
I
mean
like
so
in
case
of
you,
do
something
you
you
don't
create
an
application
that
is
expecting
some
certain
sort
of
feedback
like
so
it's
crashes
when
it
doesn't
get
that.
I
Yeah
I
mean
we
need
to
specify
how
you
say
what
types
of
feedback
you
can
live
with
and
if
you
have
the
option
of
sending
so
fear,
if
the
sender
says
I
knew
I
can
live
with
tight
legs
and
wide,
and
you
can
support
both
of
them.
We
don't
want
you
to
send
them
both.
We
want
you
to
pick
one
and
we
need
to
specify
a
way
of
specifying
that
offer.
That
says
these
are
the
alternatives
and
based
on
that
deterministic
we
have.
B
You
know
not
changing
your
mind
later
in
the
session,
because
what
is
a
sub?
This
is
some
sort
of
offer
or
now
say
only
the
one
you
picked,
or
does
it
still
say,
I
could
do
any
of
these,
which
we
might
need
and
I
need
more
SDP
offer
answer
expertise
on
that
would
yes,
I
think
so.
I
might
I
feel
like
I
noticed
that
Paul
kids
at
that
is
in
the
call
and
I
might
ask
him
to
meet
a
co.
If
he's
feeling
sufficiently
telegenic.
G
G
C
M
I
I
M
I
B
N
B
B
B
O
B
O
O
G
That
must
be
two
different
unidirectional
M
lines.
You
can't
have
a
equals
like
SPF
B
means
something
different
for
send
and
receive,
unless
you
split
as
to
him
once
yeah
with
sinan
and
so
Nolan
receive
on
yeah.
The
semantics
of
our
TCP
FB
is
not
doesn't
have
a
direction.
It's
it's
bound
to
the
SDP,
my
direction
that.
H
G
G
Topic
guys
with
the
star,
the
question
was
whether
or
not
it's
ok,
when
you're
bundling
this
stuff
to
always
apply
it
to
all
payload
types
or
would
you
ever
want
a
selection
of
pillow
types?
So
that
made
me
wonder
whether
or
not
we're,
assuming
that
all
repair
formats,
feck
and
r-tx
are
also
expected
to
be
included
or
are
they
mandated
to
be
included
in
in
the
set
of
feedback
reports.
G
B
I
I
P
Thank
you,
I
just
want
to
maybe
provide
a
little
bit
of
perspective
from
an
algorithm
design,
sort
of
a
perspective
since
I'm
kind
of
going
through
the
journey
right
now,
we've
actually
implemented
one
version
of
nada
that
works
with
our
TCP
control
messages
and
use
RDP
based
congestion
signal
and
right
now
we're
using
the
you
know,
the
version
from
Google
the
transport
feedback
and,
of
course,
we're
looking
forward
to
use
the
ramp.
You
know
this
new
version
of
congestion
control
feedback.
P
My
main
point
is
that
usually
from
an
algorithm
design
point
of
view,
if
the
receiver
could
provide
provide
alternate
versions
of
congestion
feedback,
usually
there
is
a
preference
for
the
congestion
control
algorithm
to
pick
one
of
them
right
now.
What
I'm
seeing
is
that
between,
but
between
the
version
of
Google
and
the
the
rtcp
feedback,
is
always
there.
So
then
it's
more
like
both
feedback
messages
come
back,
and
you
know
the
sender
have
the
freedom
of
you
only
sort
of
responding
to
one
of
them.
P
But
if
let's
say
a
third
one
is
on
the
table,
maybe
for
the
perspective
of
reserving
bandwidth,
it
might
be
better
for
the
sender
to
specify
a
priority
list.
So
this
way
the
receiver
can
sort
of
conform
to
the
priority
and
then
you
know
save
backward
bandwidth
if
needed.
So
that
would
be
my
preference,
yeah
yeah.
P
Yes
and
then,
usually
there
is
a
convenience
in
you
know:
processing,
different
feedback
messages,
yeah
sure
yeah.
By
the
way,
the
other
thing
is,
and
typically
the
algorithm
has
understanding
of
the
frequency
of
kind
of
the
preference
of
the
frequency
of
the
feedback.
So
potentially
that's
another
information
that
can
be
added
to
the
negotiation
yep.
I
J
I
That
means
everyone's
needs.
I
am
very
much
in
favor
of
simplicity,
I
I
think
we
need
to
figure
out
how
to
specify
identical
or
nearly
identical
semantics
such
that
people
all
all
do
it's
the
same
way
and
I,
don't
know
how
to
specify
I,
don't
know
what
words
to
use
for
that.
So
if
people
have
wording
suggestions
and
if
people
have
technical
suggestions
for
how
we
should
phrase
except
you
know,
I
am
NOT
an
expert
in
how
offer
answer
is
used.
So
it
wouldn't
very
much
appreciate
input
in
this.
So.
H
Soulja
had
again
I
mean
kind
of
equating
what
shouting
said
like
when
I
get
information
explicit
impression
as
a
as
a
constraint,
control
algorithm,
the
designer
I
mean
I
I
have
might
be
friends,
I'll
handle
it.
If
you
give
me
more
information,
better
I
can
I
can
choose
from
what
I
want
to
use
for
now
to
change
my
state.
Now
we
were
talking
about
sending
sending
back
condition,
concentrate
back,
I.
Think
the
draft
has
a
rationale
of
why
and
you
have
a
new
condition.
H
H
I
Can
write
in
the
draft
view
if,
if
the
offer
has
multiple
congestion
control
feedback
options,
then
then
the
the
answer
should
pick
one
yeah
yeah,
it's
not
here.
If
that
is
specific
enough
about
what
multiple
congestion
control
feedback
for
Masse's
yeah
I
mean,
that's
a
pretty
vague
term
people
think
that's
a
vision.
That's
easy
to
write.
I.
H
I
I
O
I
think
the
most
complicated
scenario
I
think
we
like,
obviously,
is
the
offer
you
need
to
offer
all
the
things
you
support
and
then
the
most
complicated
scenario
I
can
come
up
with
is
basically
that
the
offer
a
set
like
I
want
to
bundle
everything
here.
All
my
options
and
the
answerer
basically
breaks
the
bundle
up
into
multiple
bundle
groups
and
then
says,
like
I,
because
of
like
I'm
doing
video
over
this
machine,
then
audio
over
this
other
machine
that
they
don't
post
support.
O
J
I
I
If
you
get
this
thing
or
the
Google
thing
you
need
to
choose
between
them,
because
we
haven't
got
a
reference
to
the
Google
thing
and
I
can
write
a
congestion
control
feedback
form
at
the
Bennets,
a
little
Vegas
to
what
you
mean
by
a
congestion
or
feedback
formats.
We
don't
want
someone
pickings
some
other
rtcp
extension
which
isn't
really
congestion
control
and
using
that.
B
B
B
J
I
B
B
I
B
B
The
other
thing
I
was
thinking
on
the
other
one.
That
sort
of
unclear
me
I,
think
I
know
what
it
should
be
is
Mac
and
I
feel
like
that's
a
different
semantics.
The
semantics
of
Mac
is
more
he's.
Not
just
I'd
watched
this
packet,
but
I
lost
this
packet
and
I
still
have
enough
time
in
my
playback
buffers
that
it
would
be
useful
to
me
to
be
transmitting
it
there's.
The
difference
which
is,
you
know,
submit
semantically
different
enough
I
feel
like
it
should
not
supersede
Mac
yeah
sure
that
should
be
a
consensus.
Call
yeah.
B
I
I
B
M
M
M
B
And
taxonomy,
oh
yeah,
so
Bob,
the
other
question
I
was
going
to
ask
you
as
hopefully
the
SCP
expert
is.
What
should
we
do
so,
assuming
that
you
do
have
that
where
offer
presents
a
list
and
answer
a
picks
one,
what
should
happen
in
subsequent
offers?
Should
you
still
list
all
your
game?
Should
you
list
only
the
one
you
converged
on.
M
L
B
I
M
K
M
K
Think
every
waiting
here
for
a
while
sorry,
so
we
we've
cleared
up
that
keep
it
simple,
doesn't
isn't
quite
as
simple
as
they
could
hope
for
in
that's.
We
cannot
say
much
about
all
the
other
possible
mechanisms,
because
that's
an
unbounded
sets
really
meant,
and
you
want
tomorrow,
and
we
should.
This
draft
is
talking
about
this
mechanism
and
it
should
recommend
a
that's.
K
If
you
pick
this
one,
don't
pick
they're
the
ones
that
don't
that
do
the
same
thing.
You
will
know
that
the
implementer
will
know
that
others
won't
yeah
and
be
when
you
read
gee,
negotiate
and
prefer
to
select
the
same
thing.
You
did
last
time.
So
this
is.
These
are
two
things
that
should
go
in
this
draft
and
I.
Don't
think
we
should
say
much
more.
Okay,.
G
M
That
seems
to
raise
an
interesting
question,
which
is
I
mean
this
is
talking
about
one
mechanism
and
yet
we're
offering
a
discussion
of
how
does
one
negotiate
and
in
the
presence
of
support
for
multiple
mechanisms
in
this.
If
that
doesn't
belong
in
here
which
I
guess
it
maybe
does
us,
then
then,
presumably
it
belongs
simply
felt
that
in
something
yet
to
be
written
well,.
G
On
a
practical
note
for
implementers,
maybe
a
question
for
all
the
alternatives
were
talking
about,
are
really
abandoned.
Ids,
so
is
that
because
you're
fine
with
moving
to
anything
that
the
that
this
addresses
in
the
new
drafts
or
that's
because
the
current
experimental
solution
is
already
working
and
you
don't
so,
you
need
to
iterate
on
it
anymore
and
it's
gonna
live
forever
and
we
need
to
actually
work
on
systems
that
support
it
indefinitely.
G
K
Don't
know
this
jump
speaking
with
my
google
hat,
the
reason
why
the
drafts
have
not
progressed
s--
has
been
because
I
have
been
unable
to
make
the
group
that
is
in
charge
of
this
particular
work.
Take
the
time
to
update
them.
I'm,
sorry
about
that
it
was
not
my
decision
and
we
I
have
gotten
comments
from
that
group,
saying
that
they
will
consider
implementing
this
mechanism
and
switching
to
it
when
we
stop
fiddling
with
it.
K
G
The
transports
this
is
actually
not
document,
even
in
the
draft.
It
actually
doesn't
actually
say
that
right,
TC
FB
for
transport
CC
doesn't
exist
anywhere,
hey
job,
they
just
sniff
crumbs
STP,
and
you
get
you
find
out
that
that's
what
you
have
to
use
the
draft
itself
actually
doesn't
say:
there's
a
RTF
be
transported
CC.
J
G
Let's
ignore
those,
because
your
draft
is
not
going
to
deal
with
those,
but
your
draft
probably
should
deal
with
the
nack
issue,
because
I
think
Jonathan
are
different
pages
about
how
that
should
be
addressed
and
I'm
more
interested
in
having
a
single
solution
than
my
solution.
I,
don't
think
we
should
leave
it
open
if
yeah.
J
G
I
Yeah
I
mean
the
the
signalling
side.
I
would
very
much
appreciate
people
to
suggest
text
because
I
know
I
will
mess
it
up.
This.
I
I
I
mean
if,
if
I
mean,
if,
if
you
get
feedback
from
for
whatever
reason
that
the
packets
is
lost
and
you
support
retransmission,
there
is
nothing
stopping
you
retransmitting,
it's
the
same
way,
if
you
get
an
ACK,
there's
nothing
stopping
you
ignoring
the
neck
and
not
retransmitting
it.
These
are
all
advisers.
A
H
I
H
Yeah
there
some
my
personal
opinion
on
the
neck
thing
I
mean
here.
What
if
we
context,
this
idea
like
this
is
about
constant
control
and
all
this
thing,
and
actually
you
will
get
these
packet
loss
information
in
many
ways,
but
it's
still
maybe
you'd
like
to
send
neck.
So
I
cannot
say
here
and
for
my
condition,
if
you
look
into
my
condition,
corner
signal,
I
see
like
a
gap
and
you
actually
automatically
sends
an
iframe
and
for
your
receiver.
Fine
do
that,
but
the
receiver
might
have
other
reasons
to
send
an
ACK.
G
Etiquette
so
disagree
because
I
think
in
the
very
beginning
of
our
MCAT,
we
identified
that
this
feedback
is
not
just
for
congestion
control.
This
feedback
is
useful
for
both
congestion,
control
and
repair,
and
it
will
impact
things
like
effect,
percentages
and
retransmit
decisions,
and
things
like
that.
So
I
think
it
was
very
clear
at
the
very
beginning
that
this
feedback
is
is
gonna,
be
useful
for
both
congestion
and
the.
I
Feedback
provide
you,
the
information
about
which
packets
are
lost,
whether
you
use
that
to
send
retransmissions
or
not
yeah
I
mean
if
we
want
to
make
it
explicit
that
this
is
used
to
trigger
those
things
that
we
can
but
I.
Don't
think
we
want
to
require
the
fact
that
there
is
a
gap
in
the
sequence
space
to
require
a
retransmission,
a
hints
that
one
may
one
may
retransmitted
that,
but.
G
I
K
I'd
allow
this
job.
One
of
the
discussions
I
have
been
involved
in
in
feedback
format,
suggested
that
one
should
extend
the
format
to
have
a
to
give
the
the
explicitly
the
boundary
between
not
interesting
to
retransmit
I
mean
just
interest
map
transmits.
That's
something
I,
don't
think
they
have
any
feedback
format
now
and
I'm,
not
suggesting
we
add
it.
It's
just
one
of
those
things
that
indicates
that,
yes,
sometimes
you
want
to
read
just
nation
and
some
that
you
don't
oh
I'm
having
we
could
use.
I
O
Would
have
assumed
that
I
would
negotiate
neck
explicitly
separately
from
this
CC
FB,
and
this
is
only
for
for
bandwidth.
So
obviously
you
can
use
it
for
that,
and
actually
it
saves
you
something
if
you
use
it
for
both
purposes,
but
I
think.
The
main
point
is
that
both
sides
need
to
be
on
the
same
page
on
what
this
negotiated
thing
is
used
for.
I.
Think
as
as
ugly
as
it
is,
I
would
suggest
actually
then
provide
two
different
options
for
CC.
O
B
Yeah,
the
other
difference
is
that
max
can
be
sent.
You
know,
can
and
usually
are
sent
more
than
once
they're
set
repeatedly,
whereas
CC
FB
is
once
and
done.
You
know,
and
you
don't
want,
there's
some
packet,
you
really
need
to
repair
and
your
CC
FTP
Beckett's
lost,
get
out
of
luck,
whereas
the
backs
typically
every
transmit
for
duration
of
the
period,
which
would
be
useful
to
you.
So
that's
why
I
think
I
mean.
I
K
I
H
So
jagged
I
mean
more
I,
am
I
completely
sympathize
to
your
your
idea
of
like
having
this
kind
of
feedback.
You
have
impact
on
poorer
than
just
function.
Control,
so
I
agree
with
that.
I'm
sending
this
feedback
and
you
can
do
congestion
control.
You
can
do
a
lot
of
other
things
with
that
them
you
can.
You
can
have
a
quality
of
experience,
kind
of
map
and
stuff
like
that,
so
they
think
it
here
is
like
I
don't
want
to
like
in
first,
but
then
I
mean
what
can
I
offer
here.
H
You
can
your
interests
to
do
a
lot
of
use
this
in
a
lot
of
cases,
but
fun
for
me,
knack
is
basically
an
application
telling
me.
Can
you
send
this
to
me
explicitly
on
a
particular
case,
and
you
can
you
actually
gain
something?
What
not
sending
it
if
you
can
get
it
from
these
feedback
message,
but
I
don't
see
like
we
should
mix
them
up.
I
should
I
mean
I
mean
a
moralist.
Keeping
is
separate,
give
all
the
information
because
I
don't
know
what
sender
is
gonna.
Do
with
this
information.
I
think
the
problem
to.
I
H
My
problem
is
basically
I,
don't
for
for
Maurice
about
under,
but
I,
don't
know
like
what
a
conscious
control
that
sender
is
gonna
use
because
I
have
a
feedback
message.
This
is
not
coupled
to
a
conscious
control
or
what
the
sender
will
do.
I
will
not
prevent
a
receiver
to
export
more
explicit
thing
just
because
it's
sending
these
fit
references,
so
that
would
be
my
my
load.
I
mean.
I
H
I
Just
send
this
feedback
mechanism
and
the
sender
decides
to
send,
send
you
retransmission
here.
If
you've
negotiated
retransmission
the
sender
decides
to
send
you
them
or
it
doesn't
I
mean
you
know
it's
gonna
work
in
either
case.
The
question
is
whether
you
want
an
explicit
yeah.
You
know
you
have
to
send
me
retransmissions
if
you
get
these
or
whether
you,
whether
you're
comfortable,
if
the
sender,
picking
and
choosing.
I
B
I
I
I
About
the
offer
about
how
to
negotiate
offering
film
the
offer
ancestors,
but
so
if
the
offer
answer
stuff
I
think
the
suggestion
was,
if
you
are,
if
you
are
offered
multiple
congestion
controls
feedback
mechanisms,
you
should
pick
one
I
do
not
know
how
to
write
that
in
a
way
which
is
complying
with
all
the
various
offer
answer
extensions.
So
if
some
to
suggest
text
that
would
be
helpful
and
wouldn't
make
this.
B
I
I
We
need
to
provide
some
guidance
for
what
to
do.
That
should
probably
say
if
you
have
more
too
many
to
fit
in
the
MTU,
you
should
split
it
up
and
we
have
the
other
draft
in
our
MCAT
which
talks
about
how
to
pick
an
appropriate
feedback
rate.
So
this
isn't
doesn't
happen,
and
it
should
probably
point
to
that
to
say:
go
follow
that
guidance.
I
Yeah,
so
this
reports,
SS
RCS
in
sequence,
numbers
per
SSRC.
Some
people
have
implemented
this
congestion
control
with
a
single
sequence
number
space
in
a
header
extension
across
all
packets.
Obviously
you
it's
possible
to
map
from
this
to
the
single
single
sequence
number
space.
If
you
do
with
the
SS
SE
and
the
sequence
numbers
per
sss
here,
allows
you
to
do
different
flows.
You
know
with
different
congestion
control
algorithms,
but
as
the
ever
approach
requires
you
to
ingest
you
control
the
aggregates
or.
I
Yeah
or
I
mean
it's
hard
to
if
all
you're
getting
is
feedback
to
take
them
apart.
We
should
probably
try
and
put
some
guidance
for
you
if
you
are
using
a
congestion
controller
that
requires
a
single
sequence,
number
space,
here's
how
you
can
reconstruct
that
space,
at
least
sketch
out
a
hint
of
an
algorithm
and
yeah.
I
Obviously,
this
possibility
that
feedback
messages
should
get
lost.
We
should
have
to
say
some
words
for
what
the
congestion
control
should
do.
In
that
case,
I
think
the
specifics
are
clearly
you
know
dependent
on
the
congestion
control.
You
probably
don't
want
to
say
if
you've
lost
a
feedback
packet,
everything
in
that
packet
was
lost.
Equally,
you
probably
don't
want
to
assume
everything
was
received.
I,
don't
know
quite
what
the
right
thing
to
do.
There
is
probably
assume
that
the
the
loss
rates
was
comparable
to
the
last
into
away.
You've
got
feedback
with
some
decaying.
H
Yeah
I,
think
and
I
think
in
the
evil
test
and
dropped
in
iron
cut.
We
have
a
test
case
that
actually
chokes
your
reverse
bandwidth
and
so
idea
there
is
like
you
lost
your
feedback,
so
if
there
are
implementers
would
like
to
try
out
their
like
their
survivability
like
when
the
feedback
packets
are
lost,
they
should
go
and
test
that
one
I,
don't
think
this
is
need
to
be
addressed.
I
mean
we
can.
We
can
say
like
talk
about
the
implication
of
like
well.
H
I
I
Think
we
should
probably
say
the
congestion
control
needs
to
specify
what
to
do
and
assuming
that
everything
was
received
or
everything
is
lost,
may
not
be
the
right
thing
and
we
can
presume
he
also
refers
to
things
like
circuit
breaker.
Let's
say
if
this
stops
coming
back
for
too
long,
you
should
just
stop
sending.
Probably
the
path
was
broken.
B
D
Okay,
so
I
just
want
to
provide
some
information
of
the
status
of
our
of
the
payload
working
group.
Since
we
are
not
meeting,
we
haven't
been
to
a
couple
of
meetings
ready
most
of
the
people
who
write
those
documents
are
not
even
here
so
currently
we
have
the
the
one
that's
real.
The
people
are
really
here.
Are
the
flexible
effects
key
my
team.
D
G
We
had
a
long
long
discussion
with
between
the
author's
today
and
we
think
we've
been
able
to
resolve
all
of
the
issues
that
have
come
from
this.
Unfortunately,
I
think
the
solution
is
going
to
be,
you
know,
simplicity
and
clarity,
and
the
draft
but
unfortunate
I
think
it's
substantive
I,
don't
think
it's
a
minor
editorial
change,
so
there
it.
It
may
not
be
as
easy
as
just.
D
F
This
has
been
speaking
as
a
short-timer
ad
haven't
really
been
withdrawn.
It's
just
in
point
raised,
so
it's
not
going
to
go
into
the
our
theater
queue
until
whoever
the
ad
happens
to
be.
It
releases
it
to
it.
However,
if
we're
talking
about
material
changes,
obviously
the
working
group
needs
to
look
at
that.
If
they're
relatively
well
contained
changes,
it
might
be
so
simple
is
just
send
a
request
for
objection.
D
O
F
Q
Yeah
process
weenie
here
this
is
Barry
the
I'll
be
the
ad
taking
this
over
and
I
mean
I.
Think
technically,
once
it's
been
in
once
it's
out
of
the
iesg
evaluation
state
and
into
the
approved
state,
it
can
go
ahead,
but
that's
up
to
the
ad
and
the
IE
other
iesg
members
can
complain
if
I
make
a
stupid
choice.
So,
depending
on
exactly
what
happens,
we
may
decide
to
send
it
back
through
another
round
of.
Q
J
D
D
What
happened
here
is
that
during
the
time
in
which
this
document
was
in
the
working
group,
Etsy
registered
the
payload
type
name
in
the
in
the
in
the
page
in
the
general
payload
registry
dredges
in
a
yacht
in
the
general
I
atom
media
registry
yeah
there
registry
that's
a
slider
scheme,
so
the
authors
were
came
and
asked.
What
should
we
do?
D
Is
that
and
this
the
proposal
I
made
to
them
and
they
did
responded
after
discussing
also
we
discussed
it
also
is
the
area
director
is
that
will
they
will
look
at
what
was
registered
by
by
a
Etsy
and
if
they
have,
if
they
need
something
different,
then
they
can
use
a
different,
a
different
payload
type
name.
In
order
to
register
that
this.
F
F
D
I'll
talk
because
I
I
got
the
question
from
the
the
authors
of
this
draft.
What
to
do
I
send
responses
did
respond
back.
They
ask
me
same
things.
It's
a
problem.
If
we
don't
have
anything
to
do
just
we
just
withdraw
that
and
that's
over
I
to
talk
with
them
again
and
figure
out.
I
didn't
get
a
response
after
I
send
them
the
last
message
about.
If
there
is
a
difference,
what
you
want
to
do,
what's
your,
what
you
really
where
you
want
to
go
is
the
sorry.
The
cleaner
solution
would.
D
D
The
medium
subtype
was
registered
by
w3c
in
the
general
media,
subtype
registry
registry
Ana,
but
these
documents,
but
they
didn't
specify
an
RTP
payload.
They
just
registered
the
immediate
subtype.
So
after
discussing
the
author
of
this
draft
and
the
group
from
w3c,
the
conclusion
was
that
they,
this
draft
will
only
describe
the
payload
type.
The
RTP,
payload
and
they'll
use
the
registration
that
was
done
by
the
by
the
the
w3c
for
people
in
the
in
the
I.
Adore
Indiana,
media
type
registry
and
I'll
have
a
slide
to
discuss
this
problem
now.
B
So
my
co-author
said
he
had
an
update
for
it,
which
I
thought
meant
he
was
going
to
actually
publish
a
new
Rev,
but
what
he
did
is
he
pushed
something
to
the
repo
and
didn't
do
anything
else.
I
assumed
he
meant
I
assume
he
intended
that
I
actually
published
the
new
revision,
but
he
did
not
communicate
this
to
me.
So
I
think
that
is
partially.
My
fault
I
will
try
to
push
a
new
revision
with
the
change
he
made.
D
So
I
go
to
this
to
this
issue
of
the
registries.
We
have
two
registries
and
one
is
the
Diana
media
type
registry,
where
you
register
everything
and
there's
the
them.
There's
the
RTP
parameters
registry,
which
registers
the
media
type.
Currently
they
are
not
synchronized.
They
were
supposed
to
be
synchronized.
The
registration
should
have
been
in
the
same
in
both
of
them,
but
they
were
not
synchronized.
Some
of
the
payloads
are
only
in
the
general
media
types
and
not
in
the
RTP
one.
D
So
I
talked
about
I
mean
columns,
not
listening,
but
listening,
but
I
talked
to
it
with
my
previous
study
now
previous
cultures
in
this
work
like
English
Magnus,
and
about
some
history
about
why
we
are
using
both
of
them,
and
the
conclusion
was
that,
first
of
all,
something
that
the
this
the
payload
where
he
looked
just
need
to
do,
is
to
just
first
of
all
synchronize
them
so
they'll
have
the
same
information
in
both
of
them.
The
other
thing
is
that
my
understanding
is
that.
I
D
D
I
D
I
D
D
I
Q
The
the
issue
here,
I
agree
with
everything:
Collin
said
that
we
should
get
rid
of
the
RTP
registry.
Take
any
information,
write
synchronize
it
into
the
media
types
registry.
The
difficulty
is
that
the
media
types
experts
don't
know
about
RTP
stuff.
So
if
they
are
alerted
that
this
registration
involves
RTP
parameters,
then
they
can
contact
RTP
experts
to
help
them
do
their
review.
Okay,
so
we
problem
is:
if
the
people
registering
a
media
type,
don't
give
them
any
indication
that
that's
the
case.
I
I
Q
People
doing
the
registration
missed
that
and
the
media
type
experts
missed
that
then
then
you're
gonna
have
a
media
type,
that's
registered,
but
has
not
had
any
RTP
experts
take
a
look
at
it
now.
My
sense
is
that
that's
not
a
disaster.
The
media
type
registration
can
always
be
updated
later
or
marked
obsolete
in
some
way.
If
it
turns
out
it's.
I
But
my
my
suggestion
would
be:
we
either
get
rid
of
the
other
registry
or
probably
given
there.
It's
been
there
for
a
very
long
time
tell
the
ANA
that
whenever
they
register
a
media
type,
those
mentions
that
it's
suitable
for
ICP.
They
need
to
update
this
registry
I
think
they
already
have
that
guidance,
but
they
may
need
reminding
of
it.
B
Yeah,
don't
think
so.
The
one
thing
that
I'm
just
looking
at
the
I
on
a
page
right
now
and
the
odd
thing
is
that
the
reference
for
this
registry
is
RFC
48:55,
which
specifically
says
use
the
media
types
registry.
Don't
create
a
new
registry,
so
it's
possible.
This
table
is
just
shouldn't,
actually
even
exist,
and
it's
wrong
and
I
made
a
mistake
when
they
created
it.
So
that's.
Q
B
Q
Q
Q
D
So
so,
how
do
we
get
I
mean
the
product
here?
That's
why
I
go
back
to
this
slide
to
this
problem
that
we
have
with
this
one
where
the
registration
came
there,
okay,
in
the
middle
of
a
process
in
the
working,
we
were
working
on
that.
So
we
weren't
aware
that
he's
happening
at
all,
and
that's
was
that's
what
that
is
a
problem
right.
Q
F
So,
a
little
bit
a
little
bit
of
the
history
there,
the
reason
you're,
seeing
the
weirdness
with
4855
is
that
actually
updated
or
obsoleted
an
older
RFC,
which
was
one
they
created
on
this.
But
we
do
still
have
a
difference
in
the
registration
policy
for
each
one
of
them
and
I
haven't
actually
found
the
point.
That
makes
a
distinction,
but
the
RTP
media
type
has
a
I
believe
it
was
spec
required,
or
standardization
and
I
haven't
figured
out
where
the
ore
comes
from,
which
is
a
higher
requirement
than
for
the
media
types.
F
F
Q
D
Q
B
Q
Know
it's
not
that
the
experts
aren't
doing
their
jobs,
it's
that
them.
In
some
cases
the
the
requests
are
going
through
the
media
types
registry,
which
does
not
have
experts
that
know
about
RTP
and
the
requests
are
not
tagged
in
any
way
that
tells
the
media
types
experts
that
they
need
to
consult
the
RTP
people.
So
it's
not
that
anybody
is
doing
their
jobs.
It's
that
the
registrations
are
not
clear
enough
to
direct
them.
The
right
way.
M
Then
well
there's
something
wrong
here.
I
mean
break
right
now
that
header
for
the
registry
indicates
the
40.
What
is
it
48,
whatever
for
the
further
RTP
ones?
You
know
as
well
as
something
else
which
I
presume
is
just
for
the
regular
media,
so
both
of
those
you
know
you
know,
control
access
to
this
registry,
presumably
or
defined
procedures
for
this
registry,
seems
like
there
needs
to
be
something
whether
the
other
one
needs
to
specify
something
there.
M
Q
So
got
it,
so
what
we
have
to
figure
out
is
how
to
make
sure
that
somebody
comes
in
and
registers
a
media
type.
The
media
types
experts
know
that
they
need
to
consult
the
RTP
people,
because
this
one
is
related
to
RTP
and
there
isn't
any
way
to
do
that
now
unless
the
registrant
says
it
in
their
in
their
registration
request,
we've
relatively
recently
I
own,
maybe
four
years
ago,
updated
the
media
types
registration
procedures.
We
could
certainly
do
an
update
to
that.
J
Yeah
Jane
Sanford,
author
of
the
ttml
document
and
I
just
wanted
to
add
a
little
bit
more
context
in
that
the
case
that
we
have
had
and
the
media
type
was
created
and
I,
guess
that
the
original
authors
either
didn't
consider
the
RTP
might
be
an
option
for
transporting
it
or
it
was
just
seen
as
one
of
the
many
options
and
once
all
of
groups.
So
in
that
case
the
media
type
was
created
and
then
we
came
along
afterwards
and
said:
let's,
let's
create
a
payload
for
this
over
RTP.
J
J
I
:
Perkins
so
I,
just
looked
at
the
the
media,
type
registration
form
I
believe
it
looks
like
there's
a
this
format
is
framed
checkbox
on
the
media
side,
registration,
if
I'm,
remembering
right,
I
think
the
intent
was
that
that
was
a
signal
of
the
framing
was
a
TP
and
maybe
the
the
intent
of
that
has
gotten
lost
over
time
and
was
badly
documented
at
the
time
most
likely.
But
we
may
need
to
go
back
and
double-check
some
things
and
maybe
maybe
a
life
at
the
mic
line
is
in
the
right
time.
So.
D
F
D
Q
D
Q
D
Q
D
K
B
There's
actually
instructions
in
48
55
on
what
to
do
if
there's
an
existing
type
register
for
non
RTP
and
then
you're
adding
an
RTP
one
and
you
know
also
rules
it.
Yes,
it
has
to
have
the
same.
You
know,
format
and
the
same
parameter
set.
So
probably
just
read
the
relevant
sections
of
48,
548,
55
and
metal,
hopefully
tell
us
what
we
should
do.
Hopefully
we
were
smarter
back
then
than
we
are
now
and.