►
From YouTube: W3C WEBRTC WG interim Jan 22, 2019
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
And
I
finally
got
the
right
appear
on
it:
it's
not
cool,
it's
not
adding
everything,
because
I
found
that
I
had
a
missing
piece.
I,
don't
know
where
in
the
document
to
put
stuff
that's
this
this
stuff
might
happen
while
the
coolest
going
on.
Then
you
should
do
the
following.
I
think
I'll
have
to
add
that,
but
the
PR
and
practice
time
to
one
is
just
spraying
that
and
when
you
encode
reads
you
you
put
them
in
the
same
order
as
in
yes
as
in
the
listening
coatings
and
when
you
decode
them,
you
suggest
encoding.
B
So
ty
is
in
the
same
order
as
as
the
spectrum
from
the
STP
I
did
find
a
lot
another.
This
section
is
missing
is
here,
which
is
that
there
isn't
the
section
that
says
how
to
create
how
to
create
the
sunder
from
from
a
description
we'll
get
back
to
that
at
the
end
of
meeting.
So
no
not
2071
seem
seem
like
the
right
thing.
I
think
so
looks.
A
C
C
B
C
Long
as
so
forcing
them
both
to
be
the
same
orders,
probably
too
much,
and
rather
than
saying
just
one
of
them
is
the
is
the
definitive
order
and
I
would
say
the
simulcast
layer,
because
that
at
least
is
somewhat
similar
to
the
spec
of
simulcast
worth.
The
order
of
the
layers
are
in
preference
from
left
to
right
and
then
just
whatever
they
reference
any
ribs,
and
that's
fine.
C
D
A
A
With
respect
to
the
things
in
here,
degradation
preference
affects
the
preference
between
resolution
and
frame
rate.
One
question
which
is
not
addressed
in
the
PR
is:
does
this
affect
the
order
in
which
simulcast
streams
or
layers
are
dropped
in
it?
Within
a
sender,
two
people
have
any
opinions,
for
example,
if
you
say
prefer
maintain
resolution,
does
that
somehow
affect
what
occurs
when
layers
and/or
simulcast
streams
get
dropped.
A
That's
one
interpretation
of
it
because
degradation
preference
is
about
maintaining
frame
rate
versus
resolution.
I've
heard
it
interpreted
in
many
different
ways
for
many
different
purposes,
including
content.
Hence
so
I
think
may
be.
The
right
thing
to
do
is
to
probably
leave
this
to
a
separate
issue.
The
order
issue
which
I
guess
Harold
has
talked
about.
Maybe
we
can
clarify
that
there
so
far,
this
isn't
in
the
PR
priority
affects
the
allocation
of
bandwidth
and
basically
the
PR
says
the
user
agent
is
free
to
allocate
bandwidth
between
encodings
of
an
RTP
sender.
A
A
A
E
A
D
F
Yes,
so
this
slide
is
pretty
much
unchanged
from
last.
This
is
something
we
decided
last
time,
so
the
only
difference
here
is
that
we
have
a
PR
briefly.
The
issue
was
that
there
wasn't
really
clear
language
on
when
information
when
you
get
codecs
from
get
parameters
was
a
little
unclear
that
was
live
in
scatter.
Get
parameters
is
synchronous.
F
It
would
be
nice
to
add
some
internal
slots
so
way
out
of
the
PR
that
adds
internal
slots
for
send
codecs
and
receive
codecs,
and
these
are
set
in
basically
set
answer
which
would
be
set
remote
description
answer
or
that
local
description
answer.
Depending
on
what
side
you
are
and
which
would
mean
that
you
would
have
to
wait
for
said
well,
the
answer
to
be
set
to
be
able
to
read
codecs
out
of
get
parameters
and
the
PR
is
on
the
next
slide,
the
basically
other
than
the
boilerplate
for
creating
the
internal
slots.
D
F
F
In
short,
then,
if
this
is
answer
or
PR
answer,
then
we
set
to
send
codecs
to
the
codec
stuff
description
to
go
to
saved,
for
sending
and
in
which
the
UC
agent
is
currently
capable
of
sending
this
with
similar
language
from
where
it
looked
before
and
same
for
receiver.
Receive
codecs
to
the
codis
of
the
description
negotiates
for
receiving
and
wish
to
use.
Agent
is
currently
prepared
to
receive
and
I
think
would.
F
So
this
is
the
common
issue
we
have
with
the
asynchronous
or
France
exchanges
that
traditionally
we
we
expose
some
information
early
when
as
soon
as
you
set
remote
description
offer
like,
for
instance,
you
create
all
the
transceiver
objects,
so
if
they
don't
exist
in
it
and
already,
which
makes
sense-
and
a
lot
of
that
had
to
do
with
this-
was
an
API
meant.
So
you
can
interrogate
the
during
negotiation
and
react
to
it
and
the
downside
of
that.
F
So
we
have
some
things
that
are
exposed
early,
including
like
we
fire
the
track,
events
and
stuff
early
and
I.
Think
looking
back
the
reason
for
that
was
so
that
you,
it
used
to
be
that
for
tracks
tracks
used
to
be
the
objects
that
you
rejected,
em
lined
with
which
it
no
longer
is
so
there's
a
lot
of
legacy
there.
I
don't
know
that!
F
D
Is
if
you
want
to
use,
set
parameters
to
change
what
you're
sending
right?
If
you
have
to
wait
before
the
answer
to
do
set
parameters,
because
you
don't
have
access
to
get
parameters,
then
you
would
have
this
for
a
short
period
of
time,
where
you're
sending
the
wrong
thing
only
to
change
it's.
You
know
as
soon
as
you're
also
go
later
so.
F
H
D
E
A
D
And
Ryan,
then
it's
my
issue.
So
this
is
another
old
old
one
that
we've
discussed
that
the
tea
pack.
But
we
have
these
codec
preferences
and
you
you
set
them
in
the
offer.
You
also
set
them
in
the
answer,
and-
and
this
is
to
clarify
that
it's
intentional-
that
if,
if
both
the
offer
and
the
answer
has
codec
preferences,
then
the
answer
is
codec
preference
overrides
the
offers
or
the
the
one
that's
in
the
SDP
yeah.
D
A
So
there
was
a
material
in
section
five
point,
one
where
we
actually
had
our
own
grammar
in
there,
which
conflicted
with
draft
IETF,
em
music,
rid,
there's,
also
a
potential
conflict
with
the
abt
x-rayed
spec,
but
basically
in
PR
2067
we've
changed
this,
who
removed
the
text
of
section
five
one
and
just
cited:
draft
IETF,
M,
music
grid
and
I
posted
a
note.
The
rgc
web
list
and
they're
arguing
about
which
grammar
is
appropriate
in
the
IGF.
But
that's
no
longer
our
problem.
A
B
A
B
C
Okay,
so
it's
not
clear
how
to
set
the
number
of
layers
when
answering
an
offer
with
a
track.
So
basically
you
should
not
be
using
add
track
because
add
track
doesn't
allow
you
to
specify
the
number
of
layers.
So
in
simulcast,
if
you
are
the
the
one
who's
actually
sending,
but
the
offer
is
coming
from
the
server
and
not
from
not
from
you,
then
what
you
need
to
do
is
in
the
ad
transceiver
right.
C
You
can
specify
the
layers,
so
the
transceiver
will
be
created
for
you
and
then
before
you
call,
and
then
you
call
get
parameters
to
get
the
parameters.
It'll
have
the
encoding
layers
that
are
set
from
the
offer
and
you
can
just
change
the
parameters
using
set
parameters.
Does
that
make
sense?
Was
that
clear.
F
I
have
a
question
there.
Yeah.
E
F
A
B
C
Well
we're
not
really
saying
that,
but
that
is
probably
how
we
will
be
doing
this
and
there
was
a
and
the
request
is
to
add
language.
That
will
say
something
similar
to
that
that
a
transceiver
can
only
reduce
the
note
that
we
can't
change
the
number
of
layers
in
a
transceiver
all
right,
so
otherwise
it'll
will
add
a
new
transceiver
if
we
don't
already
have
one
with
the
correct
number
of
send
encodings
correct
if
we
don't
have
one
to
reuse.
Yes,
okay,.
B
B
A
B
F
F
I
So
y'all
far,
you
know
we
still
want
it
and
the
reason
is
the
following
and
and
look
I
I
I'm
not
are
I'm,
not
arguing
about
adding
or
deleting
as
implementing
but
I
think.
It
would
be
good
for
the
browser's
to
implement
here's.
Why
the
the
simplest
implementation
would
just
be.
You
read
a
config
off
disk.
That's
in
the
configuration
for
the
browser
or,
however,
browser
configuration
policy
is
currently
provisioned
into
the
browser
by
enterprises
in
particular,
and
if
it's
there,
then
you
return
that
string.
Apps
can
ignore
this.
I
It
doesn't
automatically
go
into
the
ice
servers
or
any
it
just
returns.
The
string,
that's
all,
and
then
apps
can
use
it
if
they
want
to
and
the
place
where
this
is
really
useful.
Is
there
are
lots
of
enterprises
where
WebRTC
is
totally
blocked
in
and
out,
but
if
it
could
run
through
an
enterprise
provide
a
turn
server,
then
it
would
continue
to
work
in
those
types
of
environments.
It
would
be
allowed
through
the
firewall
that
turn
server
and
it
also
has
privacy.
I
You
know
strong
privacy
preferences
of
it
allows
you
to
provide
your
own
turn
servers
instead
of
routing
all
of
your
traffic
through
basically
other
people's
turn
servers
so,
and
it's
obviously
really
easy
to
implement
as
well.
So
we're
sort
of
curious
why
no-one's
implemented
it
and
whether
that
could
be
prioritized
up
and
the.
I
D
I
Else
right,
right,
yeah,
but
the
browser,
but
this
is
I'm
gonna
poke
you
on
it
exactly
where
somewhere
else,
because
part
of
the
guarantee
that
the
browser
tries
to
make
is
it
doesn't
allow
you
just
to
read
from
some
generically
configurable
local
IP
address
or
something
like.
If
we
could
read
from
you
know,
a
DNS
SD
address
of
you
know,
turn
server
dot
local
right
like
we
could
do
that.
But
we
can't
that's
exactly
what
the
browser
blocks
us
from
doing
is
accessing
data
inside
an
enterprise
for
a
good
reason.
F
Okay,
III,
don't
have
a
strong
opinion
on
it
and
and
I
may
misinterpreted
the
well
I
know:
I
didn't
misinterpret
I
thought
get
default.
I
servers
was
supposed
to
say
Firefox
this
existing
implementation,
where
you
can
specify
current
servers
that
will
happen
under
under
your
now
unbeknownst
to
the
web
site,
and
so
there's.
A
F
What
Firefox
implements
is
is
well
what
we're
looking
at
here
in
the
spec
is
an
opt-in
right,
where
the
app
would
opt
in
to
use.
It's
just
extra
information
that
the
browser
can
optionally
provide,
which
is
not
what
Firefox
had
Firefox,
had
something
that
you
can
configure
the
user
couldn't
think
of
the
browser
to
do
this
on
any
web
site
if
they
want
to
take.
A
F
A
F
I
J
The
fingerprinting
and
this
also
the
issue:
do
you
trust
the
list
of
default
eye
servers?
So
does
a
web
app
tours
to
the
this
list
of
ice
servers
or
does
not
trust
it?
Oh,
how
can
it
know
that
these
ladies
to
be
courted
is
to
be
used
or
it's
not
to
be
used
really,
so
what
will
be
web
up
there?
Well.
I
What
do
you
mean
by
trust?
What
would
there
be
not
server
all
the
tropics
and
the
user
is
explicitly
telling
you
here,
here's
what
I
want
and
I
think
that
that
point
leaves
it
up
to
the
web
app.
That's
why
it's
optional.
They
can
call
this
string
or
not,
and
they
get
a
value
back
from
it
and
they
can
decide
whether
they
want
to
insert
that
in
their
list
of
turn
servers
or
not.
The.
J
User
in
Firefox
is
able
to
set
the
list
of
servers
and
it's
in
the
Chrome-
it's
not
controllable
by
the
web
app.
So
the
user
said
I
trust
this
I
service,
so
the
web
app
should
say:
ok,
the
user
already
trusted
so
I
will
use
this,
but
we've
given
default
ice
servers.
Then
the
user
is
actually
setting
this
list
and
that
web
app
can
actually
or
not
use
that
list.
But
since
it's
already
there
it
means
that
the
user
is
already
trusting
this
ice
service.
So
why
is
the
web
app?
J
I
Okay,
you're,
going
to
a
step
farther,
which
is
this
list
should
not
be
optional,
should
be
mandatory.
You
should
have
to
use
them
right
and
look,
though,
I
appreciate
that
argument,
I
sort
of
agree
I
think
there
was
a
lot
of
pushback
on
that
argument
and
it
wasn't
it
wasn't.
The
one
I
was
with
like
I
just
that
appeals
to
me
at
some
level,
but
I
think
lots
of
apps
are
going
to
not
work.
If
you
don't
use
their
term
servers
say
it
wasn't.
I
J
I'm
fine,
with
a
user
like
I'm,
trying
with
modulized
approach
where
mozilla
is
a
trusted
one
and
then
a
user
is
setting
its
parameters
and
all
websites
will
go
through
that
because
you
know
that's
the
way
it
is
I'm
like
like.
Currently
we
have
proxies
and
all
the
edge
become
time
we
go
for
practice
and
that's
fine
website
does
not
have
to
opt
in
into
going
through
a
proxy.
I
It
so
I'm
very
sympathetic
to
that
argument.
If
browsers
were
willing
to
do
it,
but
I
don't
think
they
will
be
willing
to
implement
that
because
of
the
websites
they
will
break
when
they
do
that,
so
I
mean
if
we
could
get
that
I
would
say
fine.
We
don't
need
this,
but
given
we're
unlikely
to
get
that
I
or
or
if
we
don't
get
that,
then
I
come
back
to
I
think
we
need
a
way
for
for
things
to
op
it
in
and
I.
B
J
I
J
I
I
J
Yeah
I
agree,
so,
for
instance,
I
would
be
fine
with
something
less
granular
which
would
be
a
web.
App
might
want
to
know
whether
if
we
go
through
I
servers
by
default
or
whether
it
does
not
want
it.
So
like
a
boolean,
saying
yeah,
you
will
go
through
some
tone
service
that
you
don't
know
and
if
you
do
not
trust
them
towards
that,
don't
do
it.
But
that
would
be
fine
by
me
and
there's
no
privacy
issues
there,
there's
something
of
printing
that
it's
less
granular
than
at
least
of
our
responses.
It's.
D
G
I
The
reason
we
can't
do
that
is
because
there's
no
way
to
you
know
dinette
like
to
like
it's
like
this
DNS
SD
thing.
I
mentioned
the
web.
Server
isn't
going
to
allow
us
to
put
in
some
name
that
dynamically
resolves
to
a
different
server,
depending
on
which
enterprise
you're
currently
in
right,
or
you
know
who
you
are
so
we're
looking
for
some
sort
of
dynamic
way
of
doing
this
right
it
like
if
I'm,
if
I'm
running
WebEx
at
Ford
or
at
BMW,
obviously
Ford's
going
to
use
Ford
servers.
I
I
I
It's
not
like
hangouts
from
a
privacy
point
of
view.
We
don't
require
everybody
to
be
logged
in
to
use
it,
so
you
can
join
WebEx
without
being
a
WebEx
user.
Only
the
person
who
creates
the
WebEx
conference
and
this
this
has
huge
privacy
implications
for
people.
It's
really
good,
but
that's
why
we
can't
we
can't
drive
it
from
the
server
we'd
also
have
an
awful
lot
of
websites
that
we're
adding
this
to
from
a
course
point
of
view.
So.
C
I
B
That's
what
that
was
one
company
or
that
that's
how
that's
how
we
keep
track
of
what
is
being
requested.
That's
why
I
say
why
put
it
that
way
right
if
you
requested
it
from
from
Google,
and
if
you
request
it
from
Google,
then
the
request
has
been
lost
right.
That's
that's
a
very
pure
comment.
Well,.
F
A
I
If
you're
really
do
accept
that,
then
there
are
other
ways
to
skin
this
cat,
but
people
didn't
want
to
do
that
and
that's
how
we
ended
up
with
this
one.
So
I
think
it's
reasonable
to
discuss
what
the
options
might
be
in
the
current
web
part
to
see
working
group,
even
though
it
might
extend
out
broader
to
other
places,
and
once
we
have
an
idea
of
what
a
solution
looks
like
then
we'll
know
what
the
right
place
is
to
go
discuss
in
our,
but
this
solution
is
pretty
easy.
Now
this.
B
A
So
this
is
this
one
is
about
said,
Kotick
preferences
and
how
it
relates
to
our
TX
read
and
FEC.
There
are
two
questions
that
came
up
were
King
does
said:
Kotick
references
affect
our
TX
read
and
FEC,
and
then
what
happens
if
you
end
up
with
no
codex
specified
like
you,
take
out
all
the
codex
except
for
RTX,
read
and
FEC.
Does
that
result
in
an
error?
A
So
in
PR
2069
we
basically
say
that
codex
echoed
equivalences
applies
to
all
coal
codex,
so
you
can
use
it,
for
example,
to
remove
our
TX
read
or
FEC
codex.
If
you
want-
and
it
also
says
that
if
there's
no
proper
codex
specified,
so
if
all
you're
left
with
is
our
TX
read
and
FEC,
then
you'll
throw
in
an
invalid
modification
error.
E
A
Well,
it's
a
little
bit
more
than
that
because
it
says
basically,
if
you'll
also
get
an
invalid
modification
error.
If
you
attempt
to
if
you're,
basically
it
looks
at
you
have
to
have
a
valid
offer
with
regardless
of
direction.
So
it
looks
at
the
intersection
and
if
you
have
no
codex
at
all,
you'll
also
get
an
invalid
modification
error.
That's
what
it
currently
says.
B
A
D
A
Here's
the
text
that
I
was
referring
to
it
says
if
the
intersection
between
codex
and
get
capabilities,
kind,
codex
or
the
intersection
between
codex
and
get
cables
of
receiver
get
capable
kind
it's
an
empty
set.
Then
you
throw
an
empty
mind.
Ballad
modification
error
thing
to
offer
anyway.
So
basically
the
PR
modifies
this
to
also
say
if
it's
not
just
if
it's
an
empty
set,
but
if
it's
only
our
TX
read
and
FEC
codex,
you
throw
the
invalid
modification
error.
D
Any
created
offering
Creon
sir
there's
a
clarification.
What
preferred
codex
means
that,
like
what
ji-sub
means
by
preferred
codex
and
the
language
says
that
you
know
there's
steps
of
how
to
get
the
preferred
codex
based
on
this
internal
slot,
if
it's
present
or
if,
if
the
professional
o'clock
we
enter
that,
then
you
don't
have
any
preference.
Okay.
A
Right
so
do
we
have
consensus
to
proceed
with
PR
2069.
C
So
this
one
is
about
the
way
simulcast
is
currently
written
to
contain
the
streams
that
are
going
in
both
directions.
So
so
jason
always
shows
examples
that
show
something
like
two
lines
here:
simulcast
send
all
these
and
then
receive,
and
if
you're
the
server
it
says,
simulcast
send
only
the
one
layer
and
receive
the
other
layers.
So
this
is
actually.
C
That
wondering
sorry,
I
Triple,
E
I
meant
sorry
that
one
yes,
so
this
introduces
some
complexity.
Basically,
it's
the
first
time
in
all
of
this
negotiation,
where
one
side
decides
the
identification
for
the
other
side
and
there's
no
real
benefit
for
this,
because
so
the
client
I'm
gonna
refer
to
the
client
as
the
one
who's
sending
simulcast
under
as
the
forwarding
unit.
C
So
the
client
is
the
only
one
who
needs
to
identify
what
the
rates
they're
sending
are
because
that's
the
only
case
where
there
are
multiples
and
the
server
is
always
sending
only
one
one
stream.
So
there's
no
real
need
to
identify
that
in
the
negotiations.
So
what
are
the
so?
The
values
of
this
is
only
if
you
want
to
identify
restrictions
on
the
rids
right.
C
So
if
you
want
to
say,
hey
rid
number
four,
which
is
the
only
rid
that's
going
to
be
sent
by
the
server
that
has
I'm
gonna,
ask
the
server
to
do
something
with
that,
like
limited
test
to
max
size,
or
something
like
that.
But
I
think
these
were.
These
were
supposed
to
be
in
a
different
order.
One
of
the
next
slides
is
gonna
is
going
to
talk
about
how
these
restrictions
are
not
really
sufficient
and
that
we
don't
really
want
to
use
them.
C
So,
basically,
what
you
can
say
is
you
can
you
can
move
these
restrictions
because
there's
only
one
stream,
you
can
move
them
to
the
FMT,
P
lines
or
or
to
other
places.
So
what
so?
The
suggestion
is
to
only
include
the
rids
that
are
going
from
the
client
to
the
server.
So
if
the
client
is
the
offer,
it
would
say,
simulcast
send
and
one
two
three
and
nothing
about
what
it's
the
name
of
the
stream
that
is
going
to
receive.
C
20:54
yeah,
so
there's
a
mismatch
between
the
restrictions
and
the
actual
encoding
parameters,
so
the
restrictions
lists
a
bunch
of
options,
and
it
also
says
that
you
can
register
new
options,
but
sorry
I
heard
some
other
phone,
so
it
also
says
that
restrictions
must
be
respected,
although
it's
possible
that
they
are
not
understood
by
both
parties.
So
if
I
say
something
like
max-width
and
what
other
party
does
not
support
it,
that's
still
fine,
but
what
happens
is
that
the
entire
line
is
not
is
going
to
be
discarded.
C
So
if
I
say
something
like
max
betrayed
max
width
max
height
and
bitrate
is
not
it's
not
understood,
then
I
don't
get
max
height
or
max
width
either.
It's
sort
of
like
an
all-or-nothing
restrictions
are
also
limits,
they're,
not
actual
values,
so
they
don't
really
help
me
communicate
what
the
layers
are
going
to
be.
I
can
say
that
one
of
them
is
at
most
and
I'll
10
1,000.
The
next
is
500.
The
last
one
is
300.
That
doesn't
necessarily
mean
that
they
are
that
these
are
the
values
that
they
are.
It's
just
a
top
limit.
C
Furthermore,
right
if,
if
you
restrict
something
with
a
max
width
max
height
or
let's
say
something
that
does
match
with
the
bit
rate,
they
can
be
disregarded.
The
user
can
call
set
parameters
after
negotiation
to
increase
that
whatever
was
set,
so
there's
no
real
way
to
enforce
it
long
term.
Well,.
C
But
yeah,
like
I,
said,
it's
also
unclear
how
the
layer
configurations
are
communicated
between
the
parties,
and
it
currently
looks
like
all
of
that
is
off.
Pants
is
out
of
band
signaling.
So
what
the
suggestion
is
that
we
should
not
use
restrictions
in
WebRTC.
You
just
indicate
I'm.
Sending
this
rate
is
going
to
be
sent
this
rate
is,
it
is
received
without
any
restrictions
that
accompany
that
rid
as
a
consequence.
C
What
might
happen
is
that
you
might
not
even
need
to
signal
rids
at
all,
because
there's
a
simulcast
line
that
all
rids
can
be
inferred
from
that
simulcast
line.
I,
don't
propose
that
it's
just
something
to
keep
in
mind.
I,
don't
propose
that
because
I
don't
want
to
get
into
the
into
the
point
where
we're
all
removing
the
rid
lines
and
then,
if
we
find
that
hey,
you
know
we
do
want
to
support
something
else
in
the
future.
We're
gonna
have
this
backwards.
Compatibility
nightmare.
C
C
At
2061,
okay,
continuing
so
simulcast
allows
you
to
specify
alternate
alternate
layers
right
and
these
don't
really
have
an
API
surface
for
how
we
can
specify
them.
So,
besides
a
theoretical
point,
there's
no
real
way
to
implement
it.
So
the
way
it
looks
like
is,
it
would
say,
simulcast
send
1,
comma
2
and
then
semicolon
3,
comma
4,
and
then
you
know
I
gave
5
as
the
last
layer.
What
this
means
is
all
three
real
layers,
but
you
know
one
or
two
can
be
sent
in
the
first
layer.
C
Three
or
four
can
be
sent
in
the
next
layer,
and
then
the
red
lines
would
describe
how
these
layers
are
or
how
these
alternatives
are
different,
but
there,
but
they
they
might
be
different
in
their
codec.
They
might
be
different
in
their
restrictions
or
they
might
be
different
in.
You
know
temporal
versus
spatial
sampling
or
things
like
that,
but
there
is
no
API
surface
to
really
support
it,
so
I
can't
call
set
or
a
transceiver
and
give
it
send
encodings
and
specify
how
these
two
layers
are
our
alternatives
for
each
other.
C
Furthermore,
it
looks
like
there
some
of
these.
In
some
of
these
scenarios
there
is
a
dependency.
These
are
more
configurations,
so
if
it
would
be
based
on
encoding,
right,
I
would
say,
I
want
to.
You
know,
layers
1,
3,
1,
&
3
are
both
the
same
codec
and
2
and
fourth,
both
the
same
codec.
It
won't
make
sense
for
for
this.
You
know
for
them
to
really
be
alternatives,
because
using
1,
&,
4
or
2
&
3
are
not
really
viable
configurations.
So
I
would
say
that
there
should
be
a
different
mechanism
to
do
this.
C
Maybe
sending
maybe
I'm
not
saying
that
this
is
the
right
way,
but
perhaps
sending
another
M
section
that
says:
hey
I
can
send
you
simulcast
with
with
this
or
I,
can
send
you
simulcast
with
this
or
if
it's
codecs
I
can
actually
put
the
codecs
on
the
top
of
the
M.
You
know
of
the
M
section,
and
you
can
just
reject
the
codecs
that
you
don't
want.
D
B
B
I
didn't
get
to
write
it
up
before
the
meeting
that
it
should
be
simple,
saying
that
just
put
in
a
new
section,
new
new
paragraph
next
to
create
an
hour
RTC,
RTP
sender,
that's
us
create
an
RTC
RTP
sender
from
our
media.
Scape
description
and
says:
follow
the
basic
rules
to
extract
the
IDS.
You
need
and
paid
the
strikes
and
streams
and
go
for
it.