►
From YouTube: IETF99-PERC-20170718-0930
Description
PERC meeting session at IETF99
2017/07/18 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
C
A
Some
changes
in
the
note:
well,
not
not
a
lot,
but
some
things
that
you
highlighted.
There
basically
says
that
if
you
are
in
a
box
session
and
say
something,
then
that
belongs
to
ATF
as
well.
So
please
remember
that
and
what
more
changes
on
the
rst
there
are
two
RS
is
that
spoke
about
IPR
there's
one
on
both
have
been
replaced
by
one
RFC.
So
if
you
are,
if
you
have
any
questions
on
how
the
IPR
applies
to
your
park,
please
have
a
look
at
that.
Obviously,.
A
Thank
you
then
welcome
news.
Nils
is
from
Mozilla
he's
been
in
the
real-time
development
world
for
more
than
10
years
now,
and
he's
been
one
of
the
core
developers
on
the
web
party,
phished
acting
Firefox
and
also
he
has
been
active
reviewer
of
most
of
the
documents,
so
he
is
involved
in
the
design
of
it.
So
he
also
knows
a
lot
of
our
work,
so
welcome
nails.
C
A
Which
corresponds
to
the
repair
packets.
One
thing
that
came
out
of
the
virtual
interim
is
that
we
all
agreed
that
r-tx
could
not
be
done
the
way
it's
done
today.
You
have
encrypted
packet
in
Perkins.
We
need
to
work
to
RTX
on
that.
So,
if
not
a
big
progress
in
the
virtual
interim,
but
but
at
least
we
all
came
to
the
same
conclusion,
so
today's
giving
r-tx
another
retry
and
see
if
you
can
close
some
of
those
niches
to
park
milestones.
This
is
for
the
working
group
and
our
ad.
A
Our
milestones
expired,
and
we
just
slipped
my
mind
so
sorry
for
that.
So
next
slide.
So
this
is
a
new
proposal.
If
the
working
group
thinks
this
looks
good,
we
can
work
with
ADA
to
get
those
things
added.
So
what
we
are
trying
to
say
here
is
that
by
December
2017
we
will
try
to
get
the
SRTP
specifications
and
key
management
actually
submitted,
as
a
working
group
last
call
all
right
if
last
call
and
then
by
March
2018,
we'll
have
the
other
document
selected.
A
Okay,
I'll
take
that
as
saying
acceptance
excited
okay,
now
recap
of
milestones
on
documents,
those
things
that
are
bolded
for
the
ones-
that's
been
in
the
working
group
for
a
while
and
called
quite
a
bit
of
review,
but
also
having
accepted
as
the
working
group
documents
and
also
been
reviewed
by
some
security
area.
Folks
as
well,
and
we
as
a
typical
IETF
process,
we
would
want
to
kind
of
close
any
open
issues
with
those
documents
so
that
we
can
make
progress
in
the
working
group
and
there
are
some
other
documents
which
are
individual
documents.
A
Once
we
close
the
open
issues,
we
would
want
to
handle
those
documents
as
well
next
slide
so
agenda.
For
today
we
have
70
minutes
roughly
for
Colin
to
talk
about
the
open
issues
with
Park
today
on
the
repair
packets,
I
think
he
has
a
lot
of
slides
paper
for
that
and
good
amount
of
time,
and
then
we
have
Paul
talking
about
both
tunnel
and
framework,
because
David
is
not
here
so
he'll
be
talking
about
tunnel
and
framework
updates.
A
That
happened
and
if
the
time
permits
to
us-
and
we
would
want
to
see
based
on
how
our
discussion
goes
today,
how
do
we
want
to
move
forward?
Because
the
idea
is,
it's
been
a
you
know
that
we
have
made
a
real
progress
in
terms
of
the
document
moving
forward,
so
we
want
to
kind
of
see
where
we
are
with
the
open
issues,
and
what
do
we
conclude
by
the
end
of
this
meeting
and
see
how
the
working
group
has
the
whole
wants
to
work
towards
that
finish,
column.
D
D
So
good
morning
and
I'm
very
hopeful
we're
going
to
make
more
progress
than
we
did
in
the
interim.
We
learned
a
lot
of
the
problems
at
the
interim.
It
straightened
out
my
thinking
about
how
RTX
works.
Okay,
so
well
how
I'm,
gonna
sort
of
set
things
up
today
is
go
through.
You
know
our
big
open
issue.
D
Then
I
got
a
proposal
from
Sergio
and
I
about
what
we
could
live
with.
That
we
think
would
probably
be
a
good
path
forward.
So
let
me
start
with
that.
So
the
first
thing
I
want
to
touch
on
a
little
bit.
D
The
first
one
of
those
two
is
set
up
by
keying
through
the
JavaScript
sort
of
similar
to
s
des
basically
the
second
one.
The
second
SRTP
is
set
up
through
our
normal
DTLS
SRTP,
handshake
like
we
would
do
if
we
weren't
doing
anything
with
perc
at
all,
so
I
just
wanted
to
hit
that
you
know
at
the
top
level.
That's
that's
the
basic
approach
of
that
design
and
that'll
help.
It
make
more
sense
as
we
pull
it
into
the
more
detailed
things.
D
Okay,
the
first
one
I
want
to
talk
about,
is
flex
pack
now
flex
pack,
nothing
to
do
with
perc.
On
this
slide
here,
this
is
just
about
how
flex
effects
basically
works.
Okay,
it
is
reasonably
clear
that
it
can
either
do
fact
on
the
unencrypted
data
or
the
encrypted
data.
One
way
happens
by
default
and
you
would
need
signaling
specified
the
other
direction.
D
D
Here
we're
gonna
have
basically
three
designs:
you
could
do
your
you
could
do
the
repair
or
whatever
you
were
trying
to
do
after
the
encryption
before
the
encryption
or
somewhat
in
the
middle
of
the
encryption,
which
is
that
the
light
proposal
or
the
shim
proposal
from
previous
ones?
These
are
all
you
know,
same
sort
of
thing,
so
we
pretty
much
cover
the
design
space
here,
and
so
let
me
talk
about
each
one
of
these
in
each
other,
so
just
explain
these,
and
so
that
you
understand
how
I'm
drawing
these
diagrams.
E
D
We
probably
have
room
I
gotta
stay
in
the
pink
box
that
we
have
inside
of
the
SRTP
double
box
is
the
you
know
the
end
to
end
and
the
hop-by-hop
crypto
happening,
the
output
of
that
is
cached
used
for
repair
and
then
packets
that
are
repaired.
There
are
repairing
things
they're
operating
on
already
encrypted
data,
they'd
only
do
when
they
were
encrypted.
The
algorithm
would
be
set
that
there's
like
rtcp
and
that
they're
only
done
hop-by-hop,
not
indeed,
okay.
D
So
that's
the
a
design,
the
B
design,
largely
roughly
the
same,
except
what
we're
repairing
is
the
raw
media
before
it's
encrypted.
That's
what
goes
into
the
cache
and
then
it
would
be
double
encrypted
now
this.
Unfortunately,
this
design
B
here
is
the
default
way
that
our
T's
RTP
works.
If
you
aren't
doing
anything
else
like
that,
the
RTP
SEC
says
you
know
like
in
general,
things
are
that
unless
some
text
somewhere
says
there,
otherwise
this
case,
we
all
agree
that
the
media
distributor
cannot
do
repair
in
this
case.
D
Okay,
like
so
the
the
one
default
case
for
RTP
is
the
case
that
definitely
won't
work
now.
The
last
case
here
light
the
the
the
first
SRTP
end-to-end
encryption
is
that
first
one,
though,
that
we
were
talking
about
before
the
first
search
review
session
and
then
there's
the
second
extra
session,
which
is
the
hop-by-hop
ones,
and
what
would
be
cached
is
the
intermediate
result
of
that.
D
You
know
we
provide
the
protocols
to
make
them
work,
so
I'm
not
going
to
did
delve
deep
into
pros
and
cons
of
those
right
now
other
than
say
that
we
agree
they
work.
Certainly,
some
people
feel
that
this
would
be
more
work
to
implement
in
Chrome
in
particular.
So
it's
a
you
know,
implementation.
How
close
things
are
those
types
of
things
all
come
together
so.
D
Okay,
this
steps
into
it
just
a
little
bit
more
to
show
the
differences
of
some
of
the
stuff
I
just
saw
in
the
last
slide.
I
want
to
say
on
this
slide,
whatever
it's
just
a
little
bit
more
of
the
differences,
so
one
of
the
other
things
that's
going
to
happen
on
this
is
because
this
a
plan
which
has
occasionally
been
called
triple,
has
ended
up
the
joke
about
it.
E
D
D
It
has
to
undo
this
hop-by-hop
encryption
number
two
and
it
also
has
to
undo
the
hop-by-hop
encryption
that
would
have
happened
in
number
one
right
there,
okay,
so
it's
two
of
those
this
solution
down
here,
it's
a
a
there's,
only
been
one
right,
there's
only
Indian,
so
it
only
has
to
do
one
and
we've
we've
talked
about
this
I.
D
Don't
think
any
of
us
believe
that
the
encryption
time
is
a
big
difference
here
that
the
basic
issue
is:
this
only
happens
on
a
small
percentage
of
your
packets,
which
are
the
repair,
packets
and
the
crypto,
we're
using
the
sha-1
and
is
on
a
modern
intel
processor
that
happens
at
the
same
speed
that
you
can
mem
copy
data.
So
I,
don't
think
that
we've
been
arguing
that
the
encryption
time
was
a
major
difference
on
these,
but
people
have
been
talking
about
the
the
complexity
of
implementation
to
clean
Chrome.
D
D
Stepping
in
to
RTX
it's
a
pretty
similar
story
here,
so
keep
in
mind,
though
this
middle
way
is
how
RT
X
says
it
works,
and
so,
if
we
go
to
either
of
these
a
or
light
solutions,
we
do
need
to
write
some
extra
text.
That
says,
when
you're
using
RT
X
in
this
type
of
environment,
it's
a
bit
different
and
here's
what
happens
and
explain
whichever
it
is.
The
air
or
the
light.
D
So
you
know
this
is
basically
trying
to
show
you
know
we're
sending
packet
one
and
then
yet
hot
and
a
high
bandwidth
way
and
then
later
a
low
bandwidth
version
of
it.
It's
gets
pushed
in
with
two.
This
protocol
seems
to
be
an
unedited,
since
it
was
largely
published
back
when
it
was
first
done.
This
slide
is
courtesy
of
Colin
Perkins
from
ITF
37
in
96
sort
of
dates
this
next.
D
So,
there's
a
couple
of
ways
that
this
might
end
up
being
used
in
a
perk
contest
contact.
The
first
one
is
pretty
simple
and
is
pretty
classic
right.
The
end
point
is
perhaps
doing
run
redundant
encoding
with
a
high
band
width
and
a
low
bandwidth,
and
what
I'm
trying
to
represent
in
that
packet
coming
across
from
the
endpoints
of
the
media
to
serve
you,
the
h1
is
like
a
high
band
version.
D
High
bandwidth
version
of
you
know
packet,
one
in
the
stream,
and
it
also
carries
in
the
same
packet
a
low
bandwidth
version
of
the
audio
that
was
impacted,
zero
and
the
media
distribute
can
forward
those
on
out
to
the
endpoints.
The
endpoints
can
do
repair
and
it's
it's
Indian
that
that
works
very
seamlessly.
Now
people
have
talked
about
a
slightly
more
complicated
use
case
as
well
for
perk
where
the
endpoint
is
sending
to
the
there's
a
couple
variants
of
this.
D
D
The
media
distributor
is
perhaps
just
sending
the
same
thing
to
the
endpoints
and
it
starts
noticing
on
this
endpoint
here
that
it's
having
some
packet
loss
and
decides
well,
let's
start
doing
redundant
redundant
audio
for
that
now
in
in
no
way
is
it
gonna
be
able
to
access
the
audio
data
to
be
able
to
create
a
low
bandwidth
version
of
it,
and
none
of
our
codecs
support.
Some
I
mean
you
could
design
a
codec
where
you
could.
You
might
be
able
to
make
a
low
bandwidth
version
on
the
encrypted
data
or
something
but.
D
Anything
like
that,
so
they're
going
to
be
sending
the
same
high
bandwidth
data
twice
and
that
you
know
you've
got
to
be
careful
any
time.
Your
approach
to
congestion
is
to
double
the
bandwidth
of
something
but
well
I.
Think
what
people
that
sounds
funny
when
I
say
it,
but
in
fairness
to
the
people
who
do
this
I
think
what
they
do
is
they'll
have
like
800
bands.
You
know
800
kilobits,
total
bandwidth,
maybe
a
hundred
that's
audio
I'm,
just
making
up
the
numbers
out
of
the
blue
here
and
they
suddenly
decide
they
want
that.
D
The
conference
is
going
to
crap
and
they're,
going
to
up
the
quality
of
the
audio
and
they're
gonna
down
the
the
video
so
they'll
double
the
bandwidth
of
the
audio,
but
they'll
substantially
reduce
the
bandwidth
of
their
video
at
the
same
time,
so
that
they
don't
have
this
sort
of
congestion,
control
craziest.
But
anyway,
there's
lots
of
dragons
to
be
in
implementing
stuff,
so
make
sense.
F
G
D
You've
got
to
remove
some
bandwidth
you're
using
for
video.
For
that
to
make
sense,
is
that
answer
question
right?
Okay,
next
slide
so
redundant
encoding
is,
is
in
all
of
these
plans
done
by
basically,
you
know.
Let
me
start
to
the
top
one.
We
take
the
RTP
packet,
we
encrypt
it.
We
cash
the
the
double
encrypted
version
of
of
the
various
packets
in
time,
t0,
t1,
etc,
and
in
fact
we
never
send
the
original
packet
all
by
itself.
D
That's
always
going
to
be
packaged
in
red,
so
it's
sort
of
like
it's
always
a
repair
packet.
So
then
we
form
the
red
packet,
which
takes
these
two
t0
and
t1
packets
and
gloms
them
together
into
one
big,
RTP
payload
in
a
way
that's
defined
by
red
and
then
that's
hot
by
hop
encrypted,
because
the
date
is
already
done.
It's
it's
now.
D
H
D
Right
so
the
headers
no
just
been
here
long
yeah
with
read
the
the
primary.
The
information
is
going
to
come
from
the
primary.
You
understand
the
offset
of
what
the
sequence
number
is
of
the
other
thing,
so
you
can
recover.
Oh,
you
can
recover
the
sequence
number
which
effectively
allows
you
to
recover
all
the
information
you
need
and
the
times
yeah.
D
H
This
is
I
mean
you
need
to
write
a
lot
of
I.
Think
not
a
lot
a
lot,
but
you
need
to
write
sophistication
takes
four.
Have
you
actually
recovered?
Okay,
you
need
to
recover
how
you
recover
the
packet,
yeah
and
the
IV
etc.
In
this
case,
and
how
do
you
strip
it
and
what
so
you
don't
lose
too
much
information
you
can't
recover,
because
I
think
you
need
to
go
through
that
I'm
upset.
That's
look
on.
D
All
three
of
these
I
think
that
you
need
to
read
that
this
is
a
is
a
sketch
of
how
was
we'd
need
detailed
texts
that
showed
how
to
each
one
of
these
worked
and
I
I
think
this
works,
but
I
agree.
It's
not
one
sentence
in
the
draft.
That's
for
sure
right
so
again,
the
way
that
read
would
normally
work
is
the
one
way
that
would
not
allow
the
media
distributor
to
do
anything
and
in
the
red
case
we
could
choose
to
go
with
that.
D
Just
say
like
look,
you
can't
do
read
repair
in
the
media
distributor.
You
can
only
do
it
sort
of
end
to
end.
That's.
You
know
this
is
this
is
not
a
we
can't
choose
plant,
you
know
red
B.
We
could
choose
red
B,
but
with
light
it
has
probably
nearly
the
same
complexity
and
writing
that
up.
It's
nearly
the
same
text
between
red,
a
and
red
B,
to
talk
about
what
changes
to
red
to
make
it
work
on
the
encrypted
data,
it's
not
double
encrypted,
but
single
encrypted
and
and
would
work
roughly
the
same.
D
So
what
we've
been
talking
about
here?
I've
been
talking
around,
various
conversations
has
been
suggested
on
the
list
at
various
times
in
various
ways
is
about
taking
the
information
that
is
in
the
the
ohb
today
and
instead
moving
that
to
the
payload,
so
we
no
longer
have
to
negotiate
an
idea.
So,
first
of
all,
let
me
explain
how
it
works
and
then
talk
a
little
bit
about
pros
and
cons.
So.
D
The
right
now
we
have
an
O
HB
header.
It
has
a
length
based
on
the
length
you
can
tell
what
fields
are
in
it.
It
can
have
a
couple
different
fields,
a
couple
different
combinations
of
field,
of
the
things
of
what
it's
changed
and
it
carries
the
original
sequence
number
in
this
case,
or
some
other
feels
put
there
so
we'd
replace
that
the
length
sort
of
gets
more
Lehrer
player.
D
I
C
I
E
G
D
Sorry,
okay,
yeah
yeah,
okay,
what
I
mean
is
in
the
spec
we
throw
out
the
OHP
and
we
invent
this
new
text
that
carries
roughly
the
same
information.
We
used
to
carry
yeah
yeah,
okay,
so
the
bit
field
is
always
there
and
then,
depending
on
which
bits
are
set
in
the
bit
field.
You
will
find
a
variable.
You
know
you'll
find
either
the
sequence
number
or
the
PT
or
whatever
here
and
then
after
that
is
all
the
encrypted
media,
just
as
it
was
up
there.
D
D
Yeah
I
get
you're
saying
that
was
my
first
response
to
I
was
like
hey.
We
can't
do
that,
so
it's
different.
You
know
it's
no
longer
an
hour
to
be
packing
and
sérgio.
He
really
cleared
up.
My
thinking
on
this
I
think
he's
got
it
right,
which
is
know
these
transforms
in
SRTP,
substantially
changed
the
payload
of
the
packets.
They
add
tags
to
the
end.
They
add
you
know
here
we're
just
adding
some
information
to
the
beginning
and
when
you
go
to
decrypt
it
the
same
transform
that
decrypts.
D
It
knows
how
to
remove
all
of
this
information
and
return
it
back.
So
don't
think
of
it
as
we're.
Changing
the
payload
just
think
of
it.
As
the
encryption
process.
Add
some
metadata
to
the
front
of
the
encrypted
data
and
later
removes
that
metadata
and
the
metadata
has
to
do
with
what's
allowed
to
be
changed
and
what's
not
drop.
J
Like
that
was
going
to
agree,
this
is
the
part
of
the
crypto
transform,
not
part
of
the
not
part
of
the
payload
and
I
mean
I.
Could
bike
shut
it
and
say
well?
Crypto
transforms
typically
put
things
at
the
end
at
the
beginning,
but
I'm
not
gonna
make
sure
that
yeah
I'll
wait
till
we
have
agreement
on
the
general
approach.
I,
don't
think
anyone
would
be.
F
Just
to
clarify,
because
in
what
will
be
right
in
the
SDP
I
mean,
how
do
you
describe
this
in
the
SDP?
Was
yes,
if
you
have
to
do
a
pillow
top
number
and
the
name
of
the
of
the
of
the
of
the
payload
okay?
But
now
you
can't
do
it
age
of
64,
because
any
entity
that
would
look
in
the
middle
would
be
confused
by
that
it
will
try
to
do
it
as
an
age.
So,
given
answer.
K
So
Ronnie,
when
you
like
what
srgb
transforms,
as
has
been
said,
like
they
add
overhead
to
the
payload
right,
they
add
attacks.
Okay,
okay,
maybe
I'm
misunderstanding
well.
One
thing
I
did
thing:
I
got
up
here
to
emphasize
was
that
this
really
is
internal
to
the
transform,
because
whenever
this
is,
you
know
the
thing
that
actually
appears
on
the
wire
this,
this
chunk,
that's
added
to
the
beginning
is
encrypted.
So
it's
not
visible
to
anything.
That's
looking
at
the
packet.
J
Because,
okay,
so
Mason,
what
I'm
saying
is
I
mean
you
negotiate
it
as
I
mean
the
negotiation
is
the
payload
type
is
h.264
and
then
the
crypto
transform,
which
you
know
creating
DTLS.
But
if
somebody
wants
to
some
insane
person
wants
to
perk
with
s
test,
you
negotiate
nest
s.
What
it
would
say.
You
know
double,
and
then
this
is
the
inner
half
of
double.
K
So
slightly
different
way,
as
I
said,
the
thing
on
the
wire
is
just
opaque
bits
right,
it's
just
just
random
stuff
nobody's
trying
to
interpret
that.
The
thing
that
comes
goes
in
and
comes
out
of
the
SRTP
layer
is
the
payload
type.
You
expect
it's
it's
h.264
or
whatever
it's
just
after
that
gets
shoved
into
the
SRTP
layer.
This
extra
stuff
gets
added
as
part
of
that
encryption
process.
So
the
thing
the
payload
types
that
are
actually
visible
to
the
external
world
are
the
same.
K
D
And
and
to
be
clear,
the
this
is
not
really
in
any
way
signaled
in
SDP,
like
the
SDP,
if
you
were
doing
normal,
single
encryption
or
double
remains
the
same.
It's
the
DTLS
negotiation
that
negotiates
the
the
transform
sorry,
the
protection
profile
that
TLS
is
using
and
when
that
protection
profile.
Instead
of
being
you
know,
a
s,
GCM,
whatever
is
double,
then
this
transform
knows
to
do
this,
both
when
encrypting
and
removing
it.
When
decrypting.
D
There's
one
other
little
thing
here:
that's
a
sort
of
a
side
thing:
I,
don't
want
a
rathole
on
too
much,
but
I
do
want
to
just
try
and
check
with
the
working
group
and
see
if
we've
got
consensus
on
it.
Yeah
or
not.
I,
just
I
did
I
couldn't
really
follow
what
happened
on
the
mailing
list-
and
this
is
the
in
flack,
so
I
added
an
in
flag
here
and
the
use
case
is
when
VP
not
talked
all
these
kids
to
be
also
fix.
L
Yeah,
there's
lots
need
to
be
there
because
when
you
are
doing
you
know
when
you
are
doing
vp9
as
we
see
with
helium,
you
can
drop
the
later
layers
of
their
order
frame.
So
then
you
have
to
move
there
and
then
flash
for
the
lightest
bucket
to
operate
this
one.
So
if
you
drop
the
layers
in
there
in
this,
in
this
view,
you
need
to
modify
your
southern
flag.
D
So
more
question
hat,
for
you
was:
do
the
if
you're
doing
its
the
marker
flags?
Do
you
not
need
this?
Does
that
solve
the
problem
for
vp9,
or
do
you
still
need
this
to
you?
Do
you
know,
do
you
need
to
be
able
to
have
the
SFU
changed,
the
frame
marking
bits
or
the
omit?
If
you're
using
frame
marking
bits
can
be,
can
you
get
away
with
not
having
us
if
you
change
the
input.
C
M
L
If,
in
fact,
free
market
should
not
go
from
the
media
distribute
or
today
to
anything
because
it
they
don't
need
it,
they
will
decorate
the
media
and
they
will
have
access
to
the
media.
So
if
I
were,
if
I
was
going
to
use
it,
I
will
not
send
in
the
free
market
from
the
Middle
East
to
totally
to
the
endpoint.
So
hey,
when
do
you
are
doing
behind
the
LBCC?
With
this
later
on,
you
will
see
there.
L
You
will
check
the
frame
marks
to
see
if,
if
well
they
have,
they
have
chains
now
today
and
the
semantics,
but
they
you
say
that
the
larger
frame
is
hey.
What
this
day
and
the
scalability
discolor
the
Scala
will
a
layer.
So
if
you
drop
it,
none
of
the
RTP
packets
of
that
frame
of
the
super
frame,
it
will.
J
This
applies
to
any
specialist
callable
format
based.
The
idea
is
that
the
in
frame
marking
the
end
of
the
EBA,
it
means
end
of
layer
and
whereas
the
embed
and
the
RTP
header
means
end
of
picture,
and
in
particular
this
lets.
You
know
when
you've
actually
got
the
top
layer
of
the
picture
so
that
when,
if
an
S,
if
you
was
stripping
spatial
layers,
that's
let's
you
know.
Okay,
this
is
the
last
layer
of
the
picture.
I
should
go
ahead
and
displayed
it's
down.
C
Mogan
but
I
mean
part
of
the
whole
point
of
scalability.
Is
that
your
the
whole
point
of
scalability
is
to
is
to
be
able
to
drop
layers
and
if
there's
independence
among
layers,
that's
something
that
can
be
signal
independently,
whether
or
not
you
have
whether
or
not
you
you
want
an
indication
of
whether
or
not
you're
gonna
get
more
layers,
and
that's
not
really.
A
all
you
need
to
know
is
the
independence
between
the
layers
and
whether
or
not
you're
going
to
get
more
layers
is,
is
a
that's,
a
different
kind
of
indication.
F
C
Know
so,
if
you
look
at
practical
anybody,
that's
written
to
a
real
art
to
implementation
knows
that
the
marker,
but
is
notoriously
useless
for
almost
all
payload
formats.
You
cannot
rely.
You
cannot
rely
on
it
for
a
rendering
acceleration.
You
can
do
a
heuristic
to
see.
Is
it
reliable
for
for
this
or
not,
but
you
can't
ever
absolutely
it
actually
dark
to
you
specs,
a
you
can't
so
so
I
think
you
could
infer
this
in
in
in
the
same
heuristic,
without
without
having
an
explicit
marker
for
it.
J
D
So
let
me
try
to
hack
this
from
the
other
end,
which
so
it
seems
to
be.
There's
there's
some
argument
for
very
4sf
use
being
able
to
do
this
and
let's
look
if
there's
any
harm
on
that,
and
given
the
discussion
we
just
had
about
like
if
a
wrong
in
bit
causes
you
harm,
you're,
doomed
anyway,
I
really
don't
think,
there's
really
any
risk
or
security
problems
with
allowing
the
SFU
to
set
the
input.
D
I
mean
that
may
be
able
to
mess
up
calls
in
certain
ways
on
some
things,
but
the
DMC
you
could
equivalent
or
SF
you
could
equivalent
mess
up
things
just
by
dropping
packets
or
we're
right.
This
doesn't
extend
the
damage
in
SF.
You
can
do
in
anyway
doesn't
give
us
access
to
raw
media,
so
I
see
no
problem
in
doing
this,
and
so
you
know
some
my
feeling
is
we
should,
regardless
of
this
proposal
or
ohb
or
however,
we
do
it
that
we
should
probably
move
forward
with
adding
this.
D
D
This
RTP
payload
here
is
all
encrypted
and
the
SF
you
can't
modify
it.
It
can't
even
read
it.
It
used
to
be
able
to
modify
this
header
and
add
more
things
to
the
header.
So
if
the
client
initially
put
in
a
header
that
said,
hey,
here's
the
original
payload,
but
they
wanted
to
change
the
sequence
number.
Well,
you
know
the
the
SF
you
just
extended
the
OHP
and
add
a
sequence
number
to
it.
Life
was
good.
Can
no
longer
do
that.
D
The
client
has
to
set
this
bit
field
and
it
has
to
be
set
to
enable
everything
that
the
SFU
will
be
allowed
to
change.
It
doesn't
mean
the
SFU
has
to
change
everything.
That's
in
there,
so
you
know
one
strategy
would
be.
You
know,
set
these
bits
all
to
one
and
like
let
everything
be
changed
right.
That
has
a
bandwidth
impact
for
some
people
for
audio
and
don't
want
to
do
that.
So
we
need
a
way
for
the
client
to
be
able
to
know
what
bit
field
value
to
set
when
it's
encrypting
these
packets.
J
J
And
it's
clearly
not
in
the
RTP
payload
right.
It's
point
is
part
of
a
crypto
transform
because,
as
we
discussed,
it's
not
that's,
not
the
payload,
so
I
mean
if
the
SF
should
the
s.
If
you'll
be
able
to
read
these
fields
yeah,
your
argument
is:
it
is
useful
for
the
s.
If
you
do
not
to
be
able
to
read
these
fields.
The.
D
D
That
I
I
will
strongly
disagree
with
that
path
and
when
we
get
to
the
next
slide
of
you
know
what
we'll
agree
on
what
we
can
change
and
what
not
will
be
what
we
can
test,
discuss,
pros
and
cons,
but
so
proposal
roughly
is.
The
client
needs
some
way
of
doing
this.
That
could
be
an
API
that
just
set
it
through
JavaScript
or
whatever.
There's
many
ways
to
do
it,
but
one
way
that
we
would
standardize
it
as
a
possible
way
to
do
it.
Not
the
only.
D
Ich
in
the
DTLS
ekt
message,
the
extension
that
we
put
into
DT
LS,
that
comes
from
the
KD
back
down
to
the
client,
where
we
passed
the
ke
key
key.
We
would
add
another
optional
field
there
for
the
KD
to
pass
this
data
back
to
the
DTS
stack.
Now,
when
you
look
at
implementations,
it
actually
all
sort
of
lines
up
about
how
you
sort
of
want
it.
You
get
this
information
out
of
D
TLS,
which
is
the
same
place
that
you
found
out
that
you
were
doing
double
in
the
first
place.
D
You
feed
that
into
Lib
into
the
SRTP
implementations,
along
with
all
the
other
information
you
got
from
deal
DTLS,
like
the
you
know,
the
salt
and
the
keys,
and
whatever
it's
just
one
more
thing
that
gets
passed
along
with
that
data.
So
it's
all
sort
of
in
the
right
places
and
passed
along
the
right
path.
It
actually
works
out
pretty
well
I,
don't
want
to
say
that's
the
only
way
of
doing
which
is
saying
that
that
would
be
one
way
that
we
defined
it
so
that
we
had
a
full,
complete
story
that
that
worked.
C
D
So,
look
that
the
information
that
that
the
that
it's
good-
let's
jump
back
to
this
trust
issue
for
a
second.
We
have
been
very
careful
to
not
add
to
this
list
of
bits
in
this
thing:
the
ability
to
change
anything
that
we
believe
compromises
the
security
of
the
system.
So
if
the
MD
says
always
I
want
to
change
everything,
that's
possible
to
change.
Okay,
some
embiez
will
most
definitely
do
persons.
Some
of
the
SF
use
will
most
definitely
do
that
right.
D
That
doesn't
mean
her
still
has
all
the
security
properties
that
we
expect
Perth
to
have
it's
fine
I,
don't
see
a
security
problem
with
that.
The
only
issue
with
that
is,
we
only
use
up
more
bandwidth
than
an
SF,
you
that
said,
hey
I,
don't
need
to
change
anything
and
there
will
be
SF
use
that
do
not
change
any
of
these
things
right
and
that's
been.
D
D
J
J
Then
you
don't
have
to
waste
bandwidth
on
the
uplink,
even
if
the
MD
is
adding
another
downlink
and
then
what
this
end,
you
know
if
the
MD
decides
to
start
lying
about
it.
Well,
your
end
to
end
off
will
fail
and
you
don't
get
any
media
and
somebody'll
call
up
the
MD
and
say
hey
what
the
hell
so,
okay.
D
Iii
I
think
I
probably
live
with
that
I'll
think
I'll.
Think
about
that
more.
But
let's,
let's,
let's
see
other
people
have
problems
with
with
that
type
of
design
approach.
If
we
went
that
way,
I
mean
we've
had
lots
of
implementers
on
the
ohb
say.
Please
please
please.
We
want
the
client
to
put
the
O
HP
and
then
have
it
basically
right
instead
of
having
the
immediate
distributor
inserted.
So
I
yeah.
L
I
think
that
the
one
of
the
benefits
of
AD
in
the
end,
the
payload
in
there
in
there
in
the
end-to-end
transformation-
is
that
the
SVU
distance
does
not
need
to
change
anything.
I
mean
you
don't
need
to
change
anything
in
the
MDM
to
make
it
work.
I
mean
you
just
receive
that
data
from
one
endpoint
and
you
just
transport
it
really
to
an
endpoint.
In
fact,
we
have
implemented
it
in
jános
and
you'd
see
just
with
free
marking
and
it
works.
L
I
mean
you
don't
need
to
change
anything
that
the
video
does
not
need
to
change
to
to
care
at
all
about
the
HP
me.
Yes,
get
it
from
one
side
and
put
it
together.
I
mean
there
is
a
comparison
value
wait,
but
this
is
yes
to
three
bits:
the
fruity
bytes
and
you
are
adding
a
32
task
to
the
inner
transformation.
So,
yes,
I
mean
you
are
wasting
a
lot
along
with
anyway.
Okay.
D
So
all
of
this,
let's
go
to
the
next
slide
here
for
a
second,
so
this
really
gets
the
proposal
of
what
we're
proposing,
changing
or
a
consensus
proposal
on
this,
and
this
is
all
group
together
thing
I
think
with
with
the
group
of
us,
this
sort
of
comp
said
we
could
live
with
this.
We
can
live
with
this,
but
not
bits
and
pieces
of
this.
It's
all
or
nothing
right.
D
We
were
talking
about
on
the
previous
slide
of
moving
it
into
the
pelo
header
and
we
can
modulo
the
bike,
shed
details
of
that
and
go
with
the
lines
that
were
a
for
red,
r-tx
and
flex
back
in
the
in
the
previous
designs
and
certainly
well
or
Magnus's,
comment
that,
like
non-trivial
text,
required
to
make
those
things
happen
and
then
the
last
one
on
DT,
math
and
I.
Don't
think
anyone
cares
about
this
one
deeply
we
could
change
this
one
is
DTMF
will
dealt
with
is
into
end
media.
It
is
not
some.
D
D
A
So
I
think
we
have
been
on
this
issue
for
close
to
two
more
than
two
idea
of
meetings
and
right
now,
what
I'm
hearing
from
Colin
and
like
others
is
that
they
have
a
proposal
that
they
can
leave
it
both
the
double
and
light
they
have
come
up
with
their
proposal.
So
if
the
working
group
kind
of
thinks,
the
three
points
are
color
and
straightest
if
they
think
they
can
live
with
it,
I
want
a
church
would
want
to
know
the
consensus
here.
K
D
M
C
M
That
was
going
to
be
there's
going
to
be
placed
it.
So
when
the
encryption
encryption
transforms
call
is
going
to
be
inserted,
then
the
hop-by-hop
encryption
performs
an
end
an
encryption
for
for.
But
if
we
do
that,
the
receiving
end
point
won't
get
the
decrypted,
so
that
will
have
to
be
done
in
the
middle
in
between
hop
and
then
did
unless
I'm
confused
about
something
you're.
D
N
D
J
B
B
D
B
J
Okay,
so
you
actually
are
doing
effect
over
the
HP
and
I
guess
that
might
argue
more
for
against
my
previous
thing
of
footing
and
not
putting
it
in
the
of
saying
they
don't
have
to
send
it
up
from
the
original
things.
I
guess
it
doesn't
need.
I
guess
needs
to
be,
and
then
that's
an
argument
for
setting
up
from
the
original
clients.
I
think
I.
D
Think
that
this
proposal
to
work
has
to
be
set
by
the
original
clients,
I
think
it's
very
maybe
there's
a
way
to
design
it,
so
the
middle
could
modify
it,
but
the
way
I
had
run
through
in
my
head
and
tried
to
check
with
myself
that
I
believed
it
would
work
and
okay,
we
were
all
thinking
about.
It
was
definitely
it
was
set
by
the
client.
J
D
D
And
look
I
think
in
any
of
this.
It's
it's!
You
know.
Consensus
is
at
a
point
in
time
and
where
what
we're
talking
about
here,
when
we
write
down
the
details
of
this
draft,
we
may
find
a
gotcha
that
none
of
us
are
thinking
of
that
causes
have
to
come
back
and
rethink.
This
I
I
fully
understand
that
yeah.
K
You
can
at
least
see
see
how
it
works
at
that
levels
and
verify
that
the
transform
works
and
we
can
get
the
configuration
yeah.
That's
that
I
don't
have
no
code
for,
but
do
what
I
can
I
just
wanted
to
confirm
my
understanding
here.
The
order
of
operations
here
and
kind
of
where
this
new
OHP
goes
so
the
the
is
the
order
of
operations
here
that
you
take
the
original
paleo
payload.
You
do
the
encryption
over
the
original
packet.
You
append
the
ohb
to
that,
and
then
you
do
the
external
transform.
That's
your
operations
again!
F
C
You
know
points
of
the
proposal
is
that
I
think
the
motivation
for
this
is
really
not
on
here.
The
motivation
for
this
adds
a
fourth
bullet
that
you
don't
want
to
deal
with.
Arts
be
header
extensions.
You
don't
want
that.
I
think
that
one
of
the
tenants
of
light
was
we
don't
want
to
allow
RTP
header
extensions
to
be
anything
in
in
park,
they're,
just
regular
things
that
you
can
always
manipulate.
C
L
Are
several
reasons
of
why
or
you
know
he
chose
to
do
that
that
way,
man
first
is
I,
didn't
want
to
handle
and
to
cover
into
talking
about
hair
extensions
on
the
h-e-b
sense.
Second,
that
I
don't
think
that
it
is
wise
to
introduce
a
concept
of
or
but
in
in
the
HP,
in
the
hair,
extensions
how
we
were
going
to
do.
K
L
Depending
on
what
you
put
speed,
the
essential
mean,
what
is
for
another
I
think
is
a
huge
change
of
what
anyone
is
implemented
today
and
also-
and
we
could
even
implement
and
to
end
extend
a
hair
extension
so
data,
but
put
it
into
the
bailout
anyway,
because
it
is
were
it's
meant
to
it.
I
mean,
if
you
put
it
as
we
have
a
bit
feel
if
we
find
any
use
case
that
we
do
have
not
found
any
today
that
we
need
to
Gary
some
data
from
one
endpoint
to
all
the
other
endpoints
we
could.
L
K
Yeah
I
think
I
was
gonna,
say
basically
what
Sergio
said
I
think
in
the
in
this
proposal.
I
think
as
we
grafted
it
here,
you
do
lose
the
end-to-end
the
ability
to
have
end-to-end
protective
extensions,
but
that
said,
the
mechanisms
in
double
right
now
is
kind
of
lame
and
not
really
implementable.
I
think
it's
heard
you
said
like
if
there
is
a
desire,
if
there's
a
use
case
this.
D
Yeah,
we
add
one
of
the
bits
and
the
field
indicating
that
there
was
an
offset
header.
That
said
what
the
Indian
crypto
won't
work,
so
we
can
certainly
that
if
we
want
it,
these
guys
I
had
previously
argument
that
there
were
RTP
Hatter
extensions
that
should
be
Indian
protected
and
the
example
I
had
was
the
video
orientation,
CEO
and
I.
Think
these
guys.
You
know
successfully
convinced
me
that
I
was
just
being
in
the
otic
that,
like
you
know,
if
the
SFU
wanted
to
rotate
your
video
on
you.
That
was
really
nothing
it.
D
A
B
A
A
D
Really
great,
that
was
the
hardest
problem
we
have
to
deal
with
the
Newark
group
by
far,
thank
thanks.
Everybody
who
spent
the
time
to
let
me
understand
their
issues
and
make
this
happen.
Okay,
ekt
next
slide,
there's
no
open
issues
with
it,
but
given
the
consensus,
we
just
had
it
on
the
previous
one.
We
do
need
to
add
an
extension
in
here
into
the
detail.
Se
Cayo
message
as
a
way
of
carrying
this
bit
field
value
in
ew
t
so
we'll
make
that
change
to
the
next
rep
of
this
draft
as
well.
So.
K
D
K
K
J
Little
concern
Oh
concerned
about
is
exactly
what
the
we
need
to
explain
exactly
what
the
future
extensibility
here
works.
Like
you
know
what
happens
if
I
say
you
know,
you
know:
hey
yeah
I
want
you
to
be
able
to
change
bit.
Six
and
I
have
no
idea.
What
bit
six
means.
Does
that
a
fail?
Is
that
I
have
a
way
to
go?
She
ate
that
down.
J
D
Two
shilling
for
Richard
here,
Richards
proposal
is
that
we
make
each
one
of
those
different
combinations
of
things.
You
can
change,
be
a
DTLS
protection
profile,
so
the
client
in
the
DTLS
messages
will
advertise
up
all
the
things
that
can
support
the
the
the
key
distributor
will
choose
the
one
it
wishes
you
used
and
you
know
we'll
have
a
normal
handshake
and
we'll
get
it
so
Richard.
My
way
of
just
transferring
is
optional.
D
D
M
Okay,
so
so
this
is
an
update
on
the
afternoon
and
now
potentially
obsolete
sort
of
drafts.
Maybe
tunnel
doesn't
change
that
the
other
ones
probably
will
so
what
what's
new?
There's
some
editorial
changes
to
the
tunnel
draft?
We
incorporated
DTLS
I'm
sort
of
the
tls
ID.
They
got
changed.
The
name
changed
there.
M
In
the
last
meeting
we
talked
about
introducing
that
to
avoid
having
to
have
the
commerce
within
a
fire
so
that
I
got
incorporated
into
the
TL
into
the
national
draft
and
and
then
we
addressed
other
comments
that
were
raised
during
the
last
IETF
meeting.
So
you've
got
our
next
slide,
so
the
TTLs
ad
will
not
be
utilized,
and
so
it's
just
rehash
what
I
just
said.
But
anyway,
then
points
will
be
required
to
include
the
TLS,
ID
and
STP.
So
that's
just
something
to
keep
them
keeping
keep
in
mind
and
the
background.
M
There's
an
editor's
note
says
the
the
process
through
which
the
TLS,
ID
and
STP
is
conveyed
to
the
key
distributor
is
outside
the
scope
of
this
document,
and
the
above
text
could
be
removed.
If
we
agree
that
the
mediator
trigger
will
always
forward
SDP
to
the
key
distributor.
That
said,
should
the
media
see
root,
should
the
media
server
take
take
on
this
function
or
or
should
we
have
something
else
in
the
call
control
plane
dealing
with
that
and
getting
that
information
to
the
key
distributor?
D
Yeah
I
prefer
that
too
there's
a
certain
group
of
people
who
would
like
to
get
rid
of
SDP
altogether,
yet
still
continue
to
be
able
to
use
these
types
of
mechanisms,
so
they
don't
want
to
create
dependencies
on
STP,
but
they're
fine
with
us
forwarding
the
ID,
obviously,
and
if
how
you
do
that
is
forward
all
the
STP.
That's
fine
for
this,
but
I
think
it'd
be
better
not
to
require
something:
that's
not
really
needed
so
I.
You
know,
let's
just
say,
for
the
detail:
the
TLS
ID.
However,
you
do
it
so
maybe.
M
The
the
there
used
to
be
a
DTL
SS,
RTP
association
tunnel
affinity
that
that
is
whenever
you
set
up
a
DTLS
SRTP
connection
and
through
a
particular
tunnel
between
the
md
and
the
key
distributor.
There
was
a
requirement
before
that.
Every
message
go
over
that
saying:
DTLS
SRTP
grows
over
over
the
same
tunnel,
sorry
over
the
same
tunnel
between
a
mediator,
orbiter
and
the
key
distributor
that
requirement
was
removed.
M
So
if
the
media
distributor
establishes
five
different
tunnels
to
the
key
distributor,
the
key
distributor
can
send
messages
over
any
one
of
those
five
and
that's
be
possible
because
every
session
is
identified
uniquely
anyway.
So
it
doesn't
really
matter
which
connection
it
comes
over,
so
that
that
was
changed.
M
There's
a
there's,
a
new
text
that
explicitly
states
that
mutual
TLS
authentication
is
required.
Don't
think
that
was
there
before,
but
it
was
intended,
but
it
is.
There
now
required
a
key
distributor
to
send
an
endpoint
disconnect
whenever
certain
events
occur.
So
this
this
this
is
a
way
to
know.
For
example,
if
the
endpoint
says
up
the
detail,
SS
RTP
connection
to
the
the
key
distributor,
but
for
some
reason
that
that
fails,
the
meatiest,
riveted
and
otherwise
know
that
it
failed.
M
So
now
the
the
key
distributor
can
inform
the
media
distributor
that
it
did
fail
and
the
Association
ID
is
now
a
UUID
before
I
forgot
what
it
was,
but
we
changed
it
there
in
the
meeting,
I
guess
during
the
last
meeting
it
was
Ezra
to
make
that
change
to
use
a
UUID.
So
next
line,
there's
a
bit
of
text
on
versioning.
Well,
I
have
one
version
so
far,
but
we
still
have
to
discuss
what
we're
gonna
do
going
forward.
M
So
there's
a
there's,
a
response.
If
you
see
me
the
key
distributor
initiates
a
connection
to
the
media
distributor
me
distributor
sends
over
its
supported
versions.
If
it's,
if
it's
not
supported
the
key
distributor,
respond
back
and
say,
here's
my
highest
supported
version,
so
that
was
added
also
the
version
field
is,
is
only
on
the
very
first
message.
Now
we
used
to
have
it
in
every
single
message,
so
we
took
that
out.
So
it's
just
in
the
first
message.
M
There's
a
shorter
version,
length
field,
put
the
message
type
before
the
message
links
and
then
the
version
where
they
stuff
that
I
mentioned
and
if
there's
anything
else,
I
can't
remember
what
it
is,
but
those
are
the
main
points.
All
the
UUID
field
are
the
ID
value
that
that
changed
I,
don't
think
that
changed
the
syntax,
but
it
may
have
alright
next
line.
M
In
the
example,
at
the
end
of
the
document,
there's
there's
an
example
of
what
the
actual
encoding
looks
like
on
the
wire
just
what
well
the
message
doesn't
binary
format
looks
like
that
was
changed
to
use
two
now
registered
double
code
points
so
that
we
actually
do
have
double.
If
that
may
change
as
well,
given
just
the
discussion
we
had,
but
there
is
some
code
points
register
for
double
and
we
use
those
in
the
example
and
I
think
that's
it.
M
I
M
M
Was
on
the
on
the
beach?
So
this
is
that
the
the
media
framework
document,
certainly
if
tunnel,
isn't
outdated,
I
guess
this
one's
going
to
be
up
anyway.
It's
it's
current
as
of
before
this
meeting,
so
the
next
slide.
So
the
the
there's
just
a
few
minor
things
that
we
did
to
this
one.
We
introduced
two
new
appendices.
One
of
them
is
a
just.
It's
intended
just
to
provide
an
overview
of
what
the
keys
are
that
we're
using
in
perk,
because
there
are
several
keys,
and
that
does
seem
to
cause
some
confusion.
M
So
it's
actually
multiple.
There
actually
could
be
multiple
concurrent
keys
of
any
sort
in
the
system,
so
it
got
confusing.
I
just
removed
all
that
text,
and
so,
if
we
just
refer
to
the
the
hop-by-hop
key,
the
end
end
key
and
yes,
the
the
hop
by
hop
key
can
change
the
end.
The
end
key
can
change
and
then
make
keys
more
likely
to
change,
then
the
hop
by
hop
key,
but
it
the
end
point
can
fabricate
a
new
key
anytime
I
wanted
to
and
then
send
about
Anthea
into
in
the
RTP
packet
when
it
encrypts.
M
So
there's
a
little
more
language
to
explain
the
keys
and
big
usage
in
section
4.2.
So
just
a
new
paragraph
added
there
and
throughout
the
text
I
tried
to
change
the
e
key
T
key.
Sometimes
it
was
written
together.
Sometimes
it
was
written
separate.
My
goal
was
changing.
That
was
to
try
to
make
sure
to
line
with
the
ekt
light
draft.
M
So
Appendix
A,
just
this
is
the
key
inventory.
We
just
list
the
keys
that
are
used,
so
we
have
the
key
the
ke
key
in
the
ekt
key
and
the
they
have
the
hot
key
in
the
end
n
key.
So
we've
got
those
three
keys
and
then
there's
a
couple
of
pages
of
text
that
goes
on
to
explain
those
again.
Like
I
said
it's
all
new
text
I
welcome
any
input
suggestions.
It's
just
intended
to
be
informative,
not
normative.
M
M
So
if
you
go
the
next
slide,
Appendix
B
is
just
a
packet
format
which
now
the
ohb
is
in
the
wrong
place
so
that
that'll
have
to
be
moved.
Otherwise.
It
may
largely
be
this
thing,
but
this
is
just
intend
to
show
what
the
packet
looks
like
on
the
wire
and
the
reason
for
that
was
even
I
got
confused
because
I
thought
the
ekt
field
was
somewhere
in
the
middle,
but
it
wasn't
so
that's
that
I
think.
That's
all
so.
C
J
M
C
M
Because
we're
probably
going
to
go
around
on
on
this,
this
change.
The
tunnel
draft
sounds
like
it's
not
really
going
to
have
any
significant
impact
from
those
discussions,
so
it
it
may
actually
be
closer.
So
maybe
there's
no
change,
but
certainly
I
would
welcome
some
some
feedback
if
you
find
anything
in
the
document.
Good.
Thank.
A
A
D
Mean
I'm
really
motivated
to
get
this
done
as
fast
as
possible
before
everybody
changes
their
mind
so
but
I
I'm,
so
getting
done
this
week,
I
think
I
think
in
the
next
few
weeks,
I
should
expect
to
have
the
double
changes
out.
I
think
that
working
through
all
the
details
of
the
r-tx
red
flex
pact
that
we
will
probably
stage
this
out
one
at
a
time.