►
From YouTube: IETF100-MMUSIC-20171116-1330
Description
MMUSIC meeting session at IETF100
2017/11/16 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
E
All
right
welcome
to
music
at
IETF
100,
so
sherry
today
by
myself
and
Ari.
You
know
a
blast
from
the
past
here,
so
it's
not
I,
guess
I
gotta
get
closer.
Can
you
hear
alright
so
welcome
to
music
IETF
100
chaired
by
myself,
funny
injuries
in
re,
Karen,
again,
Bowl
couldn't
make
it
this
time.
Sorry
has
kindly
agreed
to
step
in
and
help
us
out
note
well
statement.
I,
guess,
you're
all
familiar
with
that
one.
If
not,
please
take
a
close
look:
administrative
stuff!
We
have
the
blue
sheet
circling
around
I.
E
Guess
you
guys
know
how
that
works.
So
we
don't
have
to
go
over
that
getting
help.
We
already
have
two
note
takers
identified.
So
thank
you
for
that.
The
ascribe
is
well.
Thank
you
Jonathan.
So
we
had
that
covered
too.
As
always,
when
you
speak,
please
make
sure
to
use
the
microphone
and
state
your
name.
We
do
have
a
remote
participant,
so
using
the
microphone
in
particular
is
important.
Otherwise
they
can't
hear
you
just
a
general
requests
for
people
to
please
help
out
with
document
reviews.
E
The
energy
level
in
the
group
is
not
all
that
high
and
we've
had
several
documents
that
we've
gone
through
working
group
task
calls
on
and
we
have
got
very,
very
limited
feedback
from
from
the
group.
In
some
cases,
no
feedback
at
all.
We
really
need
some
participation
and
even
if
you've
looked
at
it-
and
you
don't
have
any
comments,
please
just
send
a
note
to
that
effect
and
keep
in
mind.
If
you
don't
review
anybody
else's
documents,
you're,
probably
not
gonna,
get
your
own
documents
reviewed
either
it's
a
two-way
street.
E
E
Our
agenda
here
today,
introduction
and
status
update
I
will
just
go
over
where
the
various
documents
are
at
and
what
it
looks
like
in
terms
of
the
arts.
You
see
what
dependencies
that
we
have
and
then
there's
some
open
issues
that
have
come
up
in
simulcast
and
some
of
them
actually
affect
the
writ
draft
as
well.
So
we
only
call
out
simulcast
here,
but
it's
really
both
simulcast
and
grid
that
are
being
affected
by
this.
That
is
the
proposed
agenda.
Let
me
ask
if
anybody
has
any
comments
on
the
agenda.
I.
E
See
you
know
so,
let's
just
continue
into
the
working
group
status
in
terms
of
published
RFC's.
We
don't
have
any,
but
we
got
several
documents
that
have
nominated
into
the
OFC
editor
queue,
basically
waiting
for
other
normative
reference
documents
to
work
their
way
through
so
I.
Think.
The
good
news
here
is
that
we're
getting
a
lot
closer
to
actually
getting
a
lot
of
these
dependencies
resolved.
We
have
two
requests
for
publication
right
now.
Actually
we
only
have
one,
but
it
shows
to
you
right
now,
so
you
know
wait.
E
We
submitted
yesterday
in
the
apparently
very
naive
hope
that
we
could
move
it
forward
that
way,
as
the
discussion
today
will
show.
You
know
that
was
a
little
too
optimistic,
so
that
I
don't
know
if
it
already
has
been
pulled
back.
But
it's
not
it's
being
pulled
back
okay,
it
will
be
pulled
back
from
that
shortly,
but
hopefully
it's
just
a
very
short
and
temporary
setback.
While
we
discuss
the
issues
here
today
and
then
get
some
updates
in
trigger
lies
sip.
On
the
other
hand,
that
should
be
fine,
so
that's
moving
forward.
E
The
ice
working
group
is
moving
forward,
will
trickle
eyes
as
well.
So
we've
seen
good
progress
there
too,
and
we
have
the
ice
cream
group
Koecher
here
as
well.
So
if
anybody
has
any
questions
on
that
I'm
sure
we
can
cover
that
4566
bits
that
is
ready
to
move
forward
as
well.
That's
just
basically
up
to
the
Sherratt,
which
is
me
to
get
to
review
and
the
write-up,
but
we
don't
expect
any
issues
there.
So
that's
ready
to
move
forward
in
terms
of
working
groups
of
consensus
documents.
E
We
had
the
data
channel
SDP
neck
document,
which
the
Shepherd
I
did
a
review
of
and
asked
for
some
changes
and
the
author
team
on
that
document
is
virtually
non-existent
at
this
point
and
they
have
agreed
that
they
need
help.
So
we
are
looking
for
a
volunteer
that
can
help
move
that
document
forward.
I
mean
it
says
it's
essentially
done
at
this
point,
but
the
authors
just
don't
either
have
the
cycle
is
or
the
energy.
E
So
if
anybody
is
willing
to
step
up,
we
would
greatly
appreciate
that,
if
not
I
mean
STP
net
yeah
data
channel
STP
neck
can
I
get
bit
after.
F
G
C
E
All
right,
simulcast
we'll
talk
about
that
one
today,
but
hopefully
that
should
be
moving
forward
pretty
soon
I
sip
SDP.
There
was
one
comment
from
the
working
group.
Last
call
we're
still
trying
to
get
the
author
to
respond
to
that
one,
but
hopefully
that
won't
require
a
whole
lot.
So
we
can
move
that
one
forward.
The
working
group
last
call
has
completed
and
again
the
corresponding
specification
and
ice
52:45
Biss
eyes,
essentially
ready
to
move
forward
there
as
well.
E
So
we
don't
foresee
any
issues
with
that
and
of
course
we
got
bundle
which
Krister
is
working
his
way
through.
Addressing
the
the
last
set
of
comments,
there's
been
several
pull
requests
that
have
been
circulated
on
the
list
already.
If
you
haven't
taken
a
look
at
them,
you
know
please
do
we
work
in
Google.
Ask
all
this
document
several
times
already,
so
you
know.
Hopefully
we
don't
have
to
do
that
again,
but
yeah.
D
E
Other
working
group
tasks
that
are
not
in
the
agenda
are
already
covered.
Msrp
use
its
data
channel
same
issue.
As
with
the
data
channel
STP
neck
document,
we
need
to
data
channel
STP
neck
document
first,
so
we
haven't
put
a
lot
of
emphasis
on
this
one,
but
again
and
I
forgot
to
check
actually
whether
this
is
an
RTC
with
dependency
or
not.
But
if
anybody's
interested
in
is
not
okay,
okay,
all
right,
so
that
so
that
might
be
less
of
an
issue,
but
we
are
in
the
same
situation.
E
Essentially,
the
authors
do
not
have
time,
slash
energy
to
pursue
this
document
right
now.
So,
if
anybody's
interested
in
moving
this
forward,
we
need
somebody
to
help
out
a
new
author
on
this
document.
So
I'll
ask
for
volunteers
here
again,
and
you
know
we'll
repeat
that
request
in
the
minutes
as
well.
H
Okay
thanks
mr.
quick,
quick
question
on
so
also
some
dependency
that
we
shouldn't
note
in
the
notes
on
the
MSRP
draft.
There
were
a
few
comments
that
I
not
sure
I'd
captured.
I
I
E
Opportunistic
negotiation:
we
are
having
some
discussion
with
the
authors
right
now
and
offline
as
to
whether
this
document
should
have
a
proper
offer
answer:
considerations,
sections
in
it
or
not.
I
think
that
discussion
is,
though,
ongoing
offline.
So
we'll
see
what
happens
there,
but
we
think
hopefully
that
should
be
you
ready
to
move
forward
without
too
much
further
work.
At
least
Jonathan
yeah.
J
H
K
J
Yeah
I
mean
I,
don't
have
any
problem,
I
mean
what
working
group
does
it
I
just
feel
like
they're
being
I,
don't
see
that
important
being
to
documents?
It's
not
helpful.
Anybody
I,
think
I
mean
I
might
say,
take
the
whole
sip
brandy
document
throw
it
over
here,
but
it's
about
having
some
of
it
in
that
document.
Some
of
this
document
splits
up
all
like
the
instructions
to
people
in
a
way
that
I
think
is
not
very
clear.
G
Krista,
yes,
I,
don't
really
care
if,
if
we
had
two
documents,
Asajj,
even
though
I
would
agree
with
Jonathan,
says
I'm
the
one
who
raised
this-
and
my
problem
is
really
that
that
none
of
the
documents
contain
the
offer
answer.
The
see
brandy
document
is
first
of
all,
it's
an
informative
document
and
the
only
thing
it
has
is
an
example
and
an
offer
example,
or
something
like
that.
There
are
no
offer
answer
procedures
and
that
drafts.
If
Brandis
draft
says
please
look
in
this
draft
for
the
details
in
this
draft.
G
There
is
nothing
either,
and
this
draft
says
please
look
into
sip
brandy
for
details,
so
so
I
mean
it's,
it's
I
think
it's
it's
a
mess
wherever
my
I
think,
because
this
is
an
M
music
draft.
We
should
have
the
offer
answer
precede
the
normative
offer
answer
procedures
in
this
draft.
Whatever
see
brandy
wants
to
keep
their
draft
as
an
informative
blah
blah,
that's
fine
with
me,
but
a
music
draft
is
what
the
implementer
should
be
able
to
take
in
order
to
find
out
how
to
implement
this.
Thank
you.
K
This
is
Ben
Campbell,
a
little
history
on
that
and
and
why
that's
a
little
bit
problematic,
I
understand
the
request
and
I
and
I
am
NOT
disagreeing
with
it.
But
the
reason
things
are
a
little
problematic.
That
way
is
that
this,
the
opportunistic
security
draft
was
intended
as
a
this
is
something
you
can
do
here
are
some
examples
of
things
you
can
do
with
the
existing
standards
to
do
to
opportunistic
security.
It
was
not
intended
ever
to
be
a
normative.
Here's.
How
you
do
it
right?
K
Think
something
so
I,
don't
know
what
the
right
solution
to
that
is
I'm
in
the
process
of
trying
to
have
some
80
level
discussions,
I'm
figuring
how
we
want
to
go
forward
on
that.
If
we
in
fact
say
that
yeah,
let's
go
ahead
and
normally
state
how
we
do
they
offer
an
answer
and
all
that
sort
of
thing,
then
some
of
these
comments
about
the
current
separation
of
the
documents
are
definitely
worth
thinking
about.
E
All
right,
then
we
had
the
unknown
key
share
draft
as
a
working
group
draft
now
I,
don't
remember
it
was
in
a
previous
meeting,
but
it's
the
Syrah
version.
At
least
there
were
a
little
bit
of
a
mix-up
in
terms
of
whether
this
was
information
or
a
standards
track.
It
is
standards
track,
and
that
should
be
indicated,
at
least
in
the
milestone.
I.
Don't.
D
E
L
E
The
document
is
already
reviewed,
so
what
happens
actually
is
you
know?
Sometimes
it
goes
to
direct
the
Directorate.
Sometimes
it
goes
to
the
designated
expert.
You
know,
which
is
me
and
in
in
a
case
like
that.
Typically,
what
ends
up
happening
is
that
we
check
the
actual
registration,
which
means
that
it
has
to
be
well
specified
right
there,
certain
requirements
for
what
it
takes,
but
we
don't
do
an
end-to-end
review.
Necessarily
the
document
mm.
L
E
L
D
E
L
L
G
Crysta
question
clarification:
I,
don't
know
if
it
belongs
here,
but
since
been
nice
here,
I
asked
there
was
an
email.
A
few
days
ago,
I
think
one
of
the
art
ADEs
who
sent
an
email
regarding
the
art
Directorate
and
that
more
reviewers
are
needed
for
there
and
it's
one
of
the
tasks
of
the
art
Directorate
sdp
was
mentioned.
So
I'm
just
wondering
is
there:
how
are
those
related.
K
We
haven't
talked
about
moving
SDP
Directorate
type
reviews
into
art,
art
I
can't
speak
for
the
future,
but
I
don't
think,
there's
a
plan
for
that
right
now.
If
there
is
a
plan
for
that,
no
one
told
me,
but
that
happens.
Sometimes
we
do
not
currently
have
a
plan
to
move
the
SDP
reviews
into
that.
I
would
say
that
you
can
consider
the
historically
right
contribution
to
art
art
to
be
the
kind
of
thing
that
used
to
go
to
Rio
art,
which
wasn't
very
often
we
actually
do.
People
know
we
had
a
right
art.
E
Let's
move
on
just
real
quick
to
see
where
we
stand
in
terms
of
RTC.
You
have
dependencies
in
our
music
and
I'd
appreciate
it.
If
people
could
double
check
what's
on
here
to
see
if
anything
looks
incorrect
or
and
if
anything
is
missing,
I
think
the
good
news
is
that
we're
moving
forward
and
I
think
we
see
the
light
at
the
end
of
the
tunnel
here.
E
There's
a
bunch
of
documents
now
that
are
at
the
in
the
RFC
edittext
queue.
Most
of
the
documents
are
either
in
working
group
last
call-
or
you
know
getting
very
close
to
that.
There
might
be
again.
You
know
a
few
open
issues
in
some
cases
bundle.
We
talked
about
right,
that's
being
worked
on
right
now.
If
we
look
at
the
dependencies
or
CPC
IDs
that
are
currently
holding
up
the
various
of
the
drafts.
All
of
these
are
essentially
on
a
good
path.
E
So
I'm
not
concerned
about
that,
at
least
from
a
should
we
say
holding
up
draft
point
of
view.
It's
really
just
up
to
this
group
I
think
to
just
get
our
work
finished,
so
you
know
bundle.
We
talked
about
already
symulast
right.
We
had
that
on
the
agenda.
We
thought
that
was
ready
for
our
publication
request.
Hopefully
you
will
be
now
within
a
couple
of
weeks
after
this
meeting
read
so
you
know
that
gets
pulled
back
now,
so
that
will
be
in
the
same
situation
as
symulast.
E
But
again,
hopefully
it's
just
a
matter
of
a
few
weeks
before
we
get
that
one
back
there
I
said
STP
again,
which
is
waiting
to
hear
back
from
the
author.
There
shouldn't
be
any
issues
there.
There
might
be
a
minor
update,
that's
needed,
we'll
see
what
what
ends
up
happening.
There
trickle
isip,
that's
already
publication
requested,
and
that
is
essentially
it
and
I
guess.
There
is
a
question
because
we
don't
have
do
we
have
STP
neck.
So
maybe
a
question
was
is
STP,
neck
datachannel,
STP
neck.
Is
that
a
dependency
I.
D
E
E
F
E
N
N
If
we
get
the
rest
of
the
documents
we
need
for
cluster
238
there
and
the
ice
biz
is
not
yet
ready,
then
we
will
move
all
we
will
try
and
move
all
the
dependencies,
so
nothing
depends
on
it
and
the
goal
right
now
is
as
much
as
possible
to
make
anything
that
doesn't
need
to
depend
on
something
shouldn't.
So
if
you
don't
have
to
depend
on
the
biz
document,
don't
just
use
the
baseline
document.
N
However,
we
may
get
there
and
realize
that
we
do
have
a
dependency,
in
which
case
we
will
so
the
idea-
and
it
may
in
fact
not
be
the
long
pole
in
intent.
I
mean
lots
of
the
people
and
some
of
the
authors
of
its
it
will
be
done
before
many
of
some
of
the
other
stuff.
That's
holding
it
up.
So,
if
that's
the
case
that
just
becomes
a
non-issue
and
we've
decided
just
to
let
the
things
flow
through
to
the
RFC
editor
queue
and
then
sort
them
out
there.
N
That's
that's
my
current
understanding
of
where
this
whole
mess
is.
But
again
we
shouldn't.
Unless
your
document
has
a
technical
reason,
it
needs
to
depend
on
the
biz,
dokyum
inversus,
anonymous
document
it
shouldn't
she
just
reference
the
base
document.
Then
it
will
get
updated
when
the
biz
document
replaces
the
base
document
n.
N
D
F
M
M
There
so
forth,
four
five,
six
six
bits
depends
on
datachannel,
SDP,
neg
and
SDP
MUX
attributes,
plus
the
unfinished
things.
The
reason
it
defendants
depends
on
beta,
Channel,
SDP
meg
is
because
it
allows
you
to
register
in
your
tributes,
and
one
of
the
attributes
you
can
register
is
the
DC
essays
stuff
which
is
defined
in
the
data
journalists.
Vp
Meg
thanks.
L
O
M
All
right,
Colin
Perkins,
so
the
only
reference
to
datachannel
SDP
neg
in
four
five.
Six
six
bits
is
in
the
the
Ayane
considerations.
Where
it's
talking
about
how
you
register
new
attributes-
and
it
says
you
know
when
you're
registering
in
your
attrib,
you
need
to
provide
the
following
information,
one
of
which
is
usage
level,
one
or
more
obsession,
media
source,
D,
CSA
or
DCs.
A
sub
protocol
for
a
definition
of
source
attribute
CRC,
five,
five,
seven,
six
for
a
definition
of
DCs
a
attribute
C
data
channel
STP
neck,
and
that's
why
it's
a
normative
reference.
M
D
G
Chrisser
Kristy
yeah
I've
been
looking
into
this
and,
in
my
opinion,
I
think
the
bigger
issue
than
forty
five
sixty
six
piece
is
actually
their
ice
references
because
as
far
as
I
know,
unless
something
has
changed
in
RTC
WebRTC
web,
they
referenced.
They
directly
referenced
the
RFC
five
two
four
five,
but
then
they
have
other
reference
to
two
other
documents
that
reference
I
space
and
say:
I,
say
snippy
and
so
on.
E
G
Otherwise,
it's
very
good
gonna
be
very
difficult
for
TC
web
implementers
to
figure
out
okay.
What
should
I
do
because
there
are
differences
between
eyes
and
eye
space
right
so
I
mean
that's
the
whole
reason
we
did
I
space
to
begin
with,
because
there
are
things
we
wanted
to
fix
and
change
or
add
or
remove,
and
so
on
sure.
E
K
This
has
been
I
will
still
go
ahead
and
address
what
crystal
birthing
the
80s
can
I
have
a
plan
for
that
I
think
the
idea
and
Adam
has
been
when
tracking
this
I
think.
The
general
idea
is
that
unless
the
draft
is
dependent
upon
something,
that's
new,
if
we
can
go
ahead
and
reference
the
RFP
and
then
when
all
these
things
get
released
into
the
RFI
editor
queue.
We're
gonna
ask
the
our
theatres
to
go
in
and
harmonize
it
all
I'm
sure
they
will
love
it.
For
that.
E
H
M
E
D
So
let's
talk
about
simulcast
and
rid
and
the
issues
we
found
so
ok
next
slide.
So
what
really
happened
was
that
Fleming
noted
one
issue.
You
also
noted
another
issue
and
on
the
main
list,
and
then
we
sit
down
and
start
discussing
this
being
beginning
of
this
week
and
we
found
a
couple
of
other
issues
in
due
to
that
discussion,
so
trying
to
go
foodies
to
try
to
fix,
ensure
that
simulcast
and
read
results
these
issues
as
needed
and
and
we
can
go
forward
quickly,
so
we
can
publish
the
documents.
D
D
So
what
in
this
is
in
the
context
they
are.
We
had
discussion
in
the
simulcast
draft
around
some
related
format,
such
as
comfort,
noise,
a
telephone
events
that
you
could
switch
to
in
some
cases
for
me
to
stream
and
the
accounts
personal
simulcast
Rev
in
section
5.2
stirs
you
not
in
such
related
format
must
not
be
defined
as
having
their
own
read
list.
D
Unread
I
be
listed
explicit
in
that
two-bit
parameters,
as
they
don't
to
see
local
streams.
Yeah
Flemming
is
problematic
and,
looking
back
to
you,
I
think
we,
the
others,
agreed
that
this
looks
problematic.
So
let's
go
to
next
slide
and
really
any
type
of
this
definition
of
what
you
do
with
any
type
of
special
handling
should
really
belong
to
you
in
a
music
read
document
to
begin
with
so
and
also
there
are
actually
alternative
representation
of
the
media
source,
so
even
if
there,
so
they
that's.
D
Why
I
think
we
was
the
wrong
assumption
before
and
therefore
you
would
specify
them
as
alternative
pts
for
a
particular
it.
So
you
have
maybe,
for
example,
a
little
Kovac
and
a
telephone
event.
You
could
actually
send
them
or
comfort
noise
with
g.711
if
it's,
those
together
is
actually
a
simulcast.
A
restriction
on
a
particular
in
from
a
similar
caste
perspective
is
particular
resetter
restrictions.
D
Something
so
therefore-
and
they
were
also
this
existing
text
in
Section
four
of
MU
secret,
which
is
the
old
wonder-
that's
already
said
that
least
one
or
more
PT
values
that
can
be
used
in
The
Associated,
not
to
be
stream.
So
the
proposal
here
to
fix
this
issue
is
to
remove
the
sentence
that
we
noted
about
bullet
must
not
include
related
panel.
Formal
cinema
construct
and
change
tighten
up
the
definition
in
rid.
D
So
that's
the
the
bold
text
here
in
the
new
version
is
to
try
to
clarify
that
you're
not
allowed
to
send
in
you
need
to
list
the
payload
types,
if
you're
using
a
payload
type
list
to
begin
with,
if
you're
using
it,
you
need
to
list
a
subset
of
payload
types
that
may
be
used
to
represent
that
particular
restriction.
So
that's
the
suggestion.
D
D
So
in
my
interpretation,
so
this
second
thing
was
the
thing
that
we
discussed
this
previously.
We
did
notice
they're,
actually
difference
for
how
you're
single,
for
example,
red
which
has
its
own
payload
type,
and
then
it
has
one
or
more
payload
types
that
you
express
as
being
the
reason
for
the
redundant
encoding.
D
So,
for
example,
you
can
have
97
PPO
type,
97
s,
red
eastern
eleven,
a
ye
79,
and
then
you
can
say:
oh
this
redundancy
packing
of
the
Codex
is
season
11,
plus
time
delay
is
79
and,
and
in
that
case,
there's
actually
a
difference.
If
you
were
this,
that's
why
red
line
between
sending
alternative
one
there
saying
yes,
PT
97,
which
means
we
only
say,
represent
red,
encapsulated,
tailor
to
you
and
the
second
one
where
you
can
say:
oh
this
industry
me
idly
being
red
or
it
could
be
Eastern,
11
or
d
79.
D
So
there's
a
clear
difference
and
I
think
their
proposal
is
to
actually
write
the
sentence
or
two
or
as
they
exemplify
this
into
the
reader.
After
saying,
this
is
what
they
see
in
the
context
to
the
previous
change.
After
that
say,
okay,
these
two
applies
two
examples
like
read,
etc,
where
this
will
be
a
difference
between
these
two
so
but
that
takes
proposal
hasn't
been
written
yet
so,
but
that's
so
we
can't
show
it.
D
We
just
making
clear
that
there's
a
difference
between
if
you
stand
stating
for
a
codec.
That
is
my
tab.
You
need
on
the
M
line.
Those
are
all
coded
all
those
payload
types,
but
if
you
could
only
include
one
and
only
then
your
X
restricted
to
RIT,
which
is
saying
that
what's
going
on
the
road
line,
is
the
payload
types
actually
sent
as
payload
types
in
the
RTP
header,
so
say
of
the
media
of
the
RTP
streams.
So
a
stream
Sue's
ending
right.
G
D
Exactly
yes
clarifying
that
some
people
understand
the
okay
it
might
so.
This
is
an
example
of
something
that
I
could
have
it
also
other
formats
which
has
associated
formats,
which
is
represents
as
payload
types
and
and
and
might
actually
show
up
as
encapsulated
in
some
form
in
your
stream.
So
it's
a.
D
J
D
D
So
the
issue
with
using
repaired
stream
RTP
repaired,
RTP
stream
IDs,
is
that
this
doesn't
fit
to
redundancy
formats
that
reference
multiple
source
streams,
multiple
different
as
a
source,
is
in
order
P,
which
includes
Flex
VII.
So
we
need
to
put
in
some
type
of
exceptions
for
these
kind
of
redundancy
formats.
So
if
you
have
a
one-to-one
1u,
it's
fine
to
require
to
use
repaired,
RTP
stream
IDs,
but
otherwise
you
need
to
say.
D
Ok,
there
are,
there
are
exceptions
to
other
formats
that
continues
this
Meccans
as
its
requires
and
one-to-one
mapping
between
the
reads
to
source
streams.
It
said
so
yeah
repaired
stream
ID
it
points
to
rid
the
read,
needs
to
point
to
one
single
as
the
sources
or
RTP
stream
represented
by
one
as
a.
J
D
And,
and
if
it's
that's
doesn't
come
is
to
write
for
repair
format,
then
it
can't
be
used
basically,
so
we
need
to
change
the
text.
So
if
you
go
to
the
next
slide,
we
has
it
takes
proposal
here,
for
noting
is
thinking
separatin
exception
and
saying
that
is
only
this
past
is
when
it's
applicable
and
make
clear,
for
example,
that
the
Flex
vac
is
one
case
where
it's
not
applicable,
due
to
the
reason
that
it's
it
associated
reference,
multiple
RTP
streams
or
actually
have
a
mechanism
on
RTP
level.
J
J
D
E
E
D
M
D
Issue
we
can
dub
realize
when
we're
discussing
this,
so
when
you
using
redundant
formats
like
cortex,
so
you
will
be
fake,
as
I
discussed
before
we
have
this
kind
of
reference
chain
between
the
repel
stream
idea
points
to
rids
the
readers
bounds
on
SSRC
and
your
repair
stream
and
the
repair
stream
is
bound
to
be
repaired
stream,
ID
and
because
this
is
level
of
indirection
something
you're
wrong.
Actually,
if
you
go
to
the
next
slide,
you
could
have
a
soul
if
the
repairs
bottom
reference
source,
ae4
repeller
the
different
points
it
sent.
D
That's
fine,
but
then,
if
you
have
a
change
in
the
route,
what
to
read
points
between
SS
or
say
a
and
SSRC
B-
and
you
haven't
really
received
it.
So
you
missed
it.
The
repair
packet
might
wrongly
point
to
the
source
de
and
try
to
use
that,
while
it's
in
actually
should
have
used
as
a
source
to
be
so
and
when
it
gets
the
updated
Road
point
to
2
B,
it
will
actually
use
the
right
packets,
but
it
this
can
actually
happen.
D
D
There
actually
risk
of
this
happening
in
some
sense
with
if
you
would
switch
along
the
midline
between
conceptual
source
is
not
the
EPI
middleboxes.
If
you
actually
want
to
notice,
it
would
affect
upon
the
laughing,
because
this
puzzle
that
needs
to
make
that
reflection
in
self
but
I,
don't
know
how
I
will
feel
about
that.
D
Otherwise,
the
issue
for
around
these
documents
really
to
focus
on
update
documenting
the
issue
in
a
music
grid,
and
one
way
around,
is
to
avoid
this
issues.
Of
course,
to
not
you
depend
on
this
level
of
indirection.
Instead,
use
flex
affects
that
directly
points
to
the
stream,
and
you
will
never
have
an
issue
because
it
referenced
the
package
by
its
authorities
in
sequence,
numbers
and
the
problem
is
solved
or
completely
avoided
so,
but
this
is
also
text
we
haven't
written
yet,
which
needs
to
be
suggested
in
Santa
list
so
yeah,
and
that
means
so.
D
The
suggestion
here
is
really
not
to
do
anything
about
bundle,
but
the
issue
would
kind
of
potentially
exist
here
also,
but
if
you
use
the
RTP,
it
might
be
yeah,
it's
might
not
manifest
itself
as
clearly
there,
because
you
stream
section
bound
to
the
whole
em
lines
and
and
any
stream
at
any
changed
should
contain
your
own
means
in
the
header
extension
and
therefore
will
correctly
associated
for
the
use.
So
it
probably
less
problem
they
are
done.
It
is
for
this
mechanism.
That's
actually
may
depend
on
this
leveling
direction.
D
J
J
D
M
J
N
D
J
D
Yes,
we
also
realized
in
a
simulcast
draft
at
the
STP
examples
in
there.
It
might
not
be
the
particularly
complete
they
also
both
not
using
read
in
multiple
different
ways
that
might
be
worth
it.
It
also
doesn't
contain
particularly
much
about
redundancy
related
formats.
I
didn't
know
it
when
actually
looked
a
bit
deeper.
That's
the
RTC
webs
STP
example.
Draft
actually
has
fairly
much
more
details.
D
Examples
with
simulcast
and
I
actually
need
to
go,
read
them
properly,
review
them,
but
we
might
be
actually
be
able
to
steal
watch
from
there
also
box,
and
this
in
the
same
way
of
actually
shaking
verifying
those
as
depart
examples.
But
the
plan
here
is
a
sausage
that,
anyway,
really
advice
in
document
is
to
put
in.
That
is
one
more
example.
As
a
bit
more
advanced.
D
J
D
D
G
D
D
E
D
D
P
D
That's
probably
why
we
for
this,
that's
probably
an
indication
that
we
actually
need
to
move
up.
The
examples
in
simulcast
draft
two
levels
of
people
understand
yeah,
these
kind
of
advanced
things
is
possible
and
it's
so
and
we
can
focus
discussion
in
the
simulcast
draft
on
providing
the
guidance.
How
do
you
read
this
thing
and
what
what
were
thinking
about
in
attendance?
E
D
Okay,
next
issue:
yes,
so
this
is
your
sense
comment
that
went
on
the
mailing
list
a
few
weeks
back.
Thank
you.
Maybe
so
any
comments
on
one
paragraph
in
section
five
point
one
around
so
specific,
signaling
and
and
this
sentence
release
it's
not
really
clear
what
it
tries
to
say.
I
think
we
have
had
several
different
interpretations
of
it,
which
was
both
shows
it's
confusing
but
and
I.
Think
my
my
reflections
over
is
that
in
general
is
a
source
in
and
a
ribs
are
kind
of
independent
I
mean
you
can
use
the
SSRC
one.
D
So
the
suggestions
here
is
to
remove
this
this
paragraph
from
sea-monkeys
draft,
and
it's
not
obvious
that
it
actually
needs
a
clarification
in
the
raft
around
this,
but
so
I
think
the
easiest
way
were
just
to
believe
it
long
butts
here.
You
might
have
other
ways
if
you
see
some
issues
around
completely
moving
it
when
they
have
some
qualifications.
But
that's
a
question
for
the
group.
If
you
have
any
in
any
input
on
this.
F
H
D
So
then
we
came
to
issue
number
seven,
which
way
we
for
here
summarize
so
seems
to
be.
My
take
at
least
seems
to
be
consensus
that
we
can
remove
it
and
we
don't
need
to
add
any
new
text
on
the
general
usage
that
the
existence
of
a
SSRC
and
read
can
be
almost
orthogonal
or
anything
like
that.
It's
just
okay,
they
both
mechanism
normally,
unless
specifying
anything
more,
they
will
be
two
separate
mechanism
that
may
occur
in
the
same
STP.
So.
I
D
D
So
issue
number
seven,
so
this
came
out
also
came
up
in
discussion
was
actually
about.
So
is
there
so,
let's
level
up
so
mean
values
that
you
used
in
this
context,
maybe
bind
is
actually
implicitly
buying
two
Assoc
lines
if
they
exist
because
they
are
included
in
the
same
media
description
so
the
same
in
equals
block.
If
you
have
the
SSRC
lines
there
and
you
have
a
equals
mid,
you
would
know
the
mid
value.
J
O
D
What
we
have
is
the
RTP
or
TCP
level.
Mechanist
bind
reads
to
us:
the
sources
they
are
required
because
a
source
is
signaling,
clearly
doesn't
work
in
cases
where
you
have
dynamic,
switching
back
and
forth.
You
also
have
this
kind
of
signaling
race,
condition
that
if
you
haven't,
if
the
offer
the
answer
includes
in
u.s.,
is
a
ESS
or
see
it,
and
you
have
an
established
party
position,
the
meaning
Ameri
HD
clients
prior
to
to
do
a
signaling
message
which
binds
themself.
D
D
Have
previous
Assoc
mechanism
and
single
area
change,
etc?
Which
would
happen
anyway,
if
you
use
it
today
without
finding
it
rid?
So
if,
if
you
include
a
SSRC,
you
already
have
this:
normally
your
two
peers
and
you
the
first
part
of
the
classes.
This
is
our
C's,
then
you
can
include
your
SS
or
C's.
That's
non
colliding,
so.
D
D
M
D
D
J
D
It's
actually
only
question
of
feature
parity
with
being
able
to
signal
in
those
cases
that
you
want
to
use
a
SS
or
C's.
So
that's
that's
only
the
question.
We
have
a
mechanism,
that's
sufficient
to
make
all
the
cases
you
can
think
working,
but
you
would
not
get
the
SSRC
binding
to
rids
until
the
media
start
flowing.
So
you
get
this
reward
to
PE
or
to
CP.
Q
Sum
of
work-
maybe
this
is
know
where
this
came
from
and
channel
some
of
objections
to
it
and
maybe
try
to
resolve.
Well,
you
know
what
the
pros
and
cons
were
so
originally
this.
Besides
just
you
know
having
you
know,
symmetry
or
parity
with
with
what's
available
for
mid,
which
is
not
really
a
need.
It's
just.
You
know
a
cleanliness
thing,
I,
don't.
L
Q
It's
actually
a
use
case
where
this
is
required
for
something
to
work.
So
from
that
sense,
it's
not
it's
not
a
need,
but
one
of
the
other
things
that
came
up
as
a
motivating
use
case,
for
it
is
moving
specifically
chrome
to
unify
plan.
A
chrome
currently
signals
a
bunch
of
equals
SRC
lines
to
indicate
simulcast
in
a
in
a
very
you
know,
non-standard
way
and
moving
them
to
signal
simulcast
properly.
Q
But,
yes,
the
backwards
compatibility
with
the
older
implementations
which
are
using
the
equals
a
Searcy
variant
of
signaling
simulcast,
providing
the
rear
binding
to
that
equals
s.
Src
seemed
like
a
natural
transition
to
moving
to
unified
plan,
because
then
you
could
say
that
this
equals
a
star.
C
is
the
720p.
You
know
high
resolution
layer
with
red
one
and
they
could
say
equals
SRC.
Q
The
next
one
is
the
lower
resolution
layer
360p
with
red
too,
so
it
seemed
a
natural
way
to
evolve
chrome
from
using
hard-coded
SR
C's
with
implicit
knowledge
that
these
are
different
resolutions
to
being
explicit
about.
These
are
different
resolutions,
but
so
atoms
counter
to
that
was
you
know.
Why
would
we
need
this
interim
transition
step?
Why
wouldn't
they
just
go
to
the
proper
unified
plan
which
use
a
simulcast
equal
simulcast
line?
Q
Is
what
tells
you
which
rids
are,
which
you
know
are
the
two
different
simulcast
resolutions,
and
you
don't
need
these
two
different,
a
equals
or
C
lines
to
tell
you
that
there's
two
different
resolutions-
simulcast
line,
tells
you
that
there's
two
different
resolutions
with
two
different
mid
bindings.
So
from
that
sense,
you
wouldn't
need
that
transition
period
just
go
straight
to
the
unified
plan,
simulcast
syntax
and
not
need
this.
So
the
only
real
use
of
this
that
would
provide
any
benefit.
Q
Would
those
remains
would
be
to
prime
a
decoder
pipeline
before
it
gets
the
first
RTP
packets
to
already
be
able
to
set
it
up
and
let
it
know
that
here
comes
this
RC
and
it's
this
resolution
and
you
could
create
your
decoder
instance
with
these.
You
know
maximum
frame
sizes
and
things
like
that,
which
is
a
pretty
small,
motivating
use
case
and
I
guess.
My
view
on
all
of
this
is
that
I've
kind
of
been
convinced
that
it's
probably
not
enough
of
a
motivation
to
require
new
specification
for
it
and
just
just
leave
it.
Q
D
Q
D
D
J
Not
so
much
what
is
chrome
going
to
do,
but
as
chrome
itself
going
to
do
so
much,
as
can
I,
as
a
you
know,
as
a
basic,
translate
Chrome's
weird
dialect
of
STP
into
something
closer
to
standards,
conformant
that
the
other
side
can
understand,
and
vice-versa
because
you
know,
obviously,
if
chrome,
isn't
speaking
a
know,
the
rid
header
extension
or
be,
then
you
need
it
needs
the
SSRC
to
do
anything
useful.
The
other
thing
I
mean
so
the
other
thing
a
question
is
for
mid.
Are
there
obviously
for
bundle
you?
Never?
J
You
can
do
bondable,
never
sending
an
eggless
or
see
by
just
relying
entirely
on
the
header
extension
and
rtcp
yeah,
but
people
are
sending
it
anyway,
and
that
is
that
just
for
compatibility
with
you
know
older
systems
or
is
it
that
they
would
say?
Okay,
I'd
rather
pre
bind
then
spend
the
bits
of
the
media
playing
on
the
header,
extensions
and
whatnot,
because
in
the
light,
if
there's
actually
the
latter
motivation,
then
removing
they
have
the
same
motivation.
They
would
have
might
have
the
same
motivation
for
it
as
well.
D
So
I
mean,
from
my
perspective,
there's
one
thing
here
which
priming
the
whole
Dakota
Shane
is
possible.
The
only
thing
that's
outstanding
is
this
octopus,
so
the
RTP
stream
binding
into
that
rest
of
the
code,
the
chain,
because
you
will
gonna
know
from
the
AC
mocast
line
and
the
rids
what
the
requirement
is
on
the
decoder
changes.
You're
gonna
have
to
set
up,
so
you
can
prime
them
have
them
up
and
read
the
only
thing
you
need
to
do
late.
This
say:
okay,
oh,
how
we
have
a
new
SS
or
C.
D
Q
Q
I'm
gonna
say
it
just
for
completeness
so
I
think
one
of
the
something
related
to
what
Jonathan
just
said
about
implementations
that
don't
actually
send
mid
on
the
wire
in
RTP,
but
yet
signal
you
know
in
signaling.
You
know
what
you
know
what
the
mids
are,
and
so
that's
enough
to
resolve
all
of
all
of
your
your
RTP
stack.
You
know.
Q
Q
P
P
D
D
D
Yeah,
so,
and
and
as
I
note
about,
there
is
a
possibility
to
specify
this
later.
It's
it's,
it's
just
that
he
would
have
to
work
him
or
if
you
actually
want
to
include
it.
It's
Koshien
some
other
specification.
If
you
want
to
mandate
it,
for
example,
from
our
to
see
web
perspective
or
things
like
that,
but
it's
so,
but
you
can
always
specify
new,
so
a
source,
specific
fmt
paper
on
my
aura
saying
this
is
Nesta,
starting
basically
for
use
in
within
SSRC.
So
a
separate
document
later
could
easily
fix
this.
E
D
Okay,
so
I
think
that
was
the
yeah,
so
the
goal
here
now
then
we
gone
through
the
issues
we
I
think
we
have
clear
directions
on
how
to
proceed.
It
was
a
team.
We
work
on
providing
text
for
a
not
yet
written
in
the
near
time.
I
hope
by
doing
it's
already
next
week
to
get
it
on
and
then
after
picking
a
few
about,
the
text
will
hopefully
have
publication
version
in
a
few
weeks
of
both
simulcast
on
rid
and
I.
D
Would
guess
that,
because
this
change
is
actually
change,
is
mandatory,
herb
and
normally
it
takes
to
things
like
that
we
prob
yeah.
If
we
do
have,
we
are
removing,
must
not
old,
changing
a
must
see
resection
sentences
and
adding
in
other
must
not
that
cetera,
so
I
assume
we
need
a
targeted
last
call
on
these
particular
changes
so,
and
this
guide
disagrees.